Merge branch 'linus' into sched/urgent, to resolve conflicts
Conflicts: arch/arm64/kernel/entry.S arch/x86/Kconfig include/linux/sched/mm.h kernel/fork.c Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
Коммит
8284507916
|
|
@ -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,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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -646,6 +646,20 @@
|
|||
console=brl,ttyS0
|
||||
For now, only VisioBraille is supported.
|
||||
|
||||
console_msg_format=
|
||||
[KNL] Change console messages format
|
||||
default
|
||||
By default we print messages on consoles in
|
||||
"[time stamp] text\n" format (time stamp may not be
|
||||
printed, depending on CONFIG_PRINTK_TIME or
|
||||
`printk_time' param).
|
||||
syslog
|
||||
Switch to syslog format: "<%u>[time stamp] text\n"
|
||||
IOW, each message will have a facility and loglevel
|
||||
prefix. The format is similar to one used by syslog()
|
||||
syscall, or to executing "dmesg -S --raw" or to reading
|
||||
from /proc/kmsg.
|
||||
|
||||
consoleblank= [KNL] The console blank (screen saver) timeout in
|
||||
seconds. A value of 0 disables the blank timer.
|
||||
Defaults to 0.
|
||||
|
|
@ -2538,6 +2552,9 @@
|
|||
This is useful when you use a panic=... timeout and
|
||||
need the box quickly up again.
|
||||
|
||||
These settings can be accessed at runtime via
|
||||
the nmi_watchdog and hardlockup_panic sysctls.
|
||||
|
||||
netpoll.carrier_timeout=
|
||||
[NET] Specifies amount of time (in seconds) that
|
||||
netpoll should wait for a carrier. By default netpoll
|
||||
|
|
@ -2741,8 +2758,6 @@
|
|||
norandmaps Don't use address space randomization. Equivalent to
|
||||
echo 0 > /proc/sys/kernel/randomize_va_space
|
||||
|
||||
noreplace-paravirt [X86,IA-64,PV_OPS] Don't patch paravirt_ops
|
||||
|
||||
noreplace-smp [X86-32,SMP] Don't replace SMP instructions
|
||||
with UP alternatives
|
||||
|
||||
|
|
@ -3696,7 +3711,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
|
||||
|
|
|
|||
|
|
@ -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,519 @@
|
|||
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.
|
||||
|
||||
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
|
||||
=========
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -14,6 +14,7 @@ Core utilities
|
|||
kernel-api
|
||||
assoc_array
|
||||
atomic_ops
|
||||
refcount-vs-atomic
|
||||
cpu_hotplug
|
||||
local_ops
|
||||
workqueue
|
||||
|
|
@ -21,6 +22,8 @@ Core utilities
|
|||
flexible-arrays
|
||||
librs
|
||||
genalloc
|
||||
errseq
|
||||
printk-formats
|
||||
|
||||
Interfaces for kernel debugging
|
||||
===============================
|
||||
|
|
|
|||
|
|
@ -139,6 +139,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
|
||||
|
|
@ -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";
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -48,6 +48,10 @@ Required properties:
|
|||
Documentation/devicetree/bindings/reset/reset.txt,
|
||||
the reset-names should be "hdmitx_apb", "hdmitx", "hdmitx_phy"
|
||||
|
||||
Optional properties:
|
||||
- hdmi-supply: Optional phandle to an external 5V regulator to power the HDMI
|
||||
logic, as described in the file ../regulator/regulator.txt
|
||||
|
||||
Required nodes:
|
||||
|
||||
The connections to the HDMI ports are modeled using the OF graph
|
||||
|
|
|
|||
|
|
@ -64,6 +64,10 @@ Required properties:
|
|||
- reg-names: should contain the names of the previous memory regions
|
||||
- interrupts: should contain the VENC Vsync interrupt number
|
||||
|
||||
Optional properties:
|
||||
- power-domains: Optional phandle to associated power domain as described in
|
||||
the file ../power/power_domain.txt
|
||||
|
||||
Required nodes:
|
||||
|
||||
The connections to the VPU output video ports are modeled using the OF graph
|
||||
|
|
|
|||
|
|
@ -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,25 @@
|
|||
Ilitek ILI9225 display panels
|
||||
|
||||
This binding is for display panels using an Ilitek ILI9225 controller in SPI
|
||||
mode.
|
||||
|
||||
Required properties:
|
||||
- compatible: "vot,v220hf01a-t", "ilitek,ili9225"
|
||||
- rs-gpios: Register select signal
|
||||
- reset-gpios: Reset pin
|
||||
|
||||
The node for this driver must be a child node of a SPI controller, hence
|
||||
all mandatory properties described in ../spi/spi-bus.txt must be specified.
|
||||
|
||||
Optional properties:
|
||||
- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
|
||||
|
||||
Example:
|
||||
display@0{
|
||||
compatible = "vot,v220hf01a-t", "ilitek,ili9225";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <12000000>;
|
||||
rs-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
|
||||
rotation = <270>;
|
||||
};
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
Ilitek ILI9322 TFT panel driver with SPI control bus
|
||||
|
||||
This is a driver for 320x240 TFT panels, accepting a variety of input
|
||||
streams that get adapted and scaled to the panel. The panel output has
|
||||
960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and
|
||||
VCOMH outputs.
|
||||
|
||||
Required properties:
|
||||
- compatible: "dlink,dir-685-panel", "ilitek,ili9322"
|
||||
(full system-specific compatible is always required to look up configuration)
|
||||
- reg: address of the panel on the SPI bus
|
||||
|
||||
Optional properties:
|
||||
- vcc-supply: core voltage supply, see regulator/regulator.txt
|
||||
- iovcc-supply: voltage supply for the interface input/output signals,
|
||||
see regulator/regulator.txt
|
||||
- vci-supply: voltage supply for analog parts, see regulator/regulator.txt
|
||||
- reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
|
||||
|
||||
The following optional properties only apply to RGB and YUV input modes and
|
||||
can be omitted for BT.656 input modes:
|
||||
|
||||
- pixelclk-active: see display/panel/display-timing.txt
|
||||
- de-active: see display/panel/display-timing.txt
|
||||
- hsync-active: see display/panel/display-timing.txt
|
||||
- vsync-active: see display/panel/display-timing.txt
|
||||
|
||||
The panel must obey the rules for a SPI slave device as specified in
|
||||
spi/spi-bus.txt
|
||||
|
||||
The device node can contain one 'port' child node with one child
|
||||
'endpoint' node, according to the bindings defined in
|
||||
media/video-interfaces.txt. This node should describe panel's video bus.
|
||||
|
||||
Example:
|
||||
|
||||
panel: display@0 {
|
||||
compatible = "dlink,dir-685-panel", "ilitek,ili9322";
|
||||
reg = <0>;
|
||||
vcc-supply = <&vdisp>;
|
||||
iovcc-supply = <&vdisp>;
|
||||
vci-supply = <&vdisp>;
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&display_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "mitsubishi,aa070mc01-ca1"
|
||||
|
||||
This binding is compatible with the simple-panel binding, which is specified
|
||||
in simple-panel.txt in this directory.
|
||||
|
|
@ -78,6 +78,16 @@ used for panels that implement compatible control signals.
|
|||
while active. Active high reset signals can be supported by inverting the
|
||||
GPIO specifier polarity flag.
|
||||
|
||||
Power
|
||||
-----
|
||||
|
||||
- power-supply: display panels require power to be supplied. While several
|
||||
panels need more than one power supply with panel-specific constraints
|
||||
governing the order and timings of the power supplies, in many cases a single
|
||||
power supply is sufficient, either because the panel has a single power rail,
|
||||
or because all its power rails can be driven by the same supply. In that case
|
||||
the power-supply property specifies the supply powering the panel as a phandle
|
||||
to a regulator.
|
||||
|
||||
Backlight
|
||||
---------
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@ Optional properties:
|
|||
- label: See panel-common.txt.
|
||||
- gpios: See panel-common.txt.
|
||||
- backlight: See panel-common.txt.
|
||||
- power-supply: See panel-common.txt.
|
||||
- data-mirror: If set, reverse the bit order described in the data mappings
|
||||
below on all data lanes, transmitting bits for slots 6 to 0 instead of
|
||||
0 to 6.
|
||||
|
|
|
|||
|
|
@ -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 @@
|
|||
Simple display panel
|
||||
|
||||
Required properties:
|
||||
- power-supply: regulator to provide the supply voltage
|
||||
- power-supply: See panel-common.txt
|
||||
|
||||
Optional properties:
|
||||
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
|
||||
|
|
|
|||
|
|
@ -0,0 +1,29 @@
|
|||
Tianma Micro-electronics TM070RVHG71 7.0" WXGA TFT LCD panel
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "tianma,tm070rvhg71"
|
||||
- power-supply: single regulator to provide the supply voltage
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
|
||||
Required nodes:
|
||||
- port: LVDS port mapping to connect this display
|
||||
|
||||
This panel needs single power supply voltage. Its backlight is conntrolled
|
||||
via PWM signal.
|
||||
|
||||
Example:
|
||||
--------
|
||||
|
||||
Example device-tree definition when connected to iMX6Q based board
|
||||
|
||||
panel: panel-lvds0 {
|
||||
compatible = "tianma,tm070rvhg71";
|
||||
backlight = <&backlight_lvds>;
|
||||
power-supply = <®_lvds>;
|
||||
|
||||
port {
|
||||
panel_in_lvds0: endpoint {
|
||||
remote-endpoint = <&lvds0_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
|
|||
========================
|
||||
|
||||
Required properties:
|
||||
- compatible: "toppoly,td028ttec1"
|
||||
- compatible: "tpo,td028ttec1"
|
||||
|
||||
Optional properties:
|
||||
- label: a symbolic name for the panel
|
||||
|
|
@ -14,7 +14,7 @@ Example
|
|||
-------
|
||||
|
||||
lcd-panel: td028ttec1@0 {
|
||||
compatible = "toppoly,td028ttec1";
|
||||
compatible = "tpo,td028ttec1";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <100000>;
|
||||
spi-cpol;
|
||||
|
|
@ -3,6 +3,8 @@
|
|||
Required Properties:
|
||||
|
||||
- compatible: must be one of the following.
|
||||
- "renesas,du-r8a7743" for R8A7743 (RZ/G1M) compatible DU
|
||||
- "renesas,du-r8a7745" for R8A7745 (RZ/G1E) compatible DU
|
||||
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
|
||||
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
|
||||
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
|
||||
|
|
@ -27,10 +29,10 @@ Required Properties:
|
|||
- clock-names: Name of the clocks. This property is model-dependent.
|
||||
- R8A7779 uses a single functional clock. The clock doesn't need to be
|
||||
named.
|
||||
- R8A779[0123456] use one functional clock per channel and one clock per
|
||||
LVDS encoder (if available). The functional clocks must be named "du.x"
|
||||
with "x" being the channel numerical index. The LVDS clocks must be
|
||||
named "lvds.x" with "x" being the LVDS encoder numerical index.
|
||||
- All other DU instances use one functional clock per channel and one
|
||||
clock per LVDS encoder (if available). The functional clocks must be
|
||||
named "du.x" with "x" being the channel numerical index. The LVDS clocks
|
||||
must be named "lvds.x" with "x" being the LVDS encoder numerical index.
|
||||
- In addition to the functional and encoder clocks, all DU versions also
|
||||
support externally supplied pixel clocks. Those clocks are optional.
|
||||
When supplied they must be named "dclkin.x" with "x" being the input
|
||||
|
|
@ -49,16 +51,18 @@ bindings specified in Documentation/devicetree/bindings/graph.txt.
|
|||
The following table lists for each supported model the port number
|
||||
corresponding to each DU output.
|
||||
|
||||
Port 0 Port1 Port2 Port3
|
||||
Port0 Port1 Port2 Port3
|
||||
-----------------------------------------------------------------------------
|
||||
R8A7779 (H1) DPAD 0 DPAD 1 - -
|
||||
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
|
||||
R8A7791 (M2-W) DPAD LVDS 0 - -
|
||||
R8A7792 (V2H) DPAD 0 DPAD 1 - -
|
||||
R8A7793 (M2-N) DPAD LVDS 0 - -
|
||||
R8A7794 (E2) DPAD 0 DPAD 1 - -
|
||||
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
|
||||
R8A7796 (M3-W) DPAD HDMI LVDS -
|
||||
R8A7743 (RZ/G1M) DPAD 0 LVDS 0 - -
|
||||
R8A7745 (RZ/G1E) DPAD 0 DPAD 1 - -
|
||||
R8A7779 (R-Car H1) DPAD 0 DPAD 1 - -
|
||||
R8A7790 (R-Car H2) DPAD 0 LVDS 0 LVDS 1 -
|
||||
R8A7791 (R-Car M2-W) DPAD 0 LVDS 0 - -
|
||||
R8A7792 (R-Car V2H) DPAD 0 DPAD 1 - -
|
||||
R8A7793 (R-Car M2-N) DPAD 0 LVDS 0 - -
|
||||
R8A7794 (R-Car E2) DPAD 0 DPAD 1 - -
|
||||
R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS 0
|
||||
R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
|
||||
|
||||
|
||||
Example: R8A7795 (R-Car H3) ES2.0 DU
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ buffer to an external LCD interface.
|
|||
Required properties:
|
||||
- compatible: value should be one of the following
|
||||
"rockchip,rk3036-vop";
|
||||
"rockchip,rk3126-vop";
|
||||
"rockchip,rk3288-vop";
|
||||
"rockchip,rk3368-vop";
|
||||
"rockchip,rk3366-vop";
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,35 @@
|
|||
Sitronix ST7735R display panels
|
||||
|
||||
This binding is for display panels using a Sitronix ST7735R controller in SPI
|
||||
mode.
|
||||
|
||||
Required properties:
|
||||
- compatible: "jianda,jd-t18003-t01", "sitronix,st7735r"
|
||||
- dc-gpios: Display data/command selection (D/CX)
|
||||
- reset-gpios: Reset signal (RSTX)
|
||||
|
||||
The node for this driver must be a child node of a SPI controller, hence
|
||||
all mandatory properties described in ../spi/spi-bus.txt must be specified.
|
||||
|
||||
Optional properties:
|
||||
- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
|
||||
- backlight: phandle of the backlight device attached to the panel
|
||||
|
||||
Example:
|
||||
|
||||
backlight: backlight {
|
||||
compatible = "gpio-backlight";
|
||||
gpios = <&gpio 44 GPIO_ACTIVE_HIGH>;
|
||||
}
|
||||
|
||||
...
|
||||
|
||||
display@0{
|
||||
compatible = "jianda,jd-t18003-t01", "sitronix,st7735r";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <32000000>;
|
||||
dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
|
||||
rotation = <270>;
|
||||
backlight = &backlight;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -10,7 +10,11 @@
|
|||
- "lcd" for the clock feeding the output pixel clock & IP clock.
|
||||
- resets: reset to be used by the device (defined by use of RCC macro).
|
||||
Required nodes:
|
||||
- Video port for RGB output.
|
||||
- Video port for DPI RGB output: ltdc has one video port with up to 2
|
||||
endpoints:
|
||||
- for external dpi rgb panel or bridge, using gpios.
|
||||
- for internal dpi input of the MIPI DSI host controller.
|
||||
Note: These 2 endpoints cannot be activated simultaneously.
|
||||
|
||||
* STMicroelectronics STM32 DSI controller specific extensions to Synopsys
|
||||
DesignWare MIPI DSI host controller
|
||||
|
|
|
|||
|
|
@ -93,6 +93,7 @@ Required properties:
|
|||
* allwinner,sun6i-a31s-tcon
|
||||
* allwinner,sun7i-a20-tcon
|
||||
* allwinner,sun8i-a33-tcon
|
||||
* allwinner,sun8i-a83t-tcon-lcd
|
||||
* allwinner,sun8i-v3s-tcon
|
||||
- reg: base address and size of memory-mapped region
|
||||
- interrupts: interrupt associated to this IP
|
||||
|
|
@ -121,6 +122,14 @@ 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:
|
||||
- 'lvds': The reset line driving the LVDS logic
|
||||
|
||||
And on the A23, A31, A31s and A33, you need one more clock line:
|
||||
- 'lvds-alt': An alternative clock source, separate from the TCON channel 0
|
||||
clock, that can be used to drive the LVDS clock
|
||||
|
||||
DRC
|
||||
---
|
||||
|
||||
|
|
@ -216,6 +225,7 @@ supported.
|
|||
|
||||
Required properties:
|
||||
- compatible: value must be one of:
|
||||
* allwinner,sun8i-a83t-de2-mixer-0
|
||||
* allwinner,sun8i-v3s-de2-mixer
|
||||
- reg: base address and size of the memory-mapped region.
|
||||
- clocks: phandles to the clocks feeding the mixer
|
||||
|
|
@ -245,6 +255,7 @@ Required properties:
|
|||
* allwinner,sun6i-a31s-display-engine
|
||||
* allwinner,sun7i-a20-display-engine
|
||||
* allwinner,sun8i-a33-display-engine
|
||||
* allwinner,sun8i-a83t-display-engine
|
||||
* allwinner,sun8i-v3s-display-engine
|
||||
|
||||
- allwinner,pipelines: list of phandle to the display engine
|
||||
|
|
|
|||
|
|
@ -206,21 +206,33 @@ of the following host1x client modules:
|
|||
- "nvidia,tegra132-sor": for Tegra132
|
||||
- "nvidia,tegra210-sor": for Tegra210
|
||||
- "nvidia,tegra210-sor1": for Tegra210
|
||||
- "nvidia,tegra186-sor": for Tegra186
|
||||
- "nvidia,tegra186-sor1": for Tegra186
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- sor: clock input for the SOR hardware
|
||||
- source: source clock for the SOR clock
|
||||
- out: SOR output clock
|
||||
- parent: input for the pixel clock
|
||||
- dp: reference clock for the SOR clock
|
||||
- safe: safe reference for the SOR clock during power up
|
||||
|
||||
For Tegra186 and later:
|
||||
- pad: SOR pad output clock (on Tegra186 and later)
|
||||
|
||||
Obsolete:
|
||||
- source: source clock for the SOR clock (obsolete, use "out" instead)
|
||||
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- sor
|
||||
|
||||
Required properties on Tegra186 and later:
|
||||
- nvidia,interface: index of the SOR interface
|
||||
|
||||
Optional properties:
|
||||
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
|
||||
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
|
||||
|
|
|
|||
|
|
@ -47,6 +47,11 @@ Required properties:
|
|||
- clocks: handle to fclk
|
||||
- clock-names: "fck"
|
||||
|
||||
Optional properties:
|
||||
- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit
|
||||
in bytes per second
|
||||
|
||||
|
||||
HDMI
|
||||
----
|
||||
|
||||
|
|
|
|||
|
|
@ -28,6 +28,10 @@ Required properties:
|
|||
- ti,hwmods: "dss_dispc"
|
||||
- interrupts: the DISPC interrupt
|
||||
|
||||
Optional properties:
|
||||
- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit
|
||||
in bytes per second
|
||||
|
||||
|
||||
RFBI
|
||||
----
|
||||
|
|
|
|||
|
|
@ -37,6 +37,10 @@ Required properties:
|
|||
- clocks: handle to fclk
|
||||
- clock-names: "fck"
|
||||
|
||||
Optional properties:
|
||||
- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit
|
||||
in bytes per second
|
||||
|
||||
|
||||
RFBI
|
||||
----
|
||||
|
|
|
|||
|
|
@ -36,6 +36,10 @@ Required properties:
|
|||
- clocks: handle to fclk
|
||||
- clock-names: "fck"
|
||||
|
||||
Optional properties:
|
||||
- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit
|
||||
in bytes per second
|
||||
|
||||
|
||||
RFBI
|
||||
----
|
||||
|
|
|
|||
|
|
@ -36,6 +36,10 @@ Required properties:
|
|||
- clocks: handle to fclk
|
||||
- clock-names: "fck"
|
||||
|
||||
Optional properties:
|
||||
- max-memory-bandwidth: Input memory (from main memory to dispc) bandwidth limit
|
||||
in bytes per second
|
||||
|
||||
|
||||
RFBI
|
||||
----
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче