brain-hackers_pepepper-mirror/linux-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/linux-brain.git synced 2024-06-09 23:36:23 +09:00
Code Issues Projects Releases Wiki Activity

Linux 4.16-rc2

Browse Source 
-----BEGIN PGP SIGNATURE-----
 
 iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAlqKKI0eHHRvcnZhbGRz
 QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGRNAH/0v3+nuJ0oiHE1Cl
 fH89F9Ma17j8oTo28byRPi7X5XJfJAqANhHa209rguvnC27y3ew/l9k93HoxG12i
 ttvyKFDQulQbytfJZXw8lhUyYGXVsTpyNaihPe/NtqPdIxNgfrXsUN9EIEtcnuS2
 SiAj51jUySDRNR4ST6TOx4ulDm1zLrmA28WHOBNOTvDi4jTQMt1TsngHfF5AySBB
 lD4RTRDDwWDWtdMI7euYSq019TiDXCxmwQ94vZjrqmjmSQcl/yCK/JzEV33SZslg
 4WqGIllxONvP/UlwxZLaJ+RrslqxNgDVqQKwJdfYhGaWvpgPFtS1s86zW6IgyXny
 02jJfD0=
 =DLWn
 -----END PGP SIGNATURE-----

Merge tag 'v4.16-rc2' into locking/core, to refresh the branch

Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2018-02-21 09:57:55 +01:00
commit 862e6e2a60
10261 changed files with 423371 additions and 269172 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.gitignore vendored
View File

@ -65,6 +65,11 @@ modules.builtin
#
/debian/
#
# Snap directory (make snap-pkg)
#
/snap/
#
# tar directory (make tar*-pkg)
#

4
Documentation/00-INDEX
View File

@ -228,8 +228,6 @@ isdn/
- directory with info on the Linux ISDN support, and supported cards.
kbuild/
- directory with info about the kernel build process.
kernel-doc-nano-HOWTO.txt
- outdated info about kernel-doc documentation.
kdump/
- directory with mini HowTo on getting the crash dump code to work.
doc-guide/
@ -346,8 +344,6 @@ prctl/
- directory with info on the priveledge control subsystem
preempt-locking.txt
- info on locking under a preemptive kernel.
printk-formats.txt
- how to get printk format specifiers right
process/
- how to work with the mainline kernel development process.
pps/

53
Documentation/ABI/stable/sysfs-bus-vmbus
View File

@ -42,72 +42,93 @@ Contact: K. Y. Srinivasan <kys@microsoft.com>
Description: The 16 bit vendor ID of the device
Users: tools/hv/lsvmbus and user level RDMA libraries
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/cpu
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Directory for per-channel information
NN is the VMBUS relid associtated with the channel.
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/cpu
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: VCPU (sub)channel is affinitized to
Users: tools/hv/lsvmbus and other debuggig tools
Users: tools/hv/lsvmbus and other debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/cpu
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/cpu
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: VCPU (sub)channel is affinitized to
Users: tools/hv/lsvmbus and other debuggig tools
Users: tools/hv/lsvmbus and other debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/in_mask
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/in_mask
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Inbound channel signaling state
Description: Host to guest channel interrupt mask
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/latency
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/latency
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Channel signaling latency
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/out_mask
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/out_mask
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Outbound channel signaling state
Description: Guest to host channel interrupt mask
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/pending
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/pending
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Channel interrupt pending state
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/read_avail
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/read_avail
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Bytes availabble to read
Description: Bytes available to read
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/write_avail
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/write_avail
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Bytes availabble to write
Description: Bytes available to write
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/events
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/events
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Number of times we have signaled the host
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/relid/interrupts
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/interrupts
Date: September. 2017
KernelVersion: 4.14
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Number of times we have taken an interrupt (incoming)
Users: Debugging tools
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/subchannel_id
Date: January. 2018
KernelVersion: 4.16
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Subchannel ID associated with VMBUS channel
Users: Debugging tools and userspace drivers
What: /sys/bus/vmbus/devices/vmbus_*/channels/NN/monitor_id
Date: January. 2018
KernelVersion: 4.16
Contact: Stephen Hemminger <sthemmin@microsoft.com>
Description: Monitor bit associated with channel
Users: Debugging tools and userspace drivers

33
Documentation/ABI/testing/devlink-resource-mlxsw Normal file
View File

@ -0,0 +1,33 @@
What: /kvd/
Date: 08-Jan-2018
KernelVersion: v4.16
Contact: mlxsw@mellanox.com
Description: The main database in the Spectrum device is a centralized
KVD database used for many of the tables used to configure
the chip including L2 FDB, L3 LPM, ECMP and more. The KVD
is divided into two sections, the first is hash-based table
and the second is a linear access table. The division
between the linear and hash-based sections is static and
require reload before the changes take effect.
What: /kvd/linear
Date: 08-Jan-2018
KernelVersion: v4.16
Contact: mlxsw@mellanox.com
Description: The linear section of the KVD is managed by software as a
flat memory accessed using an index.
What: /kvd/hash_single
Date: 08-Jan-2018
KernelVersion: v4.16
Contact: mlxsw@mellanox.com
Description: The hash based section of the KVD is managed by the switch
device. Used in case the key size is smaller or equal to
64bit.
What: /kvd/hash_double
Date: 08-Jan-2018
KernelVersion: v4.16
Contact: mlxsw@mellanox.com
Description: The hash based section of the KVD is managed by the switch
device. Used in case the key is larger than 64 bit.

54
Documentation/ABI/testing/evm
View File

@ -14,30 +14,46 @@ Description:
generated either locally or remotely using an
asymmetric key. These keys are loaded onto root's
keyring using keyctl, and EVM is then enabled by
echoing a value to <securityfs>/evm:
echoing a value to <securityfs>/evm made up of the
following bits:
1: enable HMAC validation and creation
2: enable digital signature validation
3: enable HMAC and digital signature validation and HMAC
creation
Bit Effect
0 Enable HMAC validation and creation
1 Enable digital signature validation
2 Permit modification of EVM-protected metadata at
runtime. Not supported if HMAC validation and
creation is enabled.
31 Disable further runtime modification of EVM policy
Further writes will be blocked if HMAC support is enabled or
if bit 32 is set:
For example:
echo 0x80000002 ><securityfs>/evm
echo 1 ><securityfs>/evm
will enable digital signature validation and block
further writes to <securityfs>/evm.
will enable HMAC validation and creation
Until this is done, EVM can not create or validate the
'security.evm' xattr, but returns INTEGRITY_UNKNOWN.
Loading keys and signaling EVM should be done as early
as possible. Normally this is done in the initramfs,
which has already been measured as part of the trusted
boot. For more information on creating and loading
existing trusted/encrypted keys, refer to:
echo 0x80000003 ><securityfs>/evm
Documentation/security/keys/trusted-encrypted.rst. Both dracut
(via 97masterkey and 98integrity) and systemd (via
will enable HMAC and digital signature validation and
HMAC creation and disable all further modification of policy.
echo 0x80000006 ><securityfs>/evm
will enable digital signature validation, permit
modification of EVM-protected metadata and
disable all further modification of policy
Note that once a key has been loaded, it will no longer be
possible to enable metadata modification.
Until key loading has been signaled EVM can not create
or validate the 'security.evm' xattr, but returns
INTEGRITY_UNKNOWN. Loading keys and signaling EVM
should be done as early as possible. Normally this is
done in the initramfs, which has already been measured
as part of the trusted boot. For more information on
creating and loading existing trusted/encrypted keys,
refer to:
Documentation/security/keys/trusted-encrypted.rst. Both
dracut (via 97masterkey and 98integrity) and systemd (via
core/ima-setup) have support for loading keys at boot
time.

3
Documentation/ABI/testing/ima_policy
View File

@ -17,7 +17,8 @@ Description:
rule format: action [condition ...]
action: measure | dont_measure | appraise | dont_appraise | audit
action: measure | dont_measure | appraise | dont_appraise |
audit | hash | dont_hash
condition:= base | lsm [option]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
[euid=] [fowner=]]

42
Documentation/ABI/testing/rtc-cdev Normal file
View File

@ -0,0 +1,42 @@
What: /dev/rtcX
Date: April 2005
KernelVersion: 2.6.12
Contact: linux-rtc@vger.kernel.org
Description:
The ioctl interface to drivers for real-time clocks (RTCs).
Following actions are supported:
* RTC_RD_TIME, RTC_SET_TIME: Read or set the RTC time. Time
format is a Gregorian calendar date and 24 hour wall clock
time.
* RTC_AIE_ON, RTC_AIE_OFF: Enable or disable the alarm interrupt
for RTCs that support alarms
* RTC_ALM_READ, RTC_ALM_SET: Read or set the alarm time for
RTCs that support alarms. Can be set upto 24 hours in the
future. Requires a separate RTC_AIE_ON call to enable the
alarm interrupt. (Prefer to use RTC_WKALM_*)
* RTC_WKALM_RD, RTC_WKALM_SET: For RTCs that support a more
powerful interface, which can issue alarms beyond 24 hours and
enable IRQs in the same request.
* RTC_PIE_ON, RTC_PIE_OFF: Enable or disable the periodic
interrupt for RTCs that support periodic interrupts.
* RTC_UIE_ON, RTC_UIE_OFF: Enable or disable the update
interrupt for RTCs that support it.
* RTC_IRQP_READ, RTC_IRQP_SET: Read or set the frequency for
periodic interrupts for RTCs that support periodic interrupts.
Requires a separate RTC_PIE_ON call to enable the periodic
interrupts.
The ioctl() calls supported by the older /dev/rtc interface are
also supported by the newer RTC class framework. However,
because the chips and systems are not standardized, some PC/AT
functionality might not be provided. And in the same way, some
newer features -- including those enabled by ACPI -- are exposed
by the RTC class framework, but can't be supported by the older
driver.

14
Documentation/ABI/testing/sysfs-bus-iio
View File

@ -32,7 +32,7 @@ Description:
Description of the physical chip / device for device X.
Typically a part number.
What: /sys/bus/iio/devices/iio:deviceX/timestamp_clock
What: /sys/bus/iio/devices/iio:deviceX/current_timestamp_clock
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
@ -1290,7 +1290,7 @@ KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
Unit-less light intensity. Modifiers both and ir indicate
that measurements contains visible and infrared light
that measurements contain visible and infrared light
components or just infrared light, respectively. Modifier uv indicates
that measurements contain ultraviolet light components.
@ -1413,6 +1413,16 @@ Description:
the available samples after the timeout expires and thus have a
maximum delay guarantee.
What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available
KernelVersion: 4.16
Contact: linux-iio@vger.kernel.org
Description:
A read-only value indicating the bytes of data available in the
buffer. In the case of an output buffer, this indicates the
amount of empty space available to write data to. In the case of
an input buffer, this indicates the amount of data available for
reading.
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_enabled
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org

25
Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd Normal file
View File

@ -0,0 +1,25 @@
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc
Date: June 2017
Contact: Lu Baolu <baolu.lu@linux.intel.com>
Description:
xHCI compatible USB host controllers (i.e. super-speed
USB3 controllers) are often implemented with the Debug
Capability (DbC). It can present a debug device which
is fully compliant with the USB framework and provides
the equivalent of a very high performance full-duplex
serial link for debug purpose.
The DbC debug device shares a root port with xHCI host.
When the DbC is enabled, the root port will be assigned
to the Debug Capability. Otherwise, it will be assigned
to xHCI.
Writing "enable" to this attribute will enable the DbC
functionality and the shared root port will be assigned
to the DbC device. Writing "disable" to this attribute
will disable the DbC functionality and the shared root
port will roll back to the xHCI.
Reading this attribute gives the state of the DbC. It
can be one of the following states: disabled, enabled,
initialized, connected, configured and stalled.

87
Documentation/ABI/testing/sysfs-bus-siox Normal file
View File

@ -0,0 +1,87 @@
What: /sys/bus/siox/devices/siox-X/active
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
On reading represents the current state of the bus. If it
contains a "0" the bus is stopped and connected devices are
expected to not do anything because their watchdog triggered.
When the file contains a "1" the bus is operated and periodically
does a push-pull cycle to write and read data from the
connected devices.
When writing a "0" or "1" the bus moves to the described state.
What: /sys/bus/siox/devices/siox-X/device_add
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Write-only file. Write
<type> <inbytes> <outbytes> <statustype>
to add a new device dynamically. <type> is the name that is used to match
to a driver (similar to the platform bus). <inbytes> and <outbytes> define
the length of the input and output shift register in bytes respectively.
<statustype> defines the 4 bit device type that is check to identify connection
problems.
The new device is added to the end of the existing chain.
What: /sys/bus/siox/devices/siox-X/device_remove
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Write-only file. A single write removes the last device in the siox chain.
What: /sys/bus/siox/devices/siox-X/poll_interval_ns
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Defines the interval between two poll cycles in nano seconds.
Note this is rounded to jiffies on writing. On reading the current value
is returned.
What: /sys/bus/siox/devices/siox-X-Y/connected
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Read-only value. "0" means the Yth device on siox bus X isn't "connected" i.e.
communication with it is not ensured. "1" signals a working connection.
What: /sys/bus/siox/devices/siox-X-Y/inbytes
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Read-only value reporting the inbytes value provided to siox-X/device_add
What: /sys/bus/siox/devices/siox-X-Y/status_errors
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Counts the number of time intervals when the read status byte doesn't yield the
expected value.
What: /sys/bus/siox/devices/siox-X-Y/type
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Read-only value reporting the type value provided to siox-X/device_add.
What: /sys/bus/siox/devices/siox-X-Y/watchdog
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Read-only value reporting if the watchdog of the siox device is
active. "0" means the watchdog is not active and the device is expected to
be operational. "1" means the watchdog keeps the device in reset.
What: /sys/bus/siox/devices/siox-X-Y/watchdog_errors
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Read-only value reporting the number to time intervals when the
watchdog was active.
What: /sys/bus/siox/devices/siox-X-Y/outbytes
KernelVersion: 4.16
Contact: Gavin Schenk <g.schenk@eckelmann.de>, Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Description:
Read-only value reporting the outbytes value provided to siox-X/device_add.

45
Documentation/ABI/testing/sysfs-class-led-trigger-netdev Normal file
View File

@ -0,0 +1,45 @@
What: /sys/class/leds/<led>/device_name
Date: Dec 2017
KernelVersion: 4.16
Contact: linux-leds@vger.kernel.org
Description:
Specifies the network device name to monitor.
What: /sys/class/leds/<led>/interval
Date: Dec 2017
KernelVersion: 4.16
Contact: linux-leds@vger.kernel.org
Description:
Specifies the duration of the LED blink in milliseconds.
Defaults to 50 ms.
What: /sys/class/leds/<led>/link
Date: Dec 2017
KernelVersion: 4.16
Contact: linux-leds@vger.kernel.org
Description:
Signal the link state of the named network device.
If set to 0 (default), the LED's normal state is off.
If set to 1, the LED's normal state reflects the link state
of the named network device.
Setting this value also immediately changes the LED state.
What: /sys/class/leds/<led>/tx
Date: Dec 2017
KernelVersion: 4.16
Contact: linux-leds@vger.kernel.org
Description:
Signal transmission of data on the named network device.
If set to 0 (default), the LED will not blink on transmission.
If set to 1, the LED will blink for the milliseconds specified
in interval to signal transmission.
What: /sys/class/leds/<led>/rx
Date: Dec 2017
KernelVersion: 4.16
Contact: linux-leds@vger.kernel.org
Description:
Signal reception of data on the named network device.
If set to 0 (default), the LED will not blink on reception.
If set to 1, the LED will blink for the milliseconds specified
in interval to signal reception.

24
Documentation/ABI/testing/sysfs-class-net
View File

@ -259,3 +259,27 @@ Contact: netdev@vger.kernel.org
Description:
Symbolic link to the PHY device this network device is attached
to.
What: /sys/class/net/<iface>/carrier_changes
Date: Mar 2014
KernelVersion: 3.15
Contact: netdev@vger.kernel.org
Description:
32-bit unsigned integer counting the number of times the link has
seen a change from UP to DOWN and vice versa
What: /sys/class/net/<iface>/carrier_up_count
Date: Jan 2018
KernelVersion: 4.16
Contact: netdev@vger.kernel.org
Description:
32-bit unsigned integer counting the number of times the link has
been up
What: /sys/class/net/<iface>/carrier_down_count
Date: Jan 2018
KernelVersion: 4.16
Contact: netdev@vger.kernel.org
Description:
32-bit unsigned integer counting the number of times the link has
been down

35
Documentation/ABI/testing/sysfs-class-ocxl Normal file
View File

@ -0,0 +1,35 @@
What: /sys/class/ocxl/<afu name>/afu_version
Date: January 2018
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Version of the AFU, in the format <major>:<minor>
Reflects what is read in the configuration space of the AFU
What: /sys/class/ocxl/<afu name>/contexts
Date: January 2018
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Number of contexts for the AFU, in the format <n>/<max>
where:
n: number of currently active contexts, for debug
max: maximum number of contexts supported by the AFU
What: /sys/class/ocxl/<afu name>/pp_mmio_size
Date: January 2018
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Size of the per-process mmio area, as defined in the
configuration space of the AFU
What: /sys/class/ocxl/<afu name>/global_mmio_size
Date: January 2018
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Size of the global mmio area, as defined in the
configuration space of the AFU
What: /sys/class/ocxl/<afu name>/global_mmio_area
Date: January 2018
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Give access the global mmio area for the AFU

91
Documentation/ABI/testing/sysfs-class-rtc Normal file
View File

@ -0,0 +1,91 @@
What: /sys/class/rtc/
Date: March 2006
KernelVersion: 2.6.17
Contact: linux-rtc@vger.kernel.org
Description:
The rtc/ class subdirectory belongs to the RTC subsystem.
What: /sys/class/rtc/rtcX/
Date: March 2006
KernelVersion: 2.6.17
Contact: linux-rtc@vger.kernel.org
Description:
The /sys/class/rtc/rtc{0,1,2,3,...} directories correspond
to each RTC device.
What: /sys/class/rtc/rtcX/date
Date: March 2006
KernelVersion: 2.6.17
Contact: linux-rtc@vger.kernel.org
Description:
(RO) RTC-provided date in YYYY-MM-DD format
What: /sys/class/rtc/rtcX/hctosys
Date: September 2009
KernelVersion: 2.6.32
Contact: linux-rtc@vger.kernel.org
Description:
(RO) 1 if the RTC provided the system time at boot via the
CONFIG_RTC_HCTOSYS kernel option, 0 otherwise
What: /sys/class/rtc/rtcX/max_user_freq
Date: October 2007
KernelVersion: 2.6.24
Contact: linux-rtc@vger.kernel.org
Description:
(RW) The maximum interrupt rate an unprivileged user may request
from this RTC.
What: /sys/class/rtc/rtcX/name
Date: March 2006
KernelVersion: 2.6.17
Contact: linux-rtc@vger.kernel.org
Description:
(RO) The name of the RTC corresponding to this sysfs directory
What: /sys/class/rtc/rtcX/since_epoch
Date: March 2006
KernelVersion: 2.6.17
Contact: linux-rtc@vger.kernel.org
Description:
(RO) RTC-provided time as the number of seconds since the epoch
What: /sys/class/rtc/rtcX/time
Date: March 2006
KernelVersion: 2.6.17
Contact: linux-rtc@vger.kernel.org
Description:
(RO) RTC-provided time in 24-hour notation (hh:mm:ss)
What: /sys/class/rtc/rtcX/*/nvmem
Date: February 2016
KernelVersion: 4.6
Contact: linux-rtc@vger.kernel.org
Description:
(RW) The non volatile storage exported as a raw file, as
described in Documentation/nvmem/nvmem.txt
What: /sys/class/rtc/rtcX/offset
Date: February 2016
KernelVersion: 4.6
Contact: linux-rtc@vger.kernel.org
Description:
(RW) The amount which the rtc clock has been adjusted in
firmware. Visible only if the driver supports clock offset
adjustment. The unit is parts per billion, i.e. The number of
clock ticks which are added to or removed from the rtc's base
clock per billion ticks. A positive value makes a day pass more
slowly, longer, and a negative value makes a day pass more
quickly.
What: /sys/class/rtc/rtcX/wakealarm
Date: February 2007
KernelVersion: 2.6.20
Contact: linux-rtc@vger.kernel.org
Description:
(RW) The time at which the clock will generate a system wakeup
event. This is a one shot wakeup event, so must be reset after
wake if a daily wakeup is required. Format is seconds since the
epoch by default, or if there's a leading +, seconds in the
future, or if there is a leading +=, seconds ahead of the
current alarm.

10
Documentation/ABI/testing/sysfs-devices-coredump Normal file
View File

@ -0,0 +1,10 @@
What: /sys/devices/.../coredump
Date: December 2017
Contact: Arend van Spriel <aspriel@gmail.com>
Description:
The /sys/devices/.../coredump attribute is only present when the
device is bound to a driver, which provides the .coredump()
callback. The attribute is write only. Anything written to this
file will trigger the .coredump() callback.
Available when CONFIG_DEV_COREDUMP is enabled.

39
Documentation/ABI/testing/sysfs-devices-platform-dock Normal file
View File

@ -0,0 +1,39 @@
What: /sys/devices/platform/dock.N/docked
Date: Dec, 2006
KernelVersion: 2.6.19
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Value 1 or 0 indicates whether the software believes the
laptop is docked in a docking station.
What: /sys/devices/platform/dock.N/undock
Date: Dec, 2006
KernelVersion: 2.6.19
Contact: linux-acpi@vger.kernel.org
Description:
(WO) Writing to this file causes the software to initiate an
undock request to the firmware.
What: /sys/devices/platform/dock.N/uid
Date: Feb, 2007
KernelVersion: v2.6.21
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Displays the docking station the laptop is docked to.
What: /sys/devices/platform/dock.N/flags
Date: May, 2007
KernelVersion: v2.6.21
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Show dock station flags, useful for checking if undock
request has been made by the user (from the immediate_undock
option).
What: /sys/devices/platform/dock.N/type
Date: Aug, 2008
KernelVersion: v2.6.27
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Display the dock station type- dock_station, ata_bay or
battery_bay.

77
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -108,6 +108,8 @@ Description: CPU topology files that describe a logical CPU's relationship
What: /sys/devices/system/cpu/cpuidle/current_driver
/sys/devices/system/cpu/cpuidle/current_governer_ro
/sys/devices/system/cpu/cpuidle/available_governors
/sys/devices/system/cpu/cpuidle/current_governor
Date: September 2007
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Discover cpuidle policy and mechanism
@ -119,13 +121,84 @@ Description: Discover cpuidle policy and mechanism
Idle policy (governor) is differentiated from idle mechanism
(driver)
current_driver: displays current idle mechanism
current_driver: (RO) displays current idle mechanism
current_governor_ro: displays current idle policy
current_governor_ro: (RO) displays current idle policy
With the cpuidle_sysfs_switch boot option enabled (meant for
developer testing), the following three attributes are visible
instead:
current_driver: same as described above
available_governors: (RO) displays a space separated list of
available governors
current_governor: (RW) displays current idle policy. Users can
switch the governor at runtime by writing to this file.
See files in Documentation/cpuidle/ for more information.
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/name
/sys/devices/system/cpu/cpuX/cpuidle/stateN/latency
/sys/devices/system/cpu/cpuX/cpuidle/stateN/power
/sys/devices/system/cpu/cpuX/cpuidle/stateN/time
/sys/devices/system/cpu/cpuX/cpuidle/stateN/usage
Date: September 2007
KernelVersion: v2.6.24
Contact: Linux power management list <linux-pm@vger.kernel.org>
Description:
The directory /sys/devices/system/cpu/cpuX/cpuidle contains per
logical CPU specific cpuidle information for each online cpu X.
The processor idle states which are available for use have the
following attributes:
name: (RO) Name of the idle state (string).
latency: (RO) The latency to exit out of this idle state (in
microseconds).
power: (RO) The power consumed while in this idle state (in
milliwatts).
time: (RO) The total time spent in this idle state (in microseconds).
usage: (RO) Number of times this state was entered (a count).
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/desc
Date: February 2008
KernelVersion: v2.6.25
Contact: Linux power management list <linux-pm@vger.kernel.org>
Description:
(RO) A small description about the idle state (string).
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/disable
Date: March 2012
KernelVersion: v3.10
Contact: Linux power management list <linux-pm@vger.kernel.org>
Description:
(RW) Option to disable this idle state (bool). The behavior and
the effect of the disable variable depends on the implementation
of a particular governor. In the ladder governor, for example,
it is not coherent, i.e. if one is disabling a light state, then
all deeper states are disabled as well, but the disable variable
does not reflect it. Likewise, if one enables a deep state but a
lighter state still is disabled, then this has no effect.
What: /sys/devices/system/cpu/cpuX/cpuidle/stateN/residency
Date: March 2014
KernelVersion: v3.15
Contact: Linux power management list <linux-pm@vger.kernel.org>
Description:
(RO) Display the target residency i.e. the minimum amount of
time (in microseconds) this cpu should spend in this idle state
to make the transition worth the effort.
What: /sys/devices/system/cpu/cpu#/cpufreq/*
Date: pre-git history
Contact: linux-pm@vger.kernel.org

2
Documentation/ABI/testing/sysfs-driver-samsung-laptop
View File

@ -3,7 +3,7 @@ Date: January 1, 2010
KernelVersion: 2.6.33
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Description: Some Samsung laptops have different "performance levels"
that are can be modified by a function key, and by this
that can be modified by a function key, and by this
sysfs file. These values don't always make a whole lot
of sense, but some users like to modify them to keep
their fans quiet at all costs. Reading from this file

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

@ -186,3 +186,9 @@ Date: August 2017
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls sleep time of GC urgent mode
What: /sys/fs/f2fs/<disk>/readdir_ra
Date: November 2017
Contact: "Sheng Yong" <shengyong1@huawei.com>
Description:
Controls readahead inode block in readdir.

26
Documentation/ABI/testing/sysfs-kernel-livepatch
View File

@ -33,6 +33,32 @@ Description:
An attribute which indicates whether the patch is currently in
transition.
What: /sys/kernel/livepatch/<patch>/signal
Date: Nov 2017
KernelVersion: 4.15.0
Contact: live-patching@vger.kernel.org
Description:
A writable attribute that allows administrator to affect the
course of an existing transition. Writing 1 sends a fake
signal to all remaining blocking tasks. The fake signal
means that no proper signal is delivered (there is no data in
signal pending structures). Tasks are interrupted or woken up,
and forced to change their patched state.
What: /sys/kernel/livepatch/<patch>/force
Date: Nov 2017
KernelVersion: 4.15.0
Contact: live-patching@vger.kernel.org
Description:
A writable attribute that allows administrator to affect the
course of an existing transition. Writing 1 clears
TIF_PATCH_PENDING flag of all tasks and thus forces the tasks to
the patched or unpatched state. Administrator should not
use this feature without a clearance from a patch
distributor. Removal (rmmod) of patch modules is permanently
disabled when the feature is used. See
Documentation/livepatch/livepatch.txt for more information.
What: /sys/kernel/livepatch/<patch>/<object>
Date: Nov 2014
KernelVersion: 3.19.0

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

@ -0,0 +1,40 @@
What: /sys/bus/platform/devices/INT3407:00/dptf_power/charger_type
Date: Jul, 2016
KernelVersion: v4.10
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The charger type - Traditional, Hybrid or NVDC.
What: /sys/bus/platform/devices/INT3407:00/dptf_power/adapter_rating_mw
Date: Jul, 2016
KernelVersion: v4.10
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Adapter rating in milliwatts (the maximum Adapter power).
Must be 0 if no AC Adaptor is plugged in.
What: /sys/bus/platform/devices/INT3407:00/dptf_power/max_platform_power_mw
Date: Jul, 2016
KernelVersion: v4.10
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Maximum platform power that can be supported by the battery
in milliwatts.
What: /sys/bus/platform/devices/INT3407:00/dptf_power/platform_power_source
Date: Jul, 2016
KernelVersion: v4.10
Contact: linux-acpi@vger.kernel.org
Description:
(RO) Display the platform power source
0x00 = DC
0x01 = AC
0x02 = USB
0x03 = Wireless Charger
What: /sys/bus/platform/devices/INT3407:00/dptf_power/battery_steady_power
Date: Jul, 2016
KernelVersion: v4.10
Contact: linux-acpi@vger.kernel.org
Description:
(RO) The maximum sustained power for battery in milliwatts.

160
Documentation/accelerators/ocxl.rst Normal file
View File

@ -0,0 +1,160 @@
========================================================
OpenCAPI (Open Coherent Accelerator Processor Interface)
========================================================
OpenCAPI is an interface between processors and accelerators. It aims
at being low-latency and high-bandwidth. The specification is
developed by the `OpenCAPI Consortium <http://opencapi.org/>`_.
It allows an accelerator (which could be a FPGA, ASICs, ...) to access
the host memory coherently, using virtual addresses. An OpenCAPI
device can also host its own memory, that can be accessed from the
host.
OpenCAPI is known in linux as 'ocxl', as the open, processor-agnostic
evolution of 'cxl' (the driver for the IBM CAPI interface for
powerpc), which was named that way to avoid confusion with the ISDN
CAPI subsystem.
High-level view
===============
OpenCAPI defines a Data Link Layer (DL) and Transaction Layer (TL), to
be implemented on top of a physical link. Any processor or device
implementing the DL and TL can start sharing memory.
::
+-----------+ +-------------+
| | | |
| | | Accelerated |
| Processor | | Function |
| | +--------+ | Unit | +--------+
| |--| Memory | | (AFU) |--| Memory |
| | +--------+ | | +--------+
+-----------+ +-------------+
| |
+-----------+ +-------------+
| TL | | TLX |
+-----------+ +-------------+
| |
+-----------+ +-------------+
| DL | | DLX |
+-----------+ +-------------+
| |
| PHY |
+---------------------------------------+
Device discovery
================
OpenCAPI relies on a PCI-like configuration space, implemented on the
device. So the host can discover AFUs by querying the config space.
OpenCAPI devices in Linux are treated like PCI devices (with a few
caveats). The firmware is expected to abstract the hardware as if it
was a PCI link. A lot of the existing PCI infrastructure is reused:
devices are scanned and BARs are assigned during the standard PCI
enumeration. Commands like 'lspci' can therefore be used to see what
devices are available.
The configuration space defines the AFU(s) that can be found on the
physical adapter, such as its name, how many memory contexts it can
work with, the size of its MMIO areas, ...
MMIO
====
OpenCAPI defines two MMIO areas for each AFU:
* the global MMIO area, with registers pertinent to the whole AFU.
* a per-process MMIO area, which has a fixed size for each context.
AFU interrupts
==============
OpenCAPI includes the possibility for an AFU to send an interrupt to a
host process. It is done through a 'intrp_req' defined in the
Transaction Layer, specifying a 64-bit object handle which defines the
interrupt.
The driver allows a process to allocate an interrupt and obtain its
64-bit object handle, that can be passed to the AFU.
char devices
============
The driver creates one char device per AFU found on the physical
device. A physical device may have multiple functions and each
function can have multiple AFUs. At the time of this writing though,
it has only been tested with devices exporting only one AFU.
Char devices can be found in /dev/ocxl/ and are named as:
/dev/ocxl/<AFU name>.<location>.<index>
where <AFU name> is a max 20-character long name, as found in the
config space of the AFU.
<location> is added by the driver and can help distinguish devices
when a system has more than one instance of the same OpenCAPI device.
<index> is also to help distinguish AFUs in the unlikely case where a
device carries multiple copies of the same AFU.
Sysfs class
===========
An ocxl class is added for the devices representing the AFUs. See
/sys/class/ocxl. The layout is described in
Documentation/ABI/testing/sysfs-class-ocxl
User API
========
open
----
Based on the AFU definition found in the config space, an AFU may
support working with more than one memory context, in which case the
associated char device may be opened multiple times by different
processes.
ioctl
-----
OCXL_IOCTL_ATTACH:
Attach the memory context of the calling process to the AFU so that
the AFU can access its memory.
OCXL_IOCTL_IRQ_ALLOC:
Allocate an AFU interrupt and return an identifier.
OCXL_IOCTL_IRQ_FREE:
Free a previously allocated AFU interrupt.
OCXL_IOCTL_IRQ_SET_FD:
Associate an event fd to an AFU interrupt so that the user process
can be notified when the AFU sends an interrupt.
mmap
----
A process can mmap the per-process MMIO area for interactions with the
AFU.

5
Documentation/admin-guide/README.rst
View File

@ -170,11 +170,6 @@ Configuring the kernel
your existing ./.config file and asking about
new config symbols.
"make silentoldconfig"
Like above, but avoids cluttering the screen
with questions already answered.
Additionally updates the dependencies.
"make olddefconfig"
Like above, but sets new symbols to their default
values without prompting.

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

@ -646,6 +646,20 @@
console=brl,ttyS0
For now, only VisioBraille is supported.
console_msg_format=
[KNL] Change console messages format
default
By default we print messages on consoles in
"[time stamp] text\n" format (time stamp may not be
printed, depending on CONFIG_PRINTK_TIME or
`printk_time' param).
syslog
Switch to syslog format: "<%u>[time stamp] text\n"
IOW, each message will have a facility and loglevel
prefix. The format is similar to one used by syslog()
syscall, or to executing "dmesg -S --raw" or to reading
from /proc/kmsg.
consoleblank= [KNL] The console blank (screen saver) timeout in
seconds. A value of 0 disables the blank timer.
Defaults to 0.
@ -917,9 +931,12 @@
earlycon= [KNL] Output early console device and options.
When used with no options, the early console is
determined by the stdout-path property in device
tree's chosen node.
[ARM64] The early console is determined by the
stdout-path property in device tree's chosen node,
or determined by the ACPI SPCR table.
[X86] When used with no options the early console is
determined by the ACPI SPCR table.
cdns,<addr>[,options]
Start an early, polled-mode console on a Cadence
@ -2538,6 +2555,9 @@
This is useful when you use a panic=... timeout and
need the box quickly up again.
These settings can be accessed at runtime via
the nmi_watchdog and hardlockup_panic sysctls.
netpoll.carrier_timeout=
[NET] Specifies amount of time (in seconds) that
netpoll should wait for a carrier. By default netpoll
@ -2741,8 +2761,6 @@
norandmaps Don't use address space randomization. Equivalent to
echo 0 > /proc/sys/kernel/randomize_va_space
noreplace-paravirt [X86,IA-64,PV_OPS] Don't patch paravirt_ops
noreplace-smp [X86-32,SMP] Don't replace SMP instructions
with UP alternatives
@ -3696,7 +3714,11 @@
[KNL, SMP] Set scheduler's default relax_domain_level.
See Documentation/cgroup-v1/cpusets.txt.
reserve= [KNL,BUGS] Force the kernel to ignore some iomem area
reserve= [KNL,BUGS] Force kernel to ignore I/O ports or memory
Format: <base1>,<size1>[,<base2>,<size2>,...]
Reserve I/O ports or memory so the kernel won't use
them. If <base> is less than 0x10000, the region
is assumed to be I/O ports; otherwise it is memory.
reservetop= [X86-32]
Format: nn[KMG]

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

@ -9,14 +9,14 @@ This will allow you to execute Mono-based .NET binaries just like any
other program after you have done the following:
1) You MUST FIRST install the Mono CLR support, either by downloading
a binary package, a source tarball or by installing from CVS. Binary
a binary package, a source tarball or by installing from Git. Binary
packages for several distributions can be found at:
http://go-mono.com/download.html
http://www.mono-project.com/download/
Instructions for compiling Mono can be found at:
http://www.go-mono.com/compiling.html
http://www.mono-project.com/docs/compiling-mono/linux/
Once the Mono CLR support has been installed, just check that
``/usr/bin/mono`` (which could be located elsewhere, for example

66
Documentation/admin-guide/thunderbolt.rst
View File

@ -3,13 +3,13 @@
=============
The interface presented here is not meant for end users. Instead there
should be a userspace tool that handles all the low-level details, keeps
database of the authorized devices and prompts user for new connections.
a database of the authorized devices and prompts users for new connections.
More details about the sysfs interface for Thunderbolt devices can be
found in ``Documentation/ABI/testing/sysfs-bus-thunderbolt``.
Those users who just want to connect any device without any sort of
manual work, can add following line to
manual work can add following line to
``/etc/udev/rules.d/99-local.rules``::
ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", ATTR{authorized}="1"
@ -20,7 +20,7 @@ vulnerable to DMA attacks.
Security levels and how to use them
-----------------------------------
Starting from Intel Falcon Ridge Thunderbolt controller there are 4
Starting with Intel Falcon Ridge Thunderbolt controller there are 4
security levels available. The reason for these is the fact that the
connected devices can be DMA masters and thus read contents of the host
memory without CPU and OS knowing about it. There are ways to prevent
@ -37,14 +37,14 @@ The security levels are as follows:
user
User is asked whether the device is allowed to be connected.
Based on the device identification information available through
``/sys/bus/thunderbolt/devices``. user then can do the decision.
``/sys/bus/thunderbolt/devices``, the user then can make the decision.
In BIOS settings this is typically called *Unique ID*.
secure
User is asked whether the device is allowed to be connected. In
addition to UUID the device (if it supports secure connect) is sent
a challenge that should match the expected one based on a random key
written to ``key`` sysfs attribute. In BIOS settings this is
written to the ``key`` sysfs attribute. In BIOS settings this is
typically called *One time saved key*.
dponly
@ -78,7 +78,7 @@ When a device is plugged in it will appear in sysfs as follows::
/sys/bus/thunderbolt/devices/0-1/unique_id - e0376f00-0300-0100-ffff-ffffffffffff
The ``authorized`` attribute reads 0 which means no PCIe tunnels are
created yet. The user can authorize the device by simply::
created yet. The user can authorize the device by simply entering::
# echo 1 > /sys/bus/thunderbolt/devices/0-1/authorized
@ -86,7 +86,7 @@ This will create the PCIe tunnels and the device is now connected.
If the device supports secure connect, and the domain security level is
set to ``secure``, it has an additional attribute ``key`` which can hold
a random 32 byte value used for authorization and challenging the device in
a random 32-byte value used for authorization and challenging the device in
future connects::
/sys/bus/thunderbolt/devices/0-3/authorized - 0
@ -99,12 +99,12 @@ future connects::
Notice the key is empty by default.
If the user does not want to use secure connect it can just ``echo 1``
If the user does not want to use secure connect they can just ``echo 1``
to the ``authorized`` attribute and the PCIe tunnels will be created in
the same way than in ``user`` security level.
the same way as in the ``user`` security level.
If the user wants to use secure connect, the first time the device is
plugged a key needs to be created and send to the device::
plugged a key needs to be created and sent to the device::
# key=$(openssl rand -hex 32)
# echo $key > /sys/bus/thunderbolt/devices/0-3/key
@ -121,27 +121,27 @@ device using the same key::
If the challenge the device returns back matches the one we expect based
on the key, the device is connected and the PCIe tunnels are created.
However, if the challenge failed no tunnels are created and error is
However, if the challenge fails no tunnels are created and error is
returned to the user.
If the user still wants to connect the device it can either approve
the device without a key or write new key and write 1 to the
If the user still wants to connect the device they can either approve
the device without a key or write a new key and write 1 to the
``authorized`` file to get the new key stored on the device NVM.
Upgrading NVM on Thunderbolt device or host
-------------------------------------------
Since most of the functionality is handled in a firmware running on a
Since most of the functionality is handled in firmware running on a
host controller or a device, it is important that the firmware can be
upgraded to the latest where possible bugs in it have been fixed.
Typically OEMs provide this firmware from their support site.
There is also a central site which has links where to download firmwares
There is also a central site which has links where to download firmware
for some machines:
`Thunderbolt Updates <https://thunderbolttechnology.net/updates>`_
Before you upgrade firmware on a device or host, please make sure it is
the suitable. Failing to do that may render the device (or host) in a
Before you upgrade firmware on a device or host, please make sure it is a
suitable upgrade. Failing to do that may render the device (or host) in a
state where it cannot be used properly anymore without special tools!
Host NVM upgrade on Apple Macs is not supported.
@ -151,7 +151,7 @@ Thunderbolt device so that the host controller appears. It does not
matter which device is connected (unless you are upgrading NVM on a
device - then you need to connect that particular device).
Note OEM-specific method to power the controller up ("force power") may
Note an OEM-specific method to power the controller up ("force power") may
be available for your system in which case there is no need to plug in a
Thunderbolt device.
@ -171,7 +171,7 @@ it comes back the driver notices it and initiates a full power cycle.
After a while the host controller appears again and this time it should
be fully functional.
We can verify that the new NVM firmware is active by running following
We can verify that the new NVM firmware is active by running the following
commands::
# cat /sys/bus/thunderbolt/devices/0-0/nvm_authenticate
@ -179,38 +179,38 @@ commands::
# cat /sys/bus/thunderbolt/devices/0-0/nvm_version
18.0
If ``nvm_authenticate`` contains anything else than 0x0 it is the error
If ``nvm_authenticate`` contains anything other than 0x0 it is the error
code from the last authentication cycle, which means the authentication
of the NVM image failed.
Note names of the NVMem devices ``nvm_activeN`` and ``nvm_non_activeN``
depends on the order they are registered in the NVMem subsystem. N in
depend on the order they are registered in the NVMem subsystem. N in
the name is the identifier added by the NVMem subsystem.
Upgrading NVM when host controller is in safe mode
--------------------------------------------------
If the existing NVM is not properly authenticated (or is missing) the
host controller goes into safe mode which means that only available
functionality is flashing new NVM image. When in this mode the reading
host controller goes into safe mode which means that the only available
functionality is flashing a new NVM image. When in this mode, reading
``nvm_version`` fails with ``ENODATA`` and the device identification
information is missing.
To recover from this mode, one needs to flash a valid NVM image to the
host host controller in the same way it is done in the previous chapter.
host controller in the same way it is done in the previous chapter.
Networking over Thunderbolt cable
---------------------------------
Thunderbolt technology allows software communication across two hosts
Thunderbolt technology allows software communication between two hosts
connected by a Thunderbolt cable.
It is possible to tunnel any kind of traffic over Thunderbolt link but
It is possible to tunnel any kind of traffic over a Thunderbolt link but
currently we only support Apple ThunderboltIP protocol.
If the other host is running Windows or macOS only thing you need to
do is to connect Thunderbolt cable between the two hosts, the
``thunderbolt-net`` is loaded automatically. If the other host is also
Linux you should load ``thunderbolt-net`` manually on one host (it does
not matter which one)::
If the other host is running Windows or macOS, the only thing you need to
do is to connect a Thunderbolt cable between the two hosts; the
``thunderbolt-net`` driver is loaded automatically. If the other host is
also Linux you should load ``thunderbolt-net`` manually on one host (it
does not matter which one)::
# modprobe thunderbolt-net
@ -220,12 +220,12 @@ is built-in to the kernel image, there is no need to do anything.
The driver will create one virtual ethernet interface per Thunderbolt
port which are named like ``thunderbolt0`` and so on. From this point
you can either use standard userspace tools like ``ifconfig`` to
configure the interface or let your GUI to handle it automatically.
configure the interface or let your GUI handle it automatically.
Forcing power
-------------
Many OEMs include a method that can be used to force the power of a
thunderbolt controller to an "On" state even if nothing is connected.
Thunderbolt controller to an "On" state even if nothing is connected.
If supported by your machine this will be exposed by the WMI bus with
a sysfs attribute called "force_power".

4
Documentation/arm64/cpu-feature-registers.txt
View File

@ -110,7 +110,9 @@ infrastructure:
x--------------------------------------------------x
| Name | bits | visible |
|--------------------------------------------------|
| RES0 | [63-48] | n |
| RES0 | [63-52] | n |
|--------------------------------------------------|
| FHM | [51-48] | y |
|--------------------------------------------------|
| DP | [47-44] | y |
|--------------------------------------------------|

4
Documentation/arm64/elf_hwcaps.txt
View File

@ -158,3 +158,7 @@ HWCAP_SHA512
HWCAP_SVE
Functionality implied by ID_AA64PFR0_EL1.SVE == 0b0001.
HWCAP_ASIMDFHM
Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0001.

2
Documentation/arm64/silicon-errata.txt
View File

@ -72,7 +72,7 @@ stable kernels.
| Hisilicon | Hip0{6,7} | #161010701 | N/A |
| Hisilicon | Hip07 | #161600802 | HISILICON_ERRATUM_161600802 |
| | | | |
| Qualcomm Tech. | Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
| Qualcomm Tech. | Falkor v1 | E1009 | QCOM_FALKOR_ERRATUM_1009 |
| Qualcomm Tech. | QDF2400 ITS | E0065 | QCOM_QDF2400_ERRATUM_0065 |
| Qualcomm Tech. | Falkor v{1,2} | E1041 | QCOM_FALKOR_ERRATUM_1041 |

7
Documentation/atomic_bitops.txt
View File

@ -58,7 +58,12 @@ Like with atomic_t, the rule of thumb is:
- RMW operations that have a return value are fully ordered.
Except for test_and_set_bit_lock() which has ACQUIRE semantics and
- RMW operations that are conditional are unordered on FAILURE,
otherwise the above rules apply. In the case of test_and_{}_bit() operations,
if the bit in memory is unchanged by the operation then it is deemed to have
failed.
Except for a successful test_and_set_bit_lock() which has ACQUIRE semantics and
clear_bit_unlock() which has RELEASE semantics.
Since a platform only has a single means of achieving atomic operations

550
Documentation/bpf/bpf_devel_QA.txt Normal file
View File

@ -0,0 +1,550 @@
This document provides information for the BPF subsystem about various
workflows related to reporting bugs, submitting patches, and queueing
patches for stable kernels.
For general information about submitting patches, please refer to
Documentation/process/. This document only describes additional specifics
related to BPF.
Reporting bugs:
---------------
Q: How do I report bugs for BPF kernel code?
A: Since all BPF kernel development as well as bpftool and iproute2 BPF
loader development happens through the netdev kernel mailing list,
please report any found issues around BPF to the following mailing
list:
netdev@vger.kernel.org
This may also include issues related to XDP, BPF tracing, etc.
Given netdev has a high volume of traffic, please also add the BPF
maintainers to Cc (from kernel MAINTAINERS file):
Alexei Starovoitov <ast@kernel.org>
Daniel Borkmann <daniel@iogearbox.net>
In case a buggy commit has already been identified, make sure to keep
the actual commit authors in Cc as well for the report. They can
typically be identified through the kernel's git tree.
Please do *not* report BPF issues to bugzilla.kernel.org since it
is a guarantee that the reported issue will be overlooked.
Submitting patches:
-------------------
Q: To which mailing list do I need to submit my BPF patches?
A: Please submit your BPF patches to the netdev kernel mailing list:
netdev@vger.kernel.org
Historically, BPF came out of networking and has always been maintained
by the kernel networking community. Although these days BPF touches
many other subsystems as well, the patches are still routed mainly
through the networking community.
In case your patch has changes in various different subsystems (e.g.
tracing, security, etc), make sure to Cc the related kernel mailing
lists and maintainers from there as well, so they are able to review
the changes and provide their Acked-by's to the patches.
Q: Where can I find patches currently under discussion for BPF subsystem?
A: All patches that are Cc'ed to netdev are queued for review under netdev
patchwork project:
http://patchwork.ozlabs.org/project/netdev/list/
Those patches which target BPF, are assigned to a 'bpf' delegate for
further processing from BPF maintainers. The current queue with
patches under review can be found at:
https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147
Once the patches have been reviewed by the BPF community as a whole
and approved by the BPF maintainers, their status in patchwork will be
changed to 'Accepted' and the submitter will be notified by mail. This
means that the patches look good from a BPF perspective and have been
applied to one of the two BPF kernel trees.
In case feedback from the community requires a respin of the patches,
their status in patchwork will be set to 'Changes Requested', and purged
from the current review queue. Likewise for cases where patches would
get rejected or are not applicable to the BPF trees (but assigned to
the 'bpf' delegate).
Q: How do the changes make their way into Linux?
A: There are two BPF kernel trees (git repositories). Once patches have
been accepted by the BPF maintainers, they will be applied to one
of the two BPF trees:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/
The bpf tree itself is for fixes only, whereas bpf-next for features,
cleanups or other kind of improvements ("next-like" content). This is
analogous to net and net-next trees for networking. Both bpf and
bpf-next will only have a master branch in order to simplify against
which branch patches should get rebased to.
Accumulated BPF patches in the bpf tree will regularly get pulled
into the net kernel tree. Likewise, accumulated BPF patches accepted
into the bpf-next tree will make their way into net-next tree. net and
net-next are both run by David S. Miller. From there, they will go
into the kernel mainline tree run by Linus Torvalds. To read up on the
process of net and net-next being merged into the mainline tree, see
the netdev FAQ under:
Documentation/networking/netdev-FAQ.txt
Occasionally, to prevent merge conflicts, we might send pull requests
to other trees (e.g. tracing) with a small subset of the patches, but
net and net-next are always the main trees targeted for integration.
The pull requests will contain a high-level summary of the accumulated
patches and can be searched on netdev kernel mailing list through the
following subject lines (yyyy-mm-dd is the date of the pull request):
pull-request: bpf yyyy-mm-dd
pull-request: bpf-next yyyy-mm-dd
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be
applied to?
A: The process is the very same as described in the netdev FAQ, so
please read up on it. The subject line must indicate whether the
patch is a fix or rather "next-like" content in order to let the
maintainers know whether it is targeted at bpf or bpf-next.
For fixes eventually landing in bpf -> net tree, the subject must
look like:
git format-patch --subject-prefix='PATCH bpf' start..finish
For features/improvements/etc that should eventually land in
bpf-next -> net-next, the subject must look like:
git format-patch --subject-prefix='PATCH bpf-next' start..finish
If unsure whether the patch or patch series should go into bpf
or net directly, or bpf-next or net-next directly, it is not a
problem either if the subject line says net or net-next as target.
It is eventually up to the maintainers to do the delegation of
the patches.
If it is clear that patches should go into bpf or bpf-next tree,
please make sure to rebase the patches against those trees in
order to reduce potential conflicts.
In case the patch or patch series has to be reworked and sent out
again in a second or later revision, it is also required to add a
version number (v2, v3, ...) into the subject prefix:
git format-patch --subject-prefix='PATCH net-next v2' start..finish
When changes have been requested to the patch series, always send the
whole patch series again with the feedback incorporated (never send
individual diffs on top of the old series).
Q: What does it mean when a patch gets applied to bpf or bpf-next tree?
A: It means that the patch looks good for mainline inclusion from
a BPF point of view.
Be aware that this is not a final verdict that the patch will
automatically get accepted into net or net-next trees eventually:
On the netdev kernel mailing list reviews can come in at any point
in time. If discussions around a patch conclude that they cannot
get included as-is, we will either apply a follow-up fix or drop
them from the trees entirely. Therefore, we also reserve to rebase
the trees when deemed necessary. After all, the purpose of the tree
is to i) accumulate and stage BPF patches for integration into trees
like net and net-next, and ii) run extensive BPF test suite and
workloads on the patches before they make their way any further.
Once the BPF pull request was accepted by David S. Miller, then
the patches end up in net or net-next tree, respectively, and
make their way from there further into mainline. Again, see the
netdev FAQ for additional information e.g. on how often they are
merged to mainline.
Q: How long do I need to wait for feedback on my BPF patches?
A: We try to keep the latency low. The usual time to feedback will
be around 2 or 3 business days. It may vary depending on the
complexity of changes and current patch load.
Q: How often do you send pull requests to major kernel trees like
net or net-next?
A: Pull requests will be sent out rather often in order to not
accumulate too many patches in bpf or bpf-next.
As a rule of thumb, expect pull requests for each tree regularly
at the end of the week. In some cases pull requests could additionally
come also in the middle of the week depending on the current patch
load or urgency.
Q: Are patches applied to bpf-next when the merge window is open?
A: For the time when the merge window is open, bpf-next will not be
processed. This is roughly analogous to net-next patch processing,
so feel free to read up on the netdev FAQ about further details.
During those two weeks of merge window, we might ask you to resend
your patch series once bpf-next is open again. Once Linus released
a v*-rc1 after the merge window, we continue processing of bpf-next.
For non-subscribers to kernel mailing lists, there is also a status
page run by David S. Miller on net-next that provides guidance:
http://vger.kernel.org/~davem/net-next.html
Q: I made a BPF verifier change, do I need to add test cases for
BPF kernel selftests?
A: If the patch has changes to the behavior of the verifier, then yes,
it is absolutely necessary to add test cases to the BPF kernel
selftests suite. If they are not present and we think they are
needed, then we might ask for them before accepting any changes.
In particular, test_verifier.c is tracking a high number of BPF test
cases, including a lot of corner cases that LLVM BPF back end may
generate out of the restricted C code. Thus, adding test cases is
absolutely crucial to make sure future changes do not accidentally
affect prior use-cases. Thus, treat those test cases as: verifier
behavior that is not tracked in test_verifier.c could potentially
be subject to change.
Q: When should I add code to samples/bpf/ and when to BPF kernel
selftests?
A: In general, we prefer additions to BPF kernel selftests rather than
samples/bpf/. The rationale is very simple: kernel selftests are
regularly run by various bots to test for kernel regressions.
The more test cases we add to BPF selftests, the better the coverage
and the less likely it is that those could accidentally break. It is
not that BPF kernel selftests cannot demo how a specific feature can
be used.
That said, samples/bpf/ may be a good place for people to get started,
so it might be advisable that simple demos of features could go into
samples/bpf/, but advanced functional and corner-case testing rather
into kernel selftests.
If your sample looks like a test case, then go for BPF kernel selftests
instead!
Q: When should I add code to the bpftool?
A: The main purpose of bpftool (under tools/bpf/bpftool/) is to provide
a central user space tool for debugging and introspection of BPF programs
and maps that are active in the kernel. If UAPI changes related to BPF
enable for dumping additional information of programs or maps, then
bpftool should be extended as well to support dumping them.
Q: When should I add code to iproute2's BPF loader?
A: For UAPI changes related to the XDP or tc layer (e.g. cls_bpf), the
convention is that those control-path related changes are added to
iproute2's BPF loader as well from user space side. This is not only
useful to have UAPI changes properly designed to be usable, but also
to make those changes available to a wider user base of major
downstream distributions.
Q: Do you accept patches as well for iproute2's BPF loader?
A: Patches for the iproute2's BPF loader have to be sent to:
netdev@vger.kernel.org
While those patches are not processed by the BPF kernel maintainers,
please keep them in Cc as well, so they can be reviewed.
The official git repository for iproute2 is run by Stephen Hemminger
and can be found at:
https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/
The patches need to have a subject prefix of '[PATCH iproute2 master]'
or '[PATCH iproute2 net-next]'. 'master' or 'net-next' describes the
target branch where the patch should be applied to. Meaning, if kernel
changes went into the net-next kernel tree, then the related iproute2
changes need to go into the iproute2 net-next branch, otherwise they
can be targeted at master branch. The iproute2 net-next branch will get
merged into the master branch after the current iproute2 version from
master has been released.
Like BPF, the patches end up in patchwork under the netdev project and
are delegated to 'shemminger' for further processing:
http://patchwork.ozlabs.org/project/netdev/list/?delegate=389
Q: What is the minimum requirement before I submit my BPF patches?
A: When submitting patches, always take the time and properly test your
patches *prior* to submission. Never rush them! If maintainers find
that your patches have not been properly tested, it is a good way to
get them grumpy. Testing patch submissions is a hard requirement!
Note, fixes that go to bpf tree *must* have a Fixes: tag included. The
same applies to fixes that target bpf-next, where the affected commit
is in net-next (or in some cases bpf-next). The Fixes: tag is crucial
in order to identify follow-up commits and tremendously helps for people
having to do backporting, so it is a must have!
We also don't accept patches with an empty commit message. Take your
time and properly write up a high quality commit message, it is
essential!
Think about it this way: other developers looking at your code a month
from now need to understand *why* a certain change has been done that
way, and whether there have been flaws in the analysis or assumptions
that the original author did. Thus providing a proper rationale and
describing the use-case for the changes is a must.
Patch submissions with >1 patch must have a cover letter which includes
a high level description of the series. This high level summary will
then be placed into the merge commit by the BPF maintainers such that
it is also accessible from the git log for future reference.
Q: What do I need to consider when adding a new instruction or feature
that would require BPF JIT and/or LLVM integration as well?
A: We try hard to keep all BPF JITs up to date such that the same user
experience can be guaranteed when running BPF programs on different
architectures without having the program punt to the less efficient
interpreter in case the in-kernel BPF JIT is enabled.
If you are unable to implement or test the required JIT changes for
certain architectures, please work together with the related BPF JIT
developers in order to get the feature implemented in a timely manner.
Please refer to the git log (arch/*/net/) to locate the necessary
people for helping out.
Also always make sure to add BPF test cases (e.g. test_bpf.c and
test_verifier.c) for new instructions, so that they can receive
broad test coverage and help run-time testing the various BPF JITs.
In case of new BPF instructions, once the changes have been accepted
into the Linux kernel, please implement support into LLVM's BPF back
end. See LLVM section below for further information.
Stable submission:
------------------
Q: I need a specific BPF commit in stable kernels. What should I do?
A: In case you need a specific fix in stable kernels, first check whether
the commit has already been applied in the related linux-*.y branches:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/
If not the case, then drop an email to the BPF maintainers with the
netdev kernel mailing list in Cc and ask for the fix to be queued up:
netdev@vger.kernel.org
The process in general is the same as on netdev itself, see also the
netdev FAQ document.
Q: Do you also backport to kernels not currently maintained as stable?
A: No. If you need a specific BPF commit in kernels that are currently not
maintained by the stable maintainers, then you are on your own.
The current stable and longterm stable kernels are all listed here:
https://www.kernel.org/
Q: The BPF patch I am about to submit needs to go to stable as well. What
should I do?
A: The same rules apply as with netdev patch submissions in general, see
netdev FAQ under:
Documentation/networking/netdev-FAQ.txt
Never add "Cc: stable@vger.kernel.org" to the patch description, but
ask the BPF maintainers to queue the patches instead. This can be done
with a note, for example, under the "---" part of the patch which does
not go into the git log. Alternatively, this can be done as a simple
request by mail instead.
Q: Where do I find currently queued BPF patches that will be submitted
to stable?
A: Once patches that fix critical bugs got applied into the bpf tree, they
are queued up for stable submission under:
http://patchwork.ozlabs.org/bundle/bpf/stable/?state=*
They will be on hold there at minimum until the related commit made its
way into the mainline kernel tree.
After having been under broader exposure, the queued patches will be
submitted by the BPF maintainers to the stable maintainers.
Testing patches:
----------------
Q: Which BPF kernel selftests version should I run my kernel against?
A: If you run a kernel xyz, then always run the BPF kernel selftests from
that kernel xyz as well. Do not expect that the BPF selftest from the
latest mainline tree will pass all the time.
In particular, test_bpf.c and test_verifier.c have a large number of
test cases and are constantly updated with new BPF test sequences, or
existing ones are adapted to verifier changes e.g. due to verifier
becoming smarter and being able to better track certain things.
LLVM:
-----
Q: Where do I find LLVM with BPF support?
A: The BPF back end for LLVM is upstream in LLVM since version 3.7.1.
All major distributions these days ship LLVM with BPF back end enabled,
so for the majority of use-cases it is not required to compile LLVM by
hand anymore, just install the distribution provided package.
LLVM's static compiler lists the supported targets through 'llc --version',
make sure BPF targets are listed. Example:
$ llc --version
LLVM (http://llvm.org/):
LLVM version 6.0.0svn
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: skylake
Registered Targets:
bpf - BPF (host endian)
bpfeb - BPF (big endian)
bpfel - BPF (little endian)
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
For developers in order to utilize the latest features added to LLVM's
BPF back end, it is advisable to run the latest LLVM releases. Support
for new BPF kernel features such as additions to the BPF instruction
set are often developed together.
All LLVM releases can be found at: http://releases.llvm.org/
Q: Got it, so how do I build LLVM manually anyway?
A: You need cmake and gcc-c++ as build requisites for LLVM. Once you have
that set up, proceed with building the latest LLVM and clang version
from the git repositories:
$ git clone http://llvm.org/git/llvm.git
$ cd llvm/tools
$ git clone --depth 1 http://llvm.org/git/clang.git
$ cd ..; mkdir build; cd build
$ cmake .. -DLLVM_TARGETS_TO_BUILD="BPF;X86" \
-DBUILD_SHARED_LIBS=OFF \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_BUILD_RUNTIME=OFF
$ make -j $(getconf _NPROCESSORS_ONLN)
The built binaries can then be found in the build/bin/ directory, where
you can point the PATH variable to.
Q: Should I notify BPF kernel maintainers about issues in LLVM's BPF code
generation back end or about LLVM generated code that the verifier
refuses to accept?
A: Yes, please do! LLVM's BPF back end is a key piece of the whole BPF
infrastructure and it ties deeply into verification of programs from the
kernel side. Therefore, any issues on either side need to be investigated
and fixed whenever necessary.
Therefore, please make sure to bring them up at netdev kernel mailing
list and Cc BPF maintainers for LLVM and kernel bits:
Yonghong Song <yhs@fb.com>
Alexei Starovoitov <ast@kernel.org>
Daniel Borkmann <daniel@iogearbox.net>
LLVM also has an issue tracker where BPF related bugs can be found:
https://bugs.llvm.org/buglist.cgi?quicksearch=bpf
However, it is better to reach out through mailing lists with having
maintainers in Cc.
Q: I have added a new BPF instruction to the kernel, how can I integrate
it into LLVM?
A: LLVM has a -mcpu selector for the BPF back end in order to allow the
selection of BPF instruction set extensions. By default the 'generic'
processor target is used, which is the base instruction set (v1) of BPF.
LLVM has an option to select -mcpu=probe where it will probe the host
kernel for supported BPF instruction set extensions and selects the
optimal set automatically.
For cross-compilation, a specific version can be select manually as well.
$ llc -march bpf -mcpu=help
Available CPUs for this target:
generic - Select the generic processor.
probe - Select the probe processor.
v1 - Select the v1 processor.
v2 - Select the v2 processor.
[...]
Newly added BPF instructions to the Linux kernel need to follow the same
scheme, bump the instruction set version and implement probing for the
extensions such that -mcpu=probe users can benefit from the optimization
transparently when upgrading their kernels.
If you are unable to implement support for the newly added BPF instruction
please reach out to BPF developers for help.
By the way, the BPF kernel selftests run with -mcpu=probe for better
test coverage.
Q: In some cases clang flag "-target bpf" is used but in other cases the
default clang target, which matches the underlying architecture, is used.
What is the difference and when I should use which?
A: Although LLVM IR generation and optimization try to stay architecture
independent, "-target <arch>" still has some impact on generated code:
- BPF program may recursively include header file(s) with file scope
inline assembly codes. The default target can handle this well,
while bpf target may fail if bpf backend assembler does not
understand these assembly codes, which is true in most cases.
- When compiled without -g, additional elf sections, e.g.,
.eh_frame and .rela.eh_frame, may be present in the object file
with default target, but not with bpf target.
- The default target may turn a C switch statement into a switch table
lookup and jump operation. Since the switch table is placed
in the global readonly section, the bpf program will fail to load.
The bpf target does not support switch table optimization.
The clang option "-fno-jump-tables" can be used to disable
switch table generation.
You should use default target when:
- Your program includes a header file, e.g., ptrace.h, which eventually
pulls in some header files containing file scope host assembly codes.
- You can add "-fno-jump-tables" to work around the switch table issue.
Otherwise, you can use bpf target.
Happy BPF hacking!

7
Documentation/cgroup-v1/cgroups.txt
View File

@ -523,12 +523,7 @@ Accessing a task's cgroup pointer may be done in the following ways:
Each subsystem should:
- add an entry in linux/cgroup_subsys.h
- define a cgroup_subsys object called <name>_subsys
If a subsystem can be compiled as a module, it should also have in its
module initcall a call to cgroup_load_subsys(), and in its exitcall a
call to cgroup_unload_subsys(). It should also set its_subsys.module =
THIS_MODULE in its .c file.
- define a cgroup_subsys object called <name>_cgrp_subsys
Each subsystem may export the following methods. The only mandatory
methods are css_alloc/free. Any others that are null are presumed to

4
Documentation/cgroup-v1/memory.txt
View File

@ -524,9 +524,9 @@ Note:
Only anonymous and swap cache memory is listed as part of 'rss' stat.
This should not be confused with the true 'resident set size' or the
amount of physical memory used by the cgroup.
'rss + file_mapped" will give you resident set size of cgroup.
'rss + mapped_file" will give you resident set size of cgroup.
(Note: file and shmem may be shared among other cgroups. In that case,
file_mapped is accounted only when the memory cgroup is owner of page
mapped_file is accounted only when the memory cgroup is owner of page
cache.)
5.3 swappiness

77
Documentation/cgroup-v2.txt
View File

@ -53,10 +53,14 @@ v1 is available under Documentation/cgroup-v1/.
5-3-2. Writeback
5-4. PID
5-4-1. PID Interface Files
5-5. RDMA
5-5-1. RDMA Interface Files
5-6. Misc
5-6-1. perf_event
5-5. Device
5-6. RDMA
5-6-1. RDMA Interface Files
5-7. Misc
5-7-1. perf_event
5-N. Non-normative information
5-N-1. CPU controller root cgroup process behaviour
5-N-2. IO controller root cgroup process behaviour
6. Namespace
6-1. Basics
6-2. The Root and Views
@ -279,7 +283,7 @@ thread mode, the following conditions must be met.
exempt from this requirement.
Topology-wise, a cgroup can be in an invalid state. Please consider
the following toplogy::
the following topology::
A (threaded domain) - B (threaded) - C (domain, just created)
@ -420,7 +424,9 @@ The root cgroup is exempt from this restriction. Root contains
processes and anonymous resource consumption which can't be associated
with any other cgroups and requires special treatment from most
controllers. How resource consumption in the root cgroup is governed
is up to each controller.
is up to each controller (for more information on this topic please
refer to the Non-normative information section in the Controllers
chapter).
Note that the restriction doesn't get in the way if there is no
enabled controller in the cgroup's "cgroup.subtree_control". This is
@ -1063,10 +1069,10 @@ PAGE_SIZE multiple when read back.
reached the limit and allocation was about to fail.
Depending on context result could be invocation of OOM
killer and retrying allocation or failing alloction.
killer and retrying allocation or failing allocation.
Failed allocation in its turn could be returned into
userspace as -ENOMEM or siletly ignored in cases like
userspace as -ENOMEM or silently ignored in cases like
disk readahead. For now OOM in memory cgroup kills
tasks iff shortage has happened inside page fault.
@ -1191,7 +1197,7 @@ PAGE_SIZE multiple when read back.
cgroups. The default is "max".
Swap usage hard limit. If a cgroup's swap usage reaches this
limit, anonymous meomry of the cgroup will not be swapped out.
limit, anonymous memory of the cgroup will not be swapped out.
Usage Guidelines
@ -1429,6 +1435,30 @@ through fork() or clone(). These will return -EAGAIN if the creation
of a new process would cause a cgroup policy to be violated.
Device controller
-----------------
Device controller manages access to device files. It includes both
creation of new device files (using mknod), and access to the
existing device files.
Cgroup v2 device controller has no interface files and is implemented
on top of cgroup BPF. To control access to device files, a user may
create bpf programs of the BPF_CGROUP_DEVICE type and attach them
to cgroups. On an attempt to access a device file, corresponding
BPF programs will be executed, and depending on the return value
the attempt will succeed or fail with -EPERM.
A BPF_CGROUP_DEVICE program takes a pointer to the bpf_cgroup_dev_ctx
structure, which describes the device access attempt: access type
(mknod/read/write) and device (type, major and minor numbers).
If the program returns 0, the attempt fails with -EPERM, otherwise
it succeeds.
An example of BPF_CGROUP_DEVICE program may be found in the kernel
source tree in the tools/testing/selftests/bpf/dev_cgroup.c file.
RDMA
----
@ -1481,6 +1511,35 @@ always be filtered by cgroup v2 path. The controller can still be
moved to a legacy hierarchy after v2 hierarchy is populated.
Non-normative information
-------------------------
This section contains information that isn't considered to be a part of
the stable kernel API and so is subject to change.
CPU controller root cgroup process behaviour
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When distributing CPU cycles in the root cgroup each thread in this
cgroup is treated as if it was hosted in a separate child cgroup of the
root cgroup. This child cgroup weight is dependent on its thread nice
level.
For details of this mapping see sched_prio_to_weight array in
kernel/sched/core.c file (values from this array should be scaled
appropriately so the neutral - nice 0 - value is 100 instead of 1024).
IO controller root cgroup process behaviour
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Root cgroup processes are hosted in an implicit leaf child node.
When distributing IO resources this implicit child node is taken into
account as if it was a normal child cgroup of the root cgroup with a
weight value of 200.
Namespace
=========

1
Documentation/conf.py
View File

@ -88,7 +88,6 @@ finally:
if makefile_version and makefile_patchlevel:
version = release = makefile_version + '.' + makefile_patchlevel
else:
sys.stderr.write('Warning: Could not extract kernel version\n')
version = release = "unknown version"
# The language for content autogenerated by Sphinx. Refer to documentation

20
Documentation/errseq.rst → Documentation/core-api/errseq.rst
View File

@ -1,5 +1,7 @@
=====================
The errseq_t datatype
=====================
An errseq_t is a way of recording errors in one place, and allowing any
number of "subscribers" to tell whether it has changed since a previous
point where it was sampled.
@ -21,12 +23,13 @@ a flag to tell whether the value has been sampled since a new value was
recorded. That allows us to avoid bumping the counter if no one has
sampled it since the last time an error was recorded.
Thus we end up with a value that looks something like this::
Thus we end up with a value that looks something like this:
bit: 31..13 12 11..0
+-----------------+----+----------------+
| counter | SF | errno |
+-----------------+----+----------------+
+--------------------------------------+----+------------------------+
| 31..13 | 12 | 11..0 |
+--------------------------------------+----+------------------------+
| counter | SF | errno |
+--------------------------------------+----+------------------------+
The general idea is for "watchers" to sample an errseq_t value and keep
it as a running cursor. That value can later be used to tell whether
@ -42,6 +45,7 @@ has ever been an error set since it was first initialized.
API usage
=========
Let me tell you a story about a worker drone. Now, he's a good worker
overall, but the company is a little...management heavy. He has to
report to 77 supervisors today, and tomorrow the "big boss" is coming in
@ -125,6 +129,7 @@ not usable by anyone else.
Serializing errseq_t cursor updates
===================================
Note that the errseq_t API does not protect the errseq_t cursor during a
check_and_advance_operation. Only the canonical error code is handled
atomically. In a situation where more than one task might be using the
@ -147,3 +152,8 @@ errseq_check_and_advance after taking the lock. e.g.::
That avoids the spinlock in the common case where nothing has changed
since the last time it was checked.
Functions
=========
.. kernel-doc:: lib/errseq.c

79
Documentation/core-api/idr.rst Normal file
View File

@ -0,0 +1,79 @@
.. SPDX-License-Identifier: CC-BY-SA-4.0
=============
ID Allocation
=============
:Author: Matthew Wilcox
Overview
========
A common problem to solve is allocating identifiers (IDs); generally
small numbers which identify a thing. Examples include file descriptors,
process IDs, packet identifiers in networking protocols, SCSI tags
and device instance numbers. The IDR and the IDA provide a reasonable
solution to the problem to avoid everybody inventing their own. The IDR
provides the ability to map an ID to a pointer, while the IDA provides
only ID allocation, and as a result is much more memory-efficient.
IDR usage
=========
Start by initialising an IDR, either with :c:func:`DEFINE_IDR`
for statically allocated IDRs or :c:func:`idr_init` for dynamically
allocated IDRs.
You can call :c:func:`idr_alloc` to allocate an unused ID. Look up
the pointer you associated with the ID by calling :c:func:`idr_find`
and free the ID by calling :c:func:`idr_remove`.
If you need to change the pointer associated with an ID, you can call
:c:func:`idr_replace`. One common reason to do this is to reserve an
ID by passing a ``NULL`` pointer to the allocation function; initialise the
object with the reserved ID and finally insert the initialised object
into the IDR.
Some users need to allocate IDs larger than ``INT_MAX``. So far all of
these users have been content with a ``UINT_MAX`` limit, and they use
:c:func:`idr_alloc_u32`. If you need IDs that will not fit in a u32,
we will work with you to address your needs.
If you need to allocate IDs sequentially, you can use
:c:func:`idr_alloc_cyclic`. The IDR becomes less efficient when dealing
with larger IDs, so using this function comes at a slight cost.
To perform an action on all pointers used by the IDR, you can
either use the callback-based :c:func:`idr_for_each` or the
iterator-style :c:func:`idr_for_each_entry`. You may need to use
:c:func:`idr_for_each_entry_continue` to continue an iteration. You can
also use :c:func:`idr_get_next` if the iterator doesn't fit your needs.
When you have finished using an IDR, you can call :c:func:`idr_destroy`
to release the memory used by the IDR. This will not free the objects
pointed to from the IDR; if you want to do that, use one of the iterators
to do it.
You can use :c:func:`idr_is_empty` to find out whether there are any
IDs currently allocated.
If you need to take a lock while allocating a new ID from the IDR,
you may need to pass a restrictive set of GFP flags, which can lead
to the IDR being unable to allocate memory. To work around this,
you can call :c:func:`idr_preload` before taking the lock, and then
:c:func:`idr_preload_end` after the allocation.
.. kernel-doc:: include/linux/idr.h
:doc: idr sync
IDA usage
=========
.. kernel-doc:: lib/idr.c
:doc: IDA description
Functions and structures
========================
.. kernel-doc:: include/linux/idr.h
.. kernel-doc:: lib/idr.c

4
Documentation/core-api/index.rst
View File

@ -14,13 +14,17 @@ Core utilities
kernel-api
assoc_array
atomic_ops
refcount-vs-atomic
cpu_hotplug
idr
local_ops
workqueue
genericirq
flexible-arrays
librs
genalloc
errseq
printk-formats
Interfaces for kernel debugging
===============================

27
Documentation/core-api/kernel-api.rst
View File

@ -103,18 +103,6 @@ CRC Functions
.. kernel-doc:: lib/crc-itu-t.c
:export:
idr/ida Functions
-----------------
.. kernel-doc:: include/linux/idr.h
:doc: idr sync
.. kernel-doc:: lib/idr.c
:doc: IDA description
.. kernel-doc:: lib/idr.c
:export:
Math Functions in Linux
=======================
@ -139,6 +127,21 @@ Division Functions
.. kernel-doc:: lib/gcd.c
:export:
Sorting
-------
.. kernel-doc:: lib/sort.c
:export:
.. kernel-doc:: lib/list_sort.c
:export:
UUID/GUID
---------
.. kernel-doc:: lib/uuid.c
:export:
Memory Management in Linux
==========================

261
Documentation/printk-formats.txt → Documentation/core-api/printk-formats.rst
View File

@ -5,6 +5,7 @@ How to get printk format specifiers right
:Author: Randy Dunlap <rdunlap@infradead.org>
:Author: Andrew Murray <amurray@mpc-data.co.uk>
Integer types
=============
@ -25,105 +26,101 @@ Integer types
s64 %lld or %llx
u64 %llu or %llx
If <type> is dependent on a config option for its size (e.g., ``sector_t``,
``blkcnt_t``) or is architecture-dependent for its size (e.g., ``tcflag_t``),
use a format specifier of its largest possible type and explicitly cast to it.
If <type> is dependent on a config option for its size (e.g., sector_t,
blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
format specifier of its largest possible type and explicitly cast to it.
Example::
printk("test: sector number/total blocks: %llu/%llu\n",
(unsigned long long)sector, (unsigned long long)blockcount);
Reminder: ``sizeof()`` result is of type ``size_t``.
Reminder: sizeof() returns type size_t.
The kernel's printf does not support ``%n``. For obvious reasons, floating
point formats (``%e, %f, %g, %a``) are also not recognized. Use of any
The kernel's printf does not support %n. Floating point formats (%e, %f,
%g, %a) are also not recognized, for obvious reasons. Use of any
unsupported specifier or length qualifier results in a WARN and early
return from vsnprintf.
return from vsnprintf().
Raw pointer value SHOULD be printed with %p. The kernel supports
the following extended format specifiers for pointer types:
Pointer Types
Pointer types
=============
Pointers printed without a specifier extension (i.e unadorned %p) are
hashed to give a unique identifier without leaking kernel addresses to user
space. On 64 bit machines the first 32 bits are zeroed. If you _really_
want the address see %px below.
A raw pointer value may be printed with %p which will hash the address
before printing. The kernel also supports extended specifiers for printing
pointers of different types.
Plain Pointers
--------------
::
%p abcdef12 or 00000000abcdef12
Pointers printed without a specifier extension (i.e unadorned %p) are
hashed to prevent leaking information about the kernel memory layout. This
has the added benefit of providing a unique identifier. On 64-bit machines
the first 32 bits are zeroed. If you *really* want the address see %px
below.
Symbols/Function Pointers
=========================
-------------------------
::
%pS versatile_init+0x0/0x110
%ps versatile_init
%pF versatile_init+0x0/0x110
%pf versatile_init
%pS versatile_init+0x0/0x110
%pSR versatile_init+0x9/0x110
(with __builtin_extract_return_addr() translation)
%ps versatile_init
%pB prev_fn_of_versatile_init+0x88/0x88
The ``F`` and ``f`` specifiers are for printing function pointers,
for example, f->func, &gettimeofday. They have the same result as
``S`` and ``s`` specifiers. But they do an extra conversion on
ia64, ppc64 and parisc64 architectures where the function pointers
are actually function descriptors.
The ``S`` and ``s`` specifiers can be used for printing symbols
from direct addresses, for example, __builtin_return_address(0),
(void *)regs->ip. They result in the symbol name with (``S``) or
without (``s``) offsets. If KALLSYMS are disabled then the symbol
address is printed instead.
The ``S`` and ``s`` specifiers are used for printing a pointer in symbolic
format. They result in the symbol name with (S) or without (s)
offsets. If KALLSYMS are disabled then the symbol address is printed instead.
Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
and thus deprecated. We have ``F`` and ``f`` because on ia64, ppc64 and
parisc64 function pointers are indirect and, in fact, are function
descriptors, which require additional dereferencing before we can lookup
the symbol. As of now, ``S`` and ``s`` perform dereferencing on those
platforms (when needed), so ``F`` and ``f`` exist for compatibility
reasons only.
The ``B`` specifier results in the symbol name with offsets and should be
used when printing stack backtraces. The specifier takes into
consideration the effect of compiler optimisations which may occur
when tail-call``s are used and marked with the noreturn GCC attribute.
Examples::
printk("Going to call: %pF\n", gettimeofday);
printk("Going to call: %pF\n", p->func);
printk("%s: called from %pS\n", __func__, (void *)_RET_IP_);
printk("%s: called from %pS\n", __func__,
(void *)__builtin_return_address(0));
printk("Faulted at %pS\n", (void *)regs->ip);
printk(" %s%pB\n", (reliable ? "" : "? "), (void *)*stack);
when tail-calls are used and marked with the noreturn GCC attribute.
Kernel Pointers
===============
---------------
::
%pK 01234567 or 0123456789abcdef
For printing kernel pointers which should be hidden from unprivileged
users. The behaviour of ``%pK`` depends on the ``kptr_restrict sysctl`` - see
users. The behaviour of %pK depends on the kptr_restrict sysctl - see
Documentation/sysctl/kernel.txt for more details.
Unmodified Addresses
====================
--------------------
::
%px 01234567 or 0123456789abcdef
For printing pointers when you _really_ want to print the address. Please
For printing pointers when you *really* want to print the address. Please
consider whether or not you are leaking sensitive information about the
Kernel layout in memory before printing pointers with %px. %px is
functionally equivalent to %lx. %px is preferred to %lx because it is more
uniquely grep'able. If, in the future, we need to modify the way the Kernel
handles printing pointers it will be nice to be able to find the call
sites.
kernel memory layout before printing pointers with %px. %px is functionally
equivalent to %lx (or %lu). %px is preferred because it is more uniquely
grep'able. If in the future we need to modify the way the kernel handles
printing pointers we will be better equipped to find the call sites.
Struct Resources
================
----------------
::
@ -133,32 +130,37 @@ Struct Resources
[mem 0x0000000060000000-0x000000006fffffff pref]
For printing struct resources. The ``R`` and ``r`` specifiers result in a
printed resource with (``R``) or without (``r``) a decoded flags member.
printed resource with (R) or without (r) a decoded flags member.
Passed by reference.
Physical addresses types ``phys_addr_t``
========================================
Physical address types phys_addr_t
----------------------------------
::
%pa[p] 0x01234567 or 0x0123456789abcdef
For printing a ``phys_addr_t`` type (and its derivatives, such as
``resource_size_t``) which can vary based on build options, regardless of
the width of the CPU data path. Passed by reference.
For printing a phys_addr_t type (and its derivatives, such as
resource_size_t) which can vary based on build options, regardless of the
width of the CPU data path.
DMA addresses types ``dma_addr_t``
==================================
Passed by reference.
DMA address types dma_addr_t
----------------------------
::
%pad 0x01234567 or 0x0123456789abcdef
For printing a ``dma_addr_t`` type which can vary based on build options,
regardless of the width of the CPU data path. Passed by reference.
For printing a dma_addr_t type which can vary based on build options,
regardless of the width of the CPU data path.
Passed by reference.
Raw buffer as an escaped string
===============================
-------------------------------
::
@ -168,8 +170,8 @@ For printing raw buffer as an escaped string. For the following buffer::
1b 62 20 5c 43 07 22 90 0d 5d
few examples show how the conversion would be done (the result string
without surrounding quotes)::
A few examples show how the conversion would be done (excluding surrounding
quotes)::
%*pE "\eb \C\a"\220\r]"
%*pEhp "\x1bb \C\x07"\x90\x0d]"
@ -179,23 +181,23 @@ The conversion rules are applied according to an optional combination
of flags (see :c:func:`string_escape_mem` kernel documentation for the
details):
- ``a`` - ESCAPE_ANY
- ``c`` - ESCAPE_SPECIAL
- ``h`` - ESCAPE_HEX
- ``n`` - ESCAPE_NULL
- ``o`` - ESCAPE_OCTAL
- ``p`` - ESCAPE_NP
- ``s`` - ESCAPE_SPACE
- a - ESCAPE_ANY
- c - ESCAPE_SPECIAL
- h - ESCAPE_HEX
- n - ESCAPE_NULL
- o - ESCAPE_OCTAL
- p - ESCAPE_NP
- s - ESCAPE_SPACE
By default ESCAPE_ANY_NP is used.
ESCAPE_ANY_NP is the sane choice for many cases, in particularly for
printing SSIDs.
If field width is omitted the 1 byte only will be escaped.
If field width is omitted then 1 byte only will be escaped.
Raw buffer as a hex string
==========================
--------------------------
::
@ -204,12 +206,12 @@ Raw buffer as a hex string
%*phD 00-01-02- ... -3f
%*phN 000102 ... 3f
For printing a small buffers (up to 64 bytes long) as a hex string with
certain separator. For the larger buffers consider to use
For printing small buffers (up to 64 bytes long) as a hex string with a
certain separator. For larger buffers consider using
:c:func:`print_hex_dump`.
MAC/FDDI addresses
==================
------------------
::
@ -220,11 +222,11 @@ MAC/FDDI addresses
%pmR 050403020100
For printing 6-byte MAC/FDDI addresses in hex notation. The ``M`` and ``m``
specifiers result in a printed address with (``M``) or without (``m``) byte
separators. The default byte separator is the colon (``:``).
specifiers result in a printed address with (M) or without (m) byte
separators. The default byte separator is the colon (:).
Where FDDI addresses are concerned the ``F`` specifier can be used after
the ``M`` specifier to use dash (``-``) separators instead of the default
the ``M`` specifier to use dash (-) separators instead of the default
separator.
For Bluetooth addresses the ``R`` specifier shall be used after the ``M``
@ -234,7 +236,7 @@ of Bluetooth addresses which are in the little endian order.
Passed by reference.
IPv4 addresses
==============
--------------
::
@ -243,8 +245,8 @@ IPv4 addresses
%p[Ii]4[hnbl]
For printing IPv4 dot-separated decimal addresses. The ``I4`` and ``i4``
specifiers result in a printed address with (``i4``) or without (``I4``)
leading zeros.
specifiers result in a printed address with (i4) or without (I4) leading
zeros.
The additional ``h``, ``n``, ``b``, and ``l`` specifiers are used to specify
host, network, big or little endian order addresses respectively. Where
@ -253,7 +255,7 @@ no specifier is provided the default network/big endian order is used.
Passed by reference.
IPv6 addresses
==============
--------------
::
@ -262,7 +264,7 @@ IPv6 addresses
%pI6c 1:2:3:4:5:6:7:8
For printing IPv6 network-order 16-bit hex addresses. The ``I6`` and ``i6``
specifiers result in a printed address with (``I6``) or without (``i6``)
specifiers result in a printed address with (I6) or without (i6)
colon-separators. Leading zeros are always used.
The additional ``c`` specifier can be used with the ``I`` specifier to
@ -272,7 +274,7 @@ http://tools.ietf.org/html/rfc5952
Passed by reference.
IPv4/IPv6 addresses (generic, with port, flowinfo, scope)
=========================================================
---------------------------------------------------------
::
@ -282,8 +284,8 @@ IPv4/IPv6 addresses (generic, with port, flowinfo, scope)
%pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345
%p[Ii]S[pfschnbl]
For printing an IP address without the need to distinguish whether it``s
of type AF_INET or AF_INET6, a pointer to a valid ``struct sockaddr``,
For printing an IP address without the need to distinguish whether it's of
type AF_INET or AF_INET6. A pointer to a valid struct sockaddr,
specified through ``IS`` or ``iS``, can be passed to this format specifier.
The additional ``p``, ``f``, and ``s`` specifiers are used to specify port
@ -309,7 +311,7 @@ Further examples::
%pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789
UUID/GUID addresses
===================
-------------------
::
@ -318,33 +320,33 @@ UUID/GUID addresses
%pUl 03020100-0504-0706-0809-0a0b0c0e0e0f
%pUL 03020100-0504-0706-0809-0A0B0C0E0E0F
For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L',
'b' and 'B' specifiers are used to specify a little endian order in
lower ('l') or upper case ('L') hex characters - and big endian order
in lower ('b') or upper case ('B') hex characters.
For printing 16-byte UUID/GUIDs addresses. The additional ``l``, ``L``,
``b`` and ``B`` specifiers are used to specify a little endian order in
lower (l) or upper case (L) hex notation - and big endian order in lower (b)
or upper case (B) hex notation.
Where no additional specifiers are used the default big endian
order with lower case hex characters will be printed.
order with lower case hex notation will be printed.
Passed by reference.
dentry names
============
------------
::
%pd{,2,3,4}
%pD{,2,3,4}
For printing dentry name; if we race with :c:func:`d_move`, the name might be
a mix of old and new ones, but it won't oops. ``%pd`` dentry is a safer
equivalent of ``%s`` ``dentry->d_name.name`` we used to use, ``%pd<n>`` prints
``n`` last components. ``%pD`` does the same thing for struct file.
For printing dentry name; if we race with :c:func:`d_move`, the name might
be a mix of old and new ones, but it won't oops. %pd dentry is a safer
equivalent of %s dentry->d_name.name we used to use, %pd<n> prints ``n``
last components. %pD does the same thing for struct file.
Passed by reference.
block_device names
==================
------------------
::
@ -353,7 +355,7 @@ block_device names
For printing name of block_device pointers.
struct va_format
================
----------------
::
@ -375,31 +377,27 @@ correctness of the format string and va_list arguments.
Passed by reference.
kobjects
========
--------
::
%pO
Base specifier for kobject based structs. Must be followed with
character for specific type of kobject as listed below:
Device tree nodes:
%pOF[fnpPcCF]
For printing device tree nodes. The optional arguments are:
f device node full_name
n device node name
p device node phandle
P device node path spec (name + @unit)
F device node flags
c major compatible string
C full compatible string
Without any arguments prints full_name (same as %pOFf)
The separator when using multiple arguments is ':'
Examples:
For printing kobject based structs (device nodes). Default behaviour is
equivalent to %pOFf.
- f - device node full_name
- n - device node name
- p - device node phandle
- P - device node path spec (name + @unit)
- F - device node flags
- c - major compatible string
- C - full compatible string
The separator when using multiple arguments is ':'
Examples::
%pOF /foo/bar@0 - Node full name
%pOFf /foo/bar@0 - Same as above
@ -412,11 +410,10 @@ kobjects
P - Populated
B - Populated bus
Passed by reference.
Passed by reference.
struct clk
==========
----------
::
@ -424,14 +421,14 @@ struct clk
%pCn pll1
%pCr 1560000000
For printing struct clk structures. ``%pC`` and ``%pCn`` print the name
For printing struct clk structures. %pC and %pCn print the name
(Common Clock Framework) or address (legacy clock framework) of the
structure; ``%pCr`` prints the current clock rate.
structure; %pCr prints the current clock rate.
Passed by reference.
bitmap and its derivatives such as cpumask and nodemask
=======================================================
-------------------------------------------------------
::
@ -439,13 +436,13 @@ bitmap and its derivatives such as cpumask and nodemask
%*pbl 0,3-6,8-10
For printing bitmap and its derivatives such as cpumask and nodemask,
``%*pb`` output the bitmap with field width as the number of bits and ``%*pbl``
%*pb outputs the bitmap with field width as the number of bits and %*pbl
output the bitmap as range list with field width as the number of bits.
Passed by reference.
Flags bitfields such as page flags, gfp_flags
=============================================
---------------------------------------------
::
@ -459,14 +456,14 @@ character. Currently supported are [p]age flags, [v]ma_flags (both
expect ``unsigned long *``) and [g]fp_flags (expects ``gfp_t *``). The flag
names and print order depends on the particular type.
Note that this format should not be used directly in :c:func:`TP_printk()` part
of a tracepoint. Instead, use the ``show_*_flags()`` functions from
<trace/events/mmflags.h>.
Note that this format should not be used directly in the
:c:func:`TP_printk()` part of a tracepoint. Instead, use the show_*_flags()
functions from <trace/events/mmflags.h>.
Passed by reference.
Network device features
=======================
-----------------------
::
@ -476,8 +473,10 @@ For printing netdev_features_t.
Passed by reference.
If you add other ``%p`` extensions, please extend lib/test_printf.c with
Thanks
======
If you add other %p extensions, please extend <lib/test_printf.c> with
one or more test cases, if at all feasible.
Thank you for your cooperation and attention.

