Merge b02847fc2e ("Merge tag 'firewire-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394") into android-mainline
Steps on the way to 6.4-rc1 Change-Id: I838a5d220c6f84ba01400af83b7ec3d582376daa Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This commit is contained in:
Greg Kroah-Hartman
@@ -520,6 +520,7 @@ ForEachMacros:
|
||||
- 'of_property_for_each_string'
|
||||
- 'of_property_for_each_u32'
|
||||
- 'pci_bus_for_each_resource'
|
||||
- 'pci_dev_for_each_resource'
|
||||
- 'pci_doe_for_each_off'
|
||||
- 'pcl_for_each_chunk'
|
||||
- 'pcl_for_each_segment'
|
||||
|
||||
@@ -166,6 +166,23 @@ Description:
|
||||
The file will be present for all speeds of USB devices, and will
|
||||
always read "no" for USB 1.1 and USB 2.0 devices.
|
||||
|
||||
What: /sys/bus/usb/devices/<INTERFACE>/wireless_status
|
||||
Date: February 2023
|
||||
Contact: Bastien Nocera <hadess@hadess.net>
|
||||
Description:
|
||||
Some USB devices use a USB receiver dongle to communicate
|
||||
wirelessly with their device using proprietary protocols. This
|
||||
attribute allows user-space to know whether the device is
|
||||
connected to its receiver dongle, and, for example, consider
|
||||
the device to be absent when choosing whether to show the
|
||||
device's battery, show a headset in a list of outputs, or show
|
||||
an on-screen keyboard if the only wireless keyboard is
|
||||
turned off.
|
||||
This attribute is not to be used to replace protocol specific
|
||||
statuses available in WWAN, WLAN/Wi-Fi, Bluetooth, etc.
|
||||
If the device does not use a receiver dongle with a wireless
|
||||
device, then this attribute will not exist.
|
||||
|
||||
What: /sys/bus/usb/devices/.../<hub_interface>/port<X>
|
||||
Date: August 2012
|
||||
Contact: Lan Tianyu <tianyu.lan@intel.com>
|
||||
|
||||
@@ -418,7 +418,6 @@ That is, the recovery API only requires that:
|
||||
- drivers/next/e100.c
|
||||
- drivers/net/e1000
|
||||
- drivers/net/e1000e
|
||||
- drivers/net/ixgb
|
||||
- drivers/net/ixgbe
|
||||
- drivers/net/cxgb3
|
||||
- drivers/net/s2io.c
|
||||
|
||||
@@ -314,7 +314,7 @@ Q: What is the compatibility story for special BPF types in map values?
|
||||
Q: Users are allowed to embed bpf_spin_lock, bpf_timer fields in their BPF map
|
||||
values (when using BTF support for BPF maps). This allows to use helpers for
|
||||
such objects on these fields inside map values. Users are also allowed to embed
|
||||
pointers to some kernel types (with __kptr and __kptr_ref BTF tags). Will the
|
||||
pointers to some kernel types (with __kptr_untrusted and __kptr BTF tags). Will the
|
||||
kernel preserve backwards compatibility for these features?
|
||||
|
||||
A: It depends. For bpf_spin_lock, bpf_timer: YES, for kptr and everything else:
|
||||
@@ -324,7 +324,7 @@ For struct types that have been added already, like bpf_spin_lock and bpf_timer,
|
||||
the kernel will preserve backwards compatibility, as they are part of UAPI.
|
||||
|
||||
For kptrs, they are also part of UAPI, but only with respect to the kptr
|
||||
mechanism. The types that you can use with a __kptr and __kptr_ref tagged
|
||||
mechanism. The types that you can use with a __kptr_untrusted and __kptr tagged
|
||||
pointer in your struct are NOT part of the UAPI contract. The supported types can
|
||||
and will change across kernel releases. However, operations like accessing kptr
|
||||
fields and bpf_kptr_xchg() helper will continue to be supported across kernel
|
||||
|
||||
@@ -128,7 +128,8 @@ into the bpf-next tree will make their way into net-next tree. net and
|
||||
net-next are both run by David S. Miller. From there, they will go
|
||||
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
||||
process of net and net-next being merged into the mainline tree, see
|
||||
the :ref:`netdev-FAQ`
|
||||
the documentation on netdev subsystem at
|
||||
Documentation/process/maintainer-netdev.rst.
|
||||
|
||||
|
||||
|
||||
@@ -147,7 +148,8 @@ request)::
|
||||
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
A: The process is the very same as described in the :ref:`netdev-FAQ`,
|
||||
A: The process is the very same as described in the netdev subsystem
|
||||
documentation at Documentation/process/maintainer-netdev.rst,
|
||||
so please read up on it. The subject line must indicate whether the
|
||||
patch is a fix or rather "next-like" content in order to let the
|
||||
maintainers know whether it is targeted at bpf or bpf-next.
|
||||
@@ -206,8 +208,9 @@ ii) run extensive BPF test suite and
|
||||
Once the BPF pull request was accepted by David S. Miller, then
|
||||
the patches end up in net or net-next tree, respectively, and
|
||||
make their way from there further into mainline. Again, see the
|
||||
:ref:`netdev-FAQ` for additional information e.g. on how often they are
|
||||
merged to mainline.
|
||||
documentation for netdev subsystem at
|
||||
Documentation/process/maintainer-netdev.rst for additional information
|
||||
e.g. on how often they are merged to mainline.
|
||||
|
||||
Q: How long do I need to wait for feedback on my BPF patches?
|
||||
-------------------------------------------------------------
|
||||
@@ -230,7 +233,8 @@ Q: Are patches applied to bpf-next when the merge window is open?
|
||||
-----------------------------------------------------------------
|
||||
A: For the time when the merge window is open, bpf-next will not be
|
||||
processed. This is roughly analogous to net-next patch processing,
|
||||
so feel free to read up on the :ref:`netdev-FAQ` about further details.
|
||||
so feel free to read up on the netdev docs at
|
||||
Documentation/process/maintainer-netdev.rst about further details.
|
||||
|
||||
During those two weeks of merge window, we might ask you to resend
|
||||
your patch series once bpf-next is open again. Once Linus released
|
||||
@@ -394,7 +398,8 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
|
||||
netdev@vger.kernel.org
|
||||
|
||||
The process in general is the same as on netdev itself, see also the
|
||||
:ref:`netdev-FAQ`.
|
||||
the documentation on networking subsystem at
|
||||
Documentation/process/maintainer-netdev.rst.
|
||||
|
||||
Q: Do you also backport to kernels not currently maintained as stable?
|
||||
----------------------------------------------------------------------
|
||||
@@ -410,7 +415,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
|
||||
What should I do?
|
||||
|
||||
A: The same rules apply as with netdev patch submissions in general, see
|
||||
the :ref:`netdev-FAQ`.
|
||||
the netdev docs at Documentation/process/maintainer-netdev.rst.
|
||||
|
||||
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
||||
ask the BPF maintainers to queue the patches instead. This can be done
|
||||
@@ -684,7 +689,6 @@ when:
|
||||
|
||||
|
||||
.. Links
|
||||
.. _netdev-FAQ: Documentation/process/maintainer-netdev.rst
|
||||
.. _selftests:
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
|
||||
|
||||
|
||||
@@ -20,6 +20,12 @@ Arithmetic instructions
|
||||
For CPU versions prior to 3, Clang v7.0 and later can enable ``BPF_ALU`` support with
|
||||
``-Xclang -target-feature -Xclang +alu32``. In CPU version 3, support is automatically included.
|
||||
|
||||
Jump instructions
|
||||
=================
|
||||
|
||||
If ``-O0`` is used, Clang will generate the ``BPF_CALL | BPF_X | BPF_JMP`` (0x8d)
|
||||
instruction, which is not supported by the Linux kernel verifier.
|
||||
|
||||
Atomic operations
|
||||
=================
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ For example:
|
||||
.. code-block:: c
|
||||
|
||||
struct cpumask_map_value {
|
||||
struct bpf_cpumask __kptr_ref * cpumask;
|
||||
struct bpf_cpumask __kptr * cpumask;
|
||||
};
|
||||
|
||||
struct array_map {
|
||||
@@ -117,18 +117,13 @@ For example:
|
||||
As mentioned and illustrated above, these ``struct bpf_cpumask *`` objects can
|
||||
also be stored in a map and used as kptrs. If a ``struct bpf_cpumask *`` is in
|
||||
a map, the reference can be removed from the map with bpf_kptr_xchg(), or
|
||||
opportunistically acquired with bpf_cpumask_kptr_get():
|
||||
|
||||
.. kernel-doc:: kernel/bpf/cpumask.c
|
||||
:identifiers: bpf_cpumask_kptr_get
|
||||
|
||||
Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map:
|
||||
opportunistically acquired using RCU:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* struct containing the struct bpf_cpumask kptr which is stored in the map. */
|
||||
struct cpumasks_kfunc_map_value {
|
||||
struct bpf_cpumask __kptr_ref * bpf_cpumask;
|
||||
struct bpf_cpumask __kptr * bpf_cpumask;
|
||||
};
|
||||
|
||||
/* The map containing struct cpumasks_kfunc_map_value entries. */
|
||||
@@ -144,7 +139,7 @@ Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map:
|
||||
/**
|
||||
* A simple example tracepoint program showing how a
|
||||
* struct bpf_cpumask * kptr that is stored in a map can
|
||||
* be acquired using the bpf_cpumask_kptr_get() kfunc.
|
||||
* be passed to kfuncs using RCU protection.
|
||||
*/
|
||||
SEC("tp_btf/cgroup_mkdir")
|
||||
int BPF_PROG(cgrp_ancestor_example, struct cgroup *cgrp, const char *path)
|
||||
@@ -158,26 +153,21 @@ Here is an example of a ``struct bpf_cpumask *`` being retrieved from a map:
|
||||
if (!v)
|
||||
return -ENOENT;
|
||||
|
||||
bpf_rcu_read_lock();
|
||||
/* Acquire a reference to the bpf_cpumask * kptr that's already stored in the map. */
|
||||
kptr = bpf_cpumask_kptr_get(&v->cpumask);
|
||||
if (!kptr)
|
||||
kptr = v->cpumask;
|
||||
if (!kptr) {
|
||||
/* If no bpf_cpumask was present in the map, it's because
|
||||
* we're racing with another CPU that removed it with
|
||||
* bpf_kptr_xchg() between the bpf_map_lookup_elem()
|
||||
* above, and our call to bpf_cpumask_kptr_get().
|
||||
* bpf_cpumask_kptr_get() internally safely handles this
|
||||
* race, and will return NULL if the cpumask is no longer
|
||||
* present in the map by the time we invoke the kfunc.
|
||||
* above, and our load of the pointer from the map.
|
||||
*/
|
||||
bpf_rcu_read_unlock();
|
||||
return -EBUSY;
|
||||
}
|
||||
|
||||
/* Free the reference we just took above. Note that the
|
||||
* original struct bpf_cpumask * kptr is still in the map. It will
|
||||
* be freed either at a later time if another context deletes
|
||||
* it from the map, or automatically by the BPF subsystem if
|
||||
* it's still present when the map is destroyed.
|
||||
*/
|
||||
bpf_cpumask_release(kptr);
|
||||
bpf_cpumask_setall(kptr);
|
||||
bpf_rcu_read_unlock();
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
@@ -11,7 +11,8 @@ Documentation conventions
|
||||
=========================
|
||||
|
||||
For brevity, this document uses the type notion "u64", "u32", etc.
|
||||
to mean an unsigned integer whose width is the specified number of bits.
|
||||
to mean an unsigned integer whose width is the specified number of bits,
|
||||
and "s32", etc. to mean a signed integer of the specified number of bits.
|
||||
|
||||
Registers and calling convention
|
||||
================================
|
||||
@@ -38,14 +39,11 @@ eBPF has two instruction encodings:
|
||||
* the wide instruction encoding, which appends a second 64-bit immediate (i.e.,
|
||||
constant) value after the basic instruction for a total of 128 bits.
|
||||
|
||||
The basic instruction encoding is as follows, where MSB and LSB mean the most significant
|
||||
bits and least significant bits, respectively:
|
||||
The fields conforming an encoded basic instruction are stored in the
|
||||
following order::
|
||||
|
||||
============= ======= ======= ======= ============
|
||||
32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB)
|
||||
============= ======= ======= ======= ============
|
||||
imm offset src_reg dst_reg opcode
|
||||
============= ======= ======= ======= ============
|
||||
opcode:8 src_reg:4 dst_reg:4 offset:16 imm:32 // In little-endian BPF.
|
||||
opcode:8 dst_reg:4 src_reg:4 offset:16 imm:32 // In big-endian BPF.
|
||||
|
||||
**imm**
|
||||
signed integer immediate value
|
||||
@@ -63,6 +61,18 @@ imm offset src_reg dst_reg opcode
|
||||
**opcode**
|
||||
operation to perform
|
||||
|
||||
Note that the contents of multi-byte fields ('imm' and 'offset') are
|
||||
stored using big-endian byte ordering in big-endian BPF and
|
||||
little-endian byte ordering in little-endian BPF.
|
||||
|
||||
For example::
|
||||
|
||||
opcode offset imm assembly
|
||||
src_reg dst_reg
|
||||
07 0 1 00 00 44 33 22 11 r1 += 0x11223344 // little
|
||||
dst_reg src_reg
|
||||
07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big
|
||||
|
||||
Note that most instructions do not use all of the fields.
|
||||
Unused fields shall be cleared to zero.
|
||||
|
||||
@@ -72,18 +82,23 @@ The 64 bits following the basic instruction contain a pseudo instruction
|
||||
using the same format but with opcode, dst_reg, src_reg, and offset all set to zero,
|
||||
and imm containing the high 32 bits of the immediate value.
|
||||
|
||||
================= ==================
|
||||
64 bits (MSB) 64 bits (LSB)
|
||||
================= ==================
|
||||
basic instruction pseudo instruction
|
||||
================= ==================
|
||||
This is depicted in the following figure::
|
||||
|
||||
basic_instruction
|
||||
.-----------------------------.
|
||||
| |
|
||||
code:8 regs:8 offset:16 imm:32 unused:32 imm:32
|
||||
| |
|
||||
'--------------'
|
||||
pseudo instruction
|
||||
|
||||
Thus the 64-bit immediate value is constructed as follows:
|
||||
|
||||
imm64 = (next_imm << 32) | imm
|
||||
|
||||
where 'next_imm' refers to the imm value of the pseudo instruction
|
||||
following the basic instruction.
|
||||
following the basic instruction. The unused bytes in the pseudo
|
||||
instruction are reserved and shall be cleared to zero.
|
||||
|
||||
Instruction classes
|
||||
-------------------
|
||||
@@ -228,28 +243,58 @@ Jump instructions
|
||||
otherwise identical operations.
|
||||
The 'code' field encodes the operation as below:
|
||||
|
||||
======== ===== ========================= ============
|
||||
code value description notes
|
||||
======== ===== ========================= ============
|
||||
BPF_JA 0x00 PC += off BPF_JMP only
|
||||
BPF_JEQ 0x10 PC += off if dst == src
|
||||
BPF_JGT 0x20 PC += off if dst > src unsigned
|
||||
BPF_JGE 0x30 PC += off if dst >= src unsigned
|
||||
BPF_JSET 0x40 PC += off if dst & src
|
||||
BPF_JNE 0x50 PC += off if dst != src
|
||||
BPF_JSGT 0x60 PC += off if dst > src signed
|
||||
BPF_JSGE 0x70 PC += off if dst >= src signed
|
||||
BPF_CALL 0x80 function call
|
||||
BPF_EXIT 0x90 function / program return BPF_JMP only
|
||||
BPF_JLT 0xa0 PC += off if dst < src unsigned
|
||||
BPF_JLE 0xb0 PC += off if dst <= src unsigned
|
||||
BPF_JSLT 0xc0 PC += off if dst < src signed
|
||||
BPF_JSLE 0xd0 PC += off if dst <= src signed
|
||||
======== ===== ========================= ============
|
||||
======== ===== === =========================================== =========================================
|
||||
code value src description notes
|
||||
======== ===== === =========================================== =========================================
|
||||
BPF_JA 0x0 0x0 PC += offset BPF_JMP only
|
||||
BPF_JEQ 0x1 any PC += offset if dst == src
|
||||
BPF_JGT 0x2 any PC += offset if dst > src unsigned
|
||||
BPF_JGE 0x3 any PC += offset if dst >= src unsigned
|
||||
BPF_JSET 0x4 any PC += offset if dst & src
|
||||
BPF_JNE 0x5 any PC += offset if dst != src
|
||||
BPF_JSGT 0x6 any PC += offset if dst > src signed
|
||||
BPF_JSGE 0x7 any PC += offset if dst >= src signed
|
||||
BPF_CALL 0x8 0x0 call helper function by address see `Helper functions`_
|
||||
BPF_CALL 0x8 0x1 call PC += offset see `Program-local functions`_
|
||||
BPF_CALL 0x8 0x2 call helper function by BTF ID see `Helper functions`_
|
||||
BPF_EXIT 0x9 0x0 return BPF_JMP only
|
||||
BPF_JLT 0xa any PC += offset if dst < src unsigned
|
||||
BPF_JLE 0xb any PC += offset if dst <= src unsigned
|
||||
BPF_JSLT 0xc any PC += offset if dst < src signed
|
||||
BPF_JSLE 0xd any PC += offset if dst <= src signed
|
||||
======== ===== === =========================================== =========================================
|
||||
|
||||
The eBPF program needs to store the return value into register R0 before doing a
|
||||
BPF_EXIT.
|
||||
``BPF_EXIT``.
|
||||
|
||||
Example:
|
||||
|
||||
``BPF_JSGE | BPF_X | BPF_JMP32`` (0x7e) means::
|
||||
|
||||
if (s32)dst s>= (s32)src goto +offset
|
||||
|
||||
where 's>=' indicates a signed '>=' comparison.
|
||||
|
||||
Helper functions
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Helper functions are a concept whereby BPF programs can call into a
|
||||
set of function calls exposed by the underlying platform.
|
||||
|
||||
Historically, each helper function was identified by an address
|
||||
encoded in the imm field. The available helper functions may differ
|
||||
for each program type, but address values are unique across all program types.
|
||||
|
||||
Platforms that support the BPF Type Format (BTF) support identifying
|
||||
a helper function by a BTF ID encoded in the imm field, where the BTF ID
|
||||
identifies the helper name and type.
|
||||
|
||||
Program-local functions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Program-local functions are functions exposed by the same BPF program as the
|
||||
caller, and are referenced by offset from the call instruction, similar to
|
||||
``BPF_JA``. A ``BPF_EXIT`` within the program-local function will return to
|
||||
the caller.
|
||||
|
||||
Load and store instructions
|
||||
===========================
|
||||
@@ -371,14 +416,56 @@ and loaded back to ``R0``.
|
||||
-----------------------------
|
||||
|
||||
Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction
|
||||
encoding for an extra imm64 value.
|
||||
encoding defined in `Instruction encoding`_, and use the 'src' field of the
|
||||
basic instruction to hold an opcode subtype.
|
||||
|
||||
There is currently only one such instruction.
|
||||
The following table defines a set of ``BPF_IMM | BPF_DW | BPF_LD`` instructions
|
||||
with opcode subtypes in the 'src' field, using new terms such as "map"
|
||||
defined further below:
|
||||
|
||||
``BPF_LD | BPF_DW | BPF_IMM`` means::
|
||||
========================= ====== === ========================================= =========== ==============
|
||||
opcode construction opcode src pseudocode imm type dst type
|
||||
========================= ====== === ========================================= =========== ==============
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
|
||||
========================= ====== === ========================================= =========== ==============
|
||||
|
||||
dst = imm64
|
||||
where
|
||||
|
||||
* map_by_fd(imm) means to convert a 32-bit file descriptor into an address of a map (see `Maps`_)
|
||||
* map_by_idx(imm) means to convert a 32-bit index into an address of a map
|
||||
* map_val(map) gets the address of the first value in a given map
|
||||
* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id
|
||||
* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions
|
||||
* the 'imm type' can be used by disassemblers for display
|
||||
* the 'dst type' can be used for verification and JIT compilation purposes
|
||||
|
||||
Maps
|
||||
~~~~
|
||||
|
||||
Maps are shared memory regions accessible by eBPF programs on some platforms.
|
||||
A map can have various semantics as defined in a separate document, and may or
|
||||
may not have a single contiguous memory region, but the 'map_val(map)' is
|
||||
currently only defined for maps that do have a single contiguous memory region.
|
||||
|
||||
Each map can have a file descriptor (fd) if supported by the platform, where
|
||||
'map_by_fd(imm)' means to get the map with the specified file descriptor. Each
|
||||
BPF program can also be defined to use a set of maps associated with the
|
||||
program at load time, and 'map_by_idx(imm)' means to get the map with the given
|
||||
index in the set associated with the BPF program containing the instruction.
|
||||
|
||||
Platform Variables
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Platform variables are memory regions, identified by integer ids, exposed by
|
||||
the runtime and accessible by BPF programs on some platforms. The
|
||||
'var_addr(imm)' operation means to get the address of the memory region
|
||||
identified by the given id.
|
||||
|
||||
Legacy BPF Packet access instructions
|
||||
-------------------------------------
|
||||
|
||||
+84
-100
@@ -100,6 +100,23 @@ Hence, whenever a constant scalar argument is accepted by a kfunc which is not a
|
||||
size parameter, and the value of the constant matters for program safety, __k
|
||||
suffix should be used.
|
||||
|
||||
2.2.2 __uninit Annotation
|
||||
-------------------------
|
||||
|
||||
This annotation is used to indicate that the argument will be treated as
|
||||
uninitialized.
|
||||
|
||||
An example is given below::
|
||||
|
||||
__bpf_kfunc int bpf_dynptr_from_skb(..., struct bpf_dynptr_kern *ptr__uninit)
|
||||
{
|
||||
...
|
||||
}
|
||||
|
||||
Here, the dynptr will be treated as an uninitialized dynptr. Without this
|
||||
annotation, the verifier will reject the program if the dynptr passed in is
|
||||
not initialized.
|
||||
|
||||
.. _BPF_kfunc_nodef:
|
||||
|
||||
2.3 Using an existing kernel function
|
||||
@@ -162,20 +179,12 @@ both are orthogonal to each other.
|
||||
---------------------
|
||||
|
||||
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
|
||||
passed in to it. There can be only one referenced pointer that can be passed in.
|
||||
All copies of the pointer being released are invalidated as a result of invoking
|
||||
kfunc with this flag.
|
||||
passed in to it. There can be only one referenced pointer that can be passed
|
||||
in. All copies of the pointer being released are invalidated as a result of
|
||||
invoking kfunc with this flag. KF_RELEASE kfuncs automatically receive the
|
||||
protection afforded by the KF_TRUSTED_ARGS flag described below.
|
||||
|
||||
2.4.4 KF_KPTR_GET flag
|
||||
----------------------
|
||||
|
||||
The KF_KPTR_GET flag is used to indicate that the kfunc takes the first argument
|
||||
as a pointer to kptr, safely increments the refcount of the object it points to,
|
||||
and returns a reference to the user. The rest of the arguments may be normal
|
||||
arguments of a kfunc. The KF_KPTR_GET flag should be used in conjunction with
|
||||
KF_ACQUIRE and KF_RET_NULL flags.
|
||||
|
||||
2.4.5 KF_TRUSTED_ARGS flag
|
||||
2.4.4 KF_TRUSTED_ARGS flag
|
||||
--------------------------
|
||||
|
||||
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
|
||||
@@ -187,7 +196,7 @@ exception described below).
|
||||
There are two types of pointers to kernel objects which are considered "valid":
|
||||
|
||||
1. Pointers which are passed as tracepoint or struct_ops callback arguments.
|
||||
2. Pointers which were returned from a KF_ACQUIRE or KF_KPTR_GET kfunc.
|
||||
2. Pointers which were returned from a KF_ACQUIRE kfunc.
|
||||
|
||||
Pointers to non-BTF objects (e.g. scalar pointers) may also be passed to
|
||||
KF_TRUSTED_ARGS kfuncs, and may have a non-zero offset.
|
||||
@@ -214,13 +223,13 @@ In other words, you must:
|
||||
2. Specify the type and name of the trusted nested field. This field must match
|
||||
the field in the original type definition exactly.
|
||||
|
||||
2.4.6 KF_SLEEPABLE flag
|
||||
2.4.5 KF_SLEEPABLE flag
|
||||
-----------------------
|
||||
|
||||
The KF_SLEEPABLE flag is used for kfuncs that may sleep. Such kfuncs can only
|
||||
be called by sleepable BPF programs (BPF_F_SLEEPABLE).
|
||||
|
||||
2.4.7 KF_DESTRUCTIVE flag
|
||||
2.4.6 KF_DESTRUCTIVE flag
|
||||
--------------------------
|
||||
|
||||
The KF_DESTRUCTIVE flag is used to indicate functions calling which is
|
||||
@@ -229,18 +238,20 @@ rebooting or panicking. Due to this additional restrictions apply to these
|
||||
calls. At the moment they only require CAP_SYS_BOOT capability, but more can be
|
||||
added later.
|
||||
|
||||
2.4.8 KF_RCU flag
|
||||
2.4.7 KF_RCU flag
|
||||
-----------------
|
||||
|
||||
The KF_RCU flag is used for kfuncs which have a rcu ptr as its argument.
|
||||
When used together with KF_ACQUIRE, it indicates the kfunc should have a
|
||||
single argument which must be a trusted argument or a MEM_RCU pointer.
|
||||
The argument may have reference count of 0 and the kfunc must take this
|
||||
into consideration.
|
||||
The KF_RCU flag is a weaker version of KF_TRUSTED_ARGS. The kfuncs marked with
|
||||
KF_RCU expect either PTR_TRUSTED or MEM_RCU arguments. The verifier guarantees
|
||||
that the objects are valid and there is no use-after-free. The pointers are not
|
||||
NULL, but the object's refcount could have reached zero. The kfuncs need to
|
||||
consider doing refcnt != 0 check, especially when returning a KF_ACQUIRE
|
||||
pointer. Note as well that a KF_ACQUIRE kfunc that is KF_RCU should very likely
|
||||
also be KF_RET_NULL.
|
||||
|
||||
.. _KF_deprecated_flag:
|
||||
|
||||
2.4.9 KF_DEPRECATED flag
|
||||
2.4.8 KF_DEPRECATED flag
|
||||
------------------------
|
||||
|
||||
The KF_DEPRECATED flag is used for kfuncs which are scheduled to be
|
||||
@@ -451,13 +462,50 @@ struct_ops callback arg. For example:
|
||||
struct task_struct *acquired;
|
||||
|
||||
acquired = bpf_task_acquire(task);
|
||||
if (acquired)
|
||||
/*
|
||||
* In a typical program you'd do something like store
|
||||
* the task in a map, and the map will automatically
|
||||
* release it later. Here, we release it manually.
|
||||
*/
|
||||
bpf_task_release(acquired);
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
References acquired on ``struct task_struct *`` objects are RCU protected.
|
||||
Therefore, when in an RCU read region, you can obtain a pointer to a task
|
||||
embedded in a map value without having to acquire a reference:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
#define private(name) SEC(".data." #name) __hidden __attribute__((aligned(8)))
|
||||
private(TASK) static struct task_struct *global;
|
||||
|
||||
/**
|
||||
* A trivial example showing how to access a task stored
|
||||
* in a map using RCU.
|
||||
*/
|
||||
SEC("tp_btf/task_newtask")
|
||||
int BPF_PROG(task_rcu_read_example, struct task_struct *task, u64 clone_flags)
|
||||
{
|
||||
struct task_struct *local_copy;
|
||||
|
||||
bpf_rcu_read_lock();
|
||||
local_copy = global;
|
||||
if (local_copy)
|
||||
/*
|
||||
* We could also pass local_copy to kfuncs or helper functions here,
|
||||
* as we're guaranteed that local_copy will be valid until we exit
|
||||
* the RCU read region below.
|
||||
*/
|
||||
bpf_printk("Global task %s is valid", local_copy->comm);
|
||||
else
|
||||
bpf_printk("No global task found");
|
||||
bpf_rcu_read_unlock();
|
||||
|
||||
/* At this point we can no longer reference local_copy. */
|
||||
|
||||
/*
|
||||
* In a typical program you'd do something like store
|
||||
* the task in a map, and the map will automatically
|
||||
* release it later. Here, we release it manually.
|
||||
*/
|
||||
bpf_task_release(acquired);
|
||||
return 0;
|
||||
}
|
||||
|
||||
@@ -515,81 +563,17 @@ bpf_task_release() respectively, so we won't provide examples for them.
|
||||
|
||||
----
|
||||
|
||||
You may also acquire a reference to a ``struct cgroup`` kptr that's already
|
||||
stored in a map using bpf_cgroup_kptr_get():
|
||||
|
||||
.. kernel-doc:: kernel/bpf/helpers.c
|
||||
:identifiers: bpf_cgroup_kptr_get
|
||||
|
||||
Here's an example of how it can be used:
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* struct containing the struct task_struct kptr which is actually stored in the map. */
|
||||
struct __cgroups_kfunc_map_value {
|
||||
struct cgroup __kptr_ref * cgroup;
|
||||
};
|
||||
|
||||
/* The map containing struct __cgroups_kfunc_map_value entries. */
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_HASH);
|
||||
__type(key, int);
|
||||
__type(value, struct __cgroups_kfunc_map_value);
|
||||
__uint(max_entries, 1);
|
||||
} __cgroups_kfunc_map SEC(".maps");
|
||||
|
||||
/* ... */
|
||||
|
||||
/**
|
||||
* A simple example tracepoint program showing how a
|
||||
* struct cgroup kptr that is stored in a map can
|
||||
* be acquired using the bpf_cgroup_kptr_get() kfunc.
|
||||
*/
|
||||
SEC("tp_btf/cgroup_mkdir")
|
||||
int BPF_PROG(cgroup_kptr_get_example, struct cgroup *cgrp, const char *path)
|
||||
{
|
||||
struct cgroup *kptr;
|
||||
struct __cgroups_kfunc_map_value *v;
|
||||
s32 id = cgrp->self.id;
|
||||
|
||||
/* Assume a cgroup kptr was previously stored in the map. */
|
||||
v = bpf_map_lookup_elem(&__cgroups_kfunc_map, &id);
|
||||
if (!v)
|
||||
return -ENOENT;
|
||||
|
||||
/* Acquire a reference to the cgroup kptr that's already stored in the map. */
|
||||
kptr = bpf_cgroup_kptr_get(&v->cgroup);
|
||||
if (!kptr)
|
||||
/* If no cgroup was present in the map, it's because
|
||||
* we're racing with another CPU that removed it with
|
||||
* bpf_kptr_xchg() between the bpf_map_lookup_elem()
|
||||
* above, and our call to bpf_cgroup_kptr_get().
|
||||
* bpf_cgroup_kptr_get() internally safely handles this
|
||||
* race, and will return NULL if the task is no longer
|
||||
* present in the map by the time we invoke the kfunc.
|
||||
*/
|
||||
return -EBUSY;
|
||||
|
||||
/* Free the reference we just took above. Note that the
|
||||
* original struct cgroup kptr is still in the map. It will
|
||||
* be freed either at a later time if another context deletes
|
||||
* it from the map, or automatically by the BPF subsystem if
|
||||
* it's still present when the map is destroyed.
|
||||
*/
|
||||
bpf_cgroup_release(kptr);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
----
|
||||
|
||||
Another kfunc available for interacting with ``struct cgroup *`` objects is
|
||||
bpf_cgroup_ancestor(). This allows callers to access the ancestor of a cgroup,
|
||||
and return it as a cgroup kptr.
|
||||
Other kfuncs available for interacting with ``struct cgroup *`` objects are
|
||||
bpf_cgroup_ancestor() and bpf_cgroup_from_id(), allowing callers to access
|
||||
the ancestor of a cgroup and find a cgroup by its ID, respectively. Both
|
||||
return a cgroup kptr.
|
||||
|
||||
.. kernel-doc:: kernel/bpf/helpers.c
|
||||
:identifiers: bpf_cgroup_ancestor
|
||||
|
||||
.. kernel-doc:: kernel/bpf/helpers.c
|
||||
:identifiers: bpf_cgroup_from_id
|
||||
|
||||
Eventually, BPF should be updated to allow this to happen with a normal memory
|
||||
load in the program itself. This is currently not possible without more work in
|
||||
the verifier. bpf_cgroup_ancestor() can be used as follows:
|
||||
|
||||
@@ -2,23 +2,32 @@
|
||||
|
||||
.. _libbpf:
|
||||
|
||||
======
|
||||
libbpf
|
||||
======
|
||||
|
||||
If you are looking to develop BPF applications using the libbpf library, this
|
||||
directory contains important documentation that you should read.
|
||||
|
||||
To get started, it is recommended to begin with the :doc:`libbpf Overview
|
||||
<libbpf_overview>` document, which provides a high-level understanding of the
|
||||
libbpf APIs and their usage. This will give you a solid foundation to start
|
||||
exploring and utilizing the various features of libbpf to develop your BPF
|
||||
applications.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
libbpf_overview
|
||||
API Documentation <https://libbpf.readthedocs.io/en/latest/api.html>
|
||||
program_types
|
||||
libbpf_naming_convention
|
||||
libbpf_build
|
||||
|
||||
This is documentation for libbpf, a userspace library for loading and
|
||||
interacting with bpf programs.
|
||||
|
||||
All general BPF questions, including kernel functionality, libbpf APIs and
|
||||
their application, should be sent to bpf@vger.kernel.org mailing list.
|
||||
You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the
|
||||
mailing list search its `archive <https://lore.kernel.org/bpf/>`_.
|
||||
Please search the archive before asking new questions. It very well might
|
||||
be that this was already addressed or answered before.
|
||||
All general BPF questions, including kernel functionality, libbpf APIs and their
|
||||
application, should be sent to bpf@vger.kernel.org mailing list. You can
|
||||
`subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the mailing list
|
||||
search its `archive <https://lore.kernel.org/bpf/>`_. Please search the archive
|
||||
before asking new questions. It may be that this was already addressed or
|
||||
answered before.
|
||||
|
||||
@@ -0,0 +1,228 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===============
|
||||
libbpf Overview
|
||||
===============
|
||||
|
||||
libbpf is a C-based library containing a BPF loader that takes compiled BPF
|
||||
object files and prepares and loads them into the Linux kernel. libbpf takes the
|
||||
heavy lifting of loading, verifying, and attaching BPF programs to various
|
||||
kernel hooks, allowing BPF application developers to focus only on BPF program
|
||||
correctness and performance.
|
||||
|
||||
The following are the high-level features supported by libbpf:
|
||||
|
||||
* Provides high-level and low-level APIs for user space programs to interact
|
||||
with BPF programs. The low-level APIs wrap all the bpf system call
|
||||
functionality, which is useful when users need more fine-grained control
|
||||
over the interactions between user space and BPF programs.
|
||||
* Provides overall support for the BPF object skeleton generated by bpftool.
|
||||
The skeleton file simplifies the process for the user space programs to access
|
||||
global variables and work with BPF programs.
|
||||
* Provides BPF-side APIS, including BPF helper definitions, BPF maps support,
|
||||
and tracing helpers, allowing developers to simplify BPF code writing.
|
||||
* Supports BPF CO-RE mechanism, enabling BPF developers to write portable
|
||||
BPF programs that can be compiled once and run across different kernel
|
||||
versions.
|
||||
|
||||
This document will delve into the above concepts in detail, providing a deeper
|
||||
understanding of the capabilities and advantages of libbpf and how it can help
|
||||
you develop BPF applications efficiently.
|
||||
|
||||
BPF App Lifecycle and libbpf APIs
|
||||
==================================
|
||||
|
||||
A BPF application consists of one or more BPF programs (either cooperating or
|
||||
completely independent), BPF maps, and global variables. The global
|
||||
variables are shared between all BPF programs, which allows them to cooperate on
|
||||
a common set of data. libbpf provides APIs that user space programs can use to
|
||||
manipulate the BPF programs by triggering different phases of a BPF application
|
||||
lifecycle.
|
||||
|
||||
The following section provides a brief overview of each phase in the BPF life
|
||||
cycle:
|
||||
|
||||
* **Open phase**: In this phase, libbpf parses the BPF
|
||||
object file and discovers BPF maps, BPF programs, and global variables. After
|
||||
a BPF app is opened, user space apps can make additional adjustments
|
||||
(setting BPF program types, if necessary; pre-setting initial values for
|
||||
global variables, etc.) before all the entities are created and loaded.
|
||||
|
||||
* **Load phase**: In the load phase, libbpf creates BPF
|
||||
maps, resolves various relocations, and verifies and loads BPF programs into
|
||||
the kernel. At this point, libbpf validates all the parts of a BPF application
|
||||
and loads the BPF program into the kernel, but no BPF program has yet been
|
||||
executed. After the load phase, it’s possible to set up the initial BPF map
|
||||
state without racing with the BPF program code execution.
|
||||
|
||||
* **Attachment phase**: In this phase, libbpf
|
||||
attaches BPF programs to various BPF hook points (e.g., tracepoints, kprobes,
|
||||
cgroup hooks, network packet processing pipeline, etc.). During this
|
||||
phase, BPF programs perform useful work such as processing
|
||||
packets, or updating BPF maps and global variables that can be read from user
|
||||
space.
|
||||
|
||||
* **Tear down phase**: In the tear down phase,
|
||||
libbpf detaches BPF programs and unloads them from the kernel. BPF maps are
|
||||
destroyed, and all the resources used by the BPF app are freed.
|
||||
|
||||
BPF Object Skeleton File
|
||||
========================
|
||||
|
||||
BPF skeleton is an alternative interface to libbpf APIs for working with BPF
|
||||
objects. Skeleton code abstract away generic libbpf APIs to significantly
|
||||
simplify code for manipulating BPF programs from user space. Skeleton code
|
||||
includes a bytecode representation of the BPF object file, simplifying the
|
||||
process of distributing your BPF code. With BPF bytecode embedded, there are no
|
||||
extra files to deploy along with your application binary.
|
||||
|
||||
You can generate the skeleton header file ``(.skel.h)`` for a specific object
|
||||
file by passing the BPF object to the bpftool. The generated BPF skeleton
|
||||
provides the following custom functions that correspond to the BPF lifecycle,
|
||||
each of them prefixed with the specific object name:
|
||||
|
||||
* ``<name>__open()`` – creates and opens BPF application (``<name>`` stands for
|
||||
the specific bpf object name)
|
||||
* ``<name>__load()`` – instantiates, loads,and verifies BPF application parts
|
||||
* ``<name>__attach()`` – attaches all auto-attachable BPF programs (it’s
|
||||
optional, you can have more control by using libbpf APIs directly)
|
||||
* ``<name>__destroy()`` – detaches all BPF programs and
|
||||
frees up all used resources
|
||||
|
||||
Using the skeleton code is the recommended way to work with bpf programs. Keep
|
||||
in mind, BPF skeleton provides access to the underlying BPF object, so whatever
|
||||
was possible to do with generic libbpf APIs is still possible even when the BPF
|
||||
skeleton is used. It's an additive convenience feature, with no syscalls, and no
|
||||
cumbersome code.
|
||||
|
||||
Other Advantages of Using Skeleton File
|
||||
---------------------------------------
|
||||
|
||||
* BPF skeleton provides an interface for user space programs to work with BPF
|
||||
global variables. The skeleton code memory maps global variables as a struct
|
||||
into user space. The struct interface allows user space programs to initialize
|
||||
BPF programs before the BPF load phase and fetch and update data from user
|
||||
space afterward.
|
||||
|
||||
* The ``skel.h`` file reflects the object file structure by listing out the
|
||||
available maps, programs, etc. BPF skeleton provides direct access to all the
|
||||
BPF maps and BPF programs as struct fields. This eliminates the need for
|
||||
string-based lookups with ``bpf_object_find_map_by_name()`` and
|
||||
``bpf_object_find_program_by_name()`` APIs, reducing errors due to BPF source
|
||||
code and user-space code getting out of sync.
|
||||
|
||||
* The embedded bytecode representation of the object file ensures that the
|
||||
skeleton and the BPF object file are always in sync.
|
||||
|
||||
BPF Helpers
|
||||
===========
|
||||
|
||||
libbpf provides BPF-side APIs that BPF programs can use to interact with the
|
||||
system. The BPF helpers definition allows developers to use them in BPF code as
|
||||
any other plain C function. For example, there are helper functions to print
|
||||
debugging messages, get the time since the system was booted, interact with BPF
|
||||
maps, manipulate network packets, etc.
|
||||
|
||||
For a complete description of what the helpers do, the arguments they take, and
|
||||
the return value, see the `bpf-helpers
|
||||
<https://man7.org/linux/man-pages/man7/bpf-helpers.7.html>`_ man page.
|
||||
|
||||
BPF CO-RE (Compile Once – Run Everywhere)
|
||||
=========================================
|
||||
|
||||
BPF programs work in the kernel space and have access to kernel memory and data
|
||||
structures. One limitation that BPF applications come across is the lack of
|
||||
portability across different kernel versions and configurations. `BCC
|
||||
<https://github.com/iovisor/bcc/>`_ is one of the solutions for BPF
|
||||
portability. However, it comes with runtime overhead and a large binary size
|
||||
from embedding the compiler with the application.
|
||||
|
||||
libbpf steps up the BPF program portability by supporting the BPF CO-RE concept.
|
||||
BPF CO-RE brings together BTF type information, libbpf, and the compiler to
|
||||
produce a single executable binary that you can run on multiple kernel versions
|
||||
and configurations.
|
||||
|
||||
To make BPF programs portable libbpf relies on the BTF type information of the
|
||||
running kernel. Kernel also exposes this self-describing authoritative BTF
|
||||
information through ``sysfs`` at ``/sys/kernel/btf/vmlinux``.
|
||||
|
||||
You can generate the BTF information for the running kernel with the following
|
||||
command:
|
||||
|
||||
::
|
||||
|
||||
$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h
|
||||
|
||||
The command generates a ``vmlinux.h`` header file with all kernel types
|
||||
(:doc:`BTF types <../btf>`) that the running kernel uses. Including
|
||||
``vmlinux.h`` in your BPF program eliminates dependency on system-wide kernel
|
||||
headers.
|
||||
|
||||
libbpf enables portability of BPF programs by looking at the BPF program’s
|
||||
recorded BTF type and relocation information and matching them to BTF
|
||||
information (vmlinux) provided by the running kernel. libbpf then resolves and
|
||||
matches all the types and fields, and updates necessary offsets and other
|
||||
relocatable data to ensure that BPF program’s logic functions correctly for a
|
||||
specific kernel on the host. BPF CO-RE concept thus eliminates overhead
|
||||
associated with BPF development and allows developers to write portable BPF
|
||||
applications without modifications and runtime source code compilation on the
|
||||
target machine.
|
||||
|
||||
The following code snippet shows how to read the parent field of a kernel
|
||||
``task_struct`` using BPF CO-RE and libbf. The basic helper to read a field in a
|
||||
CO-RE relocatable manner is ``bpf_core_read(dst, sz, src)``, which will read
|
||||
``sz`` bytes from the field referenced by ``src`` into the memory pointed to by
|
||||
``dst``.
|
||||
|
||||
.. code-block:: C
|
||||
:emphasize-lines: 6
|
||||
|
||||
//...
|
||||
struct task_struct *task = (void *)bpf_get_current_task();
|
||||
struct task_struct *parent_task;
|
||||
int err;
|
||||
|
||||
err = bpf_core_read(&parent_task, sizeof(void *), &task->parent);
|
||||
if (err) {
|
||||
/* handle error */
|
||||
}
|
||||
|
||||
/* parent_task contains the value of task->parent pointer */
|
||||
|
||||
In the code snippet, we first get a pointer to the current ``task_struct`` using
|
||||
``bpf_get_current_task()``. We then use ``bpf_core_read()`` to read the parent
|
||||
field of task struct into the ``parent_task`` variable. ``bpf_core_read()`` is
|
||||
just like ``bpf_probe_read_kernel()`` BPF helper, except it records information
|
||||
about the field that should be relocated on the target kernel. i.e, if the
|
||||
``parent`` field gets shifted to a different offset within
|
||||
``struct task_struct`` due to some new field added in front of it, libbpf will
|
||||
automatically adjust the actual offset to the proper value.
|
||||
|
||||
Getting Started with libbpf
|
||||
===========================
|
||||
|
||||
Check out the `libbpf-bootstrap <https://github.com/libbpf/libbpf-bootstrap>`_
|
||||
repository with simple examples of using libbpf to build various BPF
|
||||
applications.
|
||||
|
||||
See also `libbpf API documentation
|
||||
<https://libbpf.readthedocs.io/en/latest/api.html>`_.
|
||||
|
||||
libbpf and Rust
|
||||
===============
|
||||
|
||||
If you are building BPF applications in Rust, it is recommended to use the
|
||||
`Libbpf-rs <https://github.com/libbpf/libbpf-rs>`_ library instead of bindgen
|
||||
bindings directly to libbpf. Libbpf-rs wraps libbpf functionality in
|
||||
Rust-idiomatic interfaces and provides libbpf-cargo plugin to handle BPF code
|
||||
compilation and skeleton generation. Using Libbpf-rs will make building user
|
||||
space part of the BPF application easier. Note that the BPF program themselves
|
||||
must still be written in plain C.
|
||||
|
||||
Additional Documentation
|
||||
========================
|
||||
|
||||
* `Program types and ELF Sections <https://libbpf.readthedocs.io/en/latest/program_types.html>`_
|
||||
* `API naming convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html>`_
|
||||
* `Building libbpf <https://libbpf.readthedocs.io/en/latest/libbpf_build.html>`_
|
||||
* `API documentation Convention <https://libbpf.readthedocs.io/en/latest/libbpf_naming_convention.html#api-documentation-convention>`_
|
||||
@@ -12,6 +12,36 @@ Byte swap instructions
|
||||
|
||||
``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and ``BPF_TO_BE`` respectively.
|
||||
|
||||
Jump instructions
|
||||
=================
|
||||
|
||||
``BPF_CALL | BPF_X | BPF_JMP`` (0x8d), where the helper function
|
||||
integer would be read from a specified register, is not currently supported
|
||||
by the verifier. Any programs with this instruction will fail to load
|
||||
until such support is added.
|
||||
|
||||
Maps
|
||||
====
|
||||
|
||||
Linux only supports the 'map_val(map)' operation on array maps with a single element.
|
||||
|
||||
Linux uses an fd_array to store maps associated with a BPF program. Thus,
|
||||
map_by_idx(imm) uses the fd at that index in the array.
|
||||
|
||||
Variables
|
||||
=========
|
||||
|
||||
The following 64-bit immediate instruction specifies that a variable address,
|
||||
which corresponds to some integer stored in the 'imm' field, should be loaded:
|
||||
|
||||
========================= ====== === ========================================= =========== ==============
|
||||
opcode construction opcode src pseudocode imm type dst type
|
||||
========================= ====== === ========================================= =========== ==============
|
||||
BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer
|
||||
========================= ====== === ========================================= =========== ==============
|
||||
|
||||
On Linux, this integer is a BTF ID.
|
||||
|
||||
Legacy BPF Packet access instructions
|
||||
=====================================
|
||||
|
||||
|
||||
@@ -11,9 +11,9 @@ maps are accessed from BPF programs via BPF helpers which are documented in the
|
||||
`man-pages`_ for `bpf-helpers(7)`_.
|
||||
|
||||
BPF maps are accessed from user space via the ``bpf`` syscall, which provides
|
||||
commands to create maps, lookup elements, update elements and delete
|
||||
elements. More details of the BPF syscall are available in
|
||||
:doc:`/userspace-api/ebpf/syscall` and in the `man-pages`_ for `bpf(2)`_.
|
||||
commands to create maps, lookup elements, update elements and delete elements.
|
||||
More details of the BPF syscall are available in `ebpf-syscall`_ and in the
|
||||
`man-pages`_ for `bpf(2)`_.
|
||||
|
||||
Map Types
|
||||
=========
|
||||
@@ -79,3 +79,4 @@ Find and delete element by key in a given map using ``attr->map_fd``,
|
||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||
.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
|
||||
.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
|
||||
.. _ebpf-syscall: https://docs.kernel.org/userspace-api/ebpf/syscall.html
|
||||
|
||||
@@ -19,7 +19,7 @@ rules:
|
||||
colons: {max-spaces-before: 0, max-spaces-after: 1}
|
||||
commas: {min-spaces-after: 1, max-spaces-after: 1}
|
||||
comments:
|
||||
require-starting-space: false
|
||||
require-starting-space: true
|
||||
min-spaces-from-content: 1
|
||||
comments-indentation: disable
|
||||
document-start:
|
||||
|
||||
@@ -144,6 +144,7 @@ patternProperties:
|
||||
it is stricter and always has two compatibles.
|
||||
type: object
|
||||
$ref: '/schemas/simple-bus.yaml'
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -30,6 +30,7 @@ properties:
|
||||
|
||||
clocks:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
@@ -47,6 +48,7 @@ properties:
|
||||
|
||||
reset:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
@@ -63,6 +65,7 @@ properties:
|
||||
|
||||
pwm:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
@@ -76,8 +79,6 @@ properties:
|
||||
- compatible
|
||||
- "#pwm-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- mboxes
|
||||
|
||||
@@ -141,6 +141,7 @@ properties:
|
||||
- arm,cortex-a77
|
||||
- arm,cortex-a78
|
||||
- arm,cortex-a78ae
|
||||
- arm,cortex-a78c
|
||||
- arm,cortex-a510
|
||||
- arm,cortex-a710
|
||||
- arm,cortex-a715
|
||||
@@ -153,6 +154,7 @@ properties:
|
||||
- arm,cortex-r5
|
||||
- arm,cortex-r7
|
||||
- arm,cortex-x1
|
||||
- arm,cortex-x1c
|
||||
- arm,cortex-x2
|
||||
- arm,cortex-x3
|
||||
- arm,neoverse-e1
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,infracfg.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Infrastructure System Configuration Controller
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mmsys.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek mmsys controller
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-pcie-mirror.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek PCIE Mirror Controller for MT7622
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7622-wed.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Wireless Ethernet Dispatch Controller for MT7622
|
||||
|
||||
@@ -20,6 +20,7 @@ properties:
|
||||
items:
|
||||
- enum:
|
||||
- mediatek,mt7622-wed
|
||||
- mediatek,mt7981-wed
|
||||
- mediatek,mt7986-wed
|
||||
- const: syscon
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt7986-wed-pcie.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt7986-wed-pcie.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek PCIE WED Controller for MT7986
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Functional Clock Controller for MT8186
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek System Clock Controller for MT8186
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Functional Clock Controller for MT8192
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-sys-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-sys-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek System Clock Controller for MT8192
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Functional Clock Controller for MT8195
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,mt8195-sys-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek System Clock Controller for MT8195
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/arm/mediatek/mediatek,pericfg.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Peripheral Configuration Controller
|
||||
|
||||
|
||||
@@ -1,27 +0,0 @@
|
||||
MediaTek SGMIISYS controller
|
||||
============================
|
||||
|
||||
The MediaTek SGMIISYS controller provides various clocks to the system.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Should be:
|
||||
- "mediatek,mt7622-sgmiisys", "syscon"
|
||||
- "mediatek,mt7629-sgmiisys", "syscon"
|
||||
- "mediatek,mt7981-sgmiisys_0", "syscon"
|
||||
- "mediatek,mt7981-sgmiisys_1", "syscon"
|
||||
- "mediatek,mt7986-sgmiisys_0", "syscon"
|
||||
- "mediatek,mt7986-sgmiisys_1", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The SGMIISYS controller uses the common clk binding from
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
||||
|
||||
Example:
|
||||
|
||||
sgmiisys: sgmiisys@1b128000 {
|
||||
compatible = "mediatek,mt7622-sgmiisys", "syscon";
|
||||
reg = <0 0x1b128000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
@@ -20,6 +20,7 @@ properties:
|
||||
- st,stm32-syscfg
|
||||
- st,stm32-power-config
|
||||
- st,stm32-tamp
|
||||
- st,stm32f4-gcan
|
||||
- const: syscon
|
||||
- items:
|
||||
- const: st,stm32-tamp
|
||||
@@ -42,6 +43,7 @@ if:
|
||||
contains:
|
||||
enum:
|
||||
- st,stm32mp157-syscfg
|
||||
- st,stm32f4-gcan
|
||||
then:
|
||||
required:
|
||||
- clocks
|
||||
|
||||
@@ -234,6 +234,7 @@ properties:
|
||||
patternProperties:
|
||||
"^[a-z0-9]+$":
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
clocks:
|
||||
@@ -252,6 +253,9 @@ properties:
|
||||
for controlling a power-gate.
|
||||
See ../reset/reset.txt for more details.
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 0
|
||||
description: Must be 0.
|
||||
|
||||
@@ -59,7 +59,7 @@ properties:
|
||||
const: sata-phy
|
||||
|
||||
hba-cap:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Bitfield of the HBA generic platform capabilities like Staggered
|
||||
Spin-up or Mechanical Presence Switch support. It can be used to
|
||||
@@ -67,7 +67,7 @@ properties:
|
||||
in case if the system firmware hasn't done it.
|
||||
|
||||
ports-implemented:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Mask that indicates which ports the HBA supports. Useful if PI is not
|
||||
programmed by the BIOS, which is true for some embedded SoC's.
|
||||
@@ -110,7 +110,7 @@ $defs:
|
||||
description: Power regulator for SATA port target device
|
||||
|
||||
hba-port-cap:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
Bitfield of the HBA port-specific platform capabilities like Hot
|
||||
plugging, eSATA, FIS-based Switching, etc (see AHCI specification
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas R-Car Serial-ATA Interface
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ examples:
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/input/input.h>
|
||||
#include <dt-bindings/leds/common.h>
|
||||
i2c1 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -46,6 +46,7 @@ patternProperties:
|
||||
# All other properties should be child nodes with unit-address and 'reg'
|
||||
"^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -45,6 +45,7 @@ properties:
|
||||
patternProperties:
|
||||
"^.*@[0-9a-fA-F]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -36,6 +36,7 @@ patternProperties:
|
||||
# All other properties should be child nodes with unit-address and 'reg'
|
||||
"@[0-9a-f]+$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
# Copyright (C) 2020 BAIKAL ELECTRONICS, JSC
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/memory-controllers/baikal,bt1-l2-ctl.yaml#
|
||||
$id: http://devicetree.org/schemas/cache/baikal,bt1-l2-ctl.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Baikal-T1 L2-cache Control Block
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/l2c2x0.yaml#
|
||||
$id: http://devicetree.org/schemas/cache/l2c2x0.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM L2 Cache Controller
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/msm/qcom,llcc.yaml#
|
||||
$id: http://devicetree.org/schemas/cache/qcom,llcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Last Level Cache Controller
|
||||
+1
-1
@@ -2,7 +2,7 @@
|
||||
# Copyright (C) 2020 SiFive, Inc.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/riscv/sifive,ccache0.yaml#
|
||||
$id: http://devicetree.org/schemas/cache/sifive,ccache0.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: SiFive Composable Cache Controller
|
||||
+1
-1
@@ -1,7 +1,7 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/socionext/socionext,uniphier-system-cache.yaml#
|
||||
$id: http://devicetree.org/schemas/cache/socionext,uniphier-system-cache.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: UniPhier outer cache controller
|
||||
@@ -41,7 +41,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |+
|
||||
spi0 {
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
spi0 {
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -81,11 +81,11 @@ properties:
|
||||
maxItems: 1
|
||||
|
||||
lock-offset:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Offset to the unlocking register for the oscillator
|
||||
|
||||
vco-offset:
|
||||
$ref: '/schemas/types.yaml#/definitions/uint32'
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: Offset to the VCO register for the oscillator
|
||||
deprecated: true
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/mediatek,apmixedsys.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek AP Mixedsys Controller
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/mediatek,topckgen.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/mediatek,topckgen.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek Top Clock Generator Controller
|
||||
|
||||
|
||||
@@ -45,14 +45,14 @@ required:
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
#Example 1 - A53 PLL found on MSM8916 devices
|
||||
# Example 1 - A53 PLL found on MSM8916 devices
|
||||
- |
|
||||
a53pll: clock@b016000 {
|
||||
compatible = "qcom,msm8916-a53pll";
|
||||
reg = <0xb016000 0x40>;
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
#Example 2 - A53 PLL found on IPQ6018 devices
|
||||
# Example 2 - A53 PLL found on IPQ6018 devices
|
||||
- |
|
||||
a53pll_ipq: clock-controller@b116000 {
|
||||
compatible = "qcom,ipq6018-a53pll";
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/renesas,cpg-mssr.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas Clock Pulse Generator / Module Standby and Software Reset
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/renesas,rcar-usb2-clock-sel.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas R-Car USB 2.0 clock selector
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas RZ/{G2L,V2L,V2M} Clock Pulse Generator / Module Standby Mode
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ allOf:
|
||||
- description: External RTC clock (32768 Hz)
|
||||
- description: CMU_HSI bus clock (from CMU_TOP)
|
||||
- description: SD card clock (from CMU_TOP)
|
||||
- description: "USB 2.0 DRD clock (from CMU_TOP)"
|
||||
- description: USB 2.0 DRD clock (from CMU_TOP)
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
# Copyright 2019 Unisoc Inc.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/sprd,sc9863a-clk.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/sprd,sc9863a-clk.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: SC9863A Clock Control Unit
|
||||
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
# Copyright 2022 Unisoc Inc.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/sprd,ums512-clk.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: UMS512 Soc clock controller
|
||||
|
||||
|
||||
@@ -160,7 +160,7 @@ examples:
|
||||
};
|
||||
};
|
||||
|
||||
spi0 {
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/clock/xlnx,clocking-wizard.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
$id: http://devicetree.org/schemas/clock/xlnx,clocking-wizard.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Xilinx clocking wizard
|
||||
|
||||
|
||||
@@ -0,0 +1,156 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
# Copyright (C) 2008-2011 Freescale Semiconductor Inc.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/fsl,sec-v4.0-mon.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Freescale Secure Non-Volatile Storage (SNVS)
|
||||
|
||||
maintainers:
|
||||
- '"Horia Geantă" <horia.geanta@nxp.com>'
|
||||
- Pankaj Gupta <pankaj.gupta@nxp.com>
|
||||
- Gaurav Jain <gaurav.jain@nxp.com>
|
||||
|
||||
description:
|
||||
Node defines address range and the associated interrupt for the SNVS function.
|
||||
This function monitors security state information & reports security
|
||||
violations. This also included rtc, system power off and ON/OFF key.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: fsl,sec-v4.0-mon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: fsl,sec-v5.0-mon
|
||||
- const: fsl,sec-v4.0-mon
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,sec-v5.3-mon
|
||||
- fsl,sec-v5.4-mon
|
||||
- const: fsl,sec-v5.0-mon
|
||||
- const: fsl,sec-v4.0-mon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 2
|
||||
|
||||
snvs-rtc-lp:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
description:
|
||||
Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: fsl,sec-v4.0-mon-rtc-lp
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
const: snvs-rtc
|
||||
|
||||
interrupts:
|
||||
# VFxxx has only one. What is the 2nd one?
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
regmap:
|
||||
description: Parent node containing registers
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
offset:
|
||||
description: LP register offset
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
default: 0x34
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- interrupts
|
||||
- regmap
|
||||
|
||||
snvs-powerkey:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
description:
|
||||
The snvs-pwrkey is designed to enable POWER key function which controlled
|
||||
by SNVS ONOFF, the driver can report the status of POWER key and wakeup
|
||||
system if pressed after system suspend.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: fsl,sec-v4.0-pwrkey
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
const: snvs-pwrkey
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
regmap:
|
||||
description: Parent node containing registers
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
linux,keycode:
|
||||
default: 116
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- interrupts
|
||||
- regmap
|
||||
|
||||
snvs-lpgpr:
|
||||
$ref: /schemas/nvmem/snvs-lpgpr.yaml#
|
||||
|
||||
snvs-poweroff:
|
||||
description:
|
||||
The SNVS could drive signal to PMIC to turn off system power by setting
|
||||
SNVS_LP LPCR register.
|
||||
$ref: /schemas/power/reset/syscon-poweroff.yaml#
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/imx7d-clock.h>
|
||||
|
||||
sec_mon: sec-mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon", "syscon", "simple-mfd";
|
||||
reg = <0x314000 0x1000>;
|
||||
|
||||
snvs-rtc-lp {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
regmap = <&sec_mon>;
|
||||
offset = <0x34>;
|
||||
clocks = <&clks IMX7D_SNVS_CLK>;
|
||||
clock-names = "snvs-rtc";
|
||||
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
||||
snvs-powerkey {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&sec_mon>;
|
||||
clocks = <&clks IMX7D_SNVS_CLK>;
|
||||
clock-names = "snvs-pwrkey";
|
||||
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup-source;
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,266 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
# Copyright (C) 2008-2011 Freescale Semiconductor Inc.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/crypto/fsl,sec-v4.0.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Freescale SEC 4
|
||||
|
||||
maintainers:
|
||||
- '"Horia Geantă" <horia.geanta@nxp.com>'
|
||||
- Pankaj Gupta <pankaj.gupta@nxp.com>
|
||||
- Gaurav Jain <gaurav.jain@nxp.com>
|
||||
|
||||
description: |
|
||||
NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
|
||||
Accelerator and Assurance Module (CAAM).
|
||||
|
||||
SEC 4 h/w can process requests from 2 types of sources.
|
||||
1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4).
|
||||
2. Job Rings (HW interface between cores & SEC 4 registers).
|
||||
|
||||
High Speed Data Path Configuration:
|
||||
|
||||
HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts
|
||||
such as the P4080. The number of simultaneous dequeues the QI can make is
|
||||
equal to the number of Descriptor Controller (DECO) engines in a particular
|
||||
SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus
|
||||
dequeue from 5 subportals simultaneously.
|
||||
|
||||
Job Ring Data Path Configuration:
|
||||
|
||||
Each JR is located on a separate 4k page, they may (or may not) be made visible
|
||||
in the memory partition devoted to a particular core. The P4080 has 4 JRs, so
|
||||
up to 4 JRs can be configured; and all 4 JRs process requests in parallel.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: fsl,sec-v5.4
|
||||
- const: fsl,sec-v5.0
|
||||
- const: fsl,sec-v4.0
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx6ul-caam
|
||||
- fsl,sec-v5.0
|
||||
- const: fsl,sec-v4.0
|
||||
- const: fsl,sec-v4.0
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
ranges:
|
||||
maxItems: 1
|
||||
|
||||
'#address-cells':
|
||||
enum: [1, 2]
|
||||
|
||||
'#size-cells':
|
||||
enum: [1, 2]
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
items:
|
||||
enum: [mem, aclk, ipg, emi_slow]
|
||||
|
||||
dma-coherent: true
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
fsl,sec-era:
|
||||
description: Defines the 'ERA' of the SEC device.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
patternProperties:
|
||||
'^jr@[0-9a-f]+$':
|
||||
type: object
|
||||
additionalProperties: false
|
||||
description:
|
||||
Job Ring (JR) Node. Defines data processing interface to SEC 4 across the
|
||||
peripheral bus for purposes of processing cryptographic descriptors. The
|
||||
specified address range can be made visible to one (or more) cores. The
|
||||
interrupt defined for this node is controlled within the address range of
|
||||
this node.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: fsl,sec-v5.4-job-ring
|
||||
- const: fsl,sec-v5.0-job-ring
|
||||
- const: fsl,sec-v4.0-job-ring
|
||||
- items:
|
||||
- const: fsl,sec-v5.0-job-ring
|
||||
- const: fsl,sec-v4.0-job-ring
|
||||
- const: fsl,sec-v4.0-job-ring
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
fsl,liodn:
|
||||
description:
|
||||
Specifies the LIODN to be used in conjunction with the ppid-to-liodn
|
||||
table that specifies the PPID to LIODN mapping. Needed if the PAMU is
|
||||
used. Value is a 12 bit value where value is a LIODN ID for this JR.
|
||||
This property is normally set by boot firmware.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
maximum: 0xfff
|
||||
|
||||
'^rtic@[0-9a-f]+$':
|
||||
type: object
|
||||
additionalProperties: false
|
||||
description:
|
||||
Run Time Integrity Check (RTIC) Node. Defines a register space that
|
||||
contains up to 5 sets of addresses and their lengths (sizes) that will be
|
||||
checked at run time. After an initial hash result is calculated, these
|
||||
addresses are checked by HW to monitor any change. If any memory is
|
||||
modified, a Security Violation is triggered (see SNVS definition).
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: fsl,sec-v5.4-rtic
|
||||
- const: fsl,sec-v5.0-rtic
|
||||
- const: fsl,sec-v4.0-rtic
|
||||
- const: fsl,sec-v4.0-rtic
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
ranges:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
'#address-cells':
|
||||
const: 1
|
||||
|
||||
'#size-cells':
|
||||
const: 1
|
||||
|
||||
patternProperties:
|
||||
'^rtic-[a-z]@[0-9a-f]+$':
|
||||
type: object
|
||||
additionalProperties: false
|
||||
description:
|
||||
Run Time Integrity Check (RTIC) Memory Node defines individual RTIC
|
||||
memory regions that are used to perform run-time integrity check of
|
||||
memory areas that should not modified. The node defines a register
|
||||
that contains the memory address & length (combined) and a second
|
||||
register that contains the hash result in big endian format.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: fsl,sec-v5.4-rtic-memory
|
||||
- const: fsl,sec-v5.0-rtic-memory
|
||||
- const: fsl,sec-v4.0-rtic-memory
|
||||
- const: fsl,sec-v4.0-rtic-memory
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: RTIC memory address
|
||||
- description: RTIC hash result
|
||||
|
||||
fsl,liodn:
|
||||
description:
|
||||
Specifies the LIODN to be used in conjunction with the
|
||||
ppid-to-liodn table that specifies the PPID to LIODN mapping.
|
||||
Needed if the PAMU is used. Value is a 12 bit value where value
|
||||
is a LIODN ID for this JR. This property is normally set by boot
|
||||
firmware.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
maximum: 0xfff
|
||||
|
||||
fsl,rtic-region:
|
||||
description:
|
||||
Specifies the HW address (36 bit address) for this region
|
||||
followed by the length of the HW partition to be checked;
|
||||
the address is represented as a 64 bit quantity followed
|
||||
by a 32 bit length.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- ranges
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
crypto@300000 {
|
||||
compatible = "fsl,sec-v4.0";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x300000 0x10000>;
|
||||
ranges = <0 0x300000 0x10000>;
|
||||
interrupts = <92 2>;
|
||||
|
||||
jr@1000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x1000 0x1000>;
|
||||
interrupts = <88 2>;
|
||||
};
|
||||
|
||||
jr@2000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x2000 0x1000>;
|
||||
interrupts = <89 2>;
|
||||
};
|
||||
|
||||
jr@3000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x3000 0x1000>;
|
||||
interrupts = <90 2>;
|
||||
};
|
||||
|
||||
jr@4000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x4000 0x1000>;
|
||||
interrupts = <91 2>;
|
||||
};
|
||||
|
||||
rtic@6000 {
|
||||
compatible = "fsl,sec-v4.0-rtic";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x6000 0x100>;
|
||||
ranges = <0x0 0x6100 0xe00>;
|
||||
|
||||
rtic-a@0 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x00 0x20>, <0x100 0x80>;
|
||||
};
|
||||
|
||||
rtic-b@20 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x20 0x20>, <0x200 0x80>;
|
||||
};
|
||||
|
||||
rtic-c@40 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x40 0x20>, <0x300 0x80>;
|
||||
};
|
||||
|
||||
rtic-d@60 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x60 0x20>, <0x500 0x80>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
@@ -1,553 +0,0 @@
|
||||
=====================================================================
|
||||
SEC 4 Device Tree Binding
|
||||
Copyright (C) 2008-2011 Freescale Semiconductor Inc.
|
||||
|
||||
CONTENTS
|
||||
-Overview
|
||||
-SEC 4 Node
|
||||
-Job Ring Node
|
||||
-Run Time Integrity Check (RTIC) Node
|
||||
-Run Time Integrity Check (RTIC) Memory Node
|
||||
-Secure Non-Volatile Storage (SNVS) Node
|
||||
-Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
||||
-Full Example
|
||||
|
||||
NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator
|
||||
Accelerator and Assurance Module (CAAM).
|
||||
|
||||
=====================================================================
|
||||
Overview
|
||||
|
||||
DESCRIPTION
|
||||
|
||||
SEC 4 h/w can process requests from 2 types of sources.
|
||||
1. DPAA Queue Interface (HW interface between Queue Manager & SEC 4).
|
||||
2. Job Rings (HW interface between cores & SEC 4 registers).
|
||||
|
||||
High Speed Data Path Configuration:
|
||||
|
||||
HW interface between QM & SEC 4 and also BM & SEC 4, on DPAA-enabled parts
|
||||
such as the P4080. The number of simultaneous dequeues the QI can make is
|
||||
equal to the number of Descriptor Controller (DECO) engines in a particular
|
||||
SEC version. E.g., the SEC 4.0 in the P4080 has 5 DECOs and can thus
|
||||
dequeue from 5 subportals simultaneously.
|
||||
|
||||
Job Ring Data Path Configuration:
|
||||
|
||||
Each JR is located on a separate 4k page, they may (or may not) be made visible
|
||||
in the memory partition devoted to a particular core. The P4080 has 4 JRs, so
|
||||
up to 4 JRs can be configured; and all 4 JRs process requests in parallel.
|
||||
|
||||
=====================================================================
|
||||
SEC 4 Node
|
||||
|
||||
Description
|
||||
|
||||
Node defines the base address of the SEC 4 block.
|
||||
This block specifies the address range of all global
|
||||
configuration registers for the SEC 4 block. It
|
||||
also receives interrupts from the Run Time Integrity Check
|
||||
(RTIC) function within the SEC 4 block.
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0"
|
||||
|
||||
- fsl,sec-era
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Define the 'ERA' of the SEC
|
||||
device.
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing physical addresses in child nodes.
|
||||
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing the size of physical addresses in
|
||||
child nodes.
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SEC4 configuration registers.
|
||||
registers
|
||||
|
||||
- ranges
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
range of the SEC 4.0 register space (-SNVS not included). A
|
||||
triplet that includes the child address, parent address, &
|
||||
length.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
- clocks
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: A list of phandle and clock specifier pairs describing
|
||||
the clocks required for enabling and disabling SEC 4.0.
|
||||
|
||||
- clock-names
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <string>
|
||||
Definition: A list of clock name strings in the same order as the
|
||||
clocks property.
|
||||
|
||||
Note: All other standard properties (see the Devicetree Specification)
|
||||
are allowed but are optional.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
|
||||
iMX6QDL/SX requires four clocks
|
||||
|
||||
crypto@300000 {
|
||||
compatible = "fsl,sec-v4.0";
|
||||
fsl,sec-era = <2>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x300000 0x10000>;
|
||||
ranges = <0 0x300000 0x10000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <92 2>;
|
||||
clocks = <&clks IMX6QDL_CLK_CAAM_MEM>,
|
||||
<&clks IMX6QDL_CLK_CAAM_ACLK>,
|
||||
<&clks IMX6QDL_CLK_CAAM_IPG>,
|
||||
<&clks IMX6QDL_CLK_EIM_SLOW>;
|
||||
clock-names = "mem", "aclk", "ipg", "emi_slow";
|
||||
};
|
||||
|
||||
|
||||
iMX6UL does only require three clocks
|
||||
|
||||
crypto: crypto@2140000 {
|
||||
compatible = "fsl,sec-v4.0";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x2140000 0x3c000>;
|
||||
ranges = <0 0x2140000 0x3c000>;
|
||||
interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
clocks = <&clks IMX6UL_CLK_CAAM_MEM>,
|
||||
<&clks IMX6UL_CLK_CAAM_ACLK>,
|
||||
<&clks IMX6UL_CLK_CAAM_IPG>;
|
||||
clock-names = "mem", "aclk", "ipg";
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Job Ring (JR) Node
|
||||
|
||||
Child of the crypto node defines data processing interface to SEC 4
|
||||
across the peripheral bus for purposes of processing
|
||||
cryptographic descriptors. The specified address
|
||||
range can be made visible to one (or more) cores.
|
||||
The interrupt defined for this node is controlled within
|
||||
the address range of this node.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-job-ring"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: Specifies a two JR parameters: an offset from
|
||||
the parent physical address and the length the JR registers.
|
||||
|
||||
- fsl,liodn
|
||||
Usage: optional-but-recommended
|
||||
Value type: <prop-encoded-array>
|
||||
Definition:
|
||||
Specifies the LIODN to be used in conjunction with
|
||||
the ppid-to-liodn table that specifies the PPID to LIODN mapping.
|
||||
Needed if the PAMU is used. Value is a 12 bit value
|
||||
where value is a LIODN ID for this JR. This property is
|
||||
normally set by boot firmware.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
EXAMPLE
|
||||
jr@1000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x1000 0x1000>;
|
||||
fsl,liodn = <0x081>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <88 2>;
|
||||
};
|
||||
|
||||
|
||||
=====================================================================
|
||||
Run Time Integrity Check (RTIC) Node
|
||||
|
||||
Child node of the crypto node. Defines a register space that
|
||||
contains up to 5 sets of addresses and their lengths (sizes) that
|
||||
will be checked at run time. After an initial hash result is
|
||||
calculated, these addresses are checked by HW to monitor any
|
||||
change. If any memory is modified, a Security Violation is
|
||||
triggered (see SNVS definition).
|
||||
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-rtic".
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing physical addresses in child nodes. Must
|
||||
have a value of 1.
|
||||
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing the size of physical addresses in
|
||||
child nodes. Must have a value of 1.
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies a two parameters:
|
||||
an offset from the parent physical address and the length
|
||||
the SEC4 registers.
|
||||
|
||||
- ranges
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
range of the SEC 4 register space (-SNVS not included). A
|
||||
triplet that includes the child address, parent address, &
|
||||
length.
|
||||
|
||||
EXAMPLE
|
||||
rtic@6000 {
|
||||
compatible = "fsl,sec-v4.0-rtic";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x6000 0x100>;
|
||||
ranges = <0x0 0x6100 0xe00>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Run Time Integrity Check (RTIC) Memory Node
|
||||
A child node that defines individual RTIC memory regions that are used to
|
||||
perform run-time integrity check of memory areas that should not modified.
|
||||
The node defines a register that contains the memory address &
|
||||
length (combined) and a second register that contains the hash result
|
||||
in big endian format.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-rtic-memory".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies two parameters:
|
||||
an offset from the parent physical address and the length:
|
||||
|
||||
1. The location of the RTIC memory address & length registers.
|
||||
2. The location RTIC hash result.
|
||||
|
||||
- fsl,rtic-region
|
||||
Usage: optional-but-recommended
|
||||
Value type: <prop-encoded-array>
|
||||
Definition:
|
||||
Specifies the HW address (36 bit address) for this region
|
||||
followed by the length of the HW partition to be checked;
|
||||
the address is represented as a 64 bit quantity followed
|
||||
by a 32 bit length.
|
||||
|
||||
- fsl,liodn
|
||||
Usage: optional-but-recommended
|
||||
Value type: <prop-encoded-array>
|
||||
Definition:
|
||||
Specifies the LIODN to be used in conjunction with
|
||||
the ppid-to-liodn table that specifies the PPID to LIODN
|
||||
mapping. Needed if the PAMU is used. Value is a 12 bit value
|
||||
where value is a LIODN ID for this RTIC memory region. This
|
||||
property is normally set by boot firmware.
|
||||
|
||||
EXAMPLE
|
||||
rtic-a@0 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x00 0x20 0x100 0x80>;
|
||||
fsl,liodn = <0x03c>;
|
||||
fsl,rtic-region = <0x12345678 0x12345678 0x12345678>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Secure Non-Volatile Storage (SNVS) Node
|
||||
|
||||
Node defines address range and the associated
|
||||
interrupt for the SNVS function. This function
|
||||
monitors security state information & reports
|
||||
security violations. This also included rtc,
|
||||
system power off and ON/OFF key.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon" and "syscon".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SEC4 configuration
|
||||
registers.
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing physical addresses in child nodes. Must
|
||||
have a value of 1.
|
||||
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: A standard property. Defines the number of cells
|
||||
for representing the size of physical addresses in
|
||||
child nodes. Must have a value of 1.
|
||||
|
||||
- ranges
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical address
|
||||
range of the SNVS register space. A triplet that includes
|
||||
the child address, parent address, & length.
|
||||
|
||||
- interrupts
|
||||
Usage: optional
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
EXAMPLE
|
||||
sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon", "syscon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
||||
|
||||
A SNVS child node that defines SNVS LP RTC.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
- regmap
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
- offset
|
||||
Usage: option
|
||||
value type: <u32>
|
||||
Definition: LP register offset. default it is 0x34.
|
||||
|
||||
- clocks
|
||||
Usage: optional, required if SNVS LP RTC requires explicit
|
||||
enablement of clocks
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: a clock specifier describing the clock required for
|
||||
enabling and disabling SNVS LP RTC.
|
||||
|
||||
- clock-names
|
||||
Usage: optional, required if SNVS LP RTC requires explicit
|
||||
enablement of clocks
|
||||
Value type: <string>
|
||||
Definition: clock name string should be "snvs-rtc".
|
||||
|
||||
EXAMPLE
|
||||
sec_mon_rtc_lp@1 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
interrupts = <93 2>;
|
||||
regmap = <&snvs>;
|
||||
offset = <0x34>;
|
||||
clocks = <&clks IMX7D_SNVS_CLK>;
|
||||
clock-names = "snvs-rtc";
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
System ON/OFF key driver
|
||||
|
||||
The snvs-pwrkey is designed to enable POWER key function which controlled
|
||||
by SNVS ONOFF, the driver can report the status of POWER key and wakeup
|
||||
system if pressed after system suspend.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Mush include "fsl,sec-v4.0-pwrkey".
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: The SNVS ON/OFF interrupt number to the CPU(s).
|
||||
|
||||
- linux,keycode:
|
||||
Usage: option
|
||||
Value type: <int>
|
||||
Definition: Keycode to emit, KEY_POWER by default.
|
||||
|
||||
- wakeup-source:
|
||||
Usage: option
|
||||
Value type: <boo>
|
||||
Definition: Button can wake-up the system.
|
||||
|
||||
- regmap:
|
||||
Usage: required:
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
EXAMPLE:
|
||||
snvs-pwrkey@020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&snvs>;
|
||||
interrupts = <0 4 0x4>
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup-source;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
FULL EXAMPLE
|
||||
|
||||
crypto: crypto@300000 {
|
||||
compatible = "fsl,sec-v4.0";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x300000 0x10000>;
|
||||
ranges = <0 0x300000 0x10000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <92 2>;
|
||||
|
||||
sec_jr0: jr@1000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x1000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <88 2>;
|
||||
};
|
||||
|
||||
sec_jr1: jr@2000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x2000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <89 2>;
|
||||
};
|
||||
|
||||
sec_jr2: jr@3000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x3000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <90 2>;
|
||||
};
|
||||
|
||||
sec_jr3: jr@4000 {
|
||||
compatible = "fsl,sec-v4.0-job-ring";
|
||||
reg = <0x4000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <91 2>;
|
||||
};
|
||||
|
||||
rtic@6000 {
|
||||
compatible = "fsl,sec-v4.0-rtic";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
reg = <0x6000 0x100>;
|
||||
ranges = <0x0 0x6100 0xe00>;
|
||||
|
||||
rtic_a: rtic-a@0 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x00 0x20 0x100 0x80>;
|
||||
};
|
||||
|
||||
rtic_b: rtic-b@20 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x20 0x20 0x200 0x80>;
|
||||
};
|
||||
|
||||
rtic_c: rtic-c@40 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x40 0x20 0x300 0x80>;
|
||||
};
|
||||
|
||||
rtic_d: rtic-d@60 {
|
||||
compatible = "fsl,sec-v4.0-rtic-memory";
|
||||
reg = <0x60 0x20 0x500 0x80>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
sec_mon: sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
|
||||
sec_mon_rtc_lp@34 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
regmap = <&sec_mon>;
|
||||
offset = <0x34>;
|
||||
interrupts = <93 2>;
|
||||
clocks = <&clks IMX7D_SNVS_CLK>;
|
||||
clock-names = "snvs-rtc";
|
||||
};
|
||||
|
||||
snvs-pwrkey@020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&sec_mon>;
|
||||
interrupts = <0 4 0x4>;
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup-source;
|
||||
};
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
@@ -26,8 +26,8 @@ properties:
|
||||
dmas:
|
||||
items:
|
||||
- description: TX DMA Channel
|
||||
- description: RX DMA Channel #1
|
||||
- description: RX DMA Channel #2
|
||||
- description: 'RX DMA Channel #1'
|
||||
- description: 'RX DMA Channel #2'
|
||||
|
||||
dma-names:
|
||||
items:
|
||||
|
||||
@@ -16,8 +16,7 @@ description: |
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: analogix,anx7625
|
||||
const: analogix,anx7625
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
@@ -134,7 +133,7 @@ examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c0 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -61,7 +61,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c0 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c4 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@ examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c1 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/bridge/parade,ps8622.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Parade PS8622/PS8625 DisplayPort to LVDS Converter
|
||||
|
||||
maintainers:
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- parade,ps8622
|
||||
- parade,ps8625
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
lane-count:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [1, 2]
|
||||
description: Number of DP lanes to use.
|
||||
|
||||
use-external-pwm:
|
||||
type: boolean
|
||||
description: Backlight will be controlled by an external PWM.
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO connected to RST_ pin.
|
||||
|
||||
sleep-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO connected to PD_ pin.
|
||||
|
||||
vdd12-supply: true
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: Video port for LVDS output.
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: Video port for DisplayPort input.
|
||||
|
||||
required:
|
||||
- port@0
|
||||
- port@1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- reset-gpios
|
||||
- sleep-gpios
|
||||
- ports
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: parade,ps8622
|
||||
then:
|
||||
properties:
|
||||
lane-count:
|
||||
const: 1
|
||||
else:
|
||||
properties:
|
||||
lane-count:
|
||||
const: 2
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
lvds-bridge@48 {
|
||||
compatible = "parade,ps8625";
|
||||
reg = <0x48>;
|
||||
sleep-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpy7 7 GPIO_ACTIVE_HIGH>;
|
||||
lane-count = <2>;
|
||||
use-external-pwm;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
bridge_out: endpoint {
|
||||
remote-endpoint = <&panel_in>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
bridge_in: endpoint {
|
||||
remote-endpoint = <&dp_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -1,31 +0,0 @@
|
||||
ps8622-bridge bindings
|
||||
|
||||
Required properties:
|
||||
- compatible: "parade,ps8622" or "parade,ps8625"
|
||||
- reg: first i2c address of the bridge
|
||||
- sleep-gpios: OF device-tree gpio specification for PD_ pin.
|
||||
- reset-gpios: OF device-tree gpio specification for RST_ pin.
|
||||
|
||||
Optional properties:
|
||||
- lane-count: number of DP lanes to use
|
||||
- use-external-pwm: backlight will be controlled by an external PWM
|
||||
- video interfaces: Device node can contain video interface port
|
||||
nodes for panel according to [1].
|
||||
|
||||
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
||||
Example:
|
||||
lvds-bridge@48 {
|
||||
compatible = "parade,ps8622";
|
||||
reg = <0x48>;
|
||||
sleep-gpios = <&gpc3 6 1 0 0>;
|
||||
reset-gpios = <&gpc3 1 1 0 0>;
|
||||
lane-count = <1>;
|
||||
ports {
|
||||
port@0 {
|
||||
bridge_out: endpoint {
|
||||
remote-endpoint = <&panel_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -73,7 +73,7 @@ additionalProperties: false
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
i2c0 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@ examples:
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
i2c1 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -83,7 +83,7 @@ examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c1 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -90,7 +90,7 @@ properties:
|
||||
|
||||
properties:
|
||||
endpoint:
|
||||
$ref: /schemas/graph.yaml#/$defs/endpoint-base
|
||||
$ref: /schemas/media/video-interfaces.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
@@ -106,7 +106,6 @@ properties:
|
||||
description:
|
||||
If you have 1 logical lane the bridge supports routing
|
||||
to either port 0 or port 1. Port 0 is suggested.
|
||||
See ../../media/video-interface.txt for details.
|
||||
|
||||
- minItems: 2
|
||||
maxItems: 2
|
||||
@@ -118,7 +117,6 @@ properties:
|
||||
description:
|
||||
If you have 2 logical lanes the bridge supports
|
||||
reordering but only on physical ports 0 and 1.
|
||||
See ../../media/video-interface.txt for details.
|
||||
|
||||
- minItems: 4
|
||||
maxItems: 4
|
||||
@@ -132,7 +130,6 @@ properties:
|
||||
description:
|
||||
If you have 4 logical lanes the bridge supports
|
||||
reordering in any way.
|
||||
See ../../media/video-interface.txt for details.
|
||||
|
||||
lane-polarities:
|
||||
minItems: 1
|
||||
@@ -141,7 +138,6 @@ properties:
|
||||
enum:
|
||||
- 0
|
||||
- 1
|
||||
description: See ../../media/video-interface.txt
|
||||
|
||||
dependencies:
|
||||
lane-polarities: [data-lanes]
|
||||
|
||||
@@ -51,7 +51,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c1 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -1,35 +0,0 @@
|
||||
TC358764 MIPI-DSI to LVDS panel bridge
|
||||
|
||||
Required properties:
|
||||
- compatible: "toshiba,tc358764"
|
||||
- reg: the virtual channel number of a DSI peripheral
|
||||
- vddc-supply: core voltage supply, 1.2V
|
||||
- vddio-supply: I/O voltage supply, 1.8V or 3.3V
|
||||
- vddlvds-supply: LVDS1/2 voltage supply, 3.3V
|
||||
- reset-gpios: a GPIO spec for the reset pin
|
||||
|
||||
The device node can contain following 'port' child nodes,
|
||||
according to the OF graph bindings defined in [1]:
|
||||
0: DSI Input, not required, if the bridge is DSI controlled
|
||||
1: LVDS Output, mandatory
|
||||
|
||||
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
||||
Example:
|
||||
|
||||
bridge@0 {
|
||||
reg = <0>;
|
||||
compatible = "toshiba,tc358764";
|
||||
vddc-supply = <&vcc_1v2_reg>;
|
||||
vddio-supply = <&vcc_1v8_reg>;
|
||||
vddlvds-supply = <&vcc_3v3_reg>;
|
||||
reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
lvds_ep: endpoint {
|
||||
remote-endpoint = <&panel_ep>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -0,0 +1,89 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358764.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Toshiba TC358764 MIPI-DSI to LVDS bridge
|
||||
|
||||
maintainers:
|
||||
- Andrzej Hajda <andrzej.hajda@intel.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: toshiba,tc358764
|
||||
|
||||
reg:
|
||||
description: Virtual channel number of a DSI peripheral
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
vddc-supply:
|
||||
description: Core voltage supply, 1.2V
|
||||
|
||||
vddio-supply:
|
||||
description: I/O voltage supply, 1.8V or 3.3V
|
||||
|
||||
vddlvds-supply:
|
||||
description: LVDS1/2 voltage supply, 3.3V
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description:
|
||||
Video port for MIPI DSI input, if the bridge DSI controlled
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description:
|
||||
Video port for LVDS output (panel or connector).
|
||||
|
||||
required:
|
||||
- port@1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- reset-gpios
|
||||
- vddc-supply
|
||||
- vddio-supply
|
||||
- vddlvds-supply
|
||||
- ports
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
bridge@0 {
|
||||
compatible = "toshiba,tc358764";
|
||||
reg = <0>;
|
||||
|
||||
reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
|
||||
vddc-supply = <&vcc_1v2_reg>;
|
||||
vddio-supply = <&vcc_1v8_reg>;
|
||||
vddlvds-supply = <&vcc_3v3_reg>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
lvds_ep: endpoint {
|
||||
remote-endpoint = <&panel_ep>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -87,7 +87,7 @@ examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
i2c1 {
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -21,10 +21,9 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8183-disp-ccorr
|
||||
- items:
|
||||
- const: mediatek,mt8192-disp-ccorr
|
||||
- enum:
|
||||
- mediatek,mt8183-disp-ccorr
|
||||
- mediatek,mt8192-disp-ccorr
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8186-disp-ccorr
|
||||
|
||||
@@ -22,12 +22,10 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt2701-disp-color
|
||||
- items:
|
||||
- const: mediatek,mt8167-disp-color
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-color
|
||||
- enum:
|
||||
- mediatek,mt2701-disp-color
|
||||
- mediatek,mt8167-disp-color
|
||||
- mediatek,mt8173-disp-color
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt7623-disp-color
|
||||
|
||||
@@ -22,8 +22,8 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8183-disp-dither
|
||||
- enum:
|
||||
- mediatek,mt8183-disp-dither
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8186-disp-dither
|
||||
|
||||
@@ -20,8 +20,8 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8195-disp-dsc
|
||||
- enum:
|
||||
- mediatek,mt8195-disp-dsc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -21,10 +21,9 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-gamma
|
||||
- items:
|
||||
- const: mediatek,mt8183-disp-gamma
|
||||
- enum:
|
||||
- mediatek,mt8173-disp-gamma
|
||||
- mediatek,mt8183-disp-gamma
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8186-disp-gamma
|
||||
|
||||
@@ -21,10 +21,9 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-merge
|
||||
- items:
|
||||
- const: mediatek,mt8195-disp-merge
|
||||
- enum:
|
||||
- mediatek,mt8173-disp-merge
|
||||
- mediatek,mt8195-disp-merge
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -21,10 +21,9 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt2712-disp-od
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-od
|
||||
- enum:
|
||||
- mediatek,mt2712-disp-od
|
||||
- mediatek,mt8173-disp-od
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -21,10 +21,9 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8183-disp-ovl-2l
|
||||
- items:
|
||||
- const: mediatek,mt8192-disp-ovl-2l
|
||||
- enum:
|
||||
- mediatek,mt8183-disp-ovl-2l
|
||||
- mediatek,mt8192-disp-ovl-2l
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8186-disp-ovl-2l
|
||||
|
||||
@@ -21,14 +21,11 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt2701-disp-ovl
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-ovl
|
||||
- items:
|
||||
- const: mediatek,mt8183-disp-ovl
|
||||
- items:
|
||||
- const: mediatek,mt8192-disp-ovl
|
||||
- enum:
|
||||
- mediatek,mt2701-disp-ovl
|
||||
- mediatek,mt8173-disp-ovl
|
||||
- mediatek,mt8183-disp-ovl
|
||||
- mediatek,mt8192-disp-ovl
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt7623-disp-ovl
|
||||
|
||||
@@ -21,8 +21,8 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8192-disp-postmask
|
||||
- enum:
|
||||
- mediatek,mt8192-disp-postmask
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8186-disp-postmask
|
||||
|
||||
@@ -23,14 +23,11 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt2701-disp-rdma
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-rdma
|
||||
- items:
|
||||
- const: mediatek,mt8183-disp-rdma
|
||||
- items:
|
||||
- const: mediatek,mt8195-disp-rdma
|
||||
- enum:
|
||||
- mediatek,mt2701-disp-rdma
|
||||
- mediatek,mt8173-disp-rdma
|
||||
- mediatek,mt8183-disp-rdma
|
||||
- mediatek,mt8195-disp-rdma
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt8188-disp-rdma
|
||||
|
||||
@@ -21,8 +21,8 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-split
|
||||
- enum:
|
||||
- mediatek,mt8173-disp-split
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -22,8 +22,8 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-ufoe
|
||||
- enum:
|
||||
- mediatek,mt8173-disp-ufoe
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -21,8 +21,8 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: mediatek,mt8173-disp-wdma
|
||||
- enum:
|
||||
- mediatek,mt8173-disp-wdma
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
@@ -61,7 +61,7 @@ properties:
|
||||
- const: lut
|
||||
- const: tbu
|
||||
- const: tbu_rt
|
||||
#MSM8996 has additional iommu clock
|
||||
# MSM8996 has additional iommu clock
|
||||
- items:
|
||||
- const: iface
|
||||
- const: bus
|
||||
|
||||
@@ -101,6 +101,7 @@ required:
|
||||
patternProperties:
|
||||
"^display-controller@[1-9a-f][0-9a-f]*$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
@@ -108,6 +109,7 @@ patternProperties:
|
||||
|
||||
"^dsi@[1-9a-f][0-9a-f]*$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
@@ -115,6 +117,7 @@ patternProperties:
|
||||
|
||||
"^phy@[1-9a-f][0-9a-f]*$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
@@ -132,6 +135,7 @@ patternProperties:
|
||||
|
||||
"^hdmi-tx@[1-9a-f][0-9a-f]*$":
|
||||
type: object
|
||||
additionalProperties: true
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
|
||||
@@ -12,7 +12,7 @@ maintainers:
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/display/lvds.yaml/#
|
||||
- $ref: /schemas/display/lvds.yaml#
|
||||
|
||||
select:
|
||||
properties:
|
||||
|
||||
@@ -12,7 +12,7 @@ maintainers:
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/display/lvds.yaml/#
|
||||
- $ref: /schemas/display/lvds.yaml#
|
||||
|
||||
select:
|
||||
properties:
|
||||
|
||||
@@ -12,7 +12,7 @@ maintainers:
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/display/lvds.yaml/#
|
||||
- $ref: /schemas/display/lvds.yaml#
|
||||
|
||||
select:
|
||||
properties:
|
||||
|
||||
@@ -12,7 +12,7 @@ maintainers:
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/display/lvds.yaml/#
|
||||
- $ref: /schemas/display/lvds.yaml#
|
||||
|
||||
select:
|
||||
properties:
|
||||
|
||||
@@ -41,7 +41,7 @@ examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
spi0 {
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ maintainers:
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
- $ref: /schemas/display/lvds.yaml/#
|
||||
- $ref: /schemas/display/lvds.yaml#
|
||||
|
||||
select:
|
||||
properties:
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user