moonjuice/kernel_arpi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge 9e9fb7655e ("Merge tag 'net-next-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") into android-mainline

Browse Source 
Steps on the way to 5.15-rc1

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I49577d606b2710975407eae3fee60bc331397810
This commit is contained in:
Greg Kroah-Hartman
2021-09-07 14:40:16 +02:00
parent 2344019e04 9e9fb7655e
commit bc2f6edebd
2060 changed files with 89095 additions and 44417 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.mailmap
View File

@@ -229,6 +229,7 @@ Matthew Wilcox <willy@infradead.org> <mawilcox@microsoft.com>
Matthew Wilcox <willy@infradead.org> <willy@debian.org>
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
Matthieu CASTET <castet.matthieu@free.fr>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
Matt Ranostay <mranostay@gmail.com> Matthew Ranostay <mranostay@embeddedalley.com>
@@ -341,6 +342,7 @@ Sumit Semwal <sumit.semwal@ti.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Tejun Heo <htejun@gmail.com>
Thomas Graf <tgraf@suug.ch>
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
Thomas Pedersen <twp@codeaurora.org>
Tiezhu Yang <yangtiezhu@loongson.cn> <kernelpatch@126.com>
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>

40
Documentation/ABI/testing/sysfs-platform-dptf
View File

@@ -111,3 +111,43 @@ Contact: linux-acpi@vger.kernel.org
Description:
(RW) The PCH FIVR (Fully Integrated Voltage Regulator) switching frequency in MHz,
when FIVR clock is 38.4MHz.
What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/fivr_switching_freq_mhz
Date: September, 2021
KernelVersion: v5.15
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Get the FIVR switching control frequency in MHz.
What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/fivr_switching_fault_status
Date: September, 2021
KernelVersion: v5.15
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Read the FIVR switching frequency control fault status.
What: /sys/bus/platform/devices/INTC1045:00/pch_fivr_switch_frequency/ssc_clock_info
Date: September, 2021
KernelVersion: v5.15
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Presents SSC (spread spectrum clock) information for EMI
(Electro magnetic interference) control. This is a bit mask.
Bits Description
[7:0] Sets clock spectrum spread percentage:
0x00=0.2% , 0x3F=10%
1 LSB = 0.1% increase in spread (for
settings 0x01 thru 0x1C)
1 LSB = 0.2% increase in spread (for
settings 0x1E thru 0x3F)
[8] When set to 1, enables spread
spectrum clock
[9] 0: Triangle mode. FFC frequency
walks around the Fcenter in a linear
fashion
1: Random walk mode. FFC frequency
changes randomly within the SSC
(Spread spectrum clock) range
[10] 0: No white noise. 1: Add white noise
to spread waveform
[11] When 1, future writes are ignored.

7
Documentation/ABI/testing/sysfs-platform_profile
View File

@@ -26,3 +26,10 @@ Contact: Hans de Goede <hdegoede@redhat.com>
Description: Reading this file gives the current selected profile for this
device. Writing this file with one of the strings from
platform_profile_choices changes the profile to the new value.
This file can be monitored for changes by polling for POLLPRI,
POLLPRI will be signalled on any changes, independent of those
changes coming from a userspace write; or coming from another
source such as e.g. a hotkey triggered profile change handled
either directly by the embedded-controller or fully handled
inside the kernel.

11
Documentation/admin-guide/cgroup-v2.rst
View File

@@ -2056,6 +2056,17 @@ Cpuset Interface Files
The value of "cpuset.mems" stays constant until the next update
and won't be affected by any memory nodes hotplug events.
Setting a non-empty value to "cpuset.mems" causes memory of
tasks within the cgroup to be migrated to the designated nodes if
they are currently using memory outside of the designated nodes.
There is a cost for this memory migration. The migration
may not be complete and some memory pages may be left behind.
So it is recommended that "cpuset.mems" should be set properly
before spawning new tasks into the cpuset. Even if there is
a need to change "cpuset.mems" with active tasks, it shouldn't
be done frequently.
cpuset.mems.effective
A read-only multiple values file which exists on all
cpuset-enabled cgroups.

715
Documentation/admin-guide/device-mapper/dm-ima.rst Normal file
View File

@@ -0,0 +1,715 @@
======
dm-ima
======
For a given system, various external services/infrastructure tools
(including the attestation service) interact with it - both during the
setup and during rest of the system run-time. They share sensitive data
and/or execute critical workload on that system. The external services
may want to verify the current run-time state of the relevant kernel
subsystems before fully trusting the system with business-critical
data/workload.
Device mapper plays a critical role on a given system by providing
various important functionalities to the block devices using various
target types like crypt, verity, integrity etc. Each of these target
types’ functionalities can be configured with various attributes.
The attributes chosen to configure these target types can significantly
impact the security profile of the block device, and in-turn, of the
system itself. For instance, the type of encryption algorithm and the
key size determines the strength of encryption for a given block device.
Therefore, verifying the current state of various block devices as well
as their various target attributes is crucial for external services before
fully trusting the system with business-critical data/workload.
IMA kernel subsystem provides the necessary functionality for
device mapper to measure the state and configuration of
various block devices -
- by device mapper itself, from within the kernel,
- in a tamper resistant way,
- and re-measured - triggered on state/configuration change.
Setting the IMA Policy:
=======================
For IMA to measure the data on a given system, the IMA policy on the
system needs to be updated to have following line, and the system needs
to be restarted for the measurements to take effect.
::
/etc/ima/ima-policy
measure func=CRITICAL_DATA label=device-mapper template=ima-buf
The measurements will be reflected in the IMA logs, which are located at:
::
/sys/kernel/security/integrity/ima/ascii_runtime_measurements
/sys/kernel/security/integrity/ima/binary_runtime_measurements
Then IMA ASCII measurement log has the following format:
::
<PCR> <TEMPLATE_DATA_DIGEST> <TEMPLATE_NAME> <TEMPLATE_DATA>
PCR := Platform Configuration Register, in which the values are registered.
This is applicable if TPM chip is in use.
TEMPLATE_DATA_DIGEST := Template data digest of the IMA record.
TEMPLATE_NAME := Template name that registered the integrity value (e.g. ima-buf).
TEMPLATE_DATA := <ALG> ":" <EVENT_DIGEST> <EVENT_NAME> <EVENT_DATA>
It contains data for the specific event to be measured,
in a given template data format.
ALG := Algorithm to compute event digest
EVENT_DIGEST := Digest of the event data
EVENT_NAME := Description of the event (e.g. 'dm_table_load').
EVENT_DATA := The event data to be measured.
|
| *NOTE #1:*
| The DM target data measured by IMA subsystem can alternatively
be queried from userspace by setting DM_IMA_MEASUREMENT_FLAG with
DM_TABLE_STATUS_CMD.
|
| *NOTE #2:*
| The Kernel configuration CONFIG_IMA_DISABLE_HTABLE allows measurement of duplicate records.
| To support recording duplicate IMA events in the IMA log, the Kernel needs to be configured with
CONFIG_IMA_DISABLE_HTABLE=y.
Supported Device States:
========================
Following device state changes will trigger IMA measurements:
1. Table load
#. Device resume
#. Device remove
#. Table clear
#. Device rename
1. Table load:
---------------
When a new table is loaded in a device's inactive table slot,
the device information and target specific details from the
targets in the table are measured.
The IMA measurement log has the following format for 'dm_table_load':
::
EVENT_NAME := "dm_table_load"
EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <table_load_data>
dm_version_str := "dm_version=" <N> "." <N> "." <N>
Same as Device Mapper driver version.
device_metadata := <device_name> "," <device_uuid> "," <device_major> "," <device_minor> ","
<minor_count> "," <num_device_targets> ";"
device_name := "name=" <dm-device-name>
device_uuid := "uuid=" <dm-device-uuid>
device_major := "major=" <N>
device_minor := "minor=" <N>
minor_count := "minor_count=" <N>
num_device_targets := "num_targets=" <N>
dm-device-name := Name of the device. If it contains special characters like '\', ',', ';',
they are prefixed with '\'.
dm-device-uuid := UUID of the device. If it contains special characters like '\', ',', ';',
they are prefixed with '\'.
table_load_data := <target_data>
Represents the data (as name=value pairs) from various targets in the table,
which is being loaded into the DM device's inactive table slot.
target_data := <target_data_row> | <target_data><target_data_row>
target_data_row := <target_index> "," <target_begin> "," <target_len> "," <target_name> ","
<target_version> "," <target_attributes> ";"
target_index := "target_index=" <N>
Represents nth target in the table (from 0 to N-1 targets specified in <num_device_targets>)
If all the data for N targets doesn't fit in the given buffer - then the data that fits
in the buffer (say from target 0 to x) is measured in a given IMA event.
The remaining data from targets x+1 to N-1 is measured in the subsequent IMA events,
with the same format as that of 'dm_table_load'
i.e. <dm_version_str> ";" <device_metadata> ";" <table_load_data>.
target_begin := "target_begin=" <N>
target_len := "target_len=" <N>
target_name := Name of the target. 'linear', 'crypt', 'integrity' etc.
The targets that are supported for IMA measurements are documented below in the
'Supported targets' section.
target_version := "target_version=" <N> "." <N> "." <N>
target_attributes := Data containing comma separated list of name=value pairs of target specific attributes.
For instance, if a linear device is created with the following table entries,
# dmsetup create linear1
0 2 linear /dev/loop0 512
2 2 linear /dev/loop0 512
4 2 linear /dev/loop0 512
6 2 linear /dev/loop0 512
Then IMA ASCII measurement log will have the following entry:
(converted from ASCII to text for readability)
10 a8c5ff755561c7a28146389d1514c318592af49a ima-buf sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72
dm_table_load
dm_version=4.45.0;
name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4;
target_index=0,target_begin=0,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
target_index=1,target_begin=2,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
target_index=2,target_begin=4,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
target_index=3,target_begin=6,target_len=2,target_name=linear,target_version=1.4.0,device_name=7:0,start=512;
2. Device resume:
------------------
When a suspended device is resumed, the device information and the hash of the
data from previous load of an active table are measured.
The IMA measurement log has the following format for 'dm_device_resume':
::
EVENT_NAME := "dm_device_resume"
EVENT_DATA := <dm_version_str> ";" <device_metadata> ";" <active_table_hash> ";" <current_device_capacity> ";"
dm_version_str := As described in the 'Table load' section above.
device_metadata := As described in the 'Table load' section above.
active_table_hash := "active_table_hash=" <table_hash_alg> ":" <table_hash>
Rerpresents the hash of the IMA data being measured for the
active table for the device.
table_hash_alg := Algorithm used to compute the hash.
table_hash := Hash of the (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";")
as described in the 'dm_table_load' above.
Note: If the table_load data spans across multiple IMA 'dm_table_load'
events for a given device, the hash is computed combining all the event data
i.e. (<dm_version_str> ";" <device_metadata> ";" <table_load_data> ";")
across all those events.
current_device_capacity := "current_device_capacity=" <N>
For instance, if a linear device is resumed with the following command,
#dmsetup resume linear1
then IMA ASCII measurement log will have an entry with:
(converted from ASCII to text for readability)
10 56c00cc062ffc24ccd9ac2d67d194af3282b934e ima-buf sha256:e7d12c03b958b4e0e53e7363a06376be88d98a1ac191fdbd3baf5e4b77f329b6
dm_device_resume
dm_version=4.45.0;
name=linear1,uuid=,major=253,minor=0,minor_count=1,num_targets=4;
active_table_hash=sha256:4d73481ecce5eadba8ab084640d85bb9ca899af4d0a122989252a76efadc5b72;current_device_capacity=8;
3. Device remove:
------------------
When a device is removed, the device information and a sha256 hash of the
data from an active and inactive table are measured.
The IMA measurement log has the following format for 'dm_device_remove':
::
EVENT_NAME := "dm_device_remove"
EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <device_inactive_metadata> ";"
<active_table_hash> "," <inactive_table_hash> "," <remove_all> ";" <current_device_capacity> ";"
dm_version_str := As described in the 'Table load' section above.
device_active_metadata := Device metadata that reflects the currently loaded active table.
The format is same as 'device_metadata' described in the 'Table load' section above.
device_inactive_metadata := Device metadata that reflects the inactive table.
The format is same as 'device_metadata' described in the 'Table load' section above.
active_table_hash := Hash of the currently loaded active table.
The format is same as 'active_table_hash' described in the 'Device resume' section above.
inactive_table_hash := Hash of the inactive table.
The format is same as 'active_table_hash' described in the 'Device resume' section above.
remove_all := "remove_all=" <yes_no>
yes_no := "y" | "n"
current_device_capacity := "current_device_capacity=" <N>
For instance, if a linear device is removed with the following command,
#dmsetup remove l1
then IMA ASCII measurement log will have the following entry:
(converted from ASCII to text for readability)
10 790e830a3a7a31590824ac0642b3b31c2d0e8b38 ima-buf sha256:ab9f3c959367a8f5d4403d6ce9c3627dadfa8f9f0e7ec7899299782388de3840
dm_device_remove
dm_version=4.45.0;
device_active_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=2;
device_inactive_metadata=name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
active_table_hash=sha256:4a7e62efaebfc86af755831998b7db6f59b60d23c9534fb16a4455907957953a,
inactive_table_hash=sha256:9d79c175bc2302d55a183e8f50ad4bafd60f7692fd6249e5fd213e2464384b86,remove_all=n;
current_device_capacity=2048;
4. Table clear:
----------------
When an inactive table is cleared from the device, the device information and a sha256 hash of the
data from an inactive table are measured.
The IMA measurement log has the following format for 'dm_table_clear':
::
EVENT_NAME := "dm_table_clear"
EVENT_DATA := <dm_version_str> ";" <device_inactive_metadata> ";" <inactive_table_hash> ";" <current_device_capacity> ";"
dm_version_str := As described in the 'Table load' section above.
device_inactive_metadata := Device metadata that was captured during the load time inactive table being cleared.
The format is same as 'device_metadata' described in the 'Table load' section above.
inactive_table_hash := Hash of the inactive table being cleared from the device.
The format is same as 'active_table_hash' described in the 'Device resume' section above.
current_device_capacity := "current_device_capacity=" <N>
For instance, if a linear device's inactive table is cleared,
#dmsetup clear l1
then IMA ASCII measurement log will have an entry with:
(converted from ASCII to text for readability)
10 77d347408f557f68f0041acb0072946bb2367fe5 ima-buf sha256:42f9ca22163fdfa548e6229dece2959bc5ce295c681644240035827ada0e1db5
dm_table_clear
dm_version=4.45.0;
name=l1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
inactive_table_hash=sha256:75c0dc347063bf474d28a9907037eba060bfe39d8847fc0646d75e149045d545;current_device_capacity=1024;
5. Device rename:
------------------
When an device's NAME or UUID is changed, the device information and the new NAME and UUID
are measured.
The IMA measurement log has the following format for 'dm_device_rename':
::
EVENT_NAME := "dm_device_rename"
EVENT_DATA := <dm_version_str> ";" <device_active_metadata> ";" <new_device_name> "," <new_device_uuid> ";" <current_device_capacity> ";"
dm_version_str := As described in the 'Table load' section above.
device_active_metadata := Device metadata that reflects the currently loaded active table.
The format is same as 'device_metadata' described in the 'Table load' section above.
new_device_name := "new_name=" <dm-device-name>
dm-device-name := Same as <dm-device-name> described in 'Table load' section above
new_device_uuid := "new_uuid=" <dm-device-uuid>
dm-device-uuid := Same as <dm-device-uuid> described in 'Table load' section above
current_device_capacity := "current_device_capacity=" <N>
E.g 1: if a linear device's name is changed with the following command,
#dmsetup rename linear1 --setuuid 1234-5678
then IMA ASCII measurement log will have an entry with:
(converted from ASCII to text for readability)
10 8b0423209b4c66ac1523f4c9848c9b51ee332f48 ima-buf sha256:6847b7258134189531db593e9230b257c84f04038b5a18fd2e1473860e0569ac
dm_device_rename
dm_version=4.45.0;
name=linear1,uuid=,major=253,minor=2,minor_count=1,num_targets=1;new_name=linear1,new_uuid=1234-5678;
current_device_capacity=1024;
E.g 2: if a linear device's name is changed with the following command,
# dmsetup rename linear1 linear=2
then IMA ASCII measurement log will have an entry with:
(converted from ASCII to text for readability)
10 bef70476b99c2bdf7136fae033aa8627da1bf76f ima-buf sha256:8c6f9f53b9ef9dc8f92a2f2cca8910e622543d0f0d37d484870cb16b95111402
dm_device_rename
dm_version=4.45.0;
name=linear1,uuid=1234-5678,major=253,minor=2,minor_count=1,num_targets=1;
new_name=linear\=2,new_uuid=1234-5678;
current_device_capacity=1024;
Supported targets:
==================
Following targets are supported to measure their data using IMA:
1. cache
#. crypt
#. integrity
#. linear
#. mirror
#. multipath
#. raid
#. snapshot
#. striped
#. verity
1. cache
---------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'cache' target.
::
target_attributes := <target_name> "," <target_version> "," <metadata_mode> "," <cache_metadata_device> ","
<cache_device> "," <cache_origin_device> "," <writethrough> "," <writeback> ","
<passthrough> "," <no_discard_passdown> ";"
target_name := "target_name=cache"
target_version := "target_version=" <N> "." <N> "." <N>
metadata_mode := "metadata_mode=" <cache_metadata_mode>
cache_metadata_mode := "fail" | "ro" | "rw"
cache_device := "cache_device=" <cache_device_name_string>
cache_origin_device := "cache_origin_device=" <cache_origin_device_string>
writethrough := "writethrough=" <yes_no>
writeback := "writeback=" <yes_no>
passthrough := "passthrough=" <yes_no>
no_discard_passdown := "no_discard_passdown=" <yes_no>
yes_no := "y" | "n"
E.g.
When a 'cache' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'cache' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;name=cache1,uuid=cache_uuid,major=253,minor=2,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=28672,target_name=cache,target_version=2.2.0,metadata_mode=rw,
cache_metadata_device=253:4,cache_device=253:3,cache_origin_device=253:5,writethrough=y,writeback=n,
passthrough=n,metadata2=y,no_discard_passdown=n;
2. crypt
---------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'crypt' target.
::
target_attributes := <target_name> "," <target_version> "," <allow_discards> "," <same_cpu_crypt> ","
<submit_from_crypt_cpus> "," <no_read_workqueue> "," <no_write_workqueue> ","
<iv_large_sectors> "," <iv_large_sectors> "," [<integrity_tag_size> ","] [<cipher_auth> ","]
[<sector_size> ","] [<cipher_string> ","] <key_size> "," <key_parts> ","
<key_extra_size> "," <key_mac_size> ";"
target_name := "target_name=crypt"
target_version := "target_version=" <N> "." <N> "." <N>
allow_discards := "allow_discards=" <yes_no>
same_cpu_crypt := "same_cpu_crypt=" <yes_no>
submit_from_crypt_cpus := "submit_from_crypt_cpus=" <yes_no>
no_read_workqueue := "no_read_workqueue=" <yes_no>
no_write_workqueue := "no_write_workqueue=" <yes_no>
iv_large_sectors := "iv_large_sectors=" <yes_no>
integrity_tag_size := "integrity_tag_size=" <N>
cipher_auth := "cipher_auth=" <string>
sector_size := "sector_size=" <N>
cipher_string := "cipher_string="
key_size := "key_size=" <N>
key_parts := "key_parts=" <N>
key_extra_size := "key_extra_size=" <N>
key_mac_size := "key_mac_size=" <N>
yes_no := "y" | "n"
E.g.
When a 'crypt' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'crypt' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=crypt1,uuid=crypt_uuid1,major=253,minor=0,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=1953125,target_name=crypt,target_version=1.23.0,
allow_discards=y,same_cpu=n,submit_from_crypt_cpus=n,no_read_workqueue=n,no_write_workqueue=n,
iv_large_sectors=n,cipher_string=aes-xts-plain64,key_size=32,key_parts=1,key_extra_size=0,key_mac_size=0;
3. integrity
-------------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'integrity' target.
::
target_attributes := <target_name> "," <target_version> "," <dev_name> "," <start>
<tag_size> "," <mode> "," [<meta_device> ","] [<block_size> ","] <recalculate> ","
<allow_discards> "," <fix_padding> "," <fix_hmac> "," <legacy_recalculate> ","
<journal_sectors> "," <interleave_sectors> "," <buffer_sectors> ";"
target_name := "target_name=integrity"
target_version := "target_version=" <N> "." <N> "." <N>
dev_name := "dev_name=" <device_name_str>
start := "start=" <N>
tag_size := "tag_size=" <N>
mode := "mode=" <integrity_mode_str>
integrity_mode_str := "J" | "B" | "D" | "R"
meta_device := "meta_device=" <meta_device_str>
block_size := "block_size=" <N>
recalculate := "recalculate=" <yes_no>
allow_discards := "allow_discards=" <yes_no>
fix_padding := "fix_padding=" <yes_no>
fix_hmac := "fix_hmac=" <yes_no>
legacy_recalculate := "legacy_recalculate=" <yes_no>
journal_sectors := "journal_sectors=" <N>
interleave_sectors := "interleave_sectors=" <N>
buffer_sectors := "buffer_sectors=" <N>
yes_no := "y" | "n"
E.g.
When a 'integrity' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'integrity' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=integrity1,uuid=,major=253,minor=1,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=7856,target_name=integrity,target_version=1.10.0,
dev_name=253:0,start=0,tag_size=32,mode=J,recalculate=n,allow_discards=n,fix_padding=n,
fix_hmac=n,legacy_recalculate=n,journal_sectors=88,interleave_sectors=32768,buffer_sectors=128;
4. linear
----------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'linear' target.
::
target_attributes := <target_name> "," <target_version> "," <device_name> <,> <start> ";"
target_name := "target_name=linear"
target_version := "target_version=" <N> "." <N> "." <N>
device_name := "device_name=" <linear_device_name_str>
start := "start=" <N>
E.g.
When a 'linear' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'linear' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=linear1,uuid=linear_uuid1,major=253,minor=2,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=28672,target_name=linear,target_version=1.4.0,
device_name=253:1,start=2048;
5. mirror
----------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'mirror' target.
::
target_attributes := <target_name> "," <target_version> "," <nr_mirrors> ","
<mirror_device_data> "," <handle_errors> "," <keep_log> "," <log_type_status> ";"
target_name := "target_name=mirror"
target_version := "target_version=" <N> "." <N> "." <N>
nr_mirrors := "nr_mirrors=" <NR>
mirror_device_data := <mirror_device_row> | <mirror_device_data><mirror_device_row>
mirror_device_row is repeated <NR> times - for <NR> described in <nr_mirrors>.
mirror_device_row := <mirror_device_name> "," <mirror_device_status>
mirror_device_name := "mirror_device_" <X> "=" <mirror_device_name_str>
where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>.
mirror_device_status := "mirror_device_" <X> "_status=" <mirror_device_status_char>
where <X> ranges from 0 to (<NR> -1) - for <NR> described in <nr_mirrors>.
mirror_device_status_char := "A" | "F" | "D" | "S" | "R" | "U"
handle_errors := "handle_errors=" <yes_no>
keep_log := "keep_log=" <yes_no>
log_type_status := "log_type_status=" <log_type_status_str>
yes_no := "y" | "n"
E.g.
When a 'mirror' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'mirror' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=mirror1,uuid=mirror_uuid1,major=253,minor=6,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=2048,target_name=mirror,target_version=1.14.0,nr_mirrors=2,
mirror_device_0=253:4,mirror_device_0_status=A,
mirror_device_1=253:5,mirror_device_1_status=A,
handle_errors=y,keep_log=n,log_type_status=;
6. multipath
-------------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'multipath' target.
::
target_attributes := <target_name> "," <target_version> "," <nr_priority_groups>
["," <pg_state> "," <priority_groups> "," <priority_group_paths>] ";"
target_name := "target_name=multipath"
target_version := "target_version=" <N> "." <N> "." <N>
nr_priority_groups := "nr_priority_groups=" <NPG>
priority_groups := <priority_groups_row>|<priority_groups_row><priority_groups>
priority_groups_row := "pg_state_" <X> "=" <pg_state_str> "," "nr_pgpaths_" <X> "=" <NPGP> ","
"path_selector_name_" <X> "=" <string> "," <priority_group_paths>
where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>.
pg_state_str := "E" | "A" | "D"
<priority_group_paths> := <priority_group_paths_row> | <priority_group_paths_row><priority_group_paths>
priority_group_paths_row := "path_name_" <X> "_" <Y> "=" <string> "," "is_active_" <X> "_" <Y> "=" <is_active_str>
"fail_count_" <X> "_" <Y> "=" <N> "," "path_selector_status_" <X> "_" <Y> "=" <path_selector_status_str>
where <X> ranges from 0 to (<NPG> -1) - for <NPG> described in <nr_priority_groups>,
and <Y> ranges from 0 to (<NPGP> -1) - for <NPGP> described in <priority_groups_row>.
is_active_str := "A" | "F"
E.g.
When a 'multipath' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'multipath' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=mp,uuid=,major=253,minor=0,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=2097152,target_name=multipath,target_version=1.14.0,nr_priority_groups=2,
pg_state_0=E,nr_pgpaths_0=2,path_selector_name_0=queue-length,
path_name_0_0=8:16,is_active_0_0=A,fail_count_0_0=0,path_selector_status_0_0=,
path_name_0_1=8:32,is_active_0_1=A,fail_count_0_1=0,path_selector_status_0_1=,
pg_state_1=E,nr_pgpaths_1=2,path_selector_name_1=queue-length,
path_name_1_0=8:48,is_active_1_0=A,fail_count_1_0=0,path_selector_status_1_0=,
path_name_1_1=8:64,is_active_1_1=A,fail_count_1_1=0,path_selector_status_1_1=;
7. raid
--------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'raid' target.
::
target_attributes := <target_name> "," <target_version> "," <raid_type> "," <raid_disks> "," <raid_state>
<raid_device_status> ["," journal_dev_mode] ";"
target_name := "target_name=raid"
target_version := "target_version=" <N> "." <N> "." <N>
raid_type := "raid_type=" <raid_type_str>
raid_disks := "raid_disks=" <NRD>
raid_state := "raid_state=" <raid_state_str>
raid_state_str := "frozen" | "reshape" |"resync" | "check" | "repair" | "recover" | "idle" |"undef"
raid_device_status := <raid_device_status_row> | <raid_device_status_row><raid_device_status>
<raid_device_status_row> is repeated <NRD> times - for <NRD> described in <raid_disks>.
raid_device_status_row := "raid_device_" <X> "_status=" <raid_device_status_str>
where <X> ranges from 0 to (<NRD> -1) - for <NRD> described in <raid_disks>.
raid_device_status_str := "A" | "D" | "a" | "-"
journal_dev_mode := "journal_dev_mode=" <journal_dev_mode_str>
journal_dev_mode_str := "writethrough" | "writeback" | "invalid"
E.g.
When a 'raid' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'raid' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=raid_LV1,uuid=uuid_raid_LV1,major=253,minor=12,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=2048,target_name=raid,target_version=1.15.1,
raid_type=raid10,raid_disks=4,raid_state=idle,
raid_device_0_status=A,
raid_device_1_status=A,
raid_device_2_status=A,
raid_device_3_status=A;
8. snapshot
------------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'snapshot' target.
::
target_attributes := <target_name> "," <target_version> "," <snap_origin_name> ","
<snap_cow_name> "," <snap_valid> "," <snap_merge_failed> "," <snapshot_overflowed> ";"
target_name := "target_name=snapshot"
target_version := "target_version=" <N> "." <N> "." <N>
snap_origin_name := "snap_origin_name=" <string>
snap_cow_name := "snap_cow_name=" <string>
snap_valid := "snap_valid=" <yes_no>
snap_merge_failed := "snap_merge_failed=" <yes_no>
snapshot_overflowed := "snapshot_overflowed=" <yes_no>
yes_no := "y" | "n"
E.g.
When a 'snapshot' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'snapshot' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=snap1,uuid=snap_uuid1,major=253,minor=13,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=4096,target_name=snapshot,target_version=1.16.0,
snap_origin_name=253:11,snap_cow_name=253:12,snap_valid=y,snap_merge_failed=n,snapshot_overflowed=n;
9. striped
-----------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'striped' target.
::
target_attributes := <target_name> "," <target_version> "," <stripes> "," <chunk_size> ","
<stripe_data> ";"
target_name := "target_name=striped"
target_version := "target_version=" <N> "." <N> "." <N>
stripes := "stripes=" <NS>
chunk_size := "chunk_size=" <N>
stripe_data := <stripe_data_row>|<stripe_data><stripe_data_row>
stripe_data_row := <stripe_device_name> "," <stripe_physical_start> "," <stripe_status>
stripe_device_name := "stripe_" <X> "_device_name=" <stripe_device_name_str>
where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
stripe_physical_start := "stripe_" <X> "_physical_start=" <N>
where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
stripe_status := "stripe_" <X> "_status=" <stripe_status_str>
where <X> ranges from 0 to (<NS> -1) - for <NS> described in <stripes>.
stripe_status_str := "D" | "A"
E.g.
When a 'striped' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'striped' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=striped1,uuid=striped_uuid1,major=253,minor=5,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=640,target_name=striped,target_version=1.6.0,stripes=2,chunk_size=64,
stripe_0_device_name=253:0,stripe_0_physical_start=2048,stripe_0_status=A,
stripe_1_device_name=253:3,stripe_1_physical_start=2048,stripe_1_status=A;
10. verity
----------
The 'target_attributes' (described as part of EVENT_DATA in 'Table load'
section above) has the following data format for 'verity' target.
::
target_attributes := <target_name> "," <target_version> "," <hash_failed> "," <verity_version> ","
<data_device_name> "," <hash_device_name> "," <verity_algorithm> "," <root_digest> ","
<salt> "," <ignore_zero_blocks> "," <check_at_most_once> ["," <root_hash_sig_key_desc>]
["," <verity_mode>] ";"
target_name := "target_name=verity"
target_version := "target_version=" <N> "." <N> "." <N>
hash_failed := "hash_failed=" <hash_failed_str>
hash_failed_str := "C" | "V"
verity_version := "verity_version=" <verity_version_str>
data_device_name := "data_device_name=" <data_device_name_str>
hash_device_name := "hash_device_name=" <hash_device_name_str>
verity_algorithm := "verity_algorithm=" <verity_algorithm_str>
root_digest := "root_digest=" <root_digest_str>
salt := "salt=" <salt_str>
salt_str := "-" <verity_salt_str>
ignore_zero_blocks := "ignore_zero_blocks=" <yes_no>
check_at_most_once := "check_at_most_once=" <yes_no>
root_hash_sig_key_desc := "root_hash_sig_key_desc="
verity_mode := "verity_mode=" <verity_mode_str>
verity_mode_str := "ignore_corruption" | "restart_on_corruption" | "panic_on_corruption" | "invalid"
yes_no := "y" | "n"
E.g.
When a 'verity' target is loaded, then IMA ASCII measurement log will have an entry
similar to the following, depicting what 'verity' attributes are measured in EVENT_DATA
for 'dm_table_load' event.
(converted from ASCII to text for readability)
dm_version=4.45.0;
name=test-verity,uuid=,major=253,minor=2,minor_count=1,num_targets=1;
target_index=0,target_begin=0,target_len=1953120,target_name=verity,target_version=1.8.0,hash_failed=V,
verity_version=1,data_device_name=253:1,hash_device_name=253:0,verity_algorithm=sha256,
root_digest=29cb87e60ce7b12b443ba6008266f3e41e93e403d7f298f8e3f316b29ff89c5e,
salt=e48da609055204e89ae53b655ca2216dd983cf3cb829f34f63a297d106d53e2d,
ignore_zero_blocks=n,check_at_most_once=n;

1
Documentation/admin-guide/device-mapper/index.rst
View File

@@ -13,6 +13,7 @@ Device Mapper
dm-dust
dm-ebs
dm-flakey
dm-ima
dm-init
dm-integrity
dm-io

16
Documentation/admin-guide/device-mapper/writecache.rst
View File

@@ -78,13 +78,23 @@ Status:
2. the number of blocks
3. the number of free blocks
4. the number of blocks under writeback
5. the number of read requests
6. the number of read requests that hit the cache
7. the number of write requests
8. the number of write requests that hit uncommitted block
9. the number of write requests that hit committed block
10. the number of write requests that bypass the cache
11. the number of write requests that are allocated in the cache
12. the number of write requests that are blocked on the freelist
13. the number of flush requests
14. the number of discard requests
Messages:
flush
flush the cache device. The message returns successfully
Flush the cache device. The message returns successfully
if the cache device was flushed without an error
flush_on_suspend
flush the cache device on next suspend. Use this message
Flush the cache device on next suspend. Use this message
when you are going to remove the cache device. The proper
sequence for removing the cache device is:
@@ -98,3 +108,5 @@ Messages:
6. the cache device is now inactive and it can be deleted
cleaner
See above "cleaner" constructor documentation.
clear_stats
Clear the statistics that are reported on the status line

2
Documentation/admin-guide/kernel-parameters.txt
View File

@@ -4966,8 +4966,6 @@
sa1100ir [NET]
See drivers/net/irda/sa1100_ir.c.
sbni= [NET] Granch SBNI12 leased line adapter
sched_verbose [KNL] Enables verbose scheduler debug messages.
schedstats= [KNL,X86] Enable or disable scheduled statistics.

10
Documentation/bpf/index.rst
View File

@@ -15,15 +15,7 @@ that goes into great technical depth about the BPF Architecture.
libbpf
======
Libbpf is a userspace library for loading and interacting with bpf programs.
.. toctree::
:maxdepth: 1
libbpf/libbpf
libbpf/libbpf_api
libbpf/libbpf_build
libbpf/libbpf_naming_convention
Documentation/bpf/libbpf/libbpf.rst is a userspace library for loading and interacting with bpf programs.
BPF Type Format (BTF)
=====================

8
Documentation/bpf/libbpf/libbpf.rst → Documentation/bpf/libbpf/index.rst
View File

@@ -3,6 +3,14 @@
libbpf
======
For API documentation see the `versioned API documentation site <https://libbpf.readthedocs.io/en/latest/api.html>`_.
.. toctree::
:maxdepth: 1
libbpf_naming_convention
libbpf_build
This is documentation for libbpf, a userspace library for loading and
interacting with bpf programs.

27
Documentation/bpf/libbpf/libbpf_api.rst
View File

@@ -1,27 +0,0 @@
.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
API
===
This documentation is autogenerated from header files in libbpf, tools/lib/bpf
.. kernel-doc:: tools/lib/bpf/libbpf.h
:internal:
.. kernel-doc:: tools/lib/bpf/bpf.h
:internal:
.. kernel-doc:: tools/lib/bpf/btf.h
:internal:
.. kernel-doc:: tools/lib/bpf/xsk.h
:internal:
.. kernel-doc:: tools/lib/bpf/bpf_tracing.h
:internal:
.. kernel-doc:: tools/lib/bpf/bpf_core_read.h
:internal:
.. kernel-doc:: tools/lib/bpf/bpf_endian.h
:internal:

2
Documentation/bpf/libbpf/libbpf_naming_convention.rst
View File

@@ -69,7 +69,7 @@ functions. These can be mixed and matched. Note that these functions
are not reentrant for performance reasons.
ABI
==========
---
libbpf can be both linked statically or used as DSO. To avoid possible
conflicts with other libraries an application is linked with, all

53
Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml Normal file
View File

@@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/amd,sbrmi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: >
Sideband Remote Management Interface (SB-RMI) compliant
AMD SoC power device.
maintainers:
- Akshay Gupta <Akshay.Gupta@amd.com>
description: |
SB Remote Management Interface (SB-RMI) is an SMBus compatible
interface that reports AMD SoC's Power (normalized Power) using,
Mailbox Service Request and resembles a typical 8-pin remote power
sensor's I2C interface to BMC. The power attributes in hwmon
reports power in microwatts.
properties:
compatible:
enum:
- amd,sbrmi
reg:
maxItems: 1
description: |
I2C bus address of the device as specified in Section SBI SMBus Address
of the SoC register reference. The SB-RMI address is normally 78h for
socket 0 and 70h for socket 1, but it could vary based on hardware
address select pins.
\[open source SoC register reference\]
https://www.amd.com/en/support/tech-docs?keyword=55898
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
sbrmi@3c {
compatible = "amd,sbrmi";
reg = <0x3c>;
};
};
...

41
Documentation/devicetree/bindings/hwmon/winbond,w83781d.yaml Normal file
View File

@@ -0,0 +1,41 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/hwmon/winbond,w83781d.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Winbond W83781 and compatible hardware monitor IC
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
properties:
compatible:
enum:
- winbond,w83781d
- winbond,w83781g
- winbond,w83782d
- winbond,w83783s
- asus,as99127f
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
temperature-sensor@28 {
compatible = "winbond,w83781d";
reg = <0x28>;
};
};

6
Documentation/devicetree/bindings/leds/common.yaml
View File

@@ -128,6 +128,12 @@ properties:
as a panic indicator.
type: boolean
retain-state-shutdown:
description:
This property specifies that the LED should not be turned off or changed
when the system shuts down.
type: boolean
trigger-sources:
description: |
List of devices which should be used as a source triggering this LED

18
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
View File

@@ -29,6 +29,7 @@ properties:
- fsl,imx53-esdhc
- fsl,imx6q-usdhc
- fsl,imx6sl-usdhc
- fsl,imx6sll-usdhc
- fsl,imx6sx-usdhc
- fsl,imx6ull-usdhc
- fsl,imx7d-usdhc
@@ -115,12 +116,17 @@ properties:
- const: per
pinctrl-names:
minItems: 1
items:
- const: default
- const: state_100mhz
- const: state_200mhz
- const: sleep
oneOf:
- minItems: 3
items:
- const: default
- const: state_100mhz
- const: state_200mhz
- const: sleep
- minItems: 1
items:
- const: default
- const: sleep
required:
- compatible

4
Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.yaml
View File

@@ -11,7 +11,9 @@ maintainers:
properties:
compatible:
const: mmc-pwrseq-sd8787
enum:
- mmc-pwrseq-sd8787
- mmc-pwrseq-wilc1000
powerdown-gpios:
minItems: 1

133
Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml
View File

@@ -9,9 +9,6 @@ title: Renesas SDHI SD/MMC controller
maintainers:
- Wolfram Sang <wsa+renesas@sang-engineering.com>
allOf:
- $ref: "mmc-controller.yaml"
properties:
compatible:
oneOf:
@@ -47,19 +44,20 @@ properties:
- const: renesas,sdhi-mmc-r8a77470 # RZ/G1C (SDHI/MMC IP)
- items:
- enum:
- renesas,sdhi-r8a774a1 # RZ/G2M
- renesas,sdhi-r8a774b1 # RZ/G2N
- renesas,sdhi-r8a774c0 # RZ/G2E
- renesas,sdhi-r8a774e1 # RZ/G2H
- renesas,sdhi-r8a7795 # R-Car H3
- renesas,sdhi-r8a7796 # R-Car M3-W
- renesas,sdhi-r8a77961 # R-Car M3-W+
- renesas,sdhi-r8a77965 # R-Car M3-N
- renesas,sdhi-r8a77970 # R-Car V3M
- renesas,sdhi-r8a77980 # R-Car V3H
- renesas,sdhi-r8a77990 # R-Car E3
- renesas,sdhi-r8a77995 # R-Car D3
- renesas,sdhi-r8a779a0 # R-Car V3U
- renesas,sdhi-r8a774a1 # RZ/G2M
- renesas,sdhi-r8a774b1 # RZ/G2N
- renesas,sdhi-r8a774c0 # RZ/G2E
- renesas,sdhi-r8a774e1 # RZ/G2H
- renesas,sdhi-r8a7795 # R-Car H3
- renesas,sdhi-r8a7796 # R-Car M3-W
- renesas,sdhi-r8a77961 # R-Car M3-W+
- renesas,sdhi-r8a77965 # R-Car M3-N
- renesas,sdhi-r8a77970 # R-Car V3M
- renesas,sdhi-r8a77980 # R-Car V3H
- renesas,sdhi-r8a77990 # R-Car E3
- renesas,sdhi-r8a77995 # R-Car D3
- renesas,sdhi-r8a779a0 # R-Car V3U
- renesas,sdhi-r9a07g044 # RZ/G2{L,LC}
- const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2
reg:
@@ -69,15 +67,9 @@ properties:
minItems: 1
maxItems: 3
clocks:
minItems: 1
maxItems: 2
clocks: true
clock-names:
minItems: 1
items:
- const: core
- const: cd
clock-names: true
dmas:
minItems: 4
@@ -104,14 +96,82 @@ properties:
pinctrl-1:
maxItems: 1
pinctrl-names:
minItems: 1
items:
- const: default
- const: state_uhs
pinctrl-names: true
max-frequency: true
allOf:
- $ref: "mmc-controller.yaml"
- if:
properties:
compatible:
contains:
const: renesas,sdhi-r9a07g044
then:
properties:
clocks:
items:
- description: IMCLK, SDHI channel main clock1.
- description: IMCLK2, SDHI channel main clock2. When this clock is
turned off, external SD card detection cannot be
detected.
- description: CLK_HS, SDHI channel High speed clock which operates
4 times that of SDHI channel main clock1.
- description: ACLK, SDHI channel bus clock.
clock-names:
items:
- const: imclk
- const: imclk2
- const: clk_hs
- const: aclk
required:
- clock-names
- resets
else:
properties:
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
items:
- const: core
- const: cd
- if:
properties:
compatible:
contains:
const: renesas,sdhi-mmc-r8a77470
then:
properties:
pinctrl-names:
items:
- const: state_uhs
else:
properties:
pinctrl-names:
minItems: 1
items:
- const: default
- const: state_uhs
- if:
properties:
compatible:
contains:
enum:
- renesas,sdhi-r7s72100
- renesas,sdhi-r7s9210
then:
required:
- clock-names
description:
The internal card detection logic that exists in these controllers is
sectioned off to be run by a separate second clock source to allow
the main core clock to be turned off to save power.
required:
- compatible
- reg
@@ -119,21 +179,6 @@ required:
- clocks
- power-domains
if:
properties:
compatible:
contains:
enum:
- renesas,sdhi-r7s72100
- renesas,sdhi-r7s9210
then:
required:
- clock-names
description:
The internal card detection logic that exists in these controllers is
sectioned off to be run by a separate second clock source to allow
the main core clock to be turned off to save power.
unevaluatedProperties: false
examples:

1
Documentation/devicetree/bindings/mmc/sdhci-msm.txt
View File

@@ -19,6 +19,7 @@ Required properties:
"qcom,msm8996-sdhci", "qcom,sdhci-msm-v4"
"qcom,qcs404-sdhci", "qcom,sdhci-msm-v5"
"qcom,sc7180-sdhci", "qcom,sdhci-msm-v5";
"qcom,sc7280-sdhci", "qcom,sdhci-msm-v5";
"qcom,sdm845-sdhci", "qcom,sdhci-msm-v5"
"qcom,sdx55-sdhci", "qcom,sdhci-msm-v5";
"qcom,sm8250-sdhci", "qcom,sdhci-msm-v5"

43
Documentation/devicetree/bindings/net/brcm,unimac-mdio.txt
View File

@@ -1,43 +0,0 @@
* Broadcom UniMAC MDIO bus controller
Required properties:
- compatible: should one from "brcm,genet-mdio-v1", "brcm,genet-mdio-v2",
"brcm,genet-mdio-v3", "brcm,genet-mdio-v4", "brcm,genet-mdio-v5" or
"brcm,unimac-mdio"
- reg: address and length of the register set for the device, first one is the
base register, and the second one is optional and for indirect accesses to
larger than 16-bits MDIO transactions
- reg-names: name(s) of the register must be "mdio" and optional "mdio_indir_rw"
- #size-cells: must be 1
- #address-cells: must be 0
Optional properties:
- interrupts: must be one if the interrupt is shared with the Ethernet MAC or
Ethernet switch this MDIO block is integrated from, or must be two, if there
are two separate interrupts, first one must be "mdio done" and second must be
for "mdio error"
- interrupt-names: must be "mdio_done_error" when there is a share interrupt fed
to this hardware block, or must be "mdio_done" for the first interrupt and
"mdio_error" for the second when there are separate interrupts
- clocks: A reference to the clock supplying the MDIO bus controller
- clock-frequency: the MDIO bus clock that must be output by the MDIO bus
hardware, if absent, the default hardware values are used
Child nodes of this MDIO bus controller node are standard Ethernet PHY device
nodes as described in Documentation/devicetree/bindings/net/phy.txt
Example:
mdio@403c0 {
compatible = "brcm,unimac-mdio";
reg = <0x403c0 0x8 0x40300 0x18>;
reg-names = "mdio", "mdio_indir_rw";
#size-cells = <1>;
#address-cells = <0>;
...
phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
};

84
Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml Normal file
View File

@@ -0,0 +1,84 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/brcm,unimac-mdio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom UniMAC MDIO bus controller
maintainers:
- Rafał Miłecki <rafal@milecki.pl>
allOf:
- $ref: mdio.yaml#
properties:
compatible:
enum:
- brcm,genet-mdio-v1
- brcm,genet-mdio-v2
- brcm,genet-mdio-v3
- brcm,genet-mdio-v4
- brcm,genet-mdio-v5
- brcm,unimac-mdio
reg:
minItems: 1
items:
- description: base register
- description: indirect accesses to larger than 16-bits MDIO transactions
reg-names:
minItems: 1
items:
- const: mdio
- const: mdio_indir_rw
interrupts:
oneOf:
- description: >
Interrupt shared with the Ethernet MAC or Ethernet switch this MDIO
block is integrated from
- items:
- description: |
"mdio done" interrupt
- description: |
"mdio error" interrupt
interrupt-names:
oneOf:
- const: mdio_done_error
- items:
- const: mdio_done
- const: mdio_error
clocks:
description: A reference to the clock supplying the MDIO bus controller
clock-frequency:
description: >
The MDIO bus clock that must be output by the MDIO bus hardware, if
absent, the default hardware values are used
unevaluatedProperties: false
required:
- reg
- reg-names
- '#address-cells'
- '#size-cells'
examples:
- |
mdio@403c0 {
compatible = "brcm,unimac-mdio";
reg = <0x403c0 0x8>, <0x40300 0x18>;
reg-names = "mdio", "mdio_indir_rw";
#address-cells = <1>;
#size-cells = <0>;
ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
};

119
Documentation/devicetree/bindings/net/can/bosch,c_can.yaml Normal file
View File

@@ -0,0 +1,119 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/can/bosch,c_can.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Bosch C_CAN/D_CAN controller Device Tree Bindings
description: Bosch C_CAN/D_CAN controller for CAN bus
maintainers:
- Dario Binacchi <dariobin@libero.it>
allOf:
- $ref: can-controller.yaml#
properties:
compatible:
oneOf:
- enum:
- bosch,c_can
- bosch,d_can
- ti,dra7-d_can
- ti,am3352-d_can
- items:
- enum:
- ti,am4372-d_can
- const: ti,am3352-d_can
reg:
maxItems: 1
interrupts:
minItems: 1
maxItems: 4
power-domains:
description: |
Should contain a phandle to a PM domain provider node and an args
specifier containing the DCAN device id value. It's mandatory for
Keystone 2 66AK2G SoCs only.
maxItems: 1
clocks:
description: |
CAN functional clock phandle.
maxItems: 1
clock-names:
maxItems: 1
syscon-raminit:
description: |
Handle to system control region that contains the RAMINIT register,
register offset to the RAMINIT register and the CAN instance number (0
offset).
$ref: /schemas/types.yaml#/definitions/phandle-array
items:
items:
- description: The phandle to the system control region.
- description: The register offset.
- description: The CAN instance number.
resets:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
if:
properties:
compatible:
contains:
enum:
- bosch,d_can
then:
properties:
interrupts:
minItems: 4
maxItems: 4
items:
- description: Error and status IRQ
- description: Message object IRQ
- description: RAM ECC correctable error IRQ
- description: RAM ECC non-correctable error IRQ
else:
properties:
interrupts:
maxItems: 1
items:
- description: Error and status IRQ
additionalProperties: false
examples:
- |
#include <dt-bindings/reset/altr,rst-mgr.h>
can@ffc00000 {
compatible = "bosch,d_can";
reg = <0xffc00000 0x1000>;
interrupts = <0 131 4>, <0 132 4>, <0 133 4>, <0 134 4>;
clocks = <&can0_clk>;
resets = <&rst CAN0_RESET>;
};
- |
can@0 {
compatible = "ti,am3352-d_can";
reg = <0x0 0x2000>;
clocks = <&dcan1_fck>;
clock-names = "fck";
syscon-raminit = <&scm_conf 0x644 1>;
interrupts = <55>;
};

9
Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
View File

@@ -104,9 +104,18 @@ properties:
maximum: 32
maxItems: 1
power-domains:
description:
Power domain provider node and an args specifier containing
the can device id value.
maxItems: 1
can-transceiver:
$ref: can-transceiver.yaml#
phys:
maxItems: 1
required:
- compatible
- reg

65
Documentation/devicetree/bindings/net/can/c_can.txt
View File

@@ -1,65 +0,0 @@
Bosch C_CAN/D_CAN controller Device Tree Bindings
-------------------------------------------------
Required properties:
- compatible : Should be "bosch,c_can" for C_CAN controllers and
"bosch,d_can" for D_CAN controllers.
Can be "ti,dra7-d_can", "ti,am3352-d_can" or
"ti,am4372-d_can".
- reg : physical base address and size of the C_CAN/D_CAN
registers map
- interrupts : property with a value describing the interrupt
number
The following are mandatory properties for DRA7x, AM33xx and AM43xx SoCs only:
- ti,hwmods : Must be "d_can<n>" or "c_can<n>", n being the
instance number
The following are mandatory properties for Keystone 2 66AK2G SoCs only:
- power-domains : Should contain a phandle to a PM domain provider node
and an args specifier containing the DCAN device id
value. This property is as per the binding,
Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml
- clocks : CAN functional clock phandle. This property is as per the
binding,
Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
Optional properties:
- syscon-raminit : Handle to system control region that contains the
RAMINIT register, register offset to the RAMINIT
register and the CAN instance number (0 offset).
Note: "ti,hwmods" field is used to fetch the base address and irq
resources from TI, omap hwmod data base during device registration.
Future plan is to migrate hwmod data base contents into device tree
blob so that, all the required data will be used from device tree dts
file.
Example:
Step1: SoC common .dtsi file
dcan1: d_can@481d0000 {
compatible = "bosch,d_can";
reg = <0x481d0000 0x2000>;
interrupts = <55>;
interrupt-parent = <&intc>;
status = "disabled";
};
(or)
dcan1: d_can@481d0000 {
compatible = "bosch,d_can";
ti,hwmods = "d_can1";
reg = <0x481d0000 0x2000>;
interrupts = <55>;
interrupt-parent = <&intc>;
status = "disabled";
};
Step 2: board specific .dts file
&dcan1 {
status = "okay";
};

9
Documentation/devicetree/bindings/net/can/can-controller.yaml
View File

@@ -13,6 +13,15 @@ properties:
$nodename:
pattern: "^can(@.*)?$"
termination-gpios:
description: GPIO pin to enable CAN bus termination.
maxItems: 1
termination-ohms:
description: The resistance value of the CAN bus termination resistor.
minimum: 1
maximum: 65535
additionalProperties: true
...

17
Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml
View File

@@ -119,6 +119,9 @@ properties:
minimum: 0
maximum: 2
termination-gpios: true
termination-ohms: true
required:
- compatible
- reg
@@ -148,3 +151,17 @@ examples:
fsl,stop-mode = <&gpr 0x34 28>;
fsl,scu-index = /bits/ 8 <1>;
};
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
can@2090000 {
compatible = "fsl,imx6q-flexcan";
reg = <0x02090000 0x4000>;
interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 1>, <&clks 2>;
clock-names = "ipg", "per";
fsl,stop-mode = <&gpr 0x34 28>;
termination-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
termination-ohms = <120>;
};

69
Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
View File

@@ -30,13 +30,15 @@ properties:
- renesas,r8a77995-canfd # R-Car D3
- const: renesas,rcar-gen3-canfd # R-Car Gen3 and RZ/G2
- items:
- enum:
- renesas,r9a07g044-canfd # RZ/G2{L,LC}
- const: renesas,rzg2l-canfd # RZ/G2L family
reg:
maxItems: 1
interrupts:
items:
- description: Channel interrupt
- description: Global interrupt
interrupts: true
clocks:
maxItems: 3
@@ -50,8 +52,7 @@ properties:
power-domains:
maxItems: 1
resets:
maxItems: 1
resets: true
renesas,no-can-fd:
$ref: /schemas/types.yaml#/definitions/flag
@@ -91,6 +92,62 @@ required:
- channel0
- channel1
if:
properties:
compatible:
contains:
enum:
- renesas,rzg2l-canfd
then:
properties:
interrupts:
items:
- description: CAN global error interrupt
- description: CAN receive FIFO interrupt
- description: CAN0 error interrupt
- description: CAN0 transmit interrupt
- description: CAN0 transmit/receive FIFO receive completion interrupt
- description: CAN1 error interrupt
- description: CAN1 transmit interrupt
- description: CAN1 transmit/receive FIFO receive completion interrupt
interrupt-names:
items:
- const: g_err
- const: g_recc
- const: ch0_err
- const: ch0_rec
- const: ch0_trx
- const: ch1_err
- const: ch1_rec
- const: ch1_trx
resets:
maxItems: 2
reset-names:
items:
- const: rstp_n
- const: rstc_n
required:
- interrupt-names
- reset-names
else:
properties:
interrupts:
items:
- description: Channel interrupt
- description: Global interrupt
interrupt-names:
items:
- const: ch_int
- const: g_int
resets:
maxItems: 1
unevaluatedProperties: false
examples:

244
Documentation/devicetree/bindings/net/fsl,fec.yaml Normal file
View File

