armbian/linux-rockchip
0
0
Fork 0
mirror of https://github.com/armbian/linux-rockchip.git synced 2026-01-06 11:08:10 -08:00
Code Issues Packages Projects Releases Wiki Activity

Merge tag 'net-next-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next

Browse Source 
Pull networking updates from Jakub Kicinski:
 "The sprinkling of SPI drivers is because we added a new one and Mark
  sent us a SPI driver interface conversion pull request.

  Core
  ----

   - Introduce XDP multi-buffer support, allowing the use of XDP with
     jumbo frame MTUs and combination with Rx coalescing offloads (LRO).

   - Speed up netns dismantling (5x) and lower the memory cost a little.
     Remove unnecessary per-netns sockets. Scope some lists to a netns.
     Cut down RCU syncing. Use batch methods. Allow netdev registration
     to complete out of order.

   - Support distinguishing timestamp types (ingress vs egress) and
     maintaining them across packet scrubbing points (e.g. redirect).

   - Continue the work of annotating packet drop reasons throughout the
     stack.

   - Switch netdev error counters from an atomic to dynamically
     allocated per-CPU counters.

   - Rework a few preempt_disable(), local_irq_save() and busy waiting
     sections problematic on PREEMPT_RT.

   - Extend the ref_tracker to allow catching use-after-free bugs.

  BPF
  ---

   - Introduce "packing allocator" for BPF JIT images. JITed code is
     marked read only, and used to be allocated at page granularity.
     Custom allocator allows for more efficient memory use, lower iTLB
     pressure and prevents identity mapping huge pages from getting
     split.

   - Make use of BTF type annotations (e.g. __user, __percpu) to enforce
     the correct probe read access method, add appropriate helpers.

   - Convert the BPF preload to use light skeleton and drop the
     user-mode-driver dependency.

   - Allow XDP BPF_PROG_RUN test infra to send real packets, enabling
     its use as a packet generator.

   - Allow local storage memory to be allocated with GFP_KERNEL if
     called from a hook allowed to sleep.

   - Introduce fprobe (multi kprobe) to speed up mass attachment (arch
     bits to come later).

   - Add unstable conntrack lookup helpers for BPF by using the BPF
     kfunc infra.

   - Allow cgroup BPF progs to return custom errors to user space.

   - Add support for AF_UNIX iterator batching.

   - Allow iterator programs to use sleepable helpers.

   - Support JIT of add, and, or, xor and xchg atomic ops on arm64.

   - Add BTFGen support to bpftool which allows to use CO-RE in kernels
     without BTF info.

   - Large number of libbpf API improvements, cleanups and deprecations.

  Protocols
  ---------

   - Micro-optimize UDPv6 Tx, gaining up to 5% in test on dummy netdev.

   - Adjust TSO packet sizes based on min_rtt, allowing very low latency
     links (data centers) to always send full-sized TSO super-frames.

   - Make IPv6 flow label changes (AKA hash rethink) more configurable,
     via sysctl and setsockopt. Distinguish between server and client
     behavior.

   - VxLAN support to "collect metadata" devices to terminate only
     configured VNIs. This is similar to VLAN filtering in the bridge.

   - Support inserting IPv6 IOAM information to a fraction of frames.

   - Add protocol attribute to IP addresses to allow identifying where
     given address comes from (kernel-generated, DHCP etc.)

   - Support setting socket and IPv6 options via cmsg on ping6 sockets.

   - Reject mis-use of ECN bits in IP headers as part of DSCP/TOS.
     Define dscp_t and stop taking ECN bits into account in fib-rules.

   - Add support for locked bridge ports (for 802.1X).

   - tun: support NAPI for packets received from batched XDP buffs,
     doubling the performance in some scenarios.

   - IPv6 extension header handling in Open vSwitch.

   - Support IPv6 control message load balancing in bonding, prevent
     neighbor solicitation and advertisement from using the wrong port.
     Support NS/NA monitor selection similar to existing ARP monitor.

   - SMC
      - improve performance with TCP_CORK and sendfile()
      - support auto-corking
      - support TCP_NODELAY

   - MCTP (Management Component Transport Protocol)
      - add user space tag control interface
      - I2C binding driver (as specified by DMTF DSP0237)

   - Multi-BSSID beacon handling in AP mode for WiFi.

   - Bluetooth:
      - handle MSFT Monitor Device Event
      - add MGMT Adv Monitor Device Found/Lost events

   - Multi-Path TCP:
      - add support for the SO_SNDTIMEO socket option
      - lots of selftest cleanups and improvements

   - Increase the max PDU size in CAN ISOTP to 64 kB.

  Driver API
  ----------

   - Add HW counters for SW netdevs, a mechanism for devices which
     offload packet forwarding to report packet statistics back to
     software interfaces such as tunnels.

   - Select the default NIC queue count as a fraction of number of
     physical CPU cores, instead of hard-coding to 8.

   - Expose devlink instance locks to drivers. Allow device layer of
     drivers to use that lock directly instead of creating their own
     which always runs into ordering issues in devlink callbacks.

   - Add header/data split indication to guide user space enabling of
     TCP zero-copy Rx.

   - Allow configuring completion queue event size.

   - Refactor page_pool to enable fragmenting after allocation.

   - Add allocation and page reuse statistics to page_pool.

   - Improve Multiple Spanning Trees support in the bridge to allow
     reuse of topologies across VLANs, saving HW resources in switches.

   - DSA (Distributed Switch Architecture):
      - replay and offload of host VLAN entries
      - offload of static and local FDB entries on LAG interfaces
      - FDB isolation and unicast filtering

  New hardware / drivers
  ----------------------

   - Ethernet:
      - LAN937x T1 PHYs
      - Davicom DM9051 SPI NIC driver
      - Realtek RTL8367S, RTL8367RB-VB switch and MDIO
      - Microchip ksz8563 switches
      - Netronome NFP3800 SmartNICs
      - Fungible SmartNICs
      - MediaTek MT8195 switches

   - WiFi:
      - mt76: MediaTek mt7916
      - mt76: MediaTek mt7921u USB adapters
      - brcmfmac: Broadcom BCM43454/6

   - Mobile:
      - iosm: Intel M.2 7360 WWAN card

  Drivers
  -------

   - Convert many drivers to the new phylink API built for split PCS
     designs but also simplifying other cases.

   - Intel Ethernet NICs:
      - add TTY for GNSS module for E810T device
      - improve AF_XDP performance
      - GTP-C and GTP-U filter offload
      - QinQ VLAN support

   - Mellanox Ethernet NICs (mlx5):
      - support xdp->data_meta
      - multi-buffer XDP
      - offload tc push_eth and pop_eth actions

   - Netronome Ethernet NICs (nfp):
      - flow-independent tc action hardware offload (police / meter)
      - AF_XDP

   - Other Ethernet NICs:
      - at803x: fiber and SFP support
      - xgmac: mdio: preamble suppression and custom MDC frequencies
      - r8169: enable ASPM L1.2 if system vendor flags it as safe
      - macb/gem: ZynqMP SGMII
      - hns3: add TX push mode
      - dpaa2-eth: software TSO
      - lan743x: multi-queue, mdio, SGMII, PTP
      - axienet: NAPI and GRO support

   - Mellanox Ethernet switches (mlxsw):
      - source and dest IP address rewrites
      - RJ45 ports

   - Marvell Ethernet switches (prestera):
      - basic routing offload
      - multi-chain TC ACL offload

   - NXP embedded Ethernet switches (ocelot & felix):
      - PTP over UDP with the ocelot-8021q DSA tagging protocol
      - basic QoS classification on Felix DSA switch using dcbnl
      - port mirroring for ocelot switches

   - Microchip high-speed industrial Ethernet (sparx5):
      - offloading of bridge port flooding flags
      - PTP Hardware Clock

   - Other embedded switches:
      - lan966x: PTP Hardward Clock
      - qca8k: mdio read/write operations via crafted Ethernet packets

   - Qualcomm 802.11ax WiFi (ath11k):
      - add LDPC FEC type and 802.11ax High Efficiency data in radiotap
      - enable RX PPDU stats in monitor co-exist mode

   - Intel WiFi (iwlwifi):
      - UHB TAS enablement via BIOS
      - band disablement via BIOS
      - channel switch offload
      - 32 Rx AMPDU sessions in newer devices

   - MediaTek WiFi (mt76):
      - background radar detection
      - thermal management improvements on mt7915
      - SAR support for more mt76 platforms
      - MBSSID and 6 GHz band on mt7915

   - RealTek WiFi:
      - rtw89: AP mode
      - rtw89: 160 MHz channels and 6 GHz band
      - rtw89: hardware scan

   - Bluetooth:
      - mt7921s: wake on Bluetooth, SCO over I2S, wide-band-speed (WBS)

   - Microchip CAN (mcp251xfd):
      - multiple RX-FIFOs and runtime configurable RX/TX rings
      - internal PLL, runtime PM handling simplification
      - improve chip detection and error handling after wakeup"

* tag 'net-next-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (2521 commits)
  llc: fix netdevice reference leaks in llc_ui_bind()
  drivers: ethernet: cpsw: fix panic when interrupt coaleceing is set via ethtool
  ice: don't allow to run ice_send_event_to_aux() in atomic ctx
  ice: fix 'scheduling while atomic' on aux critical err interrupt
  net/sched: fix incorrect vlan_push_eth dest field
  net: bridge: mst: Restrict info size queries to bridge ports
  net: marvell: prestera: add missing destroy_workqueue() in prestera_module_init()
  drivers: net: xgene: Fix regression in CRC stripping
  net: geneve: add missing netlink policy and size for IFLA_GENEVE_INNER_PROTO_INHERIT
  net: dsa: fix missing host-filtered multicast addresses
  net/mlx5e: Fix build warning, detected write beyond size of field
  iwlwifi: mvm: Don't fail if PPAG isn't supported
  selftests/bpf: Fix kprobe_multi test.
  Revert "rethook: x86: Add rethook x86 implementation"
  Revert "arm64: rethook: Add arm64 rethook implementation"
  Revert "powerpc: Add rethook support"
  Revert "ARM: rethook: Add rethook arm implementation"
  netdevice: add missing dm_private kdoc
  net: bridge: mst: prevent NULL deref in br_mst_info_size()
  selftests: forwarding: Use same VRF for port and VLAN upper
  ...
This commit is contained in:
Linus Torvalds
2022-03-24 13:13:26 -07:00
parent 7403e6d826 89695196f0
commit 169e77764a
2020 changed files with 120874 additions and 36702 deletions
Download Patch File Download Diff File Expand all files Collapse all files

116
Documentation/ABI/testing/sysfs-timecard
View File

@@ -37,8 +37,15 @@ Description: (RO) Set of available destinations (sinks) for a SMA
PPS2 signal is sent to the PPS2 selector
TS1 signal is sent to timestamper 1
TS2 signal is sent to timestamper 2
TS3 signal is sent to timestamper 3
TS4 signal is sent to timestamper 4
IRIG signal is sent to the IRIG-B module
DCF signal is sent to the DCF module
FREQ1 signal is sent to frequency counter 1
FREQ2 signal is sent to frequency counter 2
FREQ3 signal is sent to frequency counter 3
FREQ4 signal is sent to frequency counter 4
None signal input is disabled
===== ================================================
What: /sys/class/timecard/ocpN/available_sma_outputs
@@ -50,10 +57,16 @@ Description: (RO) Set of available sources for a SMA output signal.
10Mhz output is from the 10Mhz reference clock
PHC output PPS is from the PHC clock
MAC output PPS is from the Miniature Atomic Clock
GNSS output PPS is from the GNSS module
GNSS1 output PPS is from the first GNSS module
GNSS2 output PPS is from the second GNSS module
IRIG output is from the PHC, in IRIG-B format
DCF output is from the PHC, in DCF format
GEN1 output is from frequency generator 1
GEN2 output is from frequency generator 2
GEN3 output is from frequency generator 3
GEN4 output is from frequency generator 4
GND output is GND
VCC output is VCC
===== ================================================
What: /sys/class/timecard/ocpN/clock_source
@@ -63,6 +76,97 @@ Description: (RW) Contains the current synchronization source used by
the PHC. May be changed by writing one of the listed
values from the available_clock_sources attribute set.
What: /sys/class/timecard/ocpN/clock_status_drift
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Contains the current drift value used by the firmware
for internal disciplining of the atomic clock.
What: /sys/class/timecard/ocpN/clock_status_offset
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Contains the current offset value used by the firmware
for internal disciplining of the atomic clock.
What: /sys/class/timecard/ocpN/freqX
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Optional directory containing the sysfs nodes for
frequency counter <X>.
What: /sys/class/timecard/ocpN/freqX/frequency
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Contains the measured frequency over the specified
measurement period.
What: /sys/class/timecard/ocpN/freqX/seconds
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) Specifies the number of seconds from 0-255 that the
frequency should be measured over. Write 0 to disable.
What: /sys/class/timecard/ocpN/genX
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Optional directory containing the sysfs nodes for
frequency generator <X>.
What: /sys/class/timecard/ocpN/genX/duty
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Specifies the signal duty cycle as a percentage from 1-99.
What: /sys/class/timecard/ocpN/genX/period
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Specifies the signal period in nanoseconds.
What: /sys/class/timecard/ocpN/genX/phase
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Specifies the signal phase offset in nanoseconds.
What: /sys/class/timecard/ocpN/genX/polarity
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Specifies the signal polarity, either 1 or 0.
What: /sys/class/timecard/ocpN/genX/running
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Either 0 or 1, showing if the signal generator is running.
What: /sys/class/timecard/ocpN/genX/start
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RO) Shows the time in <sec>.<nsec> that the signal generator
started running.
What: /sys/class/timecard/ocpN/genX/signal
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) Used to start the signal generator, and summarize
the current status.
The signal generator may be started by writing the signal
period, followed by the optional signal values. If the
optional values are not provided, they default to the current
settings, which may be obtained from the other sysfs nodes.
period [duty [phase [polarity]]]
echo 500000000 > signal # 1/2 second period
echo 1000000 40 100 > signal
echo 0 > signal # turn off generator
Period and phase are specified in nanoseconds. Duty cycle is
a percentage from 1-99. Polarity is 1 or 0.
Reading this node will return:
period duty phase polarity start_time
What: /sys/class/timecard/ocpN/gnss_sync
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
@@ -126,6 +230,16 @@ Description: (RW) These attributes specify the direction of the signal
The 10Mhz reference clock input is currently only valid
on SMA1 and may not be combined with other destination sinks.
What: /sys/class/timecard/ocpN/tod_correction
Date: March 2022
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>
Description: (RW) The incoming GNSS signal is in UTC time, and the NMEA
format messages do not provide a TAI offset. This sets the
correction value for the incoming time.
If UBX_LS is enabled, this should be 0, and the offset is
taken from the UBX-NAV-TIMELS message.
What: /sys/class/timecard/ocpN/ts_window_adjust
Date: September 2021
Contact: Jonathan Lemon <jonathan.lemon@gmail.com>

