mirror of
https://github.com/torvalds/linux.git
synced 2024-09-20 06:53:04 +00:00
Merge branch 'torvalds:master' into master
This commit is contained in:
Shubham Gaur
GitHub
commit
0401bbf56d
1
.gitignore
vendored
1
.gitignore
vendored
|
|
@ -24,6 +24,7 @@
|
|||
*.dwo
|
||||
*.elf
|
||||
*.gcno
|
||||
*.gcda
|
||||
*.gz
|
||||
*.i
|
||||
*.ko
|
||||
|
|
|
|||
5
.mailmap
5
.mailmap
|
|
@ -60,6 +60,7 @@ Amit Nischal <quic_anischal@quicinc.com> <anischal@codeaurora.org>
|
|||
Andi Kleen <ak@linux.intel.com> <ak@suse.de>
|
||||
Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
|
||||
Andreas Herrmann <aherrman@de.ibm.com>
|
||||
Andreas Hindborg <a.hindborg@kernel.org> <a.hindborg@samsung.com>
|
||||
Andrej Shadura <andrew.shadura@collabora.co.uk>
|
||||
Andrej Shadura <andrew@shadura.me> <andrew@beldisplaytech.com>
|
||||
Andrew Morton <akpm@linux-foundation.org>
|
||||
|
|
@ -269,6 +270,7 @@ James Ketrenos <jketreno@io.(none)>
|
|||
Jan Glauber <jan.glauber@gmail.com> <jang@de.ibm.com>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jang@linux.vnet.ibm.com>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
|
||||
Jan Kuliga <jtkuliga.kdev@gmail.com> <jankul@alatek.krakow.pl>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@linux.intel.com>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
|
||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@tuni.fi>
|
||||
|
|
@ -354,6 +356,8 @@ Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>
|
|||
Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
|
||||
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
||||
Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.com>
|
||||
Konrad Dybcio <konradybcio@kernel.org> <konrad.dybcio@linaro.org>
|
||||
Konrad Dybcio <konradybcio@kernel.org> <konrad.dybcio@somainline.org>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
|
|
@ -525,6 +529,7 @@ Pavankumar Kondeti <quic_pkondeti@quicinc.com> <pkondeti@codeaurora.org>
|
|||
Peter A Jonsson <pj@ludd.ltu.se>
|
||||
Peter Oruba <peter.oruba@amd.com>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> <pierre-louis.bossart@linux.intel.com>
|
||||
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> <pradeepc@codeaurora.org>
|
||||
|
|
|
|||
6
CREDITS
6
CREDITS
|
|
@ -378,6 +378,9 @@ S: 1549 Hiironen Rd.
|
|||
S: Brimson, MN 55602
|
||||
S: USA
|
||||
|
||||
N: Arnd Bergmann
|
||||
D: Maintainer of Cell Broadband Engine Architecture
|
||||
|
||||
N: Hennus Bergman
|
||||
P: 1024/77D50909 76 99 FD 31 91 E1 96 1C 90 BB 22 80 62 F6 BD 63
|
||||
D: Author and maintainer of the QIC-02 tape driver
|
||||
|
|
@ -1869,6 +1872,9 @@ S: K osmidomkum 723
|
|||
S: 160 00 Praha 6
|
||||
S: Czech Republic
|
||||
|
||||
N: Jeremy Kerr
|
||||
D: Maintainer of SPU File System
|
||||
|
||||
N: Michael Kerrisk
|
||||
E: mtk.manpages@gmail.com
|
||||
W: https://man7.org/
|
||||
|
|
|
|||
|
|
@ -9,9 +9,11 @@ maps an ELF DSO into that program's address space. This DSO is called
|
|||
the vDSO and it often contains useful and highly-optimized alternatives
|
||||
to real syscalls.
|
||||
|
||||
These functions are called just like ordinary C function according to
|
||||
your platform's ABI. Call them from a sensible context. (For example,
|
||||
if you set CS on x86 to something strange, the vDSO functions are
|
||||
These functions are called according to your platform's ABI. On many
|
||||
platforms they are called just like ordinary C function. On other platforms
|
||||
(ex: powerpc) they are called with the same convention as system calls which
|
||||
is different from ordinary C functions. Call them from a sensible context.
|
||||
(For example, if you set CS on x86 to something strange, the vDSO functions are
|
||||
within their rights to crash.) In addition, if you pass a bad
|
||||
pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT.
|
||||
|
||||
|
|
|
|||
|
|
@ -377,17 +377,33 @@ What: /sys/class/power_supply/<supply_name>/charge_type
|
|||
Date: July 2009
|
||||
Contact: linux-pm@vger.kernel.org
|
||||
Description:
|
||||
Represents the type of charging currently being applied to the
|
||||
battery. "Trickle", "Fast", and "Standard" all mean different
|
||||
charging speeds. "Adaptive" means that the charger uses some
|
||||
algorithm to adjust the charge rate dynamically, without
|
||||
any user configuration required. "Custom" means that the charger
|
||||
uses the charge_control_* properties as configuration for some
|
||||
different algorithm. "Long Life" means the charger reduces its
|
||||
charging rate in order to prolong the battery health. "Bypass"
|
||||
means the charger bypasses the charging path around the
|
||||
integrated converter allowing for a "smart" wall adaptor to
|
||||
perform the power conversion externally.
|
||||
Select the charging algorithm to use for a battery.
|
||||
|
||||
Standard:
|
||||
Fully charge the battery at a moderate rate.
|
||||
Fast:
|
||||
Quickly charge the battery using fast-charge
|
||||
technology. This is typically harder on the battery
|
||||
than standard charging and may lower its lifespan.
|
||||
Trickle:
|
||||
Users who primarily operate the system while
|
||||
plugged into an external power source can extend
|
||||
battery life with this mode. Vendor tooling may
|
||||
call this "Primarily AC Use".
|
||||
Adaptive:
|
||||
Automatically optimize battery charge rate based
|
||||
on typical usage pattern.
|
||||
Custom:
|
||||
Use the charge_control_* properties to determine
|
||||
when to start and stop charging. Advanced users
|
||||
can use this to drastically extend battery life.
|
||||
Long Life:
|
||||
The charger reduces its charging rate in order to
|
||||
prolong the battery health.
|
||||
Bypass:
|
||||
The charger bypasses the charging path around the
|
||||
integrated converter allowing for a "smart" wall
|
||||
adaptor to perform the power conversion externally.
|
||||
|
||||
Access: Read, Write
|
||||
|
||||
|
|
@ -592,7 +608,12 @@ Description:
|
|||
the supply, for example it can show if USB-PD capable source
|
||||
is attached.
|
||||
|
||||
Access: Read-Only
|
||||
Access: For power-supplies which consume USB power such
|
||||
as battery charger chips, this indicates the type of
|
||||
the connected USB power source and is Read-Only.
|
||||
|
||||
For power-supplies which act as a USB power-source such as
|
||||
e.g. the UCS1002 USB Port Power Controller this is writable.
|
||||
|
||||
Valid values:
|
||||
"Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
|
||||
|
|
|
|||
15
Documentation/ABI/testing/sysfs-class-tee
Normal file
15
Documentation/ABI/testing/sysfs-class-tee
Normal file
|
|
@ -0,0 +1,15 @@
|
|||
What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
|
||||
Date: May 2024
|
||||
KernelVersion: 6.10
|
||||
Contact: op-tee@lists.trustedfirmware.org
|
||||
Description:
|
||||
RPMB frames can be routed to the RPMB device via the
|
||||
user-space daemon tee-supplicant or the RPMB subsystem
|
||||
in the kernel. The value "user" means that the driver
|
||||
will route the RPMB frames via user space. Conversely,
|
||||
"kernel" means that the frames are routed via the RPMB
|
||||
subsystem without assistance from tee-supplicant. It
|
||||
should be assumed that RPMB frames are routed via user
|
||||
space if the variable is absent. The primary purpose
|
||||
of this variable is to let systemd know whether
|
||||
tee-supplicant is needed in the early boot with initramfs.
|
||||
|
|
@ -258,24 +258,29 @@ Description: (RW) When retrieving the PHC with the PTP SYS_OFFSET_EXTENDED
|
|||
the estimated point where the FPGA latches the PHC time. This
|
||||
value may be changed by writing an unsigned integer.
|
||||
|
||||
What: /sys/class/timecard/ocpN/ttyGNSS
|
||||
What: /sys/class/timecard/ocpN/ttyGNSS2
|
||||
Date: September 2021
|
||||
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
||||
Description: These optional attributes link to the TTY serial ports
|
||||
associated with the GNSS devices.
|
||||
What: /sys/class/timecard/ocpN/tty
|
||||
Date: August 2024
|
||||
Contact: Vadim Fedorenko <vadim.fedorenko@linux.dev>
|
||||
Description: (RO) Directory containing the sysfs nodes for TTY attributes
|
||||
|
||||
What: /sys/class/timecard/ocpN/ttyMAC
|
||||
Date: September 2021
|
||||
What: /sys/class/timecard/ocpN/tty/ttyGNSS
|
||||
What: /sys/class/timecard/ocpN/tty/ttyGNSS2
|
||||
Date: August 2024
|
||||
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
||||
Description: This optional attribute links to the TTY serial port
|
||||
associated with the Miniature Atomic Clock.
|
||||
Description: (RO) These optional attributes contain names of the TTY serial
|
||||
ports associated with the GNSS devices.
|
||||
|
||||
What: /sys/class/timecard/ocpN/ttyNMEA
|
||||
Date: September 2021
|
||||
What: /sys/class/timecard/ocpN/tty/ttyMAC
|
||||
Date: August 2024
|
||||
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
||||
Description: This optional attribute links to the TTY serial port
|
||||
which outputs the PHC time in NMEA ZDA format.
|
||||
Description: (RO) This optional attribute contains name of the TTY serial
|
||||
port associated with the Miniature Atomic Clock.
|
||||
|
||||
What: /sys/class/timecard/ocpN/tty/ttyNMEA
|
||||
Date: August 2024
|
||||
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
||||
Description: (RO) This optional attribute contains name of the TTY serial
|
||||
port which outputs the PHC time in NMEA ZDA format.
|
||||
|
||||
What: /sys/class/timecard/ocpN/utc_tai_offset
|
||||
Date: September 2021
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ driver generally needs to perform the following initialization:
|
|||
- Enable DMA/processing engines
|
||||
|
||||
When done using the device, and perhaps the module needs to be unloaded,
|
||||
the driver needs to take the follow steps:
|
||||
the driver needs to take the following steps:
|
||||
|
||||
- Disable the device from generating IRQs
|
||||
- Release the IRQ (free_irq())
|
||||
|
|
|
|||
|
|
@ -921,10 +921,10 @@ This portion of the ``rcu_data`` structure is declared as follows:
|
|||
|
||||
::
|
||||
|
||||
1 int dynticks_snap;
|
||||
1 int watching_snap;
|
||||
2 unsigned long dynticks_fqs;
|
||||
|
||||
The ``->dynticks_snap`` field is used to take a snapshot of the
|
||||
The ``->watching_snap`` field is used to take a snapshot of the
|
||||
corresponding CPU's dyntick-idle state when forcing quiescent states,
|
||||
and is therefore accessed from other CPUs. Finally, the
|
||||
``->dynticks_fqs`` field is used to count the number of times this CPU
|
||||
|
|
@ -935,8 +935,8 @@ This portion of the rcu_data structure is declared as follows:
|
|||
|
||||
::
|
||||
|
||||
1 long dynticks_nesting;
|
||||
2 long dynticks_nmi_nesting;
|
||||
1 long nesting;
|
||||
2 long nmi_nesting;
|
||||
3 atomic_t dynticks;
|
||||
4 bool rcu_need_heavy_qs;
|
||||
5 bool rcu_urgent_qs;
|
||||
|
|
@ -945,14 +945,14 @@ These fields in the rcu_data structure maintain the per-CPU dyntick-idle
|
|||
state for the corresponding CPU. The fields may be accessed only from
|
||||
the corresponding CPU (and from tracing) unless otherwise stated.
|
||||
|
||||
The ``->dynticks_nesting`` field counts the nesting depth of process
|
||||
The ``->nesting`` field counts the nesting depth of process
|
||||
execution, so that in normal circumstances this counter has value zero
|
||||
or one. NMIs, irqs, and tracers are counted by the
|
||||
``->dynticks_nmi_nesting`` field. Because NMIs cannot be masked, changes
|
||||
``->nmi_nesting`` field. Because NMIs cannot be masked, changes
|
||||
to this variable have to be undertaken carefully using an algorithm
|
||||
provided by Andy Lutomirski. The initial transition from idle adds one,
|
||||
and nested transitions add two, so that a nesting level of five is
|
||||
represented by a ``->dynticks_nmi_nesting`` value of nine. This counter
|
||||
represented by a ``->nmi_nesting`` value of nine. This counter
|
||||
can therefore be thought of as counting the number of reasons why this
|
||||
CPU cannot be permitted to enter dyntick-idle mode, aside from
|
||||
process-level transitions.
|
||||
|
|
@ -960,12 +960,12 @@ process-level transitions.
|
|||
However, it turns out that when running in non-idle kernel context, the
|
||||
Linux kernel is fully capable of entering interrupt handlers that never
|
||||
exit and perhaps also vice versa. Therefore, whenever the
|
||||
``->dynticks_nesting`` field is incremented up from zero, the
|
||||
``->dynticks_nmi_nesting`` field is set to a large positive number, and
|
||||
whenever the ``->dynticks_nesting`` field is decremented down to zero,
|
||||
the ``->dynticks_nmi_nesting`` field is set to zero. Assuming that
|
||||
``->nesting`` field is incremented up from zero, the
|
||||
``->nmi_nesting`` field is set to a large positive number, and
|
||||
whenever the ``->nesting`` field is decremented down to zero,
|
||||
the ``->nmi_nesting`` field is set to zero. Assuming that
|
||||
the number of misnested interrupts is not sufficient to overflow the
|
||||
counter, this approach corrects the ``->dynticks_nmi_nesting`` field
|
||||
counter, this approach corrects the ``->nmi_nesting`` field
|
||||
every time the corresponding CPU enters the idle loop from process
|
||||
context.
|
||||
|
||||
|
|
@ -992,8 +992,8 @@ code.
|
|||
+-----------------------------------------------------------------------+
|
||||
| **Quick Quiz**: |
|
||||
+-----------------------------------------------------------------------+
|
||||
| Why not simply combine the ``->dynticks_nesting`` and |
|
||||
| ``->dynticks_nmi_nesting`` counters into a single counter that just |
|
||||
| Why not simply combine the ``->nesting`` and |
|
||||
| ``->nmi_nesting`` counters into a single counter that just |
|
||||
| counts the number of reasons that the corresponding CPU is non-idle? |
|
||||
+-----------------------------------------------------------------------+
|
||||
| **Answer**: |
|
||||
|
|
|
|||
|
|
@ -147,10 +147,10 @@ RCU read-side critical sections preceding and following the current
|
|||
idle sojourn.
|
||||
This case is handled by calls to the strongly ordered
|
||||
``atomic_add_return()`` read-modify-write atomic operation that
|
||||
is invoked within ``rcu_dynticks_eqs_enter()`` at idle-entry
|
||||
time and within ``rcu_dynticks_eqs_exit()`` at idle-exit time.
|
||||
The grace-period kthread invokes first ``ct_dynticks_cpu_acquire()``
|
||||
(preceded by a full memory barrier) and ``rcu_dynticks_in_eqs_since()``
|
||||
is invoked within ``ct_kernel_exit_state()`` at idle-entry
|
||||
time and within ``ct_kernel_enter_state()`` at idle-exit time.
|
||||
The grace-period kthread invokes first ``ct_rcu_watching_cpu_acquire()``
|
||||
(preceded by a full memory barrier) and ``rcu_watching_snap_stopped_since()``
|
||||
(both of which rely on acquire semantics) to detect idle CPUs.
|
||||
|
||||
+-----------------------------------------------------------------------+
|
||||
|
|
|
|||
|
|
@ -528,7 +528,7 @@
|
|||
font-style="normal"
|
||||
y="-8652.5312"
|
||||
x="2466.7822"
|
||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
||||
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||
<text
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
|
||||
id="text202-7-2-7-2-0"
|
||||
|
|
@ -537,7 +537,7 @@
|
|||
font-style="normal"
|
||||
y="-8368.1475"
|
||||
x="2463.3262"
|
||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
||||
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||
</g>
|
||||
<g
|
||||
id="g4504"
|
||||
|
|
@ -607,7 +607,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-7-5-3-27-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_enter()</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_exit_state()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3745.7725"
|
||||
|
|
@ -638,7 +638,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-7-5-3-27-6-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_exit()</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_enter_state()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3745.7725"
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
|
|
@ -844,7 +844,7 @@
|
|||
font-style="normal"
|
||||
y="1547.8876"
|
||||
x="4417.6396"
|
||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
||||
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(6501.9719,-10685.904)"
|
||||
|
|
@ -899,7 +899,7 @@
|
|||
font-style="normal"
|
||||
y="1858.8729"
|
||||
x="4414.1836"
|
||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
||||
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="14659.87"
|
||||
|
|
@ -977,7 +977,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-7-5-3-27-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_enter()</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_exit_state()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3745.7725"
|
||||
|
|
@ -1008,7 +1008,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-7-5-3-27-6-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_exit()</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_enter_state()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3745.7725"
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
|
|
@ -2974,7 +2974,7 @@
|
|||
font-style="normal"
|
||||
y="38114.047"
|
||||
x="-334.33856"
|
||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
||||
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(1749.9916,25880.249)"
|
||||
|
|
@ -3029,7 +3029,7 @@
|
|||
font-style="normal"
|
||||
y="38425.035"
|
||||
x="-337.79462"
|
||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
||||
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="9907.8887"
|
||||
|
|
@ -3107,7 +3107,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-7-5-3-27-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_enter()</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_exit_state()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3745.7725"
|
||||
|
|
@ -3138,7 +3138,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-7-5-3-27-6-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_dynticks_eqs_exit()</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">ct_kernel_enter_state()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3745.7725"
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 208 KiB After Width: | Height: | Size: 208 KiB |
|
|
@ -516,7 +516,7 @@
|
|||
font-style="normal"
|
||||
y="-8652.5312"
|
||||
x="2466.7822"
|
||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
||||
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||
<text
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
|
||||
id="text202-7-2-7-2-0"
|
||||
|
|
@ -525,7 +525,7 @@
|
|||
font-style="normal"
|
||||
y="-8368.1475"
|
||||
x="2463.3262"
|
||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
||||
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;line-height:125%;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 28 KiB |
|
|
@ -2649,8 +2649,7 @@ those that are idle from RCU's perspective) and then Tasks Rude RCU can
|
|||
be removed from the kernel.
|
||||
|
||||
The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
|
||||
consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
|
||||
and rcu_barrier_tasks_rude().
|
||||
consisting solely of synchronize_rcu_tasks_rude().
|
||||
|
||||
Tasks Trace RCU
|
||||
~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -194,14 +194,13 @@ over a rather long period of time, but improvements are always welcome!
|
|||
when publicizing a pointer to a structure that can
|
||||
be traversed by an RCU read-side critical section.
|
||||
|
||||
5. If any of call_rcu(), call_srcu(), call_rcu_tasks(),
|
||||
call_rcu_tasks_rude(), or call_rcu_tasks_trace() is used,
|
||||
the callback function may be invoked from softirq context,
|
||||
and in any case with bottom halves disabled. In particular,
|
||||
this callback function cannot block. If you need the callback
|
||||
to block, run that code in a workqueue handler scheduled from
|
||||
the callback. The queue_rcu_work() function does this for you
|
||||
in the case of call_rcu().
|
||||
5. If any of call_rcu(), call_srcu(), call_rcu_tasks(), or
|
||||
call_rcu_tasks_trace() is used, the callback function may be
|
||||
invoked from softirq context, and in any case with bottom halves
|
||||
disabled. In particular, this callback function cannot block.
|
||||
If you need the callback to block, run that code in a workqueue
|
||||
handler scheduled from the callback. The queue_rcu_work()
|
||||
function does this for you in the case of call_rcu().
|
||||
|
||||
6. Since synchronize_rcu() can block, it cannot be called
|
||||
from any sort of irq context. The same rule applies
|
||||
|
|
@ -254,10 +253,10 @@ over a rather long period of time, but improvements are always welcome!
|
|||
corresponding readers must use rcu_read_lock_trace()
|
||||
and rcu_read_unlock_trace().
|
||||
|
||||
c. If an updater uses call_rcu_tasks_rude() or
|
||||
synchronize_rcu_tasks_rude(), then the corresponding
|
||||
readers must use anything that disables preemption,
|
||||
for example, preempt_disable() and preempt_enable().
|
||||
c. If an updater uses synchronize_rcu_tasks_rude(),
|
||||
then the corresponding readers must use anything that
|
||||
disables preemption, for example, preempt_disable()
|
||||
and preempt_enable().
|
||||
|
||||
Mixing things up will result in confusion and broken kernels, and
|
||||
has even resulted in an exploitable security issue. Therefore,
|
||||
|
|
@ -326,11 +325,9 @@ over a rather long period of time, but improvements are always welcome!
|
|||
d. Periodically invoke rcu_barrier(), permitting a limited
|
||||
number of updates per grace period.
|
||||
|
||||
The same cautions apply to call_srcu(), call_rcu_tasks(),
|
||||
call_rcu_tasks_rude(), and call_rcu_tasks_trace(). This is
|
||||
why there is an srcu_barrier(), rcu_barrier_tasks(),
|
||||
rcu_barrier_tasks_rude(), and rcu_barrier_tasks_rude(),
|
||||
respectively.
|
||||
The same cautions apply to call_srcu(), call_rcu_tasks(), and
|
||||
call_rcu_tasks_trace(). This is why there is an srcu_barrier(),
|
||||
rcu_barrier_tasks(), and rcu_barrier_tasks_trace(), respectively.
|
||||
|
||||
Note that although these primitives do take action to avoid
|
||||
memory exhaustion when any given CPU has too many callbacks,
|
||||
|
|
@ -383,17 +380,17 @@ over a rather long period of time, but improvements are always welcome!
|
|||
must use whatever locking or other synchronization is required
|
||||
to safely access and/or modify that data structure.
|
||||
|
||||
Do not assume that RCU callbacks will be executed on
|
||||
the same CPU that executed the corresponding call_rcu(),
|
||||
call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or
|
||||
call_rcu_tasks_trace(). For example, if a given CPU goes offline
|
||||
while having an RCU callback pending, then that RCU callback
|
||||
will execute on some surviving CPU. (If this was not the case,
|
||||
a self-spawning RCU callback would prevent the victim CPU from
|
||||
ever going offline.) Furthermore, CPUs designated by rcu_nocbs=
|
||||
might well *always* have their RCU callbacks executed on some
|
||||
other CPUs, in fact, for some real-time workloads, this is the
|
||||
whole point of using the rcu_nocbs= kernel boot parameter.
|
||||
Do not assume that RCU callbacks will be executed on the same
|
||||
CPU that executed the corresponding call_rcu(), call_srcu(),
|
||||
call_rcu_tasks(), or call_rcu_tasks_trace(). For example, if
|
||||
a given CPU goes offline while having an RCU callback pending,
|
||||
then that RCU callback will execute on some surviving CPU.
|
||||
(If this was not the case, a self-spawning RCU callback would
|
||||
prevent the victim CPU from ever going offline.) Furthermore,
|
||||
CPUs designated by rcu_nocbs= might well *always* have their
|
||||
RCU callbacks executed on some other CPUs, in fact, for some
|
||||
real-time workloads, this is the whole point of using the
|
||||
rcu_nocbs= kernel boot parameter.
|
||||
|
||||
In addition, do not assume that callbacks queued in a given order
|
||||
will be invoked in that order, even if they all are queued on the
|
||||
|
|
@ -507,9 +504,9 @@ over a rather long period of time, but improvements are always welcome!
|
|||
These debugging aids can help you find problems that are
|
||||
otherwise extremely difficult to spot.
|
||||
|
||||
17. If you pass a callback function defined within a module to one of
|
||||
call_rcu(), call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(),
|
||||
or call_rcu_tasks_trace(), then it is necessary to wait for all
|
||||
17. If you pass a callback function defined within a module
|
||||
to one of call_rcu(), call_srcu(), call_rcu_tasks(), or
|
||||
call_rcu_tasks_trace(), then it is necessary to wait for all
|
||||
pending callbacks to be invoked before unloading that module.
|
||||
Note that it is absolutely *not* sufficient to wait for a grace
|
||||
period! For example, synchronize_rcu() implementation is *not*
|
||||
|
|
@ -522,7 +519,6 @@ over a rather long period of time, but improvements are always welcome!
|
|||
- call_rcu() -> rcu_barrier()
|
||||
- call_srcu() -> srcu_barrier()
|
||||
- call_rcu_tasks() -> rcu_barrier_tasks()
|
||||
- call_rcu_tasks_rude() -> rcu_barrier_tasks_rude()
|
||||
- call_rcu_tasks_trace() -> rcu_barrier_tasks_trace()
|
||||
|
||||
However, these barrier functions are absolutely *not* guaranteed
|
||||
|
|
@ -539,7 +535,6 @@ over a rather long period of time, but improvements are always welcome!
|
|||
- Either synchronize_srcu() or synchronize_srcu_expedited(),
|
||||
together with and srcu_barrier()
|
||||
- synchronize_rcu_tasks() and rcu_barrier_tasks()
|
||||
- synchronize_tasks_rude() and rcu_barrier_tasks_rude()
|
||||
- synchronize_tasks_trace() and rcu_barrier_tasks_trace()
|
||||
|
||||
If necessary, you can use something like workqueues to execute
|
||||
|
|
|
|||
|
|
@ -1103,7 +1103,7 @@ RCU-Tasks-Rude::
|
|||
|
||||
Critical sections Grace period Barrier
|
||||
|
||||
N/A call_rcu_tasks_rude rcu_barrier_tasks_rude
|
||||
N/A N/A
|
||||
synchronize_rcu_tasks_rude
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ commands (does not impact QAIC).
|
|||
uAPI
|
||||
====
|
||||
|
||||
QAIC creates an accel device per phsyical PCIe device. This accel device exists
|
||||
QAIC creates an accel device per physical PCIe device. This accel device exists
|
||||
for as long as the PCIe device is known to Linux.
|
||||
|
||||
The PCIe device may not be in the state to accept requests from userspace at
|
||||
|
|
|
|||
|
|
@ -47,3 +47,4 @@ subdirectories.
|
|||
tomoyo
|
||||
Yama
|
||||
SafeSetID
|
||||
ipe
|
||||
|
|
|
|||
790
Documentation/admin-guide/LSM/ipe.rst
Normal file
790
Documentation/admin-guide/LSM/ipe.rst
Normal file
|
|
@ -0,0 +1,790 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Integrity Policy Enforcement (IPE)
|
||||
==================================
|
||||
|
||||
.. NOTE::
|
||||
|
||||
This is the documentation for admins, system builders, or individuals
|
||||
attempting to use IPE. If you're looking for more developer-focused
|
||||
documentation about IPE please see :doc:`the design docs </security/ipe>`.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Integrity Policy Enforcement (IPE) is a Linux Security Module that takes a
|
||||
complementary approach to access control. Unlike traditional access control
|
||||
mechanisms that rely on labels and paths for decision-making, IPE focuses
|
||||
on the immutable security properties inherent to system components. These
|
||||
properties are fundamental attributes or features of a system component
|
||||
that cannot be altered, ensuring a consistent and reliable basis for
|
||||
security decisions.
|
||||
|
||||
To elaborate, in the context of IPE, system components primarily refer to
|
||||
files or the devices these files reside on. However, this is just a
|
||||
starting point. The concept of system components is flexible and can be
|
||||
extended to include new elements as the system evolves. The immutable
|
||||
properties include the origin of a file, which remains constant and
|
||||
unchangeable over time. For example, IPE policies can be crafted to trust
|
||||
files originating from the initramfs. Since initramfs is typically verified
|
||||
by the bootloader, its files are deemed trustworthy; "file is from
|
||||
initramfs" becomes an immutable property under IPE's consideration.
|
||||
|
||||
The immutable property concept extends to the security features enabled on
|
||||
a file's origin, such as dm-verity or fs-verity, which provide a layer of
|
||||
integrity and trust. For example, IPE allows the definition of policies
|
||||
that trust files from a dm-verity protected device. dm-verity ensures the
|
||||
integrity of an entire device by providing a verifiable and immutable state
|
||||
of its contents. Similarly, fs-verity offers filesystem-level integrity
|
||||
checks, allowing IPE to enforce policies that trust files protected by
|
||||
fs-verity. These two features cannot be turned off once established, so
|
||||
they are considered immutable properties. These examples demonstrate how
|
||||
IPE leverages immutable properties, such as a file's origin and its
|
||||
integrity protection mechanisms, to make access control decisions.
|
||||
|
||||
For the IPE policy, specifically, it grants the ability to enforce
|
||||
stringent access controls by assessing security properties against
|
||||
reference values defined within the policy. This assessment can be based on
|
||||
the existence of a security property (e.g., verifying if a file originates
|
||||
from initramfs) or evaluating the internal state of an immutable security
|
||||
property. The latter includes checking the roothash of a dm-verity
|
||||
protected device, determining whether dm-verity possesses a valid
|
||||
signature, assessing the digest of a fs-verity protected file, or
|
||||
determining whether fs-verity possesses a valid built-in signature. This
|
||||
nuanced approach to policy enforcement enables a highly secure and
|
||||
customizable system defense mechanism, tailored to specific security
|
||||
requirements and trust models.
|
||||
|
||||
To enable IPE, ensure that ``CONFIG_SECURITY_IPE`` (under
|
||||
:menuselection:`Security -> Integrity Policy Enforcement (IPE)`) config
|
||||
option is enabled.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
IPE works best in fixed-function devices: devices in which their purpose
|
||||
is clearly defined and not supposed to be changed (e.g. network firewall
|
||||
device in a data center, an IoT device, etcetera), where all software and
|
||||
configuration is built and provisioned by the system owner.
|
||||
|
||||
IPE is a long-way off for use in general-purpose computing: the Linux
|
||||
community as a whole tends to follow a decentralized trust model (known as
|
||||
the web of trust), which IPE has no support for it yet. Instead, IPE
|
||||
supports PKI (public key infrastructure), which generally designates a
|
||||
set of trusted entities that provide a measure of absolute trust.
|
||||
|
||||
Additionally, while most packages are signed today, the files inside
|
||||
the packages (for instance, the executables), tend to be unsigned. This
|
||||
makes it difficult to utilize IPE in systems where a package manager is
|
||||
expected to be functional, without major changes to the package manager
|
||||
and ecosystem behind it.
|
||||
|
||||
The digest_cache LSM [#digest_cache_lsm]_ is a system that when combined with IPE,
|
||||
could be used to enable and support general-purpose computing use cases.
|
||||
|
||||
Known Limitations
|
||||
-----------------
|
||||
|
||||
IPE cannot verify the integrity of anonymous executable memory, such as
|
||||
the trampolines created by gcc closures and libffi (<3.4.2), or JIT'd code.
|
||||
Unfortunately, as this is dynamically generated code, there is no way
|
||||
for IPE to ensure the integrity of this code to form a trust basis.
|
||||
|
||||
IPE cannot verify the integrity of programs written in interpreted
|
||||
languages when these scripts are invoked by passing these program files
|
||||
to the interpreter. This is because the way interpreters execute these
|
||||
files; the scripts themselves are not evaluated as executable code
|
||||
through one of IPE's hooks, but they are merely text files that are read
|
||||
(as opposed to compiled executables) [#interpreters]_.
|
||||
|
||||
Threat Model
|
||||
------------
|
||||
|
||||
IPE specifically targets the risk of tampering with user-space executable
|
||||
code after the kernel has initially booted, including the kernel modules
|
||||
loaded from userspace via ``modprobe`` or ``insmod``.
|
||||
|
||||
To illustrate, consider a scenario where an untrusted binary, possibly
|
||||
malicious, is downloaded along with all necessary dependencies, including a
|
||||
loader and libc. The primary function of IPE in this context is to prevent
|
||||
the execution of such binaries and their dependencies.
|
||||
|
||||
IPE achieves this by verifying the integrity and authenticity of all
|
||||
executable code before allowing them to run. It conducts a thorough
|
||||
check to ensure that the code's integrity is intact and that they match an
|
||||
authorized reference value (digest, signature, etc) as per the defined
|
||||
policy. If a binary does not pass this verification process, either
|
||||
because its integrity has been compromised or it does not meet the
|
||||
authorization criteria, IPE will deny its execution. Additionally, IPE
|
||||
generates audit logs which may be utilized to detect and analyze failures
|
||||
resulting from policy violation.
|
||||
|
||||
Tampering threat scenarios include modification or replacement of
|
||||
executable code by a range of actors including:
|
||||
|
||||
- Actors with physical access to the hardware
|
||||
- Actors with local network access to the system
|
||||
- Actors with access to the deployment system
|
||||
- Compromised internal systems under external control
|
||||
- Malicious end users of the system
|
||||
- Compromised end users of the system
|
||||
- Remote (external) compromise of the system
|
||||
|
||||
IPE does not mitigate threats arising from malicious but authorized
|
||||
developers (with access to a signing certificate), or compromised
|
||||
developer tools used by them (i.e. return-oriented programming attacks).
|
||||
Additionally, IPE draws hard security boundary between userspace and
|
||||
kernelspace. As a result, kernel-level exploits are considered outside
|
||||
the scope of IPE and mitigation is left to other mechanisms.
|
||||
|
||||
Policy
|
||||
------
|
||||
|
||||
IPE policy is a plain-text [#devdoc]_ policy composed of multiple statements
|
||||
over several lines. There is one required line, at the top of the
|
||||
policy, indicating the policy name, and the policy version, for
|
||||
instance::
|
||||
|
||||
policy_name=Ex_Policy policy_version=0.0.0
|
||||
|
||||
The policy name is a unique key identifying this policy in a human
|
||||
readable name. This is used to create nodes under securityfs as well as
|
||||
uniquely identify policies to deploy new policies vs update existing
|
||||
policies.
|
||||
|
||||
The policy version indicates the current version of the policy (NOT the
|
||||
policy syntax version). This is used to prevent rollback of policy to
|
||||
potentially insecure previous versions of the policy.
|
||||
|
||||
The next portion of IPE policy are rules. Rules are formed by key=value
|
||||
pairs, known as properties. IPE rules require two properties: ``action``,
|
||||
which determines what IPE does when it encounters a match against the
|
||||
rule, and ``op``, which determines when the rule should be evaluated.
|
||||
The ordering is significant, a rule must start with ``op``, and end with
|
||||
``action``. Thus, a minimal rule is::
|
||||
|
||||
op=EXECUTE action=ALLOW
|
||||
|
||||
This example will allow any execution. Additional properties are used to
|
||||
assess immutable security properties about the files being evaluated.
|
||||
These properties are intended to be descriptions of systems within the
|
||||
kernel that can provide a measure of integrity verification, such that IPE
|
||||
can determine the trust of the resource based on the value of the property.
|
||||
|
||||
Rules are evaluated top-to-bottom. As a result, any revocation rules,
|
||||
or denies should be placed early in the file to ensure that these rules
|
||||
are evaluated before a rule with ``action=ALLOW``.
|
||||
|
||||
IPE policy supports comments. The character '#' will function as a
|
||||
comment, ignoring all characters to the right of '#' until the newline.
|
||||
|
||||
The default behavior of IPE evaluations can also be expressed in policy,
|
||||
through the ``DEFAULT`` statement. This can be done at a global level,
|
||||
or a per-operation level::
|
||||
|
||||
# Global
|
||||
DEFAULT action=ALLOW
|
||||
|
||||
# Operation Specific
|
||||
DEFAULT op=EXECUTE action=ALLOW
|
||||
|
||||
A default must be set for all known operations in IPE. If you want to
|
||||
preserve older policies being compatible with newer kernels that can introduce
|
||||
new operations, set a global default of ``ALLOW``, then override the
|
||||
defaults on a per-operation basis (as above).
|
||||
|
||||
With configurable policy-based LSMs, there's several issues with
|
||||
enforcing the configurable policies at startup, around reading and
|
||||
parsing the policy:
|
||||
|
||||
1. The kernel *should* not read files from userspace, so directly reading
|
||||
the policy file is prohibited.
|
||||
2. The kernel command line has a character limit, and one kernel module
|
||||
should not reserve the entire character limit for its own
|
||||
configuration.
|
||||
3. There are various boot loaders in the kernel ecosystem, so handing
|
||||
off a memory block would be costly to maintain.
|
||||
|
||||
As a result, IPE has addressed this problem through a concept of a "boot
|
||||
policy". A boot policy is a minimal policy which is compiled into the
|
||||
kernel. This policy is intended to get the system to a state where
|
||||
userspace is set up and ready to receive commands, at which point a more
|
||||
complex policy can be deployed via securityfs. The boot policy can be
|
||||
specified via ``SECURITY_IPE_BOOT_POLICY`` config option, which accepts
|
||||
a path to a plain-text version of the IPE policy to apply. This policy
|
||||
will be compiled into the kernel. If not specified, IPE will be disabled
|
||||
until a policy is deployed and activated through securityfs.
|
||||
|
||||
Deploying Policies
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Policies can be deployed from userspace through securityfs. These policies
|
||||
are signed through the PKCS#7 message format to enforce some level of
|
||||
authorization of the policies (prohibiting an attacker from gaining
|
||||
unconstrained root, and deploying an "allow all" policy). These
|
||||
policies must be signed by a certificate that chains to the
|
||||
``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by::
|
||||
|
||||
openssl smime -sign \
|
||||
-in "$MY_POLICY" \
|
||||
-signer "$MY_CERTIFICATE" \
|
||||
-inkey "$MY_PRIVATE_KEY" \
|
||||
-noattr \
|
||||
-nodetach \
|
||||
-nosmimecap \
|
||||
-outform der \
|
||||
-out "$MY_POLICY.p7b"
|
||||
|
||||
Deploying the policies is done through securityfs, through the
|
||||
``new_policy`` node. To deploy a policy, simply cat the file into the
|
||||
securityfs node::
|
||||
|
||||
cat "$MY_POLICY.p7b" > /sys/kernel/security/ipe/new_policy
|
||||
|
||||
Upon success, this will create one subdirectory under
|
||||
``/sys/kernel/security/ipe/policies/``. The subdirectory will be the
|
||||
``policy_name`` field of the policy deployed, so for the example above,
|
||||
the directory will be ``/sys/kernel/security/ipe/policies/Ex_Policy``.
|
||||
Within this directory, there will be seven files: ``pkcs7``, ``policy``,
|
||||
``name``, ``version``, ``active``, ``update``, and ``delete``.
|
||||
|
||||
The ``pkcs7`` file is read-only. Reading it returns the raw PKCS#7 data
|
||||
that was provided to the kernel, representing the policy. If the policy being
|
||||
read is the boot policy, this will return ``ENOENT``, as it is not signed.
|
||||
|
||||
The ``policy`` file is read only. Reading it returns the PKCS#7 inner
|
||||
content of the policy, which will be the plain text policy.
|
||||
|
||||
The ``active`` file is used to set a policy as the currently active policy.
|
||||
This file is rw, and accepts a value of ``"1"`` to set the policy as active.
|
||||
Since only a single policy can be active at one time, all other policies
|
||||
will be marked inactive. The policy being marked active must have a policy
|
||||
version greater or equal to the currently-running version.
|
||||
|
||||
The ``update`` file is used to update a policy that is already present
|
||||
in the kernel. This file is write-only and accepts a PKCS#7 signed
|
||||
policy. Two checks will always be performed on this policy: First, the
|
||||
``policy_names`` must match with the updated version and the existing
|
||||
version. Second the updated policy must have a policy version greater than
|
||||
or equal to the currently-running version. This is to prevent rollback attacks.
|
||||
|
||||
The ``delete`` file is used to remove a policy that is no longer needed.
|
||||
This file is write-only and accepts a value of ``1`` to delete the policy.
|
||||
On deletion, the securityfs node representing the policy will be removed.
|
||||
However, delete the current active policy is not allowed and will return
|
||||
an operation not permitted error.
|
||||
|
||||
Similarly, writing to both ``update`` and ``new_policy`` could result in
|
||||
bad message(policy syntax error) or file exists error. The latter error happens
|
||||
when trying to deploy a policy with a ``policy_name`` while the kernel already
|
||||
has a deployed policy with the same ``policy_name``.
|
||||
|
||||
Deploying a policy will *not* cause IPE to start enforcing the policy. IPE will
|
||||
only enforce the policy marked active. Note that only one policy can be active
|
||||
at a time.
|
||||
|
||||
Once deployment is successful, the policy can be activated, by writing file
|
||||
``/sys/kernel/security/ipe/policies/$policy_name/active``.
|
||||
For example, the ``Ex_Policy`` can be activated by::
|
||||
|
||||
echo 1 > "/sys/kernel/security/ipe/policies/Ex_Policy/active"
|
||||
|
||||
From above point on, ``Ex_Policy`` is now the enforced policy on the
|
||||
system.
|
||||
|
||||
IPE also provides a way to delete policies. This can be done via the
|
||||
``delete`` securityfs node,
|
||||
``/sys/kernel/security/ipe/policies/$policy_name/delete``.
|
||||
Writing ``1`` to that file deletes the policy::
|
||||
|
||||
echo 1 > "/sys/kernel/security/ipe/policies/$policy_name/delete"
|
||||
|
||||
There is only one requirement to delete a policy: the policy being deleted
|
||||
must be inactive.
|
||||
|
||||
.. NOTE::
|
||||
|
||||
If a traditional MAC system is enabled (SELinux, apparmor, smack), all
|
||||
writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
|
||||
|
||||
Modes
|
||||
~~~~~
|
||||
|
||||
IPE supports two modes of operation: permissive (similar to SELinux's
|
||||
permissive mode) and enforced. In permissive mode, all events are
|
||||
checked and policy violations are logged, but the policy is not really
|
||||
enforced. This allows users to test policies before enforcing them.
|
||||
|
||||
The default mode is enforce, and can be changed via the kernel command
|
||||
line parameter ``ipe.enforce=(0|1)``, or the securityfs node
|
||||
``/sys/kernel/security/ipe/enforce``.
|
||||
|
||||
.. NOTE::
|
||||
|
||||
If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera),
|
||||
all writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
|
||||
|
||||
Audit Events
|
||||
~~~~~~~~~~~~
|
||||
|
||||
1420 AUDIT_IPE_ACCESS
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
Event Examples::
|
||||
|
||||
type=1420 audit(1653364370.067:61): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2241 comm="ld-linux.so" path="/deny/lib/libc.so.6" dev="sda2" ino=14549020 rule="DEFAULT action=DENY"
|
||||
type=1300 audit(1653364370.067:61): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=7f1105a28000 a1=195000 a2=5 a3=812 items=0 ppid=2219 pid=2241 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ld-linux.so" exe="/tmp/ipe-test/lib/ld-linux.so" subj=unconfined key=(null)
|
||||
type=1327 audit(1653364370.067:61): 707974686F6E3300746573742F6D61696E2E7079002D6E00
|
||||
|
||||
type=1420 audit(1653364735.161:64): ipe_op=EXECUTE ipe_hook=MMAP enforcing=1 pid=2472 comm="mmap_test" path=? dev=? ino=? rule="DEFAULT action=DENY"
|
||||
type=1300 audit(1653364735.161:64): SYSCALL arch=c000003e syscall=9 success=no exit=-13 a0=0 a1=1000 a2=4 a3=21 items=0 ppid=2219 pid=2472 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="mmap_test" exe="/root/overlake_test/upstream_test/vol_fsverity/bin/mmap_test" subj=unconfined key=(null)
|
||||
type=1327 audit(1653364735.161:64): 707974686F6E3300746573742F6D61696E2E7079002D6E00
|
||||
|
||||
This event indicates that IPE made an access control decision; the IPE
|
||||
specific record (1420) is always emitted in conjunction with a
|
||||
``AUDITSYSCALL`` record.
|
||||
|
||||
Determining whether IPE is in permissive or enforced mode can be derived
|
||||
from ``success`` property and exit code of the ``AUDITSYSCALL`` record.
|
||||
|
||||
|
||||
Field descriptions:
|
||||
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| Field | Value Type | Optional? | Description of Value |
|
||||
+===========+============+===========+=================================================================================+
|
||||
| ipe_op | string | No | The IPE operation name associated with the log |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| ipe_hook | string | No | The name of the LSM hook that triggered the IPE event |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| enforcing | integer | No | The current IPE enforcing state 1 is in enforcing mode, 0 is in permissive mode |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| pid | integer | No | The pid of the process that triggered the IPE event. |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| comm | string | No | The command line program name of the process that triggered the IPE event |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| path | string | Yes | The absolute path to the evaluated file |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| ino | integer | Yes | The inode number of the evaluated file |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| dev | string | Yes | The device name of the evaluated file, e.g. vda |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
| rule | string | No | The matched policy rule |
|
||||
+-----------+------------+-----------+---------------------------------------------------------------------------------+
|
||||
|
||||
1421 AUDIT_IPE_CONFIG_CHANGE
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Event Example::
|
||||
|
||||
type=1421 audit(1653425583.136:54): old_active_pol_name="Allow_All" old_active_pol_version=0.0.0 old_policy_digest=sha256:E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 new_active_pol_name="boot_verified" new_active_pol_version=0.0.0 new_policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1
|
||||
type=1300 audit(1653425583.136:54): SYSCALL arch=c000003e syscall=1 success=yes exit=2 a0=3 a1=5596fcae1fb0 a2=2 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
|
||||
type=1327 audit(1653425583.136:54): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2
|
||||
|
||||
This event indicates that IPE switched the active poliy from one to another
|
||||
along with the version and the hash digest of the two policies.
|
||||
Note IPE can only have one policy active at a time, all access decision
|
||||
evaluation is based on the current active policy.
|
||||
The normal procedure to deploy a new policy is loading the policy to deploy
|
||||
into the kernel first, then switch the active policy to it.
|
||||
|
||||
This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
|
||||
|
||||
Field descriptions:
|
||||
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| Field | Value Type | Optional? | Description of Value |
|
||||
+========================+============+===========+===================================================+
|
||||
| old_active_pol_name | string | Yes | The name of previous active policy |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| old_active_pol_version | string | Yes | The version of previous active policy |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| old_policy_digest | string | Yes | The hash of previous active policy |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| new_active_pol_name | string | No | The name of current active policy |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| new_active_pol_version | string | No | The version of current active policy |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| new_policy_digest | string | No | The hash of current active policy |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| auid | integer | No | The login user ID |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| ses | integer | No | The login session ID |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| lsm | string | No | The lsm name associated with the event |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
| res | integer | No | The result of the audited operation(success/fail) |
|
||||
+------------------------+------------+-----------+---------------------------------------------------+
|
||||
|
||||
1422 AUDIT_IPE_POLICY_LOAD
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Event Example::
|
||||
|
||||
type=1422 audit(1653425529.927:53): policy_name="boot_verified" policy_version=0.0.0 policy_digest=sha256:820EEA5B40CA42B51F68962354BA083122A20BB846F26765076DD8EED7B8F4DB auid=4294967295 ses=4294967295 lsm=ipe res=1
|
||||
type=1300 audit(1653425529.927:53): arch=c000003e syscall=1 success=yes exit=2567 a0=3 a1=5596fcae1fb0 a2=a07 a3=2 items=0 ppid=184 pid=229 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="python3" exe="/usr/bin/python3.10" key=(null)
|
||||
type=1327 audit(1653425529.927:53): PROCTITLE proctitle=707974686F6E3300746573742F6D61696E2E7079002D66002E2E
|
||||
|
||||
This record indicates a new policy has been loaded into the kernel with the policy name, policy version and policy hash.
|
||||
|
||||
This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
|
||||
|
||||
Field descriptions:
|
||||
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
| Field | Value Type | Optional? | Description of Value |
|
||||
+================+============+===========+===================================================+
|
||||
| policy_name | string | No | The policy_name |
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
| policy_version | string | No | The policy_version |
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
| policy_digest | string | No | The policy hash |
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
| auid | integer | No | The login user ID |
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
| ses | integer | No | The login session ID |
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
| lsm | string | No | The lsm name associated with the event |
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
| res | integer | No | The result of the audited operation(success/fail) |
|
||||
+----------------+------------+-----------+---------------------------------------------------+
|
||||
|
||||
|
||||
1404 AUDIT_MAC_STATUS
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Event Examples::
|
||||
|
||||
type=1404 audit(1653425689.008:55): enforcing=0 old_enforcing=1 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
|
||||
type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
|
||||
type=1327 audit(1653425689.008:55): proctitle="-bash"
|
||||
|
||||
type=1404 audit(1653425689.008:55): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=ipe res=1
|
||||
type=1300 audit(1653425689.008:55): arch=c000003e syscall=1 success=yes exit=2 a0=1 a1=55c1065e5c60 a2=2 a3=0 items=0 ppid=405 pid=441 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=)
|
||||
type=1327 audit(1653425689.008:55): proctitle="-bash"
|
||||
|
||||
This record will always be emitted in conjunction with a ``AUDITSYSCALL`` record for the ``write`` syscall.
|
||||
|
||||
Field descriptions:
|
||||
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| Field | Value Type | Optional? | Description of Value |
|
||||
+===============+============+===========+=================================================================================================+
|
||||
| enforcing | integer | No | The enforcing state IPE is being switched to, 1 is in enforcing mode, 0 is in permissive mode |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| old_enforcing | integer | No | The enforcing state IPE is being switched from, 1 is in enforcing mode, 0 is in permissive mode |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| auid | integer | No | The login user ID |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| ses | integer | No | The login session ID |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| enabled | integer | No | The new TTY audit enabled setting |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| old-enabled | integer | No | The old TTY audit enabled setting |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| lsm | string | No | The lsm name associated with the event |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
| res | integer | No | The result of the audited operation(success/fail) |
|
||||
+---------------+------------+-----------+-------------------------------------------------------------------------------------------------+
|
||||
|
||||
|
||||
Success Auditing
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
IPE supports success auditing. When enabled, all events that pass IPE
|
||||
policy and are not blocked will emit an audit event. This is disabled by
|
||||
default, and can be enabled via the kernel command line
|
||||
``ipe.success_audit=(0|1)`` or
|
||||
``/sys/kernel/security/ipe/success_audit`` securityfs file.
|
||||
|
||||
This is *very* noisy, as IPE will check every userspace binary on the
|
||||
system, but is useful for debugging policies.
|
||||
|
||||
.. NOTE::
|
||||
|
||||
If a traditional MAC system is enabled (SELinux, apparmor, smack, etcetera),
|
||||
all writes to ipe's securityfs nodes require ``CAP_MAC_ADMIN``.
|
||||
|
||||
Properties
|
||||
----------
|
||||
|
||||
As explained above, IPE properties are ``key=value`` pairs expressed in IPE
|
||||
policy. Two properties are built-into the policy parser: 'op' and 'action'.
|
||||
The other properties are used to restrict immutable security properties
|
||||
about the files being evaluated. Currently those properties are:
|
||||
'``boot_verified``', '``dmverity_signature``', '``dmverity_roothash``',
|
||||
'``fsverity_signature``', '``fsverity_digest``'. A description of all
|
||||
properties supported by IPE are listed below:
|
||||
|
||||
op
|
||||
~~
|
||||
|
||||
Indicates the operation for a rule to apply to. Must be in every rule,
|
||||
as the first token. IPE supports the following operations:
|
||||
|
||||
``EXECUTE``
|
||||
|
||||
Pertains to any file attempting to be executed, or loaded as an
|
||||
executable.
|
||||
|
||||
``FIRMWARE``:
|
||||
|
||||
Pertains to firmware being loaded via the firmware_class interface.
|
||||
This covers both the preallocated buffer and the firmware file
|
||||
itself.
|
||||
|
||||
``KMODULE``:
|
||||
|
||||
Pertains to loading kernel modules via ``modprobe`` or ``insmod``.
|
||||
|
||||
``KEXEC_IMAGE``:
|
||||
|
||||
Pertains to kernel images loading via ``kexec``.
|
||||
|
||||
``KEXEC_INITRAMFS``
|
||||
|
||||
Pertains to initrd images loading via ``kexec --initrd``.
|
||||
|
||||
``POLICY``:
|
||||
|
||||
Controls loading policies via reading a kernel-space initiated read.
|
||||
|
||||
An example of such is loading IMA policies by writing the path
|
||||
to the policy file to ``$securityfs/ima/policy``
|
||||
|
||||
``X509_CERT``:
|
||||
|
||||
Controls loading IMA certificates through the Kconfigs,
|
||||
``CONFIG_IMA_X509_PATH`` and ``CONFIG_EVM_X509_PATH``.
|
||||
|
||||
action
|
||||
~~~~~~
|
||||
|
||||
Determines what IPE should do when a rule matches. Must be in every
|
||||
rule, as the final clause. Can be one of:
|
||||
|
||||
``ALLOW``:
|
||||
|
||||
If the rule matches, explicitly allow access to the resource to proceed
|
||||
without executing any more rules.
|
||||
|
||||
``DENY``:
|
||||
|
||||
If the rule matches, explicitly prohibit access to the resource to
|
||||
proceed without executing any more rules.
|
||||
|
||||
boot_verified
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
This property can be utilized for authorization of files from initramfs.
|
||||
The format of this property is::
|
||||
|
||||
boot_verified=(TRUE|FALSE)
|
||||
|
||||
|
||||
.. WARNING::
|
||||
|
||||
This property will trust files from initramfs(rootfs). It should
|
||||
only be used during early booting stage. Before mounting the real
|
||||
rootfs on top of the initramfs, initramfs script will recursively
|
||||
remove all files and directories on the initramfs. This is typically
|
||||
implemented by using switch_root(8) [#switch_root]_. Therefore the
|
||||
initramfs will be empty and not accessible after the real
|
||||
rootfs takes over. It is advised to switch to a different policy
|
||||
that doesn't rely on the property after this point.
|
||||
This ensures that the trust policies remain relevant and effective
|
||||
throughout the system's operation.
|
||||
|
||||
dmverity_roothash
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
This property can be utilized for authorization or revocation of
|
||||
specific dm-verity volumes, identified via their root hashes. It has a
|
||||
dependency on the DM_VERITY module. This property is controlled by
|
||||
the ``IPE_PROP_DM_VERITY`` config option, it will be automatically
|
||||
selected when ``SECURITY_IPE`` and ``DM_VERITY`` are all enabled.
|
||||
The format of this property is::
|
||||
|
||||
dmverity_roothash=DigestName:HexadecimalString
|
||||
|
||||
The supported DigestNames for dmverity_roothash are [#dmveritydigests]_
|
||||
|
||||
+ blake2b-512
|
||||
+ blake2s-256
|
||||
+ sha256
|
||||
+ sha384
|
||||
+ sha512
|
||||
+ sha3-224
|
||||
+ sha3-256
|
||||
+ sha3-384
|
||||
+ sha3-512
|
||||
+ sm3
|
||||
+ rmd160
|
||||
|
||||
dmverity_signature
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This property can be utilized for authorization of all dm-verity
|
||||
volumes that have a signed roothash that validated by a keyring
|
||||
specified by dm-verity's configuration, either the system trusted
|
||||
keyring, or the secondary keyring. It depends on
|
||||
``DM_VERITY_VERIFY_ROOTHASH_SIG`` config option and is controlled by
|
||||
the ``IPE_PROP_DM_VERITY_SIGNATURE`` config option, it will be automatically
|
||||
selected when ``SECURITY_IPE``, ``DM_VERITY`` and
|
||||
``DM_VERITY_VERIFY_ROOTHASH_SIG`` are all enabled.
|
||||
The format of this property is::
|
||||
|
||||
dmverity_signature=(TRUE|FALSE)
|
||||
|
||||
fsverity_digest
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
This property can be utilized for authorization of specific fsverity
|
||||
enabled files, identified via their fsverity digests.
|
||||
It depends on ``FS_VERITY`` config option and is controlled by
|
||||
the ``IPE_PROP_FS_VERITY`` config option, it will be automatically
|
||||
selected when ``SECURITY_IPE`` and ``FS_VERITY`` are all enabled.
|
||||
The format of this property is::
|
||||
|
||||
fsverity_digest=DigestName:HexadecimalString
|
||||
|
||||
The supported DigestNames for fsverity_digest are [#fsveritydigest]_
|
||||
|
||||
+ sha256
|
||||
+ sha512
|
||||
|
||||
fsverity_signature
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This property is used to authorize all fs-verity enabled files that have
|
||||
been verified by fs-verity's built-in signature mechanism. The signature
|
||||
verification relies on a key stored within the ".fs-verity" keyring. It
|
||||
depends on ``FS_VERITY_BUILTIN_SIGNATURES`` config option and
|
||||
it is controlled by the ``IPE_PROP_FS_VERITY`` config option,
|
||||
it will be automatically selected when ``SECURITY_IPE``, ``FS_VERITY``
|
||||
and ``FS_VERITY_BUILTIN_SIGNATURES`` are all enabled.
|
||||
The format of this property is::
|
||||
|
||||
fsverity_signature=(TRUE|FALSE)
|
||||
|
||||
Policy Examples
|
||||
---------------
|
||||
|
||||
Allow all
|
||||
~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
policy_name=Allow_All policy_version=0.0.0
|
||||
DEFAULT action=ALLOW
|
||||
|
||||
Allow only initramfs
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
policy_name=Allow_Initramfs policy_version=0.0.0
|
||||
DEFAULT action=DENY
|
||||
|
||||
op=EXECUTE boot_verified=TRUE action=ALLOW
|
||||
|
||||
Allow any signed and validated dm-verity volume and the initramfs
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
policy_name=Allow_Signed_DMV_And_Initramfs policy_version=0.0.0
|
||||
DEFAULT action=DENY
|
||||
|
||||
op=EXECUTE boot_verified=TRUE action=ALLOW
|
||||
op=EXECUTE dmverity_signature=TRUE action=ALLOW
|
||||
|
||||
Prohibit execution from a specific dm-verity volume
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
policy_name=Deny_DMV_By_Roothash policy_version=0.0.0
|
||||
DEFAULT action=DENY
|
||||
|
||||
op=EXECUTE dmverity_roothash=sha256:cd2c5bae7c6c579edaae4353049d58eb5f2e8be0244bf05345bc8e5ed257baff action=DENY
|
||||
|
||||
op=EXECUTE boot_verified=TRUE action=ALLOW
|
||||
op=EXECUTE dmverity_signature=TRUE action=ALLOW
|
||||
|
||||
Allow only a specific dm-verity volume
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
policy_name=Allow_DMV_By_Roothash policy_version=0.0.0
|
||||
DEFAULT action=DENY
|
||||
|
||||
op=EXECUTE dmverity_roothash=sha256:401fcec5944823ae12f62726e8184407a5fa9599783f030dec146938 action=ALLOW
|
||||
|
||||
Allow any fs-verity file with a valid built-in signature
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
policy_name=Allow_Signed_And_Validated_FSVerity policy_version=0.0.0
|
||||
DEFAULT action=DENY
|
||||
|
||||
op=EXECUTE fsverity_signature=TRUE action=ALLOW
|
||||
|
||||
Allow execution of a specific fs-verity file
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
::
|
||||
|
||||
policy_name=ALLOW_FSV_By_Digest policy_version=0.0.0
|
||||
DEFAULT action=DENY
|
||||
|
||||
op=EXECUTE fsverity_digest=sha256:fd88f2b8824e197f850bf4c5109bea5cf0ee38104f710843bb72da796ba5af9e action=ALLOW
|
||||
|
||||
Additional Information
|
||||
----------------------
|
||||
|
||||
- `Github Repository <https://github.com/microsoft/ipe>`_
|
||||
- :doc:`Developer and design docs for IPE </security/ipe>`
|
||||
|
||||
FAQ
|
||||
---
|
||||
|
||||
Q:
|
||||
What's the difference between other LSMs which provide a measure of
|
||||
trust-based access control?
|
||||
|
||||
A:
|
||||
|
||||
In general, there's two other LSMs that can provide similar functionality:
|
||||
IMA, and Loadpin.
|
||||
|
||||
IMA and IPE are functionally very similar. The significant difference between
|
||||
the two is the policy. [#devdoc]_
|
||||
|
||||
Loadpin and IPE differ fairly dramatically, as Loadpin only covers the IPE's
|
||||
kernel read operations, whereas IPE is capable of controlling execution
|
||||
on top of kernel read. The trust model is also different; Loadpin roots its
|
||||
trust in the initial super-block, whereas trust in IPE is stemmed from kernel
|
||||
itself (via ``SYSTEM_TRUSTED_KEYS``).
|
||||
|
||||
-----------
|
||||
|
||||
.. [#digest_cache_lsm] https://lore.kernel.org/lkml/20240415142436.2545003-1-roberto.sassu@huaweicloud.com/
|
||||
|
||||
.. [#interpreters] There is `some interest in solving this issue <https://lore.kernel.org/lkml/20220321161557.495388-1-mic@digikod.net/>`_.
|
||||
|
||||
.. [#devdoc] Please see :doc:`the design docs </security/ipe>` for more on
|
||||
this topic.
|
||||
|
||||
.. [#switch_root] https://man7.org/linux/man-pages/man8/switch_root.8.html
|
||||
|
||||
.. [#dmveritydigests] These hash algorithms are based on values accepted by
|
||||
the Linux crypto API; IPE does not impose any
|
||||
restrictions on the digest algorithm itself;
|
||||
thus, this list may be out of date.
|
||||
|
||||
.. [#fsveritydigest] These hash algorithms are based on values accepted by the
|
||||
kernel's fsverity support; IPE does not impose any
|
||||
restrictions on the digest algorithm itself;
|
||||
thus, this list may be out of date.
|
||||
|
|
@ -1,76 +1,144 @@
|
|||
Bisecting a bug
|
||||
+++++++++++++++
|
||||
.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
|
||||
.. [see the bottom of this file for redistribution information]
|
||||
|
||||
Last updated: 28 October 2016
|
||||
======================
|
||||
Bisecting a regression
|
||||
======================
|
||||
|
||||
Introduction
|
||||
============
|
||||
This document describes how to use a ``git bisect`` to find the source code
|
||||
change that broke something -- for example when some functionality stopped
|
||||
working after upgrading from Linux 6.0 to 6.1.
|
||||
|
||||
Always try the latest kernel from kernel.org and build from source. If you are
|
||||
not confident in doing that please report the bug to your distribution vendor
|
||||
instead of to a kernel developer.
|
||||
The text focuses on the gist of the process. If you are new to bisecting the
|
||||
kernel, better follow Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
|
||||
instead: it depicts everything from start to finish while covering multiple
|
||||
aspects even kernel developers occasionally forget. This includes detecting
|
||||
situations early where a bisection would be a waste of time, as nobody would
|
||||
care about the result -- for example, because the problem happens after the
|
||||
kernel marked itself as 'tainted', occurs in an abandoned version, was already
|
||||
fixed, or is caused by a .config change you or your Linux distributor performed.
|
||||
|
||||
Finding bugs is not always easy. Have a go though. If you can't find it don't
|
||||
give up. Report as much as you have found to the relevant maintainer. See
|
||||
MAINTAINERS for who that is for the subsystem you have worked on.
|
||||
Finding the change causing a kernel issue using a bisection
|
||||
===========================================================
|
||||
|
||||
Before you submit a bug report read
|
||||
'Documentation/admin-guide/reporting-issues.rst'.
|
||||
*Note: the following process assumes you prepared everything for a bisection.
|
||||
This includes having a Git clone with the appropriate sources, installing the
|
||||
software required to build and install kernels, as well as a .config file stored
|
||||
in a safe place (the following example assumes '~/prepared_kernel_.config') to
|
||||
use as pristine base at each bisection step; ideally, you have also worked out
|
||||
a fully reliable and straight-forward way to reproduce the regression, too.*
|
||||
|
||||
Devices not appearing
|
||||
=====================
|
||||
* Preparation: start the bisection and tell Git about the points in the history
|
||||
you consider to be working and broken, which Git calls 'good' and 'bad'::
|
||||
|
||||
Often this is caused by udev/systemd. Check that first before blaming it
|
||||
on the kernel.
|
||||
git bisect start
|
||||
git bisect good v6.0
|
||||
git bisect bad v6.1
|
||||
|
||||
Finding patch that caused a bug
|
||||
===============================
|
||||
Instead of Git tags like 'v6.0' and 'v6.1' you can specify commit-ids, too.
|
||||
|
||||
Using the provided tools with ``git`` makes finding bugs easy provided the bug
|
||||
is reproducible.
|
||||
1. Copy your prepared .config into the build directory and adjust it to the
|
||||
needs of the codebase Git checked out for testing::
|
||||
|
||||
Steps to do it:
|
||||
cp ~/prepared_kernel_.config .config
|
||||
make olddefconfig
|
||||
|
||||
- build the Kernel from its git source
|
||||
- start bisect with [#f1]_::
|
||||
2. Now build, install, and boot a kernel. This might fail for unrelated reasons,
|
||||
for example, when a compile error happens at the current stage of the
|
||||
bisection a later change resolves. In such cases run ``git bisect skip`` and
|
||||
go back to step 1.
|
||||
|
||||
$ git bisect start
|
||||
3. Check if the functionality that regressed works in the kernel you just built.
|
||||
|
||||
- mark the broken changeset with::
|
||||
If it works, execute::
|
||||
|
||||
$ git bisect bad [commit]
|
||||
git bisect good
|
||||
|
||||
- mark a changeset where the code is known to work with::
|
||||
If it is broken, run::
|
||||
|
||||
$ git bisect good [commit]
|
||||
git bisect bad
|
||||
|
||||
- rebuild the Kernel and test
|
||||
- interact with git bisect by using either::
|
||||
Note, getting this wrong just once will send the rest of the bisection
|
||||
totally off course. To prevent having to start anew later you thus want to
|
||||
ensure what you tell Git is correct; it is thus often wise to spend a few
|
||||
minutes more on testing in case your reproducer is unreliable.
|
||||
|
||||
$ git bisect good
|
||||
After issuing one of these two commands, Git will usually check out another
|
||||
bisection point and print something like 'Bisecting: 675 revisions left to
|
||||
test after this (roughly 10 steps)'. In that case go back to step 1.
|
||||
|
||||
or::
|
||||
If Git instead prints something like 'cafecaca0c0dacafecaca0c0dacafecaca0c0da
|
||||
is the first bad commit', then you have finished the bisection. In that case
|
||||
move to the next point below. Note, right after displaying that line Git will
|
||||
show some details about the culprit including its patch description; this can
|
||||
easily fill your terminal, so you might need to scroll up to see the message
|
||||
mentioning the culprit's commit-id.
|
||||
|
||||
$ git bisect bad
|
||||
In case you missed Git's output, you can always run ``git bisect log`` to
|
||||
print the status: it will show how many steps remain or mention the result of
|
||||
the bisection.
|
||||
|
||||
depending if the bug happened on the changeset you're testing
|
||||
- After some interactions, git bisect will give you the changeset that
|
||||
likely caused the bug.
|
||||
* Recommended complementary task: put the bisection log and the current .config
|
||||
file aside for the bug report; furthermore tell Git to reset the sources to
|
||||
the state before the bisection::
|
||||
|
||||
- For example, if you know that the current version is bad, and version
|
||||
4.8 is good, you could do::
|
||||
git bisect log > ~/bisection-log
|
||||
cp .config ~/bisection-config-culprit
|
||||
git bisect reset
|
||||
|
||||
$ git bisect start
|
||||
$ git bisect bad # Current version is bad
|
||||
$ git bisect good v4.8
|
||||
* Recommended optional task: try reverting the culprit on top of the latest
|
||||
codebase and check if that fixes your bug; if that is the case, it validates
|
||||
the bisection and enables developers to resolve the regression through a
|
||||
revert.
|
||||
|
||||
To try this, update your clone and check out latest mainline. Then tell Git
|
||||
to revert the change by specifying its commit-id::
|
||||
|
||||
git revert --no-edit cafec0cacaca0
|
||||
|
||||
Git might reject this, for example when the bisection landed on a merge
|
||||
commit. In that case, abandon the attempt. Do the same, if Git fails to revert
|
||||
the culprit on its own because later changes depend on it -- at least unless
|
||||
you bisected a stable or longterm kernel series, in which case you want to
|
||||
check out its latest codebase and try a revert there.
|
||||
|
||||
If a revert succeeds, build and test another kernel to check if reverting
|
||||
resolved your regression.
|
||||
|
||||
With that the process is complete. Now report the regression as described by
|
||||
Documentation/admin-guide/reporting-issues.rst.
|
||||
|
||||
|
||||
.. [#f1] You can, optionally, provide both good and bad arguments at git
|
||||
start with ``git bisect start [BAD] [GOOD]``
|
||||
Additional reading material
|
||||
---------------------------
|
||||
|
||||
For further references, please read:
|
||||
* The `man page for 'git bisect' <https://git-scm.com/docs/git-bisect>`_ and
|
||||
`fighting regressions with 'git bisect' <https://git-scm.com/docs/git-bisect-lk2009.html>`_
|
||||
in the Git documentation.
|
||||
* `Working with git bisect <https://nathanchance.dev/posts/working-with-git-bisect/>`_
|
||||
from kernel developer Nathan Chancellor.
|
||||
* `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_.
|
||||
* `Fully automated bisecting with 'git bisect run' <https://lwn.net/Articles/317154>`_.
|
||||
|
||||
- The man page for ``git-bisect``
|
||||
- `Fighting regressions with git bisect <https://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html>`_
|
||||
- `Fully automated bisecting with "git bisect run" <https://lwn.net/Articles/317154>`_
|
||||
- `Using Git bisect to figure out when brokenness was introduced <http://webchick.net/node/99>`_
|
||||
..
|
||||
end-of-content
|
||||
..
|
||||
This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If
|
||||
you spot a typo or small mistake, feel free to let him know directly and
|
||||
he'll fix it. You are free to do the same in a mostly informal way if you
|
||||
want to contribute changes to the text -- but for copyright reasons please CC
|
||||
linux-doc@vger.kernel.org and 'sign-off' your contribution as
|
||||
Documentation/process/submitting-patches.rst explains in the section 'Sign
|
||||
your work - the Developer's Certificate of Origin'.
|
||||
..
|
||||
This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top
|
||||
of the file. If you want to distribute this text under CC-BY-4.0 only,
|
||||
please use 'The Linux kernel development community' for author attribution
|
||||
and link this as source:
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/bug-bisect.rst
|
||||
|
||||
..
|
||||
Note: Only the content of this RST file as found in the Linux kernel sources
|
||||
is available under CC-BY-4.0, as versions of this text that were processed
|
||||
(for example by the kernel's build system) might contain content taken from
|
||||
files which use a more restrictive license.
|
||||
|
|
|
|||
|
|
@ -244,14 +244,14 @@ Reporting the bug
|
|||
Once you find where the bug happened, by inspecting its location,
|
||||
you could either try to fix it yourself or report it upstream.
|
||||
|
||||
In order to report it upstream, you should identify the mailing list
|
||||
used for the development of the affected code. This can be done by using
|
||||
the ``get_maintainer.pl`` script.
|
||||
In order to report it upstream, you should identify the bug tracker, if any, or
|
||||
mailing list used for the development of the affected code. This can be done by
|
||||
using the ``get_maintainer.pl`` script.
|
||||
|
||||
For example, if you find a bug at the gspca's sonixj.c file, you can get
|
||||
its maintainers with::
|
||||
|
||||
$ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
|
||||
$ ./scripts/get_maintainer.pl --bug -f drivers/media/usb/gspca/sonixj.c
|
||||
Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%)
|
||||
Tejun Heo <tj@kernel.org> (commit_signer:1/1=100%)
|
||||
|
|
@ -267,11 +267,12 @@ Please notice that it will point to:
|
|||
- The driver maintainer (Hans Verkuil);
|
||||
- The subsystem maintainer (Mauro Carvalho Chehab);
|
||||
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
|
||||
- the Linux Kernel mailing list (linux-kernel@vger.kernel.org).
|
||||
- The Linux Kernel mailing list (linux-kernel@vger.kernel.org);
|
||||
- The bug reporting URIs for the driver/subsystem (none in the above example).
|
||||
|
||||
Usually, the fastest way to have your bug fixed is to report it to mailing
|
||||
list used for the development of the code (linux-media ML) copying the
|
||||
driver maintainer (Hans).
|
||||
If the listing contains bug reporting URIs at the end, please prefer them over
|
||||
email. Otherwise, please report bugs to the mailing list used for the
|
||||
development of the code (linux-media ML) copying the driver maintainer (Hans).
|
||||
|
||||
If you are totally stumped as to whom to send the report, and
|
||||
``get_maintainer.pl`` didn't provide you anything useful, send it to
|
||||
|
|
|
|||
|
|
@ -533,10 +533,12 @@ cgroup namespace on namespace creation.
|
|||
Because the resource control interface files in a given directory
|
||||
control the distribution of the parent's resources, the delegatee
|
||||
shouldn't be allowed to write to them. For the first method, this is
|
||||
achieved by not granting access to these files. For the second, the
|
||||
kernel rejects writes to all files other than "cgroup.procs" and
|
||||
"cgroup.subtree_control" on a namespace root from inside the
|
||||
namespace.
|
||||
achieved by not granting access to these files. For the second, files
|
||||
outside the namespace should be hidden from the delegatee by the means
|
||||
of at least mount namespacing, and the kernel rejects writes to all
|
||||
files on a namespace root from inside the cgroup namespace, except for
|
||||
those files listed in "/sys/kernel/cgroup/delegate" (including
|
||||
"cgroup.procs", "cgroup.threads", "cgroup.subtree_control", etc.).
|
||||
|
||||
The end results are equivalent for both delegation types. Once
|
||||
delegated, the user can build sub-hierarchy under the directory,
|
||||
|
|
@ -981,6 +983,14 @@ All cgroup core files are prefixed with "cgroup."
|
|||
A dying cgroup can consume system resources not exceeding
|
||||
limits, which were active at the moment of cgroup deletion.
|
||||
|
||||
nr_subsys_<cgroup_subsys>
|
||||
Total number of live cgroup subsystems (e.g memory
|
||||
cgroup) at and beneath the current cgroup.
|
||||
|
||||
nr_dying_subsys_<cgroup_subsys>
|
||||
Total number of dying cgroup subsystems (e.g. memory
|
||||
cgroup) at and beneath the current cgroup.
|
||||
|
||||
cgroup.freeze
|
||||
A read-write single value file which exists on non-root cgroups.
|
||||
Allowed values are "0" and "1". The default is "0".
|
||||
|
|
@ -1717,9 +1727,10 @@ The following nested keys are defined.
|
|||
entries fault back in or are written out to disk.
|
||||
|
||||
memory.zswap.writeback
|
||||
A read-write single value file. The default value is "1". The
|
||||
initial value of the root cgroup is 1, and when a new cgroup is
|
||||
created, it inherits the current value of its parent.
|
||||
A read-write single value file. The default value is "1".
|
||||
Note that this setting is hierarchical, i.e. the writeback would be
|
||||
implicitly disabled for child cgroups if the upper hierarchy
|
||||
does so.
|
||||
|
||||
When this is set to 0, all swapping attempts to swapping devices
|
||||
are disabled. This included both zswap writebacks, and swapping due
|
||||
|
|
@ -2939,8 +2950,8 @@ Deprecated v1 Core Features
|
|||
|
||||
- "cgroup.clone_children" is removed.
|
||||
|
||||
- /proc/cgroups is meaningless for v2. Use "cgroup.controllers" file
|
||||
at the root instead.
|
||||
- /proc/cgroups is meaningless for v2. Use "cgroup.controllers" or
|
||||
"cgroup.stat" files at the root instead.
|
||||
|
||||
|
||||
Issues with v1 and Rationales for v2
|
||||
|
|
|
|||
|
|
@ -162,13 +162,18 @@ iv_large_sectors
|
|||
|
||||
|
||||
Module parameters::
|
||||
|
||||
max_read_size
|
||||
max_write_size
|
||||
Maximum size of read or write requests. When a request larger than this size
|
||||
Maximum size of read requests. When a request larger than this size
|
||||
is received, dm-crypt will split the request. The splitting improves
|
||||
concurrency (the split requests could be encrypted in parallel by multiple
|
||||
cores), but it also causes overhead. The user should tune these parameters to
|
||||
cores), but it also causes overhead. The user should tune this parameters to
|
||||
fit the actual workload.
|
||||
|
||||
max_write_size
|
||||
Maximum size of write requests. When a request larger than this size
|
||||
is received, dm-crypt will split the request. The splitting improves
|
||||
concurrency (the split requests could be encrypted in parallel by multiple
|
||||
cores), but it also causes overhead. The user should tune this parameters to
|
||||
fit the actual workload.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -158,3 +158,72 @@ poisoned BTB entry and using that safe one for all function returns.
|
|||
In older Zen1 and Zen2, this is accomplished using a reinterpretation
|
||||
technique similar to Retbleed one: srso_untrain_ret() and
|
||||
srso_safe_ret().
|
||||
|
||||
Checking the safe RET mitigation actually works
|
||||
-----------------------------------------------
|
||||
|
||||
In case one wants to validate whether the SRSO safe RET mitigation works
|
||||
on a kernel, one could use two performance counters
|
||||
|
||||
* PMC_0xc8 - Count of RET/RET lw retired
|
||||
* PMC_0xc9 - Count of RET/RET lw retired mispredicted
|
||||
|
||||
and compare the number of RETs retired properly vs those retired
|
||||
mispredicted, in kernel mode. Another way of specifying those events
|
||||
is::
|
||||
|
||||
# perf list ex_ret_near_ret
|
||||
|
||||
List of pre-defined events (to be used in -e or -M):
|
||||
|
||||
core:
|
||||
ex_ret_near_ret
|
||||
[Retired Near Returns]
|
||||
ex_ret_near_ret_mispred
|
||||
[Retired Near Returns Mispredicted]
|
||||
|
||||
Either the command using the event mnemonics::
|
||||
|
||||
# perf stat -e ex_ret_near_ret:k -e ex_ret_near_ret_mispred:k sleep 10s
|
||||
|
||||
or using the raw PMC numbers::
|
||||
|
||||
# perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s
|
||||
|
||||
should give the same amount. I.e., every RET retired should be
|
||||
mispredicted::
|
||||
|
||||
[root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s
|
||||
|
||||
Performance counter stats for 'sleep 10s':
|
||||
|
||||
137,167 cpu/event=0xc8,umask=0/k
|
||||
137,173 cpu/event=0xc9,umask=0/k
|
||||
|
||||
10.004110303 seconds time elapsed
|
||||
|
||||
0.000000000 seconds user
|
||||
0.004462000 seconds sys
|
||||
|
||||
vs the case when the mitigation is disabled (spec_rstack_overflow=off)
|
||||
or not functioning properly, showing usually a lot smaller number of
|
||||
mispredicted retired RETs vs the overall count of retired RETs during
|
||||
a workload::
|
||||
|
||||
[root@brent: ~/kernel/linux/tools/perf> ./perf stat -e cpu/event=0xc8,umask=0/k -e cpu/event=0xc9,umask=0/k sleep 10s
|
||||
|
||||
Performance counter stats for 'sleep 10s':
|
||||
|
||||
201,627 cpu/event=0xc8,umask=0/k
|
||||
4,074 cpu/event=0xc9,umask=0/k
|
||||
|
||||
10.003267252 seconds time elapsed
|
||||
|
||||
0.002729000 seconds user
|
||||
0.000000000 seconds sys
|
||||
|
||||
Also, there is a selftest which performs the above, go to
|
||||
tools/testing/selftests/x86/ and do::
|
||||
|
||||
make srso
|
||||
./srso
|
||||
|
|
|
|||
|
|
@ -333,12 +333,17 @@
|
|||
allowed anymore to lift isolation
|
||||
requirements as needed. This option
|
||||
does not override iommu=pt
|
||||
force_enable - Force enable the IOMMU on platforms known
|
||||
to be buggy with IOMMU enabled. Use this
|
||||
option with care.
|
||||
pgtbl_v1 - Use v1 page table for DMA-API (Default).
|
||||
pgtbl_v2 - Use v2 page table for DMA-API.
|
||||
irtcachedis - Disable Interrupt Remapping Table (IRT) caching.
|
||||
force_enable - Force enable the IOMMU on platforms known
|
||||
to be buggy with IOMMU enabled. Use this
|
||||
option with care.
|
||||
pgtbl_v1 - Use v1 page table for DMA-API (Default).
|
||||
pgtbl_v2 - Use v2 page table for DMA-API.
|
||||
irtcachedis - Disable Interrupt Remapping Table (IRT) caching.
|
||||
nohugepages - Limit page-sizes used for v1 page-tables
|
||||
to 4 KiB.
|
||||
v2_pgsizes_only - Limit page-sizes used for v1 page-tables
|
||||
to 4KiB/2Mib/1GiB.
|
||||
|
||||
|
||||
amd_iommu_dump= [HW,X86-64]
|
||||
Enable AMD IOMMU driver option to dump the ACPI table
|
||||
|
|
@ -517,6 +522,18 @@
|
|||
Format: <io>,<irq>,<mode>
|
||||
See header of drivers/net/hamradio/baycom_ser_hdx.c.
|
||||
|
||||
bdev_allow_write_mounted=
|
||||
Format: <bool>
|
||||
Control the ability to open a mounted block device
|
||||
for writing, i.e., allow / disallow writes that bypass
|
||||
the FS. This was implemented as a means to prevent
|
||||
fuzzers from crashing the kernel by overwriting the
|
||||
metadata underneath a mounted FS without its awareness.
|
||||
This also prevents destructive formatting of mounted
|
||||
filesystems by naive storage tooling that don't use
|
||||
O_EXCL. Default is Y and can be changed through the
|
||||
Kconfig option CONFIG_BLK_DEV_WRITE_MOUNTED.
|
||||
|
||||
bert_disable [ACPI]
|
||||
Disable BERT OS support on buggy BIOSes.
|
||||
|
||||
|
|
@ -2350,6 +2367,18 @@
|
|||
ipcmni_extend [KNL,EARLY] Extend the maximum number of unique System V
|
||||
IPC identifiers from 32,768 to 16,777,216.
|
||||
|
||||
ipe.enforce= [IPE]
|
||||
Format: <bool>
|
||||
Determine whether IPE starts in permissive (0) or
|
||||
enforce (1) mode. The default is enforce.
|
||||
|
||||
ipe.success_audit=
|
||||
[IPE]
|
||||
Format: <bool>
|
||||
Start IPE with success auditing enabled, emitting
|
||||
an audit event when a binary is allowed. The default
|
||||
is 0.
|
||||
|
||||
irqaffinity= [SMP] Set the default irq affinity mask
|
||||
The argument is a cpu list, as described above.
|
||||
|
||||
|
|
@ -4788,6 +4817,16 @@
|
|||
printk.time= Show timing data prefixed to each printk message line
|
||||
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
|
||||
|
||||
proc_mem.force_override= [KNL]
|
||||
Format: {always | ptrace | never}
|
||||
Traditionally /proc/pid/mem allows memory permissions to be
|
||||
overridden without restrictions. This option may be set to
|
||||
restrict that. Can be one of:
|
||||
- 'always': traditional behavior always allows mem overrides.
|
||||
- 'ptrace': only allow mem overrides for active ptracers.
|
||||
- 'never': never allow mem overrides.
|
||||
If not specified, default is the CONFIG_PROC_MEM_* choice.
|
||||
|
||||
processor.max_cstate= [HW,ACPI]
|
||||
Limit processor to maximum C-state
|
||||
max_cstate=9 overrides any DMI blacklist limit.
|
||||
|
|
@ -4935,6 +4974,10 @@
|
|||
Set maximum number of finished RCU callbacks to
|
||||
process in one batch.
|
||||
|
||||
rcutree.csd_lock_suppress_rcu_stall= [KNL]
|
||||
Do only a one-line RCU CPU stall warning when
|
||||
there is an ongoing too-long CSD-lock wait.
|
||||
|
||||
rcutree.do_rcu_barrier= [KNL]
|
||||
Request a call to rcu_barrier(). This is
|
||||
throttled so that userspace tests can safely
|
||||
|
|
@ -5382,7 +5425,13 @@
|
|||
Time to wait (s) after boot before inducing stall.
|
||||
|
||||
rcutorture.stall_cpu_irqsoff= [KNL]
|
||||
Disable interrupts while stalling if set.
|
||||
Disable interrupts while stalling if set, but only
|
||||
on the first stall in the set.
|
||||
|
||||
rcutorture.stall_cpu_repeat= [KNL]
|
||||
Number of times to repeat the stall sequence,
|
||||
so that rcutorture.stall_cpu_repeat=3 will result
|
||||
in four stall sequences.
|
||||
|
||||
rcutorture.stall_gp_kthread= [KNL]
|
||||
Duration (s) of forced sleep within RCU
|
||||
|
|
@ -5570,14 +5619,6 @@
|
|||
of zero will disable batching. Batching is
|
||||
always disabled for synchronize_rcu_tasks().
|
||||
|
||||
rcupdate.rcu_tasks_rude_lazy_ms= [KNL]
|
||||
Set timeout in milliseconds RCU Tasks
|
||||
Rude asynchronous callback batching for
|
||||
call_rcu_tasks_rude(). A negative value
|
||||
will take the default. A value of zero will
|
||||
disable batching. Batching is always disabled
|
||||
for synchronize_rcu_tasks_rude().
|
||||
|
||||
rcupdate.rcu_tasks_trace_lazy_ms= [KNL]
|
||||
Set timeout in milliseconds RCU Tasks
|
||||
Trace asynchronous callback batching for
|
||||
|
|
@ -7352,6 +7393,13 @@
|
|||
it can be updated at runtime by writing to the
|
||||
corresponding sysfs file.
|
||||
|
||||
workqueue.panic_on_stall=<uint>
|
||||
Panic when workqueue stall is detected by
|
||||
CONFIG_WQ_WATCHDOG. It sets the number times of the
|
||||
stall to trigger panic.
|
||||
|
||||
The default is 0, which disables the panic on stall.
|
||||
|
||||
workqueue.cpu_intensive_thresh_us=
|
||||
Per-cpu work items which run for longer than this
|
||||
threshold are automatically considered CPU intensive
|
||||
|
|
|
|||
|
|
@ -328,7 +328,7 @@ and an HDMI input, one input for each input type. Those are described in more
|
|||
detail below.
|
||||
|
||||
Special attention has been given to the rate at which new frames become
|
||||
available. The jitter will be around 1 jiffie (that depends on the HZ
|
||||
available. The jitter will be around 1 jiffy (that depends on the HZ
|
||||
configuration of your kernel, so usually 1/100, 1/250 or 1/1000 of a second),
|
||||
but the long-term behavior is exactly following the framerate. So a
|
||||
framerate of 59.94 Hz is really different from 60 Hz. If the framerate
|
||||
|
|
|
|||
17
Documentation/admin-guide/perf/arm-ni.rst
Normal file
17
Documentation/admin-guide/perf/arm-ni.rst
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
====================================
|
||||
Arm Network-on Chip Interconnect PMU
|
||||
====================================
|
||||
|
||||
NI-700 and friends implement a distinct PMU for each clock domain within the
|
||||
interconnect. Correspondingly, the driver exposes multiple PMU devices named
|
||||
arm_ni_<x>_cd_<y>, where <x> is an (arbitrary) instance identifier and <y> is
|
||||
the clock domain ID within that particular instance. If multiple NI instances
|
||||
exist within a system, the PMU devices can be correlated with the underlying
|
||||
hardware instance via sysfs parentage.
|
||||
|
||||
Each PMU exposes base event aliases for the interface types present in its clock
|
||||
domain. These require qualifying with the "eventid" and "nodeid" parameters
|
||||
to specify the event code to count and the interface at which to count it
|
||||
(per the configured hardware ID as reflected in the xxNI_NODE_INFO register).
|
||||
The exception is the "cycles" alias for the PMU cycle counter, which is encoded
|
||||
with the PMU node type and needs no further qualification.
|
||||
|
|
@ -46,16 +46,16 @@ Some of the events only exist for specific configurations.
|
|||
DesignWare Cores (DWC) PCIe PMU Driver
|
||||
=======================================
|
||||
|
||||
This driver adds PMU devices for each PCIe Root Port named based on the BDF of
|
||||
This driver adds PMU devices for each PCIe Root Port named based on the SBDF of
|
||||
the Root Port. For example,
|
||||
|
||||
30:03.0 PCI bridge: Device 1ded:8000 (rev 01)
|
||||
0001:30:03.0 PCI bridge: Device 1ded:8000 (rev 01)
|
||||
|
||||
the PMU device name for this Root Port is dwc_rootport_3018.
|
||||
the PMU device name for this Root Port is dwc_rootport_13018.
|
||||
|
||||
The DWC PCIe PMU driver registers a perf PMU driver, which provides
|
||||
description of available events and configuration options in sysfs, see
|
||||
/sys/bus/event_source/devices/dwc_rootport_{bdf}.
|
||||
/sys/bus/event_source/devices/dwc_rootport_{sbdf}.
|
||||
|
||||
The "format" directory describes format of the config fields of the
|
||||
perf_event_attr structure. The "events" directory provides configuration
|
||||
|
|
@ -66,16 +66,16 @@ The "perf list" command shall list the available events from sysfs, e.g.::
|
|||
|
||||
$# perf list | grep dwc_rootport
|
||||
<...>
|
||||
dwc_rootport_3018/Rx_PCIe_TLP_Data_Payload/ [Kernel PMU event]
|
||||
dwc_rootport_13018/Rx_PCIe_TLP_Data_Payload/ [Kernel PMU event]
|
||||
<...>
|
||||
dwc_rootport_3018/rx_memory_read,lane=?/ [Kernel PMU event]
|
||||
dwc_rootport_13018/rx_memory_read,lane=?/ [Kernel PMU event]
|
||||
|
||||
Time Based Analysis Event Usage
|
||||
-------------------------------
|
||||
|
||||
Example usage of counting PCIe RX TLP data payload (Units of bytes)::
|
||||
|
||||
$# perf stat -a -e dwc_rootport_3018/Rx_PCIe_TLP_Data_Payload/
|
||||
$# perf stat -a -e dwc_rootport_13018/Rx_PCIe_TLP_Data_Payload/
|
||||
|
||||
The average RX/TX bandwidth can be calculated using the following formula:
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ Lane Event Usage
|
|||
Each lane has the same event set and to avoid generating a list of hundreds
|
||||
of events, the user need to specify the lane ID explicitly, e.g.::
|
||||
|
||||
$# perf stat -a -e dwc_rootport_3018/rx_memory_read,lane=4/
|
||||
$# perf stat -a -e dwc_rootport_13018/rx_memory_read,lane=4/
|
||||
|
||||
The driver does not support sampling, therefore "perf record" will not
|
||||
work. Per-task (without "-a") perf sessions are not supported.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,9 @@ The "identifier" sysfs file allows users to identify the version of the
|
|||
PMU hardware device.
|
||||
|
||||
The "bus" sysfs file allows users to get the bus number of Root Ports
|
||||
monitored by PMU.
|
||||
monitored by PMU. Furthermore users can get the Root Ports range in
|
||||
[bdf_min, bdf_max] from "bdf_min" and "bdf_max" sysfs attributes
|
||||
respectively.
|
||||
|
||||
Example usage of perf::
|
||||
|
||||
|
|
|
|||
|
|
@ -16,6 +16,7 @@ Performance monitor support
|
|||
starfive_starlink_pmu
|
||||
arm-ccn
|
||||
arm-cmn
|
||||
arm-ni
|
||||
xgene-pmu
|
||||
arm_dsu_pmu
|
||||
thunderx2-pmu
|
||||
|
|
|
|||
|
|
@ -251,7 +251,9 @@ performance supported in `AMD CPPC Performance Capability <perf_cap_>`_).
|
|||
In some ASICs, the highest CPPC performance is not the one in the ``_CPC``
|
||||
table, so we need to expose it to sysfs. If boost is not active, but
|
||||
still supported, this maximum frequency will be larger than the one in
|
||||
``cpuinfo``.
|
||||
``cpuinfo``. On systems that support preferred core, the driver will have
|
||||
different values for some cores than others and this will reflect the values
|
||||
advertised by the platform at bootup.
|
||||
This attribute is read-only.
|
||||
|
||||
``amd_pstate_lowest_nonlinear_freq``
|
||||
|
|
@ -262,6 +264,17 @@ lowest non-linear performance in `AMD CPPC Performance Capability
|
|||
<perf_cap_>`_.)
|
||||
This attribute is read-only.
|
||||
|
||||
``amd_pstate_hw_prefcore``
|
||||
|
||||
Whether the platform supports the preferred core feature and it has been
|
||||
enabled. This attribute is read-only.
|
||||
|
||||
``amd_pstate_prefcore_ranking``
|
||||
|
||||
The performance ranking of the core. This number doesn't have any unit, but
|
||||
larger numbers are preferred at the time of reading. This can change at
|
||||
runtime based on platform conditions. This attribute is read-only.
|
||||
|
||||
``energy_performance_available_preferences``
|
||||
|
||||
A list of all the supported EPP preferences that could be used for
|
||||
|
|
|
|||
|
|
@ -113,3 +113,62 @@ to apply at each uncore* level.
|
|||
|
||||
Support for "current_freq_khz" is available only at each fabric cluster
|
||||
level (i.e., in uncore* directory).
|
||||
|
||||
Efficiency vs. Latency Tradeoff
|
||||
-------------------------------
|
||||
|
||||
The Efficiency Latency Control (ELC) feature improves performance
|
||||
per watt. With this feature hardware power management algorithms
|
||||
optimize trade-off between latency and power consumption. For some
|
||||
latency sensitive workloads further tuning can be done by SW to
|
||||
get desired performance.
|
||||
|
||||
The hardware monitors the average CPU utilization across all cores
|
||||
in a power domain at regular intervals and decides an uncore frequency.
|
||||
While this may result in the best performance per watt, workload may be
|
||||
expecting higher performance at the expense of power. Consider an
|
||||
application that intermittently wakes up to perform memory reads on an
|
||||
otherwise idle system. In such cases, if hardware lowers uncore
|
||||
frequency, then there may be delay in ramp up of frequency to meet
|
||||
target performance.
|
||||
|
||||
The ELC control defines some parameters which can be changed from SW.
|
||||
If the average CPU utilization is below a user-defined threshold
|
||||
(elc_low_threshold_percent attribute below), the user-defined uncore
|
||||
floor frequency will be used (elc_floor_freq_khz attribute below)
|
||||
instead of hardware calculated minimum.
|
||||
|
||||
Similarly in high load scenario where the CPU utilization goes above
|
||||
the high threshold value (elc_high_threshold_percent attribute below)
|
||||
instead of jumping to maximum uncore frequency, frequency is increased
|
||||
in 100MHz steps. This avoids consuming unnecessarily high power
|
||||
immediately with CPU utilization spikes.
|
||||
|
||||
Attributes for efficiency latency control:
|
||||
|
||||
``elc_floor_freq_khz``
|
||||
This attribute is used to get/set the efficiency latency floor frequency.
|
||||
If this variable is lower than the 'min_freq_khz', it is ignored by
|
||||
the firmware.
|
||||
|
||||
``elc_low_threshold_percent``
|
||||
This attribute is used to get/set the efficiency latency control low
|
||||
threshold. This attribute is in percentages of CPU utilization.
|
||||
|
||||
``elc_high_threshold_percent``
|
||||
This attribute is used to get/set the efficiency latency control high
|
||||
threshold. This attribute is in percentages of CPU utilization.
|
||||
|
||||
``elc_high_threshold_enable``
|
||||
This attribute is used to enable/disable the efficiency latency control
|
||||
high threshold. Write '1' to enable, '0' to disable.
|
||||
|
||||
Example system configuration below, which does following:
|
||||
* when CPU utilization is less than 10%: sets uncore frequency to 800MHz
|
||||
* when CPU utilization is higher than 95%: increases uncore frequency in
|
||||
100MHz steps, until power limit is reached
|
||||
|
||||
elc_floor_freq_khz:800000
|
||||
elc_high_threshold_percent:95
|
||||
elc_high_threshold_enable:1
|
||||
elc_low_threshold_percent:10
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ Setting the ramoops parameters can be done in several different manners:
|
|||
takes a size, alignment and name as arguments. The name is used
|
||||
to map the memory to a label that can be retrieved by ramoops.
|
||||
|
||||
reserver_mem=2M:4096:oops ramoops.mem_name=oops
|
||||
reserve_mem=2M:4096:oops ramoops.mem_name=oops
|
||||
|
||||
You can specify either RAM memory or peripheral devices' memory. However, when
|
||||
specifying RAM, be sure to reserve the memory by issuing memblock_reserve()
|
||||
|
|
|
|||
|
|
@ -182,3 +182,5 @@ More detailed explanation for tainting
|
|||
produce extremely unusual kernel structure layouts (even performance
|
||||
pathological ones), which is important to know when debugging. Set at
|
||||
build time.
|
||||
|
||||
18) ``N`` if an in-kernel test, such as a KUnit test, has been run.
|
||||
|
|
|
|||
|
|
@ -359,7 +359,7 @@ Driver updates for STM32 DMA-MDMA chaining support in foo driver
|
|||
descriptor you want a callback to be called at the end of the transfer
|
||||
(dmaengine_prep_slave_sg()) or the period (dmaengine_prep_dma_cyclic()).
|
||||
Depending on the direction, set the callback on the descriptor that finishes
|
||||
the overal transfer:
|
||||
the overall transfer:
|
||||
|
||||
* DMA_DEV_TO_MEM: set the callback on the "MDMA" descriptor
|
||||
* DMA_MEM_TO_DEV: set the callback on the "DMA" descriptor
|
||||
|
|
@ -371,7 +371,7 @@ Driver updates for STM32 DMA-MDMA chaining support in foo driver
|
|||
As STM32 MDMA channel transfer is triggered by STM32 DMA, you must issue
|
||||
STM32 MDMA channel before STM32 DMA channel.
|
||||
|
||||
If any, your callback will be called to warn you about the end of the overal
|
||||
If any, your callback will be called to warn you about the end of the overall
|
||||
transfer or the period completion.
|
||||
|
||||
Don't forget to terminate both channels. STM32 DMA channel is configured in
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ There are no systems that support the physical addition (or removal) of CPUs
|
|||
while the system is running, and ACPI is not able to sufficiently describe
|
||||
them.
|
||||
|
||||
e.g. New CPUs come with new caches, but the platform's cache toplogy is
|
||||
e.g. New CPUs come with new caches, but the platform's cache topology is
|
||||
described in a static table, the PPTT. How caches are shared between CPUs is
|
||||
not discoverable, and must be described by firmware.
|
||||
|
||||
|
|
|
|||
|
|
@ -365,6 +365,8 @@ HWCAP2_SME_SF8DP2
|
|||
HWCAP2_SME_SF8DP4
|
||||
Functionality implied by ID_AA64SMFR0_EL1.SF8DP4 == 0b1.
|
||||
|
||||
HWCAP2_POE
|
||||
Functionality implied by ID_AA64MMFR3_EL1.S1POE == 0b0001.
|
||||
|
||||
4. Unused AT_HWCAP bits
|
||||
-----------------------
|
||||
|
|
|
|||
|
|
@ -55,6 +55,8 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Ampere | AmpereOne AC04 | AC04_CPU_10 | AMPERE_ERRATUM_AC03_CPU_38 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
@ -249,8 +251,8 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Hisilicon | Hip08 SMMU PMCG | #162001900 | N/A |
|
||||
| | Hip09 SMMU PMCG | | |
|
||||
| Hisilicon | Hip{08,09,10,10C| #162001900 | N/A |
|
||||
| | ,11} SMMU PMCG | | |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
|
||||
|
|
|
|||
|
|
@ -134,7 +134,7 @@ Hardware
|
|||
|
||||
* PTCR and partition table entries (partition table is in secure
|
||||
memory). An attempt to write to PTCR will cause a Hypervisor
|
||||
Emulation Assitance interrupt.
|
||||
Emulation Assistance interrupt.
|
||||
|
||||
* LDBAR (LD Base Address Register) and IMC (In-Memory Collection)
|
||||
non-architected registers. An attempt to write to them will cause a
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ status for the use of Vector in userspace. The intended usage guideline for
|
|||
these interfaces is to give init systems a way to modify the availability of V
|
||||
for processes running under its domain. Calling these interfaces is not
|
||||
recommended in libraries routines because libraries should not override policies
|
||||
configured from the parant process. Also, users must noted that these interfaces
|
||||
configured from the parent process. Also, users must note that these interfaces
|
||||
are not portable to non-Linux, nor non-RISC-V environments, so it is discourage
|
||||
to use in a portable code. To get the availability of V in an ELF program,
|
||||
please read :c:macro:`COMPAT_HWCAP_ISA_V` bit of :c:macro:`ELF_HWCAP` in the
|
||||
|
|
|
|||
|
|
@ -134,19 +134,3 @@ RISC-V Linux Kernel SV57
|
|||
ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
|
||||
ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
|
||||
__________________|____________|__________________|_________|____________________________________________________________
|
||||
|
||||
|
||||
Userspace VAs
|
||||
--------------------
|
||||
To maintain compatibility with software that relies on the VA space with a
|
||||
maximum of 48 bits the kernel will, by default, return virtual addresses to
|
||||
userspace from a 48-bit range (sv48). This default behavior is achieved by
|
||||
passing 0 into the hint address parameter of mmap. On CPUs with an address space
|
||||
smaller than sv48, the CPU maximum supported address space will be the default.
|
||||
|
||||
Software can "opt-in" to receiving VAs from another VA space by providing
|
||||
a hint address to mmap. When a hint address is passed to mmap, the returned
|
||||
address will never use more bits than the hint address. For example, if a hint
|
||||
address of `1 << 40` is passed to mmap, a valid returned address will never use
|
||||
bits 41 through 63. If no mappable addresses are available in that range, mmap
|
||||
will return `MAP_FAILED`.
|
||||
|
|
|
|||
|
|
@ -162,7 +162,7 @@ Mitigation points
|
|||
3. It would take a large number of these precisely-timed NMIs to mount
|
||||
an actual attack. There's presumably not enough bandwidth.
|
||||
4. The NMI in question occurs after a VERW, i.e. when user state is
|
||||
restored and most interesting data is already scrubbed. Whats left
|
||||
restored and most interesting data is already scrubbed. What's left
|
||||
is only the data that NMI touches, and that may or may not be of
|
||||
any interest.
|
||||
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ FSGSBASE instructions enablement
|
|||
FSGSBASE instructions compiler support
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
GCC version 4.6.4 and newer provide instrinsics for the FSGSBASE
|
||||
GCC version 4.6.4 and newer provide intrinsics for the FSGSBASE
|
||||
instructions. Clang 5 supports them as well.
|
||||
|
||||
=================== ===========================
|
||||
|
|
@ -135,7 +135,7 @@ instructions. Clang 5 supports them as well.
|
|||
_writegsbase_u64() Write the GS base register
|
||||
=================== ===========================
|
||||
|
||||
To utilize these instrinsics <immintrin.h> must be included in the source
|
||||
To utilize these intrinsics <immintrin.h> must be included in the source
|
||||
code and the compiler option -mfsgsbase has to be added.
|
||||
|
||||
Compiler support for FS/GS based addressing
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ controllers), BFQ's main features are:
|
|||
- BFQ guarantees a high system and application responsiveness, and a
|
||||
low latency for time-sensitive applications, such as audio or video
|
||||
players;
|
||||
- BFQ distributes bandwidth, and not just time, among processes or
|
||||
- BFQ distributes bandwidth, not just time, among processes or
|
||||
groups (switching back to time distribution when needed to keep
|
||||
throughput high).
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ Higher speed for code-development tasks
|
|||
|
||||
If some additional workload happens to be executed in parallel, then
|
||||
BFQ executes the I/O-related components of typical code-development
|
||||
tasks (compilation, checkout, merge, ...) much more quickly than CFQ,
|
||||
tasks (compilation, checkout, merge, etc.) much more quickly than CFQ,
|
||||
NOOP or DEADLINE.
|
||||
|
||||
High throughput
|
||||
|
|
@ -127,9 +127,9 @@ Strong fairness, bandwidth and delay guarantees
|
|||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
BFQ distributes the device throughput, and not just the device time,
|
||||
among I/O-bound applications in proportion their weights, with any
|
||||
among I/O-bound applications in proportion to their weights, with any
|
||||
workload and regardless of the device parameters. From these bandwidth
|
||||
guarantees, it is possible to compute tight per-I/O-request delay
|
||||
guarantees, it is possible to compute a tight per-I/O-request delay
|
||||
guarantees by a simple formula. If not configured for strict service
|
||||
guarantees, BFQ switches to time-based resource sharing (only) for
|
||||
applications that would otherwise cause a throughput loss.
|
||||
|
|
@ -199,7 +199,7 @@ plus a lot of code, are borrowed from CFQ.
|
|||
|
||||
- On flash-based storage with internal queueing of commands
|
||||
(typically NCQ), device idling happens to be always detrimental
|
||||
for throughput. So, with these devices, BFQ performs idling
|
||||
to throughput. So, with these devices, BFQ performs idling
|
||||
only when strictly needed for service guarantees, i.e., for
|
||||
guaranteeing low latency or fairness. In these cases, overall
|
||||
throughput may be sub-optimal. No solution currently exists to
|
||||
|
|
@ -212,7 +212,7 @@ plus a lot of code, are borrowed from CFQ.
|
|||
and to reduce their latency. The most important action taken to
|
||||
achieve this goal is to give to the queues associated with these
|
||||
applications more than their fair share of the device
|
||||
throughput. For brevity, we call just "weight-raising" the whole
|
||||
throughput. For brevity, we call it just "weight-raising" the whole
|
||||
sets of actions taken by BFQ to privilege these queues. In
|
||||
particular, BFQ provides a milder form of weight-raising for
|
||||
interactive applications, and a stronger form for soft real-time
|
||||
|
|
@ -231,7 +231,7 @@ plus a lot of code, are borrowed from CFQ.
|
|||
responsive in detecting interleaved I/O (cooperating processes),
|
||||
that it enables BFQ to achieve a high throughput, by queue
|
||||
merging, even for queues for which CFQ needs a different
|
||||
mechanism, preemption, to get a high throughput. As such EQM is a
|
||||
mechanism, preemption, to get a high throughput. As such, EQM is a
|
||||
unified mechanism to achieve a high throughput with interleaved
|
||||
I/O.
|
||||
|
||||
|
|
@ -254,7 +254,7 @@ plus a lot of code, are borrowed from CFQ.
|
|||
- First, with any proportional-share scheduler, the maximum
|
||||
deviation with respect to an ideal service is proportional to
|
||||
the maximum budget (slice) assigned to queues. As a consequence,
|
||||
BFQ can keep this deviation tight not only because of the
|
||||
BFQ can keep this deviation tight, not only because of the
|
||||
accurate service of B-WF2Q+, but also because BFQ *does not*
|
||||
need to assign a larger budget to a queue to let the queue
|
||||
receive a higher fraction of the device throughput.
|
||||
|
|
@ -327,7 +327,7 @@ applications. Unset this tunable if you need/want to control weights.
|
|||
slice_idle
|
||||
----------
|
||||
|
||||
This parameter specifies how long BFQ should idle for next I/O
|
||||
This parameter specifies how long BFQ should idle for the next I/O
|
||||
request, when certain sync BFQ queues become empty. By default
|
||||
slice_idle is a non-zero value. Idling has a double purpose: boosting
|
||||
throughput and making sure that the desired throughput distribution is
|
||||
|
|
@ -365,7 +365,7 @@ terms of I/O-request dispatches. To guarantee that the actual service
|
|||
order then corresponds to the dispatch order, the strict_guarantees
|
||||
tunable must be set too.
|
||||
|
||||
There is an important flipside for idling: apart from the above cases
|
||||
There is an important flip side to idling: apart from the above cases
|
||||
where it is beneficial also for throughput, idling can severely impact
|
||||
throughput. One important case is random workload. Because of this
|
||||
issue, BFQ tends to avoid idling as much as possible, when it is not
|
||||
|
|
@ -475,7 +475,7 @@ max_budget
|
|||
|
||||
Maximum amount of service, measured in sectors, that can be provided
|
||||
to a BFQ queue once it is set in service (of course within the limits
|
||||
of the above timeout). According to what said in the description of
|
||||
of the above timeout). According to what was said in the description of
|
||||
the algorithm, larger values increase the throughput in proportion to
|
||||
the percentage of sequential I/O requests issued. The price of larger
|
||||
values is that they coarsen the granularity of short-term bandwidth
|
||||
|
|
|
|||
|
|
@ -49,6 +49,7 @@ Library functionality that is used throughout the kernel.
|
|||
wrappers/atomic_t
|
||||
wrappers/atomic_bitops
|
||||
floating-point
|
||||
union_find
|
||||
|
||||
Low level entry and exit
|
||||
========================
|
||||
|
|
|
|||
|
|
@ -45,8 +45,9 @@ here we briefly outline their recommended usage:
|
|||
* If the allocation is performed from an atomic context, e.g interrupt
|
||||
handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and
|
||||
IO or filesystem operations. Consequently, under memory pressure
|
||||
``GFP_NOWAIT`` allocation is likely to fail. Allocations which
|
||||
have a reasonable fallback should be using ``GFP_NOWARN``.
|
||||
``GFP_NOWAIT`` allocation is likely to fail. Users of this flag need
|
||||
to provide a suitable fallback to cope with such failures where
|
||||
appropriate.
|
||||
* If you think that accessing memory reserves is justified and the kernel
|
||||
will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``.
|
||||
* Untrusted allocations triggered from userspace should be a subject
|
||||
|
|
|
|||
106
Documentation/core-api/union_find.rst
Normal file
106
Documentation/core-api/union_find.rst
Normal file
|
|
@ -0,0 +1,106 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
====================
|
||||
Union-Find in Linux
|
||||
====================
|
||||
|
||||
|
||||
:Date: June 21, 2024
|
||||
:Author: Xavier <xavier_qy@163.com>
|
||||
|
||||
What is union-find, and what is it used for?
|
||||
------------------------------------------------
|
||||
|
||||
Union-find is a data structure used to handle the merging and querying
|
||||
of disjoint sets. The primary operations supported by union-find are:
|
||||
|
||||
Initialization: Resetting each element as an individual set, with
|
||||
each set's initial parent node pointing to itself.
|
||||
|
||||
Find: Determine which set a particular element belongs to, usually by
|
||||
returning a “representative element” of that set. This operation
|
||||
is used to check if two elements are in the same set.
|
||||
|
||||
Union: Merge two sets into one.
|
||||
|
||||
As a data structure used to maintain sets (groups), union-find is commonly
|
||||
utilized to solve problems related to offline queries, dynamic connectivity,
|
||||
and graph theory. It is also a key component in Kruskal's algorithm for
|
||||
computing the minimum spanning tree, which is crucial in scenarios like
|
||||
network routing. Consequently, union-find is widely referenced. Additionally,
|
||||
union-find has applications in symbolic computation, register allocation,
|
||||
and more.
|
||||
|
||||
Space Complexity: O(n), where n is the number of nodes.
|
||||
|
||||
Time Complexity: Using path compression can reduce the time complexity of
|
||||
the find operation, and using union by rank can reduce the time complexity
|
||||
of the union operation. These optimizations reduce the average time
|
||||
complexity of each find and union operation to O(α(n)), where α(n) is the
|
||||
inverse Ackermann function. This can be roughly considered a constant time
|
||||
complexity for practical purposes.
|
||||
|
||||
This document covers use of the Linux union-find implementation. For more
|
||||
information on the nature and implementation of union-find, see:
|
||||
|
||||
Wikipedia entry on union-find
|
||||
https://en.wikipedia.org/wiki/Disjoint-set_data_structure
|
||||
|
||||
Linux implementation of union-find
|
||||
-----------------------------------
|
||||
|
||||
Linux's union-find implementation resides in the file "lib/union_find.c".
|
||||
To use it, "#include <linux/union_find.h>".
|
||||
|
||||
The union-find data structure is defined as follows::
|
||||
|
||||
struct uf_node {
|
||||
struct uf_node *parent;
|
||||
unsigned int rank;
|
||||
};
|
||||
|
||||
In this structure, parent points to the parent node of the current node.
|
||||
The rank field represents the height of the current tree. During a union
|
||||
operation, the tree with the smaller rank is attached under the tree with the
|
||||
larger rank to maintain balance.
|
||||
|
||||
Initializing union-find
|
||||
-----------------------
|
||||
|
||||
You can complete the initialization using either static or initialization
|
||||
interface. Initialize the parent pointer to point to itself and set the rank
|
||||
to 0.
|
||||
Example::
|
||||
|
||||
struct uf_node my_node = UF_INIT_NODE(my_node);
|
||||
|
||||
or
|
||||
|
||||
uf_node_init(&my_node);
|
||||
|
||||
Find the Root Node of union-find
|
||||
--------------------------------
|
||||
|
||||
This operation is mainly used to determine whether two nodes belong to the same
|
||||
set in the union-find. If they have the same root, they are in the same set.
|
||||
During the find operation, path compression is performed to improve the
|
||||
efficiency of subsequent find operations.
|
||||
Example::
|
||||
|
||||
int connected;
|
||||
struct uf_node *root1 = uf_find(&node_1);
|
||||
struct uf_node *root2 = uf_find(&node_2);
|
||||
if (root1 == root2)
|
||||
connected = 1;
|
||||
else
|
||||
connected = 0;
|
||||
|
||||
Union Two Sets in union-find
|
||||
----------------------------
|
||||
|
||||
To union two sets in the union-find, you first find their respective root nodes
|
||||
and then link the smaller node to the larger node based on the rank of the root
|
||||
nodes.
|
||||
Example::
|
||||
|
||||
uf_union(&node_1, &node_2);
|
||||
|
|
@ -75,6 +75,17 @@ Only files which are linked to the main kernel image or are compiled as
|
|||
kernel modules are supported by this mechanism.
|
||||
|
||||
|
||||
Module specific configs
|
||||
-----------------------
|
||||
|
||||
Gcov kernel configs for specific modules are described below:
|
||||
|
||||
CONFIG_GCOV_PROFILE_RDS:
|
||||
Enables GCOV profiling on RDS for checking which functions or
|
||||
lines are executed. This config is used by the rds selftest to
|
||||
generate coverage reports. If left unset the report is omitted.
|
||||
|
||||
|
||||
Files
|
||||
-----
|
||||
|
||||
|
|
|
|||
|
|
@ -361,7 +361,8 @@ Alternatives Considered
|
|||
-----------------------
|
||||
|
||||
An alternative data race detection approach for the kernel can be found in the
|
||||
`Kernel Thread Sanitizer (KTSAN) <https://github.com/google/ktsan/wiki>`_.
|
||||
`Kernel Thread Sanitizer (KTSAN)
|
||||
<https://github.com/google/kernel-sanitizers/blob/master/KTSAN.md>`_.
|
||||
KTSAN is a happens-before data race detector, which explicitly establishes the
|
||||
happens-before order between memory operations, which can then be used to
|
||||
determine data races as defined in `Data Races`_.
|
||||
|
|
|
|||
|
|
@ -188,15 +188,26 @@ For example, a Kconfig entry might look like:
|
|||
Test File and Module Names
|
||||
==========================
|
||||
|
||||
KUnit tests can often be compiled as a module. These modules should be named
|
||||
after the test suite, followed by ``_test``. If this is likely to conflict with
|
||||
non-KUnit tests, the suffix ``_kunit`` can also be used.
|
||||
KUnit tests are often compiled as a separate module. To avoid conflicting
|
||||
with regular modules, KUnit modules should be named after the test suite,
|
||||
followed by ``_kunit`` (e.g. if "foobar" is the core module, then
|
||||
"foobar_kunit" is the KUnit test module).
|
||||
|
||||
The easiest way of achieving this is to name the file containing the test suite
|
||||
``<suite>_test.c`` (or, as above, ``<suite>_kunit.c``). This file should be
|
||||
placed next to the code under test.
|
||||
Test source files, whether compiled as a separate module or an
|
||||
``#include`` in another source file, are best kept in a ``tests/``
|
||||
subdirectory to not conflict with other source files (e.g. for
|
||||
tab-completion).
|
||||
|
||||
Note that the ``_test`` suffix has also been used in some existing
|
||||
tests. The ``_kunit`` suffix is preferred, as it makes the distinction
|
||||
between KUnit and non-KUnit tests clearer.
|
||||
|
||||
So for the common case, name the file containing the test suite
|
||||
``tests/<suite>_kunit.c``. The ``tests`` directory should be placed at
|
||||
the same level as the code under test. For example, tests for
|
||||
``lib/string.c`` live in ``lib/tests/string_kunit.c``.
|
||||
|
||||
If the suite name contains some or all of the name of the test's parent
|
||||
directory, it may make sense to modify the source filename to reduce redundancy.
|
||||
For example, a ``foo_firmware`` suite could be in the ``foo/firmware_test.c``
|
||||
file.
|
||||
directory, it may make sense to modify the source filename to reduce
|
||||
redundancy. For example, a ``foo_firmware`` suite could be in the
|
||||
``foo/tests/firmware_kunit.c`` file.
|
||||
|
|
|
|||
|
|
@ -1,17 +0,0 @@
|
|||
* ARC HS Performance Counters
|
||||
|
||||
The ARC HS can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to up to 32 counters.
|
||||
It also supports overflow interrupts.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,archs-pct"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,archs-pct";
|
||||
};
|
||||
33
Documentation/devicetree/bindings/arc/snps,archs-pct.yaml
Normal file
33
Documentation/devicetree/bindings/arc/snps,archs-pct.yaml
Normal file
|
|
@ -0,0 +1,33 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arc/snps,archs-pct.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARC HS Performance Counters
|
||||
|
||||
maintainers:
|
||||
- Aryabhatta Dey <aryabhattadey35@gmail.com>
|
||||
|
||||
description:
|
||||
The ARC HS can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to up to 32 counters.
|
||||
It also supports overflow interrupts.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: snps,archs-pct
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
|
|
@ -25,10 +25,18 @@ select:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: amlogic,meson-gx-ao-secure
|
||||
- const: syscon
|
||||
|
||||
oneOf:
|
||||
- items:
|
||||
- const: amlogic,meson-gx-ao-secure
|
||||
- const: syscon
|
||||
- items:
|
||||
- enum:
|
||||
- amlogic,a4-ao-secure
|
||||
- amlogic,c3-ao-secure
|
||||
- amlogic,s4-ao-secure
|
||||
- amlogic,t7-ao-secure
|
||||
- const: amlogic,meson-gx-ao-secure
|
||||
- const: syscon
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ description: |
|
|||
The Coresight dummy source component is for the specific coresight source
|
||||
devices kernel don't have permission to access or configure. For some SOCs,
|
||||
there would be Coresight source trace components on sub-processor which
|
||||
are conneted to AP processor via debug bus. For these devices, a dummy driver
|
||||
are connected to AP processor via debug bus. For these devices, a dummy driver
|
||||
is needed to register them as Coresight source devices, so that paths can be
|
||||
created in the driver. It provides Coresight API for operations on dummy
|
||||
source devices, such as enabling and disabling them. It also provides the
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ARM Corstone1000
|
||||
|
||||
maintainers:
|
||||
- Vishnu Banavath <vishnu.banavath@arm.com>
|
||||
- Rui Miguel Silva <rui.silva@linaro.org>
|
||||
- Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
|
||||
- Hugues Kamba Mpiana <hugues.kambampiana@arm.com>
|
||||
|
||||
description: |+
|
||||
ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
|
||||
|
|
|
|||
|
|
@ -79,6 +79,7 @@ properties:
|
|||
- aspeed,ast2600-evb-a1
|
||||
- asus,x4tf-bmc
|
||||
- facebook,bletchley-bmc
|
||||
- facebook,catalina-bmc
|
||||
- facebook,cloudripper-bmc
|
||||
- facebook,elbert-bmc
|
||||
- facebook,fuji-bmc
|
||||
|
|
@ -86,7 +87,9 @@ properties:
|
|||
- facebook,harma-bmc
|
||||
- facebook,minerva-cmc
|
||||
- facebook,yosemite4-bmc
|
||||
- ibm,blueridge-bmc
|
||||
- ibm,everest-bmc
|
||||
- ibm,fuji-bmc
|
||||
- ibm,rainier-bmc
|
||||
- ibm,system1-bmc
|
||||
- ibm,tacoma-bmc
|
||||
|
|
|
|||
|
|
@ -11,7 +11,8 @@ PIT Timer required properties:
|
|||
shared across all System Controller members.
|
||||
|
||||
PIT64B Timer required properties:
|
||||
- compatible: Should be "microchip,sam9x60-pit64b"
|
||||
- compatible: Should be "microchip,sam9x60-pit64b" or
|
||||
"microchip,sam9x7-pit64b", "microchip,sam9x60-pit64b"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for PIT64B timer
|
||||
- clocks: Should contain the available clock sources for PIT64B timer.
|
||||
|
|
@ -31,7 +32,8 @@ RAMC SDRAM/DDR Controller required properties:
|
|||
"atmel,at91sam9g45-ddramc",
|
||||
"atmel,sama5d3-ddramc",
|
||||
"microchip,sam9x60-ddramc",
|
||||
"microchip,sama7g5-uddrc"
|
||||
"microchip,sama7g5-uddrc",
|
||||
"microchip,sam9x7-ddramc", "atmel,sama5d3-ddramc".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
|
|
@ -809,19 +809,19 @@ properties:
|
|||
- const: kontron,sl-imx6ull # Kontron SL i.MX6ULL SoM
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: TQ Systems TQMa6ULLx SoM on MBa6ULx board
|
||||
- description: TQ-Systems TQMa6ULLx SoM on MBa6ULx board
|
||||
items:
|
||||
- enum:
|
||||
- tq,imx6ull-tqma6ull2-mba6ulx
|
||||
- const: tq,imx6ull-tqma6ull2 # MCIMX6Y2
|
||||
- tq,imx6ull-tqma6ull2-mba6ulx # TQMa6ULL socketable SoM with MCIMX6Y2 on MBa6ULx EVK
|
||||
- const: tq,imx6ull-tqma6ull2 # TQMa6ULL socketable SoM with MCIMX6Y2
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: TQ Systems TQMa6ULLxL SoM on MBa6ULx[L] board
|
||||
- description: TQ-Systems TQMa6ULLxL SoM on MBa6ULx[L] board
|
||||
items:
|
||||
- enum:
|
||||
- tq,imx6ull-tqma6ull2l-mba6ulx # using LGA adapter
|
||||
- tq,imx6ull-tqma6ull2l-mba6ulxl
|
||||
- const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant
|
||||
- tq,imx6ull-tqma6ull2l-mba6ulx # TQMa6ULLxL LGA SoM with socketable Adapter on MBa6ULx EVK
|
||||
- tq,imx6ull-tqma6ull2l-mba6ulxl # TQMa6ULLxL LGA SoM on MBa6ULxL gateway board
|
||||
- const: tq,imx6ull-tqma6ull2l # TQMa6ULLxL LGA SoM with MCIMX6Y2
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: Seeed Stuido i.MX6ULL SoM on dev boards
|
||||
|
|
@ -939,8 +939,8 @@ properties:
|
|||
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
|
||||
- fsl,imx8mm-evk # i.MX8MM EVK Board
|
||||
- fsl,imx8mm-evkb # i.MX8MM EVKB Board
|
||||
- gateworks,imx8mm-gw75xx-0x # i.MX8MM Gateworks Board
|
||||
- gateworks,imx8mm-gw7904
|
||||
- gateworks,imx8mm-gw7905-0x # i.MX8MM Gateworks Board
|
||||
- gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit
|
||||
- gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit
|
||||
- gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit
|
||||
|
|
@ -953,7 +953,6 @@ properties:
|
|||
- toradex,verdin-imx8mm # Verdin iMX8M Mini Modules
|
||||
- toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT
|
||||
- toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules
|
||||
- variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module
|
||||
- prt,prt8mm # i.MX8MM Protonic PRT8MM Board
|
||||
- const: fsl,imx8mm
|
||||
|
||||
|
|
@ -1082,7 +1081,7 @@ properties:
|
|||
- gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw7905-2x # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw75xx-2x # i.MX8MP Gateworks Board
|
||||
- skov,imx8mp-skov-revb-hdmi # SKOV i.MX8MP climate control without panel
|
||||
- skov,imx8mp-skov-revb-lt6 # SKOV i.MX8MP climate control with 7” panel
|
||||
- skov,imx8mp-skov-revb-mi1010ait-1cp1 # SKOV i.MX8MP climate control with 10.1" panel
|
||||
|
|
@ -1168,6 +1167,12 @@ properties:
|
|||
- const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
|
||||
- const: fsl,imx8mp
|
||||
|
||||
- description: Variscite VAR-SOM-MX8M Plus based boards
|
||||
items:
|
||||
- const: variscite,var-som-mx8mp-symphony
|
||||
- const: variscite,var-som-mx8mp
|
||||
- const: fsl,imx8mp
|
||||
|
||||
- description: i.MX8MQ based Boards
|
||||
items:
|
||||
- enum:
|
||||
|
|
@ -1293,6 +1298,7 @@ properties:
|
|||
- enum:
|
||||
- fsl,imx93-9x9-qsb # i.MX93 9x9 QSB Board
|
||||
- fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board
|
||||
- fsl,imx93-14x14-evk # i.MX93 14x14 EVK Board
|
||||
- const: fsl,imx93
|
||||
|
||||
- description: i.MX95 based Boards
|
||||
|
|
@ -1344,6 +1350,12 @@ properties:
|
|||
- const: variscite,var-som-mx93
|
||||
- const: fsl,imx93
|
||||
|
||||
- description: Kontron OSM-S i.MX93 SoM based boards
|
||||
items:
|
||||
- const: kontron,imx93-bl-osm-s # Kontron BL i.MX93 OSM-S board
|
||||
- const: kontron,imx93-osm-s # Kontron OSM-S i.MX93 SoM
|
||||
- const: fsl,imx93
|
||||
|
||||
- description:
|
||||
Freescale Vybrid Platform Device Tree Bindings
|
||||
|
||||
|
|
@ -1523,6 +1535,12 @@ properties:
|
|||
- fsl,ls2080a-rdb
|
||||
- const: fsl,ls2080a
|
||||
|
||||
- description: LS2081A based Boards
|
||||
items:
|
||||
- enum:
|
||||
- fsl,ls2081a-rdb
|
||||
- const: fsl,ls2081a
|
||||
|
||||
- description: LS2088A based Boards
|
||||
items:
|
||||
- enum:
|
||||
|
|
|
|||
|
|
@ -155,6 +155,11 @@ properties:
|
|||
- const: qcom,msm8926
|
||||
- const: qcom,msm8226
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- wingtech,wt82918hd
|
||||
- const: qcom,msm8929
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- huawei,kiwi
|
||||
|
|
@ -162,6 +167,8 @@ properties:
|
|||
- samsung,a7
|
||||
- sony,kanuti-tulip
|
||||
- square,apq8039-t2
|
||||
- wingtech,wt82918
|
||||
- wingtech,wt82918hdhw39
|
||||
- const: qcom,msm8939
|
||||
|
||||
- items:
|
||||
|
|
@ -228,12 +235,15 @@ properties:
|
|||
- samsung,grandprimelte
|
||||
- samsung,gt510
|
||||
- samsung,gt58
|
||||
- samsung,j3ltetw
|
||||
- samsung,j5
|
||||
- samsung,j5x
|
||||
- samsung,rossa
|
||||
- samsung,serranove
|
||||
- thwc,uf896
|
||||
- thwc,ufi001c
|
||||
- wingtech,wt86518
|
||||
- wingtech,wt86528
|
||||
- wingtech,wt88047
|
||||
- yiming,uz801-v3
|
||||
- const: qcom,msm8916
|
||||
|
|
@ -250,6 +260,7 @@ properties:
|
|||
- items:
|
||||
- enum:
|
||||
- lg,bullhead
|
||||
- lg,h815
|
||||
- microsoft,talkman
|
||||
- xiaomi,libra
|
||||
- const: qcom,msm8992
|
||||
|
|
@ -1038,10 +1049,18 @@ properties:
|
|||
- qcom,sm8650-qrd
|
||||
- const: qcom,sm8650
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- lenovo,thinkpad-t14s
|
||||
- const: qcom,x1e78100
|
||||
- const: qcom,x1e80100
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- asus,vivobook-s15
|
||||
- lenovo,yoga-slim7x
|
||||
- microsoft,romulus13
|
||||
- microsoft,romulus15
|
||||
- qcom,x1e80100-crd
|
||||
- qcom,x1e80100-qcp
|
||||
- const: qcom,x1e80100
|
||||
|
|
|
|||
|
|
@ -96,6 +96,13 @@ properties:
|
|||
- const: coolpi,pi-cm5
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Cool Pi CM5 GenBook
|
||||
items:
|
||||
- enum:
|
||||
- coolpi,pi-cm5-genbook
|
||||
- const: coolpi,pi-cm5
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Cool Pi 4 Model B
|
||||
items:
|
||||
- const: coolpi,pi-4b
|
||||
|
|
@ -148,6 +155,12 @@ properties:
|
|||
- const: engicam,px30-core
|
||||
- const: rockchip,px30
|
||||
|
||||
- description: Firefly Core-PX30-JD4 on MB-JD4-PX30 baseboard
|
||||
items:
|
||||
- const: firefly,px30-jd4-core-mb
|
||||
- const: firefly,px30-jd4-core
|
||||
- const: rockchip,px30
|
||||
|
||||
- description: Firefly Firefly-RK3288
|
||||
items:
|
||||
- enum:
|
||||
|
|
@ -216,6 +229,7 @@ properties:
|
|||
- friendlyarm,nanopi-r2c
|
||||
- friendlyarm,nanopi-r2c-plus
|
||||
- friendlyarm,nanopi-r2s
|
||||
- friendlyarm,nanopi-r2s-plus
|
||||
- const: rockchip,rk3328
|
||||
|
||||
- description: FriendlyElec NanoPi4 series boards
|
||||
|
|
@ -243,9 +257,11 @@ properties:
|
|||
- friendlyarm,nanopi-r6s
|
||||
- const: rockchip,rk3588s
|
||||
|
||||
- description: FriendlyElec NanoPC T6
|
||||
- description: FriendlyElec NanoPC T6 series boards
|
||||
items:
|
||||
- const: friendlyarm,nanopc-t6
|
||||
- enum:
|
||||
- friendlyarm,nanopc-t6
|
||||
- friendlyarm,nanopc-t6-lts
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: FriendlyElec CM3588-based boards
|
||||
|
|
@ -255,6 +271,11 @@ properties:
|
|||
- const: friendlyarm,cm3588
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: GameForce Ace
|
||||
items:
|
||||
- const: gameforce,ace
|
||||
- const: rockchip,rk3588s
|
||||
|
||||
- description: GameForce Chi
|
||||
items:
|
||||
- const: gameforce,chi
|
||||
|
|
@ -581,9 +602,19 @@ properties:
|
|||
|
||||
- description: Hardkernel Odroid M1
|
||||
items:
|
||||
- const: rockchip,rk3568-odroid-m1
|
||||
- const: hardkernel,odroid-m1
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Hardkernel Odroid M1S
|
||||
items:
|
||||
- const: hardkernel,odroid-m1s
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Hardkernel Odroid M2
|
||||
items:
|
||||
- const: hardkernel,odroid-m2
|
||||
- const: rockchip,rk3588s
|
||||
|
||||
- description: Hugsun X99 TV Box
|
||||
items:
|
||||
- const: hugsun,x99
|
||||
|
|
@ -622,6 +653,11 @@ properties:
|
|||
- const: leez,p710
|
||||
- const: rockchip,rk3399
|
||||
|
||||
- description: LCKFB Taishan Pi RK3566
|
||||
items:
|
||||
- const: lckfb,tspi-rk3566
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Lunzn FastRhino R66S / R68S
|
||||
items:
|
||||
- enum:
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@ select:
|
|||
- rockchip,rk3368-pmu
|
||||
- rockchip,rk3399-pmu
|
||||
- rockchip,rk3568-pmu
|
||||
- rockchip,rk3576-pmu
|
||||
- rockchip,rk3588-pmu
|
||||
- rockchip,rv1126-pmu
|
||||
|
||||
|
|
@ -43,6 +44,7 @@ properties:
|
|||
- rockchip,rk3368-pmu
|
||||
- rockchip,rk3399-pmu
|
||||
- rockchip,rk3568-pmu
|
||||
- rockchip,rk3576-pmu
|
||||
- rockchip,rk3588-pmu
|
||||
- rockchip,rv1126-pmu
|
||||
- const: syscon
|
||||
|
|
|
|||
|
|
@ -54,6 +54,8 @@ properties:
|
|||
- description: ST STM32MP151 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- prt,mecio1r0 # Protonic MECIO1r0
|
||||
- prt,mect1s # Protonic MECT1S
|
||||
- prt,prtt1a # Protonic PRTT1A
|
||||
- prt,prtt1c # Protonic PRTT1C
|
||||
- prt,prtt1s # Protonic PRTT1S
|
||||
|
|
@ -71,6 +73,12 @@ properties:
|
|||
- const: dh,stm32mp151a-dhcor-som
|
||||
- const: st,stm32mp151
|
||||
|
||||
- description: ST STM32MP153 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- prt,mecio1r1 # Protonic MECIO1r1
|
||||
- const: st,stm32mp153
|
||||
|
||||
- description: DH STM32MP153 DHCOM SoM based Boards
|
||||
items:
|
||||
- const: dh,stm32mp153c-dhcom-drc02
|
||||
|
|
|
|||
|
|
@ -61,14 +61,19 @@ properties:
|
|||
- const: anbernic,rg35xx-2024
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Anbernic RG35XX H
|
||||
items:
|
||||
- const: anbernic,rg35xx-h
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Anbernic RG35XX Plus
|
||||
items:
|
||||
- const: anbernic,rg35xx-plus
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Anbernic RG35XX H
|
||||
- description: Anbernic RG35XX SP
|
||||
items:
|
||||
- const: anbernic,rg35xx-h
|
||||
- const: anbernic,rg35xx-sp
|
||||
- const: allwinner,sun50i-h700
|
||||
|
||||
- description: Amarula A64 Relic
|
||||
|
|
|
|||
|
|
@ -127,6 +127,48 @@ properties:
|
|||
- nvidia,norrin
|
||||
- const: nvidia,tegra132
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- const: google,nyan-blaze-rev10
|
||||
- const: google,nyan-blaze-rev9
|
||||
- const: google,nyan-blaze-rev8
|
||||
- const: google,nyan-blaze-rev7
|
||||
- const: google,nyan-blaze-rev6
|
||||
- const: google,nyan-blaze-rev5
|
||||
- const: google,nyan-blaze-rev4
|
||||
- const: google,nyan-blaze-rev3
|
||||
- const: google,nyan-blaze-rev2
|
||||
- const: google,nyan-blaze-rev1
|
||||
- const: google,nyan-blaze-rev0
|
||||
- const: google,nyan-blaze
|
||||
- const: google,nyan
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- const: google,nyan-big-rev10
|
||||
- const: google,nyan-big-rev9
|
||||
- const: google,nyan-big-rev8
|
||||
- const: google,nyan-big-rev7
|
||||
- const: google,nyan-big-rev6
|
||||
- const: google,nyan-big-rev5
|
||||
- const: google,nyan-big-rev4
|
||||
- const: google,nyan-big-rev3
|
||||
- const: google,nyan-big-rev2
|
||||
- const: google,nyan-big-rev1
|
||||
- const: google,nyan-big-rev0
|
||||
- const: google,nyan-big
|
||||
- const: google,nyan
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- const: google,nyan-big-rev7
|
||||
- const: google,nyan-big-rev6
|
||||
- const: google,nyan-big-rev5
|
||||
- const: google,nyan-big-rev4
|
||||
- const: google,nyan-big-rev3
|
||||
- const: google,nyan-big-rev2
|
||||
- const: google,nyan-big-rev1
|
||||
- const: google,nyan-big-rev0
|
||||
- const: google,nyan-big
|
||||
- const: google,nyan
|
||||
- const: nvidia,tegra124
|
||||
- items:
|
||||
- enum:
|
||||
- nvidia,darcy
|
||||
|
|
|
|||
|
|
@ -140,6 +140,7 @@ properties:
|
|||
- description: K3 J722S SoC and Boards
|
||||
items:
|
||||
- enum:
|
||||
- beagle,am67a-beagley-ai
|
||||
- ti,j722s-evm
|
||||
- const: ti,j722s
|
||||
|
||||
|
|
|
|||
|
|
@ -30,6 +30,8 @@ select:
|
|||
- marvell,armada-3700-ahci
|
||||
- marvell,armada-8k-ahci
|
||||
- marvell,berlin2q-ahci
|
||||
- qcom,apq8064-ahci
|
||||
- qcom,ipq806x-ahci
|
||||
- socionext,uniphier-pro4-ahci
|
||||
- socionext,uniphier-pxs2-ahci
|
||||
- socionext,uniphier-pxs3-ahci
|
||||
|
|
@ -45,6 +47,8 @@ properties:
|
|||
- marvell,armada-8k-ahci
|
||||
- marvell,berlin2-ahci
|
||||
- marvell,berlin2q-ahci
|
||||
- qcom,apq8064-ahci
|
||||
- qcom,ipq806x-ahci
|
||||
- socionext,uniphier-pro4-ahci
|
||||
- socionext,uniphier-pxs2-ahci
|
||||
- socionext,uniphier-pxs3-ahci
|
||||
|
|
@ -64,11 +68,11 @@ properties:
|
|||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
maxItems: 5
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
maxItems: 5
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
|
@ -97,6 +101,31 @@ required:
|
|||
|
||||
allOf:
|
||||
- $ref: ahci-common.yaml#
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,apq8064-ahci
|
||||
- qcom,ipq806x-ahci
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
minItems: 5
|
||||
clock-names:
|
||||
items:
|
||||
- const: slave_iface
|
||||
- const: iface
|
||||
- const: core
|
||||
- const: rxoob
|
||||
- const: pmalive
|
||||
required:
|
||||
- phys
|
||||
- phy-names
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@ properties:
|
|||
- fsl,imx53-ahci
|
||||
- fsl,imx6q-ahci
|
||||
- fsl,imx6qp-ahci
|
||||
- fsl,imx8qm-ahci
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -27,12 +28,14 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
items:
|
||||
- description: sata clock
|
||||
- description: sata reference clock
|
||||
- description: ahb clock
|
||||
|
||||
clock-names:
|
||||
minItems: 2
|
||||
items:
|
||||
- const: sata
|
||||
- const: sata_ref
|
||||
|
|
@ -58,6 +61,25 @@ properties:
|
|||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description: if present, disable spread-spectrum clocking on the SATA link.
|
||||
|
||||
phys:
|
||||
items:
|
||||
- description: phandle to SATA PHY.
|
||||
Since "REXT" pin is only present for first lane of i.MX8QM PHY, it's
|
||||
calibration result will be stored, passed through second lane, and
|
||||
shared with all three lanes PHY. The first two lanes PHY are used as
|
||||
calibration PHYs, although only the third lane PHY is used by SATA.
|
||||
- description: phandle to the first lane PHY of i.MX8QM.
|
||||
- description: phandle to the second lane PHY of i.MX8QM.
|
||||
|
||||
phy-names:
|
||||
items:
|
||||
- const: sata-phy
|
||||
- const: cali-phy0
|
||||
- const: cali-phy1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
|
@ -65,6 +87,31 @@ required:
|
|||
- clocks
|
||||
- clock-names
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,imx53-ahci
|
||||
- fsl,imx6q-ahci
|
||||
- fsl,imx6qp-ahci
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
minItems: 3
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,imx8qm-ahci
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
minItems: 2
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
|
|
|||
|
|
@ -1,48 +0,0 @@
|
|||
* Qualcomm AHCI SATA Controller
|
||||
|
||||
SATA nodes are defined to describe on-chip Serial ATA controllers.
|
||||
Each SATA controller should have its own node.
|
||||
|
||||
Required properties:
|
||||
- compatible : compatible list, must contain "generic-ahci"
|
||||
- interrupts : <interrupt mapping for SATA IRQ>
|
||||
- reg : <registers mapping>
|
||||
- phys : Must contain exactly one entry as specified
|
||||
in phy-bindings.txt
|
||||
- phy-names : Must be "sata-phy"
|
||||
|
||||
Required properties for "qcom,ipq806x-ahci" compatible:
|
||||
- clocks : Must contain an entry for each entry in clock-names.
|
||||
- clock-names : Shall be:
|
||||
"slave_iface" - Fabric port AHB clock for SATA
|
||||
"iface" - AHB clock
|
||||
"core" - core clock
|
||||
"rxoob" - RX out-of-band clock
|
||||
"pmalive" - Power Module Alive clock
|
||||
- assigned-clocks : Shall be:
|
||||
SATA_RXOOB_CLK
|
||||
SATA_PMALIVE_CLK
|
||||
- assigned-clock-rates : Shall be:
|
||||
100Mhz (100000000) for SATA_RXOOB_CLK
|
||||
100Mhz (100000000) for SATA_PMALIVE_CLK
|
||||
|
||||
Example:
|
||||
sata@29000000 {
|
||||
compatible = "qcom,ipq806x-ahci", "generic-ahci";
|
||||
reg = <0x29000000 0x180>;
|
||||
|
||||
interrupts = <0 209 0x0>;
|
||||
|
||||
clocks = <&gcc SFAB_SATA_S_H_CLK>,
|
||||
<&gcc SATA_H_CLK>,
|
||||
<&gcc SATA_A_CLK>,
|
||||
<&gcc SATA_RXOOB_CLK>,
|
||||
<&gcc SATA_PMALIVE_CLK>;
|
||||
clock-names = "slave_iface", "iface", "core",
|
||||
"rxoob", "pmalive";
|
||||
assigned-clocks = <&gcc SATA_RXOOB_CLK>, <&gcc SATA_PMALIVE_CLK>;
|
||||
assigned-clock-rates = <100000000>, <100000000>;
|
||||
|
||||
phys = <&sata_phy>;
|
||||
phy-names = "sata-phy";
|
||||
};
|
||||
32
Documentation/devicetree/bindings/board/fsl,bcsr.yaml
Normal file
32
Documentation/devicetree/bindings/board/fsl,bcsr.yaml
Normal file
|
|
@ -0,0 +1,32 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/board/fsl,bcsr.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Board Control and Status
|
||||
|
||||
maintainers:
|
||||
- Frank Li <Frank.Li@nxp.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- fsl,mpc8360mds-bcsr
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
board@f8000000 {
|
||||
compatible = "fsl,mpc8360mds-bcsr";
|
||||
reg = <0xf8000000 0x8000>;
|
||||
};
|
||||
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/board/fsl,fpga-qixis-i2c.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Freescale on-board FPGA connected on I2C bus
|
||||
|
||||
maintainers:
|
||||
- Frank Li <Frank.Li@nxp.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,bsc9132qds-fpga
|
||||
- const: fsl,fpga-qixis-i2c
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,ls1028aqds-fpga
|
||||
- fsl,lx2160aqds-fpga
|
||||
- const: fsl,fpga-qixis-i2c
|
||||
- const: simple-mfd
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
mux-controller:
|
||||
$ref: /schemas/mux/reg-mux.yaml
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
board-control@66 {
|
||||
compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
|
||||
reg = <0x66>;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
board-control@66 {
|
||||
compatible = "fsl,ls1028aqds-fpga", "fsl,fpga-qixis-i2c",
|
||||
"simple-mfd";
|
||||
reg = <0x66>;
|
||||
|
||||
mux-controller {
|
||||
compatible = "reg-mux";
|
||||
#mux-control-cells = <1>;
|
||||
mux-reg-masks = <0x54 0xf0>; /* 0: reg 0x54, bits 7:4 */
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
81
Documentation/devicetree/bindings/board/fsl,fpga-qixis.yaml
Normal file
81
Documentation/devicetree/bindings/board/fsl,fpga-qixis.yaml
Normal file
|
|
@ -0,0 +1,81 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/board/fsl,fpga-qixis.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Freescale on-board FPGA/CPLD
|
||||
|
||||
maintainers:
|
||||
- Frank Li <Frank.Li@nxp.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: fsl,p1022ds-fpga
|
||||
- const: fsl,fpga-ngpixis
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,ls1088aqds-fpga
|
||||
- fsl,ls1088ardb-fpga
|
||||
- fsl,ls2080aqds-fpga
|
||||
- fsl,ls2080ardb-fpga
|
||||
- const: fsl,fpga-qixis
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,ls1043aqds-fpga
|
||||
- fsl,ls1043ardb-fpga
|
||||
- fsl,ls1046aqds-fpga
|
||||
- fsl,ls1046ardb-fpga
|
||||
- fsl,ls208xaqds-fpga
|
||||
- const: fsl,fpga-qixis
|
||||
- const: simple-mfd
|
||||
- enum:
|
||||
- fsl,ls1043ardb-cpld
|
||||
- fsl,ls1046ardb-cpld
|
||||
- fsl,t1040rdb-cpld
|
||||
- fsl,t1042rdb-cpld
|
||||
- fsl,t1042rdb_pi-cpld
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
ranges:
|
||||
maxItems: 1
|
||||
|
||||
patternProperties:
|
||||
'^mdio-mux@[a-f0-9,]+$':
|
||||
$ref: /schemas/net/mdio-mux-mmioreg.yaml
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
board-control@3 {
|
||||
compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
|
||||
reg = <3 0x30>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <8 IRQ_TYPE_LEVEL_LOW 0 0>;
|
||||
};
|
||||
|
||||
- |
|
||||
board-control@3 {
|
||||
compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis";
|
||||
reg = <0x3 0x10000>;
|
||||
};
|
||||
|
||||
|
|
@ -1,81 +0,0 @@
|
|||
Freescale Reference Board Bindings
|
||||
|
||||
This document describes device tree bindings for various devices that
|
||||
exist on some Freescale reference boards.
|
||||
|
||||
* Board Control and Status (BCSR)
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "fsl,<board>-bcsr"
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
Example:
|
||||
|
||||
bcsr@f8000000 {
|
||||
compatible = "fsl,mpc8360mds-bcsr";
|
||||
reg = <f8000000 8000>;
|
||||
};
|
||||
|
||||
* Freescale on-board FPGA
|
||||
|
||||
This is the memory-mapped registers for on board FPGA.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be a board-specific string followed by a string
|
||||
indicating the type of FPGA. Example:
|
||||
"fsl,<board>-fpga", "fsl,fpga-pixis", or
|
||||
"fsl,<board>-fpga", "fsl,fpga-qixis"
|
||||
- reg: should contain the address and the length of the FPGA register set.
|
||||
|
||||
Optional properties:
|
||||
- interrupts: should specify event (wakeup) IRQ.
|
||||
|
||||
Example (P1022DS):
|
||||
|
||||
board-control@3,0 {
|
||||
compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis";
|
||||
reg = <3 0 0x30>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <8 8 0 0>;
|
||||
};
|
||||
|
||||
Example (LS2080A-RDB):
|
||||
|
||||
cpld@3,0 {
|
||||
compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis";
|
||||
reg = <0x3 0 0x10000>;
|
||||
};
|
||||
|
||||
* Freescale on-board FPGA connected on I2C bus
|
||||
|
||||
Some Freescale boards like BSC9132QDS have on board FPGA connected on
|
||||
the i2c bus.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be a board-specific string followed by a string
|
||||
indicating the type of FPGA. Example:
|
||||
"fsl,<board>-fpga", "fsl,fpga-qixis-i2c"
|
||||
- reg: Should contain the address of the FPGA
|
||||
|
||||
Example:
|
||||
fpga: fpga@66 {
|
||||
compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
|
||||
reg = <0x66>;
|
||||
};
|
||||
|
||||
* Freescale on-board CPLD
|
||||
|
||||
Some Freescale boards like T1040RDB have an on board CPLD connected.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be a board-specific string like "fsl,<board>-cpld"
|
||||
Example:
|
||||
"fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld"
|
||||
- reg: should describe CPLD registers
|
||||
|
||||
Example:
|
||||
cpld@3,0 {
|
||||
compatible = "fsl,t1040rdb-cpld";
|
||||
reg = <3 0 0x300>;
|
||||
};
|
||||
|
|
@ -1,138 +0,0 @@
|
|||
Qualcomm External Bus Interface 2 (EBI2)
|
||||
|
||||
The EBI2 contains two peripheral blocks: XMEM and LCDC. The XMEM handles any
|
||||
external memory (such as NAND or other memory-mapped peripherals) whereas
|
||||
LCDC handles LCD displays.
|
||||
|
||||
As it says it connects devices to an external bus interface, meaning address
|
||||
lines (up to 9 address lines so can only address 1KiB external memory space),
|
||||
data lines (16 bits), OE (output enable), ADV (address valid, used on some
|
||||
NOR flash memories), WE (write enable). This on top of 6 different chip selects
|
||||
(CS0 thru CS5) so that in theory 6 different devices can be connected.
|
||||
|
||||
Apparently this bus is clocked at 64MHz. It has dedicated pins on the package
|
||||
and the bus can only come out on these pins, however if some of the pins are
|
||||
unused they can be left unconnected or remuxed to be used as GPIO or in some
|
||||
cases other orthogonal functions as well.
|
||||
|
||||
Also CS1 and CS2 has -A and -B signals. Why they have that is unclear to me.
|
||||
|
||||
The chip selects have the following memory range assignments. This region of
|
||||
memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big.
|
||||
|
||||
Chip Select Physical address base
|
||||
CS0 GPIO134 0x1a800000-0x1b000000 (8MB)
|
||||
CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB)
|
||||
CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB)
|
||||
CS3 GPIO133 0x1d000000-0x25000000 (128 MB)
|
||||
CS4 GPIO132 0x1c800000-0x1d000000 (8MB)
|
||||
CS5 GPIO131 0x1c000000-0x1c800000 (8MB)
|
||||
|
||||
The APQ8060 Qualcomm Application Processor User Guide, 80-N7150-14 Rev. A,
|
||||
August 6, 2012 contains some incomplete documentation of the EBI2.
|
||||
|
||||
FIXME: the manual mentions "write precharge cycles" and "precharge cycles".
|
||||
We have not been able to figure out which bit fields these correspond to
|
||||
in the hardware, or what valid values exist. The current hypothesis is that
|
||||
this is something just used on the FAST chip selects and that the SLOW
|
||||
chip selects are understood fully. There is also a "byte device enable"
|
||||
flag somewhere for 8bit memories.
|
||||
|
||||
FIXME: The chipselects have SLOW and FAST configuration registers. It's a bit
|
||||
unclear what this means, if they are mutually exclusive or can be used
|
||||
together, or if some chip selects are hardwired to be FAST and others are SLOW
|
||||
by design.
|
||||
|
||||
The XMEM registers are totally undocumented but could be partially decoded
|
||||
because the Cypress AN49576 Antioch Westbridge apparently has suspiciously
|
||||
similar register layout, see: http://www.cypress.com/file/105771/download
|
||||
|
||||
Required properties:
|
||||
- compatible: should be one of:
|
||||
"qcom,msm8660-ebi2"
|
||||
"qcom,apq8060-ebi2"
|
||||
- #address-cells: should be <2>: the first cell is the chipselect,
|
||||
the second cell is the offset inside the memory range
|
||||
- #size-cells: should be <1>
|
||||
- ranges: should be set to:
|
||||
ranges = <0 0x0 0x1a800000 0x00800000>,
|
||||
<1 0x0 0x1b000000 0x00800000>,
|
||||
<2 0x0 0x1b800000 0x00800000>,
|
||||
<3 0x0 0x1d000000 0x08000000>,
|
||||
<4 0x0 0x1c800000 0x00800000>,
|
||||
<5 0x0 0x1c000000 0x00800000>;
|
||||
- reg: two ranges of registers: EBI2 config and XMEM config areas
|
||||
- reg-names: should be "ebi2", "xmem"
|
||||
- clocks: two clocks, EBI_2X and EBI
|
||||
- clock-names: should be "ebi2x", "ebi2"
|
||||
|
||||
Optional subnodes:
|
||||
- Nodes inside the EBI2 will be considered device nodes.
|
||||
|
||||
The following optional properties are properties that can be tagged onto
|
||||
any device subnode. We are assuming that there can be only ONE device per
|
||||
chipselect subnode, else the properties will become ambiguous.
|
||||
|
||||
Optional properties arrays for SLOW chip selects:
|
||||
- qcom,xmem-recovery-cycles: recovery cycles is the time the memory continues to
|
||||
drive the data bus after OE is de-asserted, in order to avoid contention on
|
||||
the data bus. They are inserted when reading one CS and switching to another
|
||||
CS or read followed by write on the same CS. Valid values 0 thru 15. Minimum
|
||||
value is actually 1, so a value of 0 will still yield 1 recovery cycle.
|
||||
- qcom,xmem-write-hold-cycles: write hold cycles, these are extra cycles
|
||||
inserted after every write minimum 1. The data out is driven from the time
|
||||
WE is asserted until CS is asserted. With a hold of 1 (value = 0), the CS
|
||||
stays active for 1 extra cycle etc. Valid values 0 thru 15.
|
||||
- qcom,xmem-write-delta-cycles: initial latency for write cycles inserted for
|
||||
the first write to a page or burst memory. Valid values 0 thru 255.
|
||||
- qcom,xmem-read-delta-cycles: initial latency for read cycles inserted for the
|
||||
first read to a page or burst memory. Valid values 0 thru 255.
|
||||
- qcom,xmem-write-wait-cycles: number of wait cycles for every write access, 0=1
|
||||
cycle. Valid values 0 thru 15.
|
||||
- qcom,xmem-read-wait-cycles: number of wait cycles for every read access, 0=1
|
||||
cycle. Valid values 0 thru 15.
|
||||
|
||||
Optional properties arrays for FAST chip selects:
|
||||
- qcom,xmem-address-hold-enable: this is a boolean property stating that we
|
||||
shall hold the address for an extra cycle to meet hold time requirements
|
||||
with ADV assertion.
|
||||
- qcom,xmem-adv-to-oe-recovery-cycles: the number of cycles elapsed before an OE
|
||||
assertion, with respect to the cycle where ADV (address valid) is asserted.
|
||||
2 means 2 cycles between ADV and OE. Valid values 0, 1, 2 or 3.
|
||||
- qcom,xmem-read-hold-cycles: the length in cycles of the first segment of a
|
||||
read transfer. For a single read transfer this will be the time from CS
|
||||
assertion to OE assertion. Valid values 0 thru 15.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
ebi2@1a100000 {
|
||||
compatible = "qcom,apq8060-ebi2";
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x0 0x1a800000 0x00800000>,
|
||||
<1 0x0 0x1b000000 0x00800000>,
|
||||
<2 0x0 0x1b800000 0x00800000>,
|
||||
<3 0x0 0x1d000000 0x08000000>,
|
||||
<4 0x0 0x1c800000 0x00800000>,
|
||||
<5 0x0 0x1c000000 0x00800000>;
|
||||
reg = <0x1a100000 0x1000>, <0x1a110000 0x1000>;
|
||||
reg-names = "ebi2", "xmem";
|
||||
clocks = <&gcc EBI2_2X_CLK>, <&gcc EBI2_CLK>;
|
||||
clock-names = "ebi2x", "ebi2";
|
||||
/* Make sure to set up the pin control for the EBI2 */
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&foo_ebi2_pins>;
|
||||
|
||||
foo-ebi2@2,0 {
|
||||
compatible = "foo";
|
||||
reg = <2 0x0 0x100>;
|
||||
(...)
|
||||
qcom,xmem-recovery-cycles = <0>;
|
||||
qcom,xmem-write-hold-cycles = <3>;
|
||||
qcom,xmem-write-delta-cycles = <31>;
|
||||
qcom,xmem-read-delta-cycles = <28>;
|
||||
qcom,xmem-write-wait-cycles = <9>;
|
||||
qcom,xmem-read-wait-cycles = <9>;
|
||||
};
|
||||
};
|
||||
239
Documentation/devicetree/bindings/bus/qcom,ebi2.yaml
Normal file
239
Documentation/devicetree/bindings/bus/qcom,ebi2.yaml
Normal file
|
|
@ -0,0 +1,239 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/bus/qcom,ebi2.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm External Bus Interface 2 (EBI2)
|
||||
|
||||
description: |
|
||||
The EBI2 contains two peripheral blocks: XMEM and LCDC. The XMEM handles any
|
||||
external memory (such as NAND or other memory-mapped peripherals) whereas
|
||||
LCDC handles LCD displays.
|
||||
|
||||
As it says it connects devices to an external bus interface, meaning address
|
||||
lines (up to 9 address lines so can only address 1KiB external memory space),
|
||||
data lines (16 bits), OE (output enable), ADV (address valid, used on some
|
||||
NOR flash memories), WE (write enable). This on top of 6 different chip selects
|
||||
(CS0 thru CS5) so that in theory 6 different devices can be connected.
|
||||
|
||||
Apparently this bus is clocked at 64MHz. It has dedicated pins on the package
|
||||
and the bus can only come out on these pins, however if some of the pins are
|
||||
unused they can be left unconnected or remuxed to be used as GPIO or in some
|
||||
cases other orthogonal functions as well.
|
||||
|
||||
Also CS1 and CS2 has -A and -B signals. Why they have that is unclear to me.
|
||||
|
||||
The chip selects have the following memory range assignments. This region of
|
||||
memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big.
|
||||
|
||||
Chip Select Physical address base
|
||||
CS0 GPIO134 0x1a800000-0x1b000000 (8MB)
|
||||
CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB)
|
||||
CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB)
|
||||
CS3 GPIO133 0x1d000000-0x25000000 (128 MB)
|
||||
CS4 GPIO132 0x1c800000-0x1d000000 (8MB)
|
||||
CS5 GPIO131 0x1c000000-0x1c800000 (8MB)
|
||||
|
||||
The APQ8060 Qualcomm Application Processor User Guide, 80-N7150-14 Rev. A,
|
||||
August 6, 2012 contains some incomplete documentation of the EBI2.
|
||||
|
||||
FIXME: the manual mentions "write precharge cycles" and "precharge cycles".
|
||||
We have not been able to figure out which bit fields these correspond to
|
||||
in the hardware, or what valid values exist. The current hypothesis is that
|
||||
this is something just used on the FAST chip selects and that the SLOW
|
||||
chip selects are understood fully. There is also a "byte device enable"
|
||||
flag somewhere for 8bit memories.
|
||||
|
||||
FIXME: The chipselects have SLOW and FAST configuration registers. It's a bit
|
||||
unclear what this means, if they are mutually exclusive or can be used
|
||||
together, or if some chip selects are hardwired to be FAST and others are SLOW
|
||||
by design.
|
||||
|
||||
The XMEM registers are totally undocumented but could be partially decoded
|
||||
because the Cypress AN49576 Antioch Westbridge apparently has suspiciously
|
||||
similar register layout, see: http://www.cypress.com/file/105771/download
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <andersson@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,apq8060-ebi2
|
||||
- qcom,msm8660-ebi2
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: EBI2 config region
|
||||
- description: XMEM config region
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: ebi2
|
||||
- const: xmem
|
||||
|
||||
ranges: true
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: EBI_2X clock
|
||||
- description: EBI clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ebi2x
|
||||
- const: ebi2
|
||||
|
||||
'#address-cells':
|
||||
const: 2
|
||||
|
||||
'#size-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- ranges
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#address-cells'
|
||||
- '#size-cells'
|
||||
|
||||
patternProperties:
|
||||
"^.*@[0-5],[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
# SLOW chip selects
|
||||
qcom,xmem-recovery-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The time the memory continues to drive the data bus after OE
|
||||
is de-asserted, in order to avoid contention on the data bus.
|
||||
They are inserted when reading one CS and switching to another
|
||||
CS or read followed by write on the same CS. Minimum value is
|
||||
actually 1, so a value of 0 will still yield 1 recovery cycle.
|
||||
minimum: 0
|
||||
maximum: 15
|
||||
|
||||
qcom,xmem-write-hold-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The extra cycles inserted after every write minimum 1. The
|
||||
data out is driven from the time WE is asserted until CS is
|
||||
asserted. With a hold of 1 (value = 0), the CS stays active
|
||||
for 1 extra cycle, etc.
|
||||
minimum: 0
|
||||
maximum: 15
|
||||
|
||||
qcom,xmem-write-delta-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The initial latency for write cycles inserted for the first
|
||||
write to a page or burst memory.
|
||||
minimum: 0
|
||||
maximum: 255
|
||||
|
||||
qcom,xmem-read-delta-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The initial latency for read cycles inserted for the first
|
||||
read to a page or burst memory.
|
||||
minimum: 0
|
||||
maximum: 255
|
||||
|
||||
qcom,xmem-write-wait-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The number of wait cycles for every write access.
|
||||
minimum: 0
|
||||
maximum: 15
|
||||
|
||||
qcom,xmem-read-wait-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The number of wait cycles for every read access.
|
||||
minimum: 0
|
||||
maximum: 15
|
||||
|
||||
|
||||
# FAST chip selects
|
||||
qcom,xmem-address-hold-enable:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
Holds the address for an extra cycle to meet hold time
|
||||
requirements with ADV assertion, when set to 1.
|
||||
enum: [ 0, 1 ]
|
||||
|
||||
qcom,xmem-adv-to-oe-recovery-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The number of cycles elapsed before an OE assertion, with
|
||||
respect to the cycle where ADV (address valid) is asserted.
|
||||
minimum: 0
|
||||
maximum: 3
|
||||
|
||||
qcom,xmem-read-hold-cycles:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: >
|
||||
The length in cycles of the first segment of a read transfer.
|
||||
For a single read transfer this will be the time from CS
|
||||
assertion to OE assertion.
|
||||
minimum: 0
|
||||
maximum: 15
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-msm8660.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
external-bus@1a100000 {
|
||||
compatible = "qcom,msm8660-ebi2";
|
||||
reg = <0x1a100000 0x1000>, <0x1a110000 0x1000>;
|
||||
reg-names = "ebi2", "xmem";
|
||||
ranges = <0 0x0 0x1a800000 0x00800000>,
|
||||
<1 0x0 0x1b000000 0x00800000>,
|
||||
<2 0x0 0x1b800000 0x00800000>,
|
||||
<3 0x0 0x1d000000 0x08000000>,
|
||||
<4 0x0 0x1c800000 0x00800000>,
|
||||
<5 0x0 0x1c000000 0x00800000>;
|
||||
|
||||
clocks = <&gcc EBI2_2X_CLK>, <&gcc EBI2_CLK>;
|
||||
clock-names = "ebi2x", "ebi2";
|
||||
|
||||
#address-cells = <2>;
|
||||
#size-cells = <1>;
|
||||
|
||||
ethernet@2,0 {
|
||||
compatible = "smsc,lan9221", "smsc,lan9115";
|
||||
reg = <2 0x0 0x100>;
|
||||
|
||||
interrupts-extended = <&pm8058_gpio 7 IRQ_TYPE_EDGE_FALLING>,
|
||||
<&tlmm 29 IRQ_TYPE_EDGE_RISING>;
|
||||
reset-gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
|
||||
|
||||
phy-mode = "mii";
|
||||
reg-io-width = <2>;
|
||||
smsc,force-external-phy;
|
||||
smsc,irq-push-pull;
|
||||
|
||||
/* SLOW chipselect config */
|
||||
qcom,xmem-recovery-cycles = <0>;
|
||||
qcom,xmem-write-hold-cycles = <3>;
|
||||
qcom,xmem-write-delta-cycles = <31>;
|
||||
qcom,xmem-read-delta-cycles = <28>;
|
||||
qcom,xmem-write-wait-cycles = <9>;
|
||||
qcom,xmem-read-wait-cycles = <9>;
|
||||
};
|
||||
};
|
||||
|
|
@ -24,11 +24,13 @@ properties:
|
|||
items:
|
||||
- description: input top pll
|
||||
- description: input mclk pll
|
||||
- description: input fix pll
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: top
|
||||
- const: mclk
|
||||
- const: fix
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
|
@ -52,8 +54,9 @@ examples:
|
|||
compatible = "amlogic,c3-pll-clkc";
|
||||
reg = <0x0 0x8000 0x0 0x1a4>;
|
||||
clocks = <&scmi_clk 2>,
|
||||
<&scmi_clk 5>;
|
||||
clock-names = "top", "mclk";
|
||||
<&scmi_clk 5>,
|
||||
<&scmi_clk 12>;
|
||||
clock-names = "top", "mclk", "fix";
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -126,8 +126,6 @@ required:
|
|||
- compatible
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
- idt,shutdown
|
||||
- idt,output-enable-active
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
|
|
|
|||
|
|
@ -1,54 +0,0 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/mediatek,mt6795-sys-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek System Clock Controller for MT6795
|
||||
|
||||
maintainers:
|
||||
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
||||
- Chun-Jie Chen <chun-jie.chen@mediatek.com>
|
||||
|
||||
description:
|
||||
The Mediatek system clock controller provides various clocks and system
|
||||
configuration like reset and bus protection on MT6795.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- mediatek,mt6795-apmixedsys
|
||||
- mediatek,mt6795-infracfg
|
||||
- mediatek,mt6795-pericfg
|
||||
- mediatek,mt6795-topckgen
|
||||
- const: syscon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
soc {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
topckgen: clock-controller@10000000 {
|
||||
compatible = "mediatek,mt6795-topckgen", "syscon";
|
||||
reg = <0 0x10000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -31,6 +31,8 @@ properties:
|
|||
- description: USB PCIE wrapper pipe clock source
|
||||
|
||||
'#power-domain-cells': false
|
||||
'#interconnect-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ examples:
|
|||
- |
|
||||
rpm {
|
||||
rpm-requests {
|
||||
compatible = "qcom,rpm-msm8916";
|
||||
compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
|
||||
qcom,smd-channels = "rpm_requests";
|
||||
|
||||
clock-controller {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,63 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sm4450-camcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Camera Clock & Reset Controller on SM4450
|
||||
|
||||
maintainers:
|
||||
- Ajit Pandey <quic_ajipan@quicinc.com>
|
||||
- Taniya Das <quic_tdas@quicinc.com>
|
||||
|
||||
description: |
|
||||
Qualcomm camera clock control module provides the clocks, resets and power
|
||||
domains on SM4450
|
||||
|
||||
See also:: include/dt-bindings/clock/qcom,sm4450-camcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sm4450-camcc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Camera AHB clock source from GCC
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/clock/qcom,sm4450-gcc.h>
|
||||
clock-controller@ade0000 {
|
||||
compatible = "qcom,sm4450-camcc";
|
||||
reg = <0x0ade0000 0x20000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&gcc GCC_CAMERA_AHB_CLK>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sm4450-dispcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Display Clock & Reset Controller on SM4450
|
||||
|
||||
maintainers:
|
||||
- Ajit Pandey <quic_ajipan@quicinc.com>
|
||||
- Taniya Das <quic_tdas@quicinc.com>
|
||||
|
||||
description: |
|
||||
Qualcomm display clock control module provides the clocks, resets and power
|
||||
domains on SM4450
|
||||
|
||||
See also:: include/dt-bindings/clock/qcom,sm4450-dispcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sm4450-dispcc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Board active XO source
|
||||
- description: Display AHB clock source from GCC
|
||||
- description: sleep clock source
|
||||
- description: Byte clock from DSI PHY0
|
||||
- description: Pixel clock from DSI PHY0
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/clock/qcom,sm4450-gcc.h>
|
||||
clock-controller@af00000 {
|
||||
compatible = "qcom,sm4450-dispcc";
|
||||
reg = <0x0af00000 0x20000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK_A>,
|
||||
<&gcc GCC_DISP_AHB_CLK>,
|
||||
<&sleep_clk>,
|
||||
<&dsi0_phy_pll_out_byteclk>,
|
||||
<&dsi0_phy_pll_out_dsiclk>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sm8150-camcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Camera Clock & Reset Controller on SM8150
|
||||
|
||||
maintainers:
|
||||
- Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
|
||||
|
||||
description: |
|
||||
Qualcomm camera clock control module provides the clocks, resets and
|
||||
power domains on SM8150.
|
||||
|
||||
See also:: include/dt-bindings/clock/qcom,sm8150-camcc.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sm8150-camcc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Camera AHB clock from GCC
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
description:
|
||||
A phandle and PM domain specifier for the MMCX power domain.
|
||||
|
||||
required-opps:
|
||||
maxItems: 1
|
||||
description:
|
||||
A phandle to an OPP node describing required MMCX performance point.
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- power-domains
|
||||
- required-opps
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-sm8150.h>
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/power/qcom-rpmpd.h>
|
||||
clock-controller@ad00000 {
|
||||
compatible = "qcom,sm8150-camcc";
|
||||
reg = <0x0ad00000 0x10000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&gcc GCC_CAMERA_AHB_CLK>;
|
||||
power-domains = <&rpmhpd SM8150_MMCX>;
|
||||
required-opps = <&rpmhpd_opp_low_svs>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
||||
|
|
@ -14,6 +14,7 @@ description: |
|
|||
domains on Qualcomm SoCs.
|
||||
|
||||
See also::
|
||||
include/dt-bindings/clock/qcom,sm4450-gpucc.h
|
||||
include/dt-bindings/clock/qcom,sm8450-gpucc.h
|
||||
include/dt-bindings/clock/qcom,sm8550-gpucc.h
|
||||
include/dt-bindings/reset/qcom,sm8450-gpucc.h
|
||||
|
|
@ -23,6 +24,7 @@ description: |
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sm4450-gpucc
|
||||
- qcom,sm8450-gpucc
|
||||
- qcom,sm8550-gpucc
|
||||
- qcom,sm8650-gpucc
|
||||
|
|
|
|||
|
|
@ -0,0 +1,80 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/renesas,rzv2h-cpg.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas RZ/V2H(P) Clock Pulse Generator (CPG)
|
||||
|
||||
maintainers:
|
||||
- Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
|
||||
|
||||
description:
|
||||
On Renesas RZ/V2H(P) SoCs, the CPG (Clock Pulse Generator) handles generation
|
||||
and control of clock signals for the IP modules, generation and control of resets,
|
||||
and control over booting, low power consumption and power supply domains.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: renesas,r9a09g057-cpg
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: AUDIO_EXTAL clock input
|
||||
- description: RTXIN clock input
|
||||
- description: QEXTAL clock input
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: audio_extal
|
||||
- const: rtxin
|
||||
- const: qextal
|
||||
|
||||
'#clock-cells':
|
||||
description: |
|
||||
- For CPG core clocks, the two clock specifier cells must be "CPG_CORE"
|
||||
and a core clock reference, as defined in
|
||||
<dt-bindings/clock/renesas,r9a09g057-cpg.h>,
|
||||
- For module clocks, the two clock specifier cells must be "CPG_MOD" and
|
||||
a module number. The module number is calculated as the CLKON register
|
||||
offset index multiplied by 16, plus the actual bit in the register
|
||||
used to turn the CLK ON. For example, for CGC_GIC_0_GICCLK, the
|
||||
calculation is (1 * 16 + 3) = 0x13.
|
||||
const: 2
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 0
|
||||
|
||||
'#reset-cells':
|
||||
description:
|
||||
The single reset specifier cell must be the reset number. The reset number
|
||||
is calculated as the reset register offset index multiplied by 16, plus the
|
||||
actual bit in the register used to reset the specific IP block. For example,
|
||||
for SYS_0_PRESETN, the calculation is (3 * 16 + 0) = 0x30.
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#clock-cells'
|
||||
- '#power-domain-cells'
|
||||
- '#reset-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock-controller@10420000 {
|
||||
compatible = "renesas,r9a09g057-cpg";
|
||||
reg = <0x10420000 0x10000>;
|
||||
clocks = <&audio_extal_clk>, <&rtxin_clk>, <&qextal_clk>;
|
||||
clock-names = "audio_extal", "rtxin", "qextal";
|
||||
#clock-cells = <2>;
|
||||
#power-domain-cells = <0>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
|
@ -35,6 +35,7 @@ properties:
|
|||
- samsung,exynosautov9-cmu-top
|
||||
- samsung,exynosautov9-cmu-busmc
|
||||
- samsung,exynosautov9-cmu-core
|
||||
- samsung,exynosautov9-cmu-dpum
|
||||
- samsung,exynosautov9-cmu-fsys0
|
||||
- samsung,exynosautov9-cmu-fsys1
|
||||
- samsung,exynosautov9-cmu-fsys2
|
||||
|
|
@ -109,6 +110,24 @@ allOf:
|
|||
- const: oscclk
|
||||
- const: dout_clkcmu_core_bus
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: samsung,exynosautov9-cmu-dpum
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (26 MHz)
|
||||
- description: DPU Main bus clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: bus
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,162 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/samsung,exynosautov920-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung ExynosAuto v920 SoC clock controller
|
||||
|
||||
maintainers:
|
||||
- Sunyeal Hong <sunyeal.hong@samsung.com>
|
||||
- Chanwoo Choi <cw00.choi@samsung.com>
|
||||
- Krzysztof Kozlowski <krzk@kernel.org>
|
||||
- Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
|
||||
description: |
|
||||
ExynosAuto v920 clock controller is comprised of several CMU units, generating
|
||||
clocks for different domains. Those CMU units are modeled as separate device
|
||||
tree nodes, and might depend on each other. Root clocks in that clock tree are
|
||||
two external clocks:: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
|
||||
The external OSCCLK must be defined as fixed-rate clock in dts.
|
||||
|
||||
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
|
||||
dividers; all other clocks of function blocks (other CMUs) are usually
|
||||
derived from CMU_TOP.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume. All clocks available for usage
|
||||
in clock consumer nodes are defined as preprocessor macros in
|
||||
'include/dt-bindings/clock/samsung,exynosautov920.h' header.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- samsung,exynosautov920-cmu-top
|
||||
- samsung,exynosautov920-cmu-peric0
|
||||
- samsung,exynosautov920-cmu-peric1
|
||||
- samsung,exynosautov920-cmu-misc
|
||||
- samsung,exynosautov920-cmu-hsi0
|
||||
- samsung,exynosautov920-cmu-hsi1
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: samsung,exynosautov920-cmu-top
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (38.4 MHz)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- samsung,exynosautov920-cmu-peric0
|
||||
- samsung,exynosautov920-cmu-peric1
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (38.4 MHz)
|
||||
- description: CMU_PERICn NOC clock (from CMU_TOP)
|
||||
- description: CMU_PERICn IP clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: noc
|
||||
- const: ip
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- samsung,exynosautov920-cmu-misc
|
||||
- samsung,exynosautov920-cmu-hsi0
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (38.4 MHz)
|
||||
- description: CMU_MISC/CMU_HSI0 NOC clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: noc
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: samsung,exynosautov920-cmu-hsi1
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: External reference clock (38.4 MHz)
|
||||
- description: CMU_HSI1 NOC clock (from CMU_TOP)
|
||||
- description: CMU_HSI1 USBDRD clock (from CMU_TOP)
|
||||
- description: CMU_HSI1 MMC_CARD clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: oscclk
|
||||
- const: noc
|
||||
- const: usbdrd
|
||||
- const: mmc_card
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- clocks
|
||||
- clock-names
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
# Clock controller node for CMU_PERIC0
|
||||
- |
|
||||
#include <dt-bindings/clock/samsung,exynosautov920.h>
|
||||
|
||||
cmu_peric0: clock-controller@10800000 {
|
||||
compatible = "samsung,exynosautov920-cmu-peric0";
|
||||
reg = <0x10800000 0x8000>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
clocks = <&xtcxo>,
|
||||
<&cmu_top DOUT_CLKCMU_PERIC0_NOC>,
|
||||
<&cmu_top DOUT_CLKCMU_PERIC0_IP>;
|
||||
clock-names = "oscclk",
|
||||
"noc",
|
||||
"ip";
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -385,7 +385,7 @@ patternProperties:
|
|||
|
||||
This property is required in idle state nodes of device tree meant
|
||||
for RISC-V systems. For more details on the suspend_type parameter
|
||||
refer the SBI specifiation v0.3 (or higher) [7].
|
||||
refer the SBI specification v0.3 (or higher) [7].
|
||||
|
||||
local-timer-stop:
|
||||
description:
|
||||
|
|
|
|||
|
|
@ -1,37 +0,0 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/cpu/nvidia,tegra186-ccplex-cluster.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: NVIDIA Tegra186 CCPLEX Cluster
|
||||
|
||||
maintainers:
|
||||
- Thierry Reding <thierry.reding@gmail.com>
|
||||
- Jon Hunter <jonathanh@nvidia.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: nvidia,tegra186-ccplex-cluster
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
nvidia,bpmp:
|
||||
description: phandle to the BPMP used to query CPU frequency tables
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- nvidia,bpmp
|
||||
|
||||
examples:
|
||||
- |
|
||||
ccplex@e000000 {
|
||||
compatible = "nvidia,tegra186-ccplex-cluster";
|
||||
reg = <0x0e000000 0x400000>;
|
||||
nvidia,bpmp = <&bpmp>;
|
||||
};
|
||||
|
|
@ -137,7 +137,10 @@ patternProperties:
|
|||
- const: fsl,sec-v4.0-rtic
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
items:
|
||||
- description: RTIC control and status register space.
|
||||
- description: RTIC recoverable error indication register space.
|
||||
minItems: 1
|
||||
|
||||
ranges:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ properties:
|
|||
- qcom,prng-ee # 8996 and later using EE
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sa8255p-trng
|
||||
- qcom,sa8775p-trng
|
||||
- qcom,sc7280-trng
|
||||
- qcom,sm8450-trng
|
||||
|
|
|
|||
|
|
@ -50,6 +50,14 @@ properties:
|
|||
- const: disp_axi
|
||||
minItems: 1
|
||||
|
||||
dmas:
|
||||
items:
|
||||
- description: DMA specifier for the RX DMA channel.
|
||||
|
||||
dma-names:
|
||||
items:
|
||||
- const: rx
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: LCDIF DMA interrupt
|
||||
|
|
@ -156,6 +164,18 @@ allOf:
|
|||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
- if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,imx28-lcdif
|
||||
then:
|
||||
properties:
|
||||
dmas: false
|
||||
dma-names: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/imx6sx-clock.h>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ maintainers:
|
|||
description:
|
||||
This binding extends the data mapping defined in lvds-data-mapping.yaml.
|
||||
It supports reversing the bit order on the formats defined there in order
|
||||
to accomodate for even more specialized data formats, since a variety of
|
||||
to accommodate for even more specialized data formats, since a variety of
|
||||
data formats and layouts is used to drive LVDS displays.
|
||||
|
||||
properties:
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/panel/wl-355608-a8.yaml#
|
||||
$id: http://devicetree.org/schemas/display/panel/anbernic,rg35xx-plus-panel.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: WL-355608-A8 3.5" (640x480 pixels) 24-bit IPS LCD panel
|
||||
title: Anbernic RG35XX series (WL-355608-A8) 3.5" 640x480 24-bit IPS LCD panel
|
||||
|
||||
maintainers:
|
||||
- Ryan Walklin <ryan@testtoast.com>
|
||||
|
|
@ -15,7 +15,14 @@ allOf:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
const: wl-355608-a8
|
||||
oneOf:
|
||||
- const: anbernic,rg35xx-plus-panel
|
||||
- items:
|
||||
- enum:
|
||||
- anbernic,rg35xx-2024-panel
|
||||
- anbernic,rg35xx-h-panel
|
||||
- anbernic,rg35xx-sp-panel
|
||||
- const: anbernic,rg35xx-plus-panel
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -40,7 +47,7 @@ examples:
|
|||
#size-cells = <0>;
|
||||
|
||||
panel@0 {
|
||||
compatible = "wl-355608-a8";
|
||||
compatible = "anbernic,rg35xx-plus-panel";
|
||||
reg = <0>;
|
||||
|
||||
spi-3wire;
|
||||
|
|
@ -84,11 +84,7 @@ properties:
|
|||
- port@0
|
||||
- port@1
|
||||
|
||||
backlight: true
|
||||
enable-gpios: true
|
||||
power-supply: true
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
|||
|
|
@ -0,0 +1,49 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/dma/nxp,lpc3220-dmamux.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: DMA multiplexer for LPC32XX SoC (DMA request router)
|
||||
|
||||
maintainers:
|
||||
- J.M.B. Downing <jonathan.downing@nautel.com>
|
||||
- Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
|
||||
|
||||
allOf:
|
||||
- $ref: dma-router.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: nxp,lpc3220-dmamux
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
dma-masters:
|
||||
description: phandle to a dma node compatible with arm,pl080
|
||||
maxItems: 1
|
||||
|
||||
"#dma-cells":
|
||||
const: 3
|
||||
description: |
|
||||
First two cells same as for device pointed in dma-masters.
|
||||
Third cell represents mux value for the request.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- dma-masters
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
dma-router@7c {
|
||||
compatible = "nxp,lpc3220-dmamux";
|
||||
reg = <0x7c 0x8>;
|
||||
dma-masters = <&dma>;
|
||||
#dma-cells = <3>;
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -20,7 +20,7 @@ Optional properties:
|
|||
memcpy channels in eDMA.
|
||||
|
||||
Notes:
|
||||
When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request
|
||||
When requesting channel via ti,dra7-dma-crossbar, the DMA client must request
|
||||
the DMA event number as crossbar ID (input to the DMA crossbar).
|
||||
|
||||
For ti,am335x-edma-crossbar: the meaning of parameters of dmas for clients:
|
||||
|
|
|
|||
|
|
@ -22,6 +22,9 @@ description: |
|
|||
|
||||
[0] https://developer.arm.com/documentation/den0056/latest
|
||||
|
||||
anyOf:
|
||||
- $ref: /schemas/firmware/nxp,imx95-scmi.yaml
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: scmi
|
||||
|
|
@ -121,6 +124,13 @@ properties:
|
|||
atomic mode of operation, even if requested.
|
||||
default: 0
|
||||
|
||||
max-rx-timeout-ms:
|
||||
description:
|
||||
An optional time value, expressed in milliseconds, representing the
|
||||
transport maximum timeout value for the receive channel. The value should
|
||||
be a non-zero value if set.
|
||||
minimum: 1
|
||||
|
||||
arm,smc-id:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
|
|
@ -145,6 +155,14 @@ properties:
|
|||
required:
|
||||
- '#power-domain-cells'
|
||||
|
||||
protocol@12:
|
||||
$ref: '#/$defs/protocol-node'
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0x12
|
||||
|
||||
protocol@13:
|
||||
$ref: '#/$defs/protocol-node'
|
||||
unevaluatedProperties: false
|
||||
|
|
@ -284,7 +302,7 @@ properties:
|
|||
required:
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
$defs:
|
||||
protocol-node:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,43 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
# Copyright 2024 NXP
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/firmware/nxp,imx95-scmi.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: i.MX95 System Control and Management Interface(SCMI) Vendor Protocols Extension
|
||||
|
||||
maintainers:
|
||||
- Peng Fan <peng.fan@nxp.com>
|
||||
|
||||
properties:
|
||||
protocol@81:
|
||||
$ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node'
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0x81
|
||||
|
||||
protocol@84:
|
||||
$ref: '/schemas/firmware/arm,scmi.yaml#/$defs/protocol-node'
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0x84
|
||||
|
||||
nxp,ctrl-ids:
|
||||
description:
|
||||
Each entry consists of 2 integers, represents the ctrl id and the value
|
||||
items:
|
||||
items:
|
||||
- description: the ctrl id index
|
||||
enum: [0, 1, 2, 3, 4, 5, 6, 7, 0x8000, 0x8001, 0x8002, 0x8003,
|
||||
0x8004, 0x8005, 0x8006, 0x8007]
|
||||
- description: the value assigned to the ctrl id
|
||||
minItems: 1
|
||||
maxItems: 16
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
|
||||
additionalProperties: true
|
||||
|
|
@ -18,6 +18,7 @@ description:
|
|||
|
||||
allOf:
|
||||
- $ref: gnss-common.yaml#
|
||||
- $ref: /schemas/serial/serial-peripheral-props.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user