@@ -0,0 +1,244 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/fsl,fec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Freescale Fast Ethernet Controller (FEC)
maintainers:
- Joakim Zhang <qiangqing.zhang@nxp.com>
allOf:
- $ref: ethernet-controller.yaml#
properties:
compatible:
oneOf:
- enum:
- fsl,imx25-fec
- fsl,imx27-fec
- fsl,imx28-fec
- fsl,imx6q-fec
- fsl,mvf600-fec
- items:
- enum:
- fsl,imx53-fec
- fsl,imx6sl-fec
- const: fsl,imx25-fec
- items:
- enum:
- fsl,imx35-fec
- fsl,imx51-fec
- const: fsl,imx27-fec
- items:
- enum:
- fsl,imx6ul-fec
- fsl,imx6sx-fec
- const: fsl,imx6q-fec
- items:
- enum:
- fsl,imx7d-fec
- const: fsl,imx6sx-fec
- items:
- const: fsl,imx8mq-fec
- const: fsl,imx6sx-fec
- items:
- enum:
- fsl,imx8mm-fec
- fsl,imx8mn-fec
- fsl,imx8mp-fec
- const: fsl,imx8mq-fec
- const: fsl,imx6sx-fec
- items:
- const: fsl,imx8qm-fec
- const: fsl,imx6sx-fec
- items:
- enum:
- fsl,imx8qxp-fec
- const: fsl,imx8qm-fec
- const: fsl,imx6sx-fec
reg:
maxItems: 1
interrupts:
minItems: 1
maxItems: 4
interrupt-names:
oneOf:
- items:
- const: int0
- items:
- const: int0
- const: pps
- items:
- const: int0
- const: int1
- const: int2
- items:
- const: int0
- const: int1
- const: int2
- const: pps
clocks:
minItems: 2
maxItems: 5
description:
The "ipg", for MAC ipg_clk_s, ipg_clk_mac_s that are for register accessing.
The "ahb", for MAC ipg_clk, ipg_clk_mac that are bus clock.
The "ptp"(option), for IEEE1588 timer clock that requires the clock.
The "enet_clk_ref"(option), for MAC transmit/receiver reference clock like
RGMII TXC clock or RMII reference clock. It depends on board design,
the clock is required if RGMII TXC and RMII reference clock source from
SOC internal PLL.
The "enet_out"(option), output clock for external device, like supply clock
for PHY. The clock is required if PHY clock source from SOC.
The "enet_2x_txclk"(option), for RGMII sampling clock which fixed at 250Mhz.
The clock is required if SoC RGMII enable clock delay.
clock-names:
minItems: 2
maxItems: 5
items:
enum:
- ipg
- ahb
- ptp
- enet_clk_ref
- enet_out
- enet_2x_txclk
phy-mode: true
phy-handle: true
fixed-link: true
local-mac-address: true
mac-address: true
tx-internal-delay-ps:
enum: [0, 2000]
rx-internal-delay-ps:
enum: [0, 2000]
phy-supply:
description:
Regulator that powers the Ethernet PHY.
fsl,num-tx-queues:
$ref: /schemas/types.yaml#/definitions/uint32
description:
The property is valid for enet-avb IP, which supports hw multi queues.
Should specify the tx queue number, otherwise set tx queue number to 1.
enum: [1, 2, 3]
fsl,num-rx-queues:
$ref: /schemas/types.yaml#/definitions/uint32
description:
The property is valid for enet-avb IP, which supports hw multi queues.
Should specify the rx queue number, otherwise set rx queue number to 1.
enum: [1, 2, 3]
fsl,magic-packet:
$ref: /schemas/types.yaml#/definitions/flag
description:
If present, indicates that the hardware supports waking up via magic packet.
fsl,err006687-workaround-present:
$ref: /schemas/types.yaml#/definitions/flag
description:
If present indicates that the system has the hardware workaround for
ERR006687 applied and does not need a software workaround.
fsl,stop-mode:
$ref: /schemas/types.yaml#/definitions/phandle-array
description:
Register bits of stop mode control, the format is <&gpr req_gpr req_bit>.
gpr is the phandle to general purpose register node.
req_gpr is the gpr register offset for ENET stop request.
req_bit is the gpr bit offset for ENET stop request.
mdio:
type: object
description:
Specifies the mdio bus in the FEC, used as a container for phy nodes.
# Deprecated optional properties:
# To avoid these, create a phy node according to ethernet-phy.yaml in the same
# directory, and point the FEC's "phy-handle" property to it. Then use
# the phy's reset binding, again described by ethernet-phy.yaml.
phy-reset-gpios:
deprecated: true
description:
Should specify the gpio for phy reset.
phy-reset-duration:
deprecated: true
description:
Reset duration in milliseconds. Should present only if property
"phy-reset-gpios" is available. Missing the property will have the
duration be 1 millisecond. Numbers greater than 1000 are invalid
and 1 millisecond will be used instead.
phy-reset-active-high:
deprecated: true
description:
If present then the reset sequence using the GPIO specified in the
"phy-reset-gpios" property is reversed (H=reset state, L=operation state).
phy-reset-post-delay:
deprecated: true
description:
Post reset delay in milliseconds. If present then a delay of phy-reset-post-delay
milliseconds will be observed after the phy-reset-gpios has been toggled.
Can be omitted thus no delay is observed. Delay is in range of 1ms to 1000ms.
Other delays are invalid.
required:
- compatible
- reg
- interrupts
# FIXME: We had better set additionalProperties to false to avoid invalid or at
# least undocumented properties. However, PHY may have a deprecated option to
# place PHY OF properties in the MAC node, such as Micrel PHY, and we can find
# these boards which is based on i.MX6QDL.
additionalProperties: false
examples:
- |
ethernet@83fec000 {
compatible = "fsl,imx51-fec", "fsl,imx27-fec";
reg = <0x83fec000 0x4000>;
interrupts = <87>;
phy-mode = "mii";
phy-reset-gpios = <&gpio2 14 0>;
phy-supply = <&reg_fec_supply>;
};
ethernet@83fed000 {
compatible = "fsl,imx51-fec", "fsl,imx27-fec";
reg = <0x83fed000 0x4000>;
interrupts = <87>;
phy-mode = "mii";
phy-reset-gpios = <&gpio2 14 0>;
phy-supply = <&reg_fec_supply>;
phy-handle = <&ethphy0>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
};
};
};

95
Documentation/devicetree/bindings/net/fsl-fec.txt
View File

@@ -1,95 +0,0 @@
* Freescale Fast Ethernet Controller (FEC)
Required properties:
- compatible : Should be "fsl,<soc>-fec"
- reg : Address and length of the register set for the device
- interrupts : Should contain fec interrupt
- phy-mode : See ethernet.txt file in the same directory
Optional properties:
- phy-supply : regulator that powers the Ethernet PHY.
- phy-handle : phandle to the PHY device connected to this device.
- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory.
Use instead of phy-handle.
- fsl,num-tx-queues : The property is valid for enet-avb IP, which supports
hw multi queues. Should specify the tx queue number, otherwise set tx queue
number to 1.
- fsl,num-rx-queues : The property is valid for enet-avb IP, which supports
hw multi queues. Should specify the rx queue number, otherwise set rx queue
number to 1.
- fsl,magic-packet : If present, indicates that the hardware supports waking
up via magic packet.
- fsl,err006687-workaround-present: If present indicates that the system has
the hardware workaround for ERR006687 applied and does not need a software
workaround.
- fsl,stop-mode: register bits of stop mode control, the format is
<&gpr req_gpr req_bit>.
gpr is the phandle to general purpose register node.
req_gpr is the gpr register offset for ENET stop request.
req_bit is the gpr bit offset for ENET stop request.
-interrupt-names: names of the interrupts listed in interrupts property in
the same order. The defaults if not specified are
__Number of interrupts__ __Default__
1 "int0"
2 "int0", "pps"
3 "int0", "int1", "int2"
4 "int0", "int1", "int2", "pps"
The order may be changed as long as they correspond to the interrupts
property. Currently, only i.mx7 uses "int1" and "int2". They correspond to
tx/rx queues 1 and 2. "int0" will be used for queue 0 and ENET_MII interrupts.
For imx6sx, "int0" handles all 3 queues and ENET_MII. "pps" is for the pulse
per second interrupt associated with 1588 precision time protocol(PTP).
Optional subnodes:
- mdio : specifies the mdio bus in the FEC, used as a container for phy nodes
according to phy.txt in the same directory
Deprecated optional properties:
To avoid these, create a phy node according to phy.txt in the same
directory, and point the fec's "phy-handle" property to it. Then use
the phy's reset binding, again described by phy.txt.
- phy-reset-gpios : Should specify the gpio for phy reset
- phy-reset-duration : Reset duration in milliseconds. Should present
only if property "phy-reset-gpios" is available. Missing the property
will have the duration be 1 millisecond. Numbers greater than 1000 are
invalid and 1 millisecond will be used instead.
- phy-reset-active-high : If present then the reset sequence using the GPIO
specified in the "phy-reset-gpios" property is reversed (H=reset state,
L=operation state).
- phy-reset-post-delay : Post reset delay in milliseconds. If present then
a delay of phy-reset-post-delay milliseconds will be observed after the
phy-reset-gpios has been toggled. Can be omitted thus no delay is
observed. Delay is in range of 1ms to 1000ms. Other delays are invalid.
Example:
ethernet@83fec000 {
compatible = "fsl,imx51-fec", "fsl,imx27-fec";
reg = <0x83fec000 0x4000>;
interrupts = <87>;
phy-mode = "mii";
phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */
local-mac-address = [00 04 9F 01 1B B9];
phy-supply = <&reg_fec_supply>;
};
Example with phy specified:
ethernet@83fec000 {
compatible = "fsl,imx51-fec", "fsl,imx27-fec";
reg = <0x83fec000 0x4000>;
interrupts = <87>;
phy-mode = "mii";
phy-reset-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>; /* GPIO2_14 */
local-mac-address = [00 04 9F 01 1B B9];
phy-supply = <&reg_fec_supply>;
phy-handle = <&ethphy>;
mdio {
clock-frequency = <5000000>;
ethphy: ethernet-phy@6 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <6>;
max-speed = <100>;
};
};
};

54
Documentation/devicetree/bindings/net/intel,ixp46x-ptp-timer.yaml Normal file
View File

@@ -0,0 +1,54 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2018 Linaro Ltd.
%YAML 1.2
---
$id: "http://devicetree.org/schemas/net/intel,ixp46x-ptp-timer.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Intel IXP46x PTP Timer (TSYNC)
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
The Intel IXP46x PTP timer is known in the manual as IEEE1588 Hardware
Assist and Time Synchronization Hardware Assist TSYNC provides a PTP
timer. It exists in the Intel IXP45x and IXP46x XScale SoCs.
properties:
compatible:
const: intel,ixp46x-ptp-timer
reg:
maxItems: 1
interrupts:
items:
- description: Interrupt to trigger master mode snapshot from the
PRP timer, usually a GPIO interrupt.
- description: Interrupt to trigger slave mode snapshot from the
PRP timer, usually a GPIO interrupt.
interrupt-names:
items:
- const: master
- const: slave
required:
- compatible
- reg
- interrupts
- interrupt-names
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
ptp-timer@c8010000 {
compatible = "intel,ixp46x-ptp-timer";
reg = <0xc8010000 0x1000>;
interrupt-parent = <&gpio0>;
interrupts = <8 IRQ_TYPE_EDGE_FALLING>, <7 IRQ_TYPE_EDGE_FALLING>;
interrupt-names = "master", "slave";
};

98
Documentation/devicetree/bindings/net/litex,liteeth.yaml Normal file
View File

@@ -0,0 +1,98 @@
# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/litex,liteeth.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LiteX LiteETH ethernet device
maintainers:
- Joel Stanley <joel@jms.id.au>
description: |
LiteETH is a small footprint and configurable Ethernet core for FPGA based
system on chips.
The hardware source is Open Source and can be found on at
https://github.com/enjoy-digital/liteeth/.
allOf:
- $ref: ethernet-controller.yaml#
properties:
compatible:
const: litex,liteeth
reg:
items:
- description: MAC registers
- description: MDIO registers
- description: Packet buffer
reg-names:
items:
- const: mac
- const: mdio
- const: buffer
interrupts:
maxItems: 1
litex,rx-slots:
description: Number of slots in the receive buffer
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
default: 2
litex,tx-slots:
description: Number of slots in the transmit buffer
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
default: 2
litex,slot-size:
description: Size in bytes of a slot in the tx/rx buffer
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0x800
default: 0x800
mac-address: true
local-mac-address: true
phy-handle: true
mdio:
$ref: mdio.yaml#
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
mac: ethernet@8020000 {
compatible = "litex,liteeth";
reg = <0x8021000 0x100>,
<0x8020800 0x100>,
<0x8030000 0x2000>;
reg-names = "mac", "mdio", "buffer";
litex,rx-slots = <2>;
litex,tx-slots = <2>;
litex,slot-size = <0x800>;
interrupts = <0x11 0x1>;
phy-handle = <&eth_phy>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
eth_phy: ethernet-phy@0 {
reg = <0>;
};
};
};
...
# vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml :

1
Documentation/devicetree/bindings/net/macb.txt
View File

@@ -8,6 +8,7 @@ Required properties:
Use "cdns,np4-macb" for NP4 SoC devices.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2 SoCs.
Use "atmel,sama5d29-gem" for GEM XL IP (10/100) available on Atmel sama5d29 SoCs.
Use "atmel,sama5d3-macb" for the 10/100Mbit IP available on Atmel sama5d3 SoCs.
Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs.
Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs.

24
Documentation/devicetree/bindings/net/qcom,ipa.yaml
View File

@@ -87,16 +87,24 @@ properties:
- const: ipa-setup-ready
interconnects:
items:
- description: Interconnect path between IPA and main memory
- description: Interconnect path between IPA and internal memory
- description: Interconnect path between IPA and the AP subsystem
oneOf:
- items:
- description: Path leading to system memory
- description: Path between the AP and IPA config space
- items:
- description: Path leading to system memory
- description: Path leading to internal memory
- description: Path between the AP and IPA config space
interconnect-names:
items:
- const: memory
- const: imem
- const: config
oneOf:
- items:
- const: memory
- const: config
- items:
- const: memory
- const: imem
- const: config
qcom,smem-states:
$ref: /schemas/types.yaml#/definitions/phandle-array

15
Documentation/devicetree/bindings/net/qcom,ipq4019-mdio.yaml
View File

@@ -14,7 +14,9 @@ allOf:
properties:
compatible:
const: qcom,ipq4019-mdio
enum:
- qcom,ipq4019-mdio
- qcom,ipq5018-mdio
"#address-cells":
const: 1
@@ -23,7 +25,18 @@ properties:
const: 0
reg:
minItems: 1
maxItems: 2
description:
the first Address and length of the register set for the MDIO controller.
the second Address and length of the register for ethernet LDO, this second
address range is only required by the platform IPQ50xx.
clocks:
maxItems: 1
description: |
MDIO clock source frequency fixed to 100MHZ, this clock should be specified
by the platform IPQ807x, IPQ60xx and IPQ50xx.
required:
- compatible

2
Documentation/driver-api/nfc/nfc-hci.rst
View File

@@ -181,7 +181,7 @@ xmit_from_hci():
The llc must be registered with nfc before it can be used. Do that by
calling::
nfc_llc_register(const char *name, struct nfc_llc_ops *ops);
nfc_llc_register(const char *name, const struct nfc_llc_ops *ops);
Again, note that the llc does not handle the physical link. It is thus very
easy to mix any physical link with any llc for a given chip driver.

1026
Documentation/filesystems/idmappings.rst Normal file
View File

File diff suppressed because it is too large Load Diff

1
Documentation/filesystems/index.rst
View File

@@ -34,6 +34,7 @@ algorithms work.
quota
seq_file
sharedsubtree
idmappings
automount-support

61
Documentation/hwmon/aquacomputer_d5next.rst Normal file
View File

@@ -0,0 +1,61 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Kernel driver aquacomputer-d5next
=================================
Supported devices:
* Aquacomputer D5 Next watercooling pump
Author: Aleksa Savic
Description
-----------
This driver exposes hardware sensors of the Aquacomputer D5 Next watercooling
pump, which communicates through a proprietary USB HID protocol.
Available sensors are pump and fan speed, power, voltage and current, as
well as coolant temperature. Also available through debugfs are the serial
number, firmware version and power-on count.
Attaching a fan is optional and allows it to be controlled using temperature
curves directly from the pump. If it's not connected, the fan-related sensors
will report zeroes.
The pump can be configured either through software or via its physical
interface. Configuring the pump through this driver is not implemented, as it
seems to require sending it a complete configuration. That includes addressable
RGB LEDs, for which there is no standard sysfs interface. Thus, that task is
better suited for userspace tools.
Usage notes
-----------
The pump communicates via HID reports. The driver is loaded automatically by
the kernel and supports hotswapping.
Sysfs entries
-------------
============ =============================================
temp1_input Coolant temperature (in millidegrees Celsius)
fan1_input Pump speed (in RPM)
fan2_input Fan speed (in RPM)
power1_input Pump power (in micro Watts)
power2_input Fan power (in micro Watts)
in0_input Pump voltage (in milli Volts)
in1_input Fan voltage (in milli Volts)
in2_input +5V rail voltage (in milli Volts)
curr1_input Pump current (in milli Amperes)
curr2_input Fan current (in milli Amperes)
============ =============================================
Debugfs entries
---------------
================ ===============================================
serial_number Serial number of the pump
firmware_version Version of installed firmware
power_cycles Count of how many times the pump was powered on
================ ===============================================

2
Documentation/hwmon/index.rst
View File

@@ -39,6 +39,7 @@ Hardware Monitoring Kernel Drivers
adt7475
aht10
amc6821
aquacomputer_d5next
asb100
asc7621
aspeed-pwm-tacho
@@ -160,6 +161,7 @@ Hardware Monitoring Kernel Drivers
pwm-fan
q54sj108a2
raspberrypi-hwmon
sbrmi
sbtsi_temp
sch5627
sch5636

79
Documentation/hwmon/sbrmi.rst Normal file
View File

@@ -0,0 +1,79 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Kernel driver sbrmi
===================
Supported hardware:
* Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
device connected to the BMC via the APML.
Prefix: 'sbrmi'
Addresses scanned: This driver doesn't support address scanning.
To instantiate this driver on an AMD CPU with SB-RMI
support, the i2c bus number would be the bus connected from the board
management controller (BMC) to the CPU.
The SMBus address is really 7 bits. Some vendors and the SMBus
specification show the address as 8 bits, left justified with the R/W
bit as a write (0) making bit 0. Some vendors use only the 7 bits
to describe the address.
As mentioned in AMD's APML specification, The SB-RMI address is
normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
or 38h(011 1000) for socket 1, but it could vary based on hardware
address select pins.
Datasheet: The SB-RMI interface and protocol along with the Advanced
Platform Management Link (APML) Specification is available
as part of the open source SoC register reference at:
https://www.amd.com/en/support/tech-docs?keyword=55898
Author: Akshay Gupta <akshay.gupta@amd.com>
Description
-----------
The APML provides a way to communicate with the SB Remote Management interface
(SB-RMI) module from the external SMBus master that can be used to report socket
power on AMD platforms using mailbox command and resembles a typical 8-pin remote
power sensor's I2C interface to BMC.
This driver implements current power with power cap and power cap max.
sysfs-Interface
---------------
Power sensors can be queried and set via the standard ``hwmon`` interface
on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
content ``sbrmi``)
================ ===== ========================================================
Name Perm Description
================ ===== ========================================================
power1_input RO Current Power consumed
power1_cap RW Power limit can be set between 0 and power1_cap_max
power1_cap_max RO Maximum powerlimit calculated and reported by the SMU FW
================ ===== ========================================================
The following example show how the 'Power' attribute from the i2c-addresses
can be monitored using the userspace utilities like ``sensors`` binary::
# sensors
sbrmi-i2c-1-38
Adapter: bcm2835 I2C adapter
power1: 61.00 W (cap = 225.00 W)
sbrmi-i2c-1-3c
Adapter: bcm2835 I2C adapter
power1: 28.39 W (cap = 224.77 W)
#
Also, Below shows how get and set the values from sysfs entries individually::
# cat /sys/class/hwmon/hwmon1/power1_cap_max
225000000
# echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
# cat /sys/class/hwmon/hwmon1/power1_cap
180000000

2
Documentation/hwmon/scpi-hwmon.rst
View File

@@ -32,5 +32,5 @@ Usage Notes
The driver relies on device tree node to indicate the presence of SCPI
support in the kernel. See
Documentation/devicetree/bindings/arm/arm,scpi.txt for details of the
Documentation/devicetree/bindings/firmware/arm,scpi.yaml for details of the
devicetree node.

2
Documentation/hwmon/sht4x.rst
View File

@@ -42,4 +42,4 @@ humidity1_input Measured humidity in %H
update_interval The minimum interval for polling the sensor,
in milliseconds. Writable. Must be at least
2000.
============== =============================================
=============== ============================================

58
Documentation/leds/well-known-leds.txt Normal file
View File

@@ -0,0 +1,58 @@
-*- org -*-
It is somehow important to provide consistent interface to the
userland. LED devices have one problem there, and that is naming of
directories in /sys/class/leds. It would be nice if userland would
just know right "name" for given LED function, but situation got more
complex.
Anyway, if backwards compatibility is not an issue, new code should
use one of the "good" names from this list, and you should extend the
list where applicable.
Legacy names are listed, too; in case you are writing application that
wants to use particular feature, you should probe for good name, first,
but then try the legacy ones, too.
Notice there's a list of functions in include/dt-bindings/leds/common.h .
* Keyboards
Good: "input*:*:capslock"
Good: "input*:*:scrolllock"
Good: "input*:*:numlock"
Legacy: "shift-key-light" (Motorola Droid 4, capslock)
Set of common keyboard LEDs, going back to PC AT or so.
Legacy: "tpacpi::thinklight" (IBM/Lenovo Thinkpads)
Legacy: "lp5523:kb{1,2,3,4,5,6}" (Nokia N900)
Frontlight/backlight of main keyboard.
Legacy: "button-backlight" (Motorola Droid 4)
Some phones have touch buttons below screen; it is different from main
keyboard. And this is their backlight.
* Sound subsystem
Good: "platform:*:mute"
Good: "platform:*:micmute"
LEDs on notebook body, indicating that sound input / output is muted.
* System notification
Legacy: "status-led:{red,green,blue}" (Motorola Droid 4)
Legacy: "lp5523:{r,g,b}" (Nokia N900)
Phones usually have multi-color status LED.
* Power management
Good: "platform:*:charging" (allwinner sun50i)
* Screen
Good: ":backlight" (Motorola Droid 4)

2
Documentation/networking/batman-adv.rst
View File

@@ -157,7 +157,7 @@ Contact
Please send us comments, experiences, questions, anything :)
IRC:
#batman on irc.freenode.org
#batadv on ircs://irc.hackint.org/
Mailing-list:
b.a.t.m.a.n@open-mesh.org (optional subscription at
https://lists.open-mesh.org/mailman3/postorius/lists/b.a.t.m.a.n.lists.open-mesh.org/)

12
Documentation/networking/bonding.rst
View File

@@ -501,6 +501,18 @@ fail_over_mac
This option was added in bonding version 3.2.0. The "follow"
policy was added in bonding version 3.3.0.
lacp_active
Option specifying whether to send LACPDU frames periodically.
off or 0
LACPDU frames acts as "speak when spoken to".
on or 1
LACPDU frames are sent along the configured links
periodically. See lacp_rate for more details.
The default is on.
lacp_rate
Option specifying the rate in which we'll ask our link partner

1
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst
View File

@@ -9,3 +9,4 @@ DPAA2 Documentation
dpio-driver
ethernet-driver
mac-phy-support
switch-driver

217
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst Normal file
View File

@@ -0,0 +1,217 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===================
DPAA2 Switch driver
===================
:Copyright: |copy| 2021 NXP
The DPAA2 Switch driver probes on the Datapath Switch (DPSW) object which can
be instantiated on the following DPAA2 SoCs and their variants: LS2088A and
LX2160A.
The driver uses the switch device driver model and exposes each switch port as
a network interface, which can be included in a bridge or used as a standalone
interface. Traffic switched between ports is offloaded into the hardware.
The DPSW can have ports connected to DPNIs or to DPMACs for external access.
::
[ethA] [ethB] [ethC] [ethD] [ethE] [ethF]
: : : : : :
: : : : : :
[dpaa2-eth] [dpaa2-eth] [ dpaa2-switch ]
: : : : : : kernel
=============================================================================
: : : : : : hardware
[DPNI] [DPNI] [============= DPSW =================]
| | | | | |
| ---------- | [DPMAC] [DPMAC]
------------------------------- | |
| |
[PHY] [PHY]
Creating an Ethernet Switch
===========================
The dpaa2-switch driver probes on DPSW devices found on the fsl-mc bus. These
devices can be either created statically through the boot time configuration
file - DataPath Layout (DPL) - or at runtime using the DPAA2 object APIs
(incorporated already into the restool userspace tool).
At the moment, the dpaa2-switch driver imposes the following restrictions on
the DPSW object that it will probe:
* The minimum number of FDBs should be at least equal to the number of switch
interfaces. This is necessary so that separation of switch ports can be
done, ie when not under a bridge, each switch port will have its own FDB.
::
fsl_dpaa2_switch dpsw.0: The number of FDBs is lower than the number of ports, cannot probe
* Both the broadcast and flooding configuration should be per FDB. This
enables the driver to restrict the broadcast and flooding domains of each
FDB depending on the switch ports that are sharing it (aka are under the
same bridge).
::
fsl_dpaa2_switch dpsw.0: Flooding domain is not per FDB, cannot probe
fsl_dpaa2_switch dpsw.0: Broadcast domain is not per FDB, cannot probe
* The control interface of the switch should not be disabled
(DPSW_OPT_CTRL_IF_DIS not passed as a create time option). Without the
control interface, the driver is not capable to provide proper Rx/Tx traffic
support on the switch port netdevices.
::
fsl_dpaa2_switch dpsw.0: Control Interface is disabled, cannot probe
Besides the configuration of the actual DPSW object, the dpaa2-switch driver
will need the following DPAA2 objects:
* 1 DPMCP - A Management Command Portal object is needed for any interraction
with the MC firmware.
* 1 DPBP - A Buffer Pool is used for seeding buffers intended for the Rx path
on the control interface.
* Access to at least one DPIO object (Software Portal) is needed for any
enqueue/dequeue operation to be performed on the control interface queues.
The DPIO object will be shared, no need for a private one.
Switching features
==================
The driver supports the configuration of L2 forwarding rules in hardware for
port bridging as well as standalone usage of the independent switch interfaces.
The hardware is not configurable with respect to VLAN awareness, thus any DPAA2
switch port should be used only in usecases with a VLAN aware bridge::
$ ip link add dev br0 type bridge vlan_filtering 1
$ ip link add dev br1 type bridge
$ ip link set dev ethX master br1
Error: fsl_dpaa2_switch: Cannot join a VLAN-unaware bridge
Topology and loop detection through STP is supported when ``stp_state 1`` is
used at bridge create ::
$ ip link add dev br0 type bridge vlan_filtering 1 stp_state 1
L2 FDB manipulation (add/delete/dump) is supported.
HW FDB learning can be configured on each switch port independently through
bridge commands. When the HW learning is disabled, a fast age procedure will be
run and any previously learnt addresses will be removed.
::
$ bridge link set dev ethX learning off
$ bridge link set dev ethX learning on
Restricting the unknown unicast and multicast flooding domain is supported, but
not independently of each other::
$ ip link set dev ethX type bridge_slave flood off mcast_flood off
$ ip link set dev ethX type bridge_slave flood off mcast_flood on
Error: fsl_dpaa2_switch: Cannot configure multicast flooding independently of unicast.
Broadcast flooding on a switch port can be disabled/enabled through the brport sysfs::
$ echo 0 > /sys/bus/fsl-mc/devices/dpsw.Y/net/ethX/brport/broadcast_flood
Offloads
========
Routing actions (redirect, trap, drop)
--------------------------------------
The DPAA2 switch is able to offload flow-based redirection of packets making
use of ACL tables. Shared filter blocks are supported by sharing a single ACL
table between multiple ports.
The following flow keys are supported:
* Ethernet: dst_mac/src_mac
* IPv4: dst_ip/src_ip/ip_proto/tos
* VLAN: vlan_id/vlan_prio/vlan_tpid/vlan_dei
* L4: dst_port/src_port
Also, the matchall filter can be used to redirect the entire traffic received
on a port.
As per flow actions, the following are supported:
* drop
* mirred egress redirect
* trap
Each ACL entry (filter) can be setup with only one of the listed
actions.
Example 1: send frames received on eth4 with a SA of 00:01:02:03:04:05 to the
CPU::
$ tc qdisc add dev eth4 clsact
$ tc filter add dev eth4 ingress flower src_mac 00:01:02:03:04:05 skip_sw action trap
Example 2: drop frames received on eth4 with VID 100 and PCP of 3::
$ tc filter add dev eth4 ingress protocol 802.1q flower skip_sw vlan_id 100 vlan_prio 3 action drop
Example 3: redirect all frames received on eth4 to eth1::
$ tc filter add dev eth4 ingress matchall action mirred egress redirect dev eth1
Example 4: Use a single shared filter block on both eth5 and eth6::
$ tc qdisc add dev eth5 ingress_block 1 clsact
$ tc qdisc add dev eth6 ingress_block 1 clsact
$ tc filter add block 1 ingress flower dst_mac 00:01:02:03:04:04 skip_sw \
action trap
$ tc filter add block 1 ingress protocol ipv4 flower src_ip 192.168.1.1 skip_sw \
action mirred egress redirect dev eth3
Mirroring
~~~~~~~~~
The DPAA2 switch supports only per port mirroring and per VLAN mirroring.
Adding mirroring filters in shared blocks is also supported.
When using the tc-flower classifier with the 802.1q protocol, only the
''vlan_id'' key will be accepted. Mirroring based on any other fields from the
802.1q protocol will be rejected::
$ tc qdisc add dev eth8 ingress_block 1 clsact
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_prio 3 action mirred egress mirror dev eth6
Error: fsl_dpaa2_switch: Only matching on VLAN ID supported.
We have an error talking to the kernel
If a mirroring VLAN filter is requested on a port, the VLAN must to be
installed on the switch port in question either using ''bridge'' or by creating
a VLAN upper device if the switch port is used as a standalone interface::
$ tc qdisc add dev eth8 ingress_block 1 clsact
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
Error: VLAN must be installed on the switch port.
We have an error talking to the kernel
$ bridge vlan add vid 200 dev eth8
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
$ ip link add link eth8 name eth8.200 type vlan id 200
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
Also, it should be noted that the mirrored traffic will be subject to the same
egress restrictions as any other traffic. This means that when a mirrored
packet will reach the mirror port, if the VLAN found in the packet is not
installed on the port it will get dropped.
The DPAA2 switch supports only a single mirroring destination, thus multiple
mirror rules can be installed but their ''to'' port has to be the same::
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6
$ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 100 action mirred egress mirror dev eth7
Error: fsl_dpaa2_switch: Multiple mirror ports not supported.
We have an error talking to the kernel

44
Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst
View File

@@ -656,3 +656,47 @@ Bridge offloads tracepoints:
$ cat /sys/kernel/debug/tracing/trace
...
ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1
Eswitch QoS tracepoints:
- mlx5_esw_vport_qos_create: trace creation of transmit scheduler arbiter for vport::
$ echo mlx5:mlx5_esw_vport_qos_create >> /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace
...
<...>-23496 [018] .... 73136.838831: mlx5_esw_vport_qos_create: (0000:82:00.0) vport=2 tsar_ix=4 bw_share=0, max_rate=0 group=000000007b576bb3
- mlx5_esw_vport_qos_config: trace configuration of transmit scheduler arbiter for vport::
$ echo mlx5:mlx5_esw_vport_qos_config >> /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace
...
<...>-26548 [023] .... 75754.223823: mlx5_esw_vport_qos_config: (0000:82:00.0) vport=1 tsar_ix=3 bw_share=34, max_rate=10000 group=000000007b576bb3
- mlx5_esw_vport_qos_destroy: trace deletion of transmit scheduler arbiter for vport::
$ echo mlx5:mlx5_esw_vport_qos_destroy >> /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace
...
<...>-27418 [004] .... 76546.680901: mlx5_esw_vport_qos_destroy: (0000:82:00.0) vport=1 tsar_ix=3
- mlx5_esw_group_qos_create: trace creation of transmit scheduler arbiter for rate group::
$ echo mlx5:mlx5_esw_group_qos_create >> /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace
...
<...>-26578 [008] .... 75776.022112: mlx5_esw_group_qos_create: (0000:82:00.0) group=000000008dac63ea tsar_ix=5
- mlx5_esw_group_qos_config: trace configuration of transmit scheduler arbiter for rate group::
$ echo mlx5:mlx5_esw_group_qos_config >> /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace
...
<...>-27303 [020] .... 76461.455356: mlx5_esw_group_qos_config: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 bw_share=100 max_rate=20000
- mlx5_esw_group_qos_destroy: trace deletion of transmit scheduler arbiter for group::
$ echo mlx5:mlx5_esw_group_qos_destroy >> /sys/kernel/debug/tracing/set_event
$ cat /sys/kernel/debug/tracing/trace
...
<...>-27418 [006] .... 76547.187258: mlx5_esw_group_qos_destroy: (0000:82:00.0) group=000000007b576bb3 tsar_ix=1

12
Documentation/networking/devlink/devlink-params.rst
View File

@@ -97,6 +97,18 @@ own name.
* - ``enable_roce``
- Boolean
- Enable handling of RoCE traffic in the device.
* - ``enable_eth``
- Boolean
- When enabled, the device driver will instantiate Ethernet specific
auxiliary device of the devlink device.
* - ``enable_rdma``
- Boolean
- When enabled, the device driver will instantiate RDMA specific
auxiliary device of the devlink device.
* - ``enable_vnet``
- Boolean
- When enabled, the device driver will instantiate VDPA networking
specific auxiliary device of the devlink device.
* - ``internal_err_reset``
- Boolean
- When enabled, the device driver will reset the device on internal

25
Documentation/networking/devlink/hns3.rst Normal file
View File

@@ -0,0 +1,25 @@
.. SPDX-License-Identifier: GPL-2.0
====================
hns3 devlink support
====================
This document describes the devlink features implemented by the ``hns3``
device driver.
The ``hns3`` driver supports reloading via ``DEVLINK_CMD_RELOAD``.
Info versions
=============
The ``hns3`` driver reports the following versions
.. list-table:: devlink info versions implemented
:widths: 10 10 80
* - Name
- Type
- Description
* - ``fw``
- running
- Used to represent the firmware version.

2
Documentation/networking/devlink/index.rst
View File

@@ -34,6 +34,7 @@ parameters, info versions, and other features it supports.
:maxdepth: 1
bnxt
hns3
ionic
ice
mlx4
@@ -42,7 +43,6 @@ parameters, info versions, and other features it supports.
mv88e6xxx
netdevsim
nfp
sja1105
qed
ti-cpsw-switch
am65-nuss-cpsw-switch

49
Documentation/networking/devlink/sja1105.rst
View File

@@ -1,49 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
=======================
sja1105 devlink support
=======================
This document describes the devlink features implemented
by the ``sja1105`` device driver.
Parameters
==========
.. list-table:: Driver-specific parameters implemented
:widths: 5 5 5 85
* - Name
- Type
- Mode
- Description
* - ``best_effort_vlan_filtering``
- Boolean
- runtime
- Allow plain ETH_P_8021Q headers to be used as DSA tags.
Benefits:
- Can terminate untagged traffic over switch net
devices even when enslaved to a bridge with
vlan_filtering=1.
- Can terminate VLAN-tagged traffic over switch net
devices even when enslaved to a bridge with
vlan_filtering=1, with some constraints (no more than
7 non-pvid VLANs per user port).
- Can do QoS based on VLAN PCP and VLAN membership
admission control for autonomously forwarded frames
(regardless of whether they can be terminated on the
CPU or not).
Drawbacks:
- User cannot use VLANs in range 1024-3071. If the
switch receives frames with such VIDs, it will
misinterpret them as DSA tags.
- Switch uses Shared VLAN Learning (FDB lookup uses
only DMAC as key).
- When VLANs span cross-chip topologies, the total
number of permitted VLANs may be less than 7 per
port, due to a maximum number of 32 VLAN retagging
rules per switch.

29
Documentation/networking/dsa/dsa.rst
View File

@@ -200,19 +200,6 @@ receive all frames regardless of the value of the MAC DA. This can be done by
setting the ``promisc_on_master`` property of the ``struct dsa_device_ops``.
Note that this assumes a DSA-unaware master driver, which is the norm.
Hardware manufacturers are strongly discouraged to do this, but some tagging
protocols might not provide source port information on RX for all packets, but
e.g. only for control traffic (link-local PDUs). In this case, by implementing
the ``filter`` method of ``struct dsa_device_ops``, the tagger might select
which packets are to be redirected on RX towards the virtual DSA user network
interfaces, and which are to be left in the DSA master's RX data path.
It might also happen (although silicon vendors are strongly discouraged to
produce hardware like this) that a tagging protocol splits the switch-specific
information into a header portion and a tail portion, therefore not falling
cleanly into any of the above 3 categories. DSA does not support this
configuration.
Master network devices
----------------------
@@ -663,6 +650,22 @@ Bridge layer
CPU port, and flooding towards the CPU port should also be enabled, due to a
lack of an explicit address filtering mechanism in the DSA core.
- ``port_bridge_tx_fwd_offload``: bridge layer function invoked after
``port_bridge_join`` when a driver sets ``ds->num_fwd_offloading_bridges`` to
a non-zero value. Returning success in this function activates the TX
forwarding offload bridge feature for this port, which enables the tagging
protocol driver to inject data plane packets towards the bridging domain that
the port is a part of. Data plane packets are subject to FDB lookup, hardware
learning on the CPU port, and do not override the port STP state.
Additionally, replication of data plane packets (multicast, flooding) is
handled in hardware and the bridge driver will transmit a single skb for each
packet that needs replication. The method is provided as a configuration
point for drivers that need to configure the hardware for enabling this
feature.
- ``port_bridge_tx_fwd_unoffload``: bridge layer function invoken when a driver
leaves a bridge port which had the TX forwarding offload feature enabled.
Bridge VLAN filtering
---------------------

218
Documentation/networking/dsa/sja1105.rst
View File

@@ -65,199 +65,6 @@ If that changed setting can be transmitted to the switch through the dynamic
reconfiguration interface, it is; otherwise the switch is reset and
reprogrammed with the updated static configuration.
Traffic support
===============
The switches do not have hardware support for DSA tags, except for "slow
protocols" for switch control as STP and PTP. For these, the switches have two
programmable filters for link-local destination MACs.
These are used to trap BPDUs and PTP traffic to the master netdevice, and are
further used to support STP and 1588 ordinary clock/boundary clock
functionality. For frames trapped to the CPU, source port and switch ID
information is encoded by the hardware into the frames.
But by leveraging ``CONFIG_NET_DSA_TAG_8021Q`` (a software-defined DSA tagging
format based on VLANs), general-purpose traffic termination through the network
stack can be supported under certain circumstances.
Depending on VLAN awareness state, the following operating modes are possible
with the switch:
- Mode 1 (VLAN-unaware): a port is in this mode when it is used as a standalone
net device, or when it is enslaved to a bridge with ``vlan_filtering=0``.
- Mode 2 (fully VLAN-aware): a port is in this mode when it is enslaved to a
bridge with ``vlan_filtering=1``. Access to the entire VLAN range is given to
the user through ``bridge vlan`` commands, but general-purpose (anything
other than STP, PTP etc) traffic termination is not possible through the
switch net devices. The other packets can be still by user space processed
through the DSA master interface (similar to ``DSA_TAG_PROTO_NONE``).
- Mode 3 (best-effort VLAN-aware): a port is in this mode when enslaved to a
bridge with ``vlan_filtering=1``, and the devlink property of its parent
switch named ``best_effort_vlan_filtering`` is set to ``true``. When
configured like this, the range of usable VIDs is reduced (0 to 1023 and 3072
to 4094), so is the number of usable VIDs (maximum of 7 non-pvid VLANs per
port*), and shared VLAN learning is performed (FDB lookup is done only by
DMAC, not also by VID).
To summarize, in each mode, the following types of traffic are supported over
the switch net devices:
+-------------+-----------+--------------+------------+
| | Mode 1 | Mode 2 | Mode 3 |
+=============+===========+==============+============+
| Regular | Yes | No | Yes |
| traffic | | (use master) | |
+-------------+-----------+--------------+------------+
| Management | Yes | Yes | Yes |
| traffic | | | |
| (BPDU, PTP) | | | |
+-------------+-----------+--------------+------------+
To configure the switch to operate in Mode 3, the following steps can be
followed::
ip link add dev br0 type bridge
# swp2 operates in Mode 1 now
ip link set dev swp2 master br0
# swp2 temporarily moves to Mode 2
ip link set dev br0 type bridge vlan_filtering 1
[ 61.204770] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering
[ 61.239944] sja1105 spi0.1: Disabled switch tagging
# swp3 now operates in Mode 3
devlink dev param set spi/spi0.1 name best_effort_vlan_filtering value true cmode runtime
[ 64.682927] sja1105 spi0.1: Reset switch and programmed static config. Reason: VLAN filtering
[ 64.711925] sja1105 spi0.1: Enabled switch tagging
# Cannot use VLANs in range 1024-3071 while in Mode 3.
bridge vlan add dev swp2 vid 1025 untagged pvid
RTNETLINK answers: Operation not permitted
bridge vlan add dev swp2 vid 100
bridge vlan add dev swp2 vid 101 untagged
bridge vlan
port vlan ids
swp5 1 PVID Egress Untagged
swp2 1 PVID Egress Untagged
100
101 Egress Untagged
swp3 1 PVID Egress Untagged
swp4 1 PVID Egress Untagged
br0 1 PVID Egress Untagged
bridge vlan add dev swp2 vid 102
bridge vlan add dev swp2 vid 103
bridge vlan add dev swp2 vid 104
bridge vlan add dev swp2 vid 105
bridge vlan add dev swp2 vid 106
bridge vlan add dev swp2 vid 107
# Cannot use mode than 7 VLANs per port while in Mode 3.
[ 3885.216832] sja1105 spi0.1: No more free subvlans
\* "maximum of 7 non-pvid VLANs per port": Decoding VLAN-tagged packets on the
CPU in mode 3 is possible through VLAN retagging of packets that go from the
switch to the CPU. In cross-chip topologies, the port that goes to the CPU
might also go to other switches. In that case, those other switches will see
only a retagged packet (which only has meaning for the CPU). So if they are
interested in this VLAN, they need to apply retagging in the reverse direction,
to recover the original value from it. This consumes extra hardware resources
for this switch. There is a maximum of 32 entries in the Retagging Table of
each switch device.
As an example, consider this cross-chip topology::
+-------------------------------------------------+
| Host SoC |
| +-------------------------+ |
| | DSA master for embedded | |
| | switch (non-sja1105) | |
| +--------+-------------------------+--------+ |
| | embedded L2 switch | |
| | | |
| | +--------------+ +--------------+ | |
| | |DSA master for| |DSA master for| | |
| | | SJA1105 1 | | SJA1105 2 | | |
+--+---+--------------+-----+--------------+---+--+
+-----------------------+ +-----------------------+
| SJA1105 switch 1 | | SJA1105 switch 2 |
+-----+-----+-----+-----+ +-----+-----+-----+-----+
|sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3|
+-----+-----+-----+-----+ +-----+-----+-----+-----+
To reach the CPU, SJA1105 switch 1 (spi/spi2.1) uses the same port as is uses
to reach SJA1105 switch 2 (spi/spi2.2), which would be port 4 (not drawn).
Similarly for SJA1105 switch 2.
Also consider the following commands, that add VLAN 100 to every sja1105 user
port::
devlink dev param set spi/spi2.1 name best_effort_vlan_filtering value true cmode runtime
devlink dev param set spi/spi2.2 name best_effort_vlan_filtering value true cmode runtime
ip link add dev br0 type bridge
for port in sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2 sw2p3; do
ip link set dev $port master br0
done
ip link set dev br0 type bridge vlan_filtering 1
for port in sw1p0 sw1p1 sw1p2 sw1p3 \
sw2p0 sw2p1 sw2p2; do
bridge vlan add dev $port vid 100
done
ip link add link br0 name br0.100 type vlan id 100 && ip link set dev br0.100 up
ip addr add 192.168.100.3/24 dev br0.100
bridge vlan add dev br0 vid 100 self
bridge vlan
port vlan ids
sw1p0 1 PVID Egress Untagged
100
sw1p1 1 PVID Egress Untagged
100
sw1p2 1 PVID Egress Untagged
100
sw1p3 1 PVID Egress Untagged
100
sw2p0 1 PVID Egress Untagged
100
sw2p1 1 PVID Egress Untagged
100
sw2p2 1 PVID Egress Untagged
100
sw2p3 1 PVID Egress Untagged
br0 1 PVID Egress Untagged
100
SJA1105 switch 1 consumes 1 retagging entry for each VLAN on each user port
towards the CPU. It also consumes 1 retagging entry for each non-pvid VLAN that
it is also interested in, which is configured on any port of any neighbor
switch.
In this case, SJA1105 switch 1 consumes a total of 11 retagging entries, as
follows:
- 8 retagging entries for VLANs 1 and 100 installed on its user ports
(``sw1p0`` - ``sw1p3``)
- 3 retagging entries for VLAN 100 installed on the user ports of SJA1105
switch 2 (``sw2p0`` - ``sw2p2``), because it also has ports that are
interested in it. The VLAN 1 is a pvid on SJA1105 switch 2 and does not need
reverse retagging.
SJA1105 switch 2 also consumes 11 retagging entries, but organized as follows:
- 7 retagging entries for the bridge VLANs on its user ports (``sw2p0`` -
``sw2p3``).
- 4 retagging entries for VLAN 100 installed on the user ports of SJA1105
switch 1 (``sw1p0`` - ``sw1p3``).
Switching features
==================
@@ -282,33 +89,10 @@ untagged), and therefore this mode is also supported.
Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but
all bridges should have the same level of VLAN awareness (either both have
``vlan_filtering`` 0, or both 1). Also an inevitable limitation of the fact
that VLAN awareness is global at the switch level is that once a bridge with
``vlan_filtering`` enslaves at least one switch port, the other un-bridged
ports are no longer available for standalone traffic termination.
``vlan_filtering`` 0, or both 1).
Topology and loop detection through STP is supported.
L2 FDB manipulation (add/delete/dump) is currently possible for the first
generation devices. Aging time of FDB entries, as well as enabling fully static
management (no address learning and no flooding of unknown traffic) is not yet
configurable in the driver.
A special comment about bridging with other netdevices (illustrated with an
example):
A board has eth0, eth1, swp0@eth1, swp1@eth1, swp2@eth1, swp3@eth1.
The switch ports (swp0-3) are under br0.
It is desired that eth0 is turned into another switched port that communicates
with swp0-3.
If br0 has vlan_filtering 0, then eth0 can simply be added to br0 with the
intended results.
If br0 has vlan_filtering 1, then a new br1 interface needs to be created that
enslaves eth0 and eth1 (the DSA master of the switch ports). This is because in
this mode, the switch ports beneath br0 are not capable of regular traffic, and
are only used as a conduit for switchdev operations.
Offloads
========

