renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-28 07:04:00 +08:00
Code

Merge branch 'for-5.13/surface-system-aggregator-intergration' into for-linus

Browse Source 
- Surface Aggregator Module support from Maximilian Luz
This commit is contained in:
Jiri Kosina 2021-04-29 21:45:19 +02:00
commit e50fedec82
1834 changed files with 64532 additions and 31678 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.clang-format
View File

@ -109,6 +109,7 @@ ForEachMacros:
- 'css_for_each_child'
- 'css_for_each_descendant_post'
- 'css_for_each_descendant_pre'
- 'cxl_for_each_cmd'
- 'device_for_each_child_node'
- 'dma_fence_chain_for_each'
- 'do_for_each_ftrace_op'

1
.mailmap
View File

@ -237,6 +237,7 @@ Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
Mayuresh Janorkar <mayur@ti.com>
Michael Buesch <m@bues.ch>
Michel Dänzer <michel@tungstengraphics.com>
Miguel Ojeda <ojeda@kernel.org> <miguel.ojeda.sandonis@gmail.com>
Mike Rapoport <rppt@kernel.org> <mike@compulab.co.il>
Mike Rapoport <rppt@kernel.org> <mike.rapoport@gmail.com>
Mike Rapoport <rppt@kernel.org> <rppt@linux.ibm.com>

17
CREDITS
View File

@ -1244,10 +1244,10 @@ S: 80050-430 - Curitiba - Paraná
S: Brazil
N: Oded Gabbay
E: oded.gabbay@gmail.com
D: HabanaLabs and AMD KFD maintainer
S: 12 Shraga Raphaeli
S: Petah-Tikva, 4906418
E: ogabbay@kernel.org
D: HabanaLabs maintainer
S: 29 Duchifat St.
S: Ra'anana 4372029
S: Israel
N: Kumar Gala
@ -2841,14 +2841,11 @@ S: Subiaco, 6008
S: Perth, Western Australia
S: Australia
N: Miguel Ojeda Sandonis
E: miguel.ojeda.sandonis@gmail.com
W: http://miguelojeda.es
W: http://jair.lab.fi.uva.es/~migojed/
N: Miguel Ojeda
E: ojeda@kernel.org
W: https://ojeda.dev
D: Author of the ks0108, cfag12864b and cfag12864bfb auxiliary display drivers.
D: Maintainer of the auxiliary display drivers tree (drivers/auxdisplay/*)
S: C/ Mieses 20, 9-B
S: Valladolid 47009
S: Spain
N: Peter Oruba

19
Documentation/ABI/stable/sysfs-bus-fsl-mc Normal file
View File

@ -0,0 +1,19 @@
What: /sys/bus/fsl-mc/rescan
Date: January 2021
KernelVersion: 5.12
Contact: Ioana Ciornei <ioana.ciornei@nxp.com>
Description: Writing a non-zero value to this attribute will
force a rescan of fsl-mc bus in the system and
synchronize the objects under fsl-mc bus and the
Management Complex firmware.
Users: Userspace drivers and management tools
What: /sys/bus/fsl-mc/autorescan
Date: January 2021
KernelVersion: 5.12
Contact: Ioana Ciornei <ioana.ciornei@nxp.com>
Description: Writing a zero value to this attribute will
disable the DPRC IRQs on which automatic rescan
of the fsl-mc bus is performed. A non-zero value
will enable the DPRC IRQs.
Users: Userspace drivers and management tools

37
Documentation/ABI/stable/sysfs-driver-speakup
View File

@ -273,7 +273,7 @@ Description: In `/sys/accessibility/speakup` is a directory corresponding to
Below is a description of values and parameters for soft
synthesizer, which is currently the most commonly used.
What: /sys/accessibility/speakup/soft/caps_start
What: /sys/accessibility/speakup/<synth-name>/caps_start
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: This is the string that is sent to the synthesizer to cause it
@ -281,7 +281,7 @@ Description: This is the string that is sent to the synthesizer to cause it
and most others, this causes the pitch of the voice to rise
above the currently set pitch.
What: /sys/accessibility/speakup/soft/caps_stop
What: /sys/accessibility/speakup/<synth-name>/caps_stop
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: This is the string sent to the synthesizer to cause it to stop
@ -290,12 +290,12 @@ Description: This is the string sent to the synthesizer to cause it to stop
down to the
currently set pitch.
What: /sys/accessibility/speakup/soft/delay_time
What: /sys/accessibility/speakup/<synth-name>/delay_time
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: TODO:
What: /sys/accessibility/speakup/soft/direct
What: /sys/accessibility/speakup/<synth-name>/direct
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Controls if punctuation is spoken by speakup, or by the
@ -306,36 +306,43 @@ Description: Controls if punctuation is spoken by speakup, or by the
than". Zero lets speakup speak the punctuation. One lets the
synthesizer itself speak punctuation.
What: /sys/accessibility/speakup/soft/freq
What: /sys/accessibility/speakup/<synth-name>/freq
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Gets or sets the frequency of the speech synthesizer. Range is
0-9.
What: /sys/accessibility/speakup/soft/full_time
What: /sys/accessibility/speakup/<synth-name>/flush_time
KernelVersion: 5.12
Contact: speakup@linux-speakup.org
Description: Gets or sets the timeout to wait for the synthesizer flush to
complete. This can be used when the cable gets faulty and flush
notifications are getting lost.
What: /sys/accessibility/speakup/<synth-name>/full_time
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: TODO:
What: /sys/accessibility/speakup/soft/jiffy_delta
What: /sys/accessibility/speakup/<synth-name>/jiffy_delta
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: This controls how many jiffys the kernel gives to the
synthesizer. Setting this too high can make a system unstable,
or even crash it.
What: /sys/accessibility/speakup/soft/pitch
What: /sys/accessibility/speakup/<synth-name>/pitch
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Gets or sets the pitch of the synthesizer. The range is 0-9.
What: /sys/accessibility/speakup/soft/inflection
What: /sys/accessibility/speakup/<synth-name>/inflection
KernelVersion: 5.8
Contact: speakup@linux-speakup.org
Description: Gets or sets the inflection of the synthesizer, i.e. the pitch
range. The range is 0-9.
What: /sys/accessibility/speakup/soft/punct
What: /sys/accessibility/speakup/<synth-name>/punct
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Gets or sets the amount of punctuation spoken by the
@ -343,13 +350,13 @@ Description: Gets or sets the amount of punctuation spoken by the
TODO: How is this related to speakup's punc_level, or
reading_punc.
What: /sys/accessibility/speakup/soft/rate
What: /sys/accessibility/speakup/<synth-name>/rate
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Gets or sets the rate of the synthesizer. Range is from zero
slowest, to nine fastest.
What: /sys/accessibility/speakup/soft/tone
What: /sys/accessibility/speakup/<synth-name>/tone
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Gets or sets the tone of the speech synthesizer. The range for
@ -357,12 +364,12 @@ Description: Gets or sets the tone of the speech synthesizer. The range for
difference if using espeak and the espeakup connector.
TODO: does espeakup support different tonalities?
What: /sys/accessibility/speakup/soft/trigger_time
What: /sys/accessibility/speakup/<synth-name>/trigger_time
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: TODO:
What: /sys/accessibility/speakup/soft/voice
What: /sys/accessibility/speakup/<synth-name>/voice
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Gets or sets the voice used by the synthesizer if the
@ -371,7 +378,7 @@ Description: Gets or sets the voice used by the synthesizer if the
voices, this parameter will not set the voice when the espeakup
connector is used between speakup and espeak.
What: /sys/accessibility/speakup/soft/vol
What: /sys/accessibility/speakup/<synth-name>/vol
KernelVersion: 2.6
Contact: speakup@linux-speakup.org
Description: Gets or sets the volume of the speech synthesizer. Range is 0-9,

50
Documentation/ABI/testing/debugfs-driver-habanalabs
View File

@ -1,7 +1,7 @@
What: /sys/kernel/debug/habanalabs/hl<n>/addr
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets the device address to be used for read or write through
PCI bar, or the device VA of a host mapped memory to be read or
written directly from the host. The latter option is allowed
@ -11,7 +11,7 @@ Description: Sets the device address to be used for read or write through
What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate
Date: May 2020
KernelVersion: 5.8
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allow the root user to disable/enable in runtime the clock
gating mechanism in Gaudi. Due to how Gaudi is built, the
clock gating needs to be disabled in order to access the
@ -34,28 +34,28 @@ Description: Allow the root user to disable/enable in runtime the clock
What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently allocated
command buffers
What: /sys/kernel/debug/habanalabs/hl<n>/command_submission
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently active
command submissions
What: /sys/kernel/debug/habanalabs/hl<n>/command_submission_jobs
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays a list with detailed information about each JOB (CB) of
each active command submission
What: /sys/kernel/debug/habanalabs/hl<n>/data32
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the root user to read or write directly through the
device's PCI bar. Writing to this file generates a write
transaction while reading from the file generates a read
@ -70,7 +70,7 @@ Description: Allows the root user to read or write directly through the
What: /sys/kernel/debug/habanalabs/hl<n>/data64
Date: Jan 2020
KernelVersion: 5.6
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the root user to read or write 64 bit data directly
through the device's PCI bar. Writing to this file generates a
write transaction while reading from the file generates a read
@ -85,7 +85,7 @@ Description: Allows the root user to read or write 64 bit data directly
What: /sys/kernel/debug/habanalabs/hl<n>/device
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Enables the root user to set the device to specific state.
Valid values are "disable", "enable", "suspend", "resume".
User can read this property to see the valid values
@ -93,28 +93,28 @@ Description: Enables the root user to set the device to specific state.
What: /sys/kernel/debug/habanalabs/hl<n>/engines
Date: Jul 2019
KernelVersion: 5.3
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the status registers values of the device engines and
their derived idle status
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_addr
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets I2C device address for I2C transaction that is generated
by the device's CPU
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets I2C bus address for I2C transaction that is generated by
the device's CPU
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Triggers an I2C transaction that is generated by the device's
CPU. Writing to this file generates a write transaction while
reading from the file generates a read transcation
@ -122,32 +122,32 @@ Description: Triggers an I2C transaction that is generated by the device's
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets I2C register id for I2C transaction that is generated by
the device's CPU
What: /sys/kernel/debug/habanalabs/hl<n>/led0
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets the state of the first S/W led on the device
What: /sys/kernel/debug/habanalabs/hl<n>/led1
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets the state of the second S/W led on the device
What: /sys/kernel/debug/habanalabs/hl<n>/led2
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets the state of the third S/W led on the device
What: /sys/kernel/debug/habanalabs/hl<n>/mmu
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the hop values and physical address for a given ASID
and virtual address. The user should write the ASID and VA into
the file and then read the file to get the result.
@ -157,14 +157,14 @@ Description: Displays the hop values and physical address for a given ASID
What: /sys/kernel/debug/habanalabs/hl<n>/set_power_state
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets the PCI power state. Valid values are "1" for D0 and "2"
for D3Hot
What: /sys/kernel/debug/habanalabs/hl<n>/userptr
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently user
pointers (user virtual addresses) that are pinned and mapped
to DMA addresses
@ -172,13 +172,21 @@ Description: Displays a list with information about the currently user
What: /sys/kernel/debug/habanalabs/hl<n>/vm
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays a list with information about all the active virtual
address mappings per ASID
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
Date: Mar 2020
KernelVersion: 5.6
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Sets the stop-on_error option for the device engines. Value of
"0" is for disable, otherwise enable.
What: /sys/kernel/debug/habanalabs/hl<n>/dump_security_violations
Date: Jan 2021
KernelVersion: 5.12
Contact: ogabbay@kernel.org
Description: Dumps all security violations to dmesg. This will also ack
all security violations meanings those violations will not be
dumped next time user calls this API

2
Documentation/ABI/testing/ima_policy
View File

@ -29,7 +29,7 @@ Description:
option: [[appraise_type=]] [template=] [permit_directio]
[appraise_flag=] [keyrings=]
base:
func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK]MODULE_CHECK]
func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]

8
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
View File

@ -371,6 +371,14 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (Read) Print the content of the Device ID Register
(0xFC8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevarch
Date: January 2021
KernelVersion: 5.12
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (Read) Print the content of the Device Architecture Register
(offset 0xFBC). The value is taken directly read
from the HW.
What: /sys/bus/coresight/devices/etm<N>/mgmt/trcdevtype
Date: April 2015
KernelVersion: 4.01

26
Documentation/ABI/testing/sysfs-bus-cxl Normal file
View File

@ -0,0 +1,26 @@
What: /sys/bus/cxl/devices/memX/firmware_version
Date: December, 2020
KernelVersion: v5.12
Contact: linux-cxl@vger.kernel.org
Description:
(RO) "FW Revision" string as reported by the Identify
Memory Device Output Payload in the CXL-2.0
specification.
What: /sys/bus/cxl/devices/memX/ram/size
Date: December, 2020
KernelVersion: v5.12
Contact: linux-cxl@vger.kernel.org
Description:
(RO) "Volatile Only Capacity" as bytes. Represents the
identically named field in the Identify Memory Device Output
Payload in the CXL-2.0 specification.
What: /sys/bus/cxl/devices/memX/pmem/size
Date: December, 2020
KernelVersion: v5.12
Contact: linux-cxl@vger.kernel.org
Description:
(RO) "Persistent Only Capacity" as bytes. Represents the
identically named field in the Identify Memory Device Output
Payload in the CXL-2.0 specification.

25
Documentation/ABI/testing/sysfs-bus-dfl-devices-emif Normal file
View File

@ -0,0 +1,25 @@
What: /sys/bus/dfl/devices/dfl_dev.X/infX_cal_fail
Date: Oct 2020
KernelVersion: 5.12
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. It indicates if the calibration failed on this
memory interface. "1" for calibration failure, "0" for OK.
Format: %u
What: /sys/bus/dfl/devices/dfl_dev.X/infX_init_done
Date: Oct 2020
KernelVersion: 5.12
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. It indicates if the initialization completed on
this memory interface. "1" for initialization complete, "0"
for not yet.
Format: %u
What: /sys/bus/dfl/devices/dfl_dev.X/infX_clear
Date: Oct 2020
KernelVersion: 5.12
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Write-only. Writing "1" to this file will zero out all memory
data in this memory interface. Writing of other values is
invalid.
Format: %u

47
Documentation/ABI/testing/sysfs-bus-dfl-devices-n3000-nios Normal file
View File

@ -0,0 +1,47 @@
What: /sys/bus/dfl/devices/dfl_dev.X/fec_mode
Date: Oct 2020
KernelVersion: 5.12
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. Returns the FEC mode of the 25G links of the
ethernet retimers configured by Nios firmware. "rs" for Reed
Solomon FEC, "kr" for Fire Code FEC, "no" for NO FEC.
"not supported" if the FEC mode setting is not supported, this
happens when the Nios firmware version major < 3, or no link is
configured to 25G.
Format: string
What: /sys/bus/dfl/devices/dfl_dev.X/retimer_A_mode
Date: Oct 2020
KernelVersion: 5.12
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. Returns the enumeration value of the working mode of
the retimer A configured by the Nios firmware. The value is
read out from shared registers filled by the Nios firmware. Now
the values could be:
- "0": Reset
- "1": 4x10G
- "2": 4x25G
- "3": 2x25G
- "4": 2x25G+2x10G
- "5": 1x25G
If the Nios firmware is updated in future to support more
retimer modes, more enumeration value is expected.
Format: 0x%x
What: /sys/bus/dfl/devices/dfl_dev.X/retimer_B_mode
Date: Oct 2020
KernelVersion: 5.12
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. Returns the enumeration value of the working mode of
the retimer B configured by the Nios firmware. The value format
is the same as retimer_A_mode.
What: /sys/bus/dfl/devices/dfl_dev.X/nios_fw_version
Date: Oct 2020
KernelVersion: 5.12
Contact: Xu Yilun <yilun.xu@intel.com>
Description: Read-only. Returns the version of the Nios firmware in the
FPGA. Its format is "major.minor.patch".
Format: %x.%x.%x

24
Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic Normal file
View File

@ -0,0 +1,24 @@
What: /sys/devices/pci0000:00/*/QEMU0001:00/capability
Date: Jan 2021
Contact: zhenwei pi <pizhenwei@bytedance.com>
Description:
Read-only attribute. Capabilities of pvpanic device which
are supported by QEMU.
Format: %x.
Detailed bit definition refers to section <Bit Definition>
from pvpanic device specification:
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
What: /sys/devices/pci0000:00/*/QEMU0001:00/events
Date: Jan 2021
Contact: zhenwei pi <pizhenwei@bytedance.com>
Description:
RW attribute. Set/get which features in-use. This attribute
is used to enable/disable feature(s) of pvpanic device.
Notice that this value should be a subset of capability.
Format: %x.
Also refer to pvpanic device specification.

56
Documentation/ABI/testing/sysfs-devices-memory
View File

@ -13,21 +13,22 @@ What: /sys/devices/system/memory/memoryX/removable
Date: June 2008
Contact: Badari Pulavarty <pbadari@us.ibm.com>
Description:
The file /sys/devices/system/memory/memoryX/removable
indicates whether this memory block is removable or not.
This is useful for a user-level agent to determine
identify removable sections of the memory before attempting
potentially expensive hot-remove memory operation
The file /sys/devices/system/memory/memoryX/removable is a
legacy interface used to indicated whether a memory block is
likely to be offlineable or not. Newer kernel versions return
"1" if and only if the kernel supports memory offlining.
Users: hotplug memory remove tools
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
lsmem/chmem part of util-linux
What: /sys/devices/system/memory/memoryX/phys_device
Date: September 2008
Contact: Badari Pulavarty <pbadari@us.ibm.com>
Description:
The file /sys/devices/system/memory/memoryX/phys_device
is read-only and is designed to show the name of physical
memory device. Implementation is currently incomplete.
is read-only; it is a legacy interface only ever used on s390x
to expose the covered storage increment.
Users: Legacy s390-tools lsmem/chmem
What: /sys/devices/system/memory/memoryX/phys_index
Date: September 2008
@ -43,23 +44,25 @@ Date: September 2008
Contact: Badari Pulavarty <pbadari@us.ibm.com>
Description:
The file /sys/devices/system/memory/memoryX/state
is read-write. When read, its contents show the
online/offline state of the memory section. When written,
root can toggle the the online/offline state of a removable
memory section (see removable file description above)
using the following commands::
is read-write. When read, it returns the online/offline
state of the memory block. When written, root can toggle
the online/offline state of a memory block using the following
commands::
# echo online > /sys/devices/system/memory/memoryX/state
# echo offline > /sys/devices/system/memory/memoryX/state
For example, if /sys/devices/system/memory/memory22/removable
contains a value of 1 and
/sys/devices/system/memory/memory22/state contains the
string "online" the following command can be executed by
by root to offline that section::
# echo offline > /sys/devices/system/memory/memory22/state
On newer kernel versions, advanced states can be specified
when onlining to select a target zone: "online_movable"
selects the movable zone. "online_kernel" selects the
applicable kernel zone (DMA, DMA32, or Normal). However,
after successfully setting one of the advanced states,
reading the file will return "online"; the zone information
can be obtained via "valid_zones" instead.
While onlining is unlikely to fail, there are no guarantees
that offlining will succeed. Offlining is more likely to
succeed if "valid_zones" indicates "Movable".
Users: hotplug memory remove tools
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
@ -69,8 +72,19 @@ Date: July 2014
Contact: Zhang Zhen <zhenzhang.zhang@huawei.com>
Description:
The file /sys/devices/system/memory/memoryX/valid_zones is
read-only and is designed to show which zone this memory
block can be onlined to.
read-only.
For online memory blocks, it returns in which zone memory
provided by a memory block is managed. If multiple zones
apply (not applicable for hotplugged memory), "None" is returned
and the memory block cannot be offlined.
For offline memory blocks, it returns by which zone memory
provided by a memory block can be managed when onlining.
The first returned zone ("default") will be used when setting
the state of an offline memory block to "online". Only one of
the kernel zones (DMA, DMA32, Normal) is applicable for a single
memory block.
What: /sys/devices/system/memoryX/nodeY
Date: October 2009

41
Documentation/ABI/testing/sysfs-devices-xenbus Normal file
View File

@ -0,0 +1,41 @@
What: /sys/devices/*/xenbus/event_channels
Date: February 2021
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
Description:
Number of Xen event channels associated with a kernel based
paravirtualized device frontend or backend.
What: /sys/devices/*/xenbus/events
Date: February 2021
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
Description:
Total number of Xen events received for a Xen pv device
frontend or backend.
What: /sys/devices/*/xenbus/jiffies_eoi_delayed
Date: February 2021
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
Description:
Summed up time in jiffies the EOI of an interrupt for a Xen
pv device has been delayed in order to avoid stalls due to
event storms. This value rising is a first sign for a rogue
other end of the pv device.
What: /sys/devices/*/xenbus/spurious_events
Date: February 2021
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
Description:
Number of events received for a Xen pv device which did not
require any action. Too many spurious events in a row will
trigger delayed EOI processing.
What: /sys/devices/*/xenbus/spurious_threshold
Date: February 2021
Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
Description:
Controls the tolerated number of subsequent spurious events
before delayed EOI processing is triggered for a Xen pv
device. Default is 1. This can be modified in case the other
end of the pv device is issuing spurious events on a regular
basis and is known not to be malicious on purpose. Raising
the value for such cases can improve pv device performance.

58
Documentation/ABI/testing/sysfs-driver-habanalabs
View File

@ -1,7 +1,7 @@
What: /sys/class/habanalabs/hl<n>/armcp_kernel_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the Linux kernel running on the device's CPU.
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_kernel_ver
@ -9,7 +9,7 @@ Description: Version of the Linux kernel running on the device's CPU.
What: /sys/class/habanalabs/hl<n>/armcp_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the application running on the device's CPU
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_ver
@ -17,7 +17,7 @@ Description: Version of the application running on the device's CPU
What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz
Date: Jun 2019
KernelVersion: not yet upstreamed
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum clock frequency, in MHz.
The device clock might be set to lower value than the maximum.
The user should read the clk_cur_freq_mhz to see the actual
@ -27,52 +27,52 @@ Description: Allows the user to set the maximum clock frequency, in MHz.
What: /sys/class/habanalabs/hl<n>/clk_cur_freq_mhz
Date: Jun 2019
KernelVersion: not yet upstreamed
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the current frequency, in MHz, of the device clock.
This property is valid only for the Gaudi ASIC family
What: /sys/class/habanalabs/hl<n>/cpld_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the Device's CPLD F/W
What: /sys/class/habanalabs/hl<n>/cpucp_kernel_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the Linux kernel running on the device's CPU
What: /sys/class/habanalabs/hl<n>/cpucp_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the application running on the device's CPU
What: /sys/class/habanalabs/hl<n>/device_type
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the code name of the device according to its type.
The supported values are: "GOYA"
What: /sys/class/habanalabs/hl<n>/eeprom
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: A binary file attribute that contains the contents of the
on-board EEPROM
What: /sys/class/habanalabs/hl<n>/fuse_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the device's version from the eFuse
What: /sys/class/habanalabs/hl<n>/hard_reset
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Interface to trigger a hard-reset operation for the device.
Hard-reset will reset ALL internal components of the device
except for the PCI interface and the internal PLLs
@ -80,14 +80,14 @@ Description: Interface to trigger a hard-reset operation for the device.
What: /sys/class/habanalabs/hl<n>/hard_reset_cnt
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays how many times the device have undergone a hard-reset
operation since the driver was loaded
What: /sys/class/habanalabs/hl<n>/high_pll
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum clock frequency for MME, TPC
and IC when the power management profile is set to "automatic".
This property is valid only for the Goya ASIC family
@ -95,7 +95,7 @@ Description: Allows the user to set the maximum clock frequency for MME, TPC
What: /sys/class/habanalabs/hl<n>/ic_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum clock frequency, in Hz, of
the Interconnect fabric. Writes to this parameter affect the
device only when the power management profile is set to "manual"
@ -107,27 +107,27 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
What: /sys/class/habanalabs/hl<n>/ic_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the Interconnect
fabric. This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/infineon_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the Device's power supply F/W code
What: /sys/class/habanalabs/hl<n>/max_power
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum power consumption of the
device in milliwatts.
What: /sys/class/habanalabs/hl<n>/mme_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum clock frequency, in Hz, of
the MME compute engine. Writes to this parameter affect the
device only when the power management profile is set to "manual"
@ -139,21 +139,21 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
What: /sys/class/habanalabs/hl<n>/mme_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the MME compute
engine. This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/pci_addr
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the PCI address of the device. This is needed so the
user would be able to open a device based on its PCI address
What: /sys/class/habanalabs/hl<n>/pm_mng_profile
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Power management profile. Values are "auto", "manual". In "auto"
mode, the driver will set the maximum clock frequency to a high
value when a user-space process opens the device's file (unless
@ -167,13 +167,13 @@ Description: Power management profile. Values are "auto", "manual". In "auto"
What: /sys/class/habanalabs/hl<n>/preboot_btl_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the device's preboot F/W code
What: /sys/class/habanalabs/hl<n>/soft_reset
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Interface to trigger a soft-reset operation for the device.
Soft-reset will reset only the compute and DMA engines of the
device
@ -181,26 +181,26 @@ Description: Interface to trigger a soft-reset operation for the device.
What: /sys/class/habanalabs/hl<n>/soft_reset_cnt
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays how many times the device have undergone a soft-reset
operation since the driver was loaded
What: /sys/class/habanalabs/hl<n>/status
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Status of the card: "Operational", "Malfunction", "In reset".
What: /sys/class/habanalabs/hl<n>/thermal_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the Device's thermal daemon
What: /sys/class/habanalabs/hl<n>/tpc_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum clock frequency, in Hz, of
the TPC compute engines. Writes to this parameter affect the
device only when the power management profile is set to "manual"
@ -212,12 +212,12 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
What: /sys/class/habanalabs/hl<n>/tpc_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the TPC compute
engines. This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/uboot_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: oded.gabbay@gmail.com
Contact: ogabbay@kernel.org
Description: Version of the u-boot running on the device's CPU

6
Documentation/ABI/testing/sysfs-driver-input-cros-ec-keyb Normal file
View File

@ -0,0 +1,6 @@
What: /sys/class/input/input(x)/device/function_row_physmap
Date: January 2021
Contact: Philip Chen <philipchen@chromium.org>
Description: A space separated list of scancodes for the top row keys,
ordered by the physical positions of the keys, from left
to right.

43
Documentation/ABI/testing/sysfs-firmware-acpi
View File

@ -1,3 +1,46 @@
What: /sys/firmware/acpi/fpdt/
Date: Jan 2021
Contact: Zhang Rui <rui.zhang@intel.com>
Description:
ACPI Firmware Performance Data Table (FPDT) provides
information for firmware performance data for system boot,
S3 suspend and S3 resume. This sysfs entry contains the
performance data retrieved from the FPDT.
boot:
firmware_start_ns: Timer value logged at the beginning
of firmware image execution. In nanoseconds.
bootloader_load_ns: Timer value logged just prior to
loading the OS boot loader into memory.
In nanoseconds.
bootloader_launch_ns: Timer value logged just prior to
launching the currently loaded OS boot loader
image. In nanoseconds.
exitbootservice_start_ns: Timer value logged at the
point when the OS loader calls the
ExitBootServices function for UEFI compatible
firmware. In nanoseconds.
exitbootservice_end_ns: Timer value logged at the point
just prior to the OS loader gaining control
back from the ExitBootServices function for
UEFI compatible firmware. In nanoseconds.
suspend:
suspend_start_ns: Timer value recorded at the previous
OS write to SLP_TYP upon entry to S3. In
nanoseconds.
suspend_end_ns: Timer value recorded at the previous
firmware write to SLP_TYP used to trigger
hardware entry to S3. In nanoseconds.
resume:
resume_count: A count of the number of S3 resume cycles
since the last full boot sequence.
resume_avg_ns: Average timer value of all resume cycles
logged since the last full boot sequence,
including the most recent resume. In nanoseconds.
resume_prev_ns: Timer recorded at the end of the previous
platform runtime firmware S3 resume, just prior to
handoff to the OS waking vector. In nanoseconds.
What: /sys/firmware/acpi/bgrt/
Date: January 2012
Contact: Matthew Garrett <mjg@redhat.com>

15
Documentation/ABI/testing/sysfs-firmware-sfi
View File

@ -1,15 +0,0 @@
What: /sys/firmware/sfi/tables/
Date: May 2010
Contact: Len Brown <lenb@kernel.org>
Description:
SFI defines a number of small static memory tables
so the kernel can get platform information from firmware.
The tables are defined in the latest SFI specification:
http://simplefirmware.org/documentation
While the tables are used by the kernel, user-space
can observe them this way::
# cd /sys/firmware/sfi/tables
# cat $TABLENAME > $TABLENAME.bin

2
Documentation/ABI/testing/sysfs-platform-kim
View File

@ -7,7 +7,7 @@ Description:
is connected. example: "/dev/ttyS0".
The device name flows down to architecture specific board
initialization file from the SFI/ATAGS bootloader
initialization file from the ATAGS bootloader
firmware. The name exposed is read from the user-space
dameon and opens the device when install is requested.

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

@ -5,13 +5,17 @@ Description: This file contains a space-separated list of profiles supported for
Drivers must use the following standard profile-names:
============ ============================================
low-power Low power consumption
cool Cooler operation
quiet Quieter operation
balanced Balance between low power consumption and performance
performance High performance operation
============ ============================================
==================== ========================================
low-power Low power consumption
cool Cooler operation
quiet Quieter operation
balanced Balance between low power consumption
and performance
balanced-performance Balance between performance and low
power consumption with a slight bias
towards performance
performance High performance operation
==================== ========================================
Userspace may expect drivers to offer more than one of these
standard profile names.

38
Documentation/PCI/endpoint/function/binding/pci-ntb.rst Normal file
View File

@ -0,0 +1,38 @@
.. SPDX-License-Identifier: GPL-2.0
==========================
PCI NTB Endpoint Function
==========================
1) Create a subdirectory to pci_epf_ntb directory in configfs.
Standard EPF Configurable Fields:
================ ===========================================================
vendorid should be 0x104c
deviceid should be 0xb00d for TI's J721E SoC
revid don't care
progif_code don't care
subclass_code should be 0x00
baseclass_code should be 0x5
cache_line_size don't care
subsys_vendor_id don't care
subsys_id don't care
interrupt_pin don't care
msi_interrupts don't care
msix_interrupts don't care
================ ===========================================================
2) Create a subdirectory to directory created in 1
NTB EPF specific configurable fields:
================ ===========================================================
db_count Number of doorbells; default = 4
mw1 size of memory window1
mw2 size of memory window2
mw3 size of memory window3
mw4 size of memory window4
num_mws Number of memory windows; max = 4
spad_count Number of scratchpad registers; default = 64
================ ===========================================================

3
Documentation/PCI/endpoint/index.rst
View File

@ -11,5 +11,8 @@ PCI Endpoint Framework
pci-endpoint-cfs
pci-test-function
pci-test-howto
pci-ntb-function
pci-ntb-howto
function/binding/pci-test
function/binding/pci-ntb

10
Documentation/PCI/endpoint/pci-endpoint-cfs.rst
View File

@ -68,6 +68,16 @@ created)
... subsys_vendor_id
... subsys_id
... interrupt_pin
... primary/
... <Symlink EPC Device1>/
... secondary/
... <Symlink EPC Device2>/
If an EPF device has to be associated with 2 EPCs (like in the case of
Non-transparent bridge), symlink of endpoint controller connected to primary
interface should be added in 'primary' directory and symlink of endpoint
controller connected to secondary interface should be added in 'secondary'
directory.
EPC Device
==========

348
Documentation/PCI/endpoint/pci-ntb-function.rst Normal file
View File

@ -0,0 +1,348 @@
.. SPDX-License-Identifier: GPL-2.0
=================
PCI NTB Function
=================
:Author: Kishon Vijay Abraham I <kishon@ti.com>
PCI Non-Transparent Bridges (NTB) allow two host systems to communicate
with each other by exposing each host as a device to the other host.
NTBs typically support the ability to generate interrupts on the remote
machine, expose memory ranges as BARs, and perform DMA. They also support
scratchpads, which are areas of memory within the NTB that are accessible
from both machines.
PCI NTB Function allows two different systems (or hosts) to communicate
with each other by configuring the endpoint instances in such a way that
transactions from one system are routed to the other system.
In the below diagram, PCI NTB function configures the SoC with multiple
PCI Endpoint (EP) instances in such a way that transactions from one EP
controller are routed to the other EP controller. Once PCI NTB function
configures the SoC with multiple EP instances, HOST1 and HOST2 can
communicate with each other using SoC as a bridge.
.. code-block:: text
+-------------+ +-------------+
| | | |
| HOST1 | | HOST2 |
| | | |
+------^------+ +------^------+
| |
| |
+---------|-------------------------------------------------|---------+
| +------v------+ +------v------+ |
| | | | | |
| | EP | | EP | |
| | CONTROLLER1 | | CONTROLLER2 | |
| | <-----------------------------------> | |
| | | | | |
| | | | | |
| | | SoC With Multiple EP Instances | | |
| | | (Configured using NTB Function) | | |
| +-------------+ +-------------+ |
+---------------------------------------------------------------------+
Constructs used for Implementing NTB
====================================
1) Config Region
2) Self Scratchpad Registers
3) Peer Scratchpad Registers
4) Doorbell (DB) Registers
5) Memory Window (MW)
Config Region:
--------------
Config Region is a construct that is specific to NTB implemented using NTB
Endpoint Function Driver. The host and endpoint side NTB function driver will
exchange information with each other using this region. Config Region has
Control/Status Registers for configuring the Endpoint Controller. Host can
write into this region for configuring the outbound Address Translation Unit
(ATU) and to indicate the link status. Endpoint can indicate the status of
commands issued by host in this region. Endpoint can also indicate the
scratchpad offset and number of memory windows to the host using this region.
The format of Config Region is given below. All the fields here are 32 bits.
.. code-block:: text
+------------------------+
| COMMAND |
+------------------------+
| ARGUMENT |
+------------------------+
| STATUS |
+------------------------+
| TOPOLOGY |
+------------------------+
| ADDRESS (LOWER 32) |
+------------------------+
| ADDRESS (UPPER 32) |
+------------------------+
| SIZE |
+------------------------+
| NO OF MEMORY WINDOW |
+------------------------+
| MEMORY WINDOW1 OFFSET |
+------------------------+
| SPAD OFFSET |
+------------------------+
| SPAD COUNT |
+------------------------+
| DB ENTRY SIZE |
+------------------------+
| DB DATA |
+------------------------+
| : |
+------------------------+
| : |
+------------------------+
| DB DATA |
+------------------------+
COMMAND:
NTB function supports three commands:
CMD_CONFIGURE_DOORBELL (0x1): Command to configure doorbell. Before
invoking this command, the host should allocate and initialize
MSI/MSI-X vectors (i.e., initialize the MSI/MSI-X Capability in the
Endpoint). The endpoint on receiving this command will configure
the outbound ATU such that transactions to Doorbell BAR will be routed
to the MSI/MSI-X address programmed by the host. The ARGUMENT
register should be populated with number of DBs to configure (in the
lower 16 bits) and if MSI or MSI-X should be configured (BIT 16).
CMD_CONFIGURE_MW (0x2): Command to configure memory window (MW). The
host invokes this command after allocating a buffer that can be
accessed by remote host. The allocated address should be programmed
in the ADDRESS register (64 bit), the size should be programmed in
the SIZE register and the memory window index should be programmed
in the ARGUMENT register. The endpoint on receiving this command
will configure the outbound ATU such that transactions to MW BAR
are routed to the address provided by the host.
CMD_LINK_UP (0x3): Command to indicate an NTB application is
bound to the EP device on the host side. Once the endpoint
receives this command from both the hosts, the endpoint will
raise a LINK_UP event to both the hosts to indicate the host
NTB applications can start communicating with each other.
ARGUMENT:
The value of this register is based on the commands issued in
command register. See COMMAND section for more information.
TOPOLOGY:
Set to NTB_TOPO_B2B_USD for Primary interface
Set to NTB_TOPO_B2B_DSD for Secondary interface
ADDRESS/SIZE:
Address and Size to be used while configuring the memory window.
See "CMD_CONFIGURE_MW" for more info.
MEMORY WINDOW1 OFFSET:
Memory Window 1 and Doorbell registers are packed together in the
same BAR. The initial portion of the region will have doorbell
registers and the latter portion of the region is for memory window 1.
This register will specify the offset of the memory window 1.
NO OF MEMORY WINDOW:
Specifies the number of memory windows supported by the NTB device.
SPAD OFFSET:
Self scratchpad region and config region are packed together in the
same BAR. The initial portion of the region will have config region
and the latter portion of the region is for self scratchpad. This
register will specify the offset of the self scratchpad registers.
SPAD COUNT:
Specifies the number of scratchpad registers supported by the NTB
device.
DB ENTRY SIZE:
Used to determine the offset within the DB BAR that should be written
in order to raise doorbell. EPF NTB can use either MSI or MSI-X to
ring doorbell (MSI-X support will be added later). MSI uses same
address for all the interrupts and MSI-X can provide different
addresses for different interrupts. The MSI/MSI-X address is provided
by the host and the address it gives is based on the MSI/MSI-X
implementation supported by the host. For instance, ARM platform
using GIC ITS will have the same MSI-X address for all the interrupts.
In order to support all the combinations and use the same mechanism
for both MSI and MSI-X, EPF NTB allocates a separate region in the
Outbound Address Space for each of the interrupts. This region will
be mapped to the MSI/MSI-X address provided by the host. If a host
provides the same address for all the interrupts, all the regions
will be translated to the same address. If a host provides different
addresses, the regions will be translated to different addresses. This
will ensure there is no difference while raising the doorbell.
DB DATA:
EPF NTB supports 32 interrupts, so there are 32 DB DATA registers.
This holds the MSI/MSI-X data that has to be written to MSI address
for raising doorbell interrupt. This will be populated by EPF NTB
while invoking CMD_CONFIGURE_DOORBELL.
Scratchpad Registers:
---------------------
Each host has its own register space allocated in the memory of NTB endpoint
controller. They are both readable and writable from both sides of the bridge.
They are used by applications built over NTB and can be used to pass control
and status information between both sides of a device.
Scratchpad registers has 2 parts
1) Self Scratchpad: Host's own register space
2) Peer Scratchpad: Remote host's register space.
Doorbell Registers:
-------------------
Doorbell Registers are used by the hosts to interrupt each other.
Memory Window:
--------------
Actual transfer of data between the two hosts will happen using the
memory window.
Modeling Constructs:
====================
There are 5 or more distinct regions (config, self scratchpad, peer
scratchpad, doorbell, one or more memory windows) to be modeled to achieve
NTB functionality. At least one memory window is required while more than
one is permitted. All these regions should be mapped to BARs for hosts to
access these regions.
If one 32-bit BAR is allocated for each of these regions, the scheme would
look like this:
====== ===============
BAR NO CONSTRUCTS USED
====== ===============
BAR0 Config Region
BAR1 Self Scratchpad
BAR2 Peer Scratchpad
BAR3 Doorbell
BAR4 Memory Window 1
BAR5 Memory Window 2
====== ===============
However if we allocate a separate BAR for each of the regions, there would not
be enough BARs for all the regions in a platform that supports only 64-bit
BARs.
In order to be supported by most of the platforms, the regions should be
packed and mapped to BARs in a way that provides NTB functionality and
also makes sure the host doesn't access any region that it is not supposed
to.
The following scheme is used in EPF NTB Function:
====== ===============================
BAR NO CONSTRUCTS USED
====== ===============================
BAR0 Config Region + Self Scratchpad
BAR1 Peer Scratchpad
BAR2 Doorbell + Memory Window 1
BAR3 Memory Window 2
BAR4 Memory Window 3
BAR5 Memory Window 4
====== ===============================
With this scheme, for the basic NTB functionality 3 BARs should be sufficient.
Modeling Config/Scratchpad Region:
----------------------------------
.. code-block:: text
+-----------------+------->+------------------+ +-----------------+
| BAR0 | | CONFIG REGION | | BAR0 |
+-----------------+----+ +------------------+<-------+-----------------+
| BAR1 | | |SCRATCHPAD REGION | | BAR1 |
+-----------------+ +-->+------------------+<-------+-----------------+
| BAR2 | Local Memory | BAR2 |
+-----------------+ +-----------------+
| BAR3 | | BAR3 |
+-----------------+ +-----------------+
| BAR4 | | BAR4 |
+-----------------+ +-----------------+
| BAR5 | | BAR5 |
+-----------------+ +-----------------+
EP CONTROLLER 1 EP CONTROLLER 2
Above diagram shows Config region + Scratchpad region for HOST1 (connected to
EP controller 1) allocated in local memory. The HOST1 can access the config
region and scratchpad region (self scratchpad) using BAR0 of EP controller 1.
The peer host (HOST2 connected to EP controller 2) can also access this
scratchpad region (peer scratchpad) using BAR1 of EP controller 2. This
diagram shows the case where Config region and Scratchpad regions are allocated
for HOST1, however the same is applicable for HOST2.
Modeling Doorbell/Memory Window 1:
----------------------------------
.. code-block:: text
+-----------------+ +----->+----------------+-----------+-----------------+
| BAR0 | | | Doorbell 1 +-----------> MSI-X ADDRESS 1 |
+-----------------+ | +----------------+ +-----------------+
| BAR1 | | | Doorbell 2 +---------+ | |
+-----------------+----+ +----------------+ | | |
| BAR2 | | Doorbell 3 +-------+ | +-----------------+
+-----------------+----+ +----------------+ | +-> MSI-X ADDRESS 2 |
| BAR3 | | | Doorbell 4 +-----+ | +-----------------+
+-----------------+ | |----------------+ | | | |
| BAR4 | | | | | | +-----------------+
+-----------------+ | | MW1 +---+ | +-->+ MSI-X ADDRESS 3||
| BAR5 | | | | | | +-----------------+
+-----------------+ +----->-----------------+ | | | |
EP CONTROLLER 1 | | | | +-----------------+
| | | +---->+ MSI-X ADDRESS 4 |
+----------------+ | +-----------------+
EP CONTROLLER 2 | | |
(OB SPACE) | | |
+-------> MW1 |
| |
| |
+-----------------+
| |
| |
| |
| |
| |
+-----------------+
PCI Address Space
(Managed by HOST2)
Above diagram shows how the doorbell and memory window 1 is mapped so that
HOST1 can raise doorbell interrupt on HOST2 and also how HOST1 can access
buffers exposed by HOST2 using memory window1 (MW1). Here doorbell and
memory window 1 regions are allocated in EP controller 2 outbound (OB) address
space. Allocating and configuring BARs for doorbell and memory window1
is done during the initialization phase of NTB endpoint function driver.
Mapping from EP controller 2 OB space to PCI address space is done when HOST2
sends CMD_CONFIGURE_MW/CMD_CONFIGURE_DOORBELL.
Modeling Optional Memory Windows:
---------------------------------
This is modeled the same was as MW1 but each of the additional memory windows
is mapped to separate BARs.

161
Documentation/PCI/endpoint/pci-ntb-howto.rst Normal file
View File

@ -0,0 +1,161 @@
.. SPDX-License-Identifier: GPL-2.0
===================================================================
PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
===================================================================
:Author: Kishon Vijay Abraham I <kishon@ti.com>
This document is a guide to help users use pci-epf-ntb function driver
and ntb_hw_epf host driver for NTB functionality. The list of steps to
be followed in the host side and EP side is given below. For the hardware
configuration and internals of NTB using configurable endpoints see
Documentation/PCI/endpoint/pci-ntb-function.rst
Endpoint Device
===============
Endpoint Controller Devices
---------------------------
For implementing NTB functionality at least two endpoint controller devices
are required.
To find the list of endpoint controller devices in the system::
# ls /sys/class/pci_epc/
2900000.pcie-ep 2910000.pcie-ep
If PCI_ENDPOINT_CONFIGFS is enabled::
# ls /sys/kernel/config/pci_ep/controllers
2900000.pcie-ep 2910000.pcie-ep
Endpoint Function Drivers
-------------------------
To find the list of endpoint function drivers in the system::
# ls /sys/bus/pci-epf/drivers
pci_epf_ntb pci_epf_ntb
If PCI_ENDPOINT_CONFIGFS is enabled::
# ls /sys/kernel/config/pci_ep/functions
pci_epf_ntb pci_epf_ntb
Creating pci-epf-ntb Device
----------------------------
PCI endpoint function device can be created using the configfs. To create
pci-epf-ntb device, the following commands can be used::
# mount -t configfs none /sys/kernel/config
# cd /sys/kernel/config/pci_ep/
# mkdir functions/pci_epf_ntb/func1
The "mkdir func1" above creates the pci-epf-ntb function device that will
be probed by pci_epf_ntb driver.
The PCI endpoint framework populates the directory with the following
configurable fields::
# ls functions/pci_epf_ntb/func1
baseclass_code deviceid msi_interrupts pci-epf-ntb.0
progif_code secondary subsys_id vendorid
cache_line_size interrupt_pin msix_interrupts primary
revid subclass_code subsys_vendor_id
The PCI endpoint function driver populates these entries with default values
when the device is bound to the driver. The pci-epf-ntb driver populates
vendorid with 0xffff and interrupt_pin with 0x0001::
# cat functions/pci_epf_ntb/func1/vendorid
0xffff
# cat functions/pci_epf_ntb/func1/interrupt_pin
0x0001
Configuring pci-epf-ntb Device
-------------------------------
The user can configure the pci-epf-ntb device using its configfs entry. In order
to change the vendorid and the deviceid, the following
commands can be used::
# echo 0x104c > functions/pci_epf_ntb/func1/vendorid
# echo 0xb00d > functions/pci_epf_ntb/func1/deviceid
In order to configure NTB specific attributes, a new sub-directory to func1
should be created::
# mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/
The NTB function driver will populate this directory with various attributes
that can be configured by the user::
# ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/
db_count mw1 mw2 mw3 mw4 num_mws
spad_count
A sample configuration for NTB function is given below::
# echo 4 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/db_count
# echo 128 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/spad_count
# echo 2 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/num_mws
# echo 0x100000 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw1
# echo 0x100000 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw2
Binding pci-epf-ntb Device to EP Controller
--------------------------------------------
NTB function device should be attached to two PCI endpoint controllers
connected to the two hosts. Use the 'primary' and 'secondary' entries
inside NTB function device to attach one PCI endpoint controller to
primary interface and the other PCI endpoint controller to the secondary
interface::
# ln -s controllers/2900000.pcie-ep/ functions/pci-epf-ntb/func1/primary
# ln -s controllers/2910000.pcie-ep/ functions/pci-epf-ntb/func1/secondary
Once the above step is completed, both the PCI endpoint controllers are ready to
establish a link with the host.
Start the Link
--------------
In order for the endpoint device to establish a link with the host, the _start_
field should be populated with '1'. For NTB, both the PCI endpoint controllers
should establish link with the host::
# echo 1 > controllers/2900000.pcie-ep/start
# echo 1 > controllers/2910000.pcie-ep/start
RootComplex Device
==================
lspci Output
------------
Note that the devices listed here correspond to the values populated in
"Creating pci-epf-ntb Device" section above::
# lspci
0000:00:00.0 PCI bridge: Texas Instruments Device b00d
0000:01:00.0 RAM memory: Texas Instruments Device b00d
Using ntb_hw_epf Device
-----------------------
The host side software follows the standard NTB software architecture in Linux.
All the existing client side NTB utilities like NTB Transport Client and NTB
Netdev, NTB Ping Pong Test Client and NTB Tool Test Client can be used with NTB
function device.
For more information on NTB see
:doc:`Non-Transparent Bridge <../../driver-api/ntb>`

2
Documentation/admin-guide/auxdisplay/cfag12864b.rst
View File

@ -3,7 +3,7 @@ cfag12864b LCD Driver Documentation
===================================
:License: GPLv2
:Author & Maintainer: Miguel Ojeda Sandonis
:Author & Maintainer: Miguel Ojeda <ojeda@kernel.org>
:Date: 2006-10-27

2
Documentation/admin-guide/auxdisplay/ks0108.rst
View File

@ -3,7 +3,7 @@ ks0108 LCD Controller Driver Documentation
==========================================
:License: GPLv2
:Author & Maintainer: Miguel Ojeda Sandonis
:Author & Maintainer: Miguel Ojeda <ojeda@kernel.org>
:Date: 2006-10-27

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

@ -1299,6 +1299,10 @@ PAGE_SIZE multiple when read back.
Amount of cached filesystem data that was modified and
is currently being written back to disk
swapcached
Amount of swap cached in memory. The swapcache is accounted
against both memory and swap usage.
anon_thp
Amount of memory used in anonymous mappings backed by
transparent hugepages
@ -2094,7 +2098,7 @@ If the program returns 0, the attempt fails with -EPERM, otherwise
it succeeds.
An example of BPF_CGROUP_DEVICE program may be found in the kernel
source tree in the tools/testing/selftests/bpf/dev_cgroup.c file.
source tree in the tools/testing/selftests/bpf/progs/dev_cgroup.c file.
RDMA

6
Documentation/admin-guide/cifs/authors.rst
View File

@ -5,10 +5,10 @@ Authors
Original Author
---------------
Steve French (sfrench@samba.org)
Steve French (smfrench@gmail.com, sfrench@samba.org)
The author wishes to express his appreciation and thanks to:
Andrew Tridgell (Samba team) for his early suggestions about smb/cifs VFS
Andrew Tridgell (Samba team) for his early suggestions about SMB/CIFS VFS
improvements. Thanks to IBM for allowing me time and test resources to pursue
this project, to Jim McDonough from IBM (and the Samba Team) for his help, to
the IBM Linux JFS team for explaining many esoteric Linux filesystem features.
@ -51,7 +51,7 @@ Patch Contributors
- Ronnie Sahlberg (for SMB3 xattr work, bug fixes, and lots of great work on compounding)
- Shirish Pargaonkar (for many ACL patches over the years)
- Sachin Prabhu (many bug fixes, including for reconnect, copy offload and security)
- Paulo Alcantara
- Paulo Alcantara (for some excellent work in DFS, and in booting from SMB3)
- Long Li (some great work on RDMA, SMB Direct)

5
Documentation/admin-guide/cifs/changes.rst
View File

@ -3,6 +3,7 @@ Changes
=======
See https://wiki.samba.org/index.php/LinuxCIFSKernel for summary
information (that may be easier to read than parsing the output of
"git log fs/cifs") about fixes/improvements to CIFS/SMB2/SMB3 support (changes
information about fixes/improvements to CIFS/SMB2/SMB3 support (changes
to cifs.ko module) by kernel version (and cifs internal module version).
This may be easier to read than parsing the output of "git log fs/cifs"
by release.

30
Documentation/admin-guide/cifs/introduction.rst
View File

@ -7,19 +7,19 @@ Introduction
protocol which was the successor to the Server Message Block
(SMB) protocol, the native file sharing mechanism for most early
PC operating systems. New and improved versions of CIFS are now
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1)
is strongly preferred over using older dialects like CIFS due to
security reasons. All modern dialects, including the most recent,
SMB3.1.1 are supported by the CIFS VFS module. The SMB3 protocol
is implemented and supported by all major file servers
such as all modern versions of Windows (including Windows 2016
Server), as well as by Samba (which provides excellent
CIFS/SMB2/SMB3 server support and tools for Linux and many other
operating systems). Apple systems also support SMB3 well, as
do most Network Attached Storage vendors, so this network
filesystem client can mount to a wide variety of systems.
It also supports mounting to the cloud (for example
Microsoft Azure), including the necessary security features.
called SMB2 and SMB3. Use of SMB3 (and later, including SMB3.1.1
the most current dialect) is strongly preferred over using older
dialects like CIFS due to security reasons. All modern dialects,
including the most recent, SMB3.1.1, are supported by the CIFS VFS
module. The SMB3 protocol is implemented and supported by all major
file servers such as Windows (including Windows 2019 Server), as
well as by Samba (which provides excellent CIFS/SMB2/SMB3 server
support and tools for Linux and many other operating systems).
Apple systems also support SMB3 well, as do most Network Attached
Storage vendors, so this network filesystem client can mount to a
wide variety of systems. It also supports mounting to the cloud
(for example Microsoft Azure), including the necessary security
features.
The intent of this module is to provide the most advanced network
file system function for SMB3 compliant servers, including advanced
@ -27,8 +27,8 @@ Introduction
POSIX compliance, secure per-user session establishment, encryption,
high performance safe distributed caching (leases/oplocks), optional packet
signing, large files, Unicode support and other internationalization
improvements. Since both Samba server and this filesystem client support
the CIFS Unix extensions (and in the future SMB3 POSIX extensions),
improvements. Since both Samba server and this filesystem client support the
CIFS Unix extensions, and the Linux client also suppors SMB3 POSIX extensions,
the combination can provide a reasonable alternative to other network and
cluster file systems for fileserving in some Linux to Linux environments,
not just in Linux to Windows (or Linux to Mac) environments.

34
Documentation/admin-guide/cifs/todo.rst
View File

@ -13,24 +13,26 @@ is a partial list of the known problems and missing features:
a) SMB3 (and SMB3.1.1) missing optional features:
- multichannel (started), integration with RDMA
- directory leases (improved metadata caching), started (root dir only)
- multichannel (partially integrated), integration of multichannel with RDMA
- directory leases (improved metadata caching). Currently only implemented for root dir
- T10 copy offload ie "ODX" (copy chunk, and "Duplicate Extents" ioctl
currently the only two server side copy mechanisms supported)
b) improved sparse file support (fiemap and SEEK_HOLE are implemented
but additional features would be supportable by the protocol).
but additional features would be supportable by the protocol such
as FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE)
c) Directory entry caching relies on a 1 second timer, rather than
using Directory Leases, currently only the root file handle is cached longer
by leveraging Directory Leases
d) quota support (needs minor kernel change since quota calls
to make it to network filesystems or deviceless filesystems)
d) quota support (needs minor kernel change since quota calls otherwise
won't make it to network filesystems or deviceless filesystems).
e) Additional use cases can be optimized to use "compounding" (e.g.
open/query/close and open/setinfo/close) to reduce the number of
roundtrips to the server and improve performance. Various cases
(stat, statfs, create, unlink, mkdir) already have been improved by
(stat, statfs, create, unlink, mkdir, xattrs) already have been improved by
using compounding but more can be done. In addition we could
significantly reduce redundant opens by using deferred close (with
handle caching leases) and better using reference counters on file
@ -60,7 +62,9 @@ k) Add tools to take advantage of more smb3 specific ioctls and features
metadata attributes easier from tools (e.g. extending what was done
in smb-info tool).
l) encrypted file support
l) encrypted file support (currently the attribute showing the file is
encrypted on the server is reported, but changing the attribute is not
supported).
m) improved stats gathering tools (perhaps integration with nfsometer?)
to extend and make easier to use what is currently in /proc/fs/cifs/Stats
@ -69,14 +73,13 @@ n) Add support for claims based ACLs ("DAC")
o) mount helper GUI (to simplify the various configuration options on mount)
p) Add support for witness protocol (perhaps ioctl to cifs.ko from user space
tool listening on witness protocol RPC) to allow for notification of share
move, server failover, and server adapter changes. And also improve other
failover scenarios, e.g. when client knows multiple DFS entries point to
different servers, and the server we are connected to has gone down.
p) Expand support for witness protocol to allow for notification of share
move, and server network adapter changes. Currently only notifications by
the witness protocol for server move is supported by the Linux client.
q) Allow mount.cifs to be more verbose in reporting errors with dialect
or unsupported feature errors.
or unsupported feature errors. This would now be easier due to the
implementation of the new mount API.
r) updating cifs documentation, and user guide.
@ -87,11 +90,10 @@ t) split cifs and smb3 support into separate modules so legacy (and less
secure) CIFS dialect can be disabled in environments that don't need it
and simplify the code.
v) POSIX Extensions for SMB3.1.1 (started, create and mkdir support added
so far).
v) Additional testing of POSIX Extensions for SMB3.1.1
w) Add support for additional strong encryption types, and additional spnego
authentication mechanisms (see MS-SMB2)
authentication mechanisms (see MS-SMB2). GCM-256 is now partially implemented.
x) Finish support for SMB3.1.1 compression

2
Documentation/admin-guide/cifs/usage.rst
View File

@ -83,7 +83,7 @@ and encrypted shares and stronger signing and authentication algorithms.
There are additional mount options that may be helpful for SMB3 to get
improved POSIX behavior (NB: can use vers=3.0 to force only SMB3, never 2.1):
``mfsymlinks`` and ``cifsacl`` and ``idsfromsid``
``mfsymlinks`` and either ``cifsacl`` or ``modefromsid`` (usually with ``idsfromsid``)
Allowing User Mounts
====================

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

@ -1434,6 +1434,11 @@
to enforce probe and suspend/resume ordering.
rpm -- Like "on", but also use to order runtime PM.
fw_devlink.strict=<bool>
[KNL] Treat all inferred dependencies as mandatory
dependencies. This only applies for fw_devlink=on|rpm.
Format: <bool>
gamecon.map[2|3]=
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
support via parallel port (up to 5 devices per port)
@ -1674,6 +1679,12 @@
In such case C2/C3 won't be used again.
idle=nomwait: Disable mwait for CPU C-states
idxd.sva= [HW]
Format: <bool>
Allow force disabling of Shared Virtual Memory (SVA)
support for the idxd driver. By default it is set to
true (1).
ieee754= [MIPS] Select IEEE Std 754 conformance mode
Format: { strict | legacy | 2008 | relaxed }
Default: strict
@ -4893,14 +4904,6 @@
last alloc / free. For more information see
Documentation/vm/slub.rst.
slub_memcg_sysfs= [MM, SLUB]
Determines whether to enable sysfs directories for
memory cgroup sub-caches. 1 to enable, 0 to disable.
The default is determined by CONFIG_SLUB_MEMCG_SYSFS_ON.
Enabling this can lead to a very high number of debug
directories and files being created under
/sys/kernel/slub.
slub_max_order= [MM, SLUB]
Determines the maximum allowed order for slabs.
A high setting may cause OOMs due to memory
@ -5179,6 +5182,12 @@
growing up) the main stack are reserved for no other
mapping. Default value is 256 pages.
stack_depot_disable= [KNL]
Setting this to true through kernel command line will
disable the stack depot thereby saving the static memory
consumed by the stack hash table. By default this is set
to false.
stacktrace [FTRACE]
Enabled the stack tracer on boot up.
@ -5979,12 +5988,6 @@
default x2apic cluster mode on platforms
supporting x2apic.
x86_intel_mid_timer= [X86-32,APBT]
Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
x86_intel_mid_timer=apbt_only | lapic_and_apbt
xen_512gb_limit [KNL,X86-64,XEN]
Restricts the kernel running paravirtualized under Xen
to use only up to 512 GB of RAM. The reason to do so is

20
Documentation/admin-guide/mm/memory-hotplug.rst
View File

@ -160,16 +160,16 @@ Under each memory block, you can see 5 files:
"online_movable", "online", "offline" command
which will be performed on all sections in the block.
``phys_device`` read-only: designed to show the name of physical memory
device. This is not well implemented now.
``removable`` read-only: contains an integer value indicating
whether the memory block is removable or not
removable. A value of 1 indicates that the memory
block is removable and a value of 0 indicates that
it is not removable. A memory block is removable only if
every section in the block is removable.
``valid_zones`` read-only: designed to show which zones this memory block
can be onlined to.
``phys_device`` read-only: legacy interface only ever used on s390x to
expose the covered storage increment.
``removable`` read-only: legacy interface that indicated whether a memory
block was likely to be offlineable or not. Newer kernel
versions return "1" if and only if the kernel supports
memory offlining.
``valid_zones`` read-only: designed to show by which zone memory provided by
a memory block is managed, and to show by which zone memory
provided by an offline memory block could be managed when
onlining.
The first column shows it`s default zone.

48
Documentation/admin-guide/spkguide.txt
View File

@ -1033,7 +1033,9 @@ speakup + keypad 3, you would hear:
The speakup key is depressed, so the name of the key state is speakup.
This part of the message comes from the states collection.
14.2. Loading Your Own Messages
14.2. Changing language
14.2.1. Loading Your Own Messages
The files under the i18n subdirectory all follow the same format.
They consist of lines, with one message per line.
@ -1066,8 +1068,50 @@ echo '1 azul' > /speakup/i18n/colors
The next time that Speakup says message 1 from the colors group, it will
say "azul", rather than "blue."
14.2.2. Choose a language
In the future, translations into various languages will be made available,
and most users will just load the files necessary for their language.
and most users will just load the files necessary for their language. So far,
only French language is available beyond native Canadian English language.
French is only available after you are logged in.
Canadian English is the default language. To toggle another language,
download the source of Speakup and untar it in your home directory. The
following command should let you do this:
tar xvjf speakup-<version>.tar.bz2
where <version> is the version number of the application.
Next, change to the newly created directory, then into the tools/ directory, and
run the script speakup_setlocale. You are asked the language that you want to
use. Type the number associated to your language (e.g. fr for French) then press
Enter. Needed files are copied in the i18n directory.
Note: the speakupconf must be installed on your system so that settings are saved.
Otherwise, you will have an error: your language will be loaded but you will
have to run the script again every time Speakup restarts.
See section 16.1. for information about speakupconf.
You will have to repeat these steps for any change of locale, i.e. if you wish
change the speakup's language or charset (iso-8859-15 ou UTF-8).
If you wish store the settings, note that at your next login, you will need to
do:
speakup load
Alternatively, you can add the above line to your file
~/.bashrc or ~/.bash_profile.
If your system administrator ran himself the script, all the users will be able
to change from English to the language choosed by root and do directly
speakupconf load (or add this to the ~/.bashrc or
~/.bash_profile file). If there are several languages to handle, the
administrator (or every user) will have to run the first steps until speakupconf
save, choosing the appropriate language, in every user's home directory. Every
user will then be able to do speakupconf load, Speakup will load his own settings.
14.3. No Support for Non-Western-European Languages

10
Documentation/admin-guide/sysctl/vm.rst
View File

@ -983,11 +983,11 @@ that benefit from having their data cached, zone_reclaim_mode should be
left disabled as the caching effect is likely to be more important than
data locality.
zone_reclaim may be enabled if it's known that the workload is partitioned
such that each partition fits within a NUMA node and that accessing remote
memory would cause a measurable performance reduction. The page allocator
will then reclaim easily reusable pages (those page cache pages that are
currently not used) before allocating off node pages.
Consider enabling one or more zone_reclaim mode bits if it's known that the
workload is partitioned such that each partition fits within a NUMA node
and that accessing remote memory would cause a measurable performance
reduction. The page allocator will take additional actions before
allocating off node pages.
Allowing zone reclaim to write out pages stops processes that are
writing large amounts of data from dirtying pages on other nodes. Zone

16
Documentation/admin-guide/xfs.rst
View File

@ -284,6 +284,9 @@ The following sysctls are available for the XFS filesystem:
removes unused preallocation from clean inodes and releases
the unused space back to the free pool.
fs.xfs.speculative_cow_prealloc_lifetime
This is an alias for speculative_prealloc_lifetime.
fs.xfs.error_level (Min: 0 Default: 3 Max: 11)
A volume knob for error reporting when internal errors occur.
This will generate detailed messages & backtraces for filesystem
@ -356,12 +359,13 @@ The following sysctls are available for the XFS filesystem:
Deprecated Sysctls
==================
=========================== ================
Name Removal Schedule
=========================== ================
fs.xfs.irix_sgid_inherit September 2025
fs.xfs.irix_symlink_mode September 2025
=========================== ================
=========================================== ================
Name Removal Schedule
=========================================== ================
fs.xfs.irix_sgid_inherit September 2025
fs.xfs.irix_symlink_mode September 2025
fs.xfs.speculative_cow_prealloc_lifetime September 2025
=========================================== ================
Removed Sysctls

4
Documentation/block/bfq-iosched.rst
View File

@ -430,13 +430,13 @@ fifo_expire_async
-----------------
This parameter is used to set the timeout of asynchronous requests. Default
value of this is 248ms.
value of this is 250ms.
fifo_expire_sync
----------------
This parameter is used to set the timeout of synchronous requests. Default
value of this is 124ms. In case to favor synchronous requests over asynchronous
value of this is 125ms. In case to favor synchronous requests over asynchronous
one, this value should be decreased relative to fifo_expire_async.
low_latency

3
Documentation/conf.py
View File

@ -49,8 +49,7 @@ extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include',
if major >= 3:
sys.stderr.write('''WARNING: The kernel documentation build process
support for Sphinx v3.0 and above is brand new. Be prepared for
possible issues in the generated output.
''')
possible issues in the generated output.\n''')
if (major > 3) or (minor > 0 or patch >= 2):
# Sphinx c function parser is more pedantic with regards to type
# checking. Due to that, having macros at c:function cause problems.

66
Documentation/core-api/dma-api.rst
View File

@ -526,46 +526,6 @@ for the kernel vs the device.
If you don't understand how cache line coherency works between a processor and
an I/O device, you should not be using this part of the API.
::
void *
dma_alloc_noncoherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, enum dma_data_direction dir,
gfp_t gfp)
This routine allocates a region of <size> bytes of consistent memory. It
returns a pointer to the allocated region (in the processor's virtual address
space) or NULL if the allocation failed. The returned memory may or may not
be in the kernel direct mapping. Drivers must not call virt_to_page on
the returned memory region.
It also returns a <dma_handle> which may be cast to an unsigned integer the
same width as the bus and given to the device as the DMA address base of
the region.
The dir parameter specified if data is read and/or written by the device,
see dma_map_single() for details.
The gfp parameter allows the caller to specify the ``GFP_`` flags (see
kmalloc()) for the allocation, but rejects flags used to specify a memory
zone such as GFP_DMA or GFP_HIGHMEM.
Before giving the memory to the device, dma_sync_single_for_device() needs
to be called, and before reading memory written by the device,
dma_sync_single_for_cpu(), just like for streaming DMA mappings that are
reused.
::
void
dma_free_noncoherent(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle, enum dma_data_direction dir)
Free a region of memory previously allocated using dma_alloc_noncoherent().
dev, size and dma_handle and dir must all be the same as those passed into
dma_alloc_noncoherent(). cpu_addr must be the virtual address returned by
dma_alloc_noncoherent().
::
struct page *
@ -600,9 +560,29 @@ reused.
dma_addr_t dma_handle, enum dma_data_direction dir)
Free a region of memory previously allocated using dma_alloc_pages().
dev, size and dma_handle and dir must all be the same as those passed into
dma_alloc_noncoherent(). page must be the pointer returned by
dma_alloc_pages().
dev, size, dma_handle and dir must all be the same as those passed into
dma_alloc_pages(). page must be the pointer returned by dma_alloc_pages().
::
void *
dma_alloc_noncoherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, enum dma_data_direction dir,
gfp_t gfp)
This routine is a convenient wrapper around dma_alloc_pages that returns the
kernel virtual address for the allocated memory instead of the page structure.
::
void
dma_free_noncoherent(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_handle, enum dma_data_direction dir)
Free a region of memory previously allocated using dma_alloc_noncoherent().
dev, size, dma_handle and dir must all be the same as those passed into
dma_alloc_noncoherent(). cpu_addr must be the virtual address returned by
dma_alloc_noncoherent().
::

7
Documentation/core-api/mm-api.rst
View File

@ -19,11 +19,8 @@ User Space Memory Access
Memory Allocation Controls
==========================
Functions which need to allocate memory often use GFP flags to express
how that memory should be allocated. The GFP acronym stands for "get
free pages", the underlying memory allocation function. Not every GFP
flag is allowed to every function which may allocate memory. Most
users will want to use a plain ``GFP_KERNEL``.
.. kernel-doc:: include/linux/gfp.h
:internal:
.. kernel-doc:: include/linux/gfp.h
:doc: Page mobility and placement hints

1
Documentation/dev-tools/index.rst
View File

@ -22,6 +22,7 @@ whole; patches welcome!
ubsan
kmemleak
kcsan
kfence
gdb-kernel-debugging
kgdb
kselftest

32
Documentation/dev-tools/kasan.rst
View File

@ -147,16 +147,15 @@ negative values to distinguish between different kinds of inaccessible memory
like redzones or freed memory (see mm/kasan/kasan.h).
In the report above the arrows point to the shadow byte 03, which means that
the accessed address is partially accessible.
For tag-based KASAN this last report section shows the memory tags around the
accessed address (see `Implementation details`_ section).
the accessed address is partially accessible. For tag-based KASAN modes this
last report section shows the memory tags around the accessed address
(see the `Implementation details`_ section).
Boot parameters
~~~~~~~~~~~~~~~
Hardware tag-based KASAN mode (see the section about different mode below) is
intended for use in production as a security mitigation. Therefore it supports
Hardware tag-based KASAN mode (see the section about various modes below) is
intended for use in production as a security mitigation. Therefore, it supports
boot parameters that allow to disable KASAN competely or otherwise control
particular KASAN features.
@ -166,7 +165,8 @@ particular KASAN features.
traces collection (default: ``on``).
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
report or also panic the kernel (default: ``report``).
report or also panic the kernel (default: ``report``). Note, that tag
checking gets disabled after the first reported bug.
For developers
~~~~~~~~~~~~~~
@ -289,6 +289,16 @@ reserved to tag freed memory regions.
Hardware tag-based KASAN currently only supports tagging of
kmem_cache_alloc/kmalloc and page_alloc memory.
If the hardware doesn't support MTE (pre ARMv8.5), hardware tag-based KASAN
won't be enabled. In this case all boot parameters are ignored.
Note, that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when kasan.mode=off is provided, or when the hardware doesn't
support MTE (but supports TBI).
Hardware tag-based KASAN only reports the first found bug. After that MTE tag
checking gets disabled.
What memory accesses are sanitised by KASAN?
--------------------------------------------
@ -352,17 +362,17 @@ unmapped. This will require changes in arch-specific code.
This allows ``VMAP_STACK`` support on x86, and can simplify support of
architectures that do not have a fixed module region.
CONFIG_KASAN_KUNIT_TEST & CONFIG_TEST_KASAN_MODULE
--------------------------------------------------
CONFIG_KASAN_KUNIT_TEST and CONFIG_KASAN_MODULE_TEST
----------------------------------------------------
KASAN tests consist on two parts:
KASAN tests consist of two parts:
1. Tests that are integrated with the KUnit Test Framework. Enabled with
``CONFIG_KASAN_KUNIT_TEST``. These tests can be run and partially verified
automatically in a few different ways, see the instructions below.
2. Tests that are currently incompatible with KUnit. Enabled with
``CONFIG_TEST_KASAN_MODULE`` and can only be run as a module. These tests can
``CONFIG_KASAN_MODULE_TEST`` and can only be run as a module. These tests can
only be verified manually, by loading the kernel module and inspecting the
kernel log for KASAN reports.

298
Documentation/dev-tools/kfence.rst Normal file
View File

@ -0,0 +1,298 @@
.. SPDX-License-Identifier: GPL-2.0
.. Copyright (C) 2020, Google LLC.
Kernel Electric-Fence (KFENCE)
==============================
Kernel Electric-Fence (KFENCE) is a low-overhead sampling-based memory safety
error detector. KFENCE detects heap out-of-bounds access, use-after-free, and
invalid-free errors.
KFENCE is designed to be enabled in production kernels, and has near zero
performance overhead. Compared to KASAN, KFENCE trades performance for
precision. The main motivation behind KFENCE's design, is that with enough
total uptime KFENCE will detect bugs in code paths not typically exercised by
non-production test workloads. One way to quickly achieve a large enough total
uptime is when the tool is deployed across a large fleet of machines.
Usage
-----
To enable KFENCE, configure the kernel with::
CONFIG_KFENCE=y
To build a kernel with KFENCE support, but disabled by default (to enable, set
``kfence.sample_interval`` to non-zero value), configure the kernel with::
CONFIG_KFENCE=y
CONFIG_KFENCE_SAMPLE_INTERVAL=0
KFENCE provides several other configuration options to customize behaviour (see
the respective help text in ``lib/Kconfig.kfence`` for more info).
Tuning performance
~~~~~~~~~~~~~~~~~~
The most important parameter is KFENCE's sample interval, which can be set via
the kernel boot parameter ``kfence.sample_interval`` in milliseconds. The
sample interval determines the frequency with which heap allocations will be
guarded by KFENCE. The default is configurable via the Kconfig option
``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0``
disables KFENCE.
The KFENCE memory pool is of fixed size, and if the pool is exhausted, no
further KFENCE allocations occur. With ``CONFIG_KFENCE_NUM_OBJECTS`` (default
255), the number of available guarded objects can be controlled. Each object
requires 2 pages, one for the object itself and the other one used as a guard
page; object pages are interleaved with guard pages, and every object page is
therefore surrounded by two guard pages.
The total memory dedicated to the KFENCE memory pool can be computed as::
( #objects + 1 ) * 2 * PAGE_SIZE
Using the default config, and assuming a page size of 4 KiB, results in
dedicating 2 MiB to the KFENCE memory pool.
Note: On architectures that support huge pages, KFENCE will ensure that the
pool is using pages of size ``PAGE_SIZE``. This will result in additional page
tables being allocated.
Error reports
~~~~~~~~~~~~~
A typical out-of-bounds access looks like this::
==================================================================
BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa3/0x22b
Out-of-bounds read at 0xffffffffb672efff (1B left of kfence-#17):
test_out_of_bounds_read+0xa3/0x22b
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
kfence-#17 [0xffffffffb672f000-0xffffffffb672f01f, size=32, cache=kmalloc-32] allocated by task 507:
test_alloc+0xf3/0x25b
test_out_of_bounds_read+0x98/0x22b
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
CPU: 4 PID: 107 Comm: kunit_try_catch Not tainted 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
==================================================================
The header of the report provides a short summary of the function involved in
the access. It is followed by more detailed information about the access and
its origin. Note that, real kernel addresses are only shown when using the
kernel command line option ``no_hash_pointers``.
Use-after-free accesses are reported as::
==================================================================
BUG: KFENCE: use-after-free read in test_use_after_free_read+0xb3/0x143
Use-after-free read at 0xffffffffb673dfe0 (in kfence-#24):
test_use_after_free_read+0xb3/0x143
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
kfence-#24 [0xffffffffb673dfe0-0xffffffffb673dfff, size=32, cache=kmalloc-32] allocated by task 507:
test_alloc+0xf3/0x25b
test_use_after_free_read+0x76/0x143
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
freed by task 507:
test_use_after_free_read+0xa8/0x143
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
CPU: 4 PID: 109 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
==================================================================
KFENCE also reports on invalid frees, such as double-frees::
==================================================================
BUG: KFENCE: invalid free in test_double_free+0xdc/0x171
Invalid free of 0xffffffffb6741000:
test_double_free+0xdc/0x171
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
kfence-#26 [0xffffffffb6741000-0xffffffffb674101f, size=32, cache=kmalloc-32] allocated by task 507:
test_alloc+0xf3/0x25b
test_double_free+0x76/0x171
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
freed by task 507:
test_double_free+0xa8/0x171
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
CPU: 4 PID: 111 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
==================================================================
KFENCE also uses pattern-based redzones on the other side of an object's guard
page, to detect out-of-bounds writes on the unprotected side of the object.
These are reported on frees::
==================================================================
BUG: KFENCE: memory corruption in test_kmalloc_aligned_oob_write+0xef/0x184
Corrupted memory at 0xffffffffb6797ff9 [ 0xac . . . . . . ] (in kfence-#69):
test_kmalloc_aligned_oob_write+0xef/0x184
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
kfence-#69 [0xffffffffb6797fb0-0xffffffffb6797ff8, size=73, cache=kmalloc-96] allocated by task 507:
test_alloc+0xf3/0x25b
test_kmalloc_aligned_oob_write+0x57/0x184
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
CPU: 4 PID: 120 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
==================================================================
For such errors, the address where the corruption occurred as well as the
invalidly written bytes (offset from the address) are shown; in this
representation, '.' denote untouched bytes. In the example above ``0xac`` is
the value written to the invalid address at offset 0, and the remaining '.'
denote that no following bytes have been touched. Note that, real values are
only shown if the kernel was booted with ``no_hash_pointers``; to avoid
information disclosure otherwise, '!' is used instead to denote invalidly
written bytes.
And finally, KFENCE may also report on invalid accesses to any protected page
where it was not possible to determine an associated object, e.g. if adjacent
object pages had not yet been allocated::
==================================================================
BUG: KFENCE: invalid read in test_invalid_access+0x26/0xe0
Invalid read at 0xffffffffb670b00a:
test_invalid_access+0x26/0xe0
kunit_try_run_case+0x51/0x85
kunit_generic_run_threadfn_adapter+0x16/0x30
kthread+0x137/0x160
ret_from_fork+0x22/0x30
CPU: 4 PID: 124 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
==================================================================
DebugFS interface
~~~~~~~~~~~~~~~~~
Some debugging information is exposed via debugfs:
* The file ``/sys/kernel/debug/kfence/stats`` provides runtime statistics.
* The file ``/sys/kernel/debug/kfence/objects`` provides a list of objects
allocated via KFENCE, including those already freed but protected.
Implementation Details
----------------------
Guarded allocations are set up based on the sample interval. After expiration
of the sample interval, the next allocation through the main allocator (SLAB or
SLUB) returns a guarded allocation from the KFENCE object pool (allocation
sizes up to PAGE_SIZE are supported). At this point, the timer is reset, and
the next allocation is set up after the expiration of the interval. To "gate" a
KFENCE allocation through the main allocator's fast-path without overhead,
KFENCE relies on static branches via the static keys infrastructure. The static
branch is toggled to redirect the allocation to KFENCE.
KFENCE objects each reside on a dedicated page, at either the left or right
page boundaries selected at random. The pages to the left and right of the
object page are "guard pages", whose attributes are changed to a protected
state, and cause page faults on any attempted access. Such page faults are then
intercepted by KFENCE, which handles the fault gracefully by reporting an
out-of-bounds access, and marking the page as accessible so that the faulting
code can (wrongly) continue executing (set ``panic_on_warn`` to panic instead).
To detect out-of-bounds writes to memory within the object's page itself,
KFENCE also uses pattern-based redzones. For each object page, a redzone is set
up for all non-object memory. For typical alignments, the redzone is only
required on the unguarded side of an object. Because KFENCE must honor the
cache's requested alignment, special alignments may result in unprotected gaps
on either side of an object, all of which are redzoned.
The following figure illustrates the page layout::
---+-----------+-----------+-----------+-----------+-----------+---
| xxxxxxxxx | O : | xxxxxxxxx | : O | xxxxxxxxx |
| xxxxxxxxx | B : | xxxxxxxxx | : B | xxxxxxxxx |
| x GUARD x | J : RED- | x GUARD x | RED- : J | x GUARD x |
| xxxxxxxxx | E : ZONE | xxxxxxxxx | ZONE : E | xxxxxxxxx |
| xxxxxxxxx | C : | xxxxxxxxx | : C | xxxxxxxxx |
| xxxxxxxxx | T : | xxxxxxxxx | : T | xxxxxxxxx |
---+-----------+-----------+-----------+-----------+-----------+---
Upon deallocation of a KFENCE object, the object's page is again protected and
the object is marked as freed. Any further access to the object causes a fault
and KFENCE reports a use-after-free access. Freed objects are inserted at the
tail of KFENCE's freelist, so that the least recently freed objects are reused
first, and the chances of detecting use-after-frees of recently freed objects
is increased.
Interface
---------
The following describes the functions which are used by allocators as well as
page handling code to set up and deal with KFENCE allocations.
.. kernel-doc:: include/linux/kfence.h
:functions: is_kfence_address
kfence_shutdown_cache
kfence_alloc kfence_free __kfence_free
kfence_ksize kfence_object_start
kfence_handle_page_fault
Related Tools
-------------
In userspace, a similar approach is taken by `GWP-ASan
<http://llvm.org/docs/GwpAsan.html>`_. GWP-ASan also relies on guard pages and
a sampling strategy to detect memory unsafety bugs at scale. KFENCE's design is
directly influenced by GWP-ASan, and can be seen as its kernel sibling. Another
similar but non-sampling approach, that also inspired the name "KFENCE", can be
found in the userspace `Electric Fence Malloc Debugger
<https://linux.die.net/man/3/efence>`_.
In the kernel, several tools exist to debug memory access errors, and in
particular KASAN can detect all bug classes that KFENCE can detect. While KASAN
is more precise, relying on compiler instrumentation, this comes at a
performance cost.
It is worth highlighting that KASAN and KFENCE are complementary, with
different target environments. For instance, KASAN is the better debugging-aid,
where test cases or reproducers exists: due to the lower chance to detect the
error, it would require more effort using KFENCE to debug. Deployments at scale
that cannot afford to enable KASAN, however, would benefit from using KFENCE to
discover bugs due to code paths not exercised by test cases or fuzzers.

8
Documentation/devicetree/bindings/Makefile
View File

@ -78,10 +78,10 @@ $(obj)/processed-schema.json: $(DT_SCHEMA_FILES) check_dtschema_version FORCE
endif
extra-$(CHECK_DT_BINDING) += processed-schema-examples.json
extra-$(CHECK_DTBS) += processed-schema.json
extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
extra-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES))
always-$(CHECK_DT_BINDING) += processed-schema-examples.json
always-$(CHECK_DTBS) += processed-schema.json
always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES))
always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES))
# Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of
# build artifacts here before they are processed by scripts/Makefile.clean

5
Documentation/devicetree/bindings/arm/coresight.txt
View File

@ -34,9 +34,12 @@ its hardware characteristcs.
Program Flow Trace Macrocell:
"arm,coresight-etm3x", "arm,primecell";
- Embedded Trace Macrocell (version 4.x):
- Embedded Trace Macrocell (version 4.x), with memory mapped access.
"arm,coresight-etm4x", "arm,primecell";
- Embedded Trace Macrocell (version 4.x), with system register access only.
"arm,coresight-etm4x-sysreg";
- Coresight programmable Replicator :
"arm,coresight-dynamic-replicator", "arm,primecell";

1
Documentation/devicetree/bindings/arm/rockchip.yaml
View File

@ -132,6 +132,7 @@ properties:
- enum:
- friendlyarm,nanopc-t4
- friendlyarm,nanopi-m4
- friendlyarm,nanopi-m4b
- friendlyarm,nanopi-neo4
- const: rockchip,rk3399

2
Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
View File

@ -109,7 +109,7 @@ required:
- resets
- ddc
unevaluatedProperties: false
additionalProperties: false
examples:
- |

1
Documentation/devicetree/bindings/display/connector/dp-connector.yaml
View File

@ -26,7 +26,6 @@ properties:
dp-pwr-supply:
description: Power supply for the DP_PWR pin
maxItems: 1
port:
$ref: /schemas/graph.yaml#/properties/port

18
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
View File

@ -22,23 +22,7 @@ Required properties:
MIPI TX Configuration Module
============================
The MIPI TX configuration module controls the MIPI D-PHY.
Required properties:
- compatible: "mediatek,<chip>-mipi-tx"
- the supported chips are mt2701, 7623, mt8173 and mt8183.
- reg: Physical base address and length of the controller's registers
- clocks: PLL reference clock
- clock-output-names: name of the output clock line to the DSI encoder
- #clock-cells: must be <0>;
- #phy-cells: must be <0>.
Optional properties:
- drive-strength-microamp: adjust driving current, should be 3000 ~ 6000. And
the step is 200.
- nvmem-cells: A phandle to the calibration data provided by a nvmem device. If
unspecified default values shall be used.
- nvmem-cell-names: Should be "calibration-data"
See phy/mediatek,dsi-phy.yaml
Example:

18
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
View File

@ -53,23 +53,7 @@ Required properties:
HDMI PHY
========
The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
output and drives the HDMI pads.
Required properties:
- compatible: "mediatek,<chip>-hdmi-phy"
- the supported chips are mt2701, mt7623 and mt8173
- reg: Physical base address and length of the module's registers
- clocks: PLL reference clock
- clock-names: must contain "pll_ref"
- clock-output-names: must be "hdmitx_dig_cts" on mt8173
- #phy-cells: must be <0>
- #clock-cells: must be <0>
Optional properties:
- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
See phy/mediatek,hdmi-phy.yaml
Example:

2
Documentation/devicetree/bindings/dma/ingenic,dma.yaml
View File

@ -17,6 +17,8 @@ properties:
enum:
- ingenic,jz4740-dma
- ingenic,jz4725b-dma
- ingenic,jz4760-dma
- ingenic,jz4760b-dma
- ingenic,jz4770-dma
- ingenic,jz4780-dma
- ingenic,x1000-dma

116
Documentation/devicetree/bindings/dma/intel,ldma.yaml Normal file
View File

@ -0,0 +1,116 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/intel,ldma.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Lightning Mountain centralized DMA controllers.
maintainers:
- chuanhua.lei@intel.com
- mallikarjunax.reddy@intel.com
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
enum:
- intel,lgm-cdma
- intel,lgm-dma2tx
- intel,lgm-dma1rx
- intel,lgm-dma1tx
- intel,lgm-dma0tx
- intel,lgm-dma3
- intel,lgm-toe-dma30
- intel,lgm-toe-dma31
reg:
maxItems: 1
"#dma-cells":
const: 3
description:
The first cell is the peripheral's DMA request line.
The second cell is the peripheral's (port) number corresponding to the channel.
The third cell is the burst length of the channel.
dma-channels:
minimum: 1
maximum: 16
dma-channel-mask:
maxItems: 1
clocks:
maxItems: 1
resets:
maxItems: 1
reset-names:
items:
- const: ctrl
interrupts:
maxItems: 1
intel,dma-poll-cnt:
$ref: /schemas/types.yaml#/definitions/uint32
description:
DMA descriptor polling counter is used to control the poling mechanism
for the descriptor fetching for all channels.
intel,dma-byte-en:
type: boolean
description:
DMA byte enable is only valid for DMA write(RX).
Byte enable(1) means DMA write will be based on the number of dwords
instead of the whole burst.
intel,dma-drb:
type: boolean
description:
DMA descriptor read back to make sure data and desc synchronization.
intel,dma-dburst-wr:
type: boolean
description:
Enable RX dynamic burst write. When it is enabled, the DMA does RX dynamic burst;
if it is disabled, the DMA RX will still support programmable fixed burst size of 2,4,8,16.
It only applies to RX DMA and memcopy DMA.
required:
- compatible
- reg
additionalProperties: false
examples:
- |
dma0: dma-controller@e0e00000 {
compatible = "intel,lgm-cdma";
reg = <0xe0e00000 0x1000>;
#dma-cells = <3>;
dma-channels = <16>;
dma-channel-mask = <0xFFFF>;
interrupt-parent = <&ioapic1>;
interrupts = <82 1>;
resets = <&rcu0 0x30 0>;
reset-names = "ctrl";
clocks = <&cgu0 80>;
intel,dma-poll-cnt = <4>;
intel,dma-byte-en;
intel,dma-drb;
};
- |
dma3: dma-controller@ec800000 {
compatible = "intel,lgm-dma3";
reg = <0xec800000 0x1000>;
clocks = <&cgu0 71>;
resets = <&rcu0 0x10 9>;
#dma-cells = <3>;
intel,dma-poll-cnt = <16>;
intel,dma-byte-en;
intel,dma-dburst-wr;
};

7
Documentation/devicetree/bindings/dma/owl-dma.yaml
View File

@ -8,8 +8,8 @@ title: Actions Semi Owl SoCs DMA controller
description: |
The OWL DMA is a general-purpose direct memory access controller capable of
supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
respectively.
supporting 10 independent DMA channels for the Actions Semi S700 SoC and 12
independent DMA channels for the S500 and S900 SoC variants.
maintainers:
- Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
@ -20,8 +20,9 @@ allOf:
properties:
compatible:
enum:
- actions,s900-dma
- actions,s500-dma
- actions,s700-dma
- actions,s900-dma
reg:
maxItems: 1

74
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
View File

@ -14,34 +14,37 @@ allOf:
properties:
compatible:
items:
- enum:
- renesas,dmac-r8a7742 # RZ/G1H
- renesas,dmac-r8a7743 # RZ/G1M
- renesas,dmac-r8a7744 # RZ/G1N
- renesas,dmac-r8a7745 # RZ/G1E
- renesas,dmac-r8a77470 # RZ/G1C
- renesas,dmac-r8a774a1 # RZ/G2M
- renesas,dmac-r8a774b1 # RZ/G2N
- renesas,dmac-r8a774c0 # RZ/G2E
- renesas,dmac-r8a774e1 # RZ/G2H
- renesas,dmac-r8a7790 # R-Car H2
- renesas,dmac-r8a7791 # R-Car M2-W
- renesas,dmac-r8a7792 # R-Car V2H
- renesas,dmac-r8a7793 # R-Car M2-N
- renesas,dmac-r8a7794 # R-Car E2
- renesas,dmac-r8a7795 # R-Car H3
- renesas,dmac-r8a7796 # R-Car M3-W
- renesas,dmac-r8a77961 # R-Car M3-W+
- renesas,dmac-r8a77965 # R-Car M3-N
- renesas,dmac-r8a77970 # R-Car V3M
- renesas,dmac-r8a77980 # R-Car V3H
- renesas,dmac-r8a77990 # R-Car E3
- renesas,dmac-r8a77995 # R-Car D3
- const: renesas,rcar-dmac
oneOf:
- items:
- enum:
- renesas,dmac-r8a7742 # RZ/G1H
- renesas,dmac-r8a7743 # RZ/G1M
- renesas,dmac-r8a7744 # RZ/G1N
- renesas,dmac-r8a7745 # RZ/G1E
- renesas,dmac-r8a77470 # RZ/G1C
- renesas,dmac-r8a774a1 # RZ/G2M
- renesas,dmac-r8a774b1 # RZ/G2N
- renesas,dmac-r8a774c0 # RZ/G2E
- renesas,dmac-r8a774e1 # RZ/G2H
- renesas,dmac-r8a7790 # R-Car H2
- renesas,dmac-r8a7791 # R-Car M2-W
- renesas,dmac-r8a7792 # R-Car V2H
- renesas,dmac-r8a7793 # R-Car M2-N
- renesas,dmac-r8a7794 # R-Car E2
- renesas,dmac-r8a7795 # R-Car H3
- renesas,dmac-r8a7796 # R-Car M3-W
- renesas,dmac-r8a77961 # R-Car M3-W+
- renesas,dmac-r8a77965 # R-Car M3-N
- renesas,dmac-r8a77970 # R-Car V3M
- renesas,dmac-r8a77980 # R-Car V3H
- renesas,dmac-r8a77990 # R-Car E3
- renesas,dmac-r8a77995 # R-Car D3
- const: renesas,rcar-dmac
reg:
maxItems: 1
- items:
- const: renesas,dmac-r8a779a0 # R-Car V3U
reg: true
interrupts:
minItems: 9
@ -110,6 +113,23 @@ required:
- power-domains
- resets
if:
properties:
compatible:
contains:
enum:
- renesas,dmac-r8a779a0
then:
properties:
reg:
items:
- description: Base register block
- description: Channel register block
else:
properties:
reg:
maxItems: 1
additionalProperties: false
examples:

44
Documentation/devicetree/bindings/dma/sirfsoc-dma.txt
View File

@ -1,44 +0,0 @@
* CSR SiRFSoC DMA controller
See dma.txt first
Required properties:
- compatible: Should be "sirf,prima2-dmac", "sirf,atlas7-dmac" or
"sirf,atlas7-dmac-v2"
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel
- #dma-cells: must be <1>. used to represent the number of integer
cells in the dmas property of client device.
- clocks: clock required
Example:
Controller:
dmac0: dma-controller@b00b0000 {
compatible = "sirf,prima2-dmac";
reg = <0xb00b0000 0x10000>;
interrupts = <12>;
clocks = <&clks 24>;
#dma-cells = <1>;
};
Client:
Fill the specific dma request line in dmas. In the below example, spi0 read
channel request line is 9 of the 2nd dma controller, while write channel uses
4 of the 2nd dma controller; spi1 read channel request line is 12 of the 1st
dma controller, while write channel uses 13 of the 1st dma controller:
spi0: spi@b00d0000 {
compatible = "sirf,prima2-spi";
dmas = <&dmac1 9>,
<&dmac1 4>;
dma-names = "rx", "tx";
};
spi1: spi@b0170000 {
compatible = "sirf,prima2-spi";
dmas = <&dmac0 12>,
<&dmac0 13>;
dma-names = "rx", "tx";
};

39
Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
View File

@ -1,39 +0,0 @@
Synopsys DesignWare AXI DMA Controller
Required properties:
- compatible: "snps,axi-dma-1.01a"
- reg: Address range of the DMAC registers. This should include
all of the per-channel registers.
- interrupt: Should contain the DMAC interrupt number.
- dma-channels: Number of channels supported by hardware.
- snps,dma-masters: Number of AXI masters supported by the hardware.
- snps,data-width: Maximum AXI data width supported by hardware.
(0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
- snps,priority: Priority of channel. Array size is equal to the number of
dma-channels. Priority value must be programmed within [0:dma-channels-1]
range. (0 - minimum priority)
- snps,block-size: Maximum block size supported by the controller channel.
Array size is equal to the number of dma-channels.
Optional properties:
- snps,axi-max-burst-len: Restrict master AXI burst length by value specified
in this property. If this property is missing the maximum AXI burst length
supported by DMAC is used. [1:256]
Example:
dmac: dma-controller@80000 {
compatible = "snps,axi-dma-1.01a";
reg = <0x80000 0x400>;
clocks = <&core_clk>, <&cfgr_clk>;
clock-names = "core-clk", "cfgr-clk";
interrupt-parent = <&intc>;
interrupts = <27>;
dma-channels = <4>;
snps,dma-masters = <2>;
snps,data-width = <3>;
snps,block-size = <4096 4096 4096 4096>;
snps,priority = <0 1 2 3>;
snps,axi-max-burst-len = <16>;
};

126
Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml Normal file
View File

@ -0,0 +1,126 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/snps,dw-axi-dmac.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Synopsys DesignWare AXI DMA Controller
maintainers:
- Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
- Jee Heng Sia <jee.heng.sia@intel.com>
description:
Synopsys DesignWare AXI DMA Controller DT Binding
allOf:
- $ref: "dma-controller.yaml#"
properties:
compatible:
enum:
- snps,axi-dma-1.01a
- intel,kmb-axi-dma
reg:
minItems: 1
items:
- description: Address range of the DMAC registers
- description: Address range of the DMAC APB registers
reg-names:
items:
- const: axidma_ctrl_regs
- const: axidma_apb_regs
interrupts:
maxItems: 1
clocks:
items:
- description: Bus Clock
- description: Module Clock
clock-names:
items:
- const: core-clk
- const: cfgr-clk
'#dma-cells':
const: 1
dma-channels:
minimum: 1
maximum: 8
snps,dma-masters:
description: |
Number of AXI masters supported by the hardware.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2]
snps,data-width:
description: |
AXI data width supported by hardware.
(0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3, 4, 5, 6]
snps,priority:
description: |
Channel priority specifier associated with the DMA channels.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
snps,block-size:
description: |
Channel block size specifier associated with the DMA channels.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
snps,axi-max-burst-len:
description: |
Restrict master AXI burst length by value specified in this property.
If this property is missing the maximum AXI burst length supported by
DMAC is used.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 256
required:
- compatible
- reg
- clocks
- clock-names
- interrupts
- '#dma-cells'
- dma-channels
- snps,dma-masters
- snps,data-width
- snps,priority
- snps,block-size
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
/* example with snps,dw-axi-dmac */
dmac: dma-controller@80000 {
compatible = "snps,axi-dma-1.01a";
reg = <0x80000 0x400>;
clocks = <&core_clk>, <&cfgr_clk>;
clock-names = "core-clk", "cfgr-clk";
interrupt-parent = <&intc>;
interrupts = <27>;
#dma-cells = <1>;
dma-channels = <4>;
snps,dma-masters = <2>;
snps,data-width = <3>;
snps,block-size = <4096 4096 4096 4096>;
snps,priority = <0 1 2 3>;
snps,axi-max-burst-len = <16>;
};

32
Documentation/devicetree/bindings/dma/ste-coh901318.txt
View File

@ -1,32 +0,0 @@
ST-Ericsson COH 901 318 DMA Controller
This is a DMA controller which has begun as a fork of the
ARM PL08x PrimeCell VHDL code.
Required properties:
- compatible: should be "stericsson,coh901318"
- reg: register locations and length
- interrupts: the single DMA IRQ
- #dma-cells: must be set to <1>, as the channels on the
COH 901 318 are simple and identified by a single number
- dma-channels: the number of DMA channels handled
Example:
dmac: dma-controller@c00020000 {
compatible = "stericsson,coh901318";
reg = <0xc0020000 0x1000>;
interrupt-parent = <&vica>;
interrupts = <2>;
#dma-cells = <1>;
dma-channels = <40>;
};
Consumers example:
uart0: serial@c0013000 {
compatible = "...";
(...)
dmas = <&dmac 17 &dmac 18>;
dma-names = "tx", "rx";
};

38
Documentation/devicetree/bindings/dma/zxdma.txt
View File

@ -1,38 +0,0 @@
* ZTE ZX296702 DMA controller
Required properties:
- compatible: Should be "zte,zx296702-dma"
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel
- #dma-cells: see dma.txt, should be 1, para number
- dma-channels: physical channels supported
- dma-requests: virtual channels supported, each virtual channel
have specific request line
- clocks: clock required
Example:
Controller:
dma: dma-controller@09c00000{
compatible = "zte,zx296702-dma";
reg = <0x09c00000 0x1000>;
clocks = <&topclk ZX296702_DMA_ACLK>;
interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
dma-channels = <24>;
dma-requests = <24>;
};
Client:
Use specific request line passing from dmax
For example, spdif0 tx channel request line is 4
spdif0: spdif0@b004000 {
#sound-dai-cells = <0>;
compatible = "zte,zx296702-spdif";
reg = <0x0b004000 0x1000>;
clocks = <&lsp0clk ZX296702_SPDIF0_DIV>;
clock-names = "tx";
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&dma 4>;
dma-names = "tx";
}

29
Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
View File

@ -13,7 +13,10 @@ maintainers:
properties:
compatible:
items:
- const: sifive,fu540-c000-gpio
- enum:
- sifive,fu540-c000-gpio
- sifive,fu740-c000-gpio
- canaan,k210-gpiohs
- const: sifive,gpio0
reg:
@ -21,9 +24,9 @@ properties:
interrupts:
description:
interrupt mapping one per GPIO. Maximum 16 GPIOs.
Interrupt mapping, one per GPIO. Maximum 32 GPIOs.
minItems: 1
maxItems: 16
maxItems: 32
interrupt-controller: true
@ -36,6 +39,14 @@ properties:
"#gpio-cells":
const: 2
ngpios:
description:
The number of GPIOs available on the controller implementation.
It is 16 for the SiFive SoCs and 32 for the Canaan K210.
minimum: 1
maximum: 32
default: 16
gpio-controller: true
required:
@ -44,10 +55,20 @@ required:
- interrupts
- interrupt-controller
- "#interrupt-cells"
- clocks
- "#gpio-cells"
- gpio-controller
if:
properties:
compatible:
contains:
enum:
- sifive,fu540-c000-gpio
- sifive,fu740-c000-gpio
then:
required:
- clocks
additionalProperties: false
examples:

1
Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml
View File

@ -13,6 +13,7 @@ properties:
compatible:
enum:
- ti,omap4-hwspinlock # for OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
- ti,am64-hwspinlock # for K3 AM64x SoCs
- ti,am654-hwspinlock # for K3 AM65x, J721E and J7200 SoCs
reg:

24
Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml
View File

@ -31,6 +31,17 @@ properties:
if the EC does not have its own logic or hardware for this.
type: boolean
function-row-physmap:
minItems: 1
maxItems: 15
description: |
An ordered u32 array describing the rows/columns (in the scan matrix)
of top row keys from physical left (KEY_F1) to right. Each entry
encodes the row/column as:
(((row) & 0xFF) << 24) | (((column) & 0xFF) << 16)
where the lower 16 bits are reserved. This property is specified only
when the keyboard has a custom design for the top row keys.
required:
- compatible
@ -38,11 +49,24 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/input/input.h>
cros-ec-keyb {
compatible = "google,cros-ec-keyb";
keypad,num-rows = <8>;
keypad,num-columns = <13>;
google,needs-ghost-filter;
function-row-physmap = <
MATRIX_KEY(0x00, 0x02, 0) /* T1 */
MATRIX_KEY(0x03, 0x02, 0) /* T2 */
MATRIX_KEY(0x02, 0x02, 0) /* T3 */
MATRIX_KEY(0x01, 0x02, 0) /* T4 */
MATRIX_KEY(0x03, 0x04, 0) /* T5 */
MATRIX_KEY(0x02, 0x04, 0) /* T6 */
MATRIX_KEY(0x01, 0x04, 0) /* T7 */
MATRIX_KEY(0x02, 0x09, 0) /* T8 */
MATRIX_KEY(0x01, 0x09, 0) /* T9 */
MATRIX_KEY(0x00, 0x04, 0) /* T10 */
>;
/*
* Keymap entries take the form of 0xRRCCKKKK where
* RR=Row CC=Column KKKK=Key Code

77
Documentation/devicetree/bindings/interconnect/qcom,qcs404.yaml
View File

@ -1,77 +0,0 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,qcs404.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm QCS404 Network-On-Chip interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
description: |
The Qualcomm QCS404 interconnect providers support adjusting the
bandwidth requirements between the various NoC fabrics.
properties:
reg:
maxItems: 1
compatible:
enum:
- qcom,qcs404-bimc
- qcom,qcs404-pcnoc
- qcom,qcs404-snoc
'#interconnect-cells':
const: 1
clock-names:
items:
- const: bus
- const: bus_a
clocks:
items:
- description: Bus Clock
- description: Bus A Clock
required:
- compatible
- reg
- '#interconnect-cells'
- clock-names
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmcc.h>
bimc: interconnect@400000 {
reg = <0x00400000 0x80000>;
compatible = "qcom,qcs404-bimc";
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
<&rpmcc RPM_SMD_BIMC_A_CLK>;
};
pnoc: interconnect@500000 {
reg = <0x00500000 0x15080>;
compatible = "qcom,qcs404-pcnoc";
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_PNOC_CLK>,
<&rpmcc RPM_SMD_PNOC_A_CLK>;
};
snoc: interconnect@580000 {
reg = <0x00580000 0x23080>;
compatible = "qcom,qcs404-snoc";
#interconnect-cells = <1>;
clock-names = "bus", "bus_a";
clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
<&rpmcc RPM_SMD_SNOC_A_CLK>;
};

22
Documentation/devicetree/bindings/interconnect/qcom,msm8916.yaml → Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml
View File

@ -1,27 +1,35 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/qcom,msm8916.yaml#
$id: http://devicetree.org/schemas/interconnect/qcom,rpm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm MSM8916 Network-On-Chip interconnect
title: Qualcomm RPM Network-On-Chip Interconnect
maintainers:
- Georgi Djakov <georgi.djakov@linaro.org>
description: |
The Qualcomm MSM8916 interconnect providers support adjusting the
bandwidth requirements between the various NoC fabrics.
RPM interconnect providers support system bandwidth requirements through
RPM processor. The provider is able to communicate with the RPM through
the RPM shared memory device.
properties:
reg:
maxItems: 1
compatible:
enum:
- qcom,msm8916-bimc
- qcom,msm8916-pcnoc
- qcom,msm8916-snoc
reg:
maxItems: 1
- qcom,msm8939-bimc
- qcom,msm8939-pcnoc
- qcom,msm8939-snoc
- qcom,msm8939-snoc-mm
- qcom,qcs404-bimc
- qcom,qcs404-pcnoc
- qcom,qcs404-snoc
'#interconnect-cells':
const: 1

4
Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
View File

@ -45,6 +45,10 @@ properties:
- qcom,sdm845-mem-noc
- qcom,sdm845-mmss-noc
- qcom,sdm845-system-noc
- qcom,sdx55-ipa-virt
- qcom,sdx55-mc-virt
- qcom,sdx55-mem-noc
- qcom,sdx55-system-noc
- qcom,sm8150-aggre1-noc
- qcom,sm8150-aggre2-noc
- qcom,sm8150-camnoc-noc

13
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
View File

@ -8,10 +8,11 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: SiFive Platform-Level Interrupt Controller (PLIC)
description:
SiFive SOCs include an implementation of the Platform-Level Interrupt Controller
(PLIC) high-level specification in the RISC-V Privileged Architecture
specification. The PLIC connects all external interrupts in the system to all
hart contexts in the system, via the external interrupt source in each hart.
SiFive SoCs and other RISC-V SoCs include an implementation of the
Platform-Level Interrupt Controller (PLIC) high-level specification in
the RISC-V Privileged Architecture specification. The PLIC connects all
external interrupts in the system to all hart contexts in the system, via
the external interrupt source in each hart.
A hart context is a privilege mode in a hardware execution thread. For example,
in an 4 core system with 2-way SMT, you have 8 harts and probably at least two
@ -42,7 +43,9 @@ maintainers:
properties:
compatible:
items:
- const: sifive,fu540-c000-plic
- enum:
- sifive,fu540-c000-plic
- canaan,k210-plic
- const: sifive,plic-1.0.0
reg:

113
Documentation/devicetree/bindings/leds/leds-lgm.yaml Normal file
View File

@ -0,0 +1,113 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/leds/leds-lgm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel Lightning Mountain (LGM) SoC LED Serial Shift Output (SSO) Controller driver
maintainers:
- Zhu, Yi Xin <Yixin.zhu@intel.com>
- Amireddy Mallikarjuna reddy <mallikarjunax.reddy@intel.com>
properties:
compatible:
const: intel,lgm-ssoled
gpio-controller: true
'#gpio-cells':
const: 2
ngpios:
minimum: 0
maximum: 32
description:
Number of GPIOs this controller provides.
intel,sso-update-rate-hz:
description:
Blink frequency for SOUTs in Hz.
led-controller:
type: object
description:
This sub-node must contain a sub-node for each leds.
additionalProperties: false
patternProperties:
"^led@[0-23]$":
type: object
properties:
reg:
description: Index of the LED.
minimum: 0
maximum: 2
intel,sso-hw-trigger:
type: boolean
description: This property indicates Hardware driven/control LED.
intel,sso-hw-blink:
type: boolean
description: This property indicates Enable LED blink by Hardware.
intel,sso-blink-rate-hz:
description: LED HW blink frequency.
retain-state-suspended:
type: boolean
description: The suspend state of LED can be retained.
retain-state-shutdown:
type: boolean
description: Retain the state of the LED on shutdown.
required:
- compatible
- reg
- clocks
- clock-names
- "#gpio-cells"
- gpio-controller
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/intel,lgm-clk.h>
#include <dt-bindings/leds/common.h>
ssogpio: ssogpio@e0d40000 {
compatible = "intel,sso-led";
reg = <0xE0D40000 0x2E4>;
gpio-controller;
#gpio-cells = <2>;
ngpios = <32>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ledc>;
clocks = <&cgu0 LGM_GCLK_LEDC0>, <&afeclk>;
clock-names = "sso", "fpid";
intel,sso-update-rate-hz = <250000>;
led-controller {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
function = "gphy";
color = <LED_COLOR_ID_GREEN>;
led-gpio = <&ssogpio 0 0>;
};
led@23 {
reg = <23>;
function = LED_FUNCTION_POWER;
color = <LED_COLOR_ID_GREEN>;
led-gpio = <&ssogpio 23 0>;
};
};
};

4
Documentation/devicetree/bindings/mailbox/omap-mailbox.txt
View File

@ -28,6 +28,9 @@ SoCs has each of these instances form a cluster and combine multiple clusters
into a single IP block present within the Main NavSS. The interrupt lines from
all these clusters are multiplexed and routed to different processor subsystems
over a limited number of common interrupt output lines of an Interrupt Router.
The AM64x SoCS also uses a single IP block comprising of multiple clusters,
but the number of clusters are smaller, and the interrupt output lines are
connected directly to various processors.
Mailbox Device Node:
====================
@ -42,6 +45,7 @@ Required properties:
"ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx,
AM43xx and DRA7xx SoCs
"ti,am654-mailbox" for K3 AM65x and J721E SoCs
"ti,am64-mailbox" for K3 AM64x SoCs
- reg: Contains the mailbox register address range (base
address and length)
- interrupts: Contains the interrupt information for the mailbox

34
Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml
View File

@ -24,6 +24,7 @@ properties:
- qcom,msm8998-apcs-hmss-global
- qcom,qcs404-apcs-apps-global
- qcom,sc7180-apss-shared
- qcom,sc8180x-apss-shared
- qcom,sdm660-apcs-hmss-global
- qcom,sdm845-apss-shared
- qcom,sm8150-apss-shared
@ -33,9 +34,11 @@ properties:
clocks:
description: phandles to the parent clocks of the clock driver
minItems: 2
items:
- description: primary pll parent of the clock driver
- description: auxiliary parent
- description: reference clock
'#mbox-cells':
const: 1
@ -44,9 +47,11 @@ properties:
const: 0
clock-names:
minItems: 2
items:
- const: pll
- const: aux
- const: ref
required:
- compatible
@ -55,6 +60,35 @@ required:
additionalProperties: false
allOf:
- if:
properties:
compatible:
enum:
- qcom,ipq6018-apcs-apps-global
- qcom,ipq8074-apcs-apps-global
- qcom,msm8916-apcs-kpss-global
- qcom,msm8994-apcs-kpss-global
- qcom,msm8996-apcs-hmss-global
- qcom,msm8998-apcs-hmss-global
- qcom,qcs404-apcs-apps-global
- qcom,sc7180-apss-shared
- qcom,sdm660-apcs-hmss-global
- qcom,sdm845-apss-shared
- qcom,sm8150-apss-shared
then:
properties:
clocks:
maxItems: 2
- if:
properties:
compatible:
enum:
- qcom,sdx55-apcs-gcc
then:
properties:
clocks:
maxItems: 3
examples:
# Example apcs with msm8996

14
Documentation/devicetree/bindings/media/i2c/imx258.yaml
View File

@ -49,10 +49,14 @@ properties:
# See ../video-interfaces.txt for more details
port:
type: object
$ref: /schemas/graph.yaml#/properties/port
additionalProperties: false
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
oneOf:
@ -65,11 +69,7 @@ properties:
- const: 1
- const: 2
link-frequencies:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint64-array
description:
Allowed data bus frequencies.
link-frequencies: true
required:
- data-lanes

5
Documentation/devicetree/bindings/media/i2c/ovti,ov5647.yaml
View File

@ -31,7 +31,8 @@ properties:
maxItems: 1
port:
$ref: /schemas/graph.yaml#/$defs/port-base
$ref: /schemas/graph.yaml#/properties/port
additionalProperties: false
properties:
endpoint:
@ -41,8 +42,6 @@ properties:
properties:
clock-noncontinuous: true
additionalProperties: false
required:
- compatible
- reg

16
Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
View File

@ -44,19 +44,17 @@ properties:
description: Reset Pin GPIO Control (active low)
port:
type: object
description: MIPI CSI-2 transmitter port
$ref: /schemas/graph.yaml#/properties/port
additionalProperties: false
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
remote-endpoint: true
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: Allowed MIPI CSI-2 link frequencies
link-frequencies: true
data-lanes:
minItems: 1
@ -65,10 +63,6 @@ properties:
required:
- data-lanes
- link-frequencies
- remote-endpoint
required:
- endpoint
required:
- compatible

16
Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
View File

@ -44,19 +44,17 @@ properties:
description: Reset Pin GPIO Control (active low)
port:
type: object
description: MIPI CSI-2 transmitter port
$ref: /schemas/graph.yaml#/properties/port
additionalProperties: false
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
remote-endpoint: true
link-frequencies:
$ref: /schemas/types.yaml#/definitions/uint64-array
description: Allowed MIPI CSI-2 link frequencies
link-frequencies: true
data-lanes:
minItems: 1
@ -65,10 +63,6 @@ properties:
required:
- data-lanes
- link-frequencies
- remote-endpoint
required:
- endpoint
required:
- compatible

11
Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml
View File

@ -36,18 +36,17 @@ properties:
description: Reference to the GPIO connected to the XCLR pin, if any.
port:
type: object
additionalProperties: false
$ref: /schemas/graph.yaml#/properties/port
properties:
endpoint:
type: object
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
$ref: ../video-interfaces.yaml#/properties/data-lanes
link-frequencies:
$ref: ../video-interfaces.yaml#/properties/link-frequencies
data-lanes: true
link-frequencies: true
required:
- data-lanes

109
Documentation/devicetree/bindings/mfd/canaan,k210-sysctl.yaml Normal file
View File

@ -0,0 +1,109 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/canaan,k210-sysctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Canaan Kendryte K210 System Controller Device Tree Bindings
maintainers:
- Damien Le Moal <damien.lemoal@wdc.com>
description:
Canaan Inc. Kendryte K210 SoC system controller which provides a
register map for controlling the clocks, reset signals and pin power
domains of the SoC.
properties:
compatible:
items:
- const: canaan,k210-sysctl
- const: syscon
- const: simple-mfd
clocks:
maxItems: 1
description:
System controller Advanced Power Bus (APB) interface clock source.
clock-names:
items:
- const: pclk
reg:
maxItems: 1
clock-controller:
# Child node
type: object
$ref: "../clock/canaan,k210-clk.yaml"
description:
Clock controller for the SoC clocks. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/clock/canaan,k210-clk.yaml.
reset-controller:
# Child node
type: object
$ref: "../reset/canaan,k210-rst.yaml"
description:
Reset controller for the SoC. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/reset/canaan,k210-rst.yaml.
syscon-reboot:
# Child node
type: object
$ref: "../power/reset/syscon-reboot.yaml"
description:
Reboot method for the SoC. This child node definition
should follow the bindings specified in
Documentation/devicetree/bindings/power/reset/syscon-reboot.yaml.
required:
- compatible
- clocks
- reg
- clock-controller
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/k210-clk.h>
#include <dt-bindings/reset/k210-rst.h>
clocks {
in0: oscllator {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <26000000>;
};
};
sysctl: syscon@50440000 {
compatible = "canaan,k210-sysctl",
"syscon", "simple-mfd";
reg = <0x50440000 0x100>;
clocks = <&sysclk K210_CLK_APB1>;
clock-names = "pclk";
sysclk: clock-controller {
#clock-cells = <1>;
compatible = "canaan,k210-clk";
clocks = <&in0>;
};
sysrst: reset-controller {
compatible = "canaan,k210-rst";
#reset-cells = <1>;
};
reboot: syscon-reboot {
compatible = "syscon-reboot";
regmap = <&sysctl>;
offset = <48>;
mask = <1>;
value = <1>;
};
};

1
Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
View File

@ -4,6 +4,7 @@ Required properties:
- compatible : shall be one of:
"atmel,at93c46d"
"eeprom-93xx46"
"microchip,93lc46b"
- data-size : number of data bits per word (either 8 or 16)
Optional properties:

49
Documentation/devicetree/bindings/nvmem/rmem.yaml Normal file
View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/nvmem/rmem.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Reserved Memory Based nvmem Device
maintainers:
- Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
allOf:
- $ref: "nvmem.yaml#"
properties:
compatible:
items:
- enum:
- raspberrypi,bootloader-config
- const: nvmem-rmem
no-map:
$ref: /schemas/types.yaml#/definitions/flag
description:
Avoid creating a virtual mapping of the region as part of the OS'
standard mapping of system memory.
required:
- compatible
- no-map
unevaluatedProperties: false
examples:
- |
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
blconfig: nvram@10000000 {
compatible = "raspberrypi,bootloader-config", "nvmem-rmem";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x10000000 0x1000>;
no-map;
};
};
...

37
Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
View File

@ -14,6 +14,7 @@ properties:
items:
- enum:
- brcm,bcm2711-pcie # The Raspberry Pi 4
- brcm,bcm4908-pcie
- brcm,bcm7211-pcie # Broadcom STB version of RPi4
- brcm,bcm7278-pcie # Broadcom 7278 Arm
- brcm,bcm7216-pcie # Broadcom 7216 Arm
@ -63,15 +64,6 @@ properties:
aspm-no-l0s: true
resets:
description: for "brcm,bcm7216-pcie", must be a valid reset
phandle pointing to the RESCAL reset controller provider node.
$ref: "/schemas/types.yaml#/definitions/phandle"
reset-names:
items:
- const: rescal
brcm,scb-sizes:
description: u64 giving the 64bit PCIe memory
viewport size of a memory controller. There may be up to
@ -98,12 +90,39 @@ required:
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
- if:
properties:
compatible:
contains:
const: brcm,bcm4908-pcie
then:
properties:
resets:
items:
- description: reset controller handling the PERST# signal
reset-names:
items:
- const: perst
required:
- resets
- reset-names
- if:
properties:
compatible:
contains:
const: brcm,bcm7216-pcie
then:
properties:
resets:
items:
- description: phandle pointing to the RESCAL reset controller
reset-names:
items:
- const: rescal
required:
- resets
- reset-names

1
Documentation/devicetree/bindings/pci/layerscape-pci.txt
View File

@ -26,6 +26,7 @@ Required properties:
"fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
"fsl,ls1088a-pcie-ep", "fsl,ls-pcie-ep"
"fsl,ls2088a-pcie-ep", "fsl,ls-pcie-ep"
"fsl,lx2160ar2-pcie-ep", "fsl,ls-pcie-ep"
- reg: base addresses and lengths of the PCIe controller register blocks.
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.

92
Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml Normal file
View File

@ -0,0 +1,92 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/microchip,pcie-host.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip PCIe Root Port Bridge Controller Device Tree Bindings
maintainers:
- Daire McNamara <daire.mcnamara@microchip.com>
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
properties:
compatible:
const: microchip,pcie-host-1.0 # PolarFire
reg:
maxItems: 2
reg-names:
items:
- const: cfg
- const: apb
interrupts:
minItems: 1
maxItems: 2
items:
- description: PCIe host controller
- description: builtin MSI controller
interrupt-names:
minItems: 1
maxItems: 2
items:
- const: pcie
- const: msi
ranges:
maxItems: 1
msi-controller:
description: Identifies the node as an MSI controller.
msi-parent:
description: MSI controller the device is capable of using.
required:
- reg
- reg-names
- "#interrupt-cells"
- interrupts
- interrupt-map-mask
- interrupt-map
- msi-controller
unevaluatedProperties: false
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <2>;
pcie0: pcie@2030000000 {
compatible = "microchip,pcie-host-1.0";
reg = <0x0 0x70000000 0x0 0x08000000>,
<0x0 0x43000000 0x0 0x00010000>;
reg-names = "cfg", "apb";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
interrupts = <119>;
interrupt-map-mask = <0x0 0x0 0x0 0x7>;
interrupt-map = <0 0 0 1 &pcie_intc0 0>,
<0 0 0 2 &pcie_intc0 1>,
<0 0 0 3 &pcie_intc0 2>,
<0 0 0 4 &pcie_intc0 3>;
interrupt-parent = <&plic0>;
msi-parent = <&pcie0>;
msi-controller;
bus-range = <0x00 0x7f>;
ranges = <0x03000000 0x0 0x78000000 0x0 0x78000000 0x0 0x04000000>;
pcie_intc0: interrupt-controller {
#address-cells = <0>;
#interrupt-cells = <1>;
interrupt-controller;
};
};
};

17
Documentation/devicetree/bindings/pci/qcom,pcie.txt
View File

@ -132,8 +132,8 @@
- "master_bus" AXI Master clock
- "slave_bus" AXI Slave clock
-clock-names:
Usage: required for sdm845 and sm8250
- clock-names:
Usage: required for sdm845
Value type: <stringlist>
Definition: Should contain the following entries
- "aux" Auxiliary clock
@ -144,6 +144,19 @@
- "tbu" PCIe TBU clock
- "pipe" PIPE clock
- clock-names:
Usage: required for sm8250
Value type: <stringlist>
Definition: Should contain the following entries
- "aux" Auxiliary clock
- "cfg" Configuration clock
- "bus_master" Master AXI clock
- "bus_slave" Slave AXI clock
- "slave_q2a" Slave Q2A clock
- "tbu" PCIe TBU clock
- "ddrss_sf_tbu" PCIe SF TBU clock
- "pipe" PIPE clock
- resets:
Usage: required
Value type: <prop-encoded-array>

86
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.txt
View File

@ -1,86 +0,0 @@
Broadcom STB USB PHY
Required properties:
- compatible: should be one of
"brcm,brcmstb-usb-phy"
"brcm,bcm7216-usb-phy"
"brcm,bcm7211-usb-phy"
- reg and reg-names properties requirements are specific to the
compatible string.
"brcm,brcmstb-usb-phy":
- reg: 1 or 2 offset and length pairs. One for the base CTRL registers
and an optional pair for systems with USB 3.x support
- reg-names: not specified
"brcm,bcm7216-usb-phy":
- reg: 3 offset and length pairs for CTRL, XHCI_EC and XHCI_GBL
registers
- reg-names: "ctrl", "xhci_ec", "xhci_gbl"
"brcm,bcm7211-usb-phy":
- reg: 5 offset and length pairs for CTRL, XHCI_EC, XHCI_GBL,
USB_PHY and USB_MDIO registers and an optional pair
for the BDC registers
- reg-names: "ctrl", "xhci_ec", "xhci_gbl", "usb_phy", "usb_mdio", "bdc_ec"
- #phy-cells: Shall be 1 as it expects one argument for setting
the type of the PHY. Possible values are:
- PHY_TYPE_USB2 for USB1.1/2.0 PHY
- PHY_TYPE_USB3 for USB3.x PHY
Optional Properties:
- clocks : clock phandles.
- clock-names: String, clock name.
- interrupts: wakeup interrupt
- interrupt-names: "wakeup"
- brcm,ipp: Boolean, Invert Port Power.
Possible values are: 0 (Don't invert), 1 (Invert)
- brcm,ioc: Boolean, Invert Over Current detection.
Possible values are: 0 (Don't invert), 1 (Invert)
- dr_mode: String, PHY Device mode.
Possible values are: "host", "peripheral ", "drd" or "typec-pd"
If this property is not defined, the phy will default to "host" mode.
- brcm,syscon-piarbctl: phandle to syscon for handling config registers
NOTE: one or both of the following two properties must be set
- brcm,has-xhci: Boolean indicating the phy has an XHCI phy.
- brcm,has-eohci: Boolean indicating the phy has an EHCI/OHCI phy.
Example:
usbphy_0: usb-phy@f0470200 {
reg = <0xf0470200 0xb8>,
<0xf0471940 0x6c0>;
compatible = "brcm,brcmstb-usb-phy";
#phy-cells = <1>;
dr_mode = "host"
brcm,ioc = <1>;
brcm,ipp = <1>;
brcm,has-xhci;
brcm,has-eohci;
clocks = <&usb20>, <&usb30>;
clock-names = "sw_usb", "sw_usb3";
};
usb-phy@29f0200 {
reg = <0x29f0200 0x200>,
<0x29c0880 0x30>,
<0x29cc100 0x534>,
<0x2808000 0x24>,
<0x2980080 0x8>;
reg-names = "ctrl",
"xhci_ec",
"xhci_gbl",
"usb_phy",
"usb_mdio";
brcm,ioc = <0x0>;
brcm,ipp = <0x0>;
compatible = "brcm,bcm7211-usb-phy";
interrupts = <0x30>;
interrupt-parent = <&vpu_intr1_nosec_intc>;
interrupt-names = "wake";
#phy-cells = <0x1>;
brcm,has-xhci;
syscon-piarbctl = <&syscon_piarbctl>;
clocks = <&scmi_clk 256>;
clock-names = "sw_usb";
};

196
Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml Normal file
View File

@ -0,0 +1,196 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/brcm,brcmstb-usb-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom STB USB PHY
description: Broadcom's PHY that handles EHCI/OHCI and/or XHCI
maintainers:
- Al Cooper <alcooperx@gmail.com>
- Rafał Miłecki <rafal@milecki.pl>
properties:
compatible:
enum:
- brcm,bcm4908-usb-phy
- brcm,bcm7211-usb-phy
- brcm,bcm7216-usb-phy
- brcm,brcmstb-usb-phy
reg:
minItems: 1
maxItems: 6
items:
- description: the base CTRL register
- description: XHCI EC register
- description: XHCI GBL register
- description: USB PHY register
- description: USB MDIO register
- description: BDC register
reg-names:
minItems: 1
maxItems: 6
items:
- const: ctrl
- const: xhci_ec
- const: xhci_gbl
- const: usb_phy
- const: usb_mdio
- const: bdc_ec
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
maxItems: 2
items:
- const: sw_usb
- const: sw_usb3
interrupts:
description: wakeup interrupt
interrupt-names:
const: wake
brcm,ipp:
$ref: /schemas/types.yaml#/definitions/uint32
description: Invert Port Power
minimum: 0
maximum: 1
brcm,ioc:
$ref: /schemas/types.yaml#/definitions/uint32
description: Invert Over Current detection
minimum: 0
maximum: 1
dr_mode:
description: PHY Device mode. If this property is not defined, the PHY will
default to "host" mode.
enum:
- host
- peripheral
- drd
- typec-pd
brcm,syscon-piarbctl:
description: phandle to syscon for handling config registers
$ref: /schemas/types.yaml#/definitions/phandle
brcm,has-xhci:
description: Indicates the PHY has an XHCI PHY.
type: boolean
brcm,has-eohci:
description: Indicates the PHY has an EHCI/OHCI PHY.
type: boolean
"#phy-cells":
description: |
Cell allows setting the type of the PHY. Possible values are:
- PHY_TYPE_USB2 for USB1.1/2.0 PHY
- PHY_TYPE_USB3 for USB3.x PHY
const: 1
required:
- reg
- "#phy-cells"
anyOf:
- required:
- brcm,has-xhci
- required:
- brcm,has-eohci
allOf:
- if:
properties:
compatible:
contains:
enum:
- const: brcm,bcm4908-usb-phy
- const: brcm,brcmstb-usb-phy
then:
properties:
reg:
minItems: 1
maxItems: 2
- if:
properties:
compatible:
contains:
const: brcm,bcm7211-usb-phy
then:
properties:
reg:
minItems: 5
maxItems: 6
reg-names:
minItems: 5
maxItems: 6
- if:
properties:
compatible:
contains:
const: brcm,bcm7216-usb-phy
then:
properties:
reg:
minItems: 3
maxItems: 3
reg-names:
minItems: 3
maxItems: 3
additionalProperties: false
examples:
- |
#include <dt-bindings/phy/phy.h>
usb-phy@f0470200 {
compatible = "brcm,brcmstb-usb-phy";
reg = <0xf0470200 0xb8>,
<0xf0471940 0x6c0>;
#phy-cells = <1>;
dr_mode = "host";
brcm,ioc = <1>;
brcm,ipp = <1>;
brcm,has-xhci;
brcm,has-eohci;
clocks = <&usb20>, <&usb30>;
clock-names = "sw_usb", "sw_usb3";
};
- |
#include <dt-bindings/phy/phy.h>
usb-phy@29f0200 {
compatible = "brcm,bcm7211-usb-phy";
reg = <0x29f0200 0x200>,
<0x29c0880 0x30>,
<0x29cc100 0x534>,
<0x2808000 0x24>,
<0x2980080 0x8>;
reg-names = "ctrl",
"xhci_ec",
"xhci_gbl",
"usb_phy",
"usb_mdio";
brcm,ioc = <0x0>;
brcm,ipp = <0x0>;
interrupts = <0x30>;
interrupt-parent = <&vpu_intr1_nosec_intc>;
interrupt-names = "wake";
#phy-cells = <0x1>;
brcm,has-xhci;
brcm,syscon-piarbctl = <&syscon_piarbctl>;
clocks = <&scmi_clk 256>;
clock-names = "sw_usb";
};

85
Documentation/devicetree/bindings/phy/mediatek,dsi-phy.yaml Normal file
View File

@ -0,0 +1,85 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2020 MediaTek
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/mediatek,dsi-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek MIPI Display Serial Interface (DSI) PHY binding
maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
- Philipp Zabel <p.zabel@pengutronix.de>
- Chunfeng Yun <chunfeng.yun@mediatek.com>
description: The MIPI DSI PHY supports up to 4-lane output.
properties:
$nodename:
pattern: "^dsi-phy@[0-9a-f]+$"
compatible:
enum:
- mediatek,mt2701-mipi-tx
- mediatek,mt7623-mipi-tx
- mediatek,mt8173-mipi-tx
- mediatek,mt8183-mipi-tx
reg:
maxItems: 1
clocks:
items:
- description: PLL reference clock
clock-output-names:
maxItems: 1
"#phy-cells":
const: 0
"#clock-cells":
const: 0
nvmem-cells:
maxItems: 1
description: A phandle to the calibration data provided by a nvmem device,
if unspecified, default values shall be used.
nvmem-cell-names:
items:
- const: calibration-data
drive-strength-microamp:
description: adjust driving current
multipleOf: 200
minimum: 2000
maximum: 6000
default: 4600
required:
- compatible
- reg
- clocks
- clock-output-names
- "#phy-cells"
- "#clock-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt8173-clk.h>
dsi-phy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0x10215000 0x1000>;
clocks = <&clk26m>;
clock-output-names = "mipi_tx0_pll";
drive-strength-microamp = <4000>;
nvmem-cells= <&mipi_tx_calibration>;
nvmem-cell-names = "calibration-data";
#clock-cells = <0>;
#phy-cells = <0>;
};
...

92
Documentation/devicetree/bindings/phy/mediatek,hdmi-phy.yaml Normal file
View File

@ -0,0 +1,92 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2020 MediaTek
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/mediatek,hdmi-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek High Definition Multimedia Interface (HDMI) PHY binding
maintainers:
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
- Philipp Zabel <p.zabel@pengutronix.de>
- Chunfeng Yun <chunfeng.yun@mediatek.com>
description: |
The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
output and drives the HDMI pads.
properties:
$nodename:
pattern: "^hdmi-phy@[0-9a-f]+$"
compatible:
enum:
- mediatek,mt2701-hdmi-phy
- mediatek,mt7623-hdmi-phy
- mediatek,mt8173-hdmi-phy
reg:
maxItems: 1
clocks:
items:
- description: PLL reference clock
clock-names:
items:
- const: pll_ref
clock-output-names:
items:
- const: hdmitx_dig_cts
"#phy-cells":
const: 0
"#clock-cells":
const: 0
mediatek,ibias:
description:
TX DRV bias current for < 1.65Gbps
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 63
default: 0xa
mediatek,ibias_up:
description:
TX DRV bias current for >= 1.65Gbps
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 63
default: 0x1c
required:
- compatible
- reg
- clocks
- clock-names
- clock-output-names
- "#phy-cells"
- "#clock-cells"
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt8173-clk.h>
hdmi_phy: hdmi-phy@10209100 {
compatible = "mediatek,mt8173-hdmi-phy";
reg = <0x10209100 0x24>;
clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
clock-names = "pll_ref";
clock-output-names = "hdmitx_dig_cts";
mediatek,ibias = <0xa>;
mediatek,ibias_up = <0x1c>;
#clock-cells = <0>;
#phy-cells = <0>;
};
...

260
Documentation/devicetree/bindings/phy/mediatek,tphy.yaml Normal file
View File

@ -0,0 +1,260 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2020 MediaTek
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/mediatek,tphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek T-PHY Controller Device Tree Bindings
maintainers:
- Chunfeng Yun <chunfeng.yun@mediatek.com>
description: |
The T-PHY controller supports physical layer functionality for a number of
controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA.
Layout differences of banks between T-PHY V1 (mt8173/mt2701) and
T-PHY V2 (mt2712) when works on USB mode:
-----------------------------------
Version 1:
port offset bank
shared 0x0000 SPLLC
0x0100 FMREG
u2 port0 0x0800 U2PHY_COM
u3 port0 0x0900 U3PHYD
0x0a00 U3PHYD_BANK2
0x0b00 U3PHYA
0x0c00 U3PHYA_DA
u2 port1 0x1000 U2PHY_COM
u3 port1 0x1100 U3PHYD
0x1200 U3PHYD_BANK2
0x1300 U3PHYA
0x1400 U3PHYA_DA
u2 port2 0x1800 U2PHY_COM
...
Version 2:
port offset bank
u2 port0 0x0000 MISC
0x0100 FMREG
0x0300 U2PHY_COM
u3 port0 0x0700 SPLLC
0x0800 CHIP
0x0900 U3PHYD
0x0a00 U3PHYD_BANK2
0x0b00 U3PHYA
0x0c00 U3PHYA_DA
u2 port1 0x1000 MISC
0x1100 FMREG
0x1300 U2PHY_COM
u3 port1 0x1700 SPLLC
0x1800 CHIP
0x1900 U3PHYD
0x1a00 U3PHYD_BANK2
0x1b00 U3PHYA
0x1c00 U3PHYA_DA
u2 port2 0x2000 MISC
...
SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back
into each port; a new bank MISC for u2 ports and CHIP for u3 ports are
added on V2.
properties:
$nodename:
pattern: "^t-phy@[0-9a-f]+$"
compatible:
oneOf:
- items:
- enum:
- mediatek,mt2701-tphy
- mediatek,mt7623-tphy
- mediatek,mt7622-tphy
- mediatek,mt8516-tphy
- const: mediatek,generic-tphy-v1
- items:
- enum:
- mediatek,mt2712-tphy
- mediatek,mt7629-tphy
- mediatek,mt8183-tphy
- const: mediatek,generic-tphy-v2
- const: mediatek,mt2701-u3phy
deprecated: true
- const: mediatek,mt2712-u3phy
deprecated: true
- const: mediatek,mt8173-u3phy
reg:
description:
Register shared by multiple ports, exclude port's private register.
It is needed for T-PHY V1, such as mt2701 and mt8173, but not for
T-PHY V2, such as mt2712.
maxItems: 1
"#address-cells":
enum: [1, 2]
"#size-cells":
enum: [1, 2]
# Used with non-empty value if optional 'reg' is not provided.
# The format of the value is an arbitrary number of triplets of
# (child-bus-address, parent-bus-address, length).
ranges: true
mediatek,src-ref-clk-mhz:
description:
Frequency of reference clock for slew rate calibrate
default: 26
mediatek,src-coef:
description:
Coefficient for slew rate calibrate, depends on SoC process
$ref: /schemas/types.yaml#/definitions/uint32
default: 28
# Required child node:
patternProperties:
"^usb-phy@[0-9a-f]+$":
type: object
description:
A sub-node is required for each port the controller provides.
Address range information including the usual 'reg' property
is used inside these nodes to describe the controller's topology.
properties:
reg:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
items:
- description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz)
- description: Reference clock of analog phy
description:
Uses both clocks if the clock of analog and digital phys are
separated, otherwise uses "ref" clock only if needed.
clock-names:
minItems: 1
maxItems: 2
items:
- const: ref
- const: da_ref
"#phy-cells":
const: 1
description: |
The cells contain the following arguments.
- description: The PHY type
enum:
- PHY_TYPE_USB2
- PHY_TYPE_USB3
- PHY_TYPE_PCIE
- PHY_TYPE_SATA
# The following optional vendor properties are only for debug or HQA test
mediatek,eye-src:
description:
The value of slew rate calibrate (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 7
mediatek,eye-vrt:
description:
The selection of VRT reference voltage (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 7
mediatek,eye-term:
description:
The selection of HS_TX TERM reference voltage (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 7
mediatek,intr:
description:
The selection of internal resistor (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 31
mediatek,discth:
description:
The selection of disconnect threshold (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 15
mediatek,bc12:
description:
Specify the flag to enable BC1.2 if support it
type: boolean
required:
- reg
- "#phy-cells"
additionalProperties: false
required:
- compatible
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt8173-clk.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/phy/phy.h>
usb@11271000 {
compatible = "mediatek,mt8173-mtu3", "mediatek,mtu3";
reg = <0x11271000 0x3000>, <0x11280700 0x0100>;
reg-names = "mac", "ippc";
phys = <&u2port0 PHY_TYPE_USB2>,
<&u3port0 PHY_TYPE_USB3>,
<&u2port1 PHY_TYPE_USB2>;
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_LOW>;
clocks = <&topckgen CLK_TOP_USB30_SEL>;
clock-names = "sys_ck";
};
t-phy@11290000 {
compatible = "mediatek,mt8173-u3phy";
reg = <0x11290000 0x800>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
u2port0: usb-phy@11290800 {
reg = <0x11290800 0x100>;
clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>, <&clk48m>;
clock-names = "ref", "da_ref";
#phy-cells = <1>;
};
u3port0: usb-phy@11290900 {
reg = <0x11290900 0x700>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
};
u2port1: usb-phy@11291000 {
reg = <0x11291000 0x100>;
#phy-cells = <1>;
};
};
...

64
Documentation/devicetree/bindings/phy/mediatek,ufs-phy.yaml Normal file
View File

@ -0,0 +1,64 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2020 MediaTek
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/mediatek,ufs-phy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Universal Flash Storage (UFS) M-PHY binding
maintainers:
- Stanley Chu <stanley.chu@mediatek.com>
- Chunfeng Yun <chunfeng.yun@mediatek.com>
description: |
UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
Each UFS M-PHY node should have its own node.
To bind UFS M-PHY with UFS host controller, the controller node should
contain a phandle reference to UFS M-PHY node.
properties:
$nodename:
pattern: "^ufs-phy@[0-9a-f]+$"
compatible:
const: mediatek,mt8183-ufsphy
reg:
maxItems: 1
clocks:
items:
- description: Unipro core control clock.
- description: M-PHY core control clock.
clock-names:
items:
- const: unipro
- const: mp
"#phy-cells":
const: 0
required:
- compatible
- reg
- "#phy-cells"
- clocks
- clock-names
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt8183-clk.h>
ufsphy: ufs-phy@11fa0000 {
compatible = "mediatek,mt8183-ufsphy";
reg = <0x11fa0000 0xc000>;
clocks = <&infracfg CLK_INFRA_UNIPRO_SCK>,
<&infracfg CLK_INFRA_UFS_MP_SAP_BCLK>;
clock-names = "unipro", "mp";
#phy-cells = <0>;
};
...

199
Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml Normal file
View File

@ -0,0 +1,199 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (c) 2020 MediaTek
%YAML 1.2
---
$id: http://devicetree.org/schemas/phy/mediatek,xsphy.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek XS-PHY Controller Device Tree Bindings
maintainers:
- Chunfeng Yun <chunfeng.yun@mediatek.com>
description: |
The XS-PHY controller supports physical layer functionality for USB3.1
GEN2 controller on MediaTek SoCs.
Banks layout of xsphy
----------------------------------
port offset bank
u2 port0 0x0000 MISC
0x0100 FMREG
0x0300 U2PHY_COM
u2 port1 0x1000 MISC
0x1100 FMREG
0x1300 U2PHY_COM
u2 port2 0x2000 MISC
...
u31 common 0x3000 DIG_GLB
0x3100 PHYA_GLB
u31 port0 0x3400 DIG_LN_TOP
0x3500 DIG_LN_TX0
0x3600 DIG_LN_RX0
0x3700 DIG_LN_DAIF
0x3800 PHYA_LN
u31 port1 0x3a00 DIG_LN_TOP
0x3b00 DIG_LN_TX0
0x3c00 DIG_LN_RX0
0x3d00 DIG_LN_DAIF
0x3e00 PHYA_LN
...
DIG_GLB & PHYA_GLB are shared by U31 ports.
properties:
$nodename:
pattern: "^xs-phy@[0-9a-f]+$"
compatible:
items:
- enum:
- mediatek,mt3611-xsphy
- mediatek,mt3612-xsphy
- const: mediatek,xsphy
reg:
description:
Register shared by multiple U3 ports, exclude port's private register,
if only U2 ports provided, shouldn't use the property.
maxItems: 1
"#address-cells":
enum: [1, 2]
"#size-cells":
enum: [1, 2]
ranges: true
mediatek,src-ref-clk-mhz:
description:
Frequency of reference clock for slew rate calibrate
default: 26
mediatek,src-coef:
description:
Coefficient for slew rate calibrate, depends on SoC process
$ref: /schemas/types.yaml#/definitions/uint32
default: 17
# Required child node:
patternProperties:
"^usb-phy@[0-9a-f]+$":
type: object
description:
A sub-node is required for each port the controller provides.
Address range information including the usual 'reg' property
is used inside these nodes to describe the controller's topology.
properties:
reg:
maxItems: 1
clocks:
items:
- description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz)
clock-names:
items:
- const: ref
"#phy-cells":
const: 1
description: |
The cells contain the following arguments.
- description: The PHY type
enum:
- PHY_TYPE_USB2
- PHY_TYPE_USB3
# The following optional vendor properties are only for debug or HQA test
mediatek,eye-src:
description:
The value of slew rate calibrate (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 7
mediatek,eye-vrt:
description:
The selection of VRT reference voltage (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 7
mediatek,eye-term:
description:
The selection of HS_TX TERM reference voltage (U2 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 7
mediatek,efuse-intr:
description:
The selection of Internal Resistor (U2/U3 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 63
mediatek,efuse-tx-imp:
description:
The selection of TX Impedance (U3 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 31
mediatek,efuse-rx-imp:
description:
The selection of RX Impedance (U3 phy)
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 31
required:
- reg
- clocks
- clock-names
- "#phy-cells"
additionalProperties: false
required:
- compatible
- "#address-cells"
- "#size-cells"
- ranges
additionalProperties: false
examples:
- |
#include <dt-bindings/phy/phy.h>
u3phy: xs-phy@11c40000 {
compatible = "mediatek,mt3611-xsphy", "mediatek,xsphy";
reg = <0x11c43000 0x0200>;
mediatek,src-ref-clk-mhz = <26>;
mediatek,src-coef = <17>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
u2port0: usb-phy@11c40000 {
reg = <0x11c40000 0x0400>;
clocks = <&clk48m>;
clock-names = "ref";
mediatek,eye-src = <4>;
#phy-cells = <1>;
};
u3port0: usb-phy@11c43000 {
reg = <0x11c43400 0x0500>;
clocks = <&clk26m>;
clock-names = "ref";
mediatek,efuse-intr = <28>;
#phy-cells = <1>;
};
};
...

162
Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
View File

@ -1,162 +0,0 @@
MediaTek T-PHY binding
--------------------------
T-phy controller supports physical layer functionality for a number of
controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe, and SATA.
Required properties (controller (parent) node):
- compatible : should be one of
"mediatek,generic-tphy-v1"
"mediatek,generic-tphy-v2"
"mediatek,mt2701-u3phy" (deprecated)
"mediatek,mt2712-u3phy" (deprecated)
"mediatek,mt8173-u3phy";
make use of "mediatek,generic-tphy-v1" on mt2701 instead and
"mediatek,generic-tphy-v2" on mt2712 instead.
- #address-cells: the number of cells used to represent physical
base addresses.
- #size-cells: the number of cells used to represent the size of an address.
- ranges: the address mapping relationship to the parent, defined with
- empty value: if optional 'reg' is used.
- non-empty value: if optional 'reg' is not used. should set
the child's base address to 0, the physical address
within parent's address space, and the length of
the address map.
Required nodes : a sub-node is required for each port the controller
provides. Address range information including the usual
'reg' property is used inside these nodes to describe
the controller's topology.
Optional properties (controller (parent) node):
- reg : offset and length of register shared by multiple ports,
exclude port's private register. It is needed on mt2701
and mt8173, but not on mt2712.
- mediatek,src-ref-clk-mhz : frequency of reference clock for slew rate
calibrate
- mediatek,src-coef : coefficient for slew rate calibrate, depends on
SoC process
Required properties (port (child) node):
- reg : address and length of the register set for the port.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
- PHY_TYPE_USB3
- PHY_TYPE_PCIE
- PHY_TYPE_SATA
Optional properties (PHY_TYPE_USB2 port (child) node):
- clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
- clock-names : may contain
"ref": 48M reference clock for HighSpeed (digital) phy; and 26M
reference clock for SuperSpeed (digital) phy, sometimes is
24M, 25M or 27M, depended on platform.
"da_ref": the reference clock of analog phy, used if the clocks
of analog and digital phys are separated, otherwise uses
"ref" clock only if needed.
- mediatek,eye-src : u32, the value of slew rate calibrate
- mediatek,eye-vrt : u32, the selection of VRT reference voltage
- mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
- mediatek,bc12 : bool, enable BC12 of u2phy if support it
- mediatek,discth : u32, the selection of disconnect threshold
- mediatek,intr : u32, the selection of internal R (resistance)
Example:
u3phy: usb-phy@11290000 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x11290000 0 0x800>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
u2port0: usb-phy@11290800 {
reg = <0 0x11290800 0 0x100>;
clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
clock-names = "ref";
#phy-cells = <1>;
};
u3port0: usb-phy@11290900 {
reg = <0 0x11290800 0 0x700>;
clocks = <&clk26m>;
clock-names = "ref";
#phy-cells = <1>;
};
u2port1: usb-phy@11291000 {
reg = <0 0x11291000 0 0x100>;
clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
clock-names = "ref";
#phy-cells = <1>;
};
};
Specifying phy control of devices
---------------------------------
Device nodes should specify the configuration required in their "phys"
property, containing a phandle to the phy port node and a device type;
phy-names for each port are optional.
Example:
#include <dt-bindings/phy/phy.h>
usb30: usb@11270000 {
...
phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
phy-names = "usb2-0", "usb3-0";
...
};
Layout differences of banks between mt8173/mt2701 and mt2712
-------------------------------------------------------------
mt8173 and mt2701:
port offset bank
shared 0x0000 SPLLC
0x0100 FMREG
u2 port0 0x0800 U2PHY_COM
u3 port0 0x0900 U3PHYD
0x0a00 U3PHYD_BANK2
0x0b00 U3PHYA
0x0c00 U3PHYA_DA
u2 port1 0x1000 U2PHY_COM
u3 port1 0x1100 U3PHYD
0x1200 U3PHYD_BANK2
0x1300 U3PHYA
0x1400 U3PHYA_DA
u2 port2 0x1800 U2PHY_COM
...
mt2712:
port offset bank
u2 port0 0x0000 MISC
0x0100 FMREG
0x0300 U2PHY_COM
u3 port0 0x0700 SPLLC
0x0800 CHIP
0x0900 U3PHYD
0x0a00 U3PHYD_BANK2
0x0b00 U3PHYA
0x0c00 U3PHYA_DA
u2 port1 0x1000 MISC
0x1100 FMREG
0x1300 U2PHY_COM
u3 port1 0x1700 SPLLC
0x1800 CHIP
0x1900 U3PHYD
0x1a00 U3PHYD_BANK2
0x1b00 U3PHYA
0x1c00 U3PHYA_DA
u2 port2 0x2000 MISC
...
SPLLC shared by u3 ports and FMREG shared by u2 ports on
mt8173/mt2701 are put back into each port; a new bank MISC for
u2 ports and CHIP for u3 ports are added on mt2712.

38
Documentation/devicetree/bindings/phy/phy-mtk-ufs.txt
View File

@ -1,38 +0,0 @@
MediaTek Universal Flash Storage (UFS) M-PHY binding
--------------------------------------------------------
UFS M-PHY nodes are defined to describe on-chip UFS M-PHY hardware macro.
Each UFS M-PHY node should have its own node.
To bind UFS M-PHY with UFS host controller, the controller node should
contain a phandle reference to UFS M-PHY node.
Required properties for UFS M-PHY nodes:
- compatible : Compatible list, contains the following controller:
"mediatek,mt8183-ufsphy" for ufs phy
persent on MT81xx chipsets.
- reg : Address and length of the UFS M-PHY register set.
- #phy-cells : This property shall be set to 0.
- clocks : List of phandle and clock specifier pairs.
- clock-names : List of clock input name strings sorted in the same
order as the clocks property. Following clocks are
mandatory.
"unipro": Unipro core control clock.
"mp": M-PHY core control clock.
Example:
ufsphy: phy@11fa0000 {
compatible = "mediatek,mt8183-ufsphy";
reg = <0 0x11fa0000 0 0xc000>;
#phy-cells = <0>;
clocks = <&infracfg_ao INFRACFG_AO_UNIPRO_SCK_CG>,
<&infracfg_ao INFRACFG_AO_UFS_MP_SAP_BCLK_CG>;
clock-names = "unipro", "mp";
};
ufshci@11270000 {
...
phys = <&ufsphy>;
};

109
Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
View File

@ -1,109 +0,0 @@
MediaTek XS-PHY binding
--------------------------
The XS-PHY controller supports physical layer functionality for USB3.1
GEN2 controller on MediaTek SoCs.
Required properties (controller (parent) node):
- compatible : should be "mediatek,<soc-model>-xsphy", "mediatek,xsphy",
soc-model is the name of SoC, such as mt3611 etc;
when using "mediatek,xsphy" compatible string, you need SoC specific
ones in addition, one of:
- "mediatek,mt3611-xsphy"
- #address-cells, #size-cells : should use the same values as the root node
- ranges: must be present
Optional properties (controller (parent) node):
- reg : offset and length of register shared by multiple U3 ports,
exclude port's private register, if only U2 ports provided,
shouldn't use the property.
- mediatek,src-ref-clk-mhz : u32, frequency of reference clock for slew rate
calibrate
- mediatek,src-coef : u32, coefficient for slew rate calibrate, depends on
SoC process
Required nodes : a sub-node is required for each port the controller
provides. Address range information including the usual
'reg' property is used inside these nodes to describe
the controller's topology.
Required properties (port (child) node):
- reg : address and length of the register set for the port.
- clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
- clock-names : must contain
"ref": 48M reference clock for HighSpeed analog phy; and 26M
reference clock for SuperSpeedPlus analog phy, sometimes is
24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1
cell after port phandle is phy type from:
- PHY_TYPE_USB2
- PHY_TYPE_USB3
The following optional properties are only for debug or HQA test
Optional properties (PHY_TYPE_USB2 port (child) node):
- mediatek,eye-src : u32, the value of slew rate calibrate
- mediatek,eye-vrt : u32, the selection of VRT reference voltage
- mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
- mediatek,efuse-intr : u32, the selection of Internal Resistor
Optional properties (PHY_TYPE_USB3 port (child) node):
- mediatek,efuse-intr : u32, the selection of Internal Resistor
- mediatek,efuse-tx-imp : u32, the selection of TX Impedance
- mediatek,efuse-rx-imp : u32, the selection of RX Impedance
Banks layout of xsphy
-------------------------------------------------------------
port offset bank
u2 port0 0x0000 MISC
0x0100 FMREG
0x0300 U2PHY_COM
u2 port1 0x1000 MISC
0x1100 FMREG
0x1300 U2PHY_COM
u2 port2 0x2000 MISC
...
u31 common 0x3000 DIG_GLB
0x3100 PHYA_GLB
u31 port0 0x3400 DIG_LN_TOP
0x3500 DIG_LN_TX0
0x3600 DIG_LN_RX0
0x3700 DIG_LN_DAIF
0x3800 PHYA_LN
u31 port1 0x3a00 DIG_LN_TOP
0x3b00 DIG_LN_TX0
0x3c00 DIG_LN_RX0
0x3d00 DIG_LN_DAIF
0x3e00 PHYA_LN
...
DIG_GLB & PHYA_GLB are shared by U31 ports.
Example:
u3phy: usb-phy@11c40000 {
compatible = "mediatek,mt3611-xsphy", "mediatek,xsphy";
reg = <0 0x11c43000 0 0x0200>;
mediatek,src-ref-clk-mhz = <26>;
mediatek,src-coef = <17>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
u2port0: usb-phy@11c40000 {
reg = <0 0x11c40000 0 0x0400>;
clocks = <&clk48m>;
clock-names = "ref";
mediatek,eye-src = <4>;
#phy-cells = <1>;
};
u3port0: usb-phy@11c43000 {
reg = <0 0x11c43400 0 0x0500>;
clocks = <&clk26m>;
clock-names = "ref";
mediatek,efuse-intr = <28>;
#phy-cells = <1>;
};
};

22
Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml
View File

@ -45,6 +45,12 @@ properties:
"#size-cells":
const: 0
vdda1v1-supply:
description: regulator providing 1V1 power supply to the PLL block
vdda1v8-supply:
description: regulator providing 1V8 power supply to the PLL block
#Required child nodes:
patternProperties:
@ -61,12 +67,6 @@ patternProperties:
phy-supply:
description: regulator providing 3V3 power supply to the PHY.
vdda1v1-supply:
description: regulator providing 1V1 power supply to the PLL block
vdda1v8-supply:
description: regulator providing 1V8 power supply to the PLL block
"#phy-cells":
enum: [ 0x0, 0x1 ]
@ -90,8 +90,6 @@ patternProperties:
required:
- reg
- phy-supply
- vdda1v1-supply
- vdda1v8-supply
- "#phy-cells"
additionalProperties: false
@ -102,6 +100,8 @@ required:
- clocks
- "#address-cells"
- "#size-cells"
- vdda1v1-supply
- vdda1v8-supply
- usb-phy@0
- usb-phy@1
@ -116,22 +116,20 @@ examples:
reg = <0x5a006000 0x1000>;
clocks = <&rcc USBPHY_K>;
resets = <&rcc USBPHY_R>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
#address-cells = <1>;
#size-cells = <0>;
usbphyc_port0: usb-phy@0 {
reg = <0>;
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
#phy-cells = <0>;
};
usbphyc_port1: usb-phy@1 {
reg = <1>;
phy-supply = <&vdd_usb>;
vdda1v1-supply = <&reg11>;
vdda1v8-supply = <&reg18>;
#phy-cells = <1>;
};
};

97
Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml
View File

@ -25,19 +25,32 @@ properties:
- qcom,msm8998-qmp-pcie-phy
- qcom,msm8998-qmp-ufs-phy
- qcom,msm8998-qmp-usb3-phy
- qcom,sc8180x-qmp-ufs-phy
- qcom,sc8180x-qmp-usb3-phy
- qcom,sdm845-qhp-pcie-phy
- qcom,sdm845-qmp-pcie-phy
- qcom,sdm845-qmp-ufs-phy
- qcom,sdm845-qmp-usb3-uni-phy
- qcom,sm8150-qmp-ufs-phy
- qcom,sm8150-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- qcom,sm8250-qmp-ufs-phy
- qcom,sm8250-qmp-gen3x1-pcie-phy
- qcom,sm8250-qmp-gen3x2-pcie-phy
- qcom,sm8250-qmp-modem-pcie-phy
- qcom,sm8250-qmp-usb3-phy
- qcom,sm8250-qmp-usb3-uni-phy
- qcom,sm8350-qmp-ufs-phy
- qcom,sm8350-qmp-usb3-phy
- qcom,sm8350-qmp-usb3-uni-phy
- qcom,sdx55-qmp-usb3-uni-phy
reg:
minItems: 1
maxItems: 2
items:
- description: Address and length of PHY's common serdes block.
- description: Address and length of PHY's DP_COM control block.
"#clock-cells":
enum: [ 1, 2 ]
@ -131,6 +144,32 @@ allOf:
items:
- const: phy
- const: common
- if:
properties:
compatible:
contains:
enum:
- qcom,sdx55-qmp-usb3-uni-phy
then:
properties:
clocks:
items:
- description: Phy aux clock.
- description: Phy config clock.
- description: 19.2 MHz ref clk.
clock-names:
items:
- const: aux
- const: cfg_ahb
- const: ref
resets:
items:
- description: reset of phy block.
- description: phy common block reset.
reset-names:
items:
- const: phy
- const: common
- if:
properties:
compatible:
@ -285,6 +324,64 @@ allOf:
reset-names:
items:
- const: phy
- if:
properties:
compatible:
contains:
enum:
- qcom,sm8150-qmp-usb3-phy
- qcom,sm8150-qmp-usb3-uni-phy
- qcom,sm8250-qmp-usb3-uni-phy
- qcom,sm8350-qmp-usb3-uni-phy
then:
properties:
clocks:
items:
- description: Phy aux clock.
- description: 19.2 MHz ref clk source.
- description: 19.2 MHz ref clk.
- description: Phy common block aux clock.
clock-names:
items:
- const: aux
- const: ref_clk_src
- const: ref
- const: com_aux
resets:
items:
- description: reset of phy block.
- description: phy common block reset.
reset-names:
items:
- const: phy
- const: common
- if:
properties:
compatible:
contains:
enum:
- qcom,sm8250-qmp-usb3-phy
- qcom,sm8350-qmp-usb3-phy
then:
properties:
clocks:
items:
- description: Phy aux clock.
- description: 19.2 MHz ref clk.
- description: Phy common block aux clock.
clock-names:
items:
- const: aux
- const: ref_clk_src
- const: com_aux
resets:
items:
- description: reset of phy block.
- description: phy common block reset.
reset-names:
items:
- const: phy
- const: common
examples:
- |

2
Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
View File

@ -21,6 +21,8 @@ properties:
- qcom,ipq8074-qusb2-phy
- qcom,msm8996-qusb2-phy
- qcom,msm8998-qusb2-phy
- qcom,sdm660-qusb2-phy
- qcom,ipq6018-qusb2-phy
- items:
- enum:
- qcom,sc7180-qusb2-phy

1
Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml
View File

@ -16,6 +16,7 @@ properties:
compatible:
enum:
- qcom,usb-hs-28nm-femtophy
- qcom,usb-hs-28nm-mdm9607
reg:
maxItems: 1

2
Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
View File

@ -17,6 +17,8 @@ properties:
enum:
- qcom,usb-snps-hs-7nm-phy
- qcom,sm8150-usb-hs-phy
- qcom,sm8250-usb-hs-phy
- qcom,sm8350-usb-hs-phy
- qcom,usb-snps-femto-v2-phy
reg:

10
Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt
View File

@ -16,11 +16,11 @@ Optional properties:
- drive-impedance-ohm: Specifies the drive impedance in Ohm.
Possible values are 33, 40, 50, 66 and 100.
If not set, the default value of 50 will be applied.
- enable-strobe-pulldown: Enable internal pull-down for the strobe line.
If not set, pull-down is not used.
- output-tapdelay-select: Specifies the phyctrl_otapdlysec register.
If not set, the register defaults to 0x4.
Maximum value 0xf.
- rockchip,enable-strobe-pulldown: Enable internal pull-down for the strobe
line. If not set, pull-down is not used.
- rockchip,output-tapdelay-select: Specifies the phyctrl_otapdlysec register.
If not set, the register defaults to 0x4.
Maximum value 0xf.
Example:

2
Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
View File

@ -151,7 +151,7 @@ patternProperties:
WIZ node should have '1' subnode for the SERDES. It could be either
Sierra SERDES or Torrent SERDES. Sierra SERDES should follow the
bindings specified in
Documentation/devicetree/bindings/phy/phy-cadence-sierra.txt
Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml
Torrent SERDES should follow the bindings specified in
Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml

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