150
Documentation/core-api/refcount-vs-atomic.rst Normal file
View File

@ -0,0 +1,150 @@
===================================
refcount_t API compared to atomic_t
===================================
.. contents:: :local:
Introduction
============
The goal of refcount_t API is to provide a minimal API for implementing
an object's reference counters. While a generic architecture-independent
implementation from lib/refcount.c uses atomic operations underneath,
there are a number of differences between some of the ``refcount_*()`` and
``atomic_*()`` functions with regards to the memory ordering guarantees.
This document outlines the differences and provides respective examples
in order to help maintainers validate their code against the change in
these memory ordering guarantees.
The terms used through this document try to follow the formal LKMM defined in
github.com/aparri/memory-model/blob/master/Documentation/explanation.txt
memory-barriers.txt and atomic_t.txt provide more background to the
memory ordering in general and for atomic operations specifically.
Relevant types of memory ordering
=================================
.. note:: The following section only covers some of the memory
ordering types that are relevant for the atomics and reference
counters and used through this document. For a much broader picture
please consult memory-barriers.txt document.
In the absence of any memory ordering guarantees (i.e. fully unordered)
atomics & refcounters only provide atomicity and
program order (po) relation (on the same CPU). It guarantees that
each ``atomic_*()`` and ``refcount_*()`` operation is atomic and instructions
are executed in program order on a single CPU.
This is implemented using :c:func:`READ_ONCE`/:c:func:`WRITE_ONCE` and
compare-and-swap primitives.
A strong (full) memory ordering guarantees that all prior loads and
stores (all po-earlier instructions) on the same CPU are completed
before any po-later instruction is executed on the same CPU.
It also guarantees that all po-earlier stores on the same CPU
and all propagated stores from other CPUs must propagate to all
other CPUs before any po-later instruction is executed on the original
CPU (A-cumulative property). This is implemented using :c:func:`smp_mb`.
A RELEASE memory ordering guarantees that all prior loads and
stores (all po-earlier instructions) on the same CPU are completed
before the operation. It also guarantees that all po-earlier
stores on the same CPU and all propagated stores from other CPUs
must propagate to all other CPUs before the release operation
(A-cumulative property). This is implemented using
:c:func:`smp_store_release`.
A control dependency (on success) for refcounters guarantees that
if a reference for an object was successfully obtained (reference
counter increment or addition happened, function returned true),
then further stores are ordered against this operation.
Control dependency on stores are not implemented using any explicit
barriers, but rely on CPU not to speculate on stores. This is only
a single CPU relation and provides no guarantees for other CPUs.
Comparison of functions
=======================
case 1) - non-"Read/Modify/Write" (RMW) ops
-------------------------------------------
Function changes:
* :c:func:`atomic_set` --> :c:func:`refcount_set`
* :c:func:`atomic_read` --> :c:func:`refcount_read`
Memory ordering guarantee changes:
* none (both fully unordered)
case 2) - increment-based ops that return no value
--------------------------------------------------
Function changes:
* :c:func:`atomic_inc` --> :c:func:`refcount_inc`
* :c:func:`atomic_add` --> :c:func:`refcount_add`
Memory ordering guarantee changes:
* none (both fully unordered)
case 3) - decrement-based RMW ops that return no value
------------------------------------------------------
Function changes:
* :c:func:`atomic_dec` --> :c:func:`refcount_dec`
Memory ordering guarantee changes:
* fully unordered --> RELEASE ordering
case 4) - increment-based RMW ops that return a value
-----------------------------------------------------
Function changes:
* :c:func:`atomic_inc_not_zero` --> :c:func:`refcount_inc_not_zero`
* no atomic counterpart --> :c:func:`refcount_add_not_zero`
Memory ordering guarantees changes:
* fully ordered --> control dependency on success for stores
.. note:: We really assume here that necessary ordering is provided as a
result of obtaining pointer to the object!
case 5) - decrement-based RMW ops that return a value
-----------------------------------------------------
Function changes:
* :c:func:`atomic_dec_and_test` --> :c:func:`refcount_dec_and_test`
* :c:func:`atomic_sub_and_test` --> :c:func:`refcount_sub_and_test`
* no atomic counterpart --> :c:func:`refcount_dec_if_one`
* ``atomic_add_unless(&var, -1, 1)`` --> ``refcount_dec_not_one(&var)``
Memory ordering guarantees changes:
* fully ordered --> RELEASE ordering + control dependency
.. note:: :c:func:`atomic_add_unless` only provides full order on success.
case 6) - lock-based RMW
------------------------
Function changes:
* :c:func:`atomic_dec_and_lock` --> :c:func:`refcount_dec_and_lock`
* :c:func:`atomic_dec_and_mutex_lock` --> :c:func:`refcount_dec_and_mutex_lock`
Memory ordering guarantees changes:
* fully ordered --> RELEASE ordering + control dependency + hold
:c:func:`spin_lock` on success

4
Documentation/cpu-freq/cpu-drivers.txt
View File

@ -291,3 +291,7 @@ For example:
/* Do something with pos */
pos->frequency = ...
}
If you need to work with the position of pos within driver_freq_table,
do not subtract the pointers, as it is quite costly. Instead, use the
macros cpufreq_for_each_entry_idx() and cpufreq_for_each_valid_entry_idx().

4
Documentation/device-mapper/cache-policies.txt
View File

@ -60,7 +60,7 @@ Memory usage:
The mq policy used a lot of memory; 88 bytes per cache block on a 64
bit machine.
smq uses 28bit indexes to implement it's data structures rather than
smq uses 28bit indexes to implement its data structures rather than
pointers. It avoids storing an explicit hit count for each block. It
has a 'hotspot' queue, rather than a pre-cache, which uses a quarter of
the entries (each hotspot block covers a larger area than a single
@ -84,7 +84,7 @@ resulting in better promotion/demotion decisions.
Adaptability:
The mq policy maintained a hit count for each cache block. For a
different block to get promoted to the cache it's hit count has to
different block to get promoted to the cache its hit count has to
exceed the lowest currently in the cache. This meant it could take a
long time for the cache to adapt between varying IO patterns.

9
Documentation/device-mapper/cache.txt
View File

@ -59,7 +59,7 @@ Fixed block size
The origin is divided up into blocks of a fixed size. This block size
is configurable when you first create the cache. Typically we've been
using block sizes of 256KB - 1024KB. The block size must be between 64
(32KB) and 2097152 (1GB) and a multiple of 64 (32KB).
sectors (32KB) and 2097152 sectors (1GB) and a multiple of 64 sectors (32KB).
Having a fixed block size simplifies the target a lot. But it is
something of a compromise. For instance, a small part of a block may be
@ -119,7 +119,7 @@ doing here to avoid migrating during those peak io moments.
For the time being, a message "migration_threshold <#sectors>"
can be used to set the maximum number of sectors being migrated,
the default being 204800 sectors (or 100MB).
the default being 2048 sectors (1MB).
Updating on-disk metadata
-------------------------
@ -143,11 +143,6 @@ the policy how big this chunk is, but it should be kept small. Like the
dirty flags this data is lost if there's a crash so a safe fallback
value should always be possible.
For instance, the 'mq' policy, which is currently the default policy,
uses this facility to store the hit count of the cache blocks. If
there's a crash this information will be lost, which means the cache
may be less efficient until those hit counts are regenerated.
Policy hints affect performance, not correctness.
Policy messaging

5
Documentation/device-mapper/dm-raid.txt
View File

@ -343,5 +343,8 @@ Version History
1.11.0 Fix table line argument order
(wrong raid10_copies/raid10_format sequence)
1.11.1 Add raid4/5/6 journal write-back support via journal_mode option
1.12.1 fix for MD deadlock between mddev_suspend() and md_write_start() available
1.12.1 Fix for MD deadlock between mddev_suspend() and md_write_start() available
1.13.0 Fix dev_health status at end of "recover" (was 'a', now 'A')
1.13.1 Fix deadlock caused by early md_stop_writes(). Also fix size an
state races.
1.13.2 Fix raid redundancy validation and avoid keeping raid set frozen

4
Documentation/device-mapper/snapshot.txt
View File

@ -49,6 +49,10 @@ The difference between persistent and transient is with transient
snapshots less metadata must be saved on disk - they can be kept in
memory by the kernel.
When loading or unloading the snapshot target, the corresponding
snapshot-origin or snapshot-merge target must be suspended. A failure to
suspend the origin target could result in data corruption.
* snapshot-merge <origin> <COW device> <persistent> <chunksize>

14
Documentation/device-mapper/thin-provisioning.txt
View File

@ -112,9 +112,11 @@ $low_water_mark is expressed in blocks of size $data_block_size. If
free space on the data device drops below this level then a dm event
will be triggered which a userspace daemon should catch allowing it to
extend the pool device. Only one such event will be sent.
Resuming a device with a new table itself triggers an event so the
userspace daemon can use this to detect a situation where a new table
already exceeds the threshold.
No special event is triggered if a just resumed device's free space is below
the low water mark. However, resuming a device always triggers an
event; a userspace daemon should verify that free space exceeds the low
water mark when handling this event.
A low water mark for the metadata device is maintained in the kernel and
will trigger a dm event if free space on the metadata device drops below
@ -274,7 +276,8 @@ ii) Status
<transaction id> <used metadata blocks>/<total metadata blocks>
<used data blocks>/<total data blocks> <held metadata root>
[no_]discard_passdown ro|rw
ro|rw|out_of_data_space [no_]discard_passdown [error|queue]_if_no_space
needs_check|-
transaction id:
A 64-bit number used by userspace to help synchronise with metadata
@ -394,3 +397,6 @@ ii) Status
If the pool has encountered device errors and failed, the status
will just contain the string 'Fail'. The userspace recovery
tools should then be used.
In the case where <nr mapped sectors> is 0, there is no highest
mapped sector and the value of <highest mapped sector> is unspecified.

124
Documentation/device-mapper/unstriped.txt Normal file
View File

@ -0,0 +1,124 @@
Introduction
============
The device-mapper "unstriped" target provides a transparent mechanism to
unstripe a device-mapper "striped" target to access the underlying disks
without having to touch the true backing block-device. It can also be
used to unstripe a hardware RAID-0 to access backing disks.
Parameters:
<number of stripes> <chunk size> <stripe #> <dev_path> <offset>
<number of stripes>
The number of stripes in the RAID 0.
<chunk size>
The amount of 512B sectors in the chunk striping.
<dev_path>
The block device you wish to unstripe.
<stripe #>
The stripe number within the device that corresponds to physical
drive you wish to unstripe. This must be 0 indexed.
Why use this module?
====================
An example of undoing an existing dm-stripe
-------------------------------------------
This small bash script will setup 4 loop devices and use the existing
striped target to combine the 4 devices into one. It then will use
the unstriped target ontop of the striped device to access the
individual backing loop devices. We write data to the newly exposed
unstriped devices and verify the data written matches the correct
underlying device on the striped array.
#!/bin/bash
MEMBER_SIZE=$((128 * 1024 * 1024))
NUM=4
SEQ_END=$((${NUM}-1))
CHUNK=256
BS=4096
RAID_SIZE=$((${MEMBER_SIZE}*${NUM}/512))
DM_PARMS="0 ${RAID_SIZE} striped ${NUM} ${CHUNK}"
COUNT=$((${MEMBER_SIZE} / ${BS}))
for i in $(seq 0 ${SEQ_END}); do
dd if=/dev/zero of=member-${i} bs=${MEMBER_SIZE} count=1 oflag=direct
losetup /dev/loop${i} member-${i}
DM_PARMS+=" /dev/loop${i} 0"
done
echo $DM_PARMS | dmsetup create raid0
for i in $(seq 0 ${SEQ_END}); do
echo "0 1 unstriped ${NUM} ${CHUNK} ${i} /dev/mapper/raid0 0" | dmsetup create set-${i}
done;
for i in $(seq 0 ${SEQ_END}); do
dd if=/dev/urandom of=/dev/mapper/set-${i} bs=${BS} count=${COUNT} oflag=direct
diff /dev/mapper/set-${i} member-${i}
done;
for i in $(seq 0 ${SEQ_END}); do
dmsetup remove set-${i}
done
dmsetup remove raid0
for i in $(seq 0 ${SEQ_END}); do
losetup -d /dev/loop${i}
rm -f member-${i}
done
Another example
---------------
Intel NVMe drives contain two cores on the physical device.
Each core of the drive has segregated access to its LBA range.
The current LBA model has a RAID 0 128k chunk on each core, resulting
in a 256k stripe across the two cores:
Core 0: Core 1:
__________ __________
| LBA 512| | LBA 768|
| LBA 0 | | LBA 256|
---------- ----------
The purpose of this unstriping is to provide better QoS in noisy
neighbor environments. When two partitions are created on the
aggregate drive without this unstriping, reads on one partition
can affect writes on another partition. This is because the partitions
are striped across the two cores. When we unstripe this hardware RAID 0
and make partitions on each new exposed device the two partitions are now
physically separated.
With the dm-unstriped target we're able to segregate an fio script that
has read and write jobs that are independent of each other. Compared to
when we run the test on a combined drive with partitions, we were able
to get a 92% reduction in read latency using this device mapper target.
Example dmsetup usage
=====================
unstriped ontop of Intel NVMe device that has 2 cores
-----------------------------------------------------
dmsetup create nvmset0 --table '0 512 unstriped 2 256 0 /dev/nvme0n1 0'
dmsetup create nvmset1 --table '0 512 unstriped 2 256 1 /dev/nvme0n1 0'
There will now be two devices that expose Intel NVMe core 0 and 1
respectively:
/dev/mapper/nvmset0
/dev/mapper/nvmset1
unstriped ontop of striped with 4 drives using 128K chunk size
--------------------------------------------------------------
dmsetup create raid_disk0 --table '0 512 unstriped 4 256 0 /dev/mapper/striped 0'
dmsetup create raid_disk1 --table '0 512 unstriped 4 256 1 /dev/mapper/striped 0'
dmsetup create raid_disk2 --table '0 512 unstriped 4 256 2 /dev/mapper/striped 0'
dmsetup create raid_disk3 --table '0 512 unstriped 4 256 3 /dev/mapper/striped 0'

16
Documentation/devicetree/bindings/arm/actions.txt
View File

@ -21,10 +21,26 @@ Boards:
Root node property compatible must contain, depending on board:
- Allo.com Sparky: "allo,sparky"
- Cubietech CubieBoard6: "cubietech,cubieboard6"
- LeMaker Guitar Base Board rev. B: "lemaker,guitar-bb-rev-b", "lemaker,guitar"
S700 SoC
========
Required root node properties:
- compatible : must contain "actions,s700"
Boards:
Root node property compatible must contain, depending on board:
- Cubietech CubieBoard7: "cubietech,cubieboard7"
S900 SoC
========

27
Documentation/devicetree/bindings/arm/arm-dsu-pmu.txt Normal file
View File

@ -0,0 +1,27 @@
* ARM DynamIQ Shared Unit (DSU) Performance Monitor Unit (PMU)
ARM DyanmIQ Shared Unit (DSU) integrates one or more CPU cores
with a shared L3 memory system, control logic and external interfaces to
form a multicore cluster. The PMU enables to gather various statistics on
the operations of the DSU. The PMU provides independent 32bit counters that
can count any of the supported events, along with a 64bit cycle counter.
The PMU is accessed via CPU system registers and has no MMIO component.
** DSU PMU required properties:
- compatible : should be one of :
"arm,dsu-pmu"
- interrupts : Exactly 1 SPI must be listed.
- cpus : List of phandles for the CPUs connected to this DSU instance.
** Example:
dsu-pmu-0 {
compatible = "arm,dsu-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>;
cpus = <&cpu_0>, <&cpu_1>;
};

32
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -90,38 +90,6 @@ System Timer (ST) required properties:
Its subnodes can be:
- watchdog: compatible should be "atmel,at91rm9200-wdt"
TC/TCLIB Timer required properties:
- compatible: Should be "atmel,<chip>-tcb".
<chip> can be "at91rm9200" or "at91sam9x5"
- reg: Should contain registers location and length
- interrupts: Should contain all interrupts for the TC block
Note that you can specify several interrupt cells if the TC
block has one interrupt per channel.
- clock-names: tuple listing input clock names.
Required elements: "t0_clk", "slow_clk"
Optional elements: "t1_clk", "t2_clk"
- clocks: phandles to input clocks.
Examples:
One interrupt per TC block:
tcb0: timer@fff7c000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfff7c000 0x100>;
interrupts = <18 4>;
clocks = <&tcb0_clk>;
clock-names = "t0_clk";
};
One interrupt per TC channel in a TC block:
tcb1: timer@fffdc000 {
compatible = "atmel,at91rm9200-tcb";
reg = <0xfffdc000 0x100>;
interrupts = <26 4 27 4 28 4>;
clocks = <&tcb1_clk>;
clock-names = "t0_clk";
};
RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc".
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"

9
Documentation/devicetree/bindings/arm/axentia.txt
View File

@ -10,6 +10,15 @@ compatible = "axentia,linea",
and following the rules from atmel-at91.txt for a sama5d31 SoC.
Nattis v2 board with Natte v2 power board
-----------------------------------------
Required root node properties:
compatible = "axentia,nattis-2", "axentia,natte-2", "axentia,linea",
"atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
and following the rules from above for the axentia,linea CPU module.
TSE-850 v3 board
----------------

22
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
View File

@ -17,21 +17,23 @@ Further, syscon nodes that map platform-specific registers used for general
system control is required:
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-cpu-biu-ctrl",
"brcm,brcmstb-cpu-biu-ctrl",
"syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
hif-cpubiuctrl node
cpu-biu-ctrl node
-------------------
SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit
(BIU) block which controls and interfaces the CPU complex to the different
Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block
offers a feature called Write Pairing which consists in collapsing two adjacent
cache lines into a single (bursted) write transaction towards the memory
controller (MEMC) to maximize write bandwidth.
SoCs with Broadcom Brahma15 ARM-based and Brahma53 ARM64-based CPUs have a
specific Bus Interface Unit (BIU) block which controls and interfaces the CPU
complex to the different Memory Controller Ports (MCP), one per memory
controller (MEMC). This BIU block offers a feature called Write Pairing which
consists in collapsing two adjacent cache lines into a single (bursted) write
transaction towards the memory controller (MEMC) to maximize write bandwidth.
Required properties:
- compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon"
- compatible: must be "brcm,bcm7445-cpu-biu-ctrl", "brcm,brcmstb-cpu-biu-ctrl", "syscon"
Optional properties:
@ -52,7 +54,7 @@ example:
};
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
compatible = "brcm,bcm7445-cpu-biu-ctrl", "brcm,brcmstb-cpu-biu-ctrl", "syscon";
reg = <0x3e2400 0x5b4>;
brcm,write-pairing;
};

1
Documentation/devicetree/bindings/arm/cpus.txt
View File

@ -169,6 +169,7 @@ described below.
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
"brcm,brahma-b53"
"brcm,vulcan"
"cavium,thunder"
"cavium,thunder2"

42
Documentation/devicetree/bindings/arm/firmware/sdei.txt Normal file
View File

@ -0,0 +1,42 @@
* Software Delegated Exception Interface (SDEI)
Firmware implementing the SDEI functions described in ARM document number
ARM DEN 0054A ("Software Delegated Exception Interface") can be used by
Linux to receive notification of events such as those generated by
firmware-first error handling, or from an IRQ that has been promoted to
a firmware-assisted NMI.
The interface provides a number of API functions for registering callbacks
and enabling/disabling events. Functions are invoked by trapping to the
privilege level of the SDEI firmware (specified as part of the binding
below) and passing arguments in a manner specified by the "SMC Calling
Convention (ARM DEN 0028B):
r0 => 32-bit Function ID / return value
{r1 - r3} => Parameters
Note that the immediate field of the trapping instruction must be set
to #0.
The SDEI_EVENT_REGISTER function registers a callback in the kernel
text to handle the specified event number.
The sdei node should be a child node of '/firmware' and have required
properties:
- compatible : should contain:
* "arm,sdei-1.0" : For implementations complying to SDEI version 1.x.
- method : The method of calling the SDEI firmware. Permitted
values are:
* "smc" : SMC #0, with the register assignments specified in this
binding.
* "hvc" : HVC #0, with the register assignments specified in this
binding.
Example:
firmware {
sdei {
compatible = "arm,sdei-1.0";
method = "smc";
};
};

1
Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
View File

@ -20,4 +20,5 @@ ethsys: clock-controller@1b000000 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b000000 0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};

6
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
View File

