Merge drm-next into drm-intel-next-queued (this time for real)
To pull in the HDCP changes, especially wait_for changes to drm/i915 that Chris wants to build on top of. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
This commit is contained in:
Joonas Lahtinen
Коммит
bba73071b6
|
|
@ -65,6 +65,11 @@ modules.builtin
|
|||
#
|
||||
/debian/
|
||||
|
||||
#
|
||||
# Snap directory (make snap-pkg)
|
||||
#
|
||||
/snap/
|
||||
|
||||
#
|
||||
# tar directory (make tar*-pkg)
|
||||
#
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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=]]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_spi_clk_freq
|
||||
KernelVersion: 4.14
|
||||
Contact: arnaud.pouliquen@st.com
|
||||
Description:
|
||||
For audio purpose only.
|
||||
Used by audio driver to set/get the spi input frequency.
|
||||
This is mandatory if DFSDM is slave on SPI bus, to
|
||||
provide information on the SPI clock frequency during runtime
|
||||
Notice that the SPI frequency should be a multiple of sample
|
||||
frequency to ensure the precision.
|
||||
if DFSDM input is SPI master
|
||||
Reading SPI clkout frequency,
|
||||
error on writing
|
||||
If DFSDM input is SPI Slave:
|
||||
Reading returns value previously set.
|
||||
Writing value before starting conversions.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -265,37 +265,5 @@ support other architectures, such as ARM, ARM64 etc.
|
|||
|
||||
=== Debugging ===
|
||||
|
||||
If you switch on CONFIG_IRQ_DOMAIN_DEBUG (which depends on
|
||||
CONFIG_IRQ_DOMAIN and CONFIG_DEBUG_FS), you will find a new file in
|
||||
your debugfs mount point, called irq_domain_mapping. This file
|
||||
contains a live snapshot of all the IRQ domains in the system:
|
||||
|
||||
name mapped linear-max direct-max devtree-node
|
||||
pl061 8 8 0 /smb/gpio@e0080000
|
||||
pl061 8 8 0 /smb/gpio@e1050000
|
||||
pMSI 0 0 0 /interrupt-controller@e1101000/v2m@e0080000
|
||||
MSI 37 0 0 /interrupt-controller@e1101000/v2m@e0080000
|
||||
GICv2m 37 0 0 /interrupt-controller@e1101000/v2m@e0080000
|
||||
GICv2 448 448 0 /interrupt-controller@e1101000
|
||||
|
||||
it also iterates over the interrupts to display their mapping in the
|
||||
domains, and makes the domain stacking visible:
|
||||
|
||||
|
||||
irq hwirq chip name chip data active type domain
|
||||
1 0x00019 GICv2 0xffff00000916bfd8 * LINEAR GICv2
|
||||
2 0x0001d GICv2 0xffff00000916bfd8 LINEAR GICv2
|
||||
3 0x0001e GICv2 0xffff00000916bfd8 * LINEAR GICv2
|
||||
4 0x0001b GICv2 0xffff00000916bfd8 * LINEAR GICv2
|
||||
5 0x0001a GICv2 0xffff00000916bfd8 LINEAR GICv2
|
||||
[...]
|
||||
96 0x81808 MSI 0x (null) RADIX MSI
|
||||
96+ 0x00063 GICv2m 0xffff8003ee116980 RADIX GICv2m
|
||||
96+ 0x00063 GICv2 0xffff00000916bfd8 LINEAR GICv2
|
||||
97 0x08800 MSI 0x (null) * RADIX MSI
|
||||
97+ 0x00064 GICv2m 0xffff8003ee116980 * RADIX GICv2m
|
||||
97+ 0x00064 GICv2 0xffff00000916bfd8 * LINEAR GICv2
|
||||
|
||||
Here, interrupts 1-5 are only using a single domain, while 96 and 97
|
||||
are build out of a stack of three domain, each level performing a
|
||||
particular function.
|
||||
Most of the internals of the IRQ subsystem are exposed in debugfs by
|
||||
turning CONFIG_GENERIC_IRQ_DEBUGFS on.
|
||||
|
|
|
|||
|
|
@ -1097,7 +1097,8 @@ will cause the CPU to disregard the values of its counters on
|
|||
its next exit from idle.
|
||||
Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
|
||||
cases where a given operation has resulted in a quiescent state
|
||||
for all flavors of RCU, for example, <tt>cond_resched_rcu_qs()</tt>.
|
||||
for all flavors of RCU, for example, <tt>cond_resched()</tt>
|
||||
when RCU has indicated a need for quiescent states.
|
||||
|
||||
<h5>RCU Callback Handling</h5>
|
||||
|
||||
|
|
@ -1182,8 +1183,8 @@ CPU (and from tracing) unless otherwise stated.
|
|||
Its fields are as follows:
|
||||
|
||||
<pre>
|
||||
1 int dynticks_nesting;
|
||||
2 int dynticks_nmi_nesting;
|
||||
1 long dynticks_nesting;
|
||||
2 long dynticks_nmi_nesting;
|
||||
3 atomic_t dynticks;
|
||||
4 bool rcu_need_heavy_qs;
|
||||
5 unsigned long rcu_qs_ctr;
|
||||
|
|
@ -1191,15 +1192,31 @@ Its fields are as follows:
|
|||
</pre>
|
||||
|
||||
<p>The <tt>->dynticks_nesting</tt> field counts the
|
||||
nesting depth of normal interrupts.
|
||||
In addition, this counter is incremented when exiting dyntick-idle
|
||||
mode and decremented when entering it.
|
||||
nesting depth of process execution, so that in normal circumstances
|
||||
this counter has value zero or one.
|
||||
NMIs, irqs, and tracers are counted by the <tt>->dynticks_nmi_nesting</tt>
|
||||
field.
|
||||
Because NMIs cannot be masked, changes to this variable have to be
|
||||
undertaken carefully using an algorithm provided by Andy Lutomirski.
|
||||
The initial transition from idle adds one, and nested transitions
|
||||
add two, so that a nesting level of five is represented by a
|
||||
<tt>->dynticks_nmi_nesting</tt> value of nine.
|
||||
This counter can therefore be thought of as counting the number
|
||||
of reasons why this CPU cannot be permitted to enter dyntick-idle
|
||||
mode, aside from non-maskable interrupts (NMIs).
|
||||
NMIs are counted by the <tt>->dynticks_nmi_nesting</tt>
|
||||
field, except that NMIs that interrupt non-dyntick-idle execution
|
||||
are not counted.
|
||||
mode, aside from process-level transitions.
|
||||
|
||||
<p>However, it turns out that when running in non-idle kernel context,
|
||||
the Linux kernel is fully capable of entering interrupt handlers that
|
||||
never exit and perhaps also vice versa.
|
||||
Therefore, whenever the <tt>->dynticks_nesting</tt> field is
|
||||
incremented up from zero, the <tt>->dynticks_nmi_nesting</tt> field
|
||||
is set to a large positive number, and whenever the
|
||||
<tt>->dynticks_nesting</tt> field is decremented down to zero,
|
||||
the the <tt>->dynticks_nmi_nesting</tt> field is set to zero.
|
||||
Assuming that the number of misnested interrupts is not sufficient
|
||||
to overflow the counter, this approach corrects the
|
||||
<tt>->dynticks_nmi_nesting</tt> field every time the corresponding
|
||||
CPU enters the idle loop from process context.
|
||||
|
||||
</p><p>The <tt>->dynticks</tt> field counts the corresponding
|
||||
CPU's transitions to and from dyntick-idle mode, so that this counter
|
||||
|
|
@ -1231,14 +1248,16 @@ in response.
|
|||
<tr><th> </th></tr>
|
||||
<tr><th align="left">Quick Quiz:</th></tr>
|
||||
<tr><td>
|
||||
Why not just count all NMIs?
|
||||
Wouldn't that be simpler and less error prone?
|
||||
Why not simply combine the <tt>->dynticks_nesting</tt>
|
||||
and <tt>->dynticks_nmi_nesting</tt> counters into a
|
||||
single counter that just counts the number of reasons that
|
||||
the corresponding CPU is non-idle?
|
||||
</td></tr>
|
||||
<tr><th align="left">Answer:</th></tr>
|
||||
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
||||
It seems simpler only until you think hard about how to go about
|
||||
updating the <tt>rcu_dynticks</tt> structure's
|
||||
<tt>->dynticks</tt> field.
|
||||
Because this would fail in the presence of interrupts whose
|
||||
handlers never return and of handlers that manage to return
|
||||
from a made-up interrupt.
|
||||
</font></td></tr>
|
||||
<tr><td> </td></tr>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -581,7 +581,8 @@ This guarantee was only partially premeditated.
|
|||
DYNIX/ptx used an explicit memory barrier for publication, but had nothing
|
||||
resembling <tt>rcu_dereference()</tt> for subscription, nor did it
|
||||
have anything resembling the <tt>smp_read_barrier_depends()</tt>
|
||||
that was later subsumed into <tt>rcu_dereference()</tt>.
|
||||
that was later subsumed into <tt>rcu_dereference()</tt> and later
|
||||
still into <tt>READ_ONCE()</tt>.
|
||||
The need for these operations made itself known quite suddenly at a
|
||||
late-1990s meeting with the DEC Alpha architects, back in the days when
|
||||
DEC was still a free-standing company.
|
||||
|
|
@ -2797,7 +2798,7 @@ RCU must avoid degrading real-time response for CPU-bound threads, whether
|
|||
executing in usermode (which is one use case for
|
||||
<tt>CONFIG_NO_HZ_FULL=y</tt>) or in the kernel.
|
||||
That said, CPU-bound loops in the kernel must execute
|
||||
<tt>cond_resched_rcu_qs()</tt> at least once per few tens of milliseconds
|
||||
<tt>cond_resched()</tt> at least once per few tens of milliseconds
|
||||
in order to avoid receiving an IPI from RCU.
|
||||
|
||||
<p>
|
||||
|
|
@ -3128,7 +3129,7 @@ The solution, in the form of
|
|||
is to have implicit
|
||||
read-side critical sections that are delimited by voluntary context
|
||||
switches, that is, calls to <tt>schedule()</tt>,
|
||||
<tt>cond_resched_rcu_qs()</tt>, and
|
||||
<tt>cond_resched()</tt>, and
|
||||
<tt>synchronize_rcu_tasks()</tt>.
|
||||
In addition, transitions to and from userspace execution also delimit
|
||||
tasks-RCU read-side critical sections.
|
||||
|
|
|
|||
|
|
@ -122,11 +122,7 @@ o Be very careful about comparing pointers obtained from
|
|||
Note that if checks for being within an RCU read-side
|
||||
critical section are not required and the pointer is never
|
||||
dereferenced, rcu_access_pointer() should be used in place
|
||||
of rcu_dereference(). The rcu_access_pointer() primitive
|
||||
does not require an enclosing read-side critical section,
|
||||
and also omits the smp_read_barrier_depends() included in
|
||||
rcu_dereference(), which in turn should provide a small
|
||||
performance gain in some CPUs (e.g., the DEC Alpha).
|
||||
of rcu_dereference().
|
||||
|
||||
o The comparison is against a pointer that references memory
|
||||
that was initialized "a long time ago." The reason
|
||||
|
|
|
|||
|
|
@ -23,12 +23,10 @@ o A CPU looping with preemption disabled. This condition can
|
|||
o A CPU looping with bottom halves disabled. This condition can
|
||||
result in RCU-sched and RCU-bh stalls.
|
||||
|
||||
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
|
||||
kernel without invoking schedule(). Note that cond_resched()
|
||||
does not necessarily prevent RCU CPU stall warnings. Therefore,
|
||||
if the looping in the kernel is really expected and desirable
|
||||
behavior, you might need to replace some of the cond_resched()
|
||||
calls with calls to cond_resched_rcu_qs().
|
||||
o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
|
||||
without invoking schedule(). If the looping in the kernel is
|
||||
really expected and desirable behavior, you might need to add
|
||||
some calls to cond_resched().
|
||||
|
||||
o Booting Linux using a console connection that is too slow to
|
||||
keep up with the boot-time console-message rate. For example,
|
||||
|
|
|
|||
|
|
@ -600,8 +600,7 @@ don't forget about them when submitting patches making use of RCU!]
|
|||
|
||||
#define rcu_dereference(p) \
|
||||
({ \
|
||||
typeof(p) _________p1 = p; \
|
||||
smp_read_barrier_depends(); \
|
||||
typeof(p) _________p1 = READ_ONCE(p); \
|
||||
(_________p1); \
|
||||
})
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -114,7 +114,6 @@
|
|||
This facility can be used to prevent such uncontrolled
|
||||
GPE floodings.
|
||||
Format: <int>
|
||||
Support masking of GPEs numbered from 0x00 to 0x7f.
|
||||
|
||||
acpi_no_auto_serialize [HW,ACPI]
|
||||
Disable auto-serialization of AML methods
|
||||
|
|
@ -223,7 +222,7 @@
|
|||
|
||||
acpi_sleep= [HW,ACPI] Sleep options
|
||||
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
|
||||
old_ordering, nonvs, sci_force_enable }
|
||||
old_ordering, nonvs, sci_force_enable, nobl }
|
||||
See Documentation/power/video.txt for information on
|
||||
s3_bios and s3_mode.
|
||||
s3_beep is for debugging; it makes the PC's speaker beep
|
||||
|
|
@ -239,6 +238,9 @@
|
|||
sci_force_enable causes the kernel to set SCI_EN directly
|
||||
on resume from S1/S3 (which is against the ACPI spec,
|
||||
but some broken systems don't work without it).
|
||||
nobl causes the internal blacklist of systems known to
|
||||
behave incorrectly in some ways with respect to system
|
||||
suspend and resume to be ignored (use wisely).
|
||||
|
||||
acpi_use_timer_override [HW,ACPI]
|
||||
Use timer override. For some broken Nvidia NF5 boards
|
||||
|
|
@ -644,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.
|
||||
|
|
@ -915,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
|
||||
|
|
@ -2050,9 +2069,6 @@
|
|||
This tests the locking primitive's ability to
|
||||
transition abruptly to and from idle.
|
||||
|
||||
locktorture.torture_runnable= [BOOT]
|
||||
Start locktorture running at boot time.
|
||||
|
||||
locktorture.torture_type= [KNL]
|
||||
Specify the locking implementation to test.
|
||||
|
||||
|
|
@ -2539,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
|
||||
|
|
@ -2742,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
|
||||
|
||||
|
|
@ -3486,9 +3503,6 @@
|
|||
the same as for rcuperf.nreaders.
|
||||
N, where N is the number of CPUs
|
||||
|
||||
rcuperf.perf_runnable= [BOOT]
|
||||
Start rcuperf running at boot time.
|
||||
|
||||
rcuperf.perf_type= [KNL]
|
||||
Specify the RCU implementation to test.
|
||||
|
||||
|
|
@ -3622,9 +3636,6 @@
|
|||
Test RCU's dyntick-idle handling. See also the
|
||||
rcutorture.shuffle_interval parameter.
|
||||
|
||||
rcutorture.torture_runnable= [BOOT]
|
||||
Start rcutorture running at boot time.
|
||||
|
||||
rcutorture.torture_type= [KNL]
|
||||
Specify the RCU implementation to test.
|
||||
|
||||
|
|
@ -3682,7 +3693,8 @@
|
|||
|
||||
rdt= [HW,X86,RDT]
|
||||
Turn on/off individual RDT features. List is:
|
||||
cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, mba.
|
||||
cmt, mbmtotal, mbmlocal, l3cat, l3cdp, l2cat, l2cdp,
|
||||
mba.
|
||||
E.g. to turn on cmt and turn off mba use:
|
||||
rdt=cmt,!mba
|
||||
|
||||
|
|
@ -3702,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]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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".
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|--------------------------------------------------|
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
=========
|
||||
|
||||
|
|
|
|||
|
|
@ -220,8 +220,7 @@ before it writes the new tail pointer, which will erase the item.
|
|||
|
||||
Note the use of READ_ONCE() and smp_load_acquire() to read the
|
||||
opposition index. This prevents the compiler from discarding and
|
||||
reloading its cached value - which some compilers will do across
|
||||
smp_read_barrier_depends(). This isn't strictly needed if you can
|
||||
reloading its cached value. This isn't strictly needed if you can
|
||||
be sure that the opposition index will _only_ be used the once.
|
||||
The smp_load_acquire() additionally forces the CPU to order against
|
||||
subsequent memory references. Similarly, smp_store_release() is used
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
===============================
|
||||
|
|
|
|||
|
|
@ -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
|
||||
==========================
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
@ -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().
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
@ -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
|
||||
========
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
----------------
|
||||
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -169,6 +169,7 @@ described below.
|
|||
"arm,cortex-r5"
|
||||
"arm,cortex-r7"
|
||||
"brcm,brahma-b15"
|
||||
"brcm,brahma-b53"
|
||||
"brcm,vulcan"
|
||||
"cavium,thunder"
|
||||
"cavium,thunder2"
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
};
|
||||
|
|
@ -14,3 +14,22 @@ following property before the previous one:
|
|||
Example:
|
||||
|
||||
compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
|
||||
|
||||
|
||||
Power management
|
||||
----------------
|
||||
|
||||
For power management (particularly DVFS and AVS), the North Bridge
|
||||
Power Management component is needed:
|
||||
|
||||
Required properties:
|
||||
- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
|
||||
- reg : the register start and length for the North Bridge
|
||||
Power Management
|
||||
|
||||
Example:
|
||||
|
||||
nb_pm: syscon@14000 {
|
||||
compatible = "marvell,armada-3700-nb-pm", "syscon";
|
||||
reg = <0x14000 0x60>;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -20,4 +20,5 @@ ethsys: clock-controller@1b000000 {
|
|||
compatible = "mediatek,mt2701-ethsys", "syscon";
|
||||
reg = <0 0x1b000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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 >;
|
||||
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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".
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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)>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,11 +1,16 @@
|
|||
THS8135 Video DAC
|
||||
-----------------
|
||||
THS8134 and THS8135 Video DAC
|
||||
-----------------------------
|
||||
|
||||
This is the binding for Texas Instruments THS8135 Video DAC bridge.
|
||||
This is the binding for Texas Instruments THS8134, THS8134A, THS8134B and
|
||||
THS8135 Video DAC bridges.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be "ti,ths8135"
|
||||
- compatible: Must be one of
|
||||
"ti,ths8134"
|
||||
"ti,ths8134a," "ti,ths8134"
|
||||
"ti,ths8134b", "ti,ths8134"
|
||||
"ti,ths8135"
|
||||
|
||||
Required nodes:
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ Video interfaces:
|
|||
|
||||
Example:
|
||||
|
||||
dsi@11C80000 {
|
||||
dsi@11c80000 {
|
||||
compatible = "samsung,exynos4210-mipi-dsi";
|
||||
reg = <0x11C80000 0x10000>;
|
||||
interrupts = <0 79 0>;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,31 @@
|
|||
ARM Versatile TFT Panels
|
||||
|
||||
These panels are connected to the daughterboards found on the
|
||||
ARM Versatile reference designs.
|
||||
|
||||
This device node must appear as a child to a "syscon"-compatible
|
||||
node.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "arm,versatile-tft-panel"
|
||||
|
||||
Required subnodes:
|
||||
- port: see display/panel/panel-common.txt, graph.txt
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
sysreg@0 {
|
||||
compatible = "arm,versatile-sysreg", "syscon", "simple-mfd";
|
||||
reg = <0x00000 0x1000>;
|
||||
|
||||
panel: display@0 {
|
||||
compatible = "arm,versatile-tft-panel";
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&foo>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -0,0 +1,74 @@
|
|||
Rockchip RK3399 specific extensions to the cdn Display Port
|
||||
================================
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "rockchip,rk3399-cdn-dp"
|
||||
|
||||
- reg: physical base address of the controller and length
|
||||
|
||||
- clocks: from common clock binding: handle to dp clock.
|
||||
|
||||
- clock-names: from common clock binding:
|
||||
Required elements: "core-clk" "pclk" "spdif" "grf"
|
||||
|
||||
- resets : a list of phandle + reset specifier pairs
|
||||
- reset-names : string of reset names
|
||||
Required elements: "apb", "core", "dptx", "spdif"
|
||||
- power-domains : power-domain property defined with a phandle
|
||||
to respective power domain.
|
||||
- assigned-clocks: main clock, should be <&cru SCLK_DP_CORE>
|
||||
- assigned-clock-rates : the DP core clk frequency, shall be: 100000000
|
||||
|
||||
- rockchip,grf: this soc should set GRF regs, so need get grf here.
|
||||
|
||||
- ports: contain a port nodes with endpoint definitions as defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
contained 2 endpoints, connecting to the output of vop.
|
||||
|
||||
- phys: from general PHY binding: the phandle for the PHY device.
|
||||
|
||||
- extcon: extcon specifier for the Power Delivery
|
||||
|
||||
- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
|
||||
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Example:
|
||||
cdn_dp: dp@fec00000 {
|
||||
compatible = "rockchip,rk3399-cdn-dp";
|
||||
reg = <0x0 0xfec00000 0x0 0x100000>;
|
||||
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_DP_CORE>, <&cru PCLK_DP_CTRL>,
|
||||
<&cru SCLK_SPDIF_REC_DPTX>, <&cru PCLK_VIO_GRF>;
|
||||
clock-names = "core-clk", "pclk", "spdif", "grf";
|
||||
assigned-clocks = <&cru SCLK_DP_CORE>;
|
||||
assigned-clock-rates = <100000000>;
|
||||
power-domains = <&power RK3399_PD_HDCP>;
|
||||
phys = <&tcphy0_dp>, <&tcphy1_dp>;
|
||||
resets = <&cru SRST_DPTX_SPDIF_REC>;
|
||||
reset-names = "spdif";
|
||||
extcon = <&fusb0>, <&fusb1>;
|
||||
rockchip,grf = <&grf>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
#sound-dai-cells = <1>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
dp_in: port {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
dp_in_vopb: endpoint@0 {
|
||||
reg = <0>;
|
||||
remote-endpoint = <&vopb_out_dp>;
|
||||
};
|
||||
|
||||
dp_in_vopl: endpoint@1 {
|
||||
reg = <1>;
|
||||
remote-endpoint = <&vopl_out_dp>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ Example 2: DSI panel
|
|||
compatible = "st,stm32-dsi";
|
||||
reg = <0x40016c00 0x800>;
|
||||
clocks = <&rcc 1 CLK_F469_DSI>, <&clk_hse>;
|
||||
clock-names = "ref", "pclk";
|
||||
clock-names = "pclk", "ref";
|
||||
resets = <&rcc STM32F4_APB2_RESET(DSI)>;
|
||||
reset-names = "apb";
|
||||
|
||||
|
|
|
|||
|
|
@ -64,6 +64,52 @@ Required properties:
|
|||
first port should be the input endpoint. The second should be the
|
||||
output, usually to an HDMI connector.
|
||||
|
||||
DWC HDMI TX Encoder
|
||||
-------------------
|
||||
|
||||
The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
|
||||
with Allwinner's own PHY IP. It supports audio and video outputs and CEC.
|
||||
|
||||
These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
|
||||
Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
|
||||
following device-specific properties.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: value must be one of:
|
||||
* "allwinner,sun8i-a83t-dw-hdmi"
|
||||
- reg: base address and size of memory-mapped region
|
||||
- reg-io-width: See dw_hdmi.txt. Shall be 1.
|
||||
- interrupts: HDMI interrupt number
|
||||
- clocks: phandles to the clocks feeding the HDMI encoder
|
||||
* iahb: the HDMI bus clock
|
||||
* isfr: the HDMI register clock
|
||||
* tmds: TMDS clock
|
||||
- clock-names: the clock names mentioned above
|
||||
- resets: phandle to the reset controller
|
||||
- reset-names: must be "ctrl"
|
||||
- phys: phandle to the DWC HDMI PHY
|
||||
- phy-names: must be "phy"
|
||||
|
||||
- ports: A ports node with endpoint definitions as defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt. The
|
||||
first port should be the input endpoint. The second should be the
|
||||
output, usually to an HDMI connector.
|
||||
|
||||
DWC HDMI PHY
|
||||
------------
|
||||
|
||||
Required properties:
|
||||
- compatible: value must be one of:
|
||||
* allwinner,sun8i-a83t-hdmi-phy
|
||||
- reg: base address and size of memory-mapped region
|
||||
- clocks: phandles to the clocks feeding the HDMI PHY
|
||||
* bus: the HDMI PHY interface clock
|
||||
* mod: the HDMI PHY module clock
|
||||
- clock-names: the clock names mentioned above
|
||||
- resets: phandle to the reset controller driving the PHY
|
||||
- reset-names: must be "phy"
|
||||
|
||||
TV Encoder
|
||||
----------
|
||||
|
||||
|
|
@ -94,24 +140,26 @@ Required properties:
|
|||
* allwinner,sun7i-a20-tcon
|
||||
* allwinner,sun8i-a33-tcon
|
||||
* allwinner,sun8i-a83t-tcon-lcd
|
||||
* allwinner,sun8i-a83t-tcon-tv
|
||||
* allwinner,sun8i-v3s-tcon
|
||||
- reg: base address and size of memory-mapped region
|
||||
- interrupts: interrupt associated to this IP
|
||||
- clocks: phandles to the clocks feeding the TCON. Three are needed:
|
||||
- clocks: phandles to the clocks feeding the TCON.
|
||||
- 'ahb': the interface clocks
|
||||
- 'tcon-ch0': The clock driving the TCON channel 0
|
||||
- 'tcon-ch0': The clock driving the TCON channel 0, except for A83T TV TCON
|
||||
- resets: phandles to the reset controllers driving the encoder
|
||||
- "lcd": the reset line for the TCON channel 0
|
||||
|
||||
- clock-names: the clock names mentioned above
|
||||
- reset-names: the reset names mentioned above
|
||||
- clock-output-names: Name of the pixel clock created
|
||||
- clock-output-names: Name of the pixel clock created, if TCON supports
|
||||
channel 0.
|
||||
|
||||
- ports: A ports node with endpoint definitions as defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt. The
|
||||
first port should be the input endpoint, the second one the output
|
||||
|
||||
The output may have multiple endpoints. The TCON has two channels,
|
||||
The output may have multiple endpoints. TCON can have 1 or 2 channels,
|
||||
usually with the first channel being used for the panels interfaces
|
||||
(RGB, LVDS, etc.), and the second being used for the outputs that
|
||||
require another controller (TV Encoder, HDMI, etc.). The endpoints
|
||||
|
|
@ -122,8 +170,8 @@ Required properties:
|
|||
On SoCs other than the A33 and V3s, there is one more clock required:
|
||||
- 'tcon-ch1': The clock driving the TCON channel 1
|
||||
|
||||
On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you
|
||||
need one more reset line:
|
||||
When TCON support LVDS (all TCONs except TV TCON on A83T and those found
|
||||
in A13, H3, H5 and V3s SoCs), you need one more reset line:
|
||||
- 'lvds': The reset line driving the LVDS logic
|
||||
|
||||
And on the A23, A31, A31s and A33, you need one more clock line:
|
||||
|
|
@ -226,6 +274,7 @@ supported.
|
|||
Required properties:
|
||||
- compatible: value must be one of:
|
||||
* allwinner,sun8i-a83t-de2-mixer-0
|
||||
* allwinner,sun8i-a83t-de2-mixer-1
|
||||
* allwinner,sun8i-v3s-de2-mixer
|
||||
- reg: base address and size of the memory-mapped region.
|
||||
- clocks: phandles to the clocks feeding the mixer
|
||||
|
|
|
|||
|
|
@ -47,8 +47,8 @@ When the OS is not in control of the management interface (i.e. it's a guest),
|
|||
the channel nodes appear on their own, not under a management node.
|
||||
|
||||
Required properties:
|
||||
- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
|
||||
for MSI capable HW.
|
||||
- compatible: must contain "qcom,hidma-1.0" for initial HW or
|
||||
"qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
|
||||
- reg: Addresses for the transfer and event channel
|
||||
- interrupts: Should contain the event interrupt
|
||||
- desc-count: Number of asynchronous requests this channel can handle
|
||||
|
|
|
|||
|
|
@ -64,6 +64,6 @@ Example:
|
|||
reg = <0xe0000000 0x1000>;
|
||||
interrupts = <0 35 0x4>;
|
||||
dmas = <&dmahost 12 0 1>,
|
||||
<&dmahost 13 0 1 0>;
|
||||
<&dmahost 13 1 0>;
|
||||
dma-names = "rx", "rx";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Optional properties:
|
|||
|
||||
Example:
|
||||
|
||||
dma: dma-controller@801C0000 {
|
||||
dma: dma-controller@801c0000 {
|
||||
compatible = "stericsson,db8500-dma40", "stericsson,dma40";
|
||||
reg = <0x801C0000 0x1000 0x40010000 0x800>;
|
||||
reg-names = "base", "lcpa";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,78 @@
|
|||
EEPROMs (I2C)
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be a "<manufacturer>,<model>" pair. The following <model>
|
||||
values are supported (assuming "atmel" as manufacturer):
|
||||
|
||||
"atmel,24c00",
|
||||
"atmel,24c01",
|
||||
"atmel,24cs01",
|
||||
"atmel,24c02",
|
||||
"atmel,24cs02",
|
||||
"atmel,24mac402",
|
||||
"atmel,24mac602",
|
||||
"atmel,spd",
|
||||
"atmel,24c04",
|
||||
"atmel,24cs04",
|
||||
"atmel,24c08",
|
||||
"atmel,24cs08",
|
||||
"atmel,24c16",
|
||||
"atmel,24cs16",
|
||||
"atmel,24c32",
|
||||
"atmel,24cs32",
|
||||
"atmel,24c64",
|
||||
"atmel,24cs64",
|
||||
"atmel,24c128",
|
||||
"atmel,24c256",
|
||||
"atmel,24c512",
|
||||
"atmel,24c1024",
|
||||
|
||||
If <manufacturer> is not "atmel", then a fallback must be used
|
||||
with the same <model> and "atmel" as manufacturer.
|
||||
|
||||
Example:
|
||||
compatible = "microchip,24c128", "atmel,24c128";
|
||||
|
||||
Supported manufacturers are:
|
||||
|
||||
"catalyst",
|
||||
"microchip",
|
||||
"ramtron",
|
||||
"renesas",
|
||||
"nxp",
|
||||
"st",
|
||||
|
||||
Some vendors use different model names for chips which are just
|
||||
variants of the above. Known such exceptions are listed below:
|
||||
|
||||
"renesas,r1ex24002" - the fallback is "atmel,24c02"
|
||||
|
||||
- reg: The I2C address of the EEPROM.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- pagesize: The length of the pagesize for writing. Please consult the
|
||||
manual of your device, that value varies a lot. A wrong value
|
||||
may result in data loss! If not specified, a safety value of
|
||||
'1' is used which will be very slow.
|
||||
|
||||
- read-only: This parameterless property disables writes to the eeprom.
|
||||
|
||||
- size: Total eeprom size in bytes.
|
||||
|
||||
- no-read-rollover: This parameterless property indicates that the
|
||||
multi-address eeprom does not automatically roll over
|
||||
reads to the next slave address. Please consult the
|
||||
manual of your device.
|
||||
|
||||
- wp-gpios: GPIO to which the write-protect pin of the chip is connected.
|
||||
|
||||
Example:
|
||||
|
||||
eeprom@52 {
|
||||
compatible = "atmel,24c32";
|
||||
reg = <0x52>;
|
||||
pagesize = <32>;
|
||||
wp-gpios = <&gpio1 3 0>;
|
||||
};
|
||||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче