mirror of
https://github.com/armbian/linux-cix.git
synced 2026-01-06 12:30:45 -08:00
Merge tag 'net-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
Pull networking updates from Paolo Abeni:
"Core:
- Increase size limits for to-be-sent skb frag allocations. This
allows tun, tap devices and packet sockets to better cope with
large writes operations
- Store netdevs in an xarray, to simplify iterating over netdevs
- Refactor nexthop selection for multipath routes
- Improve sched class lifetime handling
- Add backup nexthop ID support for bridge
- Implement drop reasons support in openvswitch
- Several data races annotations and fixes
- Constify the sk parameter of routing functions
- Prepend kernel version to netconsole message
Protocols:
- Implement support for TCP probing the peer being under memory
pressure
- Remove hard coded limitation on IPv6 specific info placement inside
the socket struct
- Get rid of sysctl_tcp_adv_win_scale and use an auto-estimated per
socket scaling factor
- Scaling-up the IPv6 expired route GC via a separated list of
expiring routes
- In-kernel support for the TLS alert protocol
- Better support for UDP reuseport with connected sockets
- Add NEXT-C-SID support for SRv6 End.X behavior, reducing the SR
header size
- Get rid of additional ancillary per MPTCP connection struct socket
- Implement support for BPF-based MPTCP packet schedulers
- Format MPTCP subtests selftests results in TAP
- Several new SMC 2.1 features including unique experimental options,
max connections per lgr negotiation, max links per lgr negotiation
BPF:
- Multi-buffer support in AF_XDP
- Add multi uprobe BPF links for attaching multiple uprobes and usdt
probes, which is significantly faster and saves extra fds
- Implement an fd-based tc BPF attach API (TCX) and BPF link support
on top of it
- Add SO_REUSEPORT support for TC bpf_sk_assign
- Support new instructions from cpu v4 to simplify the generated code
and feature completeness, for x86, arm64, riscv64
- Support defragmenting IPv(4|6) packets in BPF
- Teach verifier actual bounds of bpf_get_smp_processor_id() and fix
perf+libbpf issue related to custom section handling
- Introduce bpf map element count and enable it for all program types
- Add a BPF hook in sys_socket() to change the protocol ID from
IPPROTO_TCP to IPPROTO_MPTCP to cover migration for legacy
- Introduce bpf_me_mcache_free_rcu() and fix OOM under stress
- Add uprobe support for the bpf_get_func_ip helper
- Check skb ownership against full socket
- Support for up to 12 arguments in BPF trampoline
- Extend link_info for kprobe_multi and perf_event links
Netfilter:
- Speed-up process exit by aborting ruleset validation if a fatal
signal is pending
- Allow NLA_POLICY_MASK to be used with BE16/BE32 types
Driver API:
- Page pool optimizations, to improve data locality and cache usage
- Introduce ndo_hwtstamp_get() and ndo_hwtstamp_set() to avoid the
need for raw ioctl() handling in drivers
- Simplify genetlink dump operations (doit/dumpit) providing them the
common information already populated in struct genl_info
- Extend and use the yaml devlink specs to [re]generate the split ops
- Introduce devlink selective dumps, to allow SF filtering SF based
on handle and other attributes
- Add yaml netlink spec for netlink-raw families, allow route, link
and address related queries via the ynl tool
- Remove phylink legacy mode support
- Support offload LED blinking to phy
- Add devlink port function attributes for IPsec
New hardware / drivers:
- Ethernet:
- Broadcom ASP 2.0 (72165) ethernet controller
- MediaTek MT7988 SoC
- Texas Instruments AM654 SoC
- Texas Instruments IEP driver
- Atheros qca8081 phy
- Marvell 88Q2110 phy
- NXP TJA1120 phy
- WiFi:
- MediaTek mt7981 support
- Can:
- Kvaser SmartFusion2 PCI Express devices
- Allwinner T113 controllers
- Texas Instruments tcan4552/4553 chips
- Bluetooth:
- Intel Gale Peak
- Qualcomm WCN3988 and WCN7850
- NXP AW693 and IW624
- Mediatek MT2925
Drivers:
- Ethernet NICs:
- nVidia/Mellanox:
- mlx5:
- support UDP encapsulation in packet offload mode
- IPsec packet offload support in eswitch mode
- improve aRFS observability by adding new set of counters
- extends MACsec offload support to cover RoCE traffic
- dynamic completion EQs
- mlx4:
- convert to use auxiliary bus instead of custom interface
logic
- Intel
- ice:
- implement switchdev bridge offload, even for LAG
interfaces
- implement SRIOV support for LAG interfaces
- igc:
- add support for multiple in-flight TX timestamps
- Broadcom:
- bnxt:
- use the unified RX page pool buffers for XDP and non-XDP
- use the NAPI skb allocation cache
- OcteonTX2:
- support Round Robin scheduling HTB offload
- TC flower offload support for SPI field
- Freescale:
- add XDP_TX feature support
- AMD:
- ionic: add support for PCI FLR event
- sfc:
- basic conntrack offload
- introduce eth, ipv4 and ipv6 pedit offloads
- ST Microelectronics:
- stmmac: maximze PTP timestamping resolution
- Virtual NICs:
- Microsoft vNIC:
- batch ringing RX queue doorbell on receiving packets
- add page pool for RX buffers
- Virtio vNIC:
- add per queue interrupt coalescing support
- Google vNIC:
- add queue-page-list mode support
- Ethernet high-speed switches:
- nVidia/Mellanox (mlxsw):
- add port range matching tc-flower offload
- permit enslavement to netdevices with uppers
- Ethernet embedded switches:
- Marvell (mv88e6xxx):
- convert to phylink_pcs
- Renesas:
- r8A779fx: add speed change support
- rzn1: enables vlan support
- Ethernet PHYs:
- convert mv88e6xxx to phylink_pcs
- WiFi:
- Qualcomm Wi-Fi 7 (ath12k):
- extremely High Throughput (EHT) PHY support
- RealTek (rtl8xxxu):
- enable AP mode for: RTL8192FU, RTL8710BU (RTL8188GU),
RTL8192EU and RTL8723BU
- RealTek (rtw89):
- Introduce Time Averaged SAR (TAS) support
- Connector:
- support for event filtering"
* tag 'net-next-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1806 commits)
net: ethernet: mtk_wed: minor change in wed_{tx,rx}info_show
net: ethernet: mtk_wed: add some more info in wed_txinfo_show handler
net: stmmac: clarify difference between "interface" and "phy_interface"
r8152: add vendor/device ID pair for D-Link DUB-E250
devlink: move devlink_notify_register/unregister() to dev.c
devlink: move small_ops definition into netlink.c
devlink: move tracepoint definitions into core.c
devlink: push linecard related code into separate file
devlink: push rate related code into separate file
devlink: push trap related code into separate file
devlink: use tracepoint_enabled() helper
devlink: push region related code into separate file
devlink: push param related code into separate file
devlink: push resource related code into separate file
devlink: push dpipe related code into separate file
devlink: move and rename devlink_dpipe_send_and_alloc_skb() helper
devlink: push shared buffer related code into separate file
devlink: push port related code into separate file
devlink: push object register/unregister notifications into separate helpers
inet: fix IP_TRANSPARENT error handling
...
This commit is contained in:
@@ -140,11 +140,6 @@ A: Because if we picked one-to-one relationship to x64 it would have made
|
||||
it more complicated to support on arm64 and other archs. Also it
|
||||
needs div-by-zero runtime check.
|
||||
|
||||
Q: Why there is no BPF_SDIV for signed divide operation?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: Because it would be rarely used. llvm errors in such case and
|
||||
prints a suggestion to use unsigned divide instead.
|
||||
|
||||
Q: Why BPF has implicit prologue and epilogue?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
A: Because architectures like sparc have register windows and in general
|
||||
|
||||
@@ -635,12 +635,12 @@ test coverage.
|
||||
|
||||
Q: clang flag for target bpf?
|
||||
-----------------------------
|
||||
Q: In some cases clang flag ``-target bpf`` is used but in other cases the
|
||||
Q: In some cases clang flag ``--target=bpf`` is used but in other cases the
|
||||
default clang target, which matches the underlying architecture, is used.
|
||||
What is the difference and when I should use which?
|
||||
|
||||
A: Although LLVM IR generation and optimization try to stay architecture
|
||||
independent, ``-target <arch>`` still has some impact on generated code:
|
||||
independent, ``--target=<arch>`` still has some impact on generated code:
|
||||
|
||||
- BPF program may recursively include header file(s) with file scope
|
||||
inline assembly codes. The default target can handle this well,
|
||||
@@ -658,7 +658,7 @@ independent, ``-target <arch>`` still has some impact on generated code:
|
||||
The clang option ``-fno-jump-tables`` can be used to disable
|
||||
switch table generation.
|
||||
|
||||
- For clang ``-target bpf``, it is guaranteed that pointer or long /
|
||||
- For clang ``--target=bpf``, it is guaranteed that pointer or long /
|
||||
unsigned long types will always have a width of 64 bit, no matter
|
||||
whether underlying clang binary or default target (or kernel) is
|
||||
32 bit. However, when native clang target is used, then it will
|
||||
@@ -668,7 +668,7 @@ independent, ``-target <arch>`` still has some impact on generated code:
|
||||
while the BPF LLVM back end still operates in 64 bit. The native
|
||||
target is mostly needed in tracing for the case of walking ``pt_regs``
|
||||
or other kernel structures where CPU's register width matters.
|
||||
Otherwise, ``clang -target bpf`` is generally recommended.
|
||||
Otherwise, ``clang --target=bpf`` is generally recommended.
|
||||
|
||||
You should use default target when:
|
||||
|
||||
@@ -685,7 +685,7 @@ when:
|
||||
into these structures is verified by the BPF verifier and may result
|
||||
in verification failures if the native architecture is not aligned with
|
||||
the BPF architecture, e.g. 64-bit. An example of this is
|
||||
BPF_PROG_TYPE_SK_MSG require ``-target bpf``
|
||||
BPF_PROG_TYPE_SK_MSG require ``--target=bpf``
|
||||
|
||||
|
||||
.. Links
|
||||
|
||||
@@ -990,7 +990,7 @@ format.::
|
||||
} g2;
|
||||
int main() { return 0; }
|
||||
int test() { return 0; }
|
||||
-bash-4.4$ clang -c -g -O2 -target bpf t2.c
|
||||
-bash-4.4$ clang -c -g -O2 --target=bpf t2.c
|
||||
-bash-4.4$ readelf -S t2.o
|
||||
......
|
||||
[ 8] .BTF PROGBITS 0000000000000000 00000247
|
||||
@@ -1000,7 +1000,7 @@ format.::
|
||||
[10] .rel.BTF.ext REL 0000000000000000 000007e0
|
||||
0000000000000040 0000000000000010 16 9 8
|
||||
......
|
||||
-bash-4.4$ clang -S -g -O2 -target bpf t2.c
|
||||
-bash-4.4$ clang -S -g -O2 --target=bpf t2.c
|
||||
-bash-4.4$ cat t2.s
|
||||
......
|
||||
.section .BTF,"",@progbits
|
||||
|
||||
@@ -12,9 +12,9 @@ that goes into great technical depth about the BPF Architecture.
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
instruction-set
|
||||
verifier
|
||||
libbpf/index
|
||||
standardization/index
|
||||
btf
|
||||
faq
|
||||
syscall_api
|
||||
@@ -29,7 +29,6 @@ that goes into great technical depth about the BPF Architecture.
|
||||
bpf_licensing
|
||||
test_debug
|
||||
clang-notes
|
||||
linux-notes
|
||||
other
|
||||
redirect
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ For example, for the following code::
|
||||
return g1 + g2 + l1 + l2;
|
||||
}
|
||||
|
||||
Compiled with ``clang -target bpf -O2 -c test.c``, the following is
|
||||
Compiled with ``clang --target=bpf -O2 -c test.c``, the following is
|
||||
the code with ``llvm-objdump -dr test.o``::
|
||||
|
||||
0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
|
||||
@@ -157,7 +157,7 @@ and ``call`` instructions. For example::
|
||||
return gfunc(a, b) + lfunc(a, b) + global;
|
||||
}
|
||||
|
||||
Compiled with ``clang -target bpf -O2 -c test.c``, we will have
|
||||
Compiled with ``clang --target=bpf -O2 -c test.c``, we will have
|
||||
following code with `llvm-objdump -dr test.o``::
|
||||
|
||||
Disassembly of section .text:
|
||||
@@ -203,7 +203,7 @@ The following is an example to show how R_BPF_64_ABS64 could be generated::
|
||||
int global() { return 0; }
|
||||
struct t { void *g; } gbl = { global };
|
||||
|
||||
Compiled with ``clang -target bpf -O2 -g -c test.c``, we will see a
|
||||
Compiled with ``clang --target=bpf -O2 -g -c test.c``, we will see a
|
||||
relocation below in ``.data`` section with command
|
||||
``llvm-readelf -r test.o``::
|
||||
|
||||
|
||||
18
Documentation/bpf/standardization/index.rst
Normal file
18
Documentation/bpf/standardization/index.rst
Normal file
@@ -0,0 +1,18 @@
|
||||
.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
|
||||
|
||||
===================
|
||||
BPF Standardization
|
||||
===================
|
||||
|
||||
This directory contains documents that are being iterated on as part of the BPF
|
||||
standardization effort with the IETF. See the `IETF BPF Working Group`_ page
|
||||
for the working group charter, documents, and more.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
instruction-set
|
||||
linux-notes
|
||||
|
||||
.. Links:
|
||||
.. _IETF BPF Working Group: https://datatracker.ietf.org/wg/bpf/about/
|
||||
@@ -10,9 +10,92 @@ This document specifies version 1.0 of the eBPF instruction set.
|
||||
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,
|
||||
and "s32", etc. to mean a signed integer of the specified number of bits.
|
||||
For brevity and consistency, this document refers to families
|
||||
of types using a shorthand syntax and refers to several expository,
|
||||
mnemonic functions when describing the semantics of instructions.
|
||||
The range of valid values for those types and the semantics of those
|
||||
functions are defined in the following subsections.
|
||||
|
||||
Types
|
||||
-----
|
||||
This document refers to integer types with the notation `SN` to specify
|
||||
a type's signedness (`S`) and bit width (`N`), respectively.
|
||||
|
||||
.. table:: Meaning of signedness notation.
|
||||
|
||||
==== =========
|
||||
`S` Meaning
|
||||
==== =========
|
||||
`u` unsigned
|
||||
`s` signed
|
||||
==== =========
|
||||
|
||||
.. table:: Meaning of bit-width notation.
|
||||
|
||||
===== =========
|
||||
`N` Bit width
|
||||
===== =========
|
||||
`8` 8 bits
|
||||
`16` 16 bits
|
||||
`32` 32 bits
|
||||
`64` 64 bits
|
||||
`128` 128 bits
|
||||
===== =========
|
||||
|
||||
For example, `u32` is a type whose valid values are all the 32-bit unsigned
|
||||
numbers and `s16` is a types whose valid values are all the 16-bit signed
|
||||
numbers.
|
||||
|
||||
Functions
|
||||
---------
|
||||
* `htobe16`: Takes an unsigned 16-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 16-bit number in big-endian
|
||||
format.
|
||||
* `htobe32`: Takes an unsigned 32-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 32-bit number in big-endian
|
||||
format.
|
||||
* `htobe64`: Takes an unsigned 64-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 64-bit number in big-endian
|
||||
format.
|
||||
* `htole16`: Takes an unsigned 16-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 16-bit number in little-endian
|
||||
format.
|
||||
* `htole32`: Takes an unsigned 32-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 32-bit number in little-endian
|
||||
format.
|
||||
* `htole64`: Takes an unsigned 64-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 64-bit number in little-endian
|
||||
format.
|
||||
* `bswap16`: Takes an unsigned 16-bit number in either big- or little-endian
|
||||
format and returns the equivalent number with the same bit width but
|
||||
opposite endianness.
|
||||
* `bswap32`: Takes an unsigned 32-bit number in either big- or little-endian
|
||||
format and returns the equivalent number with the same bit width but
|
||||
opposite endianness.
|
||||
* `bswap64`: Takes an unsigned 64-bit number in either big- or little-endian
|
||||
format and returns the equivalent number with the same bit width but
|
||||
opposite endianness.
|
||||
|
||||
|
||||
Definitions
|
||||
-----------
|
||||
|
||||
.. glossary::
|
||||
|
||||
Sign Extend
|
||||
To `sign extend an` ``X`` `-bit number, A, to a` ``Y`` `-bit number, B ,` means to
|
||||
|
||||
#. Copy all ``X`` bits from `A` to the lower ``X`` bits of `B`.
|
||||
#. Set the value of the remaining ``Y`` - ``X`` bits of `B` to the value of
|
||||
the most-significant bit of `A`.
|
||||
|
||||
.. admonition:: Example
|
||||
|
||||
Sign extend an 8-bit number ``A`` to a 16-bit number ``B`` on a big-endian platform:
|
||||
::
|
||||
|
||||
A: 10000110
|
||||
B: 11111111 10000110
|
||||
|
||||
Registers and calling convention
|
||||
================================
|
||||
@@ -154,24 +237,27 @@ otherwise identical operations.
|
||||
The 'code' field encodes the operation as below, where 'src' and 'dst' refer
|
||||
to the values of the source and destination registers, respectively.
|
||||
|
||||
======== ===== ==========================================================
|
||||
code value description
|
||||
======== ===== ==========================================================
|
||||
BPF_ADD 0x00 dst += src
|
||||
BPF_SUB 0x10 dst -= src
|
||||
BPF_MUL 0x20 dst \*= src
|
||||
BPF_DIV 0x30 dst = (src != 0) ? (dst / src) : 0
|
||||
BPF_OR 0x40 dst \|= src
|
||||
BPF_AND 0x50 dst &= src
|
||||
BPF_LSH 0x60 dst <<= (src & mask)
|
||||
BPF_RSH 0x70 dst >>= (src & mask)
|
||||
BPF_NEG 0x80 dst = ~src
|
||||
BPF_MOD 0x90 dst = (src != 0) ? (dst % src) : dst
|
||||
BPF_XOR 0xa0 dst ^= src
|
||||
BPF_MOV 0xb0 dst = src
|
||||
BPF_ARSH 0xc0 sign extending dst >>= (src & mask)
|
||||
BPF_END 0xd0 byte swap operations (see `Byte swap instructions`_ below)
|
||||
======== ===== ==========================================================
|
||||
========= ===== ======= ==========================================================
|
||||
code value offset description
|
||||
========= ===== ======= ==========================================================
|
||||
BPF_ADD 0x00 0 dst += src
|
||||
BPF_SUB 0x10 0 dst -= src
|
||||
BPF_MUL 0x20 0 dst \*= src
|
||||
BPF_DIV 0x30 0 dst = (src != 0) ? (dst / src) : 0
|
||||
BPF_SDIV 0x30 1 dst = (src != 0) ? (dst s/ src) : 0
|
||||
BPF_OR 0x40 0 dst \|= src
|
||||
BPF_AND 0x50 0 dst &= src
|
||||
BPF_LSH 0x60 0 dst <<= (src & mask)
|
||||
BPF_RSH 0x70 0 dst >>= (src & mask)
|
||||
BPF_NEG 0x80 0 dst = -dst
|
||||
BPF_MOD 0x90 0 dst = (src != 0) ? (dst % src) : dst
|
||||
BPF_SMOD 0x90 1 dst = (src != 0) ? (dst s% src) : dst
|
||||
BPF_XOR 0xa0 0 dst ^= src
|
||||
BPF_MOV 0xb0 0 dst = src
|
||||
BPF_MOVSX 0xb0 8/16/32 dst = (s8,s16,s32)src
|
||||
BPF_ARSH 0xc0 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask)
|
||||
BPF_END 0xd0 0 byte swap operations (see `Byte swap instructions`_ below)
|
||||
========= ===== ======= ==========================================================
|
||||
|
||||
Underflow and overflow are allowed during arithmetic operations, meaning
|
||||
the 64-bit or 32-bit value will wrap. If eBPF program execution would
|
||||
@@ -198,47 +284,75 @@ where '(u32)' indicates that the upper 32 bits are zeroed.
|
||||
|
||||
dst = dst ^ imm32
|
||||
|
||||
Also note that the division and modulo operations are unsigned. Thus, for
|
||||
``BPF_ALU``, 'imm' is first interpreted as an unsigned 32-bit value, whereas
|
||||
for ``BPF_ALU64``, 'imm' is first sign extended to 64 bits and the result
|
||||
interpreted as an unsigned 64-bit value. There are no instructions for
|
||||
signed division or modulo.
|
||||
Note that most instructions have instruction offset of 0. Only three instructions
|
||||
(``BPF_SDIV``, ``BPF_SMOD``, ``BPF_MOVSX``) have a non-zero offset.
|
||||
|
||||
The division and modulo operations support both unsigned and signed flavors.
|
||||
|
||||
For unsigned operations (``BPF_DIV`` and ``BPF_MOD``), for ``BPF_ALU``,
|
||||
'imm' is interpreted as a 32-bit unsigned value. For ``BPF_ALU64``,
|
||||
'imm' is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then
|
||||
interpreted as a 64-bit unsigned value.
|
||||
|
||||
For signed operations (``BPF_SDIV`` and ``BPF_SMOD``), for ``BPF_ALU``,
|
||||
'imm' is interpreted as a 32-bit signed value. For ``BPF_ALU64``, 'imm'
|
||||
is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then
|
||||
interpreted as a 64-bit signed value.
|
||||
|
||||
The ``BPF_MOVSX`` instruction does a move operation with sign extension.
|
||||
``BPF_ALU | BPF_MOVSX`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32
|
||||
bit operands, and zeroes the remaining upper 32 bits.
|
||||
``BPF_ALU64 | BPF_MOVSX`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
|
||||
operands into 64 bit operands.
|
||||
|
||||
Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31)
|
||||
for 32-bit operations.
|
||||
|
||||
Byte swap instructions
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
----------------------
|
||||
|
||||
The byte swap instructions use an instruction class of ``BPF_ALU`` and a 4-bit
|
||||
'code' field of ``BPF_END``.
|
||||
The byte swap instructions use instruction classes of ``BPF_ALU`` and ``BPF_ALU64``
|
||||
and a 4-bit 'code' field of ``BPF_END``.
|
||||
|
||||
The byte swap instructions operate on the destination register
|
||||
only and do not use a separate source register or immediate value.
|
||||
|
||||
The 1-bit source operand field in the opcode is used to select what byte
|
||||
order the operation convert from or to:
|
||||
For ``BPF_ALU``, the 1-bit source operand field in the opcode is used to
|
||||
select what byte order the operation converts from or to. For
|
||||
``BPF_ALU64``, the 1-bit source operand field in the opcode is reserved
|
||||
and must be set to 0.
|
||||
|
||||
========= ===== =================================================
|
||||
source value description
|
||||
========= ===== =================================================
|
||||
BPF_TO_LE 0x00 convert between host byte order and little endian
|
||||
BPF_TO_BE 0x08 convert between host byte order and big endian
|
||||
========= ===== =================================================
|
||||
========= ========= ===== =================================================
|
||||
class source value description
|
||||
========= ========= ===== =================================================
|
||||
BPF_ALU BPF_TO_LE 0x00 convert between host byte order and little endian
|
||||
BPF_ALU BPF_TO_BE 0x08 convert between host byte order and big endian
|
||||
BPF_ALU64 Reserved 0x00 do byte swap unconditionally
|
||||
========= ========= ===== =================================================
|
||||
|
||||
The 'imm' field encodes the width of the swap operations. The following widths
|
||||
are supported: 16, 32 and 64.
|
||||
|
||||
Examples:
|
||||
|
||||
``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16 means::
|
||||
``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16/32/64 means::
|
||||
|
||||
dst = htole16(dst)
|
||||
dst = htole32(dst)
|
||||
dst = htole64(dst)
|
||||
|
||||
``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means::
|
||||
``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 16/32/64 means::
|
||||
|
||||
dst = htobe16(dst)
|
||||
dst = htobe32(dst)
|
||||
dst = htobe64(dst)
|
||||
|
||||
``BPF_ALU64 | BPF_TO_LE | BPF_END`` with imm = 16/32/64 means::
|
||||
|
||||
dst = bswap16(dst)
|
||||
dst = bswap32(dst)
|
||||
dst = bswap64(dst)
|
||||
|
||||
Jump instructions
|
||||
-----------------
|
||||
|
||||
@@ -249,7 +363,8 @@ The 'code' field encodes the operation as below:
|
||||
======== ===== === =========================================== =========================================
|
||||
code value src description notes
|
||||
======== ===== === =========================================== =========================================
|
||||
BPF_JA 0x0 0x0 PC += offset BPF_JMP only
|
||||
BPF_JA 0x0 0x0 PC += offset BPF_JMP class
|
||||
BPF_JA 0x0 0x0 PC += imm BPF_JMP32 class
|
||||
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
|
||||
@@ -278,6 +393,19 @@ Example:
|
||||
|
||||
where 's>=' indicates a signed '>=' comparison.
|
||||
|
||||
``BPF_JA | BPF_K | BPF_JMP32`` (0x06) means::
|
||||
|
||||
gotol +imm
|
||||
|
||||
where 'imm' means the branch offset comes from insn 'imm' field.
|
||||
|
||||
Note that there are two flavors of ``BPF_JA`` instructions. The
|
||||
``BPF_JMP`` class permits a 16-bit jump offset specified by the 'offset'
|
||||
field, whereas the ``BPF_JMP32`` class permits a 32-bit jump offset
|
||||
specified by the 'imm' field. A > 16-bit conditional jump may be
|
||||
converted to a < 16-bit conditional jump plus a 32-bit unconditional
|
||||
jump.
|
||||
|
||||
Helper functions
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -320,6 +448,7 @@ The mode modifier is one of:
|
||||
BPF_ABS 0x20 legacy BPF packet access (absolute) `Legacy BPF Packet access instructions`_
|
||||
BPF_IND 0x40 legacy BPF packet access (indirect) `Legacy BPF Packet access instructions`_
|
||||
BPF_MEM 0x60 regular load and store operations `Regular load and store operations`_
|
||||
BPF_MEMSX 0x80 sign-extension load operations `Sign-extension load operations`_
|
||||
BPF_ATOMIC 0xc0 atomic operations `Atomic operations`_
|
||||
============= ===== ==================================== =============
|
||||
|
||||
@@ -350,9 +479,23 @@ instructions that transfer data between a register and memory.
|
||||
|
||||
``BPF_MEM | <size> | BPF_LDX`` means::
|
||||
|
||||
dst = *(size *) (src + offset)
|
||||
dst = *(unsigned size *) (src + offset)
|
||||
|
||||
Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``.
|
||||
Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW`` and
|
||||
'unsigned size' is one of u8, u16, u32 or u64.
|
||||
|
||||
Sign-extension load operations
|
||||
------------------------------
|
||||
|
||||
The ``BPF_MEMSX`` mode modifier is used to encode :term:`sign-extension<Sign Extend>` load
|
||||
instructions that transfer data between a register and memory.
|
||||
|
||||
``BPF_MEMSX | <size> | BPF_LDX`` means::
|
||||
|
||||
dst = *(signed size *) (src + offset)
|
||||
|
||||
Where size is one of: ``BPF_B``, ``BPF_H`` or ``BPF_W``, and
|
||||
'signed size' is one of s8, s16 or s32.
|
||||
|
||||
Atomic operations
|
||||
-----------------
|
||||
@@ -45,7 +45,8 @@ On Linux, this integer is a BTF ID.
|
||||
Legacy BPF Packet access instructions
|
||||
=====================================
|
||||
|
||||
As mentioned in the `ISA standard documentation <instruction-set.rst#legacy-bpf-packet-access-instructions>`_,
|
||||
As mentioned in the `ISA standard documentation
|
||||
<instruction-set.html#legacy-bpf-packet-access-instructions>`_,
|
||||
Linux has special eBPF instructions for access to packet data that have been
|
||||
carried over from classic BPF to retain the performance of legacy socket
|
||||
filters running in the eBPF interpreter.
|
||||
@@ -67,10 +67,11 @@ Globals
|
||||
kernel-policy
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Defines if the kernel validation policy is per operation (``per-op``)
|
||||
or for the entire family (``global``). New families should use ``per-op``
|
||||
(default) to be able to narrow down the attributes accepted by a specific
|
||||
command.
|
||||
Defines whether the kernel validation policy is ``global`` i.e. the same for all
|
||||
operations of the family, defined for each operation individually - ``per-op``,
|
||||
or separately for each operation and operation type (do vs dump) - ``split``.
|
||||
New families should use ``per-op`` (default) to be able to narrow down the
|
||||
attributes accepted by a specific command.
|
||||
|
||||
checks
|
||||
------
|
||||
|
||||
@@ -19,12 +19,14 @@ properties:
|
||||
- qcom,qca2066-bt
|
||||
- qcom,qca6174-bt
|
||||
- qcom,qca9377-bt
|
||||
- qcom,wcn3988-bt
|
||||
- qcom,wcn3990-bt
|
||||
- qcom,wcn3991-bt
|
||||
- qcom,wcn3998-bt
|
||||
- qcom,qca6390-bt
|
||||
- qcom,wcn6750-bt
|
||||
- qcom,wcn6855-bt
|
||||
- qcom,wcn7850-bt
|
||||
|
||||
enable-gpios:
|
||||
maxItems: 1
|
||||
@@ -57,6 +59,9 @@ properties:
|
||||
vddaon-supply:
|
||||
description: VDD_AON supply regulator handle
|
||||
|
||||
vdddig-supply:
|
||||
description: VDD_DIG supply regulator handle
|
||||
|
||||
vddbtcxmx-supply:
|
||||
description: VDD_BT_CXMX supply regulator handle
|
||||
|
||||
@@ -72,6 +77,9 @@ properties:
|
||||
vddrfa1p2-supply:
|
||||
description: VDD_RFA_1P2 supply regulator handle
|
||||
|
||||
vddrfa1p9-supply:
|
||||
description: VDD_RFA_1P9 supply regulator handle
|
||||
|
||||
vddrfa2p2-supply:
|
||||
description: VDD_RFA_2P2 supply regulator handle
|
||||
|
||||
@@ -111,6 +119,7 @@ allOf:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,wcn3988-bt
|
||||
- qcom,wcn3990-bt
|
||||
- qcom,wcn3991-bt
|
||||
- qcom,wcn3998-bt
|
||||
@@ -155,6 +164,22 @@ allOf:
|
||||
- vddrfa0p8-supply
|
||||
- vddrfa1p2-supply
|
||||
- vddrfa1p7-supply
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,wcn7850-bt
|
||||
then:
|
||||
required:
|
||||
- enable-gpios
|
||||
- swctrl-gpios
|
||||
- vddio-supply
|
||||
- vddaon-supply
|
||||
- vdddig-supply
|
||||
- vddrfa0p8-supply
|
||||
- vddrfa1p2-supply
|
||||
- vddrfa1p9-supply
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
155
Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
Normal file
155
Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml
Normal file
@@ -0,0 +1,155 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/brcm,asp-v2.0.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Broadcom ASP 2.0 Ethernet controller
|
||||
|
||||
maintainers:
|
||||
- Justin Chen <justin.chen@broadcom.com>
|
||||
- Florian Fainelli <florian.fainelli@broadcom.com>
|
||||
|
||||
description: Broadcom Ethernet controller first introduced with 72165
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- brcm,bcm74165-asp
|
||||
- const: brcm,asp-v2.1
|
||||
- items:
|
||||
- enum:
|
||||
- brcm,bcm72165-asp
|
||||
- const: brcm,asp-v2.0
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
ranges: true
|
||||
|
||||
interrupts:
|
||||
minItems: 1
|
||||
items:
|
||||
- description: RX/TX interrupt
|
||||
- description: Port 0 Wake-on-LAN
|
||||
- description: Port 1 Wake-on-LAN
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
ethernet-ports:
|
||||
type: object
|
||||
properties:
|
||||
"#address-cells":
|
||||
const: 1
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^port@[0-9]+$":
|
||||
type: object
|
||||
|
||||
$ref: ethernet-controller.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: Port number
|
||||
|
||||
brcm,channel:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
ASP Channel Number
|
||||
|
||||
The depacketizer channel that consumes packets from
|
||||
the unimac/port.
|
||||
|
||||
required:
|
||||
- reg
|
||||
- brcm,channel
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
patternProperties:
|
||||
"^mdio@[0-9a-f]+$":
|
||||
type: object
|
||||
$ref: brcm,unimac-mdio.yaml
|
||||
|
||||
description:
|
||||
ASP internal UniMAC MDIO bus
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- ranges
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
ethernet@9c00000 {
|
||||
compatible = "brcm,bcm72165-asp", "brcm,asp-v2.0";
|
||||
reg = <0x9c00000 0x1fff14>;
|
||||
interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
|
||||
ranges = <0x0 0x9c00000 0x1fff14>;
|
||||
clocks = <&scmi 14>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
mdio@c614 {
|
||||
compatible = "brcm,asp-v2.0-mdio";
|
||||
reg = <0xc614 0x8>;
|
||||
reg-names = "mdio";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
phy0: ethernet-phy@1 {
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
mdio@ce14 {
|
||||
compatible = "brcm,asp-v2.0-mdio";
|
||||
reg = <0xce14 0x8>;
|
||||
reg-names = "mdio";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
phy1: ethernet-phy@1 {
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
||||
ethernet-ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
brcm,channel = <8>;
|
||||
phy-mode = "rgmii";
|
||||
phy-handle = <&phy0>;
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
brcm,channel = <9>;
|
||||
phy-mode = "rgmii";
|
||||
phy-handle = <&phy1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
@@ -22,6 +22,8 @@ properties:
|
||||
- brcm,genet-mdio-v3
|
||||
- brcm,genet-mdio-v4
|
||||
- brcm,genet-mdio-v5
|
||||
- brcm,asp-v2.0-mdio
|
||||
- brcm,asp-v2.1-mdio
|
||||
- brcm,unimac-mdio
|
||||
|
||||
reg:
|
||||
|
||||
@@ -21,6 +21,7 @@ properties:
|
||||
- const: allwinner,sun4i-a10-can
|
||||
- const: allwinner,sun4i-a10-can
|
||||
- const: allwinner,sun8i-r40-can
|
||||
- const: allwinner,sun20i-d1-can
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
@@ -37,8 +38,9 @@ properties:
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: allwinner,sun8i-r40-can
|
||||
enum:
|
||||
- allwinner,sun8i-r40-can
|
||||
- allwinner,sun20i-d1-can
|
||||
|
||||
then:
|
||||
required:
|
||||
|
||||
@@ -122,8 +122,6 @@ required:
|
||||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- interrupts
|
||||
- interrupt-names
|
||||
- clocks
|
||||
- clock-names
|
||||
- bosch,mram-cfg
|
||||
@@ -132,6 +130,7 @@ additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// Example with interrupts
|
||||
#include <dt-bindings/clock/imx6sx-clock.h>
|
||||
can@20e8000 {
|
||||
compatible = "bosch,m_can";
|
||||
@@ -149,4 +148,21 @@ examples:
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
// Example with timer polling
|
||||
#include <dt-bindings/clock/imx6sx-clock.h>
|
||||
can@20e8000 {
|
||||
compatible = "bosch,m_can";
|
||||
reg = <0x020e8000 0x4000>, <0x02298000 0x4000>;
|
||||
reg-names = "m_can", "message_ram";
|
||||
clocks = <&clks IMX6SX_CLK_CANFD>,
|
||||
<&clks IMX6SX_CLK_CANFD>;
|
||||
clock-names = "hclk", "cclk";
|
||||
bosch,mram-cfg = <0x0 0 0 32 0 0 0 1>;
|
||||
|
||||
can-transceiver {
|
||||
max-bitrate = <5000000>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
@@ -4,7 +4,10 @@ Texas Instruments TCAN4x5x CAN Controller
|
||||
This file provides device node information for the TCAN4x5x interface contains.
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,tcan4x5x"
|
||||
- compatible:
|
||||
"ti,tcan4552", "ti,tcan4x5x"
|
||||
"ti,tcan4553", "ti,tcan4x5x" or
|
||||
"ti,tcan4x5x"
|
||||
- reg: 0
|
||||
- #address-cells: 1
|
||||
- #size-cells: 0
|
||||
@@ -21,8 +24,10 @@ Optional properties:
|
||||
- reset-gpios: Hardwired output GPIO. If not defined then software
|
||||
reset.
|
||||
- device-state-gpios: Input GPIO that indicates if the device is in
|
||||
a sleep state or if the device is active.
|
||||
- device-wake-gpios: Wake up GPIO to wake up the TCAN device.
|
||||
a sleep state or if the device is active. Not
|
||||
available with tcan4552/4553.
|
||||
- device-wake-gpios: Wake up GPIO to wake up the TCAN device. Not
|
||||
available with tcan4552/4553.
|
||||
|
||||
Example:
|
||||
tcan4x5x: tcan4x5x@0 {
|
||||
|
||||
@@ -46,6 +46,9 @@ properties:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: CAN Tx mailbox buffer count (CAN FD)
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
@@ -36,7 +36,7 @@ additionalProperties: true
|
||||
$defs:
|
||||
ethernet-ports:
|
||||
description: A DSA switch without any extra port properties
|
||||
$ref: '#/'
|
||||
$ref: '#'
|
||||
|
||||
patternProperties:
|
||||
"^(ethernet-)?ports$":
|
||||
|
||||
@@ -20,7 +20,7 @@ which is at a different MDIO base address in different switch families.
|
||||
6171, 6172, 6175, 6176, 6185, 6240, 6320, 6321,
|
||||
6341, 6350, 6351, 6352
|
||||
- "marvell,mv88e6190" : Switch has base address 0x00. Use with models:
|
||||
6163, 6190, 6190X, 6191, 6290, 6390, 6390X
|
||||
6190, 6190X, 6191, 6290, 6361, 6390, 6390X
|
||||
- "marvell,mv88e6250" : Switch has base address 0x08 or 0x18. Use with model:
|
||||
6220, 6250
|
||||
|
||||
|
||||
@@ -66,6 +66,7 @@ properties:
|
||||
- mii
|
||||
- gmii
|
||||
- sgmii
|
||||
- psgmii
|
||||
- qsgmii
|
||||
- qusgmii
|
||||
- tbi
|
||||
|
||||
@@ -19,10 +19,12 @@ properties:
|
||||
enum:
|
||||
- mediatek,mt2701-eth
|
||||
- mediatek,mt7623-eth
|
||||
- mediatek,mt7621-eth
|
||||
- mediatek,mt7622-eth
|
||||
- mediatek,mt7629-eth
|
||||
- mediatek,mt7981-eth
|
||||
- mediatek,mt7986-eth
|
||||
- mediatek,mt7988-eth
|
||||
- ralink,rt5350-eth
|
||||
|
||||
reg:
|
||||
@@ -32,7 +34,7 @@ properties:
|
||||
clock-names: true
|
||||
|
||||
interrupts:
|
||||
minItems: 3
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
power-domains:
|
||||
@@ -60,6 +62,12 @@ properties:
|
||||
Phandle to the mediatek hifsys controller used to provide various clocks
|
||||
and reset to the system.
|
||||
|
||||
mediatek,infracfg:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to the syscon node that handles the path from GMAC to
|
||||
PHY variants.
|
||||
|
||||
mediatek,sgmiisys:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
minItems: 1
|
||||
@@ -121,6 +129,8 @@ allOf:
|
||||
- const: gp1
|
||||
- const: gp2
|
||||
|
||||
mediatek,infracfg: false
|
||||
|
||||
mediatek,pctl:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
@@ -131,6 +141,32 @@ allOf:
|
||||
|
||||
mediatek,wed-pcie: false
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- mediatek,mt7621-eth
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ethif
|
||||
- const: fe
|
||||
|
||||
mediatek,infracfg: false
|
||||
|
||||
mediatek,wed: false
|
||||
|
||||
mediatek,wed-pcie: false
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
@@ -159,6 +195,8 @@ allOf:
|
||||
- const: sgmii_ck
|
||||
- const: eth2pll
|
||||
|
||||
mediatek,infracfg: false
|
||||
|
||||
mediatek,sgmiisys:
|
||||
minItems: 1
|
||||
maxItems: 1
|
||||
@@ -204,12 +242,6 @@ allOf:
|
||||
- const: sgmii_ck
|
||||
- const: eth2pll
|
||||
|
||||
mediatek,infracfg:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to the syscon node that handles the path from GMAC to
|
||||
PHY variants.
|
||||
|
||||
mediatek,sgmiisys:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
@@ -250,6 +282,8 @@ allOf:
|
||||
- const: netsys0
|
||||
- const: netsys1
|
||||
|
||||
mediatek,infracfg: false
|
||||
|
||||
mediatek,sgmiisys:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
@@ -286,6 +320,67 @@ allOf:
|
||||
- const: netsys0
|
||||
- const: netsys1
|
||||
|
||||
mediatek,infracfg: false
|
||||
|
||||
mediatek,sgmiisys:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: mediatek,mt7988-eth
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
minItems: 4
|
||||
|
||||
clocks:
|
||||
minItems: 34
|
||||
maxItems: 34
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: crypto
|
||||
- const: fe
|
||||
- const: gp2
|
||||
- const: gp1
|
||||
- const: gp3
|
||||
- const: ethwarp_wocpu2
|
||||
- const: ethwarp_wocpu1
|
||||
- const: ethwarp_wocpu0
|
||||
- const: esw
|
||||
- const: netsys0
|
||||
- const: netsys1
|
||||
- const: sgmii_tx250m
|
||||
- const: sgmii_rx250m
|
||||
- const: sgmii2_tx250m
|
||||
- const: sgmii2_rx250m
|
||||
- const: top_usxgmii0_sel
|
||||
- const: top_usxgmii1_sel
|
||||
- const: top_sgm0_sel
|
||||
- const: top_sgm1_sel
|
||||
- const: top_xfi_phy0_xtal_sel
|
||||
- const: top_xfi_phy1_xtal_sel
|
||||
- const: top_eth_gmii_sel
|
||||
- const: top_eth_refck_50m_sel
|
||||
- const: top_eth_sys_200m_sel
|
||||
- const: top_eth_sys_sel
|
||||
- const: top_eth_xgmii_sel
|
||||
- const: top_eth_mii_sel
|
||||
- const: top_netsys_sel
|
||||
- const: top_netsys_500m_sel
|
||||
- const: top_netsys_pao_2x_sel
|
||||
- const: top_netsys_sync_250m_sel
|
||||
- const: top_netsys_ppefb_250m_sel
|
||||
- const: top_netsys_warp_sel
|
||||
- const: wocpu1
|
||||
- const: wocpu0
|
||||
- const: xgp1
|
||||
- const: xgp2
|
||||
- const: xgp3
|
||||
|
||||
mediatek,sgmiisys:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user