@ -55,7 +55,7 @@ Note: child nodes can be added for auto probing from device tree.
Example: adding device info in dtsi file
adc: adc@12D10000 {
adc: adc@12d10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>;
interrupts = <0 106 0>;
@ -71,7 +71,7 @@ adc: adc@12D10000 {
Example: adding device info in dtsi file for Exynos3250 with additional sclk
adc: adc@126C0000 {
adc: adc@126c0000 {
compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2;
reg = <0x126C0000 0x100>;
interrupts = <0 137 0>;
@ -87,7 +87,7 @@ adc: adc@126C0000 {
Example: Adding child nodes in dts file
adc@12D10000 {
adc@12d10000 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {

2
Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
View File

@ -72,7 +72,7 @@ Optional nodes:
- compatible: only "samsung,secure-firmware" is currently supported
- reg: address of non-secure SYSRAM used for communication with firmware
firmware@203F000 {
firmware@203f000 {
compatible = "samsung,secure-firmware";
reg = <0x0203F000 0x1000>;
};

4
Documentation/devicetree/bindings/arm/shmobile.txt
View File

@ -104,12 +104,16 @@ Boards:
compatible = "renesas,salvator-x", "renesas,r8a7796"
- Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S)
compatible = "renesas,salvator-xs", "renesas,r8a7795"
- Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012S)
compatible = "renesas,salvator-xs", "renesas,r8a7796"
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"
- SK-RZG1E (YR8A77450S000BE)
compatible = "renesas,sk-rzg1e", "renesas,r8a7745"
- SK-RZG1M (YR8A77430S000BE)
compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
- V3MSK
compatible = "renesas,v3msk", "renesas,r8a77970"
- Wheat
compatible = "renesas,wheat", "renesas,r8a7792"

9
Documentation/devicetree/bindings/arm/stm32.txt Normal file
View File

@ -0,0 +1,9 @@
STMicroelectronics STM32 Platforms Device Tree Bindings
Each device tree must specify which STM32 SoC it uses,
using one of the following compatible strings:
st,stm32f429
st,stm32f469
st,stm32f746
st,stm32h743

11
Documentation/devicetree/bindings/arm/technologic.txt
View File

@ -1,6 +1,11 @@
Technologic Systems Platforms Device Tree Bindings
--------------------------------------------------
TS-4600 is a System-on-Module based on the Freescale i.MX28 System-on-Chip.
It can be mounted on a carrier board providing additional peripheral connectors.
Required root node properties:
- compatible = "technologic,imx28-ts4600", "fsl,imx28"
TS-4800 board
Required root node properties:
- compatible = "technologic,imx51-ts4800", "fsl,imx51";
@ -10,3 +15,9 @@ It can be mounted on a carrier board providing additional peripheral connectors.
Required root node properties:
- compatible = "technologic,imx6dl-ts4900", "fsl,imx6dl"
- compatible = "technologic,imx6q-ts4900", "fsl,imx6q"
TS-7970 is a System-on-Module based on the Freescale i.MX6 System-on-Chip.
It can be mounted on a carrier board providing additional peripheral connectors.
Required root node properties:
- compatible = "technologic,imx6dl-ts7970", "fsl,imx6dl"
- compatible = "technologic,imx6q-ts7970", "fsl,imx6q"

37
Documentation/devicetree/bindings/bus/ti-sysc.txt
View File

@ -19,6 +19,7 @@ Required standard properties:
- compatible shall be one of the following generic types:
"ti,sysc"
"ti,sysc-omap2"
"ti,sysc-omap4"
"ti,sysc-omap4-simple"
@ -26,6 +27,8 @@ Required standard properties:
or one of the following derivative types for hardware
needing special workarounds:
"ti,sysc-omap2-timer"
"ti,sysc-omap4-timer"
"ti,sysc-omap3430-sr"
"ti,sysc-omap3630-sr"
"ti,sysc-omap4-sr"
@ -49,6 +52,26 @@ Required standard properties:
Optional properties:
- ti,sysc-mask shall contain mask of supported register bits for the
SYSCONFIG register as documented in the Technical Reference
Manual (TRM) for the interconnect target module
- ti,sysc-midle list of master idle modes supported by the interconnect
target module as documented in the TRM for SYSCONFIG
register MIDLEMODE bits
- ti,sysc-sidle list of slave idle modes supported by the interconnect
target module as documented in the TRM for SYSCONFIG
register SIDLEMODE bits
- ti,sysc-delay-us delay needed after OCP softreset before accssing
SYSCONFIG register again
- ti,syss-mask optional mask of reset done status bits as described in the
TRM for SYSSTATUS registers, typically 1 with some devices
having separate reset done bits for children like OHCI and
EHCI
- clocks clock specifier for each name in the clock-names as
specified in the binding documentation for ti-clkctrl,
typically available for all interconnect targets on TI SoCs
@ -61,6 +84,9 @@ Optional properties:
- ti,hwmods optional TI interconnect module name to use legacy
hwmod platform data
- ti,no-reset-on-init interconnect target module should not be reset at init
- ti,no-idle-on-init interconnect target module should not be idled at init
Example: Single instance of MUSB controller on omap4 using interconnect ranges
using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000):
@ -74,6 +100,17 @@ using offsets from l4_cfg second segment (0x4a000000 + 0x80000 = 0x4a0ab000):
reg-names = "rev", "sysc", "syss";
clocks = <&l3_init_clkctrl OMAP4_USB_OTG_HS_CLKCTRL 0>;
clock-names = "fck";
ti,sysc-mask = <(SYSC_OMAP2_ENAWAKEUP |
SYSC_OMAP2_SOFTRESET |
SYSC_OMAP2_AUTOIDLE)>;
ti,sysc-midle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>;
ti,sysc-sidle = <SYSC_IDLE_FORCE>,
<SYSC_IDLE_NO>,
<SYSC_IDLE_SMART>,
<SYSC_IDLE_SMART_WKUP>;
ti,syss-mask = <1>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x2b000 0x1000>;

15
Documentation/devicetree/bindings/chosen.txt
View File

@ -120,3 +120,18 @@ e.g.
While this property does not represent a real hardware, the address
and the size are expressed in #address-cells and #size-cells,
respectively, of the root node.
linux,initrd-start and linux,initrd-end
---------------------------------------
These properties hold the physical start and end address of an initrd that's
loaded by the bootloader. Note that linux,initrd-start is inclusive, but
linux,initrd-end is exclusive.
e.g.
/ {
chosen {
linux,initrd-start = <0x82000000>;
linux,initrd-end = <0x82800000>;
};
};

7
Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt
View File

@ -5,8 +5,11 @@ controllers within the SoC.
Required Properties:
- compatible: should be "amlogic,gxbb-clkc" for GXBB SoC,
or "amlogic,gxl-clkc" for GXL and GXM SoC.
- compatible: should be:
"amlogic,gxbb-clkc" for GXBB SoC,
"amlogic,gxl-clkc" for GXL and GXM SoC,
"amlogic,axg-clkc" for AXG SoC.
- reg: physical base address of the clock controller and length of memory
mapped region.

2
Documentation/devicetree/bindings/clock/exynos3250-clock.txt
View File

@ -32,7 +32,7 @@ Example 1: Examples of clock controller nodes are listed below.
#clock-cells = <1>;
};
cmu_dmc: clock-controller@105C0000 {
cmu_dmc: clock-controller@105c0000 {
compatible = "samsung,exynos3250-cmu-dmc";
reg = <0x105C0000 0x2000>;
#clock-cells = <1>;

2
Documentation/devicetree/bindings/clock/exynos5260-clock.txt
View File

@ -180,7 +180,7 @@ Example 2: UART controller node that consumes the clock generated by the
peri clock controller. Refer to the standard clock bindings for
information about 'clocks' and 'clock-names' property.
serial@12C00000 {
serial@12c00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 146 0>;

2
Documentation/devicetree/bindings/clock/exynos5410-clock.txt
View File

@ -41,7 +41,7 @@ Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
serial@12C20000 {
serial@12c20000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 51 0>;

2
Documentation/devicetree/bindings/clock/exynos5433-clock.txt
View File

@ -472,7 +472,7 @@ Example 2: Examples of clock controller nodes are listed below.
Example 3: UART controller node that consumes the clock generated by the clock
controller.
serial_0: serial@14C10000 {
serial_0: serial@14c10000 {
compatible = "samsung,exynos5433-uart";
reg = <0x14C10000 0x100>;
interrupts = <0 421 0>;

6
Documentation/devicetree/bindings/clock/hi3660-clock.txt
View File

@ -13,12 +13,18 @@ Required Properties:
- "hisilicon,hi3660-pmuctrl"
- "hisilicon,hi3660-sctrl"
- "hisilicon,hi3660-iomcu"
- "hisilicon,hi3660-stub-clk"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
Optional Properties:
- mboxes: Phandle to the mailbox for sending message to MCU.
(See: ../mailbox/hisilicon,hi3660-mailbox.txt for more info)
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.

22
Documentation/devicetree/bindings/clock/qcom,a53pll.txt Normal file
View File

@ -0,0 +1,22 @@
Qualcomm MSM8916 A53 PLL Binding
--------------------------------
The A53 PLL on MSM8916 platforms is the main CPU PLL used used for frequencies
above 1GHz.
Required properties :
- compatible : Shall contain only one of the following:
"qcom,msm8916-a53pll"
- reg : shall contain base register location and length
- #clock-cells : must be set to <0>
Example:
a53pll: clock@b016000 {
compatible = "qcom,msm8916-a53pll";
reg = <0xb016000 0x40>;
#clock-cells = <0>;
};

59
Documentation/devicetree/bindings/clock/qcom,spmi-clkdiv.txt Normal file
View File

@ -0,0 +1,59 @@
Qualcomm Technologies, Inc. SPMI PMIC clock divider (clkdiv)
clkdiv configures the clock frequency of a set of outputs on the PMIC.
These clocks are typically wired through alternate functions on
gpio pins.
=======================
Properties
=======================
- compatible
Usage: required
Value type: <string>
Definition: must be "qcom,spmi-clkdiv".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: base address of CLKDIV peripherals.
- qcom,num-clkdivs
Usage: required
Value type: <u32>
Definition: number of CLKDIV peripherals.
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: reference to the xo clock.
- clock-names:
Usage: required
Value type: <stringlist>
Definition: must be "xo".
- #clock-cells:
Usage: required
Value type: <u32>
Definition: shall contain 1.
=======
Example
=======
pm8998_clk_divs: clock-controller@5b00 {
compatible = "qcom,spmi-clkdiv";
reg = <0x5b00>;
#clock-cells = <1>;
qcom,num-clkdivs = <3>;
clocks = <&xo_board>;
clock-names = "xo";
assigned-clocks = <&pm8998_clk_divs 1>,
<&pm8998_clk_divs 2>,
<&pm8998_clk_divs 3>;
assigned-clock-rates = <9600000>,
<9600000>,
<9600000>;
};

1
Documentation/devicetree/bindings/clock/qoriq-clock.txt
View File

@ -78,6 +78,7 @@ second cell is the clock index for the specified type.
2 hwaccel index (n in CLKCGnHWACSR)
3 fman 0 for fm1, 1 for fm2
4 platform pll 0=pll, 1=pll/2, 2=pll/3, 3=pll/4
4=pll/5, 5=pll/6, 6=pll/7, 7=pll/8
5 coreclk must be 0
3. Example

1
Documentation/devicetree/bindings/clock/silabs,si5351.txt
View File

@ -49,6 +49,7 @@ Optional child node properties:
- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
divider.
- silabs,pll-master: boolean, multisynth can change pll frequency.
- silabs,pll-reset: boolean, clock output can reset its pll.
- silabs,disable-state : clock output disable state, shall be
0 = clock output is driven LOW when disabled
1 = clock output is driven HIGH when disabled

63
Documentation/devicetree/bindings/clock/sprd.txt Normal file
View File

@ -0,0 +1,63 @@
Spreadtrum Clock Binding
------------------------
Required properties:
- compatible: should contain the following compatible strings:
- "sprd,sc9860-pmu-gate"
- "sprd,sc9860-pll"
- "sprd,sc9860-ap-clk"
- "sprd,sc9860-aon-prediv"
- "sprd,sc9860-apahb-gate"
- "sprd,sc9860-aon-gate"
- "sprd,sc9860-aonsecure-clk"
- "sprd,sc9860-agcp-gate"
- "sprd,sc9860-gpu-clk"
- "sprd,sc9860-vsp-clk"
- "sprd,sc9860-vsp-gate"
- "sprd,sc9860-cam-clk"
- "sprd,sc9860-cam-gate"
- "sprd,sc9860-disp-clk"
- "sprd,sc9860-disp-gate"
- "sprd,sc9860-apapb-gate"
- #clock-cells: must be 1
- clocks : Should be the input parent clock(s) phandle for the clock, this
property here just simply shows which clock group the clocks'
parents are in, since each clk node would represent many clocks
which are defined in the driver. The detailed dependency
relationship (i.e. how many parents and which are the parents)
are implemented in driver code.
Optional properties:
- reg: Contain the registers base address and length. It must be configured
only if no 'sprd,syscon' under the node.
- sprd,syscon: phandle to the syscon which is in the same address area with
the clock, and so we can get regmap for the clocks from the
syscon device.
Example:
pmu_gate: pmu-gate {
compatible = "sprd,sc9860-pmu-gate";
sprd,syscon = <&pmu_regs>;
clocks = <&ext_26m>;
#clock-cells = <1>;
};
pll: pll {
compatible = "sprd,sc9860-pll";
sprd,syscon = <&ana_regs>;
clocks = <&pmu_gate 0>;
#clock-cells = <1>;
};
ap_clk: clock-controller@20000000 {
compatible = "sprd,sc9860-ap-clk";
reg = <0 0x20000000 0 0x400>;
clocks = <&ext_26m>, <&pll 0>,
<&pmu_gate 0>;
#clock-cells = <1>;
};

5
Documentation/devicetree/bindings/clock/sun8i-de2.txt
View File

@ -4,13 +4,14 @@ Allwinner Display Engine 2.0 Clock Control Binding
Required properties :
- compatible: must contain one of the following compatibles:
- "allwinner,sun8i-a83t-de2-clk"
- "allwinner,sun8i-h3-de2-clk"
- "allwinner,sun8i-v3s-de2-clk"
- "allwinner,sun50i-h5-de2-clk"
- reg: Must contain the registers base address and length
- clocks: phandle to the clocks feeding the display engine subsystem.
Three are needed:
- "mod": the display engine module clock
- "mod": the display engine module clock (on A83T it's the DE PLL)
- "bus": the bus clock for the whole display engine subsystem
- clock-names: Must contain the clock names described just above
- resets: phandle to the reset control for the display engine subsystem.
@ -19,7 +20,7 @@ Required properties :
Example:
de2_clocks: clock@1000000 {
compatible = "allwinner,sun8i-a83t-de2-clk";
compatible = "allwinner,sun8i-h3-de2-clk";
reg = <0x01000000 0x100000>;
clocks = <&ccu CLK_BUS_DE>,
<&ccu CLK_DE>;

22
Documentation/devicetree/bindings/crypto/arm-cryptocell.txt Normal file
View File

@ -0,0 +1,22 @@
Arm TrustZone CryptoCell cryptographic engine
Required properties:
- compatible: Should be "arm,cryptocell-712-ree".
- reg: Base physical address of the engine and length of memory mapped region.
- interrupts: Interrupt number for the device.
Optional properties:
- interrupt-parent: The phandle for the interrupt controller that services
interrupts for this device.
- clocks: Reference to the crypto engine clock.
- dma-coherent: Present if dma operations are coherent.
Examples:
arm_cc712: crypto@80000000 {
compatible = "arm,cryptocell-712-ree";
interrupt-parent = <&intc>;
interrupts = < 0 30 4 >;
reg = < 0x80000000 0x10000 >;
};

2
Documentation/devicetree/bindings/crypto/atmel-crypto.txt
View File

@ -75,7 +75,7 @@ Required properties:
- clock-frequency: must be present in the i2c controller node.
Example:
atecc508a@C0 {
atecc508a@c0 {
compatible = "atmel,atecc508a";
reg = <0xC0>;
};

3
Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
View File

@ -1,7 +1,8 @@
Inside Secure SafeXcel cryptographic engine
Required properties:
- compatible: Should be "inside-secure,safexcel-eip197".
- compatible: Should be "inside-secure,safexcel-eip197" or
"inside-secure,safexcel-eip97".
- reg: Base physical address of the engine and length of memory mapped region.
- interrupts: Interrupt numbers for the rings and engine.
- interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem".

4
Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
View File

@ -2,7 +2,9 @@ Exynos Pseudo Random Number Generator
Required properties:
- compatible : Should be "samsung,exynos4-rng".
- compatible : One of:
- "samsung,exynos4-rng" for Exynos4210 and Exynos4412
- "samsung,exynos5250-prng" for Exynos5250+
- reg : Specifies base physical address and size of the registers map.
- clocks : Phandle to clock-controller plus clock-specifier pair.
- clock-names : "secss" as a clock name.

19
Documentation/devicetree/bindings/crypto/st,stm32-cryp.txt Normal file
View File

@ -0,0 +1,19 @@
* STMicroelectronics STM32 CRYP
Required properties:
- compatible: Should be "st,stm32f756-cryp".
- reg: The address and length of the peripheral registers space
- clocks: The input clock of the CRYP instance
- interrupts: The CRYP interrupt
Optional properties:
- resets: The input reset of the CRYP instance
Example:
crypto@50060000 {
compatible = "st,stm32f756-cryp";
reg = <0x50060000 0x400>;
interrupts = <79>;
clocks = <&rcc 0 STM32F7_AHB2_CLOCK(CRYP)>;
resets = <&rcc STM32F7_AHB2_RESET(CRYP)>;
};

2
Documentation/devicetree/bindings/devfreq/event/exynos-nocp.txt
View File

@ -20,7 +20,7 @@ Optional properties:
Example : NoC Probe nodes in Device Tree are listed below.
nocp_mem0_0: nocp@10CA1000 {
nocp_mem0_0: nocp@10ca1000 {
compatible = "samsung,exynos5420-nocp";
reg = <0x10CA1000 0x200>;
};

4
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.txt
View File

@ -48,6 +48,10 @@ Required properties:
Documentation/devicetree/bindings/reset/reset.txt,
the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
Optional properties:
- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI
logic, as described in the file ../regulator/regulator.txt
Required nodes:
The connections to the HDMI ports are modeled using the OF graph

4
Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
View File

@ -64,6 +64,10 @@ Required properties:
- reg-names: should contain the names of the previous memory regions
- interrupts: should contain the VENC Vsync interrupt number
Optional properties:
- power-domains: Optional phandle to associated power domain as described in
the file ../power/power_domain.txt
Required nodes:
The connections to the VPU output video ports are modeled using the OF graph

2
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
View File

@ -54,7 +54,7 @@ Video interfaces:
Example:
dsi@11C80000 {
dsi@11c80000 {
compatible = "samsung,exynos4210-mipi-dsi";
reg = <0x11C80000 0x10000>;
interrupts = <0 79 0>;

25
Documentation/devicetree/bindings/display/ilitek,ili9225.txt Normal file
View File

@ -0,0 +1,25 @@
Ilitek ILI9225 display panels
This binding is for display panels using an Ilitek ILI9225 controller in SPI
mode.
Required properties:
- compatible: "vot,v220hf01a-t", "ilitek,ili9225"
- rs-gpios: Register select signal
- reset-gpios: Reset pin
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in ../spi/spi-bus.txt must be specified.
Optional properties:
- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
Example:
display@0{
compatible = "vot,v220hf01a-t", "ilitek,ili9225";
reg = <0>;
spi-max-frequency = <12000000>;
rs-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
rotation = <270>;
};

49
Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt Normal file
View File

@ -0,0 +1,49 @@
Ilitek ILI9322 TFT panel driver with SPI control bus
This is a driver for 320x240 TFT panels, accepting a variety of input
streams that get adapted and scaled to the panel. The panel output has
960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and
VCOMH outputs.
Required properties:
- compatible: "dlink,dir-685-panel", "ilitek,ili9322"
(full system-specific compatible is always required to look up configuration)
- reg: address of the panel on the SPI bus
Optional properties:
- vcc-supply: core voltage supply, see regulator/regulator.txt
- iovcc-supply: voltage supply for the interface input/output signals,
see regulator/regulator.txt
- vci-supply: voltage supply for analog parts, see regulator/regulator.txt
- reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
The following optional properties only apply to RGB and YUV input modes and
can be omitted for BT.656 input modes:
- pixelclk-active: see display/panel/display-timing.txt
- de-active: see display/panel/display-timing.txt
- hsync-active: see display/panel/display-timing.txt
- vsync-active: see display/panel/display-timing.txt
The panel must obey the rules for a SPI slave device as specified in
spi/spi-bus.txt
The device node can contain one 'port' child node with one child
'endpoint' node, according to the bindings defined in
media/video-interfaces.txt. This node should describe panel's video bus.
Example:
panel: display@0 {
compatible = "dlink,dir-685-panel", "ilitek,ili9322";
reg = <0>;
vcc-supply = <&vdisp>;
iovcc-supply = <&vdisp>;
vci-supply = <&vdisp>;
port {
panel_in: endpoint {
remote-endpoint = <&display_out>;
};
};
};

7
Documentation/devicetree/bindings/display/panel/mitsubishi,aa070mc01.txt Normal file
View File

@ -0,0 +1,7 @@
Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
Required properties:
- compatible: should be "mitsubishi,aa070mc01-ca1"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

10
Documentation/devicetree/bindings/display/panel/panel-common.txt
View File

@ -78,6 +78,16 @@ used for panels that implement compatible control signals.
while active. Active high reset signals can be supported by inverting the
GPIO specifier polarity flag.
Power
-----
- power-supply: display panels require power to be supplied. While several
panels need more than one power supply with panel-specific constraints
governing the order and timings of the power supplies, in many cases a single
power supply is sufficient, either because the panel has a single power rail,
or because all its power rails can be driven by the same supply. In that case
the power-supply property specifies the supply powering the panel as a phandle
to a regulator.
Backlight
---------

1
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
View File

@ -32,6 +32,7 @@ Optional properties:
- label: See panel-common.txt.
- gpios: See panel-common.txt.
- backlight: See panel-common.txt.
- power-supply: See panel-common.txt.
- data-mirror: If set, reverse the bit order described in the data mappings
below on all data lanes, transmitting bits for slots 6 to 0 instead of
0 to 6.

41
Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.txt Normal file
View File

@ -0,0 +1,41 @@
Solomon Goldentek Display GKTW70SDAE4SE LVDS Display Panel
==========================================================
The GKTW70SDAE4SE is a 7" WVGA TFT-LCD display panel.
These DT bindings follow the LVDS panel bindings defined in panel-lvds.txt
with the following device-specific properties.
Required properties:
- compatible: Shall contain "sgd,gktw70sdae4se" and "panel-lvds", in that order.
Example
-------
panel {
compatible = "sgd,gktw70sdae4se", "panel-lvds";
width-mm = <153>;
height-mm = <86>;
data-mapping = "jeida-18";
panel-timing {
clock-frequency = <32000000>;
hactive = <800>;
vactive = <480>;
hback-porch = <39>;
hfront-porch = <39>;
vback-porch = <29>;
vfront-porch = <13>;
hsync-len = <47>;
vsync-len = <2>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_encoder>;
};
};
};

2
Documentation/devicetree/bindings/display/panel/simple-panel.txt
View File

@ -1,7 +1,7 @@
Simple display panel
Required properties:
- power-supply: regulator to provide the supply voltage
- power-supply: See panel-common.txt
Optional properties:
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing

29
Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt Normal file
View File

@ -0,0 +1,29 @@
Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
Required properties:
- compatible: should be "tianma,tm070rvhg71"
- power-supply: single regulator to provide the supply voltage
- backlight: phandle of the backlight device attached to the panel
Required nodes:
- port: LVDS port mapping to connect this display
This panel needs single power supply voltage. Its backlight is conntrolled
via PWM signal.
Example:
--------
Example device-tree definition when connected to iMX6Q based board
panel: panel-lvds0 {
compatible = "tianma,tm070rvhg71";
backlight = <&backlight_lvds>;
power-supply = <&reg_lvds>;
port {
panel_in_lvds0: endpoint {
remote-endpoint = <&lvds0_out>;
};
};
};

2
Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
View File

@ -1,7 +1,7 @@
Toshiba 8.9" WXGA (1280x768) TFT LCD panel
Required properties:
- compatible: should be "toshiba,lt089ac29000.txt"
- compatible: should be "toshiba,lt089ac29000"
- power-supply: as specified in the base binding
This binding is compatible with the simple-panel binding, which is specified

4
Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt → Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
View File

@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
========================
Required properties:
- compatible: "toppoly,td028ttec1"
- compatible: "tpo,td028ttec1"
Optional properties:
- label: a symbolic name for the panel
@ -14,7 +14,7 @@ Example
-------
lcd-panel: td028ttec1@0 {
compatible = "toppoly,td028ttec1";
compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <100000>;
spi-cpol;

30
Documentation/devicetree/bindings/display/renesas,du.txt
View File

@ -3,6 +3,8 @@
Required Properties:
- compatible: must be one of the following.
- "renesas,du-r8a7743" for R8A7743 (RZ/G1M) compatible DU
- "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
@ -27,10 +29,10 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
- R8A779[0123456] use one functional clock per channel and one clock per
LVDS encoder (if available). The functional clocks must be named "du.x"
with "x" being the channel numerical index. The LVDS clocks must be
named "lvds.x" with "x" being the LVDS encoder numerical index.
- All other DU instances use one functional clock per channel and one
clock per LVDS encoder (if available). The functional clocks must be
named "du.x" with "x" being the channel numerical index. The LVDS clocks
must be named "lvds.x" with "x" being the LVDS encoder numerical index.
- In addition to the functional and encoder clocks, all DU versions also
support externally supplied pixel clocks. Those clocks are optional.
When supplied they must be named "dclkin.x" with "x" being the input
@ -49,16 +51,18 @@ bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
Port 0 Port1 Port2 Port3
Port0 Port1 Port2 Port3
-----------------------------------------------------------------------------
R8A7779 (H1) DPAD 0 DPAD 1 - -
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
R8A7791 (M2-W) DPAD LVDS 0 - -
R8A7792 (V2H) DPAD 0 DPAD 1 - -
R8A7793 (M2-N) DPAD LVDS 0 - -
R8A7794 (E2) DPAD 0 DPAD 1 - -
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
R8A7796 (M3-W) DPAD HDMI LVDS -
R8A7743 (RZ/G1M) DPAD 0 LVDS 0 - -
R8A7745 (RZ/G1E) DPAD 0 DPAD 1 - -
R8A7779 (R-Car H1) DPAD 0 DPAD 1 - -
R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1 -
R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 - -
R8A7792 (R-Car V2H) DPAD 0 DPAD 1 - -
R8A7793 (R-Car M2-N) DPAD 0 LVDS 0 - -
R8A7794 (R-Car E2) DPAD 0 DPAD 1 - -
R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
Example: R8A7795 (R-Car H3) ES2.0 DU

1
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
View File

@ -7,6 +7,7 @@ buffer to an external LCD interface.
Required properties:
- compatible: value should be one of the following
"rockchip,rk3036-vop";
"rockchip,rk3126-vop";
"rockchip,rk3288-vop";
"rockchip,rk3368-vop";
"rockchip,rk3366-vop";

4
Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt
View File

@ -15,6 +15,10 @@ Required properties:
"de_be1-lcd1"
"de_be0-lcd0-hdmi"
"de_be1-lcd1-hdmi"
"mixer0-lcd0"
"mixer0-lcd0-hdmi"
"mixer1-lcd1-hdmi"
"mixer1-lcd1-tve"
Example:

35
Documentation/devicetree/bindings/display/sitronix,st7735r.txt Normal file
View File

@ -0,0 +1,35 @@
Sitronix ST7735R display panels
This binding is for display panels using a Sitronix ST7735R controller in SPI
mode.
Required properties:
- compatible: "jianda,jd-t18003-t01", "sitronix,st7735r"
- dc-gpios: Display data/command selection (D/CX)
- reset-gpios: Reset signal (RSTX)
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in ../spi/spi-bus.txt must be specified.
Optional properties:
- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
- backlight: phandle of the backlight device attached to the panel
Example:
backlight: backlight {
compatible = "gpio-backlight";
gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
}
...
display@0{
compatible = "jianda,jd-t18003-t01", "sitronix,st7735r";
reg = <0>;
spi-max-frequency = <32000000>;
dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
rotation = <270>;
backlight = &backlight;
};

2
Documentation/devicetree/bindings/display/st,stih4xx.txt
View File

@ -119,7 +119,7 @@ Example:
/ {
...
vtg_main_slave: sti-vtg-main-slave@fe85A800 {
vtg_main_slave: sti-vtg-main-slave@fe85a800 {
compatible = "st,vtg";
reg = <0xfe85A800 0x300>;
interrupts = <GIC_SPI 175 IRQ_TYPE_NONE>;

6
Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
View File

@ -10,7 +10,11 @@
- "lcd" for the clock feeding the output pixel clock & IP clock.
- resets: reset to be used by the device (defined by use of RCC macro).
Required nodes:
- Video port for RGB output.
- Video port for DPI RGB output: ltdc has one video port with up to 2
endpoints:
- for external dpi rgb panel or bridge, using gpios.
- for internal dpi input of the MIPI DSI host controller.
Note: These 2 endpoints cannot be activated simultaneously.
* STMicroelectronics STM32 DSI controller specific extensions to Synopsys
DesignWare MIPI DSI host controller

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