leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branches 'for-5.7/upstream-fixes', 'for-5.8/apple', 'for-5.8/asus', 'for-5.8/core', 'for-5.8/intel-ish', 'for-5.8/logitech', 'for-5.8/mcp2221' and 'for-5.8/multitouch' into for-linus

Browse Source
This commit is contained in:
Jiri Kosina 2020-06-03 22:23:52 +02:00
commit 16ba7e3120
6739 changed files with 292780 additions and 137615 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
.clang-format
View File

@ -142,10 +142,13 @@ ForEachMacros:
- 'for_each_card_auxs'
- 'for_each_card_auxs_safe'
- 'for_each_card_components'
- 'for_each_card_dapms'
- 'for_each_card_pre_auxs'
- 'for_each_card_prelinks'
- 'for_each_card_rtds'
- 'for_each_card_rtds_safe'
- 'for_each_card_widgets'
- 'for_each_card_widgets_safe'
- 'for_each_cgroup_storage_type'
- 'for_each_child_of_node'
- 'for_each_clear_bit'
@ -160,6 +163,7 @@ ForEachMacros:
- 'for_each_cpu_and'
- 'for_each_cpu_not'
- 'for_each_cpu_wrap'
- 'for_each_dapm_widgets'
- 'for_each_dev_addr'
- 'for_each_dev_scope'
- 'for_each_displayid_db'
@ -170,7 +174,6 @@ ForEachMacros:
- 'for_each_dpcm_fe'
- 'for_each_drhd_unit'
- 'for_each_dss_dev'
- 'for_each_efi_handle'
- 'for_each_efi_memory_desc'
- 'for_each_efi_memory_desc_in_map'
- 'for_each_element'
@ -191,6 +194,7 @@ ForEachMacros:
- 'for_each_ip_tunnel_rcu'
- 'for_each_irq_nr'
- 'for_each_link_codecs'
- 'for_each_link_cpus'
- 'for_each_link_platforms'
- 'for_each_lru'
- 'for_each_matching_node'
@ -250,6 +254,7 @@ ForEachMacros:
- 'for_each_pci_bridge'
- 'for_each_pci_dev'
- 'for_each_pci_msi_entry'
- 'for_each_pcm_streams'
- 'for_each_populated_zone'
- 'for_each_possible_cpu'
- 'for_each_present_cpu'
@ -260,9 +265,12 @@ ForEachMacros:
- 'for_each_property_of_node'
- 'for_each_registered_fb'
- 'for_each_reserved_mem_region'
- 'for_each_rtd_codec_dai'
- 'for_each_rtd_codec_dai_rollback'
- 'for_each_rtd_codec_dais'
- 'for_each_rtd_codec_dais_rollback'
- 'for_each_rtd_components'
- 'for_each_rtd_cpu_dais'
- 'for_each_rtd_cpu_dais_rollback'
- 'for_each_rtd_dais'
- 'for_each_set_bit'
- 'for_each_set_bit_from'
- 'for_each_set_clump8'
@ -334,6 +342,7 @@ ForEachMacros:
- 'klp_for_each_object'
- 'klp_for_each_object_safe'
- 'klp_for_each_object_static'
- 'kunit_suite_for_each_test_case'
- 'kvm_for_each_memslot'
- 'kvm_for_each_vcpu'
- 'list_for_each'
@ -387,6 +396,7 @@ ForEachMacros:
- 'of_property_for_each_string'
- 'of_property_for_each_u32'
- 'pci_bus_for_each_resource'
- 'pcm_for_each_format'
- 'ping_portaddr_for_each_entry'
- 'plist_for_each'
- 'plist_for_each_continue'
@ -482,7 +492,7 @@ KeepEmptyLinesAtTheStartOfBlocks: false
MacroBlockBegin: ''
MacroBlockEnd: ''
MaxEmptyLinesToKeep: 1
NamespaceIndentation: Inner
NamespaceIndentation: None
#ObjCBinPackProtocolList: Auto # Unknown to clang-format-5.0
ObjCBlockIndentWidth: 8
ObjCSpaceAfterProperty: true

1
.gitignore vendored
View File

@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
#
# NOTE! Don't add files that are generated in specific
# subdirectories here. Add them in the ".gitignore" file

2
.mailmap
View File

@ -210,6 +210,7 @@ Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
Paul Burton <paulburton@kernel.org> <paul.burton@imgtec.com>
@ -248,6 +249,7 @@ Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
Sedat Dilek <sedat.dilek@gmail.com> <sedat.dilek@credativ.de>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>

1
Documentation/.gitignore vendored
View File

@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
output
*.pyc

9
Documentation/ABI/obsolete/sysfs-kernel-fadump_enabled Normal file
View File

@ -0,0 +1,9 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/enabled.
What: /sys/kernel/fadump_enabled
Date: Feb 2012
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Primarily used to identify whether the FADump is enabled in
the kernel or not.
User: Kdump service

10
Documentation/ABI/obsolete/sysfs-kernel-fadump_registered Normal file
View File

@ -0,0 +1,10 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.¬
What: /sys/kernel/fadump_registered
Date: Feb 2012
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Helps to control the dump collect feature from userspace.
Setting 1 to this file enables the system to collect the
dump and 0 to disable it.
User: Kdump service

10
Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem Normal file
View File

@ -0,0 +1,10 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.¬
What: /sys/kernel/fadump_release_mem
Date: Feb 2012
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
This is a special sysfs file and only available when
the system is booted to capture the vmcore using FADump.
It is used to release the memory reserved by FADump to
save the crash dump.

9
Documentation/ABI/removed/sysfs-kernel-fadump_release_opalcore Normal file
View File

@ -0,0 +1,9 @@
This ABI is moved to /sys/firmware/opal/mpipl/release_core.
What: /sys/kernel/fadump_release_opalcore
Date: Sep 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
The sysfs file is available when the system is booted to
collect the dump on OPAL based machine. It used to release
the memory used to collect the opalcore.

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

@ -43,6 +43,20 @@ Description: Allows the root user to read or write directly through the
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/data64
Date: Jan 2020
KernelVersion: 5.6
Contact: oded.gabbay@gmail.com
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
transaction. This custom interface is needed (instead of using
the generic Linux user-space PCI mapping) because the DDR bar
is very small compared to the DDR memory and only the driver can
move the bar before and after the transaction.
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/device
Date: Jan 2019
KernelVersion: 5.1

241
Documentation/ABI/testing/sysfs-bus-coresight-devices-cti Normal file
View File

@ -0,0 +1,241 @@
What: /sys/bus/coresight/devices/<cti-name>/enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable/Disable the CTI hardware.
What: /sys/bus/coresight/devices/<cti-name>/powered
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Indicate if the CTI hardware is powered.
What: /sys/bus/coresight/devices/<cti-name>/ctmid
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Display the associated CTM ID
What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Number of devices connected to triggers on this CTI
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Name of connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Input trigger signals from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Functional types for the input trigger signals
from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Output trigger signals to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Functional types for the output trigger signals
to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Select the index for inen and outen registers.
What: /sys/bus/coresight/devices/<cti-name>/regs/inen
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIINEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/outen
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIOUTEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/gate
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write CTIGATE register.
What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write ASICCTL register.
What: /sys/bus/coresight/devices/<cti-name>/regs/intack
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write the INTACK register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appset
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Set CTIAPPSET register to activate channel. Read back to
determine current value of register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appclear
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write APPCLEAR register to deactivate channel.
What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write APPPULSE to pulse a channel active for one clock
cycle.
What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read current status of channel inputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of channel outputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of input trigger signals
What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of output trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Attach a CTI input trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Detach a CTI input trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Attach a CTI output trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Detach a CTI output trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable CTIGATE for single channel (W) or list enabled
channels through the gate (R).
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Disable CTIGATE for single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Activate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Deactivate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Pulse a single channel - activate for a single clock cycle.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) List of output triggers filtered across all connections.
What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable or disable trigger output signal filtering.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) show channels with at least one attached trigger signal.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) show channels with no attached trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Write channel number to select a channel to view, read to
see selected channel number.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read to see input triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read to see output triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Clear all channel / trigger programming.

8
Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc
View File

@ -40,3 +40,11 @@ Description: (RW) Trigger window switch for the MSC's buffer, in
triggering a window switch for the buffer. Returns an error in any
other operating mode or attempts to write something other than "1".
What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/stop_on_full
Date: March 2020
KernelVersion: 5.7
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure whether trace stops when the last available window
becomes full (1/y/Y) or wraps around and continues until the next
window becomes available again (0/n/N).

16
Documentation/ABI/testing/sysfs-driver-jz4780-efuse Normal file
View File

@ -0,0 +1,16 @@
What: /sys/devices/*/<our-device>/nvmem
Date: December 2017
Contact: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Description: read-only access to the efuse on the Ingenic JZ4780 SoC
The SoC has a one time programmable 8K efuse that is
split into segments. The driver supports read only.
The segments are
0x000 64 bit Random Number
0x008 128 bit Ingenic Chip ID
0x018 128 bit Customer ID
0x028 3520 bit Reserved
0x1E0 8 bit Protect Segment
0x1E1 2296 bit HDMI Key
0x300 2048 bit Security boot key
Users: any user space application which wants to read the Chip
and Customer ID

21
Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups Normal file
View File

@ -0,0 +1,21 @@
What: /sys/firmware/opal/sensor_groups
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: Sensor groups directory for POWER9 powernv servers
Each folder in this directory contains a sensor group
which are classified based on type of the sensor
like power, temperature, frequency, current, etc. They
can also indicate the group of sensors belonging to
different owners like CSM, Profiler, Job-Scheduler
What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: Sysfs file to clear the min-max of all the sensors
belonging to the group.
Writing 1 to this file will clear the minimum and
maximum values of all the sensors in the group.
In POWER9, the min-max of a sensor is the historical minimum
and maximum value of the sensor cached by OCC.

5
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -318,3 +318,8 @@ Date: September 2019
Contact: "Hridya Valsaraju" <hridya@google.com>
Description: Average number of valid blocks.
Available when CONFIG_F2FS_STAT_FS=y.
What: /sys/fs/f2fs/<disk>/mounted_time_sec
Date: February 2020
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Show the mounted time in secs of this partition.

40
Documentation/ABI/testing/sysfs-kernel-fadump Normal file
View File

@ -0,0 +1,40 @@
What: /sys/kernel/fadump/*
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description:
The /sys/kernel/fadump/* is a collection of FADump sysfs
file provide information about the configuration status
of Firmware Assisted Dump (FADump).
What: /sys/kernel/fadump/enabled
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Primarily used to identify whether the FADump is enabled in
the kernel or not.
User: Kdump service
What: /sys/kernel/fadump/registered
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Helps to control the dump collect feature from userspace.
Setting 1 to this file enables the system to collect the
dump and 0 to disable it.
User: Kdump service
What: /sys/kernel/fadump/release_mem
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
This is a special sysfs file and only available when
the system is booted to capture the vmcore using FADump.
It is used to release the memory reserved by FADump to
save the crash dump.
What: /sys/kernel/fadump/mem_reserved
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Provide information about the amount of memory reserved by
FADump to save the crash dump in bytes.

8
Documentation/ABI/testing/sysfs-platform-dell-laptop
View File

@ -2,7 +2,7 @@ What: /sys/class/leds/dell::kbd_backlight/als_enabled
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to control the automatic keyboard
illumination mode on some systems that have an ambient
@ -13,7 +13,7 @@ What: /sys/class/leds/dell::kbd_backlight/als_setting
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to specifiy the on/off threshold value,
as reported by the ambient light sensor.
@ -22,7 +22,7 @@ What: /sys/class/leds/dell::kbd_backlight/start_triggers
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to control the input triggers that
turn on the keyboard backlight illumination that is
@ -45,7 +45,7 @@ What: /sys/class/leds/dell::kbd_backlight/stop_timeout
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to specify the interval after which the
keyboard illumination is disabled because of inactivity.

155
Documentation/PCI/boot-interrupts.rst Normal file
View File

@ -0,0 +1,155 @@
.. SPDX-License-Identifier: GPL-2.0
===============
Boot Interrupts
===============
:Author: - Sean V Kelley <sean.v.kelley@linux.intel.com>
Overview
========
On PCI Express, interrupts are represented with either MSI or inbound
interrupt messages (Assert_INTx/Deassert_INTx). The integrated IO-APIC in a
given Core IO converts the legacy interrupt messages from PCI Express to
MSI interrupts. If the IO-APIC is disabled (via the mask bits in the
IO-APIC table entries), the messages are routed to the legacy PCH. This
in-band interrupt mechanism was traditionally necessary for systems that
did not support the IO-APIC and for boot. Intel in the past has used the
term "boot interrupts" to describe this mechanism. Further, the PCI Express
protocol describes this in-band legacy wire-interrupt INTx mechanism for
I/O devices to signal PCI-style level interrupts. The subsequent paragraphs
describe problems with the Core IO handling of INTx message routing to the
PCH and mitigation within BIOS and the OS.
Issue
=====
When in-band legacy INTx messages are forwarded to the PCH, they in turn
trigger a new interrupt for which the OS likely lacks a handler. When an
interrupt goes unhandled over time, they are tracked by the Linux kernel as
Spurious Interrupts. The IRQ will be disabled by the Linux kernel after it
reaches a specific count with the error "nobody cared". This disabled IRQ
now prevents valid usage by an existing interrupt which may happen to share
the IRQ line.
irq 19: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 2988 Comm: irq/34-nipalk Tainted: 4.14.87-rt49-02410-g4a640ec-dirty #1
Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880, BIOS 2.1.5f1 01/09/2020
Call Trace:
<IRQ>
? dump_stack+0x46/0x5e
? __report_bad_irq+0x2e/0xb0
? note_interrupt+0x242/0x290
? nNIKAL100_memoryRead16+0x8/0x10 [nikal]
? handle_irq_event_percpu+0x55/0x70
? handle_irq_event+0x4f/0x80
? handle_fasteoi_irq+0x81/0x180
? handle_irq+0x1c/0x30
? do_IRQ+0x41/0xd0
? common_interrupt+0x84/0x84
</IRQ>
handlers:
irq_default_primary_handler threaded usb_hcd_irq
Disabling IRQ #19
Conditions
==========
The use of threaded interrupts is the most likely condition to trigger
this problem today. Threaded interrupts may not be reenabled after the IRQ
handler wakes. These "one shot" conditions mean that the threaded interrupt
needs to keep the interrupt line masked until the threaded handler has run.
Especially when dealing with high data rate interrupts, the thread needs to
run to completion; otherwise some handlers will end up in stack overflows
since the interrupt of the issuing device is still active.
Affected Chipsets
=================
The legacy interrupt forwarding mechanism exists today in a number of
devices including but not limited to chipsets from AMD/ATI, Broadcom, and
Intel. Changes made through the mitigations below have been applied to
drivers/pci/quirks.c
Starting with ICX there are no longer any IO-APICs in the Core IO's
devices. IO-APIC is only in the PCH. Devices connected to the Core IO's
PCIe Root Ports will use native MSI/MSI-X mechanisms.
Mitigations
===========
The mitigations take the form of PCI quirks. The preference has been to
first identify and make use of a means to disable the routing to the PCH.
In such a case a quirk to disable boot interrupt generation can be
added.[1]
Intel® 6300ESB I/O Controller Hub
Alternate Base Address Register:
BIE: Boot Interrupt Enable
0 = Boot interrupt is enabled.
1 = Boot interrupt is disabled.
Intel® Sandy Bridge through Sky Lake based Xeon servers:
Coherent Interface Protocol Interrupt Control
dis_intx_route2pch/dis_intx_route2ich/dis_intx_route2dmi2:
When this bit is set. Local INTx messages received from the
Intel® Quick Data DMA/PCI Express ports are not routed to legacy
PCH - they are either converted into MSI via the integrated IO-APIC
(if the IO-APIC mask bit is clear in the appropriate entries)
or cause no further action (when mask bit is set)
In the absence of a way to directly disable the routing, another approach
has been to make use of PCI Interrupt pin to INTx routing tables for
purposes of redirecting the interrupt handler to the rerouted interrupt
line by default. Therefore, on chipsets where this INTx routing cannot be
disabled, the Linux kernel will reroute the valid interrupt to its legacy
interrupt. This redirection of the handler will prevent the occurrence of
the spurious interrupt detection which would ordinarily disable the IRQ
line due to excessive unhandled counts.[2]
The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS exists to enable (or
disable) the redirection of the interrupt handler to the PCH interrupt
line. The option can be overridden by either pci=ioapicreroute or
pci=noioapicreroute.[3]
More Documentation
==================
There is an overview of the legacy interrupt handling in several datasheets
(6300ESB and 6700PXH below). While largely the same, it provides insight
into the evolution of its handling with chipsets.
Example of disabling of the boot interrupt
------------------------------------------
Intel® 6300ESB I/O Controller Hub (Document # 300641-004US)
5.7.3 Boot Interrupt
https://www.intel.com/content/dam/doc/datasheet/6300esb-io-controller-hub-datasheet.pdf
Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families
Datasheet - Volume 2: Registers (Document # 330784-003)
6.6.41 cipintrc Coherent Interface Protocol Interrupt Control
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-v3-datasheet-vol-2.pdf
Example of handler rerouting
----------------------------
Intel® 6700PXH 64-bit PCI Hub (Document # 302628)
2.15.2 PCI Express Legacy INTx Support and Boot Interrupt
https://www.intel.com/content/dam/doc/datasheet/6700pxh-64-bit-pci-hub-datasheet.pdf
If you have any legacy PCI interrupt questions that aren't answered, email me.
Cheers,
Sean V Kelley
sean.v.kelley@linux.intel.com
[1] https://lore.kernel.org/r/12131949181903-git-send-email-sassmann@suse.de/
[2] https://lore.kernel.org/r/12131949182094-git-send-email-sassmann@suse.de/
[3] https://lore.kernel.org/r/487C8EA7.6020205@suse.de/

1
Documentation/PCI/index.rst
View File

@ -16,3 +16,4 @@ Linux PCI Bus Subsystem
pci-error-recovery
pcieaer-howto
endpoint/index
boot-interrupts

23
Documentation/PCI/pcieaer-howto.rst
View File

@ -156,12 +156,6 @@ default reset_link function, but different upstream ports might
have different specifications to reset pci express link, so all
upstream ports should provide their own reset_link functions.
In struct pcie_port_service_driver, a new pointer, reset_link, is
added.
::
pci_ers_result_t (*reset_link) (struct pci_dev *dev);
Section 3.2.2.2 provides more detailed info on when to call
reset_link.
@ -212,15 +206,10 @@ error_detected(dev, pci_channel_io_frozen) to all drivers within
a hierarchy in question. Then, performing link reset at upstream is
necessary. As different kinds of devices might use different approaches
to reset link, AER port service driver is required to provide the
function to reset link. Firstly, kernel looks for if the upstream
component has an aer driver. If it has, kernel uses the reset_link
callback of the aer driver. If the upstream component has no aer driver
and the port is downstream port, we will perform a hot reset as the
default by setting the Secondary Bus Reset bit of the Bridge Control
register associated with the downstream port. As for upstream ports,
they should provide their own aer service drivers with reset_link
function. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and
reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
function to reset link via callback parameter of pcie_do_recovery()
function. If reset_link is not NULL, recovery function will use it
to reset the link. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER
and reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
to mmio_enabled.
helper functions
@ -243,9 +232,9 @@ messages to root port when an error is detected.
::
int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev);`
int pci_aer_clear_nonfatal_status(struct pci_dev *dev);`
pci_cleanup_aer_uncorrect_error_status cleanups the uncorrectable
pci_aer_clear_nonfatal_status clears non-fatal errors in the uncorrectable
error status register.
Frequent Asked Questions

6
Documentation/admin-guide/binderfs.rst
View File

@ -33,6 +33,12 @@ max
a per-instance limit. If ``max=<count>`` is set then only ``<count>`` number
of binder devices can be allocated in this binderfs instance.
stats
Using ``stats=global`` enables global binder statistics.
``stats=global`` is only available for a binderfs instance mounted in the
initial user namespace. An attempt to use the option to mount a binderfs
instance in another user namespace will return a permission error.
Allocating binder Devices
-------------------------

11
Documentation/admin-guide/cgroup-v1/cpusets.rst
View File

@ -223,6 +223,17 @@ cpu_online_mask using a CPU hotplug notifier, and the mems file
automatically tracks the value of node_states[N_MEMORY]--i.e.,
nodes with memory--using the cpuset_track_online_nodes() hook.
The cpuset.effective_cpus and cpuset.effective_mems files are
normally read-only copies of cpuset.cpus and cpuset.mems files
respectively. If the cpuset cgroup filesystem is mounted with the
special "cpuset_v2_mode" option, the behavior of these files will become
similar to the corresponding files in cpuset v2. In other words, hotplug
events will not change cpuset.cpus and cpuset.mems. Those events will
only affect cpuset.effective_cpus and cpuset.effective_mems which show
the actual cpus and memory nodes that are currently used by this cpuset.
See Documentation/admin-guide/cgroup-v2.rst for more information about
cpuset v2 behavior.
1.4 What are exclusive cpusets ?
--------------------------------

103
Documentation/admin-guide/cgroup-v1/hugetlb.rst
View File

@ -2,13 +2,6 @@
HugeTLB Controller
==================
The HugeTLB controller allows to limit the HugeTLB usage per control group and
enforces the controller limit during page fault. Since HugeTLB doesn't
support page reclaim, enforcing the limit at page fault time implies that,
the application will get SIGBUS signal if it tries to access HugeTLB pages
beyond its limit. This requires the application to know beforehand how much
HugeTLB pages it would require for its use.
HugeTLB controller can be created by first mounting the cgroup filesystem.
# mount -t cgroup -o hugetlb none /sys/fs/cgroup
@ -28,10 +21,14 @@ process (bash) into it.
Brief summary of control files::
hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB limit
hugetlb.<hugepagesize>.rsvd.limit_in_bytes # set/show limit of "hugepagesize" hugetlb reservations
hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes # show max "hugepagesize" hugetlb reservations and no-reserve faults
hugetlb.<hugepagesize>.rsvd.usage_in_bytes # show current reservations and no-reserve faults for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.rsvd.failcnt # show the number of allocation failure due to HugeTLB reservation limit
hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb faults
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB usage limit
For a system supporting three hugepage sizes (64k, 32M and 1G), the control
files include::
@ -40,11 +37,95 @@ files include::
hugetlb.1GB.max_usage_in_bytes
hugetlb.1GB.usage_in_bytes
hugetlb.1GB.failcnt
hugetlb.1GB.rsvd.limit_in_bytes
hugetlb.1GB.rsvd.max_usage_in_bytes
hugetlb.1GB.rsvd.usage_in_bytes
hugetlb.1GB.rsvd.failcnt
hugetlb.64KB.limit_in_bytes
hugetlb.64KB.max_usage_in_bytes
hugetlb.64KB.usage_in_bytes
hugetlb.64KB.failcnt
hugetlb.64KB.rsvd.limit_in_bytes
hugetlb.64KB.rsvd.max_usage_in_bytes
hugetlb.64KB.rsvd.usage_in_bytes
hugetlb.64KB.rsvd.failcnt
hugetlb.32MB.limit_in_bytes
hugetlb.32MB.max_usage_in_bytes
hugetlb.32MB.usage_in_bytes
hugetlb.32MB.failcnt
hugetlb.32MB.rsvd.limit_in_bytes
hugetlb.32MB.rsvd.max_usage_in_bytes
hugetlb.32MB.rsvd.usage_in_bytes
hugetlb.32MB.rsvd.failcnt
1. Page fault accounting
hugetlb.<hugepagesize>.limit_in_bytes
hugetlb.<hugepagesize>.max_usage_in_bytes
hugetlb.<hugepagesize>.usage_in_bytes
hugetlb.<hugepagesize>.failcnt
The HugeTLB controller allows users to limit the HugeTLB usage (page fault) per
control group and enforces the limit during page fault. Since HugeTLB
doesn't support page reclaim, enforcing the limit at page fault time implies
that, the application will get SIGBUS signal if it tries to fault in HugeTLB
pages beyond its limit. Therefore the application needs to know exactly how many
HugeTLB pages it uses before hand, and the sysadmin needs to make sure that
there are enough available on the machine for all the users to avoid processes
getting SIGBUS.
2. Reservation accounting
hugetlb.<hugepagesize>.rsvd.limit_in_bytes
hugetlb.<hugepagesize>.rsvd.max_usage_in_bytes
hugetlb.<hugepagesize>.rsvd.usage_in_bytes
hugetlb.<hugepagesize>.rsvd.failcnt
The HugeTLB controller allows to limit the HugeTLB reservations per control
group and enforces the controller limit at reservation time and at the fault of
HugeTLB memory for which no reservation exists. Since reservation limits are
enforced at reservation time (on mmap or shget), reservation limits never causes
the application to get SIGBUS signal if the memory was reserved before hand. For
MAP_NORESERVE allocations, the reservation limit behaves the same as the fault
limit, enforcing memory usage at fault time and causing the application to
receive a SIGBUS if it's crossing its limit.
Reservation limits are superior to page fault limits described above, since
reservation limits are enforced at reservation time (on mmap or shget), and
never causes the application to get SIGBUS signal if the memory was reserved
before hand. This allows for easier fallback to alternatives such as
non-HugeTLB memory for example. In the case of page fault accounting, it's very
hard to avoid processes getting SIGBUS since the sysadmin needs precisely know
the HugeTLB usage of all the tasks in the system and make sure there is enough
pages to satisfy all requests. Avoiding tasks getting SIGBUS on overcommited
systems is practically impossible with page fault accounting.
3. Caveats with shared memory
For shared HugeTLB memory, both HugeTLB reservation and page faults are charged
to the first task that causes the memory to be reserved or faulted, and all
subsequent uses of this reserved or faulted memory is done without charging.
Shared HugeTLB memory is only uncharged when it is unreserved or deallocated.
This is usually when the HugeTLB file is deleted, and not when the task that
caused the reservation or fault has exited.
4. Caveats with HugeTLB cgroup offline.
When a HugeTLB cgroup goes offline with some reservations or faults still
charged to it, the behavior is as follows:
- The fault charges are charged to the parent HugeTLB cgroup (reparented),
- the reservation charges remain on the offline HugeTLB cgroup.
This means that if a HugeTLB cgroup gets offlined while there is still HugeTLB
reservations charged to it, that cgroup persists as a zombie until all HugeTLB
reservations are uncharged. HugeTLB reservations behave in this manner to match
the memory controller whose cgroups also persist as zombie until all charged
memory is uncharged. Also, the tracking of HugeTLB reservations is a bit more
complex compared to the tracking of HugeTLB faults, so it is significantly
harder to reparent reservations at offline time.

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

@ -188,6 +188,17 @@ cgroup v2 currently supports the following mount options.
modified through remount from the init namespace. The mount
option is ignored on non-init namespace mounts.
memory_recursiveprot
Recursively apply memory.min and memory.low protection to
entire subtrees, without requiring explicit downward
propagation into leaf cgroups. This allows protecting entire
subtrees from one another, while retaining free competition
within those subtrees. This should have been the default
behavior but is a mount-option to avoid regressing setups
relying on the original semantics (e.g. specifying bogusly
high 'bypass' protection values at higher tree levels).
Organizing Processes and Threads
--------------------------------

13
Documentation/admin-guide/device-mapper/dm-integrity.rst
View File

@ -182,12 +182,15 @@ fix_padding
space-efficient. If this option is not present, large padding is
used - that is for compatibility with older kernels.
allow_discards
Allow block discard requests (a.k.a. TRIM) for the integrity device.
Discards are only allowed to devices using internal hash.
The journal mode (D/J), buffer_sectors, journal_watermark, commit_time can
be changed when reloading the target (load an inactive table and swap the
tables with suspend and resume). The other arguments should not be changed
when reloading the target because the layout of disk data depend on them
and the reloaded target would be non-functional.
The journal mode (D/J), buffer_sectors, journal_watermark, commit_time and
allow_discards can be changed when reloading the target (load an inactive
table and swap the tables with suspend and resume). The other arguments
should not be changed when reloading the target because the layout of disk
data depend on them and the reloaded target would be non-functional.
The layout of the formatted block device:

3
Documentation/admin-guide/dynamic-debug-howto.rst
View File

@ -54,6 +54,9 @@ If you make a mistake with the syntax, the write will fail thus::
<debugfs>/dynamic_debug/control
-bash: echo: write error: Invalid argument
Note, for systems without 'debugfs' enabled, the control file can be
found in ``/proc/dynamic_debug/control``.
Viewing Dynamic Debug Behaviour
===============================

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

@ -22,11 +22,13 @@
default: 0
acpi_backlight= [HW,ACPI]
acpi_backlight=vendor
acpi_backlight=video
If set to vendor, prefer vendor specific driver
{ vendor | video | native | none }
If set to vendor, prefer vendor-specific driver
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
of the ACPI video.ko driver.
If set to video, use the ACPI video.ko driver.
If set to native, use the device's native backlight mode.
If set to none, disable the ACPI backlight interface.
acpi_force_32bit_fadt_addr
force FADT to use 32 bit addresses rather than the
@ -683,7 +685,7 @@
coredump_filter=
[KNL] Change the default value for
/proc/<pid>/coredump_filter.
See also Documentation/filesystems/proc.txt.
See also Documentation/filesystems/proc.rst.
coresight_cpu_debug.enable
[ARM,ARM64]
@ -960,7 +962,7 @@
edid/1680x1050.bin, or edid/1920x1080.bin is given
and no file with the same name exists. Details and
instructions how to build your own EDID data are
available in Documentation/driver-api/edid.rst. An EDID
available in Documentation/admin-guide/edid.rst. An EDID
data set will only be used for a particular connector,
if its name and a colon are prepended to the EDID
name. Each connector may use a unique EDID data
@ -990,10 +992,6 @@
Documentation/admin-guide/dynamic-debug-howto.rst
for details.
nompx [X86] Disables Intel Memory Protection Extensions.
See Documentation/x86/intel_mpx.rst for more
information about the feature.
nopku [X86] Disable Memory Protection Keys CPU feature found
in some Intel CPUs.
@ -1473,6 +1471,14 @@
hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
hugetlb_cma= [HW] The size of a cma area used for allocation
of gigantic hugepages.
Format: nn[KMGTPE]
Reserve a cma area of given size and allocate gigantic
hugepages using the cma allocator. If enabled, the
boot-time allocation of gigantic hugepages is skipped.
hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
@ -2571,13 +2577,22 @@
For details see: Documentation/admin-guide/hw-vuln/mds.rst
mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
Amount of memory to be used when the kernel is not able
to see the whole system memory or for test.
Amount of memory to be used in cases as follows:
1 for test;
2 when the kernel is not able to see the whole system memory;
3 memory that lies after 'mem=' boundary is excluded from
the hypervisor, then assigned to KVM guests.
[X86] Work as limiting max address. Use together
with memmap= to avoid physical address space collisions.
Without memmap= PCI devices could be placed at addresses
belonging to unused RAM.
Note that this only takes effects during boot time since
in above case 3, memory may need be hot added after boot
if system memory of hypervisor is not sufficient.
mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel
memory.
@ -3720,6 +3735,9 @@
Override pmtimer IOPort with a hex value.
e.g. pmtmr=0x508
pm_debug_messages [SUSPEND,KNL]
Enable suspend/resume debug messages during boot up.
pnp.debug=1 [PNP]
Enable PNP debug messages (depends on the
CONFIG_PNP_DEBUG_MESSAGES option). Change at run-time
@ -3821,6 +3839,11 @@
before loading.
See Documentation/admin-guide/blockdev/ramdisk.rst.
prot_virt= [S390] enable hosting protected virtual machines
isolated from the hypervisor (if hardware supports
that).
Format: <bool>
psi= [KNL] Enable or disable pressure stall information
tracking.
Format: <bool>
@ -5164,8 +5187,7 @@
usbcore.old_scheme_first=
[USB] Start with the old device initialization
scheme, applies only to low and full-speed devices
(default 0 = off).
scheme (default 0 = off).
usbcore.usbfs_memory_mb=
[USB] Memory limit (in MB) for buffers allocated by

14
Documentation/admin-guide/mm/transhuge.rst
View File

@ -310,6 +310,11 @@ thp_fault_fallback
is incremented if a page fault fails to allocate
a huge page and instead falls back to using small pages.
thp_fault_fallback_charge
is incremented if a page fault fails to charge a huge page and
instead falls back to using small pages even though the
allocation was successful.
thp_collapse_alloc_failed
is incremented if khugepaged found a range
of pages that should be collapsed into one huge page but failed
@ -319,6 +324,15 @@ thp_file_alloc
is incremented every time a file huge page is successfully
allocated.
thp_file_fallback
is incremented if a file huge page is attempted to be allocated
but fails and instead falls back to using small pages.
thp_file_fallback_charge
is incremented if a file huge page cannot be charged and instead
falls back to using small pages even though the allocation was
successful.
thp_file_mapped
is incremented every time a file huge page is mapped into
user address space.

51
Documentation/admin-guide/mm/userfaultfd.rst
View File

@ -108,6 +108,57 @@ UFFDIO_COPY. They're atomic as in guaranteeing that nothing can see an
half copied page since it'll keep userfaulting until the copy has
finished.
Notes:
- If you requested UFFDIO_REGISTER_MODE_MISSING when registering then
you must provide some kind of page in your thread after reading from
the uffd. You must provide either UFFDIO_COPY or UFFDIO_ZEROPAGE.
The normal behavior of the OS automatically providing a zero page on
an annonymous mmaping is not in place.
- None of the page-delivering ioctls default to the range that you
registered with. You must fill in all fields for the appropriate
ioctl struct including the range.
- You get the address of the access that triggered the missing page
event out of a struct uffd_msg that you read in the thread from the
uffd. You can supply as many pages as you want with UFFDIO_COPY or
UFFDIO_ZEROPAGE. Keep in mind that unless you used DONTWAKE then
the first of any of those IOCTLs wakes up the faulting thread.
- Be sure to test for all errors including (pollfd[0].revents &
POLLERR). This can happen, e.g. when ranges supplied were
incorrect.
Write Protect Notifications
---------------------------
This is equivalent to (but faster than) using mprotect and a SIGSEGV
signal handler.
Firstly you need to register a range with UFFDIO_REGISTER_MODE_WP.
Instead of using mprotect(2) you use ioctl(uffd, UFFDIO_WRITEPROTECT,
struct *uffdio_writeprotect) while mode = UFFDIO_WRITEPROTECT_MODE_WP
in the struct passed in. The range does not default to and does not
have to be identical to the range you registered with. You can write
protect as many ranges as you like (inside the registered range).
Then, in the thread reading from uffd the struct will have
msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP set. Now you send
ioctl(uffd, UFFDIO_WRITEPROTECT, struct *uffdio_writeprotect) again
while pagefault.mode does not have UFFDIO_WRITEPROTECT_MODE_WP set.
This wakes up the thread which will continue to run with writes. This
allows you to do the bookkeeping about the write in the uffd reading
thread before the ioctl.
If you registered with both UFFDIO_REGISTER_MODE_MISSING and
UFFDIO_REGISTER_MODE_WP then you need to think about the sequence in
which you supply a page and undo write protect. Note that there is a
difference between writes into a WP area and into a !WP area. The
former will have UFFD_PAGEFAULT_FLAG_WP set, the latter
UFFD_PAGEFAULT_FLAG_WRITE. The latter did not fail on protection but
you still need to supply a page when UFFDIO_REGISTER_MODE_MISSING was
used.
QEMU/KVM
========

270
Documentation/admin-guide/pm/suspend-flows.rst Normal file
View File

@ -0,0 +1,270 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
=========================
System Suspend Code Flows
=========================
:Copyright: |copy| 2020 Intel Corporation
:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
At least one global system-wide transition needs to be carried out for the
system to get from the working state into one of the supported
:doc:`sleep states <sleep-states>`. Hibernation requires more than one
transition to occur for this purpose, but the other sleep states, commonly
referred to as *system-wide suspend* (or simply *system suspend*) states, need
only one.
For those sleep states, the transition from the working state of the system into
the target sleep state is referred to as *system suspend* too (in the majority
of cases, whether this means a transition or a sleep state of the system should
be clear from the context) and the transition back from the sleep state into the
working state is referred to as *system resume*.
The kernel code flows associated with the suspend and resume transitions for
different sleep states of the system are quite similar, but there are some
significant differences between the :ref:`suspend-to-idle <s2idle>` code flows
and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and
:ref:`standby <standby>` sleep states.
The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states
cannot be implemented without platform support and the difference between them
boils down to the platform-specific actions carried out by the suspend and
resume hooks that need to be provided by the platform driver to make them
available. Apart from that, the suspend and resume code flows for these sleep
states are mostly identical, so they both together will be referred to as
*platform-dependent suspend* states in what follows.
.. _s2idle_suspend:
Suspend-to-idle Suspend Code Flow
=================================
The following steps are taken in order to transition the system from the working
state to the :ref:`suspend-to-idle <s2idle>` sleep state:
1. Invoking system-wide suspend notifiers.
Kernel subsystems can register callbacks to be invoked when the suspend
transition is about to occur and when the resume transition has finished.
That allows them to prepare for the change of the system state and to clean
up after getting back to the working state.
2. Freezing tasks.
Tasks are frozen primarily in order to avoid unchecked hardware accesses
from user space through MMIO regions or I/O registers exposed directly to
it and to prevent user space from entering the kernel while the next step
of the transition is in progress (which might have been problematic for
various reasons).
All user space tasks are intercepted as though they were sent a signal and
put into uninterruptible sleep until the end of the subsequent system resume
transition.
The kernel threads that choose to be frozen during system suspend for
specific reasons are frozen subsequently, but they are not intercepted.
Instead, they are expected to periodically check whether or not they need
to be frozen and to put themselves into uninterruptible sleep if so. [Note,
however, that kernel threads can use locking and other concurrency controls
available in kernel space to synchronize themselves with system suspend and
resume, which can be much more precise than the freezing, so the latter is
not a recommended option for kernel threads.]
3. Suspending devices and reconfiguring IRQs.
Devices are suspended in four phases called *prepare*, *suspend*,
*late suspend* and *noirq suspend* (see :ref:`driverapi_pm_devices` for more
information on what exactly happens in each phase).
Every device is visited in each phase, but typically it is not physically
accessed in more than two of them.
The runtime PM API is disabled for every device during the *late* suspend
phase and high-level ("action") interrupt handlers are prevented from being
invoked before the *noirq* suspend phase.
Interrupts are still handled after that, but they are only acknowledged to
interrupt controllers without performing any device-specific actions that
would be triggered in the working state of the system (those actions are
deferred till the subsequent system resume transition as described
`below <s2idle_resume_>`_).
IRQs associated with system wakeup devices are "armed" so that the resume
transition of the system is started when one of them signals an event.
4. Freezing the scheduler tick and suspending timekeeping.
When all devices have been suspended, CPUs enter the idle loop and are put
into the deepest available idle state. While doing that, each of them
"freezes" its own scheduler tick so that the timer events associated with
the tick do not occur until the CPU is woken up by another interrupt source.
The last CPU to enter the idle state also stops the timekeeping which
(among other things) prevents high resolution timers from triggering going
forward until the first CPU that is woken up restarts the timekeeping.
That allows the CPUs to stay in the deep idle state relatively long in one
go.
From this point on, the CPUs can only be woken up by non-timer hardware
interrupts. If that happens, they go back to the idle state unless the
interrupt that woke up one of them comes from an IRQ that has been armed for
system wakeup, in which case the system resume transition is started.
.. _s2idle_resume:
Suspend-to-idle Resume Code Flow
================================
The following steps are taken in order to transition the system from the
:ref:`suspend-to-idle <s2idle>` sleep state into the working state:
1. Resuming timekeeping and unfreezing the scheduler tick.
When one of the CPUs is woken up (by a non-timer hardware interrupt), it
leaves the idle state entered in the last step of the preceding suspend
transition, restarts the timekeeping (unless it has been restarted already
by another CPU that woke up earlier) and the scheduler tick on that CPU is
unfrozen.
If the interrupt that has woken up the CPU was armed for system wakeup,
the system resume transition begins.
2. Resuming devices and restoring the working-state configuration of IRQs.
Devices are resumed in four phases called *noirq resume*, *early resume*,
*resume* and *complete* (see :ref:`driverapi_pm_devices` for more
information on what exactly happens in each phase).
Every device is visited in each phase, but typically it is not physically
accessed in more than two of them.
The working-state configuration of IRQs is restored after the *noirq* resume
phase and the runtime PM API is re-enabled for every device whose driver
supports it during the *early* resume phase.
3. Thawing tasks.
Tasks frozen in step 2 of the preceding `suspend <s2idle_suspend_>`_
transition are "thawed", which means that they are woken up from the
uninterruptible sleep that they went into at that time and user space tasks
are allowed to exit the kernel.
4. Invoking system-wide resume notifiers.
This is analogous to step 1 of the `suspend <s2idle_suspend_>`_ transition
and the same set of callbacks is invoked at this point, but a different
"notification type" parameter value is passed to them.
Platform-dependent Suspend Code Flow
====================================
The following steps are taken in order to transition the system from the working
state to platform-dependent suspend state:
1. Invoking system-wide suspend notifiers.
This step is the same as step 1 of the suspend-to-idle suspend transition
described `above <s2idle_suspend_>`_.
2. Freezing tasks.
This step is the same as step 2 of the suspend-to-idle suspend transition
described `above <s2idle_suspend_>`_.
3. Suspending devices and reconfiguring IRQs.
This step is analogous to step 3 of the suspend-to-idle suspend transition
described `above <s2idle_suspend_>`_, but the arming of IRQs for system
wakeup generally does not have any effect on the platform.
There are platforms that can go into a very deep low-power state internally
when all CPUs in them are in sufficiently deep idle states and all I/O
devices have been put into low-power states. On those platforms,
suspend-to-idle can reduce system power very effectively.
On the other platforms, however, low-level components (like interrupt
controllers) need to be turned off in a platform-specific way (implemented
in the hooks provided by the platform driver) to achieve comparable power
reduction.
That usually prevents in-band hardware interrupts from waking up the system,
which must be done in a special platform-dependent way. Then, the
configuration of system wakeup sources usually starts when system wakeup
devices are suspended and is finalized by the platform suspend hooks later
on.
4. Disabling non-boot CPUs.
On some platforms the suspend hooks mentioned above must run in a one-CPU
configuration of the system (in particular, the hardware cannot be accessed
by any code running in parallel with the platform suspend hooks that may,
and often do, trap into the platform firmware in order to finalize the
suspend transition).
For this reason, the CPU offline/online (CPU hotplug) framework is used
to take all of the CPUs in the system, except for one (the boot CPU),
offline (typically, the CPUs that have been taken offline go into deep idle
states).
This means that all tasks are migrated away from those CPUs and all IRQs are
rerouted to the only CPU that remains online.
5. Suspending core system components.
This prepares the core system components for (possibly) losing power going
forward and suspends the timekeeping.
6. Platform-specific power removal.
This is expected to remove power from all of the system components except
for the memory controller and RAM (in order to preserve the contents of the
latter) and some devices designated for system wakeup.
In many cases control is passed to the platform firmware which is expected
to finalize the suspend transition as needed.
Platform-dependent Resume Code Flow
===================================
The following steps are taken in order to transition the system from a
platform-dependent suspend state into the working state:
1. Platform-specific system wakeup.
The platform is woken up by a signal from one of the designated system
wakeup devices (which need not be an in-band hardware interrupt) and
control is passed back to the kernel (the working configuration of the
platform may need to be restored by the platform firmware before the
kernel gets control again).
2. Resuming core system components.
The suspend-time configuration of the core system components is restored and
the timekeeping is resumed.
3. Re-enabling non-boot CPUs.
The CPUs disabled in step 4 of the preceding suspend transition are taken
back online and their suspend-time configuration is restored.
4. Resuming devices and restoring the working-state configuration of IRQs.
This step is the same as step 2 of the suspend-to-idle suspend transition
described `above <s2idle_resume_>`_.
5. Thawing tasks.
This step is the same as step 3 of the suspend-to-idle suspend transition
described `above <s2idle_resume_>`_.
6. Invoking system-wide resume notifiers.
This step is the same as step 4 of the suspend-to-idle suspend transition
described `above <s2idle_resume_>`_.

1
Documentation/admin-guide/pm/system-wide.rst
View File

@ -8,3 +8,4 @@ System-Wide Power Management
:maxdepth: 2
sleep-states
suspend-flows

26
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -390,9 +390,17 @@ When ``kptr_restrict`` is set to 2, kernel pointers printed using
modprobe
========
This gives the full path of the modprobe command which the kernel will
use to load modules. This can be used to debug module loading
requests::
The full path to the usermode helper for autoloading kernel modules,
by default "/sbin/modprobe". This binary is executed when the kernel
requests a module. For example, if userspace passes an unknown
filesystem type to mount(), then the kernel will automatically request
the corresponding filesystem module by executing this usermode helper.
This usermode helper should insert the needed module into the kernel.
This sysctl only affects module autoloading. It has no effect on the
ability to explicitly insert modules.
This sysctl can be used to debug module loading requests::
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
@ -400,10 +408,15 @@ requests::
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
This only applies when the *kernel* is requesting that the module be
loaded; it won't have any effect if the module is being loaded
explicitly using ``modprobe`` from userspace.
Alternatively, if this sysctl is set to the empty string, then module
autoloading is completely disabled. The kernel will not try to
execute a usermode helper at all, nor will it call the
kernel_module_request LSM hook.
If CONFIG_STATIC_USERMODEHELPER=y is set in the kernel configuration,
then the configured static usermode helper overrides this sysctl,
except that the empty string is still accepted to completely disable
module autoloading as described above.
modules_disabled
================
@ -446,7 +459,6 @@ Notes:
successful IPC object allocation. If an IPC object allocation syscall
fails, it is undefined if the value remains unmodified or is reset to -1.
nmi_watchdog
============

6
Documentation/admin-guide/sysctl/user.rst
View File

@ -65,6 +65,12 @@ max_pid_namespaces
The maximum number of pid namespaces that any user in the current
user namespace may create.
max_time_namespaces
===================
The maximum number of time namespaces that any user in the current
user namespace may create.
max_user_namespaces
===================

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

@ -128,6 +128,9 @@ allowed to examine the unevictable lru (mlocked pages) for pages to compact.
This should be used on systems where stalls for minor page faults are an
acceptable trade for large contiguous free memory. Set to 0 to prevent
compaction from moving pages that are unevictable. Default value is 1.
On CONFIG_PREEMPT_RT the default value is 0 in order to avoid a page fault, due
to compaction, which would block the task from becomming active until the fault
is resolved.
dirty_background_bytes

20
Documentation/admin-guide/sysrq.rst
View File

@ -48,9 +48,10 @@ always allowed (by a user with admin privileges).
How do I use the magic SysRq key?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On x86 - You press the key combo :kbd:`ALT-SysRq-<command key>`.
On x86
You press the key combo :kbd:`ALT-SysRq-<command key>`.
.. note::
.. note::
Some
keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is
also known as the 'Print Screen' key. Also some keyboards cannot
@ -58,14 +59,15 @@ On x86 - You press the key combo :kbd:`ALT-SysRq-<command key>`.
have better luck with press :kbd:`Alt`, press :kbd:`SysRq`,
release :kbd:`SysRq`, press :kbd:`<command key>`, release everything.
On SPARC - You press :kbd:`ALT-STOP-<command key>`, I believe.
On SPARC
You press :kbd:`ALT-STOP-<command key>`, I believe.
On the serial console (PC style standard serial ports only)
You send a ``BREAK``, then within 5 seconds a command key. Sending
``BREAK`` twice is interpreted as a normal BREAK.
On PowerPC
Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`,
Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`.
:kbd:`Print Screen` (or :kbd:`F13`) - :kbd:`<command key>` may suffice.
On other
@ -73,7 +75,7 @@ On other
let me know so I can add them to this section.
On all
write a character to /proc/sysrq-trigger. e.g.::
Write a character to /proc/sysrq-trigger. e.g.::
echo t > /proc/sysrq-trigger
@ -282,7 +284,7 @@ Just ask them on the linux-kernel mailing list:
Credits
~~~~~~~
Written by Mydraal <vulpyne@vulpyne.net>
Updated by Adam Sulmicki <adam@cfar.umd.edu>
Updated by Jeremy M. Dolan <jmd@turbogeek.org> 2001/01/28 10:15:59
Added to by Crutcher Dunnavant <crutcher+kernel@datastacks.com>
- Written by Mydraal <vulpyne@vulpyne.net>
- Updated by Adam Sulmicki <adam@cfar.umd.edu>
- Updated by Jeremy M. Dolan <jmd@turbogeek.org> 2001/01/28 10:15:59
- Added to by Crutcher Dunnavant <crutcher+kernel@datastacks.com>

47
Documentation/arm64/amu.rst
View File

@ -23,13 +23,14 @@ optional external memory-mapped interface.
Version 1 of the Activity Monitors architecture implements a counter group
of four fixed and architecturally defined 64-bit event counters.
- CPU cycle counter: increments at the frequency of the CPU.
- Constant counter: increments at the fixed frequency of the system
clock.
- Instructions retired: increments with every architecturally executed
instruction.
- Memory stall cycles: counts instruction dispatch stall cycles caused by
misses in the last level cache within the clock domain.
- CPU cycle counter: increments at the frequency of the CPU.
- Constant counter: increments at the fixed frequency of the system
clock.
- Instructions retired: increments with every architecturally executed
instruction.
- Memory stall cycles: counts instruction dispatch stall cycles caused by
misses in the last level cache within the clock domain.
When in WFI or WFE these counters do not increment.
@ -57,11 +58,12 @@ counters, only the presence of the extension.
Firmware (code running at higher exception levels, e.g. arm-tf) support is
needed to:
- Enable access for lower exception levels (EL2 and EL1) to the AMU
registers.
- Enable the counters. If not enabled these will read as 0.
- Save/restore the counters before/after the CPU is being put/brought up
from the 'off' power state.
- Enable access for lower exception levels (EL2 and EL1) to the AMU
registers.
- Enable the counters. If not enabled these will read as 0.
- Save/restore the counters before/after the CPU is being put/brought up
from the 'off' power state.
When using kernels that have this feature enabled but boot with broken
firmware the user may experience panics or lockups when accessing the
@ -78,10 +80,11 @@ are not trapped in EL2/EL3.
The fixed counters of AMUv1 are accessible though the following system
register definitions:
- SYS_AMEVCNTR0_CORE_EL0
- SYS_AMEVCNTR0_CONST_EL0
- SYS_AMEVCNTR0_INST_RET_EL0
- SYS_AMEVCNTR0_MEM_STALL_EL0
- SYS_AMEVCNTR0_CORE_EL0
- SYS_AMEVCNTR0_CONST_EL0
- SYS_AMEVCNTR0_INST_RET_EL0
- SYS_AMEVCNTR0_MEM_STALL_EL0
Auxiliary platform specific counters can be accessed using
SYS_AMEVCNTR1_EL0(n), where n is a value between 0 and 15.
@ -93,9 +96,10 @@ Userspace access
----------------
Currently, access from userspace to the AMU registers is disabled due to:
- Security reasons: they might expose information about code executed in
secure mode.
- Purpose: AMU counters are intended for system management use.
- Security reasons: they might expose information about code executed in
secure mode.
- Purpose: AMU counters are intended for system management use.
Also, the presence of the feature is not visible to userspace.
@ -105,8 +109,9 @@ Virtualization
Currently, access from userspace (EL0) and kernelspace (EL1) on the KVM
guest side is disabled due to:
- Security reasons: they might expose information about code executed
by other guests or the host.
- Security reasons: they might expose information about code executed
by other guests or the host.
Any attempt to access the AMU registers will result in an UNDEFINED
exception being injected into the guest.

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

@ -73,6 +73,9 @@ File Mapping and Page Cache
.. kernel-doc:: mm/truncate.c
:export:
.. kernel-doc:: include/linux/pagemap.h
:internal:
Memory pools
============

86
Documentation/core-api/pin_user_pages.rst
View File

@ -52,8 +52,22 @@ Which flags are set by each wrapper
For these pin_user_pages*() functions, FOLL_PIN is OR'd in with whatever gup
flags the caller provides. The caller is required to pass in a non-null struct
pages* array, and the function then pin pages by incrementing each by a special
value. For now, that value is +1, just like get_user_pages*().::
pages* array, and the function then pins pages by incrementing each by a special
value: GUP_PIN_COUNTING_BIAS.
For huge pages (and in fact, any compound page of more than 2 pages), the
GUP_PIN_COUNTING_BIAS scheme is not used. Instead, an exact form of pin counting
is achieved, by using the 3rd struct page in the compound page. A new struct
page field, hpage_pinned_refcount, has been added in order to support this.
This approach for compound pages avoids the counting upper limit problems that
are discussed below. Those limitations would have been aggravated severely by
huge pages, because each tail page adds a refcount to the head page. And in
fact, testing revealed that, without a separate hpage_pinned_refcount field,
page overflows were seen in some huge page stress tests.
This also means that huge pages and compound pages (of order > 1) do not suffer
from the false positives problem that is mentioned below.::
Function
--------
@ -99,27 +113,6 @@ pages:
This also leads to limitations: there are only 31-10==21 bits available for a
counter that increments 10 bits at a time.
TODO: for 1GB and larger huge pages, this is cutting it close. That's because
when pin_user_pages() follows such pages, it increments the head page by "1"
(where "1" used to mean "+1" for get_user_pages(), but now means "+1024" for
pin_user_pages()) for each tail page. So if you have a 1GB huge page:
* There are 256K (18 bits) worth of 4 KB tail pages.
* There are 21 bits available to count up via GUP_PIN_COUNTING_BIAS (that is,
10 bits at a time)
* There are 21 - 18 == 3 bits available to count. Except that there aren't,
because you need to allow for a few normal get_page() calls on the head page,
as well. Fortunately, the approach of using addition, rather than "hard"
bitfields, within page->_refcount, allows for sharing these bits gracefully.
But we're still looking at about 8 references.
This, however, is a missing feature more than anything else, because it's easily
solved by addressing an obvious inefficiency in the original get_user_pages()
approach of retrieving pages: stop treating all the pages as if they were
PAGE_SIZE. Retrieve huge pages as huge pages. The callers need to be aware of
this, so some work is required. Once that's in place, this limitation mostly
disappears from view, because there will be ample refcounting range available.
* Callers must specifically request "dma-pinned tracking of pages". In other
words, just calling get_user_pages() will not suffice; a new set of functions,
pin_user_page() and related, must be used.
@ -173,8 +166,8 @@ CASE 4: Pinning for struct page manipulation only
-------------------------------------------------
Here, normal GUP calls are sufficient, so neither flag needs to be set.
page_dma_pinned(): the whole point of pinning
=============================================
page_maybe_dma_pinned(): the whole point of pinning
===================================================
The whole point of marking pages as "DMA-pinned" or "gup-pinned" is to be able
to query, "is this page DMA-pinned?" That allows code such as page_mkclean()
@ -186,7 +179,7 @@ and debates (see the References at the end of this document). It's a TODO item
here: fill in the details once that's worked out. Meanwhile, it's safe to say
that having this available: ::
static inline bool page_dma_pinned(struct page *page)
static inline bool page_maybe_dma_pinned(struct page *page)
...is a prerequisite to solving the long-running gup+DMA problem.
@ -215,12 +208,42 @@ has the following new calls to exercise the new pin*() wrapper functions:
You can monitor how many total dma-pinned pages have been acquired and released
since the system was booted, via two new /proc/vmstat entries: ::
/proc/vmstat/nr_foll_pin_requested
/proc/vmstat/nr_foll_pin_requested
/proc/vmstat/nr_foll_pin_acquired
/proc/vmstat/nr_foll_pin_released
Those are both going to show zero, unless CONFIG_DEBUG_VM is set. This is
because there is a noticeable performance drop in unpin_user_page(), when they
are activated.
Under normal conditions, these two values will be equal unless there are any
long-term [R]DMA pins in place, or during pin/unpin transitions.
* nr_foll_pin_acquired: This is the number of logical pins that have been
acquired since the system was powered on. For huge pages, the head page is
pinned once for each page (head page and each tail page) within the huge page.
This follows the same sort of behavior that get_user_pages() uses for huge
pages: the head page is refcounted once for each tail or head page in the huge
page, when get_user_pages() is applied to a huge page.
* nr_foll_pin_released: The number of logical pins that have been released since
the system was powered on. Note that pages are released (unpinned) on a
PAGE_SIZE granularity, even if the original pin was applied to a huge page.
Becaused of the pin count behavior described above in "nr_foll_pin_acquired",
the accounting balances out, so that after doing this::
pin_user_pages(huge_page);
for (each page in huge_page)
unpin_user_page(page);
...the following is expected::
nr_foll_pin_released == nr_foll_pin_acquired
(...unless it was already out of balance due to a long-term RDMA pin being in
place.)
Other diagnostics
=================
dump_page() has been enhanced slightly, to handle these new counting fields, and
to better report on compound pages in general. Specifically, for compound pages
with order > 1, the exact (hpage_pinned_refcount) pincount is reported.
References
==========
@ -228,5 +251,6 @@ References
* `Some slow progress on get_user_pages() (Apr 2, 2019) <https://lwn.net/Articles/784574/>`_
* `DMA and get_user_pages() (LPC: Dec 12, 2018) <https://lwn.net/Articles/774411/>`_
* `The trouble with get_user_pages() (Apr 30, 2018) <https://lwn.net/Articles/753027/>`_
* `LWN kernel index: get_user_pages() <https://lwn.net/Kernel/Index/#Memory_management-get_user_pages>`_
John Hubbard, October, 2019

6
Documentation/core-api/timekeeping.rst
View File

@ -154,9 +154,9 @@ architectures. These are the recommended replacements:
Use ktime_get() or ktime_get_ts64() instead.
.. c:function:: struct timeval do_gettimeofday( void )
struct timespec getnstimeofday( void )
struct timespec64 getnstimeofday64( void )
.. c:function:: void do_gettimeofday( struct timeval * )
void getnstimeofday( struct timespec * )
void getnstimeofday64( struct timespec64 * )
void ktime_get_real_ts( struct timespec * )
ktime_get_real_ts64() is a direct replacement, but consider using

40
Documentation/dev-tools/kunit/index.rst
View File

@ -17,14 +17,23 @@ What is KUnit?
==============
KUnit is a lightweight unit testing and mocking framework for the Linux kernel.
These tests are able to be run locally on a developer's workstation without a VM
or special hardware.
KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining unit test
cases, grouping related test cases into test suites, providing common
infrastructure for running tests, and much more.
KUnit consists of a kernel component, which provides a set of macros for easily
writing unit tests. Tests written against KUnit will run on kernel boot if
built-in, or when loaded if built as a module. These tests write out results to
the kernel log in `TAP <https://testanything.org/>`_ format.
To make running these tests (and reading the results) easier, KUnit offers
:doc:`kunit_tool <kunit-tool>`, which builds a `User Mode Linux
<http://user-mode-linux.sourceforge.net>`_ kernel, runs it, and parses the test
results. This provides a quick way of running KUnit tests during development,
without requiring a virtual machine or separate hardware.
Get started now: :doc:`start`
Why KUnit?
@ -36,21 +45,20 @@ allow all possible code paths to be tested in the code under test; this is only
possible if the code under test is very small and does not have any external
dependencies outside of the test's control like hardware.
Outside of KUnit, there are no testing frameworks currently
available for the kernel that do not require installing the kernel on a test
machine or in a VM and all require tests to be written in userspace running on
the kernel; this is true for Autotest, and kselftest, disqualifying
any of them from being considered unit testing frameworks.
KUnit provides a common framework for unit tests within the kernel.
KUnit addresses the problem of being able to run tests without needing a virtual
machine or actual hardware with User Mode Linux. User Mode Linux is a Linux
architecture, like ARM or x86; however, unlike other architectures it compiles
to a standalone program that can be run like any other program directly inside
of a host operating system; to be clear, it does not require any virtualization
support; it is just a regular program.
KUnit tests can be run on most architectures, and most tests are architecture
independent. All built-in KUnit tests run on kernel startup. Alternatively,
KUnit and KUnit tests can be built as modules and tests will run when the test
module is loaded.
Alternatively, kunit and kunit tests can be built as modules and tests will
run when the test module is loaded.
.. note::
KUnit can also run tests without needing a virtual machine or actual
hardware under User Mode Linux. User Mode Linux is a Linux architecture,
like ARM or x86, which compiles the kernel as a Linux executable. KUnit
can be used with UML either by building with ``ARCH=um`` (like any other
architecture), or by using :doc:`kunit_tool <kunit-tool>`.
KUnit is fast. Excluding build time, from invocation to completion KUnit can run
several dozen tests in only 10 to 20 seconds; this might not sound like a big
@ -81,3 +89,5 @@ How do I use it?
* :doc:`start` - for new users of KUnit
* :doc:`usage` - for a more detailed explanation of KUnit features
* :doc:`api/index` - for the list of KUnit APIs used for testing
* :doc:`kunit-tool` - for more information on the kunit_tool helper script
* :doc:`faq` - for answers to some common questions about KUnit

7
Documentation/dev-tools/kunit/kunit-tool.rst
View File

@ -12,6 +12,13 @@ the Linux kernel as UML (`User Mode Linux
<http://user-mode-linux.sourceforge.net/>`_), running KUnit tests, parsing
the test results and displaying them in a user friendly manner.
kunit_tool addresses the problem of being able to run tests without needing a
virtual machine or actual hardware with User Mode Linux. User Mode Linux is a
Linux architecture, like ARM or x86; however, unlike other architectures it
compiles the kernel as a standalone Linux executable that can be run like any
other program directly inside of a host operating system. To be clear, it does
not require any virtualization support: it is just a regular program.
What is a kunitconfig?
======================

78
Documentation/dev-tools/kunit/start.rst
View File

@ -9,11 +9,10 @@ Installing dependencies
KUnit has the same dependencies as the Linux kernel. As long as you can build
the kernel, you can run KUnit.
KUnit Wrapper
=============
Included with KUnit is a simple Python wrapper that helps format the output to
easily use and read KUnit output. It handles building and running the kernel, as
well as formatting the output.
Running tests with the KUnit Wrapper
====================================
Included with KUnit is a simple Python wrapper which runs tests under User Mode
Linux, and formats the test results.
The wrapper can be run with:
@ -21,22 +20,42 @@ The wrapper can be run with:
./tools/testing/kunit/kunit.py run --defconfig
For more information on this wrapper (also called kunit_tool) checkout the
For more information on this wrapper (also called kunit_tool) check out the
:doc:`kunit-tool` page.
Creating a .kunitconfig
=======================
The Python script is a thin wrapper around Kbuild. As such, it needs to be
configured with a ``.kunitconfig`` file. This file essentially contains the
regular Kernel config, with the specific test targets as well.
-----------------------
If you want to run a specific set of tests (rather than those listed in the
KUnit defconfig), you can provide Kconfig options in the ``.kunitconfig`` file.
This file essentially contains the regular Kernel config, with the specific
test targets as well. The ``.kunitconfig`` should also contain any other config
options required by the tests.
A good starting point for a ``.kunitconfig`` is the KUnit defconfig:
.. code-block:: bash
cd $PATH_TO_LINUX_REPO
cp arch/um/configs/kunit_defconfig .kunitconfig
Verifying KUnit Works
---------------------
You can then add any other Kconfig options you wish, e.g.:
.. code-block:: none
CONFIG_LIST_KUNIT_TEST=y
:doc:`kunit_tool <kunit-tool>` will ensure that all config options set in
``.kunitconfig`` are set in the kernel ``.config`` before running the tests.
It'll warn you if you haven't included the dependencies of the options you're
using.
.. note::
Note that removing something from the ``.kunitconfig`` will not trigger a
rebuild of the ``.config`` file: the configuration is only updated if the
``.kunitconfig`` is not a subset of ``.config``. This means that you can use
other tools (such as make menuconfig) to adjust other config options.
Running the tests
-----------------
To make sure that everything is set up correctly, simply invoke the Python
wrapper from your kernel repo:
@ -62,6 +81,41 @@ followed by a list of tests that are run. All of them should be passing.
Because it is building a lot of sources for the first time, the
``Building KUnit kernel`` step may take a while.
Running tests without the KUnit Wrapper
=======================================
If you'd rather not use the KUnit Wrapper (if, for example, you need to
integrate with other systems, or use an architecture other than UML), KUnit can
be included in any kernel, and the results read out and parsed manually.
.. note::
KUnit is not designed for use in a production system, and it's possible that
tests may reduce the stability or security of the system.
Configuring the kernel
----------------------
In order to enable KUnit itself, you simply need to enable the ``CONFIG_KUNIT``
Kconfig option (it's under Kernel Hacking/Kernel Testing and Coverage in
menuconfig). From there, you can enable any KUnit tests you want: they usually
have config options ending in ``_KUNIT_TEST``.
KUnit and KUnit tests can be compiled as modules: in this case the tests in a
module will be run when the module is loaded.
Running the tests
-----------------
Build and run your kernel as usual. Test output will be written to the kernel
log in `TAP <https://testanything.org/>`_ format.
.. note::
It's possible that there will be other lines and/or data interspersed in the
TAP output.
Writing your first test
=======================

14
Documentation/dev-tools/kunit/usage.rst
View File

@ -591,3 +591,17 @@ able to run one test case per invocation.
.. TODO(brendanhiggins@google.com): Add an actual example of an architecture
dependent KUnit test.
KUnit debugfs representation
============================
When kunit test suites are initialized, they create an associated directory
in /sys/kernel/debug/kunit/<test-suite>. The directory contains one file
- results: "cat results" displays results of each test case and the results
of the entire suite for the last test run.
The debugfs representation is primarily of use when kunit test suites are
run in a native environment, either as modules or builtin. Having a way
to display results like this is valuable as otherwise results can be
intermixed with other events in dmesg output. The maximum size of each
results file is KUNIT_LOG_SIZE bytes (defined in include/kunit/test.h).

1
Documentation/devicetree/bindings/.gitignore vendored
View File

@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
*.example.dts
processed-schema*.yaml

23
Documentation/devicetree/bindings/Makefile
View File

@ -2,6 +2,7 @@
DT_DOC_CHECKER ?= dt-doc-validate
DT_EXTRACT_EX ?= dt-extract-example
DT_MK_SCHEMA ?= dt-mk-schema
DT_MK_SCHEMA_USERONLY_FLAG := $(if $(DT_SCHEMA_FILES), -u)
quiet_cmd_chk_binding = CHKDT $(patsubst $(srctree)/%,%,$<)
cmd_chk_binding = $(DT_DOC_CHECKER) -u $(srctree)/$(src) $< ; \
@ -13,16 +14,18 @@ $(obj)/%.example.dts: $(src)/%.yaml FORCE
# Use full schemas when checking %.example.dts
DT_TMP_SCHEMA := $(obj)/processed-schema-examples.yaml
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) -o $@ $(real-prereqs)
DT_DOCS = $(addprefix $(src)/, \
$(shell \
cd $(srctree)/$(src) && \
find * \( -name '*.yaml' ! \
find_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \
-name 'processed-schema*' ! \
-name '*.example.dt.yaml' \) \
))
-name '*.example.dt.yaml' \)
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = rm -f $@ ; \
$(if $(DT_MK_SCHEMA_FLAGS), \
echo $(real-prereqs), \
$(find_cmd)) | \
xargs $(DT_MK_SCHEMA) $(DT_MK_SCHEMA_FLAGS) >> $@
DT_DOCS = $(shell $(find_cmd) | sed -e 's|^$(srctree)/||')
DT_SCHEMA_FILES ?= $(DT_DOCS)
@ -37,7 +40,7 @@ override DTC_FLAGS := \
$(obj)/processed-schema-examples.yaml: $(DT_DOCS) FORCE
$(call if_changed,mk_schema)
$(obj)/processed-schema.yaml: DT_MK_SCHEMA_FLAGS := -u
$(obj)/processed-schema.yaml: DT_MK_SCHEMA_FLAGS := $(DT_MK_SCHEMA_USERONLY_FLAG)
$(obj)/processed-schema.yaml: $(DT_SCHEMA_FILES) FORCE
$(call if_changed,mk_schema)

2
Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
View File

@ -21,6 +21,8 @@ properties:
required:
- compatible
additionalProperties: false
examples:
- |
clkmgr@ffd04000 {

2
Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
View File

@ -43,6 +43,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
ao-secure@140 {

86
Documentation/devicetree/bindings/arm/arm,integrator.yaml Normal file
View File

@ -0,0 +1,86 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,integrator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Integrator Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
These were the first ARM platforms officially supported by ARM Ltd.
They are ARMv4, ARMv5 and ARMv6-capable using different core tiles,
so the system is modular and can host a variety of CPU tiles called
"core tiles" and referred to in the device tree as "core modules".
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: ARM Integrator Application Platform, this board has a PCI
host and several PCI slots, as well as a number of slots for logical
expansion modules, it is referred to as an "ASIC Development
Motherboard" and is extended with custom FPGA and is intended for
rapid prototyping. See ARM DUI 0098B. This board can physically come
pre-packaged in a PC Tower form factor called Integrator/PP1 or a
special metal fixture called Integrator/PP2, see ARM DUI 0169A.
items:
- const: arm,integrator-ap
- description: ARM Integrator Compact Platform (HBI-0086), this board has
a compact form factor and mainly consists of the bare minimum
peripherals to make use of the core module. See ARM DUI 0159B.
items:
- const: arm,integrator-cp
- description: ARM Integrator Standard Development Board (SDB) Platform,
this board is a PCI-based board conforming to the Microsoft SDB
(HARP) specification. See ARM DUI 0099A.
items:
- const: arm,integrator-sp
core-module@10000000:
type: object
description: the root node in the Integrator platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Integrator variants.
properties:
compatible:
items:
- const: arm,core-module-integrator
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
description: All Integrator boards must provide a system controller as a
node in the root of the device tree.
type: object
properties:
compatible:
items:
- enum:
- arm,integrator-ap-syscon
- arm,integrator-cp-syscon
- arm,integrator-sp-syscon
- const: syscon
reg:
maxItems: 1
required:
- compatible
- reg
required:
- compatible
- core-module@10000000
...

123
Documentation/devicetree/bindings/arm/arm,realview.yaml Normal file
View File

@ -0,0 +1,123 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,realview.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM RealView Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
The ARM RealView series of reference designs were built to explore the ARM
11, Cortex A-8 and Cortex A-9 CPUs. This included new features compared to
the earlier CPUs such as TrustZone and multicore (MPCore).
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: ARM RealView Emulation Baseboard (HBI-0140) was created
as a generic platform to test different FPGA designs, and has
pluggable CPU modules, see ARM DUI 0303E.
items:
- const: arm,realview-eb
- description: ARM RealView Platform Baseboard for ARM1176JZF-S
(HBI-0147) was created as a development board to test ARM TrustZone,
CoreSight and Intelligent Energy Management (IEM) see ARM DUI 0425F.
items:
- const: arm,realview-pb1176
- description: ARM RealView Platform Baseboard for ARM 11 MPCore
(HBI-0159, HBI-0175 and HBI-0176) was created to showcase
multiprocessing with ARM11 using MPCore using symmetric
multiprocessing (SMP). See ARM DUI 0351E.
items:
- const: arm,realview-pb11mp
- description: ARM RealView Platform Baseboard for Cortex-A8 (HBI-0178,
HBI-0176 and HBI-0175) was the first reference platform for the
Cortex CPU family, including a Cortex-A8 test chip.
items:
- const: arm,realview-pba8
- description: ARM RealView Platform Baseboard Explore for Cortex-A9
(HBI-0182 and HBI-0183) was the reference platform for the Cortex-A9
CPU.
items:
- const: arm,realview-pbx
soc:
description: All RealView boards must provide a soc node in the root of the
device tree, representing the System-on-Chip since these test chips are
rather complex.
type: object
properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb-soc
- const: simple-bus
- items:
- const: arm,realview-pb1176-soc
- const: simple-bus
- items:
- const: arm,realview-pb11mp-soc
- const: simple-bus
- items:
- const: arm,realview-pba8-soc
- const: simple-bus
- items:
- const: arm,realview-pbx-soc
- const: simple-bus
patternProperties:
"^.*syscon@[0-9a-f]+$":
type: object
description: All RealView boards must provide a syscon system controller
node inside the soc node.
properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb11mp-revb-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb11mp-revc-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb1176-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb11mp-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pba8-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pbx-syscon
- const: syscon
- const: simple-mfd
required:
- compatible
- reg
required:
- compatible
required:
- compatible
- soc
...

71
Documentation/devicetree/bindings/arm/arm,versatile.yaml Normal file
View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,versatile.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
The ARM Versatile boards are two variants of ARM926EJ-S evaluation boards
with various pluggable interface boards, in essence the Versatile PB version
is a superset of the Versatile AB version.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: The ARM Versatile Application Baseboard (HBI-0118) is an
evaluation board specifically for the ARM926EJ-S. It can be connected
to an IB1 interface board for a touchscreen-type use case or an IB2
for a candybar phone-type use case. See ARM DUI 0225D.
items:
- const: arm,versatile-ab
- description: The ARM Versatile Platform Baseboard (HBI-0117) is an
extension of the Versatile Application Baseboard that includes a
PCI host controller. Like the sibling board, it is done specifically
for ARM926EJ-S. See ARM DUI 0224B.
items:
- const: arm,versatile-pb
core-module@10000000:
type: object
description: the root node in the Versatile platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Versatile variants.
properties:
compatible:
items:
- const: arm,core-module-versatile
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
type: object
description: When fitted with the IB2 Interface Board, the Versatile
AB will present an optional system controller node which controls the
extra peripherals on the interface board.
properties:
compatible:
contains:
const: arm,versatile-ib2-syscon
required:
- compatible
- reg
required:
- compatible
- core-module@10000000
...

223
Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml Normal file
View File

@ -0,0 +1,223 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,vexpress-juno.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express and Juno Boards Device Tree Bindings
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
- Linus Walleij <linus.walleij@linaro.org>
description: |+
ARM's Versatile Express platform were built as reference designs for exploring
multicore Cortex-A class systems. The Versatile Express family contains both
32 bit (Aarch32) and 64 bit (Aarch64) systems.
The board consist of a motherboard and one or more daughterboards (tiles). The
motherboard provides a set of peripherals. Processor and RAM "live" on the
tiles.
The motherboard and each core tile should be described by a separate Device
Tree source file, with the tile's description including the motherboard file
using an include directive. As the motherboard can be initialized in one of
two different configurations ("memory maps"), care must be taken to include
the correct one.
When a new generation of boards were introduced under the name "Juno", these
shared to many common characteristics with the Versatile Express that the
"arm,vexpress" compatible was retained in the root node, and these are
included in this binding schema as well.
The root node indicates the CPU SoC on the core tile, and this
is a daughterboard to the main motherboard. The name used in the compatible
string shall match the name given in the core tile's technical reference
manual, followed by "arm,vexpress" as an additional compatible value. If
further subvariants are released of the core tile, even more fine-granular
compatible strings with up to three compatible strings are used.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: CoreTile Express A9x4 (V2P-CA9) has 4 Cortex A9 CPU cores
in MPCore configuration in a test chip on the core tile. See ARM
DUI 0448I. This was the first Versatile Express platform.
items:
- const: arm,vexpress,v2p-ca9
- const: arm,vexpress
- description: CoreTile Express A5x2 (V2P-CA5s) has 2 Cortex A5 CPU cores
in a test chip on the core tile. It is intended to evaluate NEON, FPU
and Jazelle support in the Cortex A5 family. See ARM DUI 0541C.
items:
- const: arm,vexpress,v2p-ca5s
- const: arm,vexpress
- description: Coretile Express A15x2 (V2P-CA15) has 2 Cortex A15 CPU
cores in a MPCore configuration in a test chip on the core tile. See
ARM DUI 0604F.
items:
- const: arm,vexpress,v2p-ca15
- const: arm,vexpress
- description: CoreTile Express A15x4 (V2P-CA15, HBI-0237A) has 4 Cortex
A15 CPU cores in a test chip on the core tile. This is the first test
chip called "TC1".
items:
- const: arm,vexpress,v2p-ca15,tc1
- const: arm,vexpress,v2p-ca15
- const: arm,vexpress
- description: Coretile Express A15x2 A7x3 (V2P-CA15_A7) has 2 Cortex A15
CPU cores and 3 Cortex A7 cores in a big.LITTLE MPCore configuration
in a test chip on the core tile. See ARM DDI 0503I.
items:
- const: arm,vexpress,v2p-ca15_a7
- const: arm,vexpress
- description: LogicTile Express 20MG (V2F-1XV7) has 2 Cortex A53 CPU
cores in a test chip on the core tile. See ARM DDI 0498D.
items:
- const: arm,vexpress,v2f-1xv7,ca53x2
- const: arm,vexpress,v2f-1xv7
- const: arm,vexpress
- description: Arm Versatile Express Juno "r0" (the first Juno board,
V2M-Juno) was introduced as a vehicle for evaluating big.LITTLE on
AArch64 CPU cores. It has 2 Cortex A57 CPU cores and 4 Cortex A53
cores in a big.LITTLE configuration. It also features the MALI T624
GPU. See ARM document 100113_0000_07_en.
items:
- const: arm,juno
- const: arm,vexpress
- description: Arm Versatile Express Juno r1 Development Platform
(V2M-Juno r1) was introduced mainly aimed at development of PCIe
based systems. Juno r1 also has support for AXI masters placed on
the TLX connectors to join the coherency domain. Otherwise it is the
same configuration as Juno r0. See ARM document 100122_0100_06_en.
items:
- const: arm,juno-r1
- const: arm,juno
- const: arm,vexpress
- description: Arm Versatile Express Juno r2 Development Platform
(V2M-Juno r2). It has the same feature set as Juno r0 and r1. See
ARM document 100114_0200_04_en.
items:
- const: arm,juno-r2
- const: arm,juno
- const: arm,vexpress
- description: Arm AEMv8a Versatile Express Real-Time System Model
(VE RTSM) is a programmers view of the Versatile Express with Arm
v8A hardware. See ARM DUI 0575D.
items:
- const: arm,rtsm_ve,aemv8a
- const: arm,vexpress
- description: Arm FVP (Fixed Virtual Platform) base model revision C
See ARM Document 100964_1190_00_en.
items:
- const: arm,fvp-base-revc
- const: arm,vexpress
- description: Arm Foundation model for Aarch64
items:
- const: arm,foundation-aarch64
- const: arm,vexpress
arm,hbi:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: This indicates the ARM HBI (Hardware Board ID), this is
ARM's unique board model ID, visible on the PCB's silkscreen.
arm,vexpress,site:
description: As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
For this reason the root node and main motherboard node must define this
property, describing the physical location of the children nodes.
0 means motherboard site, while 1 and 2 are daughterboard sites, and
0xf means "sisterboard" which is the site containing the main CPU tile.
allOf:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- minimum: 0
maximum: 15
arm,vexpress,position:
description: When daughterboards are stacked on one site, their position
in the stack be be described this attribute.
allOf:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- minimum: 0
maximum: 3
arm,vexpress,dcc:
description: When describing tiles consisting of more than one DCC, its
number can be specified with this attribute.
allOf:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- minimum: 0
maximum: 3
patternProperties:
"^bus@[0-9a-f]+$":
description: Static Memory Bus (SMB) node, if this exists it describes
the connection between the motherboard and any tiles. Sometimes the
compatible is placed directly under this node, sometimes it is placed
in a subnode named "motherboard". Sometimes the compatible includes
"arm,vexpress,v2?-p1" sometimes (on software models) is is just
"simple-bus". If the compatible is placed in the "motherboard" node,
it is stricter and always has two compatibles.
type: object
allOf:
- $ref: '/schemas/simple-bus.yaml'
properties:
compatible:
oneOf:
- items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
- const: simple-bus
motherboard:
type: object
description: The motherboard description provides a single "motherboard"
node using 2 address cells corresponding to the Static Memory Bus
used between the motherboard and the tile. The first cell defines the
Chip Select (CS) line number, the second cell address offset within
the CS. All interrupt lines between the motherboard and the tile
are active high and are described using single cell.
properties:
"#address-cells":
const: 2
"#size-cells":
const: 1
compatible:
items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
arm,v2m-memory-map:
description: This describes the memory map type.
allOf:
- $ref: '/schemas/types.yaml#/definitions/string'
- enum:
- rs1
- rs2
required:
- compatible
required:
- compatible
allOf:
- if:
properties:
compatible:
contains:
enum:
- arm,vexpress,v2p-ca9
- arm,vexpress,v2p-ca5s
- arm,vexpress,v2p-ca15
- arm,vexpress,v2p-ca15_a7
- arm,vexpress,v2f-1xv7,ca53x2
then:
required:
- arm,hbi
...

237
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -1,237 +0,0 @@
ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform)
-----------------------------------------------------------------------------
ARM's oldest Linux-supported platform with connectors for different core
tiles of ARMv4, ARMv5 and ARMv6 type.
Required properties (in root node):
compatible = "arm,integrator-ap"; /* Application Platform */
compatible = "arm,integrator-cp"; /* Compact Platform */
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
Required nodes:
- core-module: the root node to the Integrator platforms must have
a core-module with regs and the compatible string
"arm,core-module-integrator"
- external-bus-interface: the root node to the Integrator platforms
must have an external bus interface with regs and the
compatible-string "arm,external-bus-interface"
Required properties for the core module:
- regs: the location and size of the core module registers, one
range of 0x200 bytes.
- syscon: the root node of the Integrator platforms must have a
system controller node pointing to the control registers,
with the compatible string
"arm,integrator-ap-syscon"
"arm,integrator-cp-syscon"
respectively.
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x100 bytes.
Required properties for the AP system controller:
- interrupts: the AP syscon node must include the logical module
interrupts, stated in order of module instance <module 0>,
<module 1>, <module 2> ... for the CP system controller this
is not required not of any use.
/dts-v1/;
/include/ "integrator.dtsi"
/ {
model = "ARM Integrator/AP";
compatible = "arm,integrator-ap";
core-module@10000000 {
compatible = "arm,core-module-integrator";
reg = <0x10000000 0x200>;
};
ebi@12000000 {
compatible = "arm,external-bus-interface";
reg = <0x12000000 0x100>;
};
syscon {
compatible = "arm,integrator-ap-syscon";
reg = <0x11000000 0x100>;
interrupt-parent = <&pic>;
/* These are the logic module IRQs */
interrupts = <9>, <10>, <11>, <12>;
};
};
ARM Versatile Application and Platform Baseboards
-------------------------------------------------
ARM's development hardware platform with connectors for customizable
core tiles. The hardware configuration of the Versatile boards is
highly customizable.
Required properties (in root node):
compatible = "arm,versatile-ab"; /* Application baseboard */
compatible = "arm,versatile-pb"; /* Platform baseboard */
Interrupt controllers:
- VIC required properties:
compatible = "arm,versatile-vic";
interrupt-controller;
#interrupt-cells = <1>;
- SIC required properties:
compatible = "arm,versatile-sic";
interrupt-controller;
#interrupt-cells = <1>;
Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
Optional nodes:
- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface
board mounted, this has a separate system controller that is
defined in this node.
Required properties:
compatible = "arm,versatile-ib2-syscon", "syscon"
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
the ARM11 and Cortex A-8 and Cortex A-9 processors.
Required properties (in root node):
/* RealView Emulation Baseboard */
compatible = "arm,realview-eb";
/* RealView Platform Baseboard for ARM1176JZF-S */
compatible = "arm,realview-pb1176";
/* RealView Platform Baseboard for ARM11 MPCore */
compatible = "arm,realview-pb11mp";
/* RealView Platform Baseboard for Cortex A-8 */
compatible = "arm,realview-pba8";
/* RealView Platform Baseboard Explore for Cortex A-9 */
compatible = "arm,realview-pbx";
Required nodes:
- soc: some node of the RealView platforms must be the SoC
node that contain the SoC-specific devices, with the compatible
string set to one of these tuples:
"arm,realview-eb-soc", "simple-bus"
"arm,realview-pb1176-soc", "simple-bus"
"arm,realview-pb11mp-soc", "simple-bus"
"arm,realview-pba8-soc", "simple-bus"
"arm,realview-pbx-soc", "simple-bus"
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these:
"arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"
"arm,realview-pba8-syscon", "syscon"
"arm,realview-pbx-syscon", "syscon"
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x1000 bytes.
Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
#address-cells = <1>;
#size-cells = <1>;
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "arm,realview-pb1176-soc", "simple-bus";
ranges;
syscon: syscon@10000000 {
compatible = "arm,realview-syscon", "syscon";
reg = <0x10000000 0x1000>;
};
};
};
ARM Versatile Express Boards
-----------------------------
For details on the device tree bindings for ARM Versatile Express boards
please consult the vexpress.txt file in the same directory as this file.
ARM Juno Boards
----------------
The Juno boards are targeting development for AArch64 systems. The first
iteration, Juno r0, is a vehicle for evaluating big.LITTLE on AArch64,
with the second iteration, Juno r1, mainly aimed at development of PCIe
based systems. Juno r1 also has support for AXI masters placed on the TLX
connectors to join the coherency domain.
Juno boards are described in a similar way to ARM Versatile Express boards,
with the motherboard part of the hardware being described in a separate file
to highlight the fact that is part of the support infrastructure for the SoC.
Juno device tree bindings also share the Versatile Express bindings as
described under the RS1 memory mapping.
Required properties (in root node):
compatible = "arm,juno"; /* For Juno r0 board */
compatible = "arm,juno-r1"; /* For Juno r1 board */
compatible = "arm,juno-r2"; /* For Juno r2 board */
Required nodes:
The description for the board must include:
- a "psci" node describing the boot method used for the secondary CPUs.
A detailed description of the bindings used for "psci" nodes is present
in the psci.yaml file.
- a "cpus" node describing the available cores and their associated
"enable-method"s. For more details see cpus.yaml file.
Example:
/dts-v1/;
/ {
model = "ARM Juno development board (r0)";
compatible = "arm,juno", "arm,vexpress";
interrupt-parent = <&gic>;
#address-cells = <2>;
#size-cells = <2>;
cpus {
#address-cells = <2>;
#size-cells = <0>;
A57_0: cpu@0 {
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
};
.....
A53_0: cpu@100 {
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";
};
.....
};
};

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method.txt
View File

@ -1,36 +0,0 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
The enable method is specified by defining the following required
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm11351-cpu-method";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
};
};

10
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.txt
View File

@ -1,10 +0,0 @@
Broadcom BCM11351 device tree bindings
-------------------------------------------
Boards with the bcm281xx SoC family (which includes bcm11130, bcm11140,
bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties:
Required root node property:
compatible = "brcm,bcm11351";
DEPRECATED: compatible = "bcm,bcm11351";

21
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml Normal file
View File

@ -0,0 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm11351.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM11351 device tree bindings
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm28155-ap
- const: brcm,bcm11351
...

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM21664 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM21664
SoC.
Required root node property:
- compatible: brcm,bcm21664
Example:
/ {
model = "BCM21664 SoC";
compatible = "brcm,bcm21664";
[...]
}

21
Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml Normal file
View File

@ -0,0 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm21664.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM21664 device tree bindings
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm21664-garnet
- const: brcm,bcm21664
...

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550-cpu-method.txt
View File

@ -1,36 +0,0 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM23550
The enable method is specified by defining the following required
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm23550";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm23550";
secondary-boot-reg = <0x3500417c>;
};
};

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM23550 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM23550
SoC.
Required root node property:
- compatible: brcm,bcm23550
Example:
/ {
model = "BCM23550 SoC";
compatible = "brcm,bcm23550";
[...]
}

21
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml Normal file
View File

@ -0,0 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm23550.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM23550 device tree bindings
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm23550-sparrow
- const: brcm,bcm23550
...

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM4708 device tree bindings
-------------------------------------------
Boards with the BCM4708 SoC shall have the following properties:
Required root node property:
bcm4708
compatible = "brcm,bcm4708";
bcm4709
compatible = "brcm,bcm4709";
bcm53012
compatible = "brcm,bcm53012";

88
Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml Normal file
View File

@ -0,0 +1,88 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm4708.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM4708 device tree bindings
description:
Broadcom BCM4708/47081/4709/47094/53012 Wi-Fi/network SoCs based
on the iProc architecture (Northstar).
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
- Hauke Mehrtens <hauke@hauke-m.de>
- Rafal Milecki <zajec5@gmail.com>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: BCM4708 based boards
items:
- enum:
- asus,rt-ac56u
- asus,rt-ac68u
- buffalo,wzr-1750dhp
- linksys,ea6300-v1
- linksys,ea6500-v2
- luxul,xap-1510v1
- luxul,xwc-1000
- netgear,r6250v1
- netgear,r6300v2
- smartrg,sr400ac
- brcm,bcm94708
- const: brcm,bcm4708
- description: BCM47081 based boards
items:
- enum:
- asus,rt-n18u
- buffalo,wzr-600dhp2
- buffalo,wzr-900dhp
- luxul,xap-1410v1
- luxul,xwr-1200v1
- tplink,archer-c5-v2
- const: brcm,bcm47081
- const: brcm,bcm4708
- description: BCM4709 based boards
items:
- enum:
- asus,rt-ac87u
- buffalo,wxr-1900dhp
- linksys,ea9200
- netgear,r7000
- netgear,r8000
- tplink,archer-c9-v1
- brcm,bcm94709
- const: brcm,bcm4709
- const: brcm,bcm4708
- description: BCM47094 based boards
items:
- enum:
- dlink,dir-885l
- linksys,panamera
- luxul,abr-4500-v1
- luxul,xap-1610-v1
- luxul,xbr-4500-v1
- luxul,xwc-2000-v1
- luxul,xwr-3100v1
- luxul,xwr-3150-v1
- netgear,r8500
- phicomm,k3
- const: brcm,bcm47094
- const: brcm,bcm4708
- description: BCM53012 based boards
items:
- enum:
- brcm,bcm953012er
- brcm,bcm953012hr
- brcm,bcm953012k
- const: brcm,brcm53012
- const: brcm,bcm4708
...

31
Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.txt
View File

@ -1,31 +0,0 @@
Broadcom Cygnus device tree bindings
------------------------------------
Boards with Cygnus SoCs shall have the following properties:
Required root node property:
BCM11300
compatible = "brcm,bcm11300", "brcm,cygnus";
BCM11320
compatible = "brcm,bcm11320", "brcm,cygnus";
BCM11350
compatible = "brcm,bcm11350", "brcm,cygnus";
BCM11360
compatible = "brcm,bcm11360", "brcm,cygnus";
BCM58300
compatible = "brcm,bcm58300", "brcm,cygnus";
BCM58302
compatible = "brcm,bcm58302", "brcm,cygnus";
BCM58303
compatible = "brcm,bcm58303", "brcm,cygnus";
BCM58305
compatible = "brcm,bcm58305", "brcm,cygnus";

29
Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml Normal file
View File

@ -0,0 +1,29 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,cygnus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Cygnus device tree bindings
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm11300
- brcm,bcm11320
- brcm,bcm11350
- brcm,bcm11360
- brcm,bcm58300
- brcm,bcm58302
- brcm,bcm58303
- brcm,bcm58305
- const: brcm,cygnus
...

14
Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt
View File

@ -1,14 +0,0 @@
Broadcom Hurricane 2 device tree bindings
---------------------------------------
Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs
are based on Broadcom's iProc SoC architecture and feature a single core Cortex
A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND
flash and a PCIe attached integrated switching engine.
Boards with Hurricane SoCs shall have the following properties:
Required root node property:
BCM53342
compatible = "brcm,bcm53342", "brcm,hr2";

28
Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml Normal file
View File

@ -0,0 +1,28 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,hr2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Hurricane 2 device tree bindings
description:
Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs
are based on Broadcom's iProc SoC architecture and feature a single core Cortex
A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND
flash and a PCIe attached integrated switching engine.
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- ubnt,unifi-switch8
- const: brcm,bcm53342
- const: brcm,hr2
...

9
Documentation/devicetree/bindings/arm/bcm/brcm,ns2.txt
View File

@ -1,9 +0,0 @@
Broadcom North Star 2 (NS2) device tree bindings
------------------------------------------------
Boards with NS2 shall have the following properties:
Required root node property:
NS2 SVK board
compatible = "brcm,ns2-svk", "brcm,ns2";

23
Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml Normal file
View File

@ -0,0 +1,23 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,ns2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom North Star 2 (NS2) device tree bindings
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,ns2-svk
- brcm,ns2-xmc
- const: brcm,ns2
...

39
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
View File

@ -1,39 +0,0 @@
Broadcom Northstar Plus SoC CPU Enable Method
---------------------------------------------
This binding defines the enable method used for starting secondary
CPU in the following Broadcom SoCs:
BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
The enable method is specified by defining the following required
properties in the corresponding secondary "cpu" device tree node:
- enable-method = "brcm,bcm-nsp-smp";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register which should hold the common
entry point for a secondary CPU. This entry is cpu node specific
and should be added per cpu. E.g., in case of NSP (BCM58625) which
is a dual core CPU SoC, this entry should be added to cpu1 node.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
next-level-cache = <&L2>;
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
next-level-cache = <&L2>;
enable-method = "brcm,bcm-nsp-smp";
secondary-boot-reg = <0xffff042c>;
reg = <1>;
};
};

34
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
View File

@ -1,34 +0,0 @@
Broadcom Northstar Plus device tree bindings
--------------------------------------------
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
Boards with Northstar Plus SoCs shall have the following properties:
Required root node property:
BCM58522
compatible = "brcm,bcm58522", "brcm,nsp";
BCM58525
compatible = "brcm,bcm58525", "brcm,nsp";
BCM58535
compatible = "brcm,bcm58535", "brcm,nsp";
BCM58622
compatible = "brcm,bcm58622", "brcm,nsp";
BCM58623
compatible = "brcm,bcm58623", "brcm,nsp";
BCM58625
compatible = "brcm,bcm58625", "brcm,nsp";
BCM88312
compatible = "brcm,bcm88312", "brcm,nsp";

36
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml Normal file
View File

@ -0,0 +1,36 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,nsp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Northstar Plus device tree bindings
description:
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm58522
- brcm,bcm58525
- brcm,bcm58535
- brcm,bcm58622
- brcm,bcm58623
- brcm,bcm58625
- brcm,bcm88312
- const: brcm,nsp
...

12
Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
View File

@ -1,12 +0,0 @@
Broadcom Stingray device tree bindings
------------------------------------------------
Boards with Stingray shall have the following properties:
Required root node property:
Stingray Combo SVK board
compatible = "brcm,bcm958742k", "brcm,stingray";
Stingray SST100 board
compatible = "brcm,bcm958742t", "brcm,stingray";

24
Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml Normal file
View File

@ -0,0 +1,24 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,stingray.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Stingray device tree bindings
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm958742k
- brcm,bcm958742t
- brcm,bcm958802a802x
- const: brcm,stingray
...

10
Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt
View File

@ -1,10 +0,0 @@
Broadcom Vulcan device tree bindings
------------------------------------
Boards with Broadcom Vulcan shall have the following root property:
Broadcom Vulcan Evaluation Board:
compatible = "brcm,vulcan-eval", "brcm,vulcan-soc";
Generic Vulcan board:
compatible = "brcm,vulcan-soc";

22
Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml Normal file
View File

@ -0,0 +1,22 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,vulcan-soc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Vulcan device tree bindings
maintainers:
- Robert Richter <rrichter@marvell.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,vulcan-eval
- cavium,thunderx2-cn9900
- const: brcm,vulcan-soc
...

336
Documentation/devicetree/bindings/arm/coresight-cti.yaml Normal file
View File

@ -0,0 +1,336 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/coresight-cti.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Coresight Cross Trigger Interface (CTI) device.
description: |
The CoreSight Embedded Cross Trigger (ECT) consists of CTI devices connected
to one or more CoreSight components and/or a CPU, with CTIs interconnected in
a star topology via the Cross Trigger Matrix (CTM), which is not programmable.
The ECT components are not part of the trace generation data path and are thus
not part of the CoreSight graph described in the general CoreSight bindings
file coresight.txt.
The CTI component properties define the connections between the individual
CTI and the components it is directly connected to, consisting of input and
output hardware trigger signals. CTIs can have a maximum number of input and
output hardware trigger signals (8 each for v1 CTI, 32 each for v2 CTI). The
number is defined at design time, the maximum of each defined in the DEVID
register.
CTIs are interconnected in a star topology via the CTM, using a number of
programmable channels, usually 4, but again implementation defined and
described in the DEVID register. The star topology is not required to be
described in the bindings as the actual connections are software
programmable.
In general the connections between CTI and components via the trigger signals
are implementation defined, except when the CTI is connected to an ARM v8
architecture core and optional ETM.
In this case the ARM v8 architecture defines the required signal connections
between CTI and the CPU core and ETM if present. In the case of a v8
architecturally connected CTI an additional compatible string is used to
indicate this feature (arm,coresight-cti-v8-arch).
When CTI trigger connection information is unavailable then a minimal driver
binding can be declared with no explicit trigger signals. This will result
the driver detecting the maximum available triggers and channels from the
DEVID register and make them all available for use as a single default
connection. Any user / client application will require additional information
on the connections between the CTI and other components for correct operation.
This information might be found by enabling the Integration Test registers in
the driver (set CONFIG_CORESIGHT_CTI_INTEGRATION_TEST in Kernel
configuration). These registers may be used to explore the trigger connections
between CTI and other CoreSight components.
Certain triggers between CoreSight devices and the CTI have specific types
and usages. These can be defined along with the signal indexes with the
constants defined in <dt-bindings/arm/coresight-cti-dt.h>
For example a CTI connected to a core will usually have a DBGREQ signal. This
is defined in the binding as type PE_EDBGREQ. These types will appear in an
optional array alongside the signal indexes. Omitting types will default all
signals to GEN_IO.
Note that some hardware trigger signals can be connected to non-CoreSight
components (e.g. UART etc) depending on hardware implementation.
maintainers:
- Mike Leach <mike.leach@linaro.org>
allOf:
- $ref: /schemas/arm/primecell.yaml#
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
enum:
- arm,coresight-cti
required:
- compatible
properties:
$nodename:
pattern: "^cti(@[0-9a-f]+)$"
compatible:
oneOf:
- items:
- const: arm,coresight-cti
- const: arm,primecell
- items:
- const: arm,coresight-cti-v8-arch
- const: arm,coresight-cti
- const: arm,primecell
reg:
maxItems: 1
cpu:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Handle to cpu this device is associated with. This must appear in the
base cti node if compatible string arm,coresight-cti-v8-arch is used,
or may appear in a trig-conns child node when appropriate.
arm,cti-ctm-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the CTM this CTI is connected to, in large systems with multiple
separate CTI/CTM nets. Typically multi-socket systems where the CTM is
propagated between sockets.
arm,cs-dev-assoc:
$ref: /schemas/types.yaml#/definitions/phandle
description:
defines a phandle reference to an associated CoreSight trace device.
When the associated trace device is enabled, then the respective CTI
will be enabled. Use in a trig-conns node, or in CTI base node when
compatible string arm,coresight-cti-v8-arch used. If the associated
device has not been registered then the node name will be stored as
the connection name for later resolution. If the associated device is
not a CoreSight device or not registered then the node name will remain
the connection name and automatic enabling will not occur.
# size cells and address cells required if trig-conns node present.
"#size-cells":
const: 0
"#address-cells":
const: 1
patternProperties:
'^trig-conns@([0-9]+)$':
type: object
description:
A trigger connections child node which describes the trigger signals
between this CTI and another hardware device. This device may be a CPU,
CoreSight device, any other hardware device or simple external IO lines.
The connection may have both input and output triggers, or only one or the
other.
properties:
reg:
maxItems: 1
arm,trig-in-sigs:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger in signal numbers in use by a trig-conns node.
arm,trig-in-types:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger in
signals. Types in this array match to the corresponding signal in the
arm,trig-in-sigs array. If the -types array is smaller, or omitted
completely, then the types will default to GEN_IO.
arm,trig-out-sigs:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signal numbers in use by a trig-conns node.
arm,trig-out-types:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger out
signals. Types in this array match to the corresponding signal
in the arm,trig-out-sigs array. If the "-types" array is smaller,
or omitted completely, then the types will default to GEN_IO.
arm,trig-filters:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signals that will be blocked from becoming
active, unless filtering is disabled on the driver.
arm,trig-conn-name:
allOf:
- $ref: /schemas/types.yaml#/definitions/string
description:
Defines a connection name that will be displayed, if the cpu or
arm,cs-dev-assoc properties are not being used in this connection.
Principle use for CTI that are connected to non-CoreSight devices, or
external IO.
anyOf:
- required:
- arm,trig-in-sigs
- required:
- arm,trig-out-sigs
oneOf:
- required:
- arm,trig-conn-name
- required:
- cpu
- required:
- arm,cs-dev-assoc
required:
- reg
required:
- compatible
- reg
- clocks
- clock-names
if:
properties:
compatible:
contains:
const: arm,coresight-cti-v8-arch
then:
required:
- cpu
examples:
# minimum CTI definition. DEVID register used to set number of triggers.
- |
cti@20020000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x20020000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
};
# v8 architecturally defined CTI - CPU + ETM connections generated by the
# driver according to the v8 architecture specification.
- |
cti@859000 {
compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
"arm,primecell";
reg = <0x859000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
cpu = <&CPU1>;
arm,cs-dev-assoc = <&etm1>;
};
# Implementation defined CTI - CPU + ETM connections explicitly defined..
# Shows use of type constants from dt-bindings/arm/coresight-cti-dt.h
# #size-cells and #address-cells are required if trig-conns@ nodes present.
- |
#include <dt-bindings/arm/coresight-cti-dt.h>
cti@858000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x858000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
arm,cti-ctm-id = <1>;
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs = <4 5 6 7>;
arm,trig-in-types = <ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT>;
arm,trig-out-sigs = <4 5 6 7>;
arm,trig-out-types = <ETM_EXTIN
ETM_EXTIN
ETM_EXTIN
ETM_EXTIN>;
arm,cs-dev-assoc = <&etm0>;
};
trig-conns@1 {
reg = <1>;
cpu = <&CPU0>;
arm,trig-in-sigs = <0 1>;
arm,trig-in-types = <PE_DBGTRIGGER
PE_PMUIRQ>;
arm,trig-out-sigs=<0 1 2 >;
arm,trig-out-types = <PE_EDBGREQ
PE_DBGRESTART
PE_CTIIRQ>;
arm,trig-filters = <0>;
};
};
# Implementation defined CTI - non CoreSight component connections.
- |
cti@20110000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0 0x20110000 0 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs=<0>;
arm,trig-in-types=<GEN_INTREQ>;
arm,trig-out-sigs=<0>;
arm,trig-out-types=<GEN_HALTREQ>;
arm,trig-conn-name = "sys_profiler";
};
trig-conns@1 {
reg = <1>;
arm,trig-out-sigs=<2 3>;
arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "watchdog";
};
trig-conns@2 {
reg = <2>;
arm,trig-in-sigs=<1 6>;
arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "g_counter";
};
};
...

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

@ -45,6 +45,10 @@ its hardware characteristcs.
- Coresight Address Translation Unit (CATU)
"arm,coresight-catu", "arm,primecell";
- Coresight Cross Trigger Interface (CTI):
"arm,coresight-cti", "arm,primecell";
See coresight-cti.yaml for full CTI definitions.
* reg: physical base address and length of the register
set(s) of the component.
@ -72,6 +76,9 @@ its hardware characteristcs.
* reg-names: the only acceptable values are "stm-base" and
"stm-stimulus-base", each corresponding to the areas defined in "reg".
* Required properties for Coresight Cross Trigger Interface (CTI)
See coresight-cti.yaml for full CTI definitions.
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators and non-configurable funnels:

46
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@ -123,11 +123,18 @@ properties:
- arm,cortex-a12
- arm,cortex-a15
- arm,cortex-a17
- arm,cortex-a32
- arm,cortex-a34
- arm,cortex-a35
- arm,cortex-a53
- arm,cortex-a55
- arm,cortex-a57
- arm,cortex-a65
- arm,cortex-a72
- arm,cortex-a73
- arm,cortex-a75
- arm,cortex-a76
- arm,cortex-a77
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
@ -136,6 +143,8 @@ properties:
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
- arm,neoverse-e1
- arm,neoverse-n1
- brcm,brahma-b15
- brcm,brahma-b53
- brcm,vulcan
@ -155,6 +164,8 @@ properties:
- nvidia,tegra194-carmel
- qcom,krait
- qcom,kryo
- qcom,kryo260
- qcom,kryo280
- qcom,kryo385
- qcom,kryo485
- qcom,scorpion
@ -201,6 +212,8 @@ properties:
- rockchip,rk3066-smp
- socionext,milbeaut-m10v-smp
- ste,dbx500-smp
- ti,am3352
- ti,am4372
cpu-release-addr:
$ref: '/schemas/types.yaml#/definitions/uint64'
@ -287,6 +300,39 @@ properties:
While optional, it is the preferred way to get access to
the cpu-core power-domains.
secondary-boot-reg:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: |
Required for systems that have an "enable-method" property value of
"brcm,bcm11351-cpu-method", "brcm,bcm23550" or "brcm,bcm-nsp-smp".
This includes the following SoCs: |
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664, BCM23550
BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
if:
# If the enable-method property contains one of those values
properties:
enable-method:
contains:
enum:
- brcm,bcm11351-cpu-method
- brcm,bcm23550
- brcm,bcm-nsp-smp
# and if enable-method is present
required:
- enable-method
then:
required:
- secondary-boot-reg
required:
- device_type
- reg

18
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
View File

@ -164,7 +164,18 @@ Required properties:
- compatible: should be:
"fsl,imx8qxp-sc-key"
followed by "fsl,imx-sc-key";
- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
- linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml
Thermal bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: Should be :
"fsl,imx8qxp-sc-thermal"
followed by "fsl,imx-sc-thermal";
- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal.txt
for a description.
Example (imx8qxp):
-------------
@ -238,6 +249,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
tsens: thermal-sensor {
compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal";
#thermal-sensor-cells = <1>;
};
};
};

69
Documentation/devicetree/bindings/arm/fsl.yaml
View File

@ -119,6 +119,10 @@ properties:
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
- technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf
- technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit
- technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph
- technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi
- technologic,imx6q-ts4900
- technologic,imx6q-ts7970
- toradex,apalis_imx6q # Apalis iMX6 Module
@ -166,6 +170,10 @@ properties:
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
- technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf
- technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit
- technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph
- technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi
- technologic,imx6dl-ts4900
- technologic,imx6dl-ts7970
- toradex,colibri_imx6dl # Colibri iMX6 Module
@ -225,6 +233,9 @@ properties:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
- kontron,imx6ul-n6311-som # Kontron N6311 SOM
- technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL Pico-Dwarf
- technexion,imx6ul-pico-hobbit # TechNexion i.MX6UL Pico-Hobbit
- technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi
- const: fsl,imx6ul
- description: Kontron N6310 S Board
@ -274,6 +285,7 @@ properties:
items:
- enum:
- toradex,colibri-imx7s # Colibri iMX7 Solo Module
- toradex,colibri-imx7s-aster # Colibri iMX7 Solo Module on Aster Carrier Board
- toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3
- tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM
- const: fsl,imx7s
@ -284,8 +296,14 @@ properties:
- fsl,imx7d-sdb # i.MX7 SabreSD Board
- fsl,imx7d-sdb-reva # i.MX7 SabreSD Rev-A Board
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
- technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf
- technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit
- technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph
- technexion,imx7d-pico-pi # TechNexion i.MX7D Pico-Pi
- toradex,colibri-imx7d # Colibri iMX7 Dual Module
- toradex,colibri-imx7d-aster # Colibri iMX7 Dual Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc # Colibri iMX7 Dual 1GB (eMMC) Module
- toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on Colibri Evaluation Board V3
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on Colibri Evaluation Board V3
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
@ -324,6 +342,12 @@ properties:
- fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board
- const: fsl,imx8mn
- description: i.MX8MP based Boards
items:
- enum:
- fsl,imx8mp-evk # i.MX8MP EVK Board
- const: fsl,imx8mp
- description: i.MX8MQ based Boards
items:
- enum:
@ -395,6 +419,51 @@ properties:
- fsl,ls1021a-twr
- const: fsl,ls1021a
- description: LS1028A based Boards
items:
- enum:
- fsl,ls1028a-qds
- fsl,ls1028a-rdb
- const: fsl,ls1028a
- description: Kontron KBox A-230-LS
items:
- const: kontron,kbox-a-230-ls
- const: kontron,sl28-var4
- const: kontron,sl28
- const: fsl,ls1028a
- description:
Kontron SMARC-sAL28 board on the SMARC Eval Carrier 2.0
items:
- enum:
- kontron,sl28-var2-ads2
- kontron,sl28-var3-ads2
- kontron,sl28-var4-ads2
- enum:
- kontron,sl28-var2
- kontron,sl28-var3
- kontron,sl28-var4
- const: kontron,sl28
- const: fsl,ls1028a
- description:
Kontron SMARC-sAL28 board (on a generic/undefined carrier)
items:
- enum:
- kontron,sl28-var2
- kontron,sl28-var3
- kontron,sl28-var4
- const: kontron,sl28
- const: fsl,ls1028a
- description:
Kontron SMARC-sAL28 board (base). This is used in the base device
tree which is compatible with the overlays provided by the
vendor.
items:
- const: kontron,sl28
- const: fsl,ls1028a
- description: LS1043A based Boards
items:
- enum:

45
Documentation/devicetree/bindings/arm/l2c2x0.yaml
View File

@ -29,27 +29,30 @@ allOf:
properties:
compatible:
enum:
- arm,pl310-cache
- arm,l220-cache
- arm,l210-cache
# DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
- bcm,bcm11351-a2-pl310-cache
# For Broadcom bcm11351 chipset where an
# offset needs to be added to the address before passing down to the L2
# cache controller
- brcm,bcm11351-a2-pl310-cache
# Marvell Controller designed to be
# compatible with the ARM one, with system cache mode (meaning
# maintenance operations on L1 are broadcasted to the L2 and L2
# performs the same operation).
- marvell,aurora-system-cache
# Marvell Controller designed to be
# compatible with the ARM one with outer cache mode.
- marvell,aurora-outer-cache
# Marvell Tauros3 cache controller, compatible
# with arm,pl310-cache controller.
- marvell,tauros3-cache
oneOf:
- enum:
- arm,pl310-cache
- arm,l220-cache
- arm,l210-cache
# DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
- bcm,bcm11351-a2-pl310-cache
# For Broadcom bcm11351 chipset where an
# offset needs to be added to the address before passing down to the L2
# cache controller
- brcm,bcm11351-a2-pl310-cache
# Marvell Controller designed to be
# compatible with the ARM one, with system cache mode (meaning
# maintenance operations on L1 are broadcasted to the L2 and L2
# performs the same operation).
- marvell,aurora-system-cache
# Marvell Controller designed to be
# compatible with the ARM one with outer cache mode.
- marvell,aurora-outer-cache
- items:
# Marvell Tauros3 cache controller, compatible
# with arm,pl310-cache controller.
- const: marvell,tauros3-cache
- const: arm,pl310-cache
cache-level:
const: 2

5
Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
View File

@ -28,8 +28,11 @@ properties:
items:
- enum:
- mrvl,mmp2-brownstone
- olpc,xo-1.75
- const: mrvl,mmp2
- description: MMP3 based boards
items:
- const: mrvl,mmp3
- enum:
- dell,wyse-ariel
- const: marvell,mmp3
...

2
Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
View File

@ -43,6 +43,8 @@ required:
- reg-names
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>

41
Documentation/devicetree/bindings/arm/pmu.yaml
View File

@ -20,27 +20,36 @@ properties:
items:
- enum:
- apm,potenza-pmu
- arm,armv8-pmuv3
- arm,cortex-a73-pmu
- arm,cortex-a72-pmu
- arm,cortex-a57-pmu
- arm,cortex-a53-pmu
- arm,cortex-a35-pmu
- arm,cortex-a17-pmu
- arm,cortex-a15-pmu
- arm,cortex-a12-pmu
- arm,cortex-a9-pmu
- arm,cortex-a8-pmu
- arm,cortex-a7-pmu
- arm,cortex-a5-pmu
- arm,arm11mpcore-pmu
- arm,arm1176-pmu
- arm,armv8-pmuv3 # Only for s/w models
- arm,arm1136-pmu
- arm,arm1176-pmu
- arm,arm11mpcore-pmu
- arm,cortex-a5-pmu
- arm,cortex-a7-pmu
- arm,cortex-a8-pmu
- arm,cortex-a9-pmu
- arm,cortex-a12-pmu
- arm,cortex-a15-pmu
- arm,cortex-a17-pmu
- arm,cortex-a32-pmu
- arm,cortex-a34-pmu
- arm,cortex-a35-pmu
- arm,cortex-a53-pmu
- arm,cortex-a55-pmu
- arm,cortex-a57-pmu
- arm,cortex-a65-pmu
- arm,cortex-a72-pmu
- arm,cortex-a73-pmu
- arm,cortex-a75-pmu
- arm,cortex-a76-pmu
- arm,cortex-a77-pmu
- arm,neoverse-e1-pmu
- arm,neoverse-n1-pmu
- brcm,vulcan-pmu
- cavium,thunder-pmu
- qcom,krait-pmu
- qcom,scorpion-pmu
- qcom,scorpion-mp-pmu
- qcom,krait-pmu
interrupts:
# Don't know how many CPUs, so no constraints to specify

5
Documentation/devicetree/bindings/arm/psci.yaml
View File

@ -32,6 +32,9 @@ description: |+
http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
properties:
$nodename:
const: psci
compatible:
oneOf:
- description:
@ -141,6 +144,8 @@ allOf:
- cpu_off
- cpu_on
additionalProperties: false
examples:
- |+

8
Documentation/devicetree/bindings/arm/qcom.yaml
View File

@ -28,6 +28,7 @@ description: |
apq8074
apq8084
apq8096
ipq6018
ipq8074
mdm9615
msm8916
@ -41,6 +42,7 @@ description: |
The 'board' element must be one of the following strings:
cdp
cp01-c1
dragonboard
hk01
idp
@ -150,4 +152,10 @@ properties:
- enum:
- qcom,sc7180-idp
- const: qcom,sc7180
- items:
- enum:
- qcom,ipq6018-cp01-c1
- const: qcom,ipq6018
...

2
Documentation/devicetree/bindings/arm/renesas,prr.yaml
View File

@ -27,6 +27,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
prr: chipid@ff000044 {

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

@ -208,6 +208,7 @@ properties:
- description: R-Car M3-W+ (R8A77961)
items:
- enum:
- renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP8J77961ASKB0SK0SA05A (M3 ES3.0))
- renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012SA5A)
- const: renesas,r8a77961

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

@ -402,6 +402,11 @@ properties:
- const: phytec,rk3288-phycore-som
- const: rockchip,rk3288
- description: Pine64 PinebookPro
items:
- const: pine64,pinebook-pro
- const: rockchip,rk3399
- description: Pine64 Rock64
items:
- const: pine64,rock64
@ -443,7 +448,7 @@ properties:
- description: Rockchip Kylin
items:
- const: rockchip,kylin-rk3036
- const: rockchip,rk3036-kylin
- const: rockchip,rk3036
- description: Rockchip PX3 Evaluation board
@ -468,6 +473,11 @@ properties:
- const: rockchip,r88
- const: rockchip,rk3368
- description: Rockchip RK3036 Evaluation board
items:
- const: rockchip,rk3036-evb
- const: rockchip,rk3036
- description: Rockchip RK3228 Evaluation board
items:
- const: rockchip,rk3228-evb

2
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml
View File

@ -30,6 +30,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
chipid@10000000 {

2
Documentation/devicetree/bindings/arm/samsung/pmu.yaml
View File

@ -89,6 +89,8 @@ required:
- clock-names
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos5250.h>

2
Documentation/devicetree/bindings/arm/samsung/samsung-secure-firmware.yaml
View File

@ -23,6 +23,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
firmware@203f000 {

60
Documentation/devicetree/bindings/arm/socionext/cache-uniphier.txt
View File

@ -1,60 +0,0 @@
UniPhier outer cache controller
UniPhier SoCs are integrated with a full-custom outer cache controller system.
All of them have a level 2 cache controller, and some have a level 3 cache
controller as well.
Required properties:
- compatible: should be "socionext,uniphier-system-cache"
- reg: offsets and lengths of the register sets for the device. It should
contain 3 regions: control register, revision register, operation register,
in this order.
- cache-unified: specifies the cache is a unified cache.
- cache-size: specifies the size in bytes of the cache
- cache-sets: specifies the number of associativity sets of the cache
- cache-line-size: specifies the line size in bytes
- cache-level: specifies the level in the cache hierarchy. The value should
be 2 for L2 cache, 3 for L3 cache, etc.
Optional properties:
- next-level-cache: phandle to the next level cache if present. The next level
cache should be also compatible with "socionext,uniphier-system-cache".
The L2 cache must exist to use the L3 cache; the cache hierarchy must be
indicated correctly with "next-level-cache" properties.
Example 1 (system with L2):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x4>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x80000>;
cache-sets = <256>;
cache-line-size = <128>;
cache-level = <2>;
};
Example 2 (system with L2 and L3):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x8>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
next-level-cache = <&l3>;
};
l3: l3-cache@500c8000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
<0x506c8000 0x400>;
cache-unified;
cache-size = <0x400000>;
cache-sets = <512>;
cache-line-size = <256>;
cache-level = <3>;
};

102
Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml Normal file
View File

@ -0,0 +1,102 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/socionext/socionext,uniphier-system-cache.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UniPhier outer cache controller
description: |
UniPhier ARM 32-bit SoCs are integrated with a full-custom outer cache
controller system. All of them have a level 2 cache controller, and some
have a level 3 cache controller as well.
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
compatible:
const: socionext,uniphier-system-cache
reg:
description: |
should contain 3 regions: control register, revision register,
operation register, in this order.
minItems: 3
maxItems: 3
interrupts:
description: |
Interrupts can be used to notify the completion of cache operations.
The number of interrupts should match to the number of CPU cores.
The specified interrupts correspond to CPU0, CPU1, ... in this order.
minItems: 1
maxItems: 4
cache-unified: true
cache-size: true
cache-sets: true
cache-line-size: true
cache-level:
minimum: 2
maximum: 3
next-level-cache: true
allOf:
- $ref: /schemas/cache-controller.yaml#
additionalProperties: false
required:
- compatible
- reg
- interrupts
- cache-unified
- cache-size
- cache-sets
- cache-line-size
- cache-level
examples:
- |
// System with L2.
cache-controller@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x4>, <0x506c0000 0x400>;
interrupts = <0 174 4>, <0 175 4>, <0 190 4>, <0 191 4>;
cache-unified;
cache-size = <0x140000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
};
- |
// System with L2 and L3.
// L2 should specify the next level cache by 'next-level-cache'.
l2: cache-controller@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x8>, <0x506c0000 0x400>;
interrupts = <0 190 4>, <0 191 4>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
next-level-cache = <&l3>;
};
l3: cache-controller@500c8000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, <0x506c8000 0x400>;
interrupts = <0 174 4>, <0 175 4>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <256>;
cache-level = <3>;
};

47
Documentation/devicetree/bindings/arm/socionext/uniphier.txt
View File

@ -1,47 +0,0 @@
Socionext UniPhier SoC family
-----------------------------
Required properties in the root node:
- compatible: should contain board and SoC compatible strings
SoC and board compatible strings:
(sorted chronologically)
- LD4 SoC: "socionext,uniphier-ld4"
- Reference Board: "socionext,uniphier-ld4-ref"
- Pro4 SoC: "socionext,uniphier-pro4"
- Reference Board: "socionext,uniphier-pro4-ref"
- Ace Board: "socionext,uniphier-pro4-ace"
- Sanji Board: "socionext,uniphier-pro4-sanji"
- sLD8 SoC: "socionext,uniphier-sld8"
- Reference Board: "socionext,uniphier-sld8-ref"
- PXs2 SoC: "socionext,uniphier-pxs2"
- Gentil Board: "socionext,uniphier-pxs2-gentil"
- Vodka Board: "socionext,uniphier-pxs2-vodka"
- LD6b SoC: "socionext,uniphier-ld6b"
- Reference Board: "socionext,uniphier-ld6b-ref"
- LD11 SoC: "socionext,uniphier-ld11"
- Reference Board: "socionext,uniphier-ld11-ref"
- Global Board: "socionext,uniphier-ld11-global"
- LD20 SoC: "socionext,uniphier-ld20"
- Reference Board: "socionext,uniphier-ld20-ref"
- Global Board: "socionext,uniphier-ld20-global"
- PXs3 SoC: "socionext,uniphier-pxs3"
- Reference Board: "socionext,uniphier-pxs3-ref"
Example:
/dts-v1/;
/ {
compatible = "socionext,uniphier-ld20-ref", "socionext,uniphier-ld20";
...
};

61
Documentation/devicetree/bindings/arm/socionext/uniphier.yaml Normal file
View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/socionext/uniphier.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Socionext UniPhier platform device tree bindings
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
$nodename:
const: /
compatible:
oneOf:
- description: LD4 SoC boards
items:
- enum:
- socionext,uniphier-ld4-ref
- const: socionext,uniphier-ld4
- description: Pro4 SoC boards
items:
- enum:
- socionext,uniphier-pro4-ace
- socionext,uniphier-pro4-ref
- socionext,uniphier-pro4-sanji
- const: socionext,uniphier-pro4
- description: sLD8 SoC boards
items:
- enum:
- socionext,uniphier-sld8-ref
- const: socionext,uniphier-sld8
- description: PXs2 SoC boards
items:
- enum:
- socionext,uniphier-pxs2-gentil
- socionext,uniphier-pxs2-vodka
- const: socionext,uniphier-pxs2
- description: LD6b SoC boards
items:
- enum:
- socionext,uniphier-ld6b-ref
- const: socionext,uniphier-ld6b
- description: LD11 SoC boards
items:
- enum:
- socionext,uniphier-ld11-global
- socionext,uniphier-ld11-ref
- const: socionext,uniphier-ld11
- description: LD20 SoC boards
items:
- enum:
- socionext,uniphier-ld20-global
- socionext,uniphier-ld20-ref
- const: socionext,uniphier-ld20
- description: PXs3 SoC boards
items:
- enum:
- socionext,uniphier-pxs3-ref
- const: socionext,uniphier-pxs3

2
Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
View File

@ -29,6 +29,8 @@ required:
- reg
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>

26
Documentation/devicetree/bindings/arm/sunxi.yaml
View File

@ -394,6 +394,12 @@ properties:
- const: linksprite,pcduino3-nano
- const: allwinner,sun7i-a20
- description: Linutronix Testbox v2
items:
- const: linutronix,testbox-v2
- const: lamobo,lamobo-r1
- const: allwinner,sun7i-a20
- description: HAOYU Electronics Marsboard A10
items:
- const: haoyu,a10-marsboard
@ -636,6 +642,21 @@ properties:
- const: pine64,pinebook
- const: allwinner,sun50i-a64
- description: Pine64 PinePhone Developer Batch (1.0)
items:
- const: pine64,pinephone-1.0
- const: allwinner,sun50i-a64
- description: Pine64 PinePhone Braveheart (1.1)
items:
- const: pine64,pinephone-1.1
- const: allwinner,sun50i-a64
- description: Pine64 PineTab
items:
- const: pine64,pinetab
- const: allwinner,sun50i-a64
- description: Pine64 SoPine Baseboard
items:
- const: pine64,sopine-baseboard
@ -647,6 +668,11 @@ properties:
- const: pineriver,mini-xplus
- const: allwinner,sun4i-a10
- description: PocketBook Touch Lux 3
items:
- const: pocketbook,touch-lux-3
- const: allwinner,sun5i-a13
- description: Point of View Protab2-IPS9
items:
- const: pov,protab2-ips9

7
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml
View File

@ -30,6 +30,7 @@ properties:
enum:
- allwinner,sun5i-a13-mbus
- allwinner,sun8i-h3-mbus
- allwinner,sun50i-a64-mbus
reg:
maxItems: 1
@ -41,6 +42,10 @@ properties:
description:
See section 2.3.9 of the DeviceTree Specification.
'#address-cells': true
'#size-cells': true
required:
- "#interconnect-cells"
- compatible
@ -58,6 +63,8 @@ examples:
compatible = "allwinner,sun5i-a13-mbus";
reg = <0x01c01000 0x1000>;
clocks = <&ccu CLK_MBUS>;
#address-cells = <1>;
#size-cells = <1>;
dma-ranges = <0x00000000 0x40000000 0x20000000>;
#interconnect-cells = <1>;
};

300
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
View File

@ -1,300 +0,0 @@
NVIDIA Tegra Power Management Controller (PMC)
== Power Management Controller Node ==
The PMC block interacts with an external Power Management Unit. The PMC
mostly controls the entry and exit of the system from different sleep
modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : Should contain one of the following:
For Tegra20 must contain "nvidia,tegra20-pmc".
For Tegra30 must contain "nvidia,tegra30-pmc".
For Tegra114 must contain "nvidia,tegra114-pmc"
For Tegra124 must contain "nvidia,tegra124-pmc"
For Tegra132 must contain "nvidia,tegra124-pmc"
For Tegra210 must contain "nvidia,tegra210-pmc"
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entries:
"pclk" (The Tegra clock of that name),
"clk32k_in" (The 32KHz clock input to Tegra).
Optional properties:
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
- nvidia,suspend-mode : The suspend mode that the platform should use.
Valid values are 0, 1 and 2:
0 (LP0): CPU + Core voltage off and DRAM in self-refresh
1 (LP1): CPU voltage off and DRAM in self-refresh
2 (LP2): CPU voltage off
- nvidia,core-power-req-active-high : Boolean, core power request active-high
- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
is enabled.
Required properties when nvidia,suspend-mode is specified:
- nvidia,cpu-pwr-good-time : CPU power good time in uS.
- nvidia,cpu-pwr-off-time : CPU power off time in uS.
- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
Core power good time in uS.
- nvidia,core-pwr-off-time : Core power off time in uS.
Required properties when nvidia,suspend-mode=<0>:
- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
The LP0 vector contains the warm boot code that is executed by AVP when
resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
processor and always being the first boot processor when chip is power on
or resume from deep sleep mode. When the system is resumed from the deep
sleep mode, the warm boot code will restore some PLLs, clocks and then
bring up CPU0 for resuming the system.
Hardware-triggered thermal reset:
On Tegra30, Tegra114 and Tegra124, if the 'i2c-thermtrip' subnode exists,
hardware-triggered thermal reset will be enabled.
Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,i2c-controller-id : ID of I2C controller to send poweroff command to. Valid values are
described in section 9.2.148 "APBDEV_PMC_SCRATCH53_0" of the
Tegra K1 Technical Reference Manual.
- nvidia,bus-addr : Bus address of the PMU on the I2C bus
- nvidia,reg-addr : I2C register address to write poweroff command to
- nvidia,reg-data : Poweroff command to write to PMU
Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command.
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
Optional nodes:
- powergates : This node contains a hierarchy of power domain nodes, which
should match the powergates on the Tegra SoC. See "Powergate
Nodes" below.
Example:
/ SoC dts including file
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
clocks = <&tegra_car 110>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
nvidia,invert-interrupt;
nvidia,suspend-mode = <1>;
nvidia,cpu-pwr-good-time = <2000>;
nvidia,cpu-pwr-off-time = <100>;
nvidia,core-pwr-good-time = <3845 3845>;
nvidia,core-pwr-off-time = <458>;
nvidia,core-power-req-active-high;
nvidia,sys-clock-req-active-high;
nvidia,lp0-vec = <0xbdffd000 0x2000>;
};
/ Tegra board dts file
{
...
pmc@7000f400 {
i2c-thermtrip {
nvidia,i2c-controller-id = <4>;
nvidia,bus-addr = <0x40>;
nvidia,reg-addr = <0x36>;
nvidia,reg-data = <0x2>;
};
};
...
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
clk32k_in: clock {
compatible = "fixed-clock";
reg=<0>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
...
};
== Powergate Nodes ==
Each of the powergate nodes represents a power-domain on the Tegra SoC
that can be power-gated by the Tegra PMC. The name of the powergate node
should be one of the below. Note that not every powergate is applicable
to all Tegra devices and the following list shows which powergates are
applicable to which devices. Please refer to the Tegra TRM for more
details on the various powergates.
Name Description Devices Applicable
3d 3D Graphics Tegra20/114/124/210
3d0 3D Graphics 0 Tegra30
3d1 3D Graphics 1 Tegra30
aud Audio Tegra210
dfd Debug Tegra210
dis Display A Tegra114/124/210
disb Display B Tegra114/124/210
heg 2D Graphics Tegra30/114/124/210
iram Internal RAM Tegra124/210
mpe MPEG Encode All
nvdec NVIDIA Video Decode Engine Tegra210
nvjpg NVIDIA JPEG Engine Tegra210
pcie PCIE Tegra20/30/124/210
sata SATA Tegra30/124/210
sor Display interfaces Tegra124/210
ve2 Video Encode Engine 2 Tegra210
venc Video Encode Engine All
vdec Video Decode Engine Tegra20/30/114/124
vic Video Imaging Compositor Tegra124/210
xusba USB Partition A Tegra114/124/210
xusbb USB Partition B Tegra114/124/210
xusbc USB Partition C Tegra114/124/210
Required properties:
- clocks: Must contain an entry for each clock required by the PMC for
controlling a power-gate. See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each reset required by the PMC for
controlling a power-gate. See ../reset/reset.txt for details.
- #power-domain-cells: Must be 0.
Example:
pmc: pmc@7000e400 {
compatible = "nvidia,tegra210-pmc";
reg = <0x0 0x7000e400 0x0 0x400>;
clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
powergates {
pd_audio: aud {
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
resets = <&tegra_car 198>;
#power-domain-cells = <0>;
};
};
};
== Powergate Clients ==
Hardware blocks belonging to a power domain should contain a "power-domains"
property that is a phandle pointing to the corresponding powergate node.
Example:
adma: adma@702e2000 {
...
power-domains = <&pd_audio>;
...
};
== Pad Control ==
On Tegra SoCs a pad is a set of pins which are configured as a group.
The pin grouping is a fixed attribute of the hardware. The PMC can be
used to set pad power state and signaling voltage. A pad can be either
in active or power down mode. The support for power state and signaling
voltage configuration varies depending on the pad in question. 3.3 V and
1.8 V signaling voltages are supported on pins where software
controllable signaling voltage switching is available.
The pad configuration state nodes are placed under the pmc node and they
are referred to by the pinctrl client properties. For more information
see Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt.
The pad name should be used as the value of the pins property in pin
configuration nodes.
The following pads are present on Tegra124 and Tegra132:
audio bb cam comp
csia csb cse dsi
dsib dsic dsid hdmi
hsic hv lvds mipi-bias
nand pex-bias pex-clk1 pex-clk2
pex-cntrl sdmmc1 sdmmc3 sdmmc4
sys_ddc uart usb0 usb1
usb2 usb_bias
The following pads are present on Tegra210:
audio audio-hv cam csia
csib csic csid csie
csif dbg debug-nonao dmic
dp dsi dsib dsic
dsid emmc emmc2 gpio
hdmi hsic lvds mipi-bias
pex-bias pex-clk1 pex-clk2 pex-cntrl
sdmmc1 sdmmc3 spi spi-hv
uart usb0 usb1 usb2
usb3 usb-bias
Required pin configuration properties:
- pins: Must contain name of the pad(s) to be configured.
Optional pin configuration properties:
- low-power-enable: Configure the pad into power down mode
- low-power-disable: Configure the pad into active mode
- power-source: Must contain either TEGRA_IO_PAD_VOLTAGE_1V8
or TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages.
The values are defined in
include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h.
Note: The power state can be configured on all of the Tegra124 and
Tegra132 pads. None of the Tegra124 or Tegra132 pads support
signaling voltage switching.
Note: All of the listed Tegra210 pads except pex-cntrl support power
state configuration. Signaling voltage switching is supported on
following Tegra210 pads: audio, audio-hv, cam, dbg, dmic, gpio,
pex-cntrl, sdmmc1, sdmmc3, spi, spi-hv, and uart.
Pad configuration state example:
pmc: pmc@7000e400 {
compatible = "nvidia,tegra210-pmc";
reg = <0x0 0x7000e400 0x0 0x400>;
clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
...
sdmmc1_3v3: sdmmc1-3v3 {
pins = "sdmmc1";
power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>;
};
sdmmc1_1v8: sdmmc1-1v8 {
pins = "sdmmc1";
power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>;
};
hdmi_off: hdmi-off {
pins = "hdmi";
low-power-enable;
}
hdmi_on: hdmi-on {
pins = "hdmi";
low-power-disable;
}
};
Pinctrl client example:
sdmmc1: sdhci@700b0000 {
...
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
pinctrl-0 = <&sdmmc1_3v3>;
pinctrl-1 = <&sdmmc1_1v8>;
};
...
sor@54540000 {
...
pinctrl-0 = <&hdmi_off>;
pinctrl-1 = <&hdmi_on>;
pinctrl-names = "hdmi-on", "hdmi-off";
};

354
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml Normal file
View File

@ -0,0 +1,354 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra20-pmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Tegra Power Management Controller (PMC)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jonathan Hunter <jonathanh@nvidia.com>
properties:
compatible:
enum:
- nvidia,tegra20-pmc
- nvidia,tegra20-pmc
- nvidia,tegra30-pmc
- nvidia,tegra114-pmc
- nvidia,tegra124-pmc
- nvidia,tegra210-pmc
reg:
maxItems: 1
description:
Offset and length of the register set for the device.
clock-names:
items:
- const: pclk
- const: clk32k_in
description:
Must includes entries pclk and clk32k_in.
pclk is the Tegra clock of that name and clk32k_in is 32KHz clock
input to Tegra.
clocks:
maxItems: 2
description:
Must contain an entry for each entry in clock-names.
See ../clocks/clocks-bindings.txt for details.
'#clock-cells':
const: 1
description:
Tegra PMC has clk_out_1, clk_out_2, and clk_out_3.
PMC also has blink control which allows 32Khz clock output to
Tegra blink pad.
Consumer of PMC clock should specify the desired clock by having
the clock ID in its "clocks" phandle cell with pmc clock provider.
See include/dt-bindings/soc/tegra-pmc.h for the list of Tegra PMC
clock IDs.
'#interrupt-cells':
const: 2
description:
Specifies number of cells needed to encode an interrupt source.
The value must be 2.
interrupt-controller: true
nvidia,invert-interrupt:
$ref: /schemas/types.yaml#/definitions/flag
description: Inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and
then fed into the ARM GIC. The PMC is not involved in the detection
or handling of this interrupt signal, merely its inversion.
nvidia,core-power-req-active-high:
$ref: /schemas/types.yaml#/definitions/flag
description: Core power request active-high.
nvidia,sys-clock-req-active-high:
$ref: /schemas/types.yaml#/definitions/flag
description: System clock request active-high.
nvidia,combined-power-req:
$ref: /schemas/types.yaml#/definitions/flag
description: combined power request for CPU and Core.
nvidia,cpu-pwr-good-en:
$ref: /schemas/types.yaml#/definitions/flag
description:
CPU power good signal from external PMIC to PMC is enabled.
nvidia,suspend-mode:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2]
description:
The suspend mode that the platform should use.
Mode 0 is for LP0, CPU + Core voltage off and DRAM in self-refresh
Mode 1 is for LP1, CPU voltage off and DRAM in self-refresh
Mode 2 is for LP2, CPU voltage off
nvidia,cpu-pwr-good-time:
$ref: /schemas/types.yaml#/definitions/uint32
description: CPU power good time in uSec.
nvidia,cpu-pwr-off-time:
$ref: /schemas/types.yaml#/definitions/uint32
description: CPU power off time in uSec.
nvidia,core-pwr-good-time:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
<Oscillator-stable-time Power-stable-time>
Core power good time in uSec.
nvidia,core-pwr-off-time:
$ref: /schemas/types.yaml#/definitions/uint32
description: Core power off time in uSec.
nvidia,lp0-vec:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
<start length> Starting address and length of LP0 vector.
The LP0 vector contains the warm boot code that is executed
by AVP when resuming from the LP0 state.
The AVP (Audio-Video Processor) is an ARM7 processor and
always being the first boot processor when chip is power on
or resume from deep sleep mode. When the system is resumed
from the deep sleep mode, the warm boot code will restore
some PLLs, clocks and then brings up CPU0 for resuming the
system.
i2c-thermtrip:
type: object
description:
On Tegra30, Tegra114 and Tegra124 if i2c-thermtrip subnode exists,
hardware-triggered thermal reset will be enabled.
properties:
nvidia,i2c-controller-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
ID of I2C controller to send poweroff command to PMU.
Valid values are described in section 9.2.148
"APBDEV_PMC_SCRATCH53_0" of the Tegra K1 Technical Reference
Manual.
nvidia,bus-addr:
$ref: /schemas/types.yaml#/definitions/uint32
description: Bus address of the PMU on the I2C bus.
nvidia,reg-addr:
$ref: /schemas/types.yaml#/definitions/uint32
description: PMU I2C register address to issue poweroff command.
nvidia,reg-data:
$ref: /schemas/types.yaml#/definitions/uint32
description: Poweroff command to write to PMU.
nvidia,pinmux-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Pinmux used by the hardware when issuing Poweroff command.
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
required:
- nvidia,i2c-controller-id
- nvidia,bus-addr
- nvidia,reg-addr
- nvidia,reg-data
additionalProperties: false
powergates:
type: object
description: |
This node contains a hierarchy of power domain nodes, which should
match the powergates on the Tegra SoC. Each powergate node
represents a power-domain on the Tegra SoC that can be power-gated
by the Tegra PMC.
Hardware blocks belonging to a power domain should contain
"power-domains" property that is a phandle pointing to corresponding
powergate node.
The name of the powergate node should be one of the below. Note that
not every powergate is applicable to all Tegra devices and the following
list shows which powergates are applicable to which devices.
Please refer to Tegra TRM for mode details on the powergate nodes to
use for each power-gate block inside Tegra.
Name Description Devices Applicable
3d 3D Graphics Tegra20/114/124/210
3d0 3D Graphics 0 Tegra30
3d1 3D Graphics 1 Tegra30
aud Audio Tegra210
dfd Debug Tegra210
dis Display A Tegra114/124/210
disb Display B Tegra114/124/210
heg 2D Graphics Tegra30/114/124/210
iram Internal RAM Tegra124/210
mpe MPEG Encode All
nvdec NVIDIA Video Decode Engine Tegra210
nvjpg NVIDIA JPEG Engine Tegra210
pcie PCIE Tegra20/30/124/210
sata SATA Tegra30/124/210
sor Display interfaces Tegra124/210
ve2 Video Encode Engine 2 Tegra210
venc Video Encode Engine All
vdec Video Decode Engine Tegra20/30/114/124
vic Video Imaging Compositor Tegra124/210
xusba USB Partition A Tegra114/124/210
xusbb USB Partition B Tegra114/124/210
xusbc USB Partition C Tegra114/124/210
patternProperties:
"^[a-z0-9]+$":
type: object
patternProperties:
clocks:
minItems: 1
maxItems: 8
description:
Must contain an entry for each clock required by the PMC
for controlling a power-gate.
See ../clocks/clock-bindings.txt document for more details.
resets:
minItems: 1
maxItems: 8
description:
Must contain an entry for each reset required by the PMC
for controlling a power-gate.
See ../reset/reset.txt for more details.
'#power-domain-cells':
const: 0
description: Must be 0.
required:
- clocks
- resets
- '#power-domain-cells'
additionalProperties: false
patternProperties:
"^[a-f0-9]+-[a-f0-9]+$":
type: object
description:
This is a Pad configuration node. On Tegra SOCs a pad is a set of
pins which are configured as a group. The pin grouping is a fixed
attribute of the hardware. The PMC can be used to set pad power state
and signaling voltage. A pad can be either in active or power down mode.
The support for power state and signaling voltage configuration varies
depending on the pad in question. 3.3V and 1.8V signaling voltages
are supported on pins where software controllable signaling voltage
switching is available.
The pad configuration state nodes are placed under the pmc node and they
are referred to by the pinctrl client properties. For more information
see Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt.
The pad name should be used as the value of the pins property in pin
configuration nodes.
The following pads are present on Tegra124 and Tegra132
audio, bb, cam, comp, csia, csb, cse, dsi, dsib, dsic, dsid, hdmi, hsic,
hv, lvds, mipi-bias, nand, pex-bias, pex-clk1, pex-clk2, pex-cntrl,
sdmmc1, sdmmc3, sdmmc4, sys_ddc, uart, usb0, usb1, usb2, usb_bias.
The following pads are present on Tegra210
audio, audio-hv, cam, csia, csib, csic, csid, csie, csif, dbg,
debug-nonao, dmic, dp, dsi, dsib, dsic, dsid, emmc, emmc2, gpio, hdmi,
hsic, lvds, mipi-bias, pex-bias, pex-clk1, pex-clk2, pex-cntrl, sdmmc1,
sdmmc3, spi, spi-hv, uart, usb0, usb1, usb2, usb3, usb-bias.
properties:
pins:
$ref: /schemas/types.yaml#/definitions/string
description: Must contain name of the pad(s) to be configured.
low-power-enable:
$ref: /schemas/types.yaml#/definitions/flag
description: Configure the pad into power down mode.
low-power-disable:
$ref: /schemas/types.yaml#/definitions/flag
description: Configure the pad into active mode.
power-source:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or
TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages.
The values are defined in
include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h.
Power state can be configured on all Tegra124 and Tegra132
pads. None of the Tegra124 or Tegra132 pads support signaling
voltage switching.
All of the listed Tegra210 pads except pex-cntrl support power
state configuration. Signaling voltage switching is supported
on below Tegra210 pads.
audio, audio-hv, cam, dbg, dmic, gpio, pex-cntrl, sdmmc1,
sdmmc3, spi, spi-hv, and uart.
required:
- pins
additionalProperties: false
required:
- compatible
- reg
- clock-names
- clocks
- '#clock-cells'
dependencies:
"nvidia,suspend-mode": ["nvidia,core-pwr-off-time", "nvidia,cpu-pwr-off-time"]
"nvidia,core-pwr-off-time": ["nvidia,core-pwr-good-time"]
"nvidia,cpu-pwr-off-time": ["nvidia,cpu-pwr-good-time"]
examples:
- |
#include <dt-bindings/clock/tegra210-car.h>
#include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h>
#include <dt-bindings/soc/tegra-pmc.h>
tegra_pmc: pmc@7000e400 {
compatible = "nvidia,tegra210-pmc";
reg = <0x0 0x7000e400 0x0 0x400>;
clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
#clock-cells = <1>;
nvidia,invert-interrupt;
nvidia,suspend-mode = <0>;
nvidia,cpu-pwr-good-time = <0>;
nvidia,cpu-pwr-off-time = <0>;
nvidia,core-pwr-good-time = <4587 3876>;
nvidia,core-pwr-off-time = <39065>;
nvidia,core-power-req-active-high;
nvidia,sys-clock-req-active-high;
powergates {
pd_audio: aud {
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
resets = <&tegra_car 198>;
#power-domain-cells = <0>;
};
pd_xusbss: xusba {
clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>;
resets = <&tegra_car TEGRA210_CLK_XUSB_SS>;
#power-domain-cells = <0>;
};
};
};

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