Merge branch 'torvalds:master' into master
1
.gitignore
vendored
|
@ -24,6 +24,7 @@
|
||||||
*.dwo
|
*.dwo
|
||||||
*.elf
|
*.elf
|
||||||
*.gcno
|
*.gcno
|
||||||
|
*.gcda
|
||||||
*.gz
|
*.gz
|
||||||
*.i
|
*.i
|
||||||
*.ko
|
*.ko
|
||||||
|
|
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 Kleen <ak@linux.intel.com> <ak@suse.de>
|
||||||
Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
|
Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
|
||||||
Andreas Herrmann <aherrman@de.ibm.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@collabora.co.uk>
|
||||||
Andrej Shadura <andrew@shadura.me> <andrew@beldisplaytech.com>
|
Andrej Shadura <andrew@shadura.me> <andrew@beldisplaytech.com>
|
||||||
Andrew Morton <akpm@linux-foundation.org>
|
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@de.ibm.com>
|
||||||
Jan Glauber <jan.glauber@gmail.com> <jang@linux.vnet.ibm.com>
|
Jan Glauber <jan.glauber@gmail.com> <jang@linux.vnet.ibm.com>
|
||||||
Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.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.sakkinen@linux.intel.com>
|
||||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
|
Jarkko Sakkinen <jarkko@kernel.org> <jarkko@profian.com>
|
||||||
Jarkko Sakkinen <jarkko@kernel.org> <jarkko.sakkinen@tuni.fi>
|
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>
|
Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>
|
||||||
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>
|
||||||
Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.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> <khlebnikov@yandex-team.ru>
|
||||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||||
Koushik <raghavendra.koushik@neterion.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 A Jonsson <pj@ludd.ltu.se>
|
||||||
Peter Oruba <peter.oruba@amd.com>
|
Peter Oruba <peter.oruba@amd.com>
|
||||||
Peter Oruba <peter@oruba.de>
|
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>
|
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||||
Praveen BP <praveenbp@ti.com>
|
Praveen BP <praveenbp@ti.com>
|
||||||
Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> <pradeepc@codeaurora.org>
|
Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> <pradeepc@codeaurora.org>
|
||||||
|
|
6
CREDITS
|
@ -378,6 +378,9 @@ S: 1549 Hiironen Rd.
|
||||||
S: Brimson, MN 55602
|
S: Brimson, MN 55602
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
|
N: Arnd Bergmann
|
||||||
|
D: Maintainer of Cell Broadband Engine Architecture
|
||||||
|
|
||||||
N: Hennus Bergman
|
N: Hennus Bergman
|
||||||
P: 1024/77D50909 76 99 FD 31 91 E1 96 1C 90 BB 22 80 62 F6 BD 63
|
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
|
D: Author and maintainer of the QIC-02 tape driver
|
||||||
|
@ -1869,6 +1872,9 @@ S: K osmidomkum 723
|
||||||
S: 160 00 Praha 6
|
S: 160 00 Praha 6
|
||||||
S: Czech Republic
|
S: Czech Republic
|
||||||
|
|
||||||
|
N: Jeremy Kerr
|
||||||
|
D: Maintainer of SPU File System
|
||||||
|
|
||||||
N: Michael Kerrisk
|
N: Michael Kerrisk
|
||||||
E: mtk.manpages@gmail.com
|
E: mtk.manpages@gmail.com
|
||||||
W: https://man7.org/
|
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
|
the vDSO and it often contains useful and highly-optimized alternatives
|
||||||
to real syscalls.
|
to real syscalls.
|
||||||
|
|
||||||
These functions are called just like ordinary C function according to
|
These functions are called according to your platform's ABI. On many
|
||||||
your platform's ABI. Call them from a sensible context. (For example,
|
platforms they are called just like ordinary C function. On other platforms
|
||||||
if you set CS on x86 to something strange, the vDSO functions are
|
(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
|
within their rights to crash.) In addition, if you pass a bad
|
||||||
pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT.
|
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
|
Date: July 2009
|
||||||
Contact: linux-pm@vger.kernel.org
|
Contact: linux-pm@vger.kernel.org
|
||||||
Description:
|
Description:
|
||||||
Represents the type of charging currently being applied to the
|
Select the charging algorithm to use for a battery.
|
||||||
battery. "Trickle", "Fast", and "Standard" all mean different
|
|
||||||
charging speeds. "Adaptive" means that the charger uses some
|
Standard:
|
||||||
algorithm to adjust the charge rate dynamically, without
|
Fully charge the battery at a moderate rate.
|
||||||
any user configuration required. "Custom" means that the charger
|
Fast:
|
||||||
uses the charge_control_* properties as configuration for some
|
Quickly charge the battery using fast-charge
|
||||||
different algorithm. "Long Life" means the charger reduces its
|
technology. This is typically harder on the battery
|
||||||
charging rate in order to prolong the battery health. "Bypass"
|
than standard charging and may lower its lifespan.
|
||||||
means the charger bypasses the charging path around the
|
Trickle:
|
||||||
integrated converter allowing for a "smart" wall adaptor to
|
Users who primarily operate the system while
|
||||||
perform the power conversion externally.
|
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
|
Access: Read, Write
|
||||||
|
|
||||||
|
@ -592,7 +608,12 @@ Description:
|
||||||
the supply, for example it can show if USB-PD capable source
|
the supply, for example it can show if USB-PD capable source
|
||||||
is attached.
|
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:
|
Valid values:
|
||||||
"Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
|
"Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
|
||||||
|
|
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
|
the estimated point where the FPGA latches the PHC time. This
|
||||||
value may be changed by writing an unsigned integer.
|
value may be changed by writing an unsigned integer.
|
||||||
|
|
||||||
What: /sys/class/timecard/ocpN/ttyGNSS
|
What: /sys/class/timecard/ocpN/tty
|
||||||
What: /sys/class/timecard/ocpN/ttyGNSS2
|
Date: August 2024
|
||||||
Date: September 2021
|
Contact: Vadim Fedorenko <vadim.fedorenko@linux.dev>
|
||||||
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
Description: (RO) Directory containing the sysfs nodes for TTY attributes
|
||||||
Description: These optional attributes link to the TTY serial ports
|
|
||||||
associated with the GNSS devices.
|
|
||||||
|
|
||||||
What: /sys/class/timecard/ocpN/ttyMAC
|
What: /sys/class/timecard/ocpN/tty/ttyGNSS
|
||||||
Date: September 2021
|
What: /sys/class/timecard/ocpN/tty/ttyGNSS2
|
||||||
|
Date: August 2024
|
||||||
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
||||||
Description: This optional attribute links to the TTY serial port
|
Description: (RO) These optional attributes contain names of the TTY serial
|
||||||
associated with the Miniature Atomic Clock.
|
ports associated with the GNSS devices.
|
||||||
|
|
||||||
What: /sys/class/timecard/ocpN/ttyNMEA
|
What: /sys/class/timecard/ocpN/tty/ttyMAC
|
||||||
Date: September 2021
|
Date: August 2024
|
||||||
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
|
||||||
Description: This optional attribute links to the TTY serial port
|
Description: (RO) This optional attribute contains name of the TTY serial
|
||||||
which outputs the PHC time in NMEA ZDA format.
|
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
|
What: /sys/class/timecard/ocpN/utc_tai_offset
|
||||||
Date: September 2021
|
Date: September 2021
|
||||||
|
|
|
@ -52,7 +52,7 @@ driver generally needs to perform the following initialization:
|
||||||
- Enable DMA/processing engines
|
- Enable DMA/processing engines
|
||||||
|
|
||||||
When done using the device, and perhaps the module needs to be unloaded,
|
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
|
- Disable the device from generating IRQs
|
||||||
- Release the IRQ (free_irq())
|
- 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;
|
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,
|
corresponding CPU's dyntick-idle state when forcing quiescent states,
|
||||||
and is therefore accessed from other CPUs. Finally, the
|
and is therefore accessed from other CPUs. Finally, the
|
||||||
``->dynticks_fqs`` field is used to count the number of times this CPU
|
``->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;
|
1 long nesting;
|
||||||
2 long dynticks_nmi_nesting;
|
2 long nmi_nesting;
|
||||||
3 atomic_t dynticks;
|
3 atomic_t dynticks;
|
||||||
4 bool rcu_need_heavy_qs;
|
4 bool rcu_need_heavy_qs;
|
||||||
5 bool rcu_urgent_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
|
state for the corresponding CPU. The fields may be accessed only from
|
||||||
the corresponding CPU (and from tracing) unless otherwise stated.
|
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
|
execution, so that in normal circumstances this counter has value zero
|
||||||
or one. NMIs, irqs, and tracers are counted by the
|
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
|
to this variable have to be undertaken carefully using an algorithm
|
||||||
provided by Andy Lutomirski. The initial transition from idle adds one,
|
provided by Andy Lutomirski. The initial transition from idle adds one,
|
||||||
and nested transitions add two, so that a nesting level of five is
|
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
|
can therefore be thought of as counting the number of reasons why this
|
||||||
CPU cannot be permitted to enter dyntick-idle mode, aside from
|
CPU cannot be permitted to enter dyntick-idle mode, aside from
|
||||||
process-level transitions.
|
process-level transitions.
|
||||||
|
@ -960,12 +960,12 @@ process-level transitions.
|
||||||
However, it turns out that when running in non-idle kernel context, the
|
However, it turns out that when running in non-idle kernel context, the
|
||||||
Linux kernel is fully capable of entering interrupt handlers that never
|
Linux kernel is fully capable of entering interrupt handlers that never
|
||||||
exit and perhaps also vice versa. Therefore, whenever the
|
exit and perhaps also vice versa. Therefore, whenever the
|
||||||
``->dynticks_nesting`` field is incremented up from zero, the
|
``->nesting`` field is incremented up from zero, the
|
||||||
``->dynticks_nmi_nesting`` field is set to a large positive number, and
|
``->nmi_nesting`` field is set to a large positive number, and
|
||||||
whenever the ``->dynticks_nesting`` field is decremented down to zero,
|
whenever the ``->nesting`` field is decremented down to zero,
|
||||||
the ``->dynticks_nmi_nesting`` field is set to zero. Assuming that
|
the ``->nmi_nesting`` field is set to zero. Assuming that
|
||||||
the number of misnested interrupts is not sufficient to overflow the
|
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
|
every time the corresponding CPU enters the idle loop from process
|
||||||
context.
|
context.
|
||||||
|
|
||||||
|
@ -992,8 +992,8 @@ code.
|
||||||
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
|
||||||
| **Quick Quiz**: |
|
| **Quick Quiz**: |
|
||||||
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
|
||||||
| Why not simply combine the ``->dynticks_nesting`` and |
|
| Why not simply combine the ``->nesting`` and |
|
||||||
| ``->dynticks_nmi_nesting`` counters into a single counter that just |
|
| ``->nmi_nesting`` counters into a single counter that just |
|
||||||
| counts the number of reasons that the corresponding CPU is non-idle? |
|
| counts the number of reasons that the corresponding CPU is non-idle? |
|
||||||
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
|
||||||
| **Answer**: |
|
| **Answer**: |
|
||||||
|
|
|
@ -147,10 +147,10 @@ RCU read-side critical sections preceding and following the current
|
||||||
idle sojourn.
|
idle sojourn.
|
||||||
This case is handled by calls to the strongly ordered
|
This case is handled by calls to the strongly ordered
|
||||||
``atomic_add_return()`` read-modify-write atomic operation that
|
``atomic_add_return()`` read-modify-write atomic operation that
|
||||||
is invoked within ``rcu_dynticks_eqs_enter()`` at idle-entry
|
is invoked within ``ct_kernel_exit_state()`` at idle-entry
|
||||||
time and within ``rcu_dynticks_eqs_exit()`` at idle-exit time.
|
time and within ``ct_kernel_enter_state()`` at idle-exit time.
|
||||||
The grace-period kthread invokes first ``ct_dynticks_cpu_acquire()``
|
The grace-period kthread invokes first ``ct_rcu_watching_cpu_acquire()``
|
||||||
(preceded by a full memory barrier) and ``rcu_dynticks_in_eqs_since()``
|
(preceded by a full memory barrier) and ``rcu_watching_snap_stopped_since()``
|
||||||
(both of which rely on acquire semantics) to detect idle CPUs.
|
(both of which rely on acquire semantics) to detect idle CPUs.
|
||||||
|
|
||||||
+-----------------------------------------------------------------------+
|
+-----------------------------------------------------------------------+
|
||||||
|
|
|
@ -528,7 +528,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="-8652.5312"
|
y="-8652.5312"
|
||||||
x="2466.7822"
|
x="2466.7822"
|
||||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||||
<text
|
<text
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
|
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"
|
id="text202-7-2-7-2-0"
|
||||||
|
@ -537,7 +537,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="-8368.1475"
|
y="-8368.1475"
|
||||||
x="2463.3262"
|
x="2463.3262"
|
||||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||||
</g>
|
</g>
|
||||||
<g
|
<g
|
||||||
id="g4504"
|
id="g4504"
|
||||||
|
@ -607,7 +607,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-7-5-3-27-6"
|
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
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3745.7725"
|
x="3745.7725"
|
||||||
|
@ -638,7 +638,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-7-5-3-27-6-1"
|
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
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3745.7725"
|
x="3745.7725"
|
||||||
|
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
|
@ -844,7 +844,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="1547.8876"
|
y="1547.8876"
|
||||||
x="4417.6396"
|
x="4417.6396"
|
||||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(6501.9719,-10685.904)"
|
transform="translate(6501.9719,-10685.904)"
|
||||||
|
@ -899,7 +899,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="1858.8729"
|
y="1858.8729"
|
||||||
x="4414.1836"
|
x="4414.1836"
|
||||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="14659.87"
|
x="14659.87"
|
||||||
|
@ -977,7 +977,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-7-5-3-27-6"
|
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
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3745.7725"
|
x="3745.7725"
|
||||||
|
@ -1008,7 +1008,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-7-5-3-27-6-1"
|
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
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3745.7725"
|
x="3745.7725"
|
||||||
|
|
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
|
@ -2974,7 +2974,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="38114.047"
|
y="38114.047"
|
||||||
x="-334.33856"
|
x="-334.33856"
|
||||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||||
<g
|
<g
|
||||||
style="fill:none;stroke-width:0.025in"
|
style="fill:none;stroke-width:0.025in"
|
||||||
transform="translate(1749.9916,25880.249)"
|
transform="translate(1749.9916,25880.249)"
|
||||||
|
@ -3029,7 +3029,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="38425.035"
|
y="38425.035"
|
||||||
x="-337.79462"
|
x="-337.79462"
|
||||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||||
<text
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="9907.8887"
|
x="9907.8887"
|
||||||
|
@ -3107,7 +3107,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-7-5-3-27-6"
|
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
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3745.7725"
|
x="3745.7725"
|
||||||
|
@ -3138,7 +3138,7 @@
|
||||||
font-weight="bold"
|
font-weight="bold"
|
||||||
font-size="192"
|
font-size="192"
|
||||||
id="text202-7-5-3-27-6-1"
|
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
|
<text
|
||||||
xml:space="preserve"
|
xml:space="preserve"
|
||||||
x="3745.7725"
|
x="3745.7725"
|
||||||
|
|
Before Width: | Height: | Size: 208 KiB After Width: | Height: | Size: 208 KiB |
|
@ -516,7 +516,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="-8652.5312"
|
y="-8652.5312"
|
||||||
x="2466.7822"
|
x="2466.7822"
|
||||||
xml:space="preserve">dyntick_save_progress_counter()</text>
|
xml:space="preserve">rcu_watching_snap_save()</text>
|
||||||
<text
|
<text
|
||||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"
|
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"
|
id="text202-7-2-7-2-0"
|
||||||
|
@ -525,7 +525,7 @@
|
||||||
font-style="normal"
|
font-style="normal"
|
||||||
y="-8368.1475"
|
y="-8368.1475"
|
||||||
x="2463.3262"
|
x="2463.3262"
|
||||||
xml:space="preserve">rcu_implicit_dynticks_qs()</text>
|
xml:space="preserve">rcu_watching_snap_recheck()</text>
|
||||||
<text
|
<text
|
||||||
sodipodi:linespacing="125%"
|
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"
|
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.
|
be removed from the kernel.
|
||||||
|
|
||||||
The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
|
The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
|
||||||
consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
|
consisting solely of synchronize_rcu_tasks_rude().
|
||||||
and rcu_barrier_tasks_rude().
|
|
||||||
|
|
||||||
Tasks Trace RCU
|
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
|
when publicizing a pointer to a structure that can
|
||||||
be traversed by an RCU read-side critical section.
|
be traversed by an RCU read-side critical section.
|
||||||
|
|
||||||
5. If any of call_rcu(), call_srcu(), call_rcu_tasks(),
|
5. If any of call_rcu(), call_srcu(), call_rcu_tasks(), or
|
||||||
call_rcu_tasks_rude(), or call_rcu_tasks_trace() is used,
|
call_rcu_tasks_trace() is used, the callback function may be
|
||||||
the callback function may be invoked from softirq context,
|
invoked from softirq context, and in any case with bottom halves
|
||||||
and in any case with bottom halves disabled. In particular,
|
disabled. In particular, this callback function cannot block.
|
||||||
this callback function cannot block. If you need the callback
|
If you need the callback to block, run that code in a workqueue
|
||||||
to block, run that code in a workqueue handler scheduled from
|
handler scheduled from the callback. The queue_rcu_work()
|
||||||
the callback. The queue_rcu_work() function does this for you
|
function does this for you in the case of call_rcu().
|
||||||
in the case of call_rcu().
|
|
||||||
|
|
||||||
6. Since synchronize_rcu() can block, it cannot be called
|
6. Since synchronize_rcu() can block, it cannot be called
|
||||||
from any sort of irq context. The same rule applies
|
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()
|
corresponding readers must use rcu_read_lock_trace()
|
||||||
and rcu_read_unlock_trace().
|
and rcu_read_unlock_trace().
|
||||||
|
|
||||||
c. If an updater uses call_rcu_tasks_rude() or
|
c. If an updater uses synchronize_rcu_tasks_rude(),
|
||||||
synchronize_rcu_tasks_rude(), then the corresponding
|
then the corresponding readers must use anything that
|
||||||
readers must use anything that disables preemption,
|
disables preemption, for example, preempt_disable()
|
||||||
for example, preempt_disable() and preempt_enable().
|
and preempt_enable().
|
||||||
|
|
||||||
Mixing things up will result in confusion and broken kernels, and
|
Mixing things up will result in confusion and broken kernels, and
|
||||||
has even resulted in an exploitable security issue. Therefore,
|
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
|
d. Periodically invoke rcu_barrier(), permitting a limited
|
||||||
number of updates per grace period.
|
number of updates per grace period.
|
||||||
|
|
||||||
The same cautions apply to call_srcu(), call_rcu_tasks(),
|
The same cautions apply to call_srcu(), call_rcu_tasks(), and
|
||||||
call_rcu_tasks_rude(), and call_rcu_tasks_trace(). This is
|
call_rcu_tasks_trace(). This is why there is an srcu_barrier(),
|
||||||
why there is an srcu_barrier(), rcu_barrier_tasks(),
|
rcu_barrier_tasks(), and rcu_barrier_tasks_trace(), respectively.
|
||||||
rcu_barrier_tasks_rude(), and rcu_barrier_tasks_rude(),
|
|
||||||
respectively.
|
|
||||||
|
|
||||||
Note that although these primitives do take action to avoid
|
Note that although these primitives do take action to avoid
|
||||||
memory exhaustion when any given CPU has too many callbacks,
|
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
|
must use whatever locking or other synchronization is required
|
||||||
to safely access and/or modify that data structure.
|
to safely access and/or modify that data structure.
|
||||||
|
|
||||||
Do not assume that RCU callbacks will be executed on
|
Do not assume that RCU callbacks will be executed on the same
|
||||||
the same CPU that executed the corresponding call_rcu(),
|
CPU that executed the corresponding call_rcu(), call_srcu(),
|
||||||
call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or
|
call_rcu_tasks(), or call_rcu_tasks_trace(). For example, if
|
||||||
call_rcu_tasks_trace(). For example, if a given CPU goes offline
|
a given CPU goes offline while having an RCU callback pending,
|
||||||
while having an RCU callback pending, then that RCU callback
|
then that RCU callback will execute on some surviving CPU.
|
||||||
will execute on some surviving CPU. (If this was not the case,
|
(If this was not the case, a self-spawning RCU callback would
|
||||||
a self-spawning RCU callback would prevent the victim CPU from
|
prevent the victim CPU from ever going offline.) Furthermore,
|
||||||
ever going offline.) Furthermore, CPUs designated by rcu_nocbs=
|
CPUs designated by rcu_nocbs= might well *always* have their
|
||||||
might well *always* have their RCU callbacks executed on some
|
RCU callbacks executed on some other CPUs, in fact, for some
|
||||||
other CPUs, in fact, for some real-time workloads, this is the
|
real-time workloads, this is the whole point of using the
|
||||||
whole point of using the rcu_nocbs= kernel boot parameter.
|
rcu_nocbs= kernel boot parameter.
|
||||||
|
|
||||||
In addition, do not assume that callbacks queued in a given order
|
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
|
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
|
These debugging aids can help you find problems that are
|
||||||
otherwise extremely difficult to spot.
|
otherwise extremely difficult to spot.
|
||||||
|
|
||||||
17. If you pass a callback function defined within a module to one of
|
17. If you pass a callback function defined within a module
|
||||||
call_rcu(), call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(),
|
to one of call_rcu(), call_srcu(), call_rcu_tasks(), or
|
||||||
or call_rcu_tasks_trace(), then it is necessary to wait for all
|
call_rcu_tasks_trace(), then it is necessary to wait for all
|
||||||
pending callbacks to be invoked before unloading that module.
|
pending callbacks to be invoked before unloading that module.
|
||||||
Note that it is absolutely *not* sufficient to wait for a grace
|
Note that it is absolutely *not* sufficient to wait for a grace
|
||||||
period! For example, synchronize_rcu() implementation is *not*
|
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_rcu() -> rcu_barrier()
|
||||||
- call_srcu() -> srcu_barrier()
|
- call_srcu() -> srcu_barrier()
|
||||||
- call_rcu_tasks() -> rcu_barrier_tasks()
|
- call_rcu_tasks() -> rcu_barrier_tasks()
|
||||||
- call_rcu_tasks_rude() -> rcu_barrier_tasks_rude()
|
|
||||||
- call_rcu_tasks_trace() -> rcu_barrier_tasks_trace()
|
- call_rcu_tasks_trace() -> rcu_barrier_tasks_trace()
|
||||||
|
|
||||||
However, these barrier functions are absolutely *not* guaranteed
|
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(),
|
- Either synchronize_srcu() or synchronize_srcu_expedited(),
|
||||||
together with and srcu_barrier()
|
together with and srcu_barrier()
|
||||||
- synchronize_rcu_tasks() and rcu_barrier_tasks()
|
- synchronize_rcu_tasks() and rcu_barrier_tasks()
|
||||||
- synchronize_tasks_rude() and rcu_barrier_tasks_rude()
|
|
||||||
- synchronize_tasks_trace() and rcu_barrier_tasks_trace()
|
- synchronize_tasks_trace() and rcu_barrier_tasks_trace()
|
||||||
|
|
||||||
If necessary, you can use something like workqueues to execute
|
If necessary, you can use something like workqueues to execute
|
||||||
|
|
|
@ -1103,7 +1103,7 @@ RCU-Tasks-Rude::
|
||||||
|
|
||||||
Critical sections Grace period Barrier
|
Critical sections Grace period Barrier
|
||||||
|
|
||||||
N/A call_rcu_tasks_rude rcu_barrier_tasks_rude
|
N/A N/A
|
||||||
synchronize_rcu_tasks_rude
|
synchronize_rcu_tasks_rude
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -93,7 +93,7 @@ commands (does not impact QAIC).
|
||||||
uAPI
|
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.
|
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
|
The PCIe device may not be in the state to accept requests from userspace at
|
||||||
|
|
|
@ -47,3 +47,4 @@ subdirectories.
|
||||||
tomoyo
|
tomoyo
|
||||||
Yama
|
Yama
|
||||||
SafeSetID
|
SafeSetID
|
||||||
|
ipe
|
||||||
|
|
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
|
The text focuses on the gist of the process. If you are new to bisecting the
|
||||||
not confident in doing that please report the bug to your distribution vendor
|
kernel, better follow Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
|
||||||
instead of to a kernel developer.
|
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
|
Finding the change causing a kernel issue using a bisection
|
||||||
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.
|
|
||||||
|
|
||||||
Before you submit a bug report read
|
*Note: the following process assumes you prepared everything for a bisection.
|
||||||
'Documentation/admin-guide/reporting-issues.rst'.
|
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
|
git bisect start
|
||||||
on the kernel.
|
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
|
1. Copy your prepared .config into the build directory and adjust it to the
|
||||||
is reproducible.
|
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
|
2. Now build, install, and boot a kernel. This might fail for unrelated reasons,
|
||||||
- start bisect with [#f1]_::
|
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
|
Note, getting this wrong just once will send the rest of the bisection
|
||||||
- interact with git bisect by using either::
|
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
|
* Recommended complementary task: put the bisection log and the current .config
|
||||||
- After some interactions, git bisect will give you the changeset that
|
file aside for the bug report; furthermore tell Git to reset the sources to
|
||||||
likely caused the bug.
|
the state before the bisection::
|
||||||
|
|
||||||
- For example, if you know that the current version is bad, and version
|
git bisect log > ~/bisection-log
|
||||||
4.8 is good, you could do::
|
cp .config ~/bisection-config-culprit
|
||||||
|
git bisect reset
|
||||||
|
|
||||||
$ git bisect start
|
* Recommended optional task: try reverting the culprit on top of the latest
|
||||||
$ git bisect bad # Current version is bad
|
codebase and check if that fixes your bug; if that is the case, it validates
|
||||||
$ git bisect good v4.8
|
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
|
Additional reading material
|
||||||
start with ``git bisect start [BAD] [GOOD]``
|
---------------------------
|
||||||
|
|
||||||
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>`_
|
end-of-content
|
||||||
- `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>`_
|
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,
|
Once you find where the bug happened, by inspecting its location,
|
||||||
you could either try to fix it yourself or report it upstream.
|
you could either try to fix it yourself or report it upstream.
|
||||||
|
|
||||||
In order to report it upstream, you should identify the mailing list
|
In order to report it upstream, you should identify the bug tracker, if any, or
|
||||||
used for the development of the affected code. This can be done by using
|
mailing list used for the development of the affected code. This can be done by
|
||||||
the ``get_maintainer.pl`` script.
|
using the ``get_maintainer.pl`` script.
|
||||||
|
|
||||||
For example, if you find a bug at the gspca's sonixj.c file, you can get
|
For example, if you find a bug at the gspca's sonixj.c file, you can get
|
||||||
its maintainers with::
|
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%)
|
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%)
|
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%)
|
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 driver maintainer (Hans Verkuil);
|
||||||
- The subsystem maintainer (Mauro Carvalho Chehab);
|
- The subsystem maintainer (Mauro Carvalho Chehab);
|
||||||
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
|
- 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
|
If the listing contains bug reporting URIs at the end, please prefer them over
|
||||||
list used for the development of the code (linux-media ML) copying the
|
email. Otherwise, please report bugs to the mailing list used for the
|
||||||
driver maintainer (Hans).
|
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
|
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
|
``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
|
Because the resource control interface files in a given directory
|
||||||
control the distribution of the parent's resources, the delegatee
|
control the distribution of the parent's resources, the delegatee
|
||||||
shouldn't be allowed to write to them. For the first method, this is
|
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
|
achieved by not granting access to these files. For the second, files
|
||||||
kernel rejects writes to all files other than "cgroup.procs" and
|
outside the namespace should be hidden from the delegatee by the means
|
||||||
"cgroup.subtree_control" on a namespace root from inside the
|
of at least mount namespacing, and the kernel rejects writes to all
|
||||||
namespace.
|
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
|
The end results are equivalent for both delegation types. Once
|
||||||
delegated, the user can build sub-hierarchy under the directory,
|
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
|
A dying cgroup can consume system resources not exceeding
|
||||||
limits, which were active at the moment of cgroup deletion.
|
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
|
cgroup.freeze
|
||||||
A read-write single value file which exists on non-root cgroups.
|
A read-write single value file which exists on non-root cgroups.
|
||||||
Allowed values are "0" and "1". The default is "0".
|
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.
|
entries fault back in or are written out to disk.
|
||||||
|
|
||||||
memory.zswap.writeback
|
memory.zswap.writeback
|
||||||
A read-write single value file. The default value is "1". The
|
A read-write single value file. The default value is "1".
|
||||||
initial value of the root cgroup is 1, and when a new cgroup is
|
Note that this setting is hierarchical, i.e. the writeback would be
|
||||||
created, it inherits the current value of its parent.
|
implicitly disabled for child cgroups if the upper hierarchy
|
||||||
|
does so.
|
||||||
|
|
||||||
When this is set to 0, all swapping attempts to swapping devices
|
When this is set to 0, all swapping attempts to swapping devices
|
||||||
are disabled. This included both zswap writebacks, and swapping due
|
are disabled. This included both zswap writebacks, and swapping due
|
||||||
|
@ -2939,8 +2950,8 @@ Deprecated v1 Core Features
|
||||||
|
|
||||||
- "cgroup.clone_children" is removed.
|
- "cgroup.clone_children" is removed.
|
||||||
|
|
||||||
- /proc/cgroups is meaningless for v2. Use "cgroup.controllers" file
|
- /proc/cgroups is meaningless for v2. Use "cgroup.controllers" or
|
||||||
at the root instead.
|
"cgroup.stat" files at the root instead.
|
||||||
|
|
||||||
|
|
||||||
Issues with v1 and Rationales for v2
|
Issues with v1 and Rationales for v2
|
||||||
|
|
|
@ -162,13 +162,18 @@ iv_large_sectors
|
||||||
|
|
||||||
|
|
||||||
Module parameters::
|
Module parameters::
|
||||||
|
|
||||||
max_read_size
|
max_read_size
|
||||||
max_write_size
|
Maximum size of read requests. When a request larger than this size
|
||||||
Maximum size of read or write requests. When a request larger than this size
|
|
||||||
is received, dm-crypt will split the request. The splitting improves
|
is received, dm-crypt will split the request. The splitting improves
|
||||||
concurrency (the split requests could be encrypted in parallel by multiple
|
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.
|
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
|
In older Zen1 and Zen2, this is accomplished using a reinterpretation
|
||||||
technique similar to Retbleed one: srso_untrain_ret() and
|
technique similar to Retbleed one: srso_untrain_ret() and
|
||||||
srso_safe_ret().
|
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
|
allowed anymore to lift isolation
|
||||||
requirements as needed. This option
|
requirements as needed. This option
|
||||||
does not override iommu=pt
|
does not override iommu=pt
|
||||||
force_enable - Force enable the IOMMU on platforms known
|
force_enable - Force enable the IOMMU on platforms known
|
||||||
to be buggy with IOMMU enabled. Use this
|
to be buggy with IOMMU enabled. Use this
|
||||||
option with care.
|
option with care.
|
||||||
pgtbl_v1 - Use v1 page table for DMA-API (Default).
|
pgtbl_v1 - Use v1 page table for DMA-API (Default).
|
||||||
pgtbl_v2 - Use v2 page table for DMA-API.
|
pgtbl_v2 - Use v2 page table for DMA-API.
|
||||||
irtcachedis - Disable Interrupt Remapping Table (IRT) caching.
|
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]
|
amd_iommu_dump= [HW,X86-64]
|
||||||
Enable AMD IOMMU driver option to dump the ACPI table
|
Enable AMD IOMMU driver option to dump the ACPI table
|
||||||
|
@ -517,6 +522,18 @@
|
||||||
Format: <io>,<irq>,<mode>
|
Format: <io>,<irq>,<mode>
|
||||||
See header of drivers/net/hamradio/baycom_ser_hdx.c.
|
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]
|
bert_disable [ACPI]
|
||||||
Disable BERT OS support on buggy BIOSes.
|
Disable BERT OS support on buggy BIOSes.
|
||||||
|
|
||||||
|
@ -2350,6 +2367,18 @@
|
||||||
ipcmni_extend [KNL,EARLY] Extend the maximum number of unique System V
|
ipcmni_extend [KNL,EARLY] Extend the maximum number of unique System V
|
||||||
IPC identifiers from 32,768 to 16,777,216.
|
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
|
irqaffinity= [SMP] Set the default irq affinity mask
|
||||||
The argument is a cpu list, as described above.
|
The argument is a cpu list, as described above.
|
||||||
|
|
||||||
|
@ -4788,6 +4817,16 @@
|
||||||
printk.time= Show timing data prefixed to each printk message line
|
printk.time= Show timing data prefixed to each printk message line
|
||||||
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
|
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]
|
processor.max_cstate= [HW,ACPI]
|
||||||
Limit processor to maximum C-state
|
Limit processor to maximum C-state
|
||||||
max_cstate=9 overrides any DMI blacklist limit.
|
max_cstate=9 overrides any DMI blacklist limit.
|
||||||
|
@ -4935,6 +4974,10 @@
|
||||||
Set maximum number of finished RCU callbacks to
|
Set maximum number of finished RCU callbacks to
|
||||||
process in one batch.
|
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]
|
rcutree.do_rcu_barrier= [KNL]
|
||||||
Request a call to rcu_barrier(). This is
|
Request a call to rcu_barrier(). This is
|
||||||
throttled so that userspace tests can safely
|
throttled so that userspace tests can safely
|
||||||
|
@ -5382,7 +5425,13 @@
|
||||||
Time to wait (s) after boot before inducing stall.
|
Time to wait (s) after boot before inducing stall.
|
||||||
|
|
||||||
rcutorture.stall_cpu_irqsoff= [KNL]
|
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]
|
rcutorture.stall_gp_kthread= [KNL]
|
||||||
Duration (s) of forced sleep within RCU
|
Duration (s) of forced sleep within RCU
|
||||||
|
@ -5570,14 +5619,6 @@
|
||||||
of zero will disable batching. Batching is
|
of zero will disable batching. Batching is
|
||||||
always disabled for synchronize_rcu_tasks().
|
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]
|
rcupdate.rcu_tasks_trace_lazy_ms= [KNL]
|
||||||
Set timeout in milliseconds RCU Tasks
|
Set timeout in milliseconds RCU Tasks
|
||||||
Trace asynchronous callback batching for
|
Trace asynchronous callback batching for
|
||||||
|
@ -7352,6 +7393,13 @@
|
||||||
it can be updated at runtime by writing to the
|
it can be updated at runtime by writing to the
|
||||||
corresponding sysfs file.
|
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=
|
workqueue.cpu_intensive_thresh_us=
|
||||||
Per-cpu work items which run for longer than this
|
Per-cpu work items which run for longer than this
|
||||||
threshold are automatically considered CPU intensive
|
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.
|
detail below.
|
||||||
|
|
||||||
Special attention has been given to the rate at which new frames become
|
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),
|
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
|
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
|
framerate of 59.94 Hz is really different from 60 Hz. If the framerate
|
||||||
|
|
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
|
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,
|
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
|
The DWC PCIe PMU driver registers a perf PMU driver, which provides
|
||||||
description of available events and configuration options in sysfs, see
|
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
|
The "format" directory describes format of the config fields of the
|
||||||
perf_event_attr structure. The "events" directory provides configuration
|
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
|
$# 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
|
Time Based Analysis Event Usage
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
Example usage of counting PCIe RX TLP data payload (Units of bytes)::
|
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:
|
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
|
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.::
|
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
|
The driver does not support sampling, therefore "perf record" will not
|
||||||
work. Per-task (without "-a") perf sessions are not supported.
|
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.
|
PMU hardware device.
|
||||||
|
|
||||||
The "bus" sysfs file allows users to get the bus number of Root Ports
|
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::
|
Example usage of perf::
|
||||||
|
|
||||||
|
|
|
@ -16,6 +16,7 @@ Performance monitor support
|
||||||
starfive_starlink_pmu
|
starfive_starlink_pmu
|
||||||
arm-ccn
|
arm-ccn
|
||||||
arm-cmn
|
arm-cmn
|
||||||
|
arm-ni
|
||||||
xgene-pmu
|
xgene-pmu
|
||||||
arm_dsu_pmu
|
arm_dsu_pmu
|
||||||
thunderx2-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``
|
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
|
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
|
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.
|
This attribute is read-only.
|
||||||
|
|
||||||
``amd_pstate_lowest_nonlinear_freq``
|
``amd_pstate_lowest_nonlinear_freq``
|
||||||
|
@ -262,6 +264,17 @@ lowest non-linear performance in `AMD CPPC Performance Capability
|
||||||
<perf_cap_>`_.)
|
<perf_cap_>`_.)
|
||||||
This attribute is read-only.
|
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``
|
``energy_performance_available_preferences``
|
||||||
|
|
||||||
A list of all the supported EPP preferences that could be used for
|
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
|
Support for "current_freq_khz" is available only at each fabric cluster
|
||||||
level (i.e., in uncore* directory).
|
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
|
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.
|
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
|
You can specify either RAM memory or peripheral devices' memory. However, when
|
||||||
specifying RAM, be sure to reserve the memory by issuing memblock_reserve()
|
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
|
produce extremely unusual kernel structure layouts (even performance
|
||||||
pathological ones), which is important to know when debugging. Set at
|
pathological ones), which is important to know when debugging. Set at
|
||||||
build time.
|
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
|
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()).
|
(dmaengine_prep_slave_sg()) or the period (dmaengine_prep_dma_cyclic()).
|
||||||
Depending on the direction, set the callback on the descriptor that finishes
|
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_DEV_TO_MEM: set the callback on the "MDMA" descriptor
|
||||||
* DMA_MEM_TO_DEV: set the callback on the "DMA" 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
|
As STM32 MDMA channel transfer is triggered by STM32 DMA, you must issue
|
||||||
STM32 MDMA channel before STM32 DMA channel.
|
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.
|
transfer or the period completion.
|
||||||
|
|
||||||
Don't forget to terminate both channels. STM32 DMA channel is configured in
|
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
|
while the system is running, and ACPI is not able to sufficiently describe
|
||||||
them.
|
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
|
described in a static table, the PPTT. How caches are shared between CPUs is
|
||||||
not discoverable, and must be described by firmware.
|
not discoverable, and must be described by firmware.
|
||||||
|
|
||||||
|
|
|
@ -365,6 +365,8 @@ HWCAP2_SME_SF8DP2
|
||||||
HWCAP2_SME_SF8DP4
|
HWCAP2_SME_SF8DP4
|
||||||
Functionality implied by ID_AA64SMFR0_EL1.SF8DP4 == 0b1.
|
Functionality implied by ID_AA64SMFR0_EL1.SF8DP4 == 0b1.
|
||||||
|
|
||||||
|
HWCAP2_POE
|
||||||
|
Functionality implied by ID_AA64MMFR3_EL1.S1POE == 0b0001.
|
||||||
|
|
||||||
4. Unused AT_HWCAP bits
|
4. Unused AT_HWCAP bits
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
|
@ -55,6 +55,8 @@ stable kernels.
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
|
| 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 |
|
| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
|
@ -249,8 +251,8 @@ stable kernels.
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
|
| Hisilicon | Hip08 SMMU PMCG | #162001800 | N/A |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| Hisilicon | Hip08 SMMU PMCG | #162001900 | N/A |
|
| Hisilicon | Hip{08,09,10,10C| #162001900 | N/A |
|
||||||
| | Hip09 SMMU PMCG | | |
|
| | ,11} SMMU PMCG | | |
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
+----------------+-----------------+-----------------+-----------------------------+
|
+----------------+-----------------+-----------------+-----------------------------+
|
||||||
| Qualcomm Tech. | Kryo/Falkor v1 | E1003 | QCOM_FALKOR_ERRATUM_1003 |
|
| 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
|
* PTCR and partition table entries (partition table is in secure
|
||||||
memory). An attempt to write to PTCR will cause a Hypervisor
|
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)
|
* LDBAR (LD Base Address Register) and IMC (In-Memory Collection)
|
||||||
non-architected registers. An attempt to write to them will cause a
|
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
|
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
|
for processes running under its domain. Calling these interfaces is not
|
||||||
recommended in libraries routines because libraries should not override policies
|
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
|
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,
|
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
|
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
|
ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF
|
||||||
ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel
|
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
|
3. It would take a large number of these precisely-timed NMIs to mount
|
||||||
an actual attack. There's presumably not enough bandwidth.
|
an actual attack. There's presumably not enough bandwidth.
|
||||||
4. The NMI in question occurs after a VERW, i.e. when user state is
|
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
|
is only the data that NMI touches, and that may or may not be of
|
||||||
any interest.
|
any interest.
|
||||||
|
|
||||||
|
|
|
@ -125,7 +125,7 @@ FSGSBASE instructions enablement
|
||||||
FSGSBASE instructions compiler support
|
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.
|
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
|
_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.
|
code and the compiler option -mfsgsbase has to be added.
|
||||||
|
|
||||||
Compiler support for FS/GS based addressing
|
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
|
- BFQ guarantees a high system and application responsiveness, and a
|
||||||
low latency for time-sensitive applications, such as audio or video
|
low latency for time-sensitive applications, such as audio or video
|
||||||
players;
|
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
|
groups (switching back to time distribution when needed to keep
|
||||||
throughput high).
|
throughput high).
|
||||||
|
|
||||||
|
@ -111,7 +111,7 @@ Higher speed for code-development tasks
|
||||||
|
|
||||||
If some additional workload happens to be executed in parallel, then
|
If some additional workload happens to be executed in parallel, then
|
||||||
BFQ executes the I/O-related components of typical code-development
|
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.
|
NOOP or DEADLINE.
|
||||||
|
|
||||||
High throughput
|
High throughput
|
||||||
|
@ -127,9 +127,9 @@ Strong fairness, bandwidth and delay guarantees
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
BFQ distributes the device throughput, and not just the device time,
|
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
|
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 by a simple formula. If not configured for strict service
|
||||||
guarantees, BFQ switches to time-based resource sharing (only) for
|
guarantees, BFQ switches to time-based resource sharing (only) for
|
||||||
applications that would otherwise cause a throughput loss.
|
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
|
- On flash-based storage with internal queueing of commands
|
||||||
(typically NCQ), device idling happens to be always detrimental
|
(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
|
only when strictly needed for service guarantees, i.e., for
|
||||||
guaranteeing low latency or fairness. In these cases, overall
|
guaranteeing low latency or fairness. In these cases, overall
|
||||||
throughput may be sub-optimal. No solution currently exists to
|
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
|
and to reduce their latency. The most important action taken to
|
||||||
achieve this goal is to give to the queues associated with these
|
achieve this goal is to give to the queues associated with these
|
||||||
applications more than their fair share of the device
|
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
|
sets of actions taken by BFQ to privilege these queues. In
|
||||||
particular, BFQ provides a milder form of weight-raising for
|
particular, BFQ provides a milder form of weight-raising for
|
||||||
interactive applications, and a stronger form for soft real-time
|
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),
|
responsive in detecting interleaved I/O (cooperating processes),
|
||||||
that it enables BFQ to achieve a high throughput, by queue
|
that it enables BFQ to achieve a high throughput, by queue
|
||||||
merging, even for queues for which CFQ needs a different
|
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
|
unified mechanism to achieve a high throughput with interleaved
|
||||||
I/O.
|
I/O.
|
||||||
|
|
||||||
|
@ -254,7 +254,7 @@ plus a lot of code, are borrowed from CFQ.
|
||||||
- First, with any proportional-share scheduler, the maximum
|
- First, with any proportional-share scheduler, the maximum
|
||||||
deviation with respect to an ideal service is proportional to
|
deviation with respect to an ideal service is proportional to
|
||||||
the maximum budget (slice) assigned to queues. As a consequence,
|
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*
|
accurate service of B-WF2Q+, but also because BFQ *does not*
|
||||||
need to assign a larger budget to a queue to let the queue
|
need to assign a larger budget to a queue to let the queue
|
||||||
receive a higher fraction of the device throughput.
|
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
|
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
|
request, when certain sync BFQ queues become empty. By default
|
||||||
slice_idle is a non-zero value. Idling has a double purpose: boosting
|
slice_idle is a non-zero value. Idling has a double purpose: boosting
|
||||||
throughput and making sure that the desired throughput distribution is
|
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
|
order then corresponds to the dispatch order, the strict_guarantees
|
||||||
tunable must be set too.
|
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
|
where it is beneficial also for throughput, idling can severely impact
|
||||||
throughput. One important case is random workload. Because of this
|
throughput. One important case is random workload. Because of this
|
||||||
issue, BFQ tends to avoid idling as much as possible, when it is not
|
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
|
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
|
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 algorithm, larger values increase the throughput in proportion to
|
||||||
the percentage of sequential I/O requests issued. The price of larger
|
the percentage of sequential I/O requests issued. The price of larger
|
||||||
values is that they coarsen the granularity of short-term bandwidth
|
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_t
|
||||||
wrappers/atomic_bitops
|
wrappers/atomic_bitops
|
||||||
floating-point
|
floating-point
|
||||||
|
union_find
|
||||||
|
|
||||||
Low level entry and exit
|
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
|
* If the allocation is performed from an atomic context, e.g interrupt
|
||||||
handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and
|
handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and
|
||||||
IO or filesystem operations. Consequently, under memory pressure
|
IO or filesystem operations. Consequently, under memory pressure
|
||||||
``GFP_NOWAIT`` allocation is likely to fail. Allocations which
|
``GFP_NOWAIT`` allocation is likely to fail. Users of this flag need
|
||||||
have a reasonable fallback should be using ``GFP_NOWARN``.
|
to provide a suitable fallback to cope with such failures where
|
||||||
|
appropriate.
|
||||||
* If you think that accessing memory reserves is justified and the kernel
|
* If you think that accessing memory reserves is justified and the kernel
|
||||||
will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``.
|
will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``.
|
||||||
* Untrusted allocations triggered from userspace should be a subject
|
* Untrusted allocations triggered from userspace should be a subject
|
||||||
|
|
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.
|
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
|
Files
|
||||||
-----
|
-----
|
||||||
|
|
||||||
|
|
|
@ -361,7 +361,8 @@ Alternatives Considered
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
An alternative data race detection approach for the kernel can be found in the
|
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
|
KTSAN is a happens-before data race detector, which explicitly establishes the
|
||||||
happens-before order between memory operations, which can then be used to
|
happens-before order between memory operations, which can then be used to
|
||||||
determine data races as defined in `Data Races`_.
|
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
|
Test File and Module Names
|
||||||
==========================
|
==========================
|
||||||
|
|
||||||
KUnit tests can often be compiled as a module. These modules should be named
|
KUnit tests are often compiled as a separate module. To avoid conflicting
|
||||||
after the test suite, followed by ``_test``. If this is likely to conflict with
|
with regular modules, KUnit modules should be named after the test suite,
|
||||||
non-KUnit tests, the suffix ``_kunit`` can also be used.
|
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
|
Test source files, whether compiled as a separate module or an
|
||||||
``<suite>_test.c`` (or, as above, ``<suite>_kunit.c``). This file should be
|
``#include`` in another source file, are best kept in a ``tests/``
|
||||||
placed next to the code under test.
|
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
|
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.
|
directory, it may make sense to modify the source filename to reduce
|
||||||
For example, a ``foo_firmware`` suite could be in the ``foo/firmware_test.c``
|
redundancy. For example, a ``foo_firmware`` suite could be in the
|
||||||
file.
|
``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
|
@ -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:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
items:
|
oneOf:
|
||||||
- const: amlogic,meson-gx-ao-secure
|
- items:
|
||||||
- const: syscon
|
- 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:
|
reg:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
|
|
|
@ -17,7 +17,7 @@ description: |
|
||||||
The Coresight dummy source component is for the specific coresight source
|
The Coresight dummy source component is for the specific coresight source
|
||||||
devices kernel don't have permission to access or configure. For some SOCs,
|
devices kernel don't have permission to access or configure. For some SOCs,
|
||||||
there would be Coresight source trace components on sub-processor which
|
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
|
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
|
created in the driver. It provides Coresight API for operations on dummy
|
||||||
source devices, such as enabling and disabling them. It also provides the
|
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
|
title: ARM Corstone1000
|
||||||
|
|
||||||
maintainers:
|
maintainers:
|
||||||
- Vishnu Banavath <vishnu.banavath@arm.com>
|
- Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
|
||||||
- Rui Miguel Silva <rui.silva@linaro.org>
|
- Hugues Kamba Mpiana <hugues.kambampiana@arm.com>
|
||||||
|
|
||||||
description: |+
|
description: |+
|
||||||
ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
|
ARM's Corstone1000 includes pre-verified Corstone SSE-710 subsystem that
|
||||||
|
|
|
@ -79,6 +79,7 @@ properties:
|
||||||
- aspeed,ast2600-evb-a1
|
- aspeed,ast2600-evb-a1
|
||||||
- asus,x4tf-bmc
|
- asus,x4tf-bmc
|
||||||
- facebook,bletchley-bmc
|
- facebook,bletchley-bmc
|
||||||
|
- facebook,catalina-bmc
|
||||||
- facebook,cloudripper-bmc
|
- facebook,cloudripper-bmc
|
||||||
- facebook,elbert-bmc
|
- facebook,elbert-bmc
|
||||||
- facebook,fuji-bmc
|
- facebook,fuji-bmc
|
||||||
|
@ -86,7 +87,9 @@ properties:
|
||||||
- facebook,harma-bmc
|
- facebook,harma-bmc
|
||||||
- facebook,minerva-cmc
|
- facebook,minerva-cmc
|
||||||
- facebook,yosemite4-bmc
|
- facebook,yosemite4-bmc
|
||||||
|
- ibm,blueridge-bmc
|
||||||
- ibm,everest-bmc
|
- ibm,everest-bmc
|
||||||
|
- ibm,fuji-bmc
|
||||||
- ibm,rainier-bmc
|
- ibm,rainier-bmc
|
||||||
- ibm,system1-bmc
|
- ibm,system1-bmc
|
||||||
- ibm,tacoma-bmc
|
- ibm,tacoma-bmc
|
||||||
|
|
|
@ -11,7 +11,8 @@ PIT Timer required properties:
|
||||||
shared across all System Controller members.
|
shared across all System Controller members.
|
||||||
|
|
||||||
PIT64B Timer required properties:
|
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
|
- reg: Should contain registers location and length
|
||||||
- interrupts: Should contain interrupt for PIT64B timer
|
- interrupts: Should contain interrupt for PIT64B timer
|
||||||
- clocks: Should contain the available clock sources 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,at91sam9g45-ddramc",
|
||||||
"atmel,sama5d3-ddramc",
|
"atmel,sama5d3-ddramc",
|
||||||
"microchip,sam9x60-ddramc",
|
"microchip,sam9x60-ddramc",
|
||||||
"microchip,sama7g5-uddrc"
|
"microchip,sama7g5-uddrc",
|
||||||
|
"microchip,sam9x7-ddramc", "atmel,sama5d3-ddramc".
|
||||||
- reg: Should contain registers location and length
|
- reg: Should contain registers location and length
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
|
@ -809,19 +809,19 @@ properties:
|
||||||
- const: kontron,sl-imx6ull # Kontron SL i.MX6ULL SoM
|
- const: kontron,sl-imx6ull # Kontron SL i.MX6ULL SoM
|
||||||
- const: fsl,imx6ull
|
- const: fsl,imx6ull
|
||||||
|
|
||||||
- description: TQ Systems TQMa6ULLx SoM on MBa6ULx board
|
- description: TQ-Systems TQMa6ULLx SoM on MBa6ULx board
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
- tq,imx6ull-tqma6ull2-mba6ulx
|
- tq,imx6ull-tqma6ull2-mba6ulx # TQMa6ULL socketable SoM with MCIMX6Y2 on MBa6ULx EVK
|
||||||
- const: tq,imx6ull-tqma6ull2 # MCIMX6Y2
|
- const: tq,imx6ull-tqma6ull2 # TQMa6ULL socketable SoM with MCIMX6Y2
|
||||||
- const: fsl,imx6ull
|
- const: fsl,imx6ull
|
||||||
|
|
||||||
- description: TQ Systems TQMa6ULLxL SoM on MBa6ULx[L] board
|
- description: TQ-Systems TQMa6ULLxL SoM on MBa6ULx[L] board
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
- tq,imx6ull-tqma6ull2l-mba6ulx # using LGA adapter
|
- tq,imx6ull-tqma6ull2l-mba6ulx # TQMa6ULLxL LGA SoM with socketable Adapter on MBa6ULx EVK
|
||||||
- tq,imx6ull-tqma6ull2l-mba6ulxl
|
- tq,imx6ull-tqma6ull2l-mba6ulxl # TQMa6ULLxL LGA SoM on MBa6ULxL gateway board
|
||||||
- const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant
|
- const: tq,imx6ull-tqma6ull2l # TQMa6ULLxL LGA SoM with MCIMX6Y2
|
||||||
- const: fsl,imx6ull
|
- const: fsl,imx6ull
|
||||||
|
|
||||||
- description: Seeed Stuido i.MX6ULL SoM on dev boards
|
- 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-ddr4-evk # i.MX8MM DDR4 EVK Board
|
||||||
- fsl,imx8mm-evk # i.MX8MM EVK Board
|
- fsl,imx8mm-evk # i.MX8MM EVK Board
|
||||||
- fsl,imx8mm-evkb # i.MX8MM EVKB Board
|
- fsl,imx8mm-evkb # i.MX8MM EVKB Board
|
||||||
|
- gateworks,imx8mm-gw75xx-0x # i.MX8MM Gateworks Board
|
||||||
- gateworks,imx8mm-gw7904
|
- gateworks,imx8mm-gw7904
|
||||||
- gateworks,imx8mm-gw7905-0x # i.MX8MM Gateworks Board
|
|
||||||
- gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit
|
- gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit
|
||||||
- gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit
|
- gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit
|
||||||
- gw,imx8mm-gw73xx-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 # Verdin iMX8M Mini Modules
|
||||||
- toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT
|
- toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT
|
||||||
- toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules
|
- 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
|
- prt,prt8mm # i.MX8MM Protonic PRT8MM Board
|
||||||
- const: fsl,imx8mm
|
- const: fsl,imx8mm
|
||||||
|
|
||||||
|
@ -1082,7 +1081,7 @@ properties:
|
||||||
- gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
|
- gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
|
||||||
- gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board
|
- gateworks,imx8mp-gw73xx-2x # i.MX8MP Gateworks Board
|
||||||
- gateworks,imx8mp-gw74xx # 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-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-lt6 # SKOV i.MX8MP climate control with 7” panel
|
||||||
- skov,imx8mp-skov-revb-mi1010ait-1cp1 # SKOV i.MX8MP climate control with 10.1" 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: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
|
||||||
- const: fsl,imx8mp
|
- 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
|
- description: i.MX8MQ based Boards
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
|
@ -1293,6 +1298,7 @@ properties:
|
||||||
- enum:
|
- enum:
|
||||||
- fsl,imx93-9x9-qsb # i.MX93 9x9 QSB Board
|
- fsl,imx93-9x9-qsb # i.MX93 9x9 QSB Board
|
||||||
- fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board
|
- fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board
|
||||||
|
- fsl,imx93-14x14-evk # i.MX93 14x14 EVK Board
|
||||||
- const: fsl,imx93
|
- const: fsl,imx93
|
||||||
|
|
||||||
- description: i.MX95 based Boards
|
- description: i.MX95 based Boards
|
||||||
|
@ -1344,6 +1350,12 @@ properties:
|
||||||
- const: variscite,var-som-mx93
|
- const: variscite,var-som-mx93
|
||||||
- const: fsl,imx93
|
- 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:
|
- description:
|
||||||
Freescale Vybrid Platform Device Tree Bindings
|
Freescale Vybrid Platform Device Tree Bindings
|
||||||
|
|
||||||
|
@ -1523,6 +1535,12 @@ properties:
|
||||||
- fsl,ls2080a-rdb
|
- fsl,ls2080a-rdb
|
||||||
- const: fsl,ls2080a
|
- const: fsl,ls2080a
|
||||||
|
|
||||||
|
- description: LS2081A based Boards
|
||||||
|
items:
|
||||||
|
- enum:
|
||||||
|
- fsl,ls2081a-rdb
|
||||||
|
- const: fsl,ls2081a
|
||||||
|
|
||||||
- description: LS2088A based Boards
|
- description: LS2088A based Boards
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
|
|
|
@ -155,6 +155,11 @@ properties:
|
||||||
- const: qcom,msm8926
|
- const: qcom,msm8926
|
||||||
- const: qcom,msm8226
|
- const: qcom,msm8226
|
||||||
|
|
||||||
|
- items:
|
||||||
|
- enum:
|
||||||
|
- wingtech,wt82918hd
|
||||||
|
- const: qcom,msm8929
|
||||||
|
|
||||||
- items:
|
- items:
|
||||||
- enum:
|
- enum:
|
||||||
- huawei,kiwi
|
- huawei,kiwi
|
||||||
|
@ -162,6 +167,8 @@ properties:
|
||||||
- samsung,a7
|
- samsung,a7
|
||||||
- sony,kanuti-tulip
|
- sony,kanuti-tulip
|
||||||
- square,apq8039-t2
|
- square,apq8039-t2
|
||||||
|
- wingtech,wt82918
|
||||||
|
- wingtech,wt82918hdhw39
|
||||||
- const: qcom,msm8939
|
- const: qcom,msm8939
|
||||||
|
|
||||||
- items:
|
- items:
|
||||||
|
@ -228,12 +235,15 @@ properties:
|
||||||
- samsung,grandprimelte
|
- samsung,grandprimelte
|
||||||
- samsung,gt510
|
- samsung,gt510
|
||||||
- samsung,gt58
|
- samsung,gt58
|
||||||
|
- samsung,j3ltetw
|
||||||
- samsung,j5
|
- samsung,j5
|
||||||
- samsung,j5x
|
- samsung,j5x
|
||||||
- samsung,rossa
|
- samsung,rossa
|
||||||
- samsung,serranove
|
- samsung,serranove
|
||||||
- thwc,uf896
|
- thwc,uf896
|
||||||
- thwc,ufi001c
|
- thwc,ufi001c
|
||||||
|
- wingtech,wt86518
|
||||||
|
- wingtech,wt86528
|
||||||
- wingtech,wt88047
|
- wingtech,wt88047
|
||||||
- yiming,uz801-v3
|
- yiming,uz801-v3
|
||||||
- const: qcom,msm8916
|
- const: qcom,msm8916
|
||||||
|
@ -250,6 +260,7 @@ properties:
|
||||||
- items:
|
- items:
|
||||||
- enum:
|
- enum:
|
||||||
- lg,bullhead
|
- lg,bullhead
|
||||||
|
- lg,h815
|
||||||
- microsoft,talkman
|
- microsoft,talkman
|
||||||
- xiaomi,libra
|
- xiaomi,libra
|
||||||
- const: qcom,msm8992
|
- const: qcom,msm8992
|
||||||
|
@ -1038,10 +1049,18 @@ properties:
|
||||||
- qcom,sm8650-qrd
|
- qcom,sm8650-qrd
|
||||||
- const: qcom,sm8650
|
- const: qcom,sm8650
|
||||||
|
|
||||||
|
- items:
|
||||||
|
- enum:
|
||||||
|
- lenovo,thinkpad-t14s
|
||||||
|
- const: qcom,x1e78100
|
||||||
|
- const: qcom,x1e80100
|
||||||
|
|
||||||
- items:
|
- items:
|
||||||
- enum:
|
- enum:
|
||||||
- asus,vivobook-s15
|
- asus,vivobook-s15
|
||||||
- lenovo,yoga-slim7x
|
- lenovo,yoga-slim7x
|
||||||
|
- microsoft,romulus13
|
||||||
|
- microsoft,romulus15
|
||||||
- qcom,x1e80100-crd
|
- qcom,x1e80100-crd
|
||||||
- qcom,x1e80100-qcp
|
- qcom,x1e80100-qcp
|
||||||
- const: qcom,x1e80100
|
- const: qcom,x1e80100
|
||||||
|
|
|
@ -96,6 +96,13 @@ properties:
|
||||||
- const: coolpi,pi-cm5
|
- const: coolpi,pi-cm5
|
||||||
- const: rockchip,rk3588
|
- 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
|
- description: Cool Pi 4 Model B
|
||||||
items:
|
items:
|
||||||
- const: coolpi,pi-4b
|
- const: coolpi,pi-4b
|
||||||
|
@ -148,6 +155,12 @@ properties:
|
||||||
- const: engicam,px30-core
|
- const: engicam,px30-core
|
||||||
- const: rockchip,px30
|
- 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
|
- description: Firefly Firefly-RK3288
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
|
@ -216,6 +229,7 @@ properties:
|
||||||
- friendlyarm,nanopi-r2c
|
- friendlyarm,nanopi-r2c
|
||||||
- friendlyarm,nanopi-r2c-plus
|
- friendlyarm,nanopi-r2c-plus
|
||||||
- friendlyarm,nanopi-r2s
|
- friendlyarm,nanopi-r2s
|
||||||
|
- friendlyarm,nanopi-r2s-plus
|
||||||
- const: rockchip,rk3328
|
- const: rockchip,rk3328
|
||||||
|
|
||||||
- description: FriendlyElec NanoPi4 series boards
|
- description: FriendlyElec NanoPi4 series boards
|
||||||
|
@ -243,9 +257,11 @@ properties:
|
||||||
- friendlyarm,nanopi-r6s
|
- friendlyarm,nanopi-r6s
|
||||||
- const: rockchip,rk3588s
|
- const: rockchip,rk3588s
|
||||||
|
|
||||||
- description: FriendlyElec NanoPC T6
|
- description: FriendlyElec NanoPC T6 series boards
|
||||||
items:
|
items:
|
||||||
- const: friendlyarm,nanopc-t6
|
- enum:
|
||||||
|
- friendlyarm,nanopc-t6
|
||||||
|
- friendlyarm,nanopc-t6-lts
|
||||||
- const: rockchip,rk3588
|
- const: rockchip,rk3588
|
||||||
|
|
||||||
- description: FriendlyElec CM3588-based boards
|
- description: FriendlyElec CM3588-based boards
|
||||||
|
@ -255,6 +271,11 @@ properties:
|
||||||
- const: friendlyarm,cm3588
|
- const: friendlyarm,cm3588
|
||||||
- const: rockchip,rk3588
|
- const: rockchip,rk3588
|
||||||
|
|
||||||
|
- description: GameForce Ace
|
||||||
|
items:
|
||||||
|
- const: gameforce,ace
|
||||||
|
- const: rockchip,rk3588s
|
||||||
|
|
||||||
- description: GameForce Chi
|
- description: GameForce Chi
|
||||||
items:
|
items:
|
||||||
- const: gameforce,chi
|
- const: gameforce,chi
|
||||||
|
@ -581,9 +602,19 @@ properties:
|
||||||
|
|
||||||
- description: Hardkernel Odroid M1
|
- description: Hardkernel Odroid M1
|
||||||
items:
|
items:
|
||||||
- const: rockchip,rk3568-odroid-m1
|
- const: hardkernel,odroid-m1
|
||||||
- const: rockchip,rk3568
|
- 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
|
- description: Hugsun X99 TV Box
|
||||||
items:
|
items:
|
||||||
- const: hugsun,x99
|
- const: hugsun,x99
|
||||||
|
@ -622,6 +653,11 @@ properties:
|
||||||
- const: leez,p710
|
- const: leez,p710
|
||||||
- const: rockchip,rk3399
|
- const: rockchip,rk3399
|
||||||
|
|
||||||
|
- description: LCKFB Taishan Pi RK3566
|
||||||
|
items:
|
||||||
|
- const: lckfb,tspi-rk3566
|
||||||
|
- const: rockchip,rk3566
|
||||||
|
|
||||||
- description: Lunzn FastRhino R66S / R68S
|
- description: Lunzn FastRhino R66S / R68S
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
|
|
|
@ -26,6 +26,7 @@ select:
|
||||||
- rockchip,rk3368-pmu
|
- rockchip,rk3368-pmu
|
||||||
- rockchip,rk3399-pmu
|
- rockchip,rk3399-pmu
|
||||||
- rockchip,rk3568-pmu
|
- rockchip,rk3568-pmu
|
||||||
|
- rockchip,rk3576-pmu
|
||||||
- rockchip,rk3588-pmu
|
- rockchip,rk3588-pmu
|
||||||
- rockchip,rv1126-pmu
|
- rockchip,rv1126-pmu
|
||||||
|
|
||||||
|
@ -43,6 +44,7 @@ properties:
|
||||||
- rockchip,rk3368-pmu
|
- rockchip,rk3368-pmu
|
||||||
- rockchip,rk3399-pmu
|
- rockchip,rk3399-pmu
|
||||||
- rockchip,rk3568-pmu
|
- rockchip,rk3568-pmu
|
||||||
|
- rockchip,rk3576-pmu
|
||||||
- rockchip,rk3588-pmu
|
- rockchip,rk3588-pmu
|
||||||
- rockchip,rv1126-pmu
|
- rockchip,rv1126-pmu
|
||||||
- const: syscon
|
- const: syscon
|
||||||
|
|
|
@ -54,6 +54,8 @@ properties:
|
||||||
- description: ST STM32MP151 based Boards
|
- description: ST STM32MP151 based Boards
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
|
- prt,mecio1r0 # Protonic MECIO1r0
|
||||||
|
- prt,mect1s # Protonic MECT1S
|
||||||
- prt,prtt1a # Protonic PRTT1A
|
- prt,prtt1a # Protonic PRTT1A
|
||||||
- prt,prtt1c # Protonic PRTT1C
|
- prt,prtt1c # Protonic PRTT1C
|
||||||
- prt,prtt1s # Protonic PRTT1S
|
- prt,prtt1s # Protonic PRTT1S
|
||||||
|
@ -71,6 +73,12 @@ properties:
|
||||||
- const: dh,stm32mp151a-dhcor-som
|
- const: dh,stm32mp151a-dhcor-som
|
||||||
- const: st,stm32mp151
|
- const: st,stm32mp151
|
||||||
|
|
||||||
|
- description: ST STM32MP153 based Boards
|
||||||
|
items:
|
||||||
|
- enum:
|
||||||
|
- prt,mecio1r1 # Protonic MECIO1r1
|
||||||
|
- const: st,stm32mp153
|
||||||
|
|
||||||
- description: DH STM32MP153 DHCOM SoM based Boards
|
- description: DH STM32MP153 DHCOM SoM based Boards
|
||||||
items:
|
items:
|
||||||
- const: dh,stm32mp153c-dhcom-drc02
|
- const: dh,stm32mp153c-dhcom-drc02
|
||||||
|
|
|
@ -61,14 +61,19 @@ properties:
|
||||||
- const: anbernic,rg35xx-2024
|
- const: anbernic,rg35xx-2024
|
||||||
- const: allwinner,sun50i-h700
|
- const: allwinner,sun50i-h700
|
||||||
|
|
||||||
|
- description: Anbernic RG35XX H
|
||||||
|
items:
|
||||||
|
- const: anbernic,rg35xx-h
|
||||||
|
- const: allwinner,sun50i-h700
|
||||||
|
|
||||||
- description: Anbernic RG35XX Plus
|
- description: Anbernic RG35XX Plus
|
||||||
items:
|
items:
|
||||||
- const: anbernic,rg35xx-plus
|
- const: anbernic,rg35xx-plus
|
||||||
- const: allwinner,sun50i-h700
|
- const: allwinner,sun50i-h700
|
||||||
|
|
||||||
- description: Anbernic RG35XX H
|
- description: Anbernic RG35XX SP
|
||||||
items:
|
items:
|
||||||
- const: anbernic,rg35xx-h
|
- const: anbernic,rg35xx-sp
|
||||||
- const: allwinner,sun50i-h700
|
- const: allwinner,sun50i-h700
|
||||||
|
|
||||||
- description: Amarula A64 Relic
|
- description: Amarula A64 Relic
|
||||||
|
|
|
@ -127,6 +127,48 @@ properties:
|
||||||
- nvidia,norrin
|
- nvidia,norrin
|
||||||
- const: nvidia,tegra132
|
- const: nvidia,tegra132
|
||||||
- const: nvidia,tegra124
|
- 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:
|
- items:
|
||||||
- enum:
|
- enum:
|
||||||
- nvidia,darcy
|
- nvidia,darcy
|
||||||
|
|
|
@ -140,6 +140,7 @@ properties:
|
||||||
- description: K3 J722S SoC and Boards
|
- description: K3 J722S SoC and Boards
|
||||||
items:
|
items:
|
||||||
- enum:
|
- enum:
|
||||||
|
- beagle,am67a-beagley-ai
|
||||||
- ti,j722s-evm
|
- ti,j722s-evm
|
||||||
- const: ti,j722s
|
- const: ti,j722s
|
||||||
|
|
||||||
|
|
|
@ -30,6 +30,8 @@ select:
|
||||||
- marvell,armada-3700-ahci
|
- marvell,armada-3700-ahci
|
||||||
- marvell,armada-8k-ahci
|
- marvell,armada-8k-ahci
|
||||||
- marvell,berlin2q-ahci
|
- marvell,berlin2q-ahci
|
||||||
|
- qcom,apq8064-ahci
|
||||||
|
- qcom,ipq806x-ahci
|
||||||
- socionext,uniphier-pro4-ahci
|
- socionext,uniphier-pro4-ahci
|
||||||
- socionext,uniphier-pxs2-ahci
|
- socionext,uniphier-pxs2-ahci
|
||||||
- socionext,uniphier-pxs3-ahci
|
- socionext,uniphier-pxs3-ahci
|
||||||
|
@ -45,6 +47,8 @@ properties:
|
||||||
- marvell,armada-8k-ahci
|
- marvell,armada-8k-ahci
|
||||||
- marvell,berlin2-ahci
|
- marvell,berlin2-ahci
|
||||||
- marvell,berlin2q-ahci
|
- marvell,berlin2q-ahci
|
||||||
|
- qcom,apq8064-ahci
|
||||||
|
- qcom,ipq806x-ahci
|
||||||
- socionext,uniphier-pro4-ahci
|
- socionext,uniphier-pro4-ahci
|
||||||
- socionext,uniphier-pxs2-ahci
|
- socionext,uniphier-pxs2-ahci
|
||||||
- socionext,uniphier-pxs3-ahci
|
- socionext,uniphier-pxs3-ahci
|
||||||
|
@ -64,11 +68,11 @@ properties:
|
||||||
|
|
||||||
clocks:
|
clocks:
|
||||||
minItems: 1
|
minItems: 1
|
||||||
maxItems: 3
|
maxItems: 5
|
||||||
|
|
||||||
clock-names:
|
clock-names:
|
||||||
minItems: 1
|
minItems: 1
|
||||||
maxItems: 3
|
maxItems: 5
|
||||||
|
|
||||||
interrupts:
|
interrupts:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
@ -97,6 +101,31 @@ required:
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- $ref: ahci-common.yaml#
|
- $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:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|
|
@ -19,6 +19,7 @@ properties:
|
||||||
- fsl,imx53-ahci
|
- fsl,imx53-ahci
|
||||||
- fsl,imx6q-ahci
|
- fsl,imx6q-ahci
|
||||||
- fsl,imx6qp-ahci
|
- fsl,imx6qp-ahci
|
||||||
|
- fsl,imx8qm-ahci
|
||||||
|
|
||||||
reg:
|
reg:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
@ -27,12 +28,14 @@ properties:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
clocks:
|
clocks:
|
||||||
|
minItems: 2
|
||||||
items:
|
items:
|
||||||
- description: sata clock
|
- description: sata clock
|
||||||
- description: sata reference clock
|
- description: sata reference clock
|
||||||
- description: ahb clock
|
- description: ahb clock
|
||||||
|
|
||||||
clock-names:
|
clock-names:
|
||||||
|
minItems: 2
|
||||||
items:
|
items:
|
||||||
- const: sata
|
- const: sata
|
||||||
- const: sata_ref
|
- const: sata_ref
|
||||||
|
@ -58,6 +61,25 @@ properties:
|
||||||
$ref: /schemas/types.yaml#/definitions/flag
|
$ref: /schemas/types.yaml#/definitions/flag
|
||||||
description: if present, disable spread-spectrum clocking on the SATA link.
|
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:
|
required:
|
||||||
- compatible
|
- compatible
|
||||||
- reg
|
- reg
|
||||||
|
@ -65,6 +87,31 @@ required:
|
||||||
- clocks
|
- clocks
|
||||||
- clock-names
|
- 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
|
additionalProperties: false
|
||||||
|
|
||||||
examples:
|
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
|
@ -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
|
@ -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
|
@ -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:
|
items:
|
||||||
- description: input top pll
|
- description: input top pll
|
||||||
- description: input mclk pll
|
- description: input mclk pll
|
||||||
|
- description: input fix pll
|
||||||
|
|
||||||
clock-names:
|
clock-names:
|
||||||
items:
|
items:
|
||||||
- const: top
|
- const: top
|
||||||
- const: mclk
|
- const: mclk
|
||||||
|
- const: fix
|
||||||
|
|
||||||
"#clock-cells":
|
"#clock-cells":
|
||||||
const: 1
|
const: 1
|
||||||
|
@ -52,8 +54,9 @@ examples:
|
||||||
compatible = "amlogic,c3-pll-clkc";
|
compatible = "amlogic,c3-pll-clkc";
|
||||||
reg = <0x0 0x8000 0x0 0x1a4>;
|
reg = <0x0 0x8000 0x0 0x1a4>;
|
||||||
clocks = <&scmi_clk 2>,
|
clocks = <&scmi_clk 2>,
|
||||||
<&scmi_clk 5>;
|
<&scmi_clk 5>,
|
||||||
clock-names = "top", "mclk";
|
<&scmi_clk 12>;
|
||||||
|
clock-names = "top", "mclk", "fix";
|
||||||
#clock-cells = <1>;
|
#clock-cells = <1>;
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
|
@ -126,8 +126,6 @@ required:
|
||||||
- compatible
|
- compatible
|
||||||
- reg
|
- reg
|
||||||
- '#clock-cells'
|
- '#clock-cells'
|
||||||
- idt,shutdown
|
|
||||||
- idt,output-enable-active
|
|
||||||
|
|
||||||
allOf:
|
allOf:
|
||||||
- if:
|
- 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
|
- description: USB PCIE wrapper pipe clock source
|
||||||
|
|
||||||
'#power-domain-cells': false
|
'#power-domain-cells': false
|
||||||
|
'#interconnect-cells':
|
||||||
|
const: 1
|
||||||
|
|
||||||
required:
|
required:
|
||||||
- compatible
|
- compatible
|
||||||
|
|
|
@ -139,7 +139,7 @@ examples:
|
||||||
- |
|
- |
|
||||||
rpm {
|
rpm {
|
||||||
rpm-requests {
|
rpm-requests {
|
||||||
compatible = "qcom,rpm-msm8916";
|
compatible = "qcom,rpm-msm8916", "qcom,smd-rpm";
|
||||||
qcom,smd-channels = "rpm_requests";
|
qcom,smd-channels = "rpm_requests";
|
||||||
|
|
||||||
clock-controller {
|
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.
|
domains on Qualcomm SoCs.
|
||||||
|
|
||||||
See also::
|
See also::
|
||||||
|
include/dt-bindings/clock/qcom,sm4450-gpucc.h
|
||||||
include/dt-bindings/clock/qcom,sm8450-gpucc.h
|
include/dt-bindings/clock/qcom,sm8450-gpucc.h
|
||||||
include/dt-bindings/clock/qcom,sm8550-gpucc.h
|
include/dt-bindings/clock/qcom,sm8550-gpucc.h
|
||||||
include/dt-bindings/reset/qcom,sm8450-gpucc.h
|
include/dt-bindings/reset/qcom,sm8450-gpucc.h
|
||||||
|
@ -23,6 +24,7 @@ description: |
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
enum:
|
enum:
|
||||||
|
- qcom,sm4450-gpucc
|
||||||
- qcom,sm8450-gpucc
|
- qcom,sm8450-gpucc
|
||||||
- qcom,sm8550-gpucc
|
- qcom,sm8550-gpucc
|
||||||
- qcom,sm8650-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-top
|
||||||
- samsung,exynosautov9-cmu-busmc
|
- samsung,exynosautov9-cmu-busmc
|
||||||
- samsung,exynosautov9-cmu-core
|
- samsung,exynosautov9-cmu-core
|
||||||
|
- samsung,exynosautov9-cmu-dpum
|
||||||
- samsung,exynosautov9-cmu-fsys0
|
- samsung,exynosautov9-cmu-fsys0
|
||||||
- samsung,exynosautov9-cmu-fsys1
|
- samsung,exynosautov9-cmu-fsys1
|
||||||
- samsung,exynosautov9-cmu-fsys2
|
- samsung,exynosautov9-cmu-fsys2
|
||||||
|
@ -109,6 +110,24 @@ allOf:
|
||||||
- const: oscclk
|
- const: oscclk
|
||||||
- const: dout_clkcmu_core_bus
|
- 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:
|
- if:
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
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
|
This property is required in idle state nodes of device tree meant
|
||||||
for RISC-V systems. For more details on the suspend_type parameter
|
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:
|
local-timer-stop:
|
||||||
description:
|
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
|
- const: fsl,sec-v4.0-rtic
|
||||||
|
|
||||||
reg:
|
reg:
|
||||||
maxItems: 1
|
items:
|
||||||
|
- description: RTIC control and status register space.
|
||||||
|
- description: RTIC recoverable error indication register space.
|
||||||
|
minItems: 1
|
||||||
|
|
||||||
ranges:
|
ranges:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
|
@ -17,6 +17,7 @@ properties:
|
||||||
- qcom,prng-ee # 8996 and later using EE
|
- qcom,prng-ee # 8996 and later using EE
|
||||||
- items:
|
- items:
|
||||||
- enum:
|
- enum:
|
||||||
|
- qcom,sa8255p-trng
|
||||||
- qcom,sa8775p-trng
|
- qcom,sa8775p-trng
|
||||||
- qcom,sc7280-trng
|
- qcom,sc7280-trng
|
||||||
- qcom,sm8450-trng
|
- qcom,sm8450-trng
|
||||||
|
|
|
@ -50,6 +50,14 @@ properties:
|
||||||
- const: disp_axi
|
- const: disp_axi
|
||||||
minItems: 1
|
minItems: 1
|
||||||
|
|
||||||
|
dmas:
|
||||||
|
items:
|
||||||
|
- description: DMA specifier for the RX DMA channel.
|
||||||
|
|
||||||
|
dma-names:
|
||||||
|
items:
|
||||||
|
- const: rx
|
||||||
|
|
||||||
interrupts:
|
interrupts:
|
||||||
items:
|
items:
|
||||||
- description: LCDIF DMA interrupt
|
- description: LCDIF DMA interrupt
|
||||||
|
@ -156,6 +164,18 @@ allOf:
|
||||||
interrupts:
|
interrupts:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
|
||||||
|
- if:
|
||||||
|
not:
|
||||||
|
properties:
|
||||||
|
compatible:
|
||||||
|
contains:
|
||||||
|
enum:
|
||||||
|
- fsl,imx28-lcdif
|
||||||
|
then:
|
||||||
|
properties:
|
||||||
|
dmas: false
|
||||||
|
dma-names: false
|
||||||
|
|
||||||
examples:
|
examples:
|
||||||
- |
|
- |
|
||||||
#include <dt-bindings/clock/imx6sx-clock.h>
|
#include <dt-bindings/clock/imx6sx-clock.h>
|
||||||
|
|
|
@ -16,7 +16,7 @@ maintainers:
|
||||||
description:
|
description:
|
||||||
This binding extends the data mapping defined in lvds-data-mapping.yaml.
|
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
|
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.
|
data formats and layouts is used to drive LVDS displays.
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
|
|
|
@ -1,10 +1,10 @@
|
||||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||||
%YAML 1.2
|
%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#
|
$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:
|
maintainers:
|
||||||
- Ryan Walklin <ryan@testtoast.com>
|
- Ryan Walklin <ryan@testtoast.com>
|
||||||
|
@ -15,7 +15,14 @@ allOf:
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
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:
|
reg:
|
||||||
maxItems: 1
|
maxItems: 1
|
||||||
|
@ -40,7 +47,7 @@ examples:
|
||||||
#size-cells = <0>;
|
#size-cells = <0>;
|
||||||
|
|
||||||
panel@0 {
|
panel@0 {
|
||||||
compatible = "wl-355608-a8";
|
compatible = "anbernic,rg35xx-plus-panel";
|
||||||
reg = <0>;
|
reg = <0>;
|
||||||
|
|
||||||
spi-3wire;
|
spi-3wire;
|
|
@ -84,11 +84,7 @@ properties:
|
||||||
- port@0
|
- port@0
|
||||||
- port@1
|
- port@1
|
||||||
|
|
||||||
backlight: true
|
unevaluatedProperties: false
|
||||||
enable-gpios: true
|
|
||||||
power-supply: true
|
|
||||||
|
|
||||||
additionalProperties: false
|
|
||||||
|
|
||||||
required:
|
required:
|
||||||
- compatible
|
- 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.
|
memcpy channels in eDMA.
|
||||||
|
|
||||||
Notes:
|
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).
|
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:
|
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
|
[0] https://developer.arm.com/documentation/den0056/latest
|
||||||
|
|
||||||
|
anyOf:
|
||||||
|
- $ref: /schemas/firmware/nxp,imx95-scmi.yaml
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
$nodename:
|
$nodename:
|
||||||
const: scmi
|
const: scmi
|
||||||
|
@ -121,6 +124,13 @@ properties:
|
||||||
atomic mode of operation, even if requested.
|
atomic mode of operation, even if requested.
|
||||||
default: 0
|
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:
|
arm,smc-id:
|
||||||
$ref: /schemas/types.yaml#/definitions/uint32
|
$ref: /schemas/types.yaml#/definitions/uint32
|
||||||
description:
|
description:
|
||||||
|
@ -145,6 +155,14 @@ properties:
|
||||||
required:
|
required:
|
||||||
- '#power-domain-cells'
|
- '#power-domain-cells'
|
||||||
|
|
||||||
|
protocol@12:
|
||||||
|
$ref: '#/$defs/protocol-node'
|
||||||
|
unevaluatedProperties: false
|
||||||
|
|
||||||
|
properties:
|
||||||
|
reg:
|
||||||
|
const: 0x12
|
||||||
|
|
||||||
protocol@13:
|
protocol@13:
|
||||||
$ref: '#/$defs/protocol-node'
|
$ref: '#/$defs/protocol-node'
|
||||||
unevaluatedProperties: false
|
unevaluatedProperties: false
|
||||||
|
@ -284,7 +302,7 @@ properties:
|
||||||
required:
|
required:
|
||||||
- reg
|
- reg
|
||||||
|
|
||||||
additionalProperties: false
|
unevaluatedProperties: false
|
||||||
|
|
||||||
$defs:
|
$defs:
|
||||||
protocol-node:
|
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:
|
allOf:
|
||||||
- $ref: gnss-common.yaml#
|
- $ref: gnss-common.yaml#
|
||||||
|
- $ref: /schemas/serial/serial-peripheral-props.yaml#
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
compatible:
|
compatible:
|
||||||
|
|