9
Documentation/admin-guide/sysctl/net.rst
View File

@@ -365,6 +365,15 @@ new netns has been created.
Default : 0 (for compatibility reasons)
txrehash
--------
Controls default hash rethink behaviour on listening socket when SO_TXREHASH
option is set to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt).
If set to 1 (default), hash rethink is performed on listening socket.
If set to 0, hash rethink is not performed.
2. /proc/sys/net/unix - Parameters for Unix domain sockets
----------------------------------------------------------

117
Documentation/bpf/bpf_prog_run.rst Normal file
View File

@@ -0,0 +1,117 @@
.. SPDX-License-Identifier: GPL-2.0
===================================
Running BPF programs from userspace
===================================
This document describes the ``BPF_PROG_RUN`` facility for running BPF programs
from userspace.
.. contents::
:local:
:depth: 2
Overview
--------
The ``BPF_PROG_RUN`` command can be used through the ``bpf()`` syscall to
execute a BPF program in the kernel and return the results to userspace. This
can be used to unit test BPF programs against user-supplied context objects, and
as way to explicitly execute programs in the kernel for their side effects. The
command was previously named ``BPF_PROG_TEST_RUN``, and both constants continue
to be defined in the UAPI header, aliased to the same value.
The ``BPF_PROG_RUN`` command can be used to execute BPF programs of the
following types:
- ``BPF_PROG_TYPE_SOCKET_FILTER``
- ``BPF_PROG_TYPE_SCHED_CLS``
- ``BPF_PROG_TYPE_SCHED_ACT``
- ``BPF_PROG_TYPE_XDP``
- ``BPF_PROG_TYPE_SK_LOOKUP``
- ``BPF_PROG_TYPE_CGROUP_SKB``
- ``BPF_PROG_TYPE_LWT_IN``
- ``BPF_PROG_TYPE_LWT_OUT``
- ``BPF_PROG_TYPE_LWT_XMIT``
- ``BPF_PROG_TYPE_LWT_SEG6LOCAL``
- ``BPF_PROG_TYPE_FLOW_DISSECTOR``
- ``BPF_PROG_TYPE_STRUCT_OPS``
- ``BPF_PROG_TYPE_RAW_TRACEPOINT``
- ``BPF_PROG_TYPE_SYSCALL``
When using the ``BPF_PROG_RUN`` command, userspace supplies an input context
object and (for program types operating on network packets) a buffer containing
the packet data that the BPF program will operate on. The kernel will then
execute the program and return the results to userspace. Note that programs will
not have any side effects while being run in this mode; in particular, packets
will not actually be redirected or dropped, the program return code will just be
returned to userspace. A separate mode for live execution of XDP programs is
provided, documented separately below.
Running XDP programs in "live frame mode"
-----------------------------------------
The ``BPF_PROG_RUN`` command has a separate mode for running live XDP programs,
which can be used to execute XDP programs in a way where packets will actually
be processed by the kernel after the execution of the XDP program as if they
arrived on a physical interface. This mode is activated by setting the
``BPF_F_TEST_XDP_LIVE_FRAMES`` flag when supplying an XDP program to
``BPF_PROG_RUN``.
The live packet mode is optimised for high performance execution of the supplied
XDP program many times (suitable for, e.g., running as a traffic generator),
which means the semantics are not quite as straight-forward as the regular test
run mode. Specifically:
- When executing an XDP program in live frame mode, the result of the execution
will not be returned to userspace; instead, the kernel will perform the
operation indicated by the program's return code (drop the packet, redirect
it, etc). For this reason, setting the ``data_out`` or ``ctx_out`` attributes
in the syscall parameters when running in this mode will be rejected. In
addition, not all failures will be reported back to userspace directly;
specifically, only fatal errors in setup or during execution (like memory
allocation errors) will halt execution and return an error. If an error occurs
in packet processing, like a failure to redirect to a given interface,
execution will continue with the next repetition; these errors can be detected
via the same trace points as for regular XDP programs.
- Userspace can supply an ifindex as part of the context object, just like in
the regular (non-live) mode. The XDP program will be executed as though the
packet arrived on this interface; i.e., the ``ingress_ifindex`` of the context
object will point to that interface. Furthermore, if the XDP program returns
``XDP_PASS``, the packet will be injected into the kernel networking stack as
though it arrived on that ifindex, and if it returns ``XDP_TX``, the packet
will be transmitted *out* of that same interface. Do note, though, that
because the program execution is not happening in driver context, an
``XDP_TX`` is actually turned into the same action as an ``XDP_REDIRECT`` to
that same interface (i.e., it will only work if the driver has support for the
``ndo_xdp_xmit`` driver op).
- When running the program with multiple repetitions, the execution will happen
in batches. The batch size defaults to 64 packets (which is same as the
maximum NAPI receive batch size), but can be specified by userspace through
the ``batch_size`` parameter, up to a maximum of 256 packets. For each batch,
the kernel executes the XDP program repeatedly, each invocation getting a
separate copy of the packet data. For each repetition, if the program drops
the packet, the data page is immediately recycled (see below). Otherwise, the
packet is buffered until the end of the batch, at which point all packets
buffered this way during the batch are transmitted at once.
- When setting up the test run, the kernel will initialise a pool of memory
pages of the same size as the batch size. Each memory page will be initialised
with the initial packet data supplied by userspace at ``BPF_PROG_RUN``
invocation. When possible, the pages will be recycled on future program
invocations, to improve performance. Pages will generally be recycled a full
batch at a time, except when a packet is dropped (by return code or because
of, say, a redirection error), in which case that page will be recycled
immediately. If a packet ends up being passed to the regular networking stack
(because the XDP program returns ``XDP_PASS``, or because it ends up being
redirected to an interface that injects it into the stack), the page will be
released and a new one will be allocated when the pool is empty.
When recycling, the page content is not rewritten; only the packet boundary
pointers (``data``, ``data_end`` and ``data_meta``) in the context object will
be reset to the original values. This means that if a program rewrites the
packet contents, it has to be prepared to see either the original content or
the modified version on subsequent invocations.

45
Documentation/bpf/btf.rst
View File

@@ -503,6 +503,19 @@ valid index (starting from 0) pointing to a member or an argument.
* ``info.vlen``: 0
* ``type``: the type with ``btf_type_tag`` attribute
Currently, ``BTF_KIND_TYPE_TAG`` is only emitted for pointer types.
It has the following btf type chain:
::
ptr -> [type_tag]*
-> [const | volatile | restrict | typedef]*
-> base_type
Basically, a pointer type points to zero or more
type_tag, then zero or more const/volatile/restrict/typedef
and finally the base type. The base type is one of
int, ptr, array, struct, union, enum, func_proto and float types.
3. BTF Kernel API
=================
@@ -565,18 +578,15 @@ A map can be created with ``btf_fd`` and specified key/value type id.::
In libbpf, the map can be defined with extra annotation like below:
::
struct bpf_map_def SEC("maps") btf_map = {
.type = BPF_MAP_TYPE_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(struct ipv_counts),
.max_entries = 4,
};
BPF_ANNOTATE_KV_PAIR(btf_map, int, struct ipv_counts);
struct {
__uint(type, BPF_MAP_TYPE_ARRAY);
__type(key, int);
__type(value, struct ipv_counts);
__uint(max_entries, 4);
} btf_map SEC(".maps");
Here, the parameters for macro BPF_ANNOTATE_KV_PAIR are map name, key and
value types for the map. During ELF parsing, libbpf is able to extract
key/value type_id's and assign them to BPF_MAP_CREATE attributes
automatically.
During ELF parsing, libbpf is able to extract key/value type_id's and assign
them to BPF_MAP_CREATE attributes automatically.
.. _BPF_Prog_Load:
@@ -824,13 +834,12 @@ structure has bitfields. For example, for the following map,::
___A b1:4;
enum A b2:4;
};
struct bpf_map_def SEC("maps") tmpmap = {
.type = BPF_MAP_TYPE_ARRAY,
.key_size = sizeof(__u32),
.value_size = sizeof(struct tmp_t),
.max_entries = 1,
};
BPF_ANNOTATE_KV_PAIR(tmpmap, int, struct tmp_t);
struct {
__uint(type, BPF_MAP_TYPE_ARRAY);
__type(key, int);
__type(value, struct tmp_t);
__uint(max_entries, 1);
} tmpmap SEC(".maps");
bpftool is able to pretty print like below:
::

1
Documentation/bpf/index.rst
View File

@@ -21,6 +21,7 @@ that goes into great technical depth about the BPF Architecture.
helpers
programs
maps
bpf_prog_run
classic_vs_extended.rst
bpf_licensing
test_debug

215
Documentation/bpf/instruction-set.rst
View File

@@ -22,7 +22,13 @@ necessary across calls.
Instruction encoding
====================
eBPF uses 64-bit instructions with the following encoding:
eBPF has two instruction encodings:
* the basic instruction encoding, which uses 64 bits to encode an instruction
* the wide instruction encoding, which appends a second 64-bit immediate value
(imm64) after the basic instruction for a total of 128 bits.
The basic instruction encoding looks as follows:
============= ======= =============== ==================== ============
32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB)
@@ -82,9 +88,9 @@ BPF_ALU uses 32-bit wide operands while BPF_ALU64 uses 64-bit wide operands for
otherwise identical operations.
The code field encodes the operation as below:
======== ===== ==========================
======== ===== =================================================
code value description
======== ===== ==========================
======== ===== =================================================
BPF_ADD 0x00 dst += src
BPF_SUB 0x10 dst -= src
BPF_MUL 0x20 dst \*= src
@@ -98,8 +104,8 @@ The code field encodes the operation as below:
BPF_XOR 0xa0 dst ^= src
BPF_MOV 0xb0 dst = src
BPF_ARSH 0xc0 sign extending shift right
BPF_END 0xd0 endianness conversion
======== ===== ==========================
BPF_END 0xd0 byte swap operations (see separate section below)
======== ===== =================================================
BPF_ADD | BPF_X | BPF_ALU means::
@@ -118,6 +124,42 @@ BPF_XOR | BPF_K | BPF_ALU64 means::
src_reg = src_reg ^ imm32
Byte swap instructions
----------------------
The byte swap instructions use an instruction class of ``BFP_ALU`` and a 4-bit
code field of ``BPF_END``.
The byte swap instructions 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 to select what byte
order the operation convert from or to:
========= ===== =================================================
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
========= ===== =================================================
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::
dst_reg = htole16(dst_reg)
``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means::
dst_reg = htobe64(dst_reg)
``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and
``BPF_TO_LE`` respetively.
Jump instructions
-----------------
@@ -176,63 +218,96 @@ The mode modifier is one of:
============= ===== ====================================
mode modifier value description
============= ===== ====================================
BPF_IMM 0x00 used for 64-bit mov
BPF_ABS 0x20 legacy BPF packet access
BPF_IND 0x40 legacy BPF packet access
BPF_MEM 0x60 all normal load and store operations
BPF_IMM 0x00 64-bit immediate instructions
BPF_ABS 0x20 legacy BPF packet access (absolute)
BPF_IND 0x40 legacy BPF packet access (indirect)
BPF_MEM 0x60 regular load and store operations
BPF_ATOMIC 0xc0 atomic operations
============= ===== ====================================
BPF_MEM | <size> | BPF_STX means::
Regular load and store operations
---------------------------------
The ``BPF_MEM`` mode modifier is used to encode regular load and store
instructions that transfer data between a register and memory.
``BPF_MEM | <size> | BPF_STX`` means::
*(size *) (dst_reg + off) = src_reg
BPF_MEM | <size> | BPF_ST means::
``BPF_MEM | <size> | BPF_ST`` means::
*(size *) (dst_reg + off) = imm32
BPF_MEM | <size> | BPF_LDX means::
``BPF_MEM | <size> | BPF_LDX`` means::
dst_reg = *(size *) (src_reg + off)
Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW.
Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``.
Atomic operations
-----------------
eBPF includes atomic operations, which use the immediate field for extra
encoding::
Atomic operations are operations that operate on memory and can not be
interrupted or corrupted by other access to the same memory region
by other eBPF programs or means outside of this specification.
.imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg
.imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg
All atomic operations supported by eBPF are encoded as store operations
that use the ``BPF_ATOMIC`` mode modifier as follows:
The basic atomic operations supported are::
* ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations
* ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations
* 8-bit and 16-bit wide atomic operations are not supported.
BPF_ADD
BPF_AND
BPF_OR
BPF_XOR
The imm field is used to encode the actual atomic operation.
Simple atomic operation use a subset of the values defined to encode
arithmetic operations in the imm field to encode the atomic operation:
Each having equivalent semantics with the ``BPF_ADD`` example, that is: the
memory location addresed by ``dst_reg + off`` is atomically modified, with
``src_reg`` as the other operand. If the ``BPF_FETCH`` flag is set in the
immediate, then these operations also overwrite ``src_reg`` with the
value that was in memory before it was modified.
======== ===== ===========
imm value description
======== ===== ===========
BPF_ADD 0x00 atomic add
BPF_OR 0x40 atomic or
BPF_AND 0x50 atomic and
BPF_XOR 0xa0 atomic xor
======== ===== ===========
The more special operations are::
BPF_XCHG
``BPF_ATOMIC | BPF_W | BPF_STX`` with imm = BPF_ADD means::
This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg +
off``. ::
*(u32 *)(dst_reg + off16) += src_reg
BPF_CMPXCHG
``BPF_ATOMIC | BPF_DW | BPF_STX`` with imm = BPF ADD means::
This atomically compares the value addressed by ``dst_reg + off`` with
``R0``. If they match it is replaced with ``src_reg``. In either case, the
value that was there before is zero-extended and loaded back to ``R0``.
*(u64 *)(dst_reg + off16) += src_reg
Note that 1 and 2 byte atomic operations are not supported.
``BPF_XADD`` is a deprecated name for ``BPF_ATOMIC | BPF_ADD``.
In addition to the simple atomic operations, there also is a modifier and
two complex atomic operations:
=========== ================ ===========================
imm value description
=========== ================ ===========================
BPF_FETCH 0x01 modifier: return old value
BPF_XCHG 0xe0 | BPF_FETCH atomic exchange
BPF_CMPXCHG 0xf0 | BPF_FETCH atomic compare and exchange
=========== ================ ===========================
The ``BPF_FETCH`` modifier is optional for simple atomic operations, and
always set for the complex atomic operations. If the ``BPF_FETCH`` flag
is set, then the operation also overwrites ``src_reg`` with the value that
was in memory before it was modified.
The ``BPF_XCHG`` operation atomically exchanges ``src_reg`` with the value
addressed by ``dst_reg + off``.
The ``BPF_CMPXCHG`` operation atomically compares the value addressed by
``dst_reg + off`` with ``R0``. If they match, the value addressed by
``dst_reg + off`` is replaced with ``src_reg``. In either case, the
value that was at ``dst_reg + off`` before the operation is zero-extended
and loaded back to ``R0``.
Clang can generate atomic instructions by default when ``-mcpu=v3`` is
enabled. If a lower version for ``-mcpu`` is set, the only atomic instruction
@@ -240,40 +315,52 @@ Clang can generate is ``BPF_ADD`` *without* ``BPF_FETCH``. If you need to enable
the atomics features, while keeping a lower ``-mcpu`` version, you can use
``-Xclang -target-feature -Xclang +alu32``.
You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``,
referring to the exclusive-add operation encoded when the immediate field is
zero.
64-bit immediate instructions
-----------------------------
16-byte instructions
--------------------
Instructions with the ``BPF_IMM`` mode modifier use the wide instruction
encoding for an extra imm64 value.
eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which consists
of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as single
instruction that loads 64-bit immediate value into a dst_reg.
There is currently only one such instruction.
Packet access instructions
--------------------------
``BPF_LD | BPF_DW | BPF_IMM`` means::
eBPF has two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and
(BPF_IND | <size> | BPF_LD) which are used to access packet data.
dst_reg = imm64
They had to be carried over from classic BPF to have strong performance of
socket filters running in eBPF interpreter. These instructions can only
be used when interpreter context is a pointer to ``struct sk_buff`` and
have seven implicit operands. Register R6 is an implicit input that must
contain pointer to sk_buff. Register R0 is an implicit output which contains
the data fetched from the packet. Registers R1-R5 are scratch registers
and must not be used to store the data across BPF_ABS | BPF_LD or
BPF_IND | BPF_LD instructions.
These instructions have implicit program exit condition as well. When
eBPF program is trying to access the data beyond the packet boundary,
the interpreter will abort the execution of the program. JIT compilers
therefore must preserve this property. src_reg and imm32 fields are
explicit inputs to these instructions.
Legacy BPF Packet access instructions
-------------------------------------
For example, BPF_IND | BPF_W | BPF_LD means::
eBPF has special 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.
The instructions come in two forms: ``BPF_ABS | <size> | BPF_LD`` and
``BPF_IND | <size> | BPF_LD``.
These instructions are used to access packet data and can only be used when
the program context is a pointer to networking packet. ``BPF_ABS``
accesses packet data at an absolute offset specified by the immediate data
and ``BPF_IND`` access packet data at an offset that includes the value of
a register in addition to the immediate data.
These instructions have seven implicit operands:
* Register R6 is an implicit input that must contain pointer to a
struct sk_buff.
* Register R0 is an implicit output which contains the data fetched from
the packet.
* Registers R1-R5 are scratch registers that are clobbered after a call to
``BPF_ABS | BPF_LD`` or ``BPF_IND`` | BPF_LD instructions.
These instructions have an implicit program exit condition as well. When an
eBPF program is trying to access the data beyond the packet boundary, the
program execution will be aborted.
``BPF_ABS | BPF_W | BPF_LD`` means::
R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + imm32))
``BPF_IND | BPF_W | BPF_LD`` means::
R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32))
and R1 - R5 are clobbered.

2
Documentation/bpf/verifier.rst
View File

@@ -329,7 +329,7 @@ Program with unreachable instructions::
BPF_EXIT_INSN(),
};
Error:
Error::
unreachable insn 1

4
Documentation/devicetree/bindings/i2c/i2c.txt
View File

@@ -95,6 +95,10 @@ wants to support one of the below features, it should adapt these bindings.
- smbus-alert
states that the optional SMBus-Alert feature apply to this bus.
- mctp-controller
indicates that the system is accessible via this bus as an endpoint for
MCTP over I2C transport.
Required properties (per child device)
--------------------------------------

3
Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml
View File

@@ -10,6 +10,9 @@ maintainers:
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
allOf:
- $ref: can-controller.yaml#
properties:
compatible:
oneOf:

9
Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
View File

@@ -9,7 +9,10 @@ title: Bosch MCAN controller Bindings
description: Bosch MCAN controller for CAN bus
maintainers:
- Sriram Dash <sriram.dash@samsung.com>
- Chandrasekar Ramakrishnan <rcsekar@samsung.com>
allOf:
- $ref: can-controller.yaml#
properties:
compatible:
@@ -66,8 +69,8 @@ properties:
M_CAN includes the following elements according to user manual:
11-bit Filter 0-128 elements / 0-128 words
29-bit Filter 0-64 elements / 0-128 words
Rx FIFO 0 0-64 elements / 0-1152 words
Rx FIFO 1 0-64 elements / 0-1152 words
Rx FIFO 0 0-64 elements / 0-1152 words
Rx FIFO 1 0-64 elements / 0-1152 words
Rx Buffers 0-64 elements / 0-1152 words
Tx Event FIFO 0-32 elements / 0-64 words
Tx Buffers 0-32 elements / 0-576 words

3
Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml
View File

@@ -11,6 +11,9 @@ title:
maintainers:
- Marc Kleine-Budde <mkl@pengutronix.de>
allOf:
- $ref: can-controller.yaml#
properties:
compatible:
oneOf:

2
Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml
View File

@@ -35,6 +35,8 @@ properties:
- renesas,r9a07g044-canfd # RZ/G2{L,LC}
- const: renesas,rzg2l-canfd # RZ/G2L family
- const: renesas,r8a779a0-canfd # R-Car V3U
reg:
maxItems: 1

161
Documentation/devicetree/bindings/net/can/xilinx,can.yaml Normal file
View File

@@ -0,0 +1,161 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/can/xilinx,can.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title:
Xilinx Axi CAN/Zynq CANPS controller
maintainers:
- Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com>
properties:
compatible:
enum:
- xlnx,zynq-can-1.0
- xlnx,axi-can-1.00.a
- xlnx,canfd-1.0
- xlnx,canfd-2.0
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
minItems: 1
maxItems: 2
clock-names:
maxItems: 2
power-domains:
maxItems: 1
tx-fifo-depth:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: CAN Tx fifo depth (Zynq, Axi CAN).
rx-fifo-depth:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: CAN Rx fifo depth (Zynq, Axi CAN, CAN FD in sequential Rx mode)
tx-mailbox-count:
$ref: "/schemas/types.yaml#/definitions/uint32"
description: CAN Tx mailbox buffer count (CAN FD)
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
unevaluatedProperties: false
allOf:
- $ref: can-controller.yaml#
- if:
properties:
compatible:
contains:
enum:
- xlnx,zynq-can-1.0
then:
properties:
clock-names:
items:
- const: can_clk
- const: pclk
required:
- tx-fifo-depth
- rx-fifo-depth
- if:
properties:
compatible:
contains:
enum:
- xlnx,axi-can-1.00.a
then:
properties:
clock-names:
items:
- const: can_clk
- const: s_axi_aclk
required:
- tx-fifo-depth
- rx-fifo-depth
- if:
properties:
compatible:
contains:
enum:
- xlnx,canfd-1.0
- xlnx,canfd-2.0
then:
properties:
clock-names:
items:
- const: can_clk
- const: s_axi_aclk
required:
- tx-mailbox-count
- rx-fifo-depth
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
can@e0008000 {
compatible = "xlnx,zynq-can-1.0";
reg = <0xe0008000 0x1000>;
clocks = <&clkc 19>, <&clkc 36>;
clock-names = "can_clk", "pclk";
interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&intc>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};
- |
can@40000000 {
compatible = "xlnx,axi-can-1.00.a";
reg = <0x40000000 0x10000>;
clocks = <&clkc 0>, <&clkc 1>;
clock-names = "can_clk", "s_axi_aclk";
interrupt-parent = <&intc>;
interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};
- |
can@40000000 {
compatible = "xlnx,canfd-1.0";
reg = <0x40000000 0x2000>;
clocks = <&clkc 0>, <&clkc 1>;
clock-names = "can_clk", "s_axi_aclk";
interrupt-parent = <&intc>;
interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>;
tx-mailbox-count = <0x20>;
rx-fifo-depth = <0x20>;
};
- |
can@ff060000 {
compatible = "xlnx,canfd-2.0";
reg = <0xff060000 0x6000>;
clocks = <&clkc 0>, <&clkc 1>;
clock-names = "can_clk", "s_axi_aclk";
interrupt-parent = <&intc>;
interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>;
tx-mailbox-count = <0x20>;
rx-fifo-depth = <0x40>;
};

61
Documentation/devicetree/bindings/net/can/xilinx_can.txt
View File

@@ -1,61 +0,0 @@
Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
---------------------------------------------------------
Required properties:
- compatible : Should be:
- "xlnx,zynq-can-1.0" for Zynq CAN controllers
- "xlnx,axi-can-1.00.a" for Axi CAN controllers
- "xlnx,canfd-1.0" for CAN FD controllers
- "xlnx,canfd-2.0" for CAN FD 2.0 controllers
- reg : Physical base address and size of the controller
registers map.
- interrupts : Property with a value describing the interrupt
number.
- clock-names : List of input clock names
- "can_clk", "pclk" (For CANPS),
- "can_clk", "s_axi_aclk" (For AXI CAN and CAN FD).
(See clock bindings for details).
- clocks : Clock phandles (see clock bindings for details).
- tx-fifo-depth : Can Tx fifo depth (Zynq, Axi CAN).
- rx-fifo-depth : Can Rx fifo depth (Zynq, Axi CAN, CAN FD in
sequential Rx mode).
- tx-mailbox-count : Can Tx mailbox buffer count (CAN FD).
- rx-mailbox-count : Can Rx mailbox buffer count (CAN FD in mailbox Rx
mode).
Example:
For Zynq CANPS Dts file:
zynq_can_0: can@e0008000 {
compatible = "xlnx,zynq-can-1.0";
clocks = <&clkc 19>, <&clkc 36>;
clock-names = "can_clk", "pclk";
reg = <0xe0008000 0x1000>;
interrupts = <0 28 4>;
interrupt-parent = <&intc>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};
For Axi CAN Dts file:
axi_can_0: axi-can@40000000 {
compatible = "xlnx,axi-can-1.00.a";
clocks = <&clkc 0>, <&clkc 1>;
clock-names = "can_clk","s_axi_aclk" ;
reg = <0x40000000 0x10000>;
interrupt-parent = <&intc>;
interrupts = <0 59 1>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};
For CAN FD Dts file:
canfd_0: canfd@40000000 {
compatible = "xlnx,canfd-1.0";
clocks = <&clkc 0>, <&clkc 1>;
clock-names = "can_clk", "s_axi_aclk";
reg = <0x40000000 0x2000>;
interrupt-parent = <&intc>;
interrupts = <0 59 1>;
tx-mailbox-count = <0x20>;
rx-fifo-depth = <0x20>;
};

56
Documentation/devicetree/bindings/net/cdns,macb.yaml
View File

@@ -81,6 +81,25 @@ properties:
phy-handle: true
phys:
maxItems: 1
phy-names:
const: sgmii-phy
description:
Required with ZynqMP SoC when in SGMII mode.
Should reference PS-GTR generic PHY device for this controller
instance. See ZynqMP example.
resets:
maxItems: 1
description:
Recommended with ZynqMP, specify reset control for this
controller instance with zynqmp-reset driver.
reset-names:
maxItems: 1
fixed-link: true
iommus:
@@ -157,3 +176,40 @@ examples:
reset-gpios = <&pioE 6 1>;
};
};
- |
#include <dt-bindings/clock/xlnx-zynqmp-clk.h>
#include <dt-bindings/power/xlnx-zynqmp-power.h>
#include <dt-bindings/reset/xlnx-zynqmp-resets.h>
#include <dt-bindings/phy/phy.h>
bus {
#address-cells = <2>;
#size-cells = <2>;
gem1: ethernet@ff0c0000 {
compatible = "cdns,zynqmp-gem", "cdns,gem";
interrupt-parent = <&gic>;
interrupts = <0 59 4>, <0 59 4>;
reg = <0x0 0xff0c0000 0x0 0x1000>;
clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
<&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
<&zynqmp_clk GEM_TSU>;
clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
#address-cells = <1>;
#size-cells = <0>;
#stream-id-cells = <1>;
iommus = <&smmu 0x875>;
power-domains = <&zynqmp_firmware PD_ETH_1>;
resets = <&zynqmp_reset ZYNQMP_RESET_GEM1>;
reset-names = "gem1_rst";
status = "okay";
phy-mode = "sgmii";
phy-names = "sgmii-phy";
phys = <&psgtr 1 PHY_TYPE_SGMII 1 1>;
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};

62
Documentation/devicetree/bindings/net/davicom,dm9051.yaml Normal file
View File

@@ -0,0 +1,62 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/davicom,dm9051.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Davicom DM9051 SPI Ethernet Controller
maintainers:
- Joseph CHANG <josright123@gmail.com>
description: |
The DM9051 is a fully integrated and cost-effective low pin count single
chip Fast Ethernet controller with a Serial Peripheral Interface (SPI).
allOf:
- $ref: ethernet-controller.yaml#
properties:
compatible:
const: davicom,dm9051
reg:
maxItems: 1
spi-max-frequency:
maximum: 45000000
interrupts:
maxItems: 1
local-mac-address: true
mac-address: true
required:
- compatible
- reg
- spi-max-frequency
- interrupts
additionalProperties: false
examples:
# Raspberry Pi platform
- |
/* for Raspberry Pi with pin control stuff for GPIO irq */
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
spi {
#address-cells = <1>;
#size-cells = <0>;
ethernet@0 {
compatible = "davicom,dm9051";
reg = <0>; /* spi chip select */
local-mac-address = [00 00 00 00 00 00];
interrupt-parent = <&gpio>;
interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
spi-max-frequency = <31200000>;
};
};

2
Documentation/devicetree/bindings/net/dsa/dsa-port.yaml
View File

@@ -51,6 +51,8 @@ properties:
- edsa
- ocelot
- ocelot-8021q
- rtl8_4
- rtl8_4t
- seville
phy-handle: true

6
Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
View File

@@ -42,6 +42,12 @@ properties:
description:
Set if the output SYNCLKO frequency should be set to 125MHz instead of 25MHz.
microchip,synclko-disable:
$ref: /schemas/types.yaml#/definitions/flag
description:
Set if the output SYNCLKO clock should be disabled. Do not mix with
microchip,synclko-125.
required:
- compatible
- reg

240
Documentation/devicetree/bindings/net/dsa/realtek-smi.txt
View File

@@ -1,240 +0,0 @@
Realtek SMI-based Switches
==========================
The SMI "Simple Management Interface" is a two-wire protocol using
bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
not use the MDIO protocol. This binding defines how to specify the
SMI-based Realtek devices.
Required properties:
- compatible: must be exactly one of:
"realtek,rtl8365mb" (4+1 ports)
"realtek,rtl8366"
"realtek,rtl8366rb" (4+1 ports)
"realtek,rtl8366s" (4+1 ports)
"realtek,rtl8367"
"realtek,rtl8367b"
"realtek,rtl8368s" (8 port)
"realtek,rtl8369"
"realtek,rtl8370" (8 port)
Required properties:
- mdc-gpios: GPIO line for the MDC clock line.
- mdio-gpios: GPIO line for the MDIO data line.
- reset-gpios: GPIO line for the reset signal.
Optional properties:
- realtek,disable-leds: if the LED drivers are not used in the
hardware design this will disable them so they are not turned on
and wasting power.
Required subnodes:
- interrupt-controller
This defines an interrupt controller with an IRQ line (typically
a GPIO) that will demultiplex and handle the interrupt from the single
interrupt line coming out of one of the SMI-based chips. It most
importantly provides link up/down interrupts to the PHY blocks inside
the ASIC.
Required properties of interrupt-controller:
- interrupt: parent interrupt, see interrupt-controller/interrupts.txt
- interrupt-controller: see interrupt-controller/interrupts.txt
- #address-cells: should be <0>
- #interrupt-cells: should be <1>
- mdio
This defines the internal MDIO bus of the SMI device, mostly for the
purpose of being able to hook the interrupts to the right PHY and
the right PHY to the corresponding port.
Required properties of mdio:
- compatible: should be set to "realtek,smi-mdio" for all SMI devices
See net/mdio.txt for additional MDIO bus properties.
See net/dsa/dsa.txt for a list of additional required and optional properties
and subnodes of DSA switches.
Examples:
An example for the RTL8366RB:
switch {
compatible = "realtek,rtl8366rb";
/* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
switch_intc: interrupt-controller {
/* GPIO 15 provides the interrupt */
interrupt-parent = <&gpio0>;
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
ports {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
port@0 {
reg = <0>;
label = "lan0";
phy-handle = <&phy0>;
};
port@1 {
reg = <1>;
label = "lan1";
phy-handle = <&phy1>;
};
port@2 {
reg = <2>;
label = "lan2";
phy-handle = <&phy2>;
};
port@3 {
reg = <3>;
label = "lan3";
phy-handle = <&phy3>;
};
port@4 {
reg = <4>;
label = "wan";
phy-handle = <&phy4>;
};
port@5 {
reg = <5>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
mdio {
compatible = "realtek,smi-mdio", "dsa-mdio";
#address-cells = <1>;
#size-cells = <0>;
phy0: phy@0 {
reg = <0>;
interrupt-parent = <&switch_intc>;
interrupts = <0>;
};
phy1: phy@1 {
reg = <1>;
interrupt-parent = <&switch_intc>;
interrupts = <1>;
};
phy2: phy@2 {
reg = <2>;
interrupt-parent = <&switch_intc>;
interrupts = <2>;
};
phy3: phy@3 {
reg = <3>;
interrupt-parent = <&switch_intc>;
interrupts = <3>;
};
phy4: phy@4 {
reg = <4>;
interrupt-parent = <&switch_intc>;
interrupts = <12>;
};
};
};
An example for the RTL8365MB-VC:
switch {
compatible = "realtek,rtl8365mb";
mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
switch_intc: interrupt-controller {
interrupt-parent = <&gpio5>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
ports {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
port@0 {
reg = <0>;
label = "swp0";
phy-handle = <&ethphy0>;
};
port@1 {
reg = <1>;
label = "swp1";
phy-handle = <&ethphy1>;
};
port@2 {
reg = <2>;
label = "swp2";
phy-handle = <&ethphy2>;
};
port@3 {
reg = <3>;
label = "swp3";
phy-handle = <&ethphy3>;
};
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&fec1>;
phy-mode = "rgmii";
tx-internal-delay-ps = <2000>;
rx-internal-delay-ps = <2000>;
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
mdio {
compatible = "realtek,smi-mdio";
#address-cells = <1>;
#size-cells = <0>;
ethphy0: phy@0 {
reg = <0>;
interrupt-parent = <&switch_intc>;
interrupts = <0>;
};
ethphy1: phy@1 {
reg = <1>;
interrupt-parent = <&switch_intc>;
interrupts = <1>;
};
ethphy2: phy@2 {
reg = <2>;
interrupt-parent = <&switch_intc>;
interrupts = <2>;
};
ethphy3: phy@3 {
reg = <3>;
interrupt-parent = <&switch_intc>;
interrupts = <3>;
};
};
};

394
Documentation/devicetree/bindings/net/dsa/realtek.yaml Normal file
View File

@@ -0,0 +1,394 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/realtek.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Realtek switches for unmanaged switches
allOf:
- $ref: dsa.yaml#
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description:
Realtek advertises these chips as fast/gigabit switches or unmanaged
switches. They can be controlled using different interfaces, like SMI,
MDIO or SPI.
The SMI "Simple Management Interface" is a two-wire protocol using
bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does
not use the MDIO protocol. This binding defines how to specify the
SMI-based Realtek devices. The realtek-smi driver is a platform driver
and it must be inserted inside a platform node.
The MDIO-connected switches use MDIO protocol to access their registers.
The realtek-mdio driver is an MDIO driver and it must be inserted inside
an MDIO node.
properties:
compatible:
enum:
- realtek,rtl8365mb
- realtek,rtl8366
- realtek,rtl8366rb
- realtek,rtl8366s
- realtek,rtl8367
- realtek,rtl8367b
- realtek,rtl8367rb
- realtek,rtl8367s
- realtek,rtl8368s
- realtek,rtl8369
- realtek,rtl8370
description: |
realtek,rtl8365mb: 4+1 ports
realtek,rtl8366: 5+1 ports
realtek,rtl8366rb: 5+1 ports
realtek,rtl8366s: 5+1 ports
realtek,rtl8367:
realtek,rtl8367b:
realtek,rtl8367rb: 5+2 ports
realtek,rtl8367s: 5+2 ports
realtek,rtl8368s: 8 ports
realtek,rtl8369: 8+1 ports
realtek,rtl8370: 8+2 ports
mdc-gpios:
description: GPIO line for the MDC clock line.
maxItems: 1
mdio-gpios:
description: GPIO line for the MDIO data line.
maxItems: 1
reset-gpios:
description: GPIO to be used to reset the whole device
maxItems: 1
realtek,disable-leds:
type: boolean
description: |
if the LED drivers are not used in the hardware design,
this will disable them so they are not turned on
and wasting power.
interrupt-controller:
type: object
description: |
This defines an interrupt controller with an IRQ line (typically
a GPIO) that will demultiplex and handle the interrupt from the single
interrupt line coming out of one of the Realtek switch chips. It most
importantly provides link up/down interrupts to the PHY blocks inside
the ASIC.
properties:
interrupt-controller: true
interrupts:
maxItems: 1
description:
A single IRQ line from the switch, either active LOW or HIGH
'#address-cells':
const: 0
'#interrupt-cells':
const: 1
required:
- interrupt-controller
- '#address-cells'
- '#interrupt-cells'
mdio:
$ref: /schemas/net/mdio.yaml#
unevaluatedProperties: false
properties:
compatible:
const: realtek,smi-mdio
if:
required:
- reg
then:
not:
required:
- mdc-gpios
- mdio-gpios
- mdio
properties:
mdc-gpios: false
mdio-gpios: false
mdio: false
else:
required:
- mdc-gpios
- mdio-gpios
- mdio
- reset-gpios
required:
- compatible
# - mdc-gpios
# - mdio-gpios
# - reset-gpios
# - mdio
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
platform {
switch {
compatible = "realtek,rtl8366rb";
/* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */
mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>;
mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>;
switch_intc1: interrupt-controller {
/* GPIO 15 provides the interrupt */
interrupt-parent = <&gpio0>;
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
phy-handle = <&phy0>;
};
port@1 {
reg = <1>;
label = "lan1";
phy-handle = <&phy1>;
};
port@2 {
reg = <2>;
label = "lan2";
phy-handle = <&phy2>;
};
port@3 {
reg = <3>;
label = "lan3";
phy-handle = <&phy3>;
};
port@4 {
reg = <4>;
label = "wan";
phy-handle = <&phy4>;
};
port@5 {
reg = <5>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
mdio {
compatible = "realtek,smi-mdio";
#address-cells = <1>;
#size-cells = <0>;
phy0: ethernet-phy@0 {
reg = <0>;
interrupt-parent = <&switch_intc1>;
interrupts = <0>;
};
phy1: ethernet-phy@1 {
reg = <1>;
interrupt-parent = <&switch_intc1>;
interrupts = <1>;
};
phy2: ethernet-phy@2 {
reg = <2>;
interrupt-parent = <&switch_intc1>;
interrupts = <2>;
};
phy3: ethernet-phy@3 {
reg = <3>;
interrupt-parent = <&switch_intc1>;
interrupts = <3>;
};
phy4: ethernet-phy@4 {
reg = <4>;
interrupt-parent = <&switch_intc1>;
interrupts = <12>;
};
};
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
platform {
switch {
compatible = "realtek,rtl8365mb";
mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
switch_intc2: interrupt-controller {
interrupt-parent = <&gpio5>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "swp0";
phy-handle = <&ethphy0>;
};
port@1 {
reg = <1>;
label = "swp1";
phy-handle = <&ethphy1>;
};
port@2 {
reg = <2>;
label = "swp2";
phy-handle = <&ethphy2>;
};
port@3 {
reg = <3>;
label = "swp3";
phy-handle = <&ethphy3>;
};
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&fec1>;
phy-mode = "rgmii";
tx-internal-delay-ps = <2000>;
rx-internal-delay-ps = <2000>;
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
mdio {
compatible = "realtek,smi-mdio";
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
reg = <0>;
interrupt-parent = <&switch_intc2>;
interrupts = <0>;
};
ethphy1: ethernet-phy@1 {
reg = <1>;
interrupt-parent = <&switch_intc2>;
interrupts = <1>;
};
ethphy2: ethernet-phy@2 {
reg = <2>;
interrupt-parent = <&switch_intc2>;
interrupts = <2>;
};
ethphy3: ethernet-phy@3 {
reg = <3>;
interrupt-parent = <&switch_intc2>;
interrupts = <3>;
};
};
};
};
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
mdio {
#address-cells = <1>;
#size-cells = <0>;
switch@29 {
compatible = "realtek,rtl8367s";
reg = <29>;
reset-gpios = <&gpio2 20 GPIO_ACTIVE_LOW>;
switch_intc3: interrupt-controller {
interrupt-parent = <&gpio0>;
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan4";
};
port@1 {
reg = <1>;
label = "lan3";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan1";
};
port@4 {
reg = <4>;
label = "wan";
};
port@7 {
reg = <7>;
ethernet = <&ethernet>;
phy-mode = "rgmii";
tx-internal-delay-ps = <2000>;
rx-internal-delay-ps = <0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};

Some files were not shown because too many files have changed in this diff Show More