23
Documentation/networking/ethtool-netlink.rst
View File

@@ -595,6 +595,14 @@ Link extended substates:
that is not formally
supported, which led to
signal integrity issues
``ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_REFERENCE_CLOCK_LOST`` The external clock signal for
SerDes is too weak or
unavailable.
``ETHTOOL_LINK_EXT_SUBSTATE_BSI_SERDES_ALOS`` The received signal for
SerDes is too weak because
analog loss of signal.
================================================================= =============================
Cable issue substates:
@@ -939,12 +947,25 @@ Kernel response contents:
``ETHTOOL_A_COALESCE_TX_USECS_HIGH`` u32 delay (us), high Tx
``ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGH`` u32 max packets, high Tx
``ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVAL`` u32 rate sampling interval
``ETHTOOL_A_COALESCE_USE_CQE_TX`` bool timer reset mode, Tx
``ETHTOOL_A_COALESCE_USE_CQE_RX`` bool timer reset mode, Rx
=========================================== ====== =======================
Attributes are only included in reply if their value is not zero or the
corresponding bit in ``ethtool_ops::supported_coalesce_params`` is set (i.e.
they are declared as supported by driver).
Timer reset mode (``ETHTOOL_A_COALESCE_USE_CQE_TX`` and
``ETHTOOL_A_COALESCE_USE_CQE_RX``) controls the interaction between packet
arrival and the various time based delay parameters. By default timers are
expected to limit the max delay between any packet arrival/departure and a
corresponding interrupt. In this mode timer should be started by packet
arrival (sometimes delivery of previous interrupt) and reset when interrupt
is delivered.
Setting the appropriate attribute to 1 will enable ``CQE`` mode, where
each packet event resets the timer. In this mode timer is used to force
the interrupt if queue goes idle, while busy queues depend on the packet
limit to trigger interrupts.
COALESCE_SET
============
@@ -977,6 +998,8 @@ Request contents:
``ETHTOOL_A_COALESCE_TX_USECS_HIGH`` u32 delay (us), high Tx
``ETHTOOL_A_COALESCE_TX_MAX_FRAMES_HIGH`` u32 max packets, high Tx
``ETHTOOL_A_COALESCE_RATE_SAMPLE_INTERVAL`` u32 rate sampling interval
``ETHTOOL_A_COALESCE_USE_CQE_TX`` bool timer reset mode, Tx
``ETHTOOL_A_COALESCE_USE_CQE_RX`` bool timer reset mode, Rx
=========================================== ====== =======================
Request is rejected if it attributes declared as unsupported by driver (i.e.

27
Documentation/networking/filter.rst
View File

@@ -320,13 +320,6 @@ Examples for low-level BPF:
ret #-1
drop: ret #0
**(Accelerated) VLAN w/ id 10**::
ld vlan_tci
jneq #10, drop
ret #-1
drop: ret #0
**icmp random packet sampling, 1 in 4**::
ldh [12]
@@ -358,6 +351,22 @@ Examples for low-level BPF:
bad: ret #0 /* SECCOMP_RET_KILL_THREAD */
good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */
Examples for low-level BPF extension:
**Packet for interface index 13**::
ld ifidx
jneq #13, drop
ret #-1
drop: ret #0
**(Accelerated) VLAN w/ id 10**::
ld vlan_tci
jneq #10, drop
ret #-1
drop: ret #0
The above example code can be placed into a file (here called "foo"), and
then be passed to the bpf_asm tool for generating opcodes, output that xt_bpf
and cls_bpf understands and can directly be loaded with. Example with above
@@ -629,8 +638,8 @@ extension, PTP dissector/classifier, and much more. They are all internally
converted by the kernel into the new instruction set representation and run
in the eBPF interpreter. For in-kernel handlers, this all works transparently
by using bpf_prog_create() for setting up the filter, resp.
bpf_prog_destroy() for destroying it. The macro
BPF_PROG_RUN(filter, ctx) transparently invokes eBPF interpreter or JITed
bpf_prog_destroy() for destroying it. The function
bpf_prog_run(filter, ctx) transparently invokes eBPF interpreter or JITed
code to run the filter. 'filter' is a pointer to struct bpf_prog that we
got from bpf_prog_create(), and 'ctx' the given context (e.g.
skb pointer). All constraints and restrictions from bpf_check_classic() apply

2
Documentation/networking/index.rst
View File

@@ -57,6 +57,7 @@ Contents:
gen_stats
gtp
ila
ioam6-sysctl
ipddp
ip_dynaddr
ipsec
@@ -68,6 +69,7 @@ Contents:
l2tp
lapb-module
mac80211-injection
mctp
mpls-sysctl
mptcp-sysctl
multiqueue

26
Documentation/networking/ioam6-sysctl.rst Normal file
View File

@@ -0,0 +1,26 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
IOAM6 Sysfs variables
=====================
/proc/sys/net/conf/<iface>/ioam6_* variables:
=============================================
ioam6_enabled - BOOL
Accept (= enabled) or ignore (= disabled) IPv6 IOAM options on ingress
for this interface.
* 0 - disabled (default)
* 1 - enabled
ioam6_id - SHORT INTEGER
Define the IOAM id of this interface.
Default is ~0.
ioam6_id_wide - INTEGER
Define the wide IOAM id of this interface.
Default is ~0.

17
Documentation/networking/ip-sysctl.rst
View File

@@ -1926,6 +1926,23 @@ fib_notify_on_flag_change - INTEGER
- 1 - Emit notifications.
- 2 - Emit notifications only for RTM_F_OFFLOAD_FAILED flag change.
ioam6_id - INTEGER
Define the IOAM id of this node. Uses only 24 bits out of 32 in total.
Min: 0
Max: 0xFFFFFF
Default: 0xFFFFFF
ioam6_id_wide - LONG INTEGER
Define the wide IOAM id of this node. Uses only 56 bits out of 64 in
total. Can be different from ioam6_id.
Min: 0
Max: 0xFFFFFFFFFFFFFF
Default: 0xFFFFFFFFFFFFFF
IPv6 Fragmentation:
ip6frag_high_thresh - INTEGER

213
Documentation/networking/mctp.rst Normal file
View File

@@ -0,0 +1,213 @@
.. SPDX-License-Identifier: GPL-2.0
==============================================
Management Component Transport Protocol (MCTP)
==============================================
net/mctp/ contains protocol support for MCTP, as defined by DMTF standard
DSP0236. Physical interface drivers ("bindings" in the specification) are
provided in drivers/net/mctp/.
The core code provides a socket-based interface to send and receive MCTP
messages, through an AF_MCTP, SOCK_DGRAM socket.
Structure: interfaces & networks
================================
The kernel models the local MCTP topology through two items: interfaces and
networks.
An interface (or "link") is an instance of an MCTP physical transport binding
(as defined by DSP0236, section 3.2.47), likely connected to a specific hardware
device. This is represented as a ``struct netdevice``.
A network defines a unique address space for MCTP endpoints by endpoint-ID
(described by DSP0236, section 3.2.31). A network has a user-visible identifier
to allow references from userspace. Route definitions are specific to one
network.
Interfaces are associated with one network. A network may be associated with one
or more interfaces.
If multiple networks are present, each may contain endpoint IDs (EIDs) that are
also present on other networks.
Sockets API
===========
Protocol definitions
--------------------
MCTP uses ``AF_MCTP`` / ``PF_MCTP`` for the address- and protocol- families.
Since MCTP is message-based, only ``SOCK_DGRAM`` sockets are supported.
.. code-block:: C
int sd = socket(AF_MCTP, SOCK_DGRAM, 0);
The only (current) value for the ``protocol`` argument is 0.
As with all socket address families, source and destination addresses are
specified with a ``sockaddr`` type, with a single-byte endpoint address:
.. code-block:: C
typedef __u8 mctp_eid_t;
struct mctp_addr {
mctp_eid_t s_addr;
};
struct sockaddr_mctp {
unsigned short int smctp_family;
int smctp_network;
struct mctp_addr smctp_addr;
__u8 smctp_type;
__u8 smctp_tag;
};
#define MCTP_NET_ANY 0x0
#define MCTP_ADDR_ANY 0xff
Syscall behaviour
-----------------
The following sections describe the MCTP-specific behaviours of the standard
socket system calls. These behaviours have been chosen to map closely to the
existing sockets APIs.
``bind()`` : set local socket address
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sockets that receive incoming request packets will bind to a local address,
using the ``bind()`` syscall.
.. code-block:: C
struct sockaddr_mctp addr;
addr.smctp_family = AF_MCTP;
addr.smctp_network = MCTP_NET_ANY;
addr.smctp_addr.s_addr = MCTP_ADDR_ANY;
addr.smctp_type = MCTP_TYPE_PLDM;
addr.smctp_tag = MCTP_TAG_OWNER;
int rc = bind(sd, (struct sockaddr *)&addr, sizeof(addr));
This establishes the local address of the socket. Incoming MCTP messages that
match the network, address, and message type will be received by this socket.
The reference to 'incoming' is important here; a bound socket will only receive
messages with the TO bit set, to indicate an incoming request message, rather
than a response.
The ``smctp_tag`` value will configure the tags accepted from the remote side of
this socket. Given the above, the only valid value is ``MCTP_TAG_OWNER``, which
will result in remotely "owned" tags being routed to this socket. Since
``MCTP_TAG_OWNER`` is set, the 3 least-significant bits of ``smctp_tag`` are not
used; callers must set them to zero.
A ``smctp_network`` value of ``MCTP_NET_ANY`` will configure the socket to
receive incoming packets from any locally-connected network. A specific network
value will cause the socket to only receive incoming messages from that network.
The ``smctp_addr`` field specifies a local address to bind to. A value of
``MCTP_ADDR_ANY`` configures the socket to receive messages addressed to any
local destination EID.
The ``smctp_type`` field specifies which message types to receive. Only the
lower 7 bits of the type is matched on incoming messages (ie., the
most-significant IC bit is not part of the match). This results in the socket
receiving packets with and without a message integrity check footer.
``sendto()``, ``sendmsg()``, ``send()`` : transmit an MCTP message
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
An MCTP message is transmitted using one of the ``sendto()``, ``sendmsg()`` or
``send()`` syscalls. Using ``sendto()`` as the primary example:
.. code-block:: C
struct sockaddr_mctp addr;
char buf[14];
ssize_t len;
/* set message destination */
addr.smctp_family = AF_MCTP;
addr.smctp_network = 0;
addr.smctp_addr.s_addr = 8;
addr.smctp_tag = MCTP_TAG_OWNER;
addr.smctp_type = MCTP_TYPE_ECHO;
/* arbitrary message to send, with message-type header */
buf[0] = MCTP_TYPE_ECHO;
memcpy(buf + 1, "hello, world!", sizeof(buf) - 1);
len = sendto(sd, buf, sizeof(buf), 0,
(struct sockaddr_mctp *)&addr, sizeof(addr));
The network and address fields of ``addr`` define the remote address to send to.
If ``smctp_tag`` has the ``MCTP_TAG_OWNER``, the kernel will ignore any bits set
in ``MCTP_TAG_VALUE``, and generate a tag value suitable for the destination
EID. If ``MCTP_TAG_OWNER`` is not set, the message will be sent with the tag
value as specified. If a tag value cannot be allocated, the system call will
report an errno of ``EAGAIN``.
The application must provide the message type byte as the first byte of the
message buffer passed to ``sendto()``. If a message integrity check is to be
included in the transmitted message, it must also be provided in the message
buffer, and the most-significant bit of the message type byte must be 1.
The ``sendmsg()`` system call allows a more compact argument interface, and the
message buffer to be specified as a scatter-gather list. At present no ancillary
message types (used for the ``msg_control`` data passed to ``sendmsg()``) are
defined.
Transmitting a message on an unconnected socket with ``MCTP_TAG_OWNER``
specified will cause an allocation of a tag, if no valid tag is already
allocated for that destination. The (destination-eid,tag) tuple acts as an
implicit local socket address, to allow the socket to receive responses to this
outgoing message. If any previous allocation has been performed (to for a
different remote EID), that allocation is lost.
Sockets will only receive responses to requests they have sent (with TO=1) and
may only respond (with TO=0) to requests they have received.
``recvfrom()``, ``recvmsg()``, ``recv()`` : receive an MCTP message
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
An MCTP message can be received by an application using one of the
``recvfrom()``, ``recvmsg()``, or ``recv()`` system calls. Using ``recvfrom()``
as the primary example:
.. code-block:: C
struct sockaddr_mctp addr;
socklen_t addrlen;
char buf[14];
ssize_t len;
addrlen = sizeof(addr);
len = recvfrom(sd, buf, sizeof(buf), 0,
(struct sockaddr_mctp *)&addr, &addrlen);
/* We can expect addr to describe an MCTP address */
assert(addrlen >= sizeof(buf));
assert(addr.smctp_family == AF_MCTP);
printf("received %zd bytes from remote EID %d\n", rc, addr.smctp_addr);
The address argument to ``recvfrom`` and ``recvmsg`` is populated with the
remote address of the incoming message, including tag value (this will be needed
in order to reply to the message).
The first byte of the message buffer will contain the message type byte. If an
integrity check follows the message, it will be included in the received buffer.
The ``recv()`` system call behaves in a similar way, but does not provide a
remote address to the application. Therefore, these are only useful if the
remote address is already known, or the message does not require a reply.
Like the send calls, sockets will only receive responses to requests they have
sent (TO=1) and may only respond (TO=0) to requests they have received.

12
Documentation/networking/mptcp-sysctl.rst
View File

@@ -45,3 +45,15 @@ allow_join_initial_addr_port - BOOLEAN
This is a per-namespace sysctl.
Default: 1
stale_loss_cnt - INTEGER
The number of MPTCP-level retransmission intervals with no traffic and
pending outstanding data on a given subflow required to declare it stale.
The packet scheduler ignores stale subflows.
A low stale_loss_cnt value allows for fast active-backup switch-over,
an high value maximize links utilization on edge scenarios e.g. lossy
link with high BER or peer pausing the data processing.
This is a per-namespace sysctl.
Default: 4

29
Documentation/networking/netdevices.rst
View File

@@ -222,6 +222,35 @@ ndo_do_ioctl:
Synchronization: rtnl_lock() semaphore.
Context: process
This is only called by network subsystems internally,
not by user space calling ioctl as it was in before
linux-5.14.
ndo_siocbond:
Synchronization: rtnl_lock() semaphore.
Context: process
Used by the bonding driver for the SIOCBOND family of
ioctl commands.
ndo_siocwandev:
Synchronization: rtnl_lock() semaphore.
Context: process
Used by the drivers/net/wan framework to handle
the SIOCWANDEV ioctl with the if_settings structure.
ndo_siocdevprivate:
Synchronization: rtnl_lock() semaphore.
Context: process
This is used to implement SIOCDEVPRIVATE ioctl helpers.
These should not be added to new drivers, so don't use.
ndo_eth_ioctl:
Synchronization: rtnl_lock() semaphore.
Context: process
ndo_get_stats:
Synchronization: rtnl_lock() semaphore, dev_base_lock rwlock, or RCU.
Context: atomic (can't sleep under rwlock or RCU)

7
Documentation/networking/nf_conntrack-sysctl.rst
View File

@@ -184,6 +184,13 @@ nf_conntrack_gre_timeout_stream - INTEGER (seconds)
This extended timeout will be used in case there is an GRE stream
detected.
nf_hooks_lwtunnel - BOOLEAN
- 0 - disabled (default)
- not 0 - enabled
If this option is enabled, the lightweight tunnel netfilter hooks are
enabled. This option cannot be disabled once it is enabled.
nf_flowtable_tcp_timeout - INTEGER (seconds)
default 30

18
Documentation/networking/pktgen.rst
View File

@@ -248,26 +248,24 @@ Usage:::
-i : ($DEV) output interface/device (required)
-s : ($PKT_SIZE) packet size
-d : ($DEST_IP) destination IP
-d : ($DEST_IP) destination IP. CIDR (e.g. 198.18.0.0/15) is also allowed
-m : ($DST_MAC) destination MAC-addr
-p : ($DST_PORT) destination PORT range (e.g. 433-444) is also allowed
-t : ($THREADS) threads to start
-f : ($F_THREAD) index of first thread (zero indexed CPU number)
-c : ($SKB_CLONE) SKB clones send before alloc new SKB
-n : ($COUNT) num messages to send per thread, 0 means indefinitely
-b : ($BURST) HW level bursting of SKBs
-v : ($VERBOSE) verbose
-x : ($DEBUG) debug
-6 : ($IP6) IPv6
-w : ($DELAY) Tx Delay value (ns)
-a : ($APPEND) Script will not reset generator's state, but will append its config
The global variables being set are also listed. E.g. the required
interface/device parameter "-i" sets variable $DEV. Copy the
pktgen_sampleXX scripts and modify them to fit your own needs.
The old scripts::
pktgen.conf-1-2 # 1 CPU 2 dev
pktgen.conf-1-1-rdos # 1 CPU 1 dev w. route DoS
pktgen.conf-1-1-ip6 # 1 CPU 1 dev ipv6
pktgen.conf-1-1-ip6-rdos # 1 CPU 1 dev ipv6 w. route DoS
pktgen.conf-1-1-flows # 1 CPU 1 dev multiple flows.
Interrupt affinity
===================
@@ -398,7 +396,7 @@ Current commands and configuration options
References:
- ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/
- tp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/
- ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/
Paper from Linux-Kongress in Erlangen 2004.
- ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf

6
Documentation/networking/timestamping.rst
View File

@@ -625,7 +625,7 @@ interfaces of a DSA switch to share the same PHC.
By design, PTP timestamping with a DSA switch does not need any special
handling in the driver for the host port it is attached to. However, when the
host port also supports PTP timestamping, DSA will take care of intercepting
the ``.ndo_do_ioctl`` calls towards the host port, and block attempts to enable
the ``.ndo_eth_ioctl`` calls towards the host port, and block attempts to enable
hardware timestamping on it. This is because the SO_TIMESTAMPING API does not
allow the delivery of multiple hardware timestamps for the same packet, so
anybody else except for the DSA switch port must be prevented from doing so.
@@ -688,7 +688,7 @@ ethtool ioctl operations for them need to be mediated by their respective MAC
driver. Therefore, as opposed to DSA switches, modifications need to be done
to each individual MAC driver for PHY timestamping support. This entails:
- Checking, in ``.ndo_do_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)``
- Checking, in ``.ndo_eth_ioctl``, whether ``phy_has_hwtstamp(netdev->phydev)``
is true or not. If it is, then the MAC driver should not process this request
but instead pass it on to the PHY using ``phy_mii_ioctl()``.
@@ -747,7 +747,7 @@ For example, a typical driver design for TX timestamping might be to split the
transmission part into 2 portions:
1. "TX": checks whether PTP timestamping has been previously enabled through
the ``.ndo_do_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the
the ``.ndo_eth_ioctl`` ("``priv->hwtstamp_tx_enabled == true``") and the
current skb requires a TX timestamp ("``skb_shinfo(skb)->tx_flags &
SKBTX_HW_TSTAMP``"). If this is true, it sets the
"``skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS``" flag. Note: as

13
Documentation/networking/vrf.rst
View File

@@ -144,6 +144,19 @@ default VRF are only handled by a socket not bound to any VRF::
netfilter rules on the VRF device can be used to limit access to services
running in the default VRF context as well.
Using VRF-aware applications (applications which simultaneously create sockets
outside and inside VRFs) in conjunction with ``net.ipv4.tcp_l3mdev_accept=1``
is possible but may lead to problems in some situations. With that sysctl
value, it is unspecified which listening socket will be selected to handle
connections for VRF traffic; ie. either a socket bound to the VRF or an unbound
socket may be used to accept new connections from a VRF. This somewhat
unexpected behavior can lead to problems if sockets are configured with extra
options (ex. TCP MD5 keys) with the expectation that VRF traffic will
exclusively be handled by sockets bound to VRFs, as would be the case with
``net.ipv4.tcp_l3mdev_accept=0``. Finally and as a reminder, regardless of
which listening socket is selected, established sockets will be created in the
VRF based on the ingress interface, as documented earlier.
--------------------------------------------------------------------------------
Using iproute2 for VRFs

65
MAINTAINERS
View File

@@ -1316,6 +1316,13 @@ L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/i2c/aptina-pll.*
AQUACOMPUTER D5 NEXT PUMP SENSOR DRIVER
M: Aleksa Savic <savicaleksa83@gmail.com>
L: linux-hwmon@vger.kernel.org
S: Maintained
F: Documentation/hwmon/aquacomputer_d5next.rst
F: drivers/hwmon/aquacomputer_d5next.c
AQUANTIA ETHERNET DRIVER (atlantic)
M: Igor Russkikh <irusskikh@marvell.com>
L: netdev@vger.kernel.org
@@ -2842,7 +2849,7 @@ AS3645A LED FLASH CONTROLLER DRIVER
M: Sakari Ailus <sakari.ailus@iki.fi>
L: linux-leds@vger.kernel.org
S: Maintained
F: drivers/leds/leds-as3645a.c
F: drivers/leds/flash/leds-as3645a.c
ASAHI KASEI AK7375 LENS VOICE COIL DRIVER
M: Tianshu Qiu <tian.shu.qiu@intel.com>
@@ -3197,7 +3204,7 @@ S: Maintained
W: https://www.open-mesh.org/
Q: https://patchwork.open-mesh.org/project/batman/list/
B: https://www.open-mesh.org/projects/batman-adv/issues
C: irc://chat.freenode.net/batman
C: ircs://irc.hackint.org/batadv
T: git https://git.open-mesh.org/linux-merge.git
F: Documentation/networking/batman-adv.rst
F: include/uapi/linux/batadv_packet.h
@@ -3409,7 +3416,6 @@ F: drivers/net/ethernet/netronome/nfp/bpf/
BPF JIT for POWERPC (32-BIT AND 64-BIT)
M: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
M: Sandipan Das <sandipan@linux.ibm.com>
L: netdev@vger.kernel.org
L: bpf@vger.kernel.org
S: Maintained
@@ -5695,6 +5701,7 @@ DPAA2 ETHERNET SWITCH DRIVER
M: Ioana Ciornei <ioana.ciornei@nxp.com>
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst
F: drivers/net/ethernet/freescale/dpaa2/dpaa2-switch*
F: drivers/net/ethernet/freescale/dpaa2/dpsw*
@@ -6915,6 +6922,12 @@ M: Mark Einon <mark.einon@gmail.com>
S: Odd Fixes
F: drivers/net/ethernet/agere/
ETAS ES58X CAN/USB DRIVER
M: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
L: linux-can@vger.kernel.org
S: Maintained
F: drivers/net/can/usb/etas_es58x/
ETHERNET BRIDGE
M: Roopa Prabhu <roopa@nvidia.com>
M: Nikolay Aleksandrov <nikolay@nvidia.com>
@@ -9767,11 +9780,6 @@ M: David Sterba <dsterba@suse.com>
S: Odd Fixes
F: drivers/tty/ipwireless/
IPX NETWORK LAYER
L: netdev@vger.kernel.org
S: Obsolete
F: include/uapi/linux/ipx.h
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
M: Marc Zyngier <maz@kernel.org>
S: Maintained
@@ -10417,6 +10425,7 @@ F: net/core/skmsg.c
F: net/core/sock_map.c
F: net/ipv4/tcp_bpf.c
F: net/ipv4/udp_bpf.c
F: net/unix/unix_bpf.c
LANDLOCK SECURITY MODULE
M: Mickaël Salaün <mic@digikod.net>
@@ -11050,6 +11059,18 @@ F: drivers/mailbox/arm_mhuv2.c
F: include/linux/mailbox/arm_mhuv2_message.h
F: Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
MANAGEMENT COMPONENT TRANSPORT PROTOCOL (MCTP)
M: Jeremy Kerr <jk@codeconstruct.com.au>
M: Matt Johnston <matt@codeconstruct.com.au>
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/networking/mctp.rst
F: drivers/net/mctp/
F: include/net/mctp.h
F: include/net/mctpdevice.h
F: include/net/netns/mctp.h
F: net/mctp/
MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
M: Michael Kerrisk <mtk.manpages@gmail.com>
L: linux-man@vger.kernel.org
@@ -11347,6 +11368,12 @@ W: https://linuxtv.org
T: git git://linuxtv.org/media_tree.git
F: drivers/media/radio/radio-maxiradio*
MAXLINEAR ETHERNET PHY DRIVER
M: Xu Liang <lxu@maxlinear.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/phy/mxl-gpy.c
MCBA MICROCHIP CAN BUS ANALYZER TOOL DRIVER
R: Yasushi SHOJI <yashi@spacecubics.com>
L: linux-can@vger.kernel.org
@@ -13896,6 +13923,12 @@ F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
OPENCOMPUTE PTP CLOCK DRIVER
M: Jonathan Lemon <jonathan.lemon@gmail.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/ptp/ptp_ocp.c
OPENCORES I2C BUS DRIVER
M: Peter Korsgaard <peter@korsgaard.com>
M: Andrew Lunn <andrew@lunn.ch>
@@ -14959,13 +14992,6 @@ S: Maintained
F: include/linux/printk.h
F: kernel/printk/
PRISM54 WIRELESS DRIVER
M: Luis Chamberlain <mcgrof@kernel.org>
L: linux-wireless@vger.kernel.org
S: Obsolete
W: https://wireless.wiki.kernel.org/en/users/Drivers/p54
F: drivers/net/wireless/intersil/prism54/
PROC FILESYSTEM
L: linux-kernel@vger.kernel.org
L: linux-fsdevel@vger.kernel.org
@@ -19749,6 +19775,15 @@ S: Maintained
F: include/uapi/linux/virtio_snd.h
F: sound/virtio/*
VIRTIO I2C DRIVER
M: Jie Deng <jie.deng@intel.com>
M: Viresh Kumar <viresh.kumar@linaro.org>
L: linux-i2c@vger.kernel.org
L: virtualization@lists.linux-foundation.org
S: Maintained
F: drivers/i2c/busses/i2c-virtio.c
F: include/uapi/linux/virtio_i2c.h
VIRTUAL BOX GUEST DEVICE DRIVER
M: Hans de Goede <hdegoede@redhat.com>
M: Arnd Bergmann <arnd@arndb.de>

2
arch/alpha/include/uapi/asm/socket.h
View File

@@ -129,6 +129,8 @@
#define SO_NETNS_COOKIE 71
#define SO_BUF_LOCK 72
#if !defined(__KERNEL__)
#if __BITS_PER_LONG == 64

2
arch/arm/boot/dts/imx35.dtsi
View File

@@ -189,7 +189,7 @@
status = "disabled";
};
fec: fec@50038000 {
fec: ethernet@50038000 {
compatible = "fsl,imx35-fec", "fsl,imx27-fec";
reg = <0x50038000 0x4000>;
clocks = <&clks 46>, <&clks 8>;

34
arch/arm/boot/dts/imx6q-novena.dts
View File

@@ -222,20 +222,30 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet_novena>;
phy-mode = "rgmii";
phy-handle = <&ethphy>;
phy-reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
rxc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
txc-skew-ps = <3000>;
txen-skew-ps = <0>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <3000>;
txd1-skew-ps = <3000>;
txd2-skew-ps = <3000>;
txd3-skew-ps = <3000>;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy {
compatible = "ethernet-phy-ieee802.3-c22";
rxc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
txc-skew-ps = <3000>;
txen-skew-ps = <0>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <3000>;
txd1-skew-ps = <3000>;
txd2-skew-ps = <3000>;
txd3-skew-ps = <3000>;
};
};
};
&hdmi {

18
arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
View File

@@ -316,12 +316,22 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
phy-handle = <&ethphy>;
phy-reset-gpios = <&gpio7 18 GPIO_ACTIVE_LOW>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy {
compatible = "ethernet-phy-ieee802.3-c22";
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
};
};
};
&gpmi {

34
arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
View File

@@ -190,23 +190,33 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
phy-handle = <&ethphy>;
phy-reset-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
<&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
fsl,err006687-workaround-present;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy {
compatible = "ethernet-phy-ieee802.3-c22";
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
};
};
};
&hdmi {

34
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
View File

@@ -332,23 +332,33 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
phy-handle = <&ethphy>;
phy-reset-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
<&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
fsl,err006687-workaround-present;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy {
compatible = "ethernet-phy-ieee802.3-c22";
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
};
};
};
&hdmi {

34
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
View File

@@ -265,23 +265,33 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
phy-handle = <&ethphy>;
phy-reset-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
<&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
fsl,err006687-workaround-present;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy {
compatible = "ethernet-phy-ieee802.3-c22";
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
};
};
};
&hdmi {

34
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
View File

@@ -324,20 +324,30 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
phy-handle = <&ethphy>;
phy-reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy: ethernet-phy {
compatible = "ethernet-phy-ieee802.3-c22";
txen-skew-ps = <0>;
txc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
rxc-skew-ps = <3000>;
rxd0-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd3-skew-ps = <0>;
txd0-skew-ps = <0>;
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
};
};
};
&hdmi {

1
arch/arm/boot/dts/imx7-mba7.dtsi
View File

@@ -216,7 +216,6 @@
phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio7 15 GPIO_ACTIVE_LOW>;
phy-reset-duration = <1>;
phy-reset-delay = <1>;
phy-supply = <&reg_fec1_pwdn>;
phy-handle = <&ethphy1_0>;
fsl,magic-packet;

1
arch/arm/boot/dts/imx7d-mba7.dts
View File

@@ -23,7 +23,6 @@
phy-mode = "rgmii-id";
phy-reset-gpios = <&gpio2 28 GPIO_ACTIVE_LOW>;
phy-reset-duration = <1>;
phy-reset-delay = <1>;
phy-supply = <&reg_fec2_pwdn>;
phy-handle = <&ethphy2_0>;
fsl,magic-packet;

14
arch/arm/mach-ixp4xx/common.c
View File

@@ -268,9 +268,23 @@ static struct platform_device ixp46x_i2c_controller = {
.resource = ixp46x_i2c_resources
};
static struct resource ixp46x_ptp_resources[] = {
DEFINE_RES_MEM(IXP4XX_TIMESYNC_BASE_PHYS, SZ_4K),
DEFINE_RES_IRQ_NAMED(IRQ_IXP4XX_GPIO8, "master"),
DEFINE_RES_IRQ_NAMED(IRQ_IXP4XX_GPIO7, "slave"),
};
static struct platform_device ixp46x_ptp = {
.name = "ptp-ixp46x",
.id = -1,
.resource = ixp46x_ptp_resources,
.num_resources = ARRAY_SIZE(ixp46x_ptp_resources),
};
static struct platform_device *ixp46x_devices[] __initdata = {
&ixp46x_hwrandom_device,
&ixp46x_i2c_controller,
&ixp46x_ptp,
};
unsigned long ixp4xx_exp_bus_size;

2
arch/arm64/boot/dts/freescale/imx8mm.dtsi
View File

@@ -920,7 +920,7 @@
};
fec1: ethernet@30be0000 {
compatible = "fsl,imx8mm-fec", "fsl,imx6sx-fec";
compatible = "fsl,imx8mm-fec", "fsl,imx8mq-fec", "fsl,imx6sx-fec";
reg = <0x30be0000 0x10000>;
interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,

2
arch/arm64/boot/dts/freescale/imx8mn.dtsi
View File

@@ -923,7 +923,7 @@
};
fec1: ethernet@30be0000 {
compatible = "fsl,imx8mn-fec", "fsl,imx6sx-fec";
compatible = "fsl,imx8mn-fec", "fsl,imx8mq-fec", "fsl,imx6sx-fec";
reg = <0x30be0000 0x10000>;
interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,

4
arch/arm64/boot/dts/freescale/imx8qxp-ss-conn.dtsi
View File

@@ -17,9 +17,9 @@
};
&fec1 {
compatible = "fsl,imx8qxp-fec", "fsl,imx6sx-fec";
compatible = "fsl,imx8qxp-fec", "fsl,imx8qm-fec", "fsl,imx6sx-fec";
};
&fec2 {
compatible = "fsl,imx8qxp-fec", "fsl,imx6sx-fec";
compatible = "fsl,imx8qxp-fec", "fsl,imx8qm-fec", "fsl,imx6sx-fec";
};

5
arch/arm64/boot/dts/microchip/sparx5.dtsi
View File

@@ -471,8 +471,9 @@
<0x6 0x10004000 0x7fc000>,
<0x6 0x11010000 0xaf0000>;
reg-names = "cpu", "dev", "gcb";
interrupt-names = "xtr";
interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "xtr", "fdma";
interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
resets = <&reset 0>;
reset-names = "switch";
};

24
arch/arm64/boot/dts/qcom/sc7180.dtsi
View File

@@ -786,6 +786,8 @@
<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -838,6 +840,8 @@
<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -890,6 +894,8 @@
<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -924,6 +930,8 @@
<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -976,6 +984,8 @@
<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -1010,6 +1020,8 @@
<&aggre1_noc MASTER_QUP_0 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -1075,6 +1087,8 @@
<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -1127,6 +1141,8 @@
<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -1161,6 +1177,8 @@
<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -1213,6 +1231,8 @@
<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -1247,6 +1267,8 @@
<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};
@@ -1299,6 +1321,8 @@
<&aggre2_noc MASTER_QUP_1 0 &mc_virt SLAVE_EBI1 0>;
interconnect-names = "qup-core", "qup-config",
"qup-memory";
power-domains = <&rpmhpd SC7180_CX>;
required-opps = <&rpmhpd_opp_low_svs>;
status = "disabled";
};

3
arch/arm64/include/asm/acpi.h
View File

@@ -50,6 +50,9 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size);
#define acpi_os_ioremap acpi_os_ioremap
void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size);
#define acpi_os_memmap acpi_os_memmap
typedef u64 phys_cpuid_t;
#define PHYS_CPUID_INVALID INVALID_HWID

14
arch/arm64/include/asm/compat.h
View File

@@ -5,6 +5,9 @@
#ifndef __ASM_COMPAT_H
#define __ASM_COMPAT_H
#define compat_mode_t compat_mode_t
typedef u16 compat_mode_t;
#include <asm-generic/compat.h>
#ifdef CONFIG_COMPAT
@@ -27,13 +30,9 @@ typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u16 __compat_uid16_t;
typedef u16 __compat_gid16_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
typedef u32 compat_dev_t;
typedef s32 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
struct compat_stat {
@@ -103,13 +102,6 @@ struct compat_statfs {
#define COMPAT_RLIM_INFINITY 0xffffffff
typedef u32 compat_old_sigset_t;
#define _COMPAT_NSIG 64
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#define COMPAT_OFF_T_MAX 0x7fffffff
#define compat_user_stack_pointer() (user_stack_pointer(task_pt_regs(current)))

19
arch/arm64/kernel/acpi.c
View File

@@ -273,7 +273,8 @@ pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
return __pgprot(PROT_DEVICE_nGnRnE);
}
void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
static void __iomem *__acpi_os_ioremap(acpi_physical_address phys,
acpi_size size, bool memory)
{
efi_memory_desc_t *md, *region = NULL;
pgprot_t prot;
@@ -299,9 +300,11 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
* It is fine for AML to remap regions that are not represented in the
* EFI memory map at all, as it only describes normal memory, and MMIO
* regions that require a virtual mapping to make them accessible to
* the EFI runtime services.
* the EFI runtime services. Determine the region default
* attributes by checking the requested memory semantics.
*/
prot = __pgprot(PROT_DEVICE_nGnRnE);
prot = memory ? __pgprot(PROT_NORMAL_NC) :
__pgprot(PROT_DEVICE_nGnRnE);
if (region) {
switch (region->type) {
case EFI_LOADER_CODE:
@@ -361,6 +364,16 @@ void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
return __ioremap(phys, size, prot);
}
void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size)
{
return __acpi_os_ioremap(phys, size, false);
}
void __iomem *acpi_os_memmap(acpi_physical_address phys, acpi_size size)
{
return __acpi_os_ioremap(phys, size, true);
}
/*
* Claim Synchronous External Aborts as a firmware first notification.
*

24
arch/mips/include/asm/compat.h
View File

@@ -9,20 +9,25 @@
#include <asm/page.h>
#include <asm/ptrace.h>
typedef s32 __compat_uid_t;
typedef s32 __compat_gid_t;
typedef __compat_uid_t __compat_uid32_t;
typedef __compat_gid_t __compat_gid32_t;
#define __compat_uid32_t __compat_uid32_t
#define __compat_gid32_t __compat_gid32_t
#define _COMPAT_NSIG 128 /* Don't ask !$@#% ... */
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#include <asm-generic/compat.h>
#define COMPAT_USER_HZ 100
#define COMPAT_UTS_MACHINE "mips\0\0\0"
typedef s32 __compat_uid_t;
typedef s32 __compat_gid_t;
typedef __compat_uid_t __compat_uid32_t;
typedef __compat_gid_t __compat_gid32_t;
typedef u32 compat_mode_t;
typedef u32 compat_dev_t;
typedef u32 compat_nlink_t;
typedef s32 compat_ipc_pid_t;
typedef s32 compat_caddr_t;
typedef struct {
s32 val[2];
} compat_fsid_t;
@@ -89,13 +94,6 @@ struct compat_statfs {
#define COMPAT_RLIM_INFINITY 0x7fffffffUL
typedef u32 compat_old_sigset_t; /* at least 32 bits */
#define _COMPAT_NSIG 128 /* Don't ask !$@#% ... */
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#define COMPAT_OFF_T_MAX 0x7fffffff
static inline void __user *arch_compat_alloc_user_space(long len)

2
arch/mips/include/uapi/asm/socket.h
View File

@@ -140,6 +140,8 @@
#define SO_NETNS_COOKIE 71
#define SO_BUF_LOCK 72
#if !defined(__KERNEL__)
#if __BITS_PER_LONG == 64

14
arch/parisc/include/asm/compat.h
View File

@@ -8,6 +8,9 @@
#include <linux/sched.h>
#include <linux/thread_info.h>
#define compat_mode_t compat_mode_t
typedef u16 compat_mode_t;
#include <asm-generic/compat.h>
#define COMPAT_USER_HZ 100
@@ -15,13 +18,9 @@
typedef u32 __compat_uid_t;
typedef u32 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
typedef u32 compat_dev_t;
typedef u16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
typedef u32 compat_caddr_t;
struct compat_stat {
compat_dev_t st_dev; /* dev_t is 32 bits on parisc */
@@ -96,13 +95,6 @@ struct compat_sigcontext {
#define COMPAT_RLIM_INFINITY 0xffffffff
typedef u32 compat_old_sigset_t; /* at least 32 bits */
#define _COMPAT_NSIG 64
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#define COMPAT_OFF_T_MAX 0x7fffffff
struct compat_ipc64_perm {

2
arch/parisc/include/uapi/asm/socket.h
View File

@@ -121,6 +121,8 @@
#define SO_NETNS_COOKIE 0x4045
#define SO_BUF_LOCK 0x4046
#if !defined(__KERNEL__)
#if __BITS_PER_LONG == 64

11
arch/powerpc/include/asm/compat.h
View File

@@ -19,13 +19,9 @@
typedef u32 __compat_uid_t;
typedef u32 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u32 compat_mode_t;
typedef u32 compat_dev_t;
typedef s16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
struct compat_stat {
@@ -85,13 +81,6 @@ struct compat_statfs {
#define COMPAT_RLIM_INFINITY 0xffffffff
typedef u32 compat_old_sigset_t;
#define _COMPAT_NSIG 64
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#define COMPAT_OFF_T_MAX 0x7fffffff
static inline void __user *arch_compat_alloc_user_space(long len)

2
arch/s390/include/asm/ccwgroup.h
View File

@@ -53,8 +53,6 @@ extern int ccwgroup_driver_register (struct ccwgroup_driver *cdriver);
extern void ccwgroup_driver_unregister (struct ccwgroup_driver *cdriver);
int ccwgroup_create_dev(struct device *root, struct ccwgroup_driver *gdrv,
int num_devices, const char *buf);
struct ccwgroup_device *get_ccwgroupdev_by_busid(struct ccwgroup_driver *gdrv,
char *bus_id);
extern int ccwgroup_set_online(struct ccwgroup_device *gdev);
extern int ccwgroup_set_offline(struct ccwgroup_device *gdev);

14
arch/s390/include/asm/compat.h
View File

@@ -9,6 +9,9 @@
#include <linux/sched/task_stack.h>
#include <linux/thread_info.h>
#define compat_mode_t compat_mode_t
typedef u16 compat_mode_t;
#include <asm-generic/compat.h>
#define __TYPE_IS_PTR(t) (!__builtin_types_compatible_p( \
@@ -55,13 +58,9 @@
typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
typedef u16 compat_dev_t;
typedef u16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
typedef struct {
@@ -155,13 +154,6 @@ struct compat_statfs64 {
#define COMPAT_RLIM_INFINITY 0xffffffff
typedef u32 compat_old_sigset_t; /* at least 32 bits */
#define _COMPAT_NSIG 64
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#define COMPAT_OFF_T_MAX 0x7fffffff
/*

14
arch/sparc/include/asm/compat.h
View File

@@ -6,6 +6,9 @@
*/
#include <linux/types.h>
#define compat_mode_t compat_mode_t
typedef u16 compat_mode_t;
#include <asm-generic/compat.h>
#define COMPAT_USER_HZ 100
@@ -13,13 +16,9 @@
typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
typedef u16 compat_dev_t;
typedef s16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
struct compat_stat {
@@ -115,13 +114,6 @@ struct compat_statfs {
#define COMPAT_RLIM_INFINITY 0x7fffffff
typedef u32 compat_old_sigset_t;
#define _COMPAT_NSIG 64
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#define COMPAT_OFF_T_MAX 0x7fffffff
#ifdef CONFIG_COMPAT

2
arch/sparc/include/uapi/asm/socket.h
View File

@@ -122,6 +122,8 @@
#define SO_NETNS_COOKIE 0x0050
#define SO_BUF_LOCK 0x0051
#if !defined(__KERNEL__)

8
arch/um/drivers/vector_kern.c
View File

@@ -1488,7 +1488,9 @@ static void vector_get_ethtool_stats(struct net_device *dev,
}
static int vector_get_coalesce(struct net_device *netdev,
struct ethtool_coalesce *ec)
struct ethtool_coalesce *ec,
struct kernel_ethtool_coalesce *kernel_coal,
struct netlink_ext_ack *extack)
{
struct vector_private *vp = netdev_priv(netdev);
@@ -1497,7 +1499,9 @@ static int vector_get_coalesce(struct net_device *netdev,
}
static int vector_set_coalesce(struct net_device *netdev,
struct ethtool_coalesce *ec)
struct ethtool_coalesce *ec,
struct kernel_ethtool_coalesce *kernel_coal,
struct netlink_ext_ack *extack)
{
struct vector_private *vp = netdev_priv(netdev);

14
arch/x86/include/asm/compat.h
View File

@@ -12,6 +12,9 @@
#include <asm/user32.h>
#include <asm/unistd.h>
#define compat_mode_t compat_mode_t
typedef u16 compat_mode_t;
#include <asm-generic/compat.h>
#define COMPAT_USER_HZ 100
@@ -19,13 +22,9 @@
typedef u16 __compat_uid_t;
typedef u16 __compat_gid_t;
typedef u32 __compat_uid32_t;
typedef u32 __compat_gid32_t;
typedef u16 compat_mode_t;
typedef u16 compat_dev_t;
typedef u16 compat_nlink_t;
typedef u16 compat_ipc_pid_t;
typedef u32 compat_caddr_t;
typedef __kernel_fsid_t compat_fsid_t;
struct compat_stat {
@@ -92,13 +91,6 @@ struct compat_statfs {
#define COMPAT_RLIM_INFINITY 0xffffffff
typedef u32 compat_old_sigset_t; /* at least 32 bits */
#define _COMPAT_NSIG 64
#define _COMPAT_NSIG_BPW 32
typedef u32 compat_sigset_word;
#define COMPAT_OFF_T_MAX 0x7fffffff
struct compat_ipc64_perm {

1
arch/x86/include/asm/signal.h
View File

@@ -29,6 +29,7 @@ typedef struct {
#define SA_X32_ABI 0x01000000u
#ifndef CONFIG_COMPAT
#define compat_sigset_t compat_sigset_t
typedef sigset_t compat_sigset_t;
#endif

5
arch/x86/kernel/amd_nb.c
View File

@@ -25,6 +25,8 @@
#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F4 0x144c
#define PCI_DEVICE_ID_AMD_17H_M70H_DF_F4 0x1444
#define PCI_DEVICE_ID_AMD_19H_DF_F4 0x1654
#define PCI_DEVICE_ID_AMD_19H_M40H_ROOT 0x14b5
#define PCI_DEVICE_ID_AMD_19H_M40H_DF_F4 0x167d
#define PCI_DEVICE_ID_AMD_19H_M50H_DF_F4 0x166e
/* Protect the PCI config register pairs used for SMN and DF indirect access. */
@@ -37,6 +39,7 @@ static const struct pci_device_id amd_root_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_ROOT) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M30H_ROOT) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_ROOT) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M40H_ROOT) },
{}
};
@@ -58,6 +61,7 @@ static const struct pci_device_id amd_nb_misc_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M40H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M50H_DF_F3) },
{}
};
@@ -74,6 +78,7 @@ static const struct pci_device_id amd_nb_link_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M40H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M50H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
{}

10
arch/x86/kernel/setup.c
View File

@@ -572,16 +572,6 @@ void __init reserve_standard_io_resources(void)
}
static __init void reserve_ibft_region(void)
{
unsigned long addr, size = 0;
addr = find_ibft_region(&size);
if (size)
memblock_reserve(addr, size);
}
static bool __init snb_gfx_workaround_needed(void)
{
#ifdef CONFIG_PCI

Some files were not shown because too many files have changed in this diff Show More