diff options
| author | Linus Torvalds <torvalds@linux-foundation.org> | 2024-07-16 19:28:34 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2024-07-16 19:28:34 -0700 |
| commit | 51835949dda3783d4639cfa74ce13a3c9829de00 (patch) | |
| tree | 2b593de5eba6ecc73f7c58fc65fdaffae45c7323 /Documentation | |
| parent | 0434dbe32053d07d658165be681505120c6b1abc (diff) | |
| parent | 77ae5e5b00720372af2860efdc4bc652ac682696 (diff) | |
Merge tag 'net-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-nextHEADmaster
Pull networking updates from Jakub Kicinski:
"Not much excitement - a handful of large patchsets (devmem among them)
did not make it in time.
Core & protocols:
- Use local_lock in addition to local_bh_disable() to protect per-CPU
resources in networking, a step closer for local_bh_disable() not
to act as a big lock on PREEMPT_RT
- Use flex array for netdevice priv area, ensure its cache alignment
- Add a sysctl knob to allow user to specify a default rto_min at
socket init time. Bit of a big hammer but multiple companies were
independently carrying such patch downstream so clearly it's useful
- Support scheduling transmission of packets based on CLOCK_TAI
- Un-pin TCP TIMEWAIT timer to avoid it firing on CPUs later cordoned
off using cpusets
- Support multiple L2TPv3 UDP tunnels using the same 5-tuple address
- Allow configuration of multipath hash seed, to both allow
synchronizing hashing of two routers, and preventing partial
accidental sync
- Improve TCP compliance with RFC 9293 for simultaneous connect()
- Support sending NAT keepalives in IPsec ESP in UDP states.
Userspace IKE daemon had to do this before, but the kernel can
better keep track of it
- Support sending supervision HSR frames with MAC addresses stored in
ProxyNodeTable when RedBox (i.e. HSR-SAN) is enabled
- Introduce IPPROTO_SMC for selecting SMC when socket is created
- Allow UDP GSO transmit from devices with no checksum offload
- openvswitch: add packet sampling via psample, separating the
sampled traffic from "upcall" packets sent to user space for
forwarding
- nf_tables: shrink memory consumption for transaction objects
Things we sprinkled into general kernel code:
- Power Sequencing subsystem (used by Qualcomm Bluetooth driver for
QCA6390) [ Already merged separately - Linus ]
- Add IRQ information in sysfs for auxiliary bus
- Introduce guard definition for local_lock
- Add aligned flavor of __cacheline_group_{begin, end}() markings for
grouping fields in structures
BPF:
- Notify user space (via epoll) when a struct_ops object is getting
detached/unregistered
- Add new kfuncs for a generic, open-coded bits iterator
- Enable BPF programs to declare arrays of kptr, bpf_rb_root, and
bpf_list_head
- Support resilient split BTF which cuts down on duplication and
makes BTF as compact as possible WRT BTF from modules
- Add support for dumping kfunc prototypes from BTF which enables
both detecting as well as dumping compilable prototypes for kfuncs
- riscv64 BPF JIT improvements in particular to add 12-argument
support for BPF trampolines and to utilize bpf_prog_pack for the
latter
- Add the capability to offload the netfilter flowtable in XDP layer
through kfuncs
Driver API:
- Allow users to configure IRQ tresholds between which automatic IRQ
moderation can choose
- Expand Power Sourcing (PoE) status with power, class and failure
reason. Support setting power limits
- Track additional RSS contexts in the core, make sure configuration
changes don't break them
- Support IPsec crypto offload for IPv6 ESP and IPv4 UDP-encapsulated
ESP data paths
- Support updating firmware on SFP modules
Tests and tooling:
- mptcp: use net/lib.sh to manage netns
- TCP-AO and TCP-MD5: replace debug prints used by tests with
tracepoints
- openvswitch: make test self-contained (don't depend on OvS CLI
tools)
Drivers:
- Ethernet high-speed NICs:
- Broadcom (bnxt):
- increase the max total outstanding PTP TX packets to 4
- add timestamping statistics support
- implement netdev_queue_mgmt_ops
- support new RSS context API
- Intel (100G, ice, idpf):
- implement FEC statistics and dumping signal quality indicators
- support E825C products (with 56Gbps PHYs)
- nVidia/Mellanox:
- support HW-GRO
- mlx4/mlx5: support per-queue statistics via netlink
- obey the max number of EQs setting in sub-functions
- AMD/Solarflare:
- support new RSS context API
- AMD/Pensando:
- ionic: rework fix for doorbell miss to lower overhead and
skip it on new HW
- Wangxun:
- txgbe: support Flow Director perfect filters
- Ethernet NICs consumer, embedded and virtual:
- Add driver for Tehuti Networks TN40xx chips
- Add driver for Meta's internal NIC chips
- Add driver for Ethernet MAC on Airoha EN7581 SoCs
- Add driver for Renesas Ethernet-TSN devices
- Google cloud vNIC:
- flow steering support
- Microsoft vNIC:
- support page sizes other than 4KB on ARM64
- vmware vNIC:
- support latency measurement (update to version 9)
- VirtIO net:
- support for Byte Queue Limits
- support configuring thresholds for automatic IRQ moderation
- support for AF_XDP Rx zero-copy
- Synopsys (stmmac):
- support for STM32MP13 SoC
- let platforms select the right PCS implementation
- TI:
- icssg-prueth: add multicast filtering support
- icssg-prueth: enable PTP timestamping and PPS
- Renesas:
- ravb: improve Rx performance 30-400% by using page pool,
theaded NAPI and timer-based IRQ coalescing
- ravb: add MII support for R-Car V4M
- Cadence (macb):
- macb: add ARP support to Wake-On-LAN
- Cortina:
- use phylib for RX and TX pause configuration
- Ethernet switches:
- nVidia/Mellanox:
- support configuration of multipath hash seed
- report more accurate max MTU
- use page_pool to improve Rx performance
- MediaTek:
- mt7530: add support for bridge port isolation
- Qualcomm:
- qca8k: add support for bridge port isolation
- Microchip:
- lan9371/2: add 100BaseTX PHY support
- NXP:
- vsc73xx: implement VLAN operations
- Ethernet PHYs:
- aquantia: enable support for aqr115c
- aquantia: add support for PHY LEDs
- realtek: add support for rtl8224 2.5Gbps PHY
- xpcs: add memory-mapped device support
- add BroadR-Reach link mode and support in Broadcom's PHY driver
- CAN:
- add document for ISO 15765-2 protocol support
- mcp251xfd: workaround for erratum DS80000789E, use timestamps to
catch when device returns incorrect FIFO status
- WiFi:
- mac80211/cfg80211:
- parse Transmit Power Envelope (TPE) data in mac80211 instead
of in drivers
- improvements for 6 GHz regulatory flexibility
- multi-link improvements
- support multiple radios per wiphy
- remove DEAUTH_NEED_MGD_TX_PREP flag
- Intel (iwlwifi):
- bump FW API to 91 for BZ/SC devices
- report 64-bit radiotap timestamp
- enable P2P low latency by default
- handle Transmit Power Envelope (TPE) advertised by AP
- remove support for older FW for new devices
- fast resume (keeping the device configured)
- mvm: re-enable Multi-Link Operation (MLO)
- aggregation (A-MSDU) optimizations
- MediaTek (mt76):
- mt7925 Multi-Link Operation (MLO) support
- Qualcomm (ath10k):
- LED support for various chipsets
- Qualcomm (ath12k):
- remove unsupported Tx monitor handling
- support channel 2 in 6 GHz band
- support Spatial Multiplexing Power Save (SMPS) in 6 GHz band
- supprt multiple BSSID (MBSSID) and Enhanced Multi-BSSID
Advertisements (EMA)
- support dynamic VLAN
- add panic handler for resetting the firmware state
- DebugFS support for datapath statistics
- WCN7850: support for Wake on WLAN
- Microchip (wilc1000):
- read MAC address during probe to make it visible to user space
- suspend/resume improvements
- TI (wl18xx):
- support newer firmware versions
- RealTek (rtw89):
- preparation for RTL8852BE-VT support
- Wake on WLAN support for WiFi 6 chips
- 36-bit PCI DMA support
- RealTek (rtlwifi):
- RTL8192DU support
- Broadcom (brcmfmac):
- Management Frame Protection support (to enable WPA3)
- Bluetooth:
- qualcomm: use the power sequencer for QCA6390
- btusb: mediatek: add ISO data transmission functions
- hci_bcm4377: add BCM4388 support
- btintel: add support for BlazarU core
- btintel: add support for Whale Peak2
- btnxpuart: add support for AW693 A1 chipset
- btnxpuart: add support for IW615 chipset
- btusb: add Realtek RTL8852BE support ID 0x13d3:0x3591"
* tag 'net-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1589 commits)
eth: fbnic: Fix spelling mistake "tiggerring" -> "triggering"
tcp: Replace strncpy() with strscpy()
wifi: ath12k: fix build vs old compiler
tcp: Don't access uninit tcp_rsk(req)->ao_keyid in tcp_create_openreq_child().
eth: fbnic: Write the TCAM tables used for RSS control and Rx to host
eth: fbnic: Add L2 address programming
eth: fbnic: Add basic Rx handling
eth: fbnic: Add basic Tx handling
eth: fbnic: Add link detection
eth: fbnic: Add initial messaging to notify FW of our presence
eth: fbnic: Implement Rx queue alloc/start/stop/free
eth: fbnic: Implement Tx queue alloc/start/stop/free
eth: fbnic: Allocate a netdevice and napi vectors with queues
eth: fbnic: Add FW communication mechanism
eth: fbnic: Add message parsing for FW messages
eth: fbnic: Add register init to set PCIe/Ethernet device config
eth: fbnic: Allocate core device specific structures and devlink interface
eth: fbnic: Add scaffolding for Meta's NIC driver
PCI: Add Meta Platforms vendor ID
net/sched: cls_flower: propagate tca[TCA_OPTIONS] to NL_REQ_ATTR_CHECK
...
Diffstat (limited to 'Documentation')
62 files changed, 3308 insertions, 1430 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-auxiliary b/Documentation/ABI/testing/sysfs-bus-auxiliary new file mode 100644 index 000000000000..cc856079690f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-auxiliary @@ -0,0 +1,9 @@ +What: /sys/bus/auxiliary/devices/.../irqs/ +Date: April, 2024 +Contact: Shay Drory <shayd@nvidia.com> +Description: + The /sys/devices/.../irqs directory contains a variable set of + files, with each file is named as irq number similar to PCI PF + or VF's irq number located in msi_irqs directory. + These irq files are added and removed dynamically when an IRQ + is requested and freed respectively for the PCI SF. diff --git a/Documentation/bpf/libbpf/libbpf_overview.rst b/Documentation/bpf/libbpf/libbpf_overview.rst index f36a2d4ffea2..f4d22f0c62b0 100644 --- a/Documentation/bpf/libbpf/libbpf_overview.rst +++ b/Documentation/bpf/libbpf/libbpf_overview.rst @@ -219,6 +219,14 @@ compilation and skeleton generation. Using Libbpf-rs will make building user space part of the BPF application easier. Note that the BPF program themselves must still be written in plain C. +libbpf logging +============== + +By default, libbpf logs informational and warning messages to stderr. The +verbosity of these messages can be controlled by setting the environment +variable LIBBPF_LOG_LEVEL to either warn, info, or debug. A custom log +callback can be set using ``libbpf_set_print()``. + Additional Documentation ======================== diff --git a/Documentation/bpf/standardization/abi.rst b/Documentation/bpf/standardization/abi.rst index 0c2e10eeb89a..41514137cb7b 100644 --- a/Documentation/bpf/standardization/abi.rst +++ b/Documentation/bpf/standardization/abi.rst @@ -23,3 +23,6 @@ The BPF calling convention is defined as: R0 - R5 are scratch registers and BPF programs needs to spill/fill them if necessary across calls. + +The BPF program needs to store the return value into register R0 before doing an +``EXIT``. diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst index 00c93eb42613..ab820d565052 100644 --- a/Documentation/bpf/standardization/instruction-set.rst +++ b/Documentation/bpf/standardization/instruction-set.rst @@ -5,15 +5,29 @@ BPF Instruction Set Architecture (ISA) ====================================== -eBPF (which is no longer an acronym for anything), also commonly +eBPF, also commonly referred to as BPF, is a technology with origins in the Linux kernel that can run untrusted programs in a privileged context such as an operating system kernel. This document specifies the BPF instruction set architecture (ISA). +As a historical note, BPF originally stood for Berkeley Packet Filter, +but now that it can do so much more than packet filtering, the acronym +no longer makes sense. BPF is now considered a standalone term that +does not stand for anything. The original BPF is sometimes referred to +as cBPF (classic BPF) to distinguish it from the now widely deployed +eBPF (extended BPF). + Documentation conventions ========================= +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and +"OPTIONAL" in this document are to be interpreted as described in +BCP 14 `<https://www.rfc-editor.org/info/rfc2119>`_ +`<https://www.rfc-editor.org/info/rfc8174>`_ +when, and only when, they appear in all capitals, as shown here. + 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. @@ -25,7 +39,7 @@ 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. +.. table:: Meaning of signedness notation ==== ========= S Meaning @@ -34,7 +48,7 @@ a type's signedness (`S`) and bit width (`N`), respectively. s signed ==== ========= -.. table:: Meaning of bit-width notation. +.. table:: Meaning of bit-width notation ===== ========= N Bit width @@ -52,24 +66,18 @@ 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. + +The following byteswap functions are direction-agnostic. That is, +the same function is used for conversion in either direction discussed +below. + +* be16: Takes an unsigned 16-bit number and converts it between + host byte order and big-endian + (`IEN137 <https://www.rfc-editor.org/ien/ien137.txt>`_) byte order. +* be32: Takes an unsigned 32-bit number and converts it between + host byte order and big-endian byte order. +* be64: Takes an unsigned 64-bit number and converts it between + host byte order and big-endian byte order. * 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. @@ -79,7 +87,12 @@ Functions * 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. - +* le16: Takes an unsigned 16-bit number and converts it between + host byte order and little-endian byte order. +* le32: Takes an unsigned 32-bit number and converts it between + host byte order and little-endian byte order. +* le64: Takes an unsigned 64-bit number and converts it between + host byte order and little-endian byte order. Definitions ----------- @@ -106,9 +119,9 @@ Conformance groups An implementation does not need to support all instructions specified in this document (e.g., deprecated instructions). Instead, a number of conformance -groups are specified. An implementation must support the base32 conformance -group and may support additional conformance groups, where supporting a -conformance group means it must support all instructions in that conformance +groups are specified. An implementation MUST support the base32 conformance +group and MAY support additional conformance groups, where supporting a +conformance group means it MUST support all instructions in that conformance group. The use of named conformance groups enables interoperability between a runtime @@ -209,7 +222,7 @@ For example:: 07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big Note that most instructions do not use all of the fields. -Unused fields shall be cleared to zero. +Unused fields SHALL be cleared to zero. Wide instruction encoding -------------------------- @@ -256,18 +269,20 @@ Instruction classes The three least significant bits of the 'opcode' field store the instruction class: -===== ===== =============================== =================================== -class value description reference -===== ===== =============================== =================================== -LD 0x0 non-standard load operations `Load and store instructions`_ -LDX 0x1 load into register operations `Load and store instructions`_ -ST 0x2 store from immediate operations `Load and store instructions`_ -STX 0x3 store from register operations `Load and store instructions`_ -ALU 0x4 32-bit arithmetic operations `Arithmetic and jump instructions`_ -JMP 0x5 64-bit jump operations `Arithmetic and jump instructions`_ -JMP32 0x6 32-bit jump operations `Arithmetic and jump instructions`_ -ALU64 0x7 64-bit arithmetic operations `Arithmetic and jump instructions`_ -===== ===== =============================== =================================== +.. table:: Instruction class + + ===== ===== =============================== =================================== + class value description reference + ===== ===== =============================== =================================== + LD 0x0 non-standard load operations `Load and store instructions`_ + LDX 0x1 load into register operations `Load and store instructions`_ + ST 0x2 store from immediate operations `Load and store instructions`_ + STX 0x3 store from register operations `Load and store instructions`_ + ALU 0x4 32-bit arithmetic operations `Arithmetic and jump instructions`_ + JMP 0x5 64-bit jump operations `Arithmetic and jump instructions`_ + JMP32 0x6 32-bit jump operations `Arithmetic and jump instructions`_ + ALU64 0x7 64-bit arithmetic operations `Arithmetic and jump instructions`_ + ===== ===== =============================== =================================== Arithmetic and jump instructions ================================ @@ -285,12 +300,14 @@ For arithmetic and jump instructions (``ALU``, ``ALU64``, ``JMP`` and **s (source)** the source operand location, which unless otherwise specified is one of: - ====== ===== ============================================== - source value description - ====== ===== ============================================== - K 0 use 32-bit 'imm' value as source operand - X 1 use 'src_reg' register value as source operand - ====== ===== ============================================== + .. table:: Source operand location + + ====== ===== ============================================== + source value description + ====== ===== ============================================== + K 0 use 32-bit 'imm' value as source operand + X 1 use 'src_reg' register value as source operand + ====== ===== ============================================== **instruction class** the instruction class (see `Instruction classes`_) @@ -305,27 +322,29 @@ The 'code' field encodes the operation as below, where 'src' refers to the the source operand and 'dst' refers to the value of the destination register. -===== ===== ======= ========================================================== -name code offset description -===== ===== ======= ========================================================== -ADD 0x0 0 dst += src -SUB 0x1 0 dst -= src -MUL 0x2 0 dst \*= src -DIV 0x3 0 dst = (src != 0) ? (dst / src) : 0 -SDIV 0x3 1 dst = (src != 0) ? (dst s/ src) : 0 -OR 0x4 0 dst \|= src -AND 0x5 0 dst &= src -LSH 0x6 0 dst <<= (src & mask) -RSH 0x7 0 dst >>= (src & mask) -NEG 0x8 0 dst = -dst -MOD 0x9 0 dst = (src != 0) ? (dst % src) : dst -SMOD 0x9 1 dst = (src != 0) ? (dst s% src) : dst -XOR 0xa 0 dst ^= src -MOV 0xb 0 dst = src -MOVSX 0xb 8/16/32 dst = (s8,s16,s32)src -ARSH 0xc 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask) -END 0xd 0 byte swap operations (see `Byte swap instructions`_ below) -===== ===== ======= ========================================================== +.. table:: Arithmetic instructions + + ===== ===== ======= ========================================================== + name code offset description + ===== ===== ======= ========================================================== + ADD 0x0 0 dst += src + SUB 0x1 0 dst -= src + MUL 0x2 0 dst \*= src + DIV 0x3 0 dst = (src != 0) ? (dst / src) : 0 + SDIV 0x3 1 dst = (src != 0) ? (dst s/ src) : 0 + OR 0x4 0 dst \|= src + AND 0x5 0 dst &= src + LSH 0x6 0 dst <<= (src & mask) + RSH 0x7 0 dst >>= (src & mask) + NEG 0x8 0 dst = -dst + MOD 0x9 0 dst = (src != 0) ? (dst % src) : dst + SMOD 0x9 1 dst = (src != 0) ? (dst s% src) : dst + XOR 0xa 0 dst ^= src + MOV 0xb 0 dst = src + MOVSX 0xb 8/16/32 dst = (s8,s16,s32)src + ARSH 0xc 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask) + END 0xd 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 BPF program execution would @@ -374,7 +393,7 @@ interpreted as a 64-bit signed value. Note that there are varying definitions of the signed modulo operation when the dividend or divisor are negative, where implementations often vary by language such that Python, Ruby, etc. differ from C, Go, Java, -etc. This specification requires that signed modulo use truncated division +etc. This specification requires that signed modulo MUST use truncated division (where -13 % 3 == -1) as implemented in C, Go, etc.:: a % n = a - n * trunc(a / n) @@ -386,6 +405,19 @@ The ``MOVSX`` instruction does a move operation with sign extension. operands into 64-bit operands. Unlike other arithmetic instructions, ``MOVSX`` is only defined for register source operands (``X``). +``{MOV, K, ALU64}`` means:: + + dst = (s64)imm + +``{MOV, X, ALU}`` means:: + + dst = (u32)src + +``{MOVSX, X, ALU}`` with 'offset' 8 means:: + + dst = (u32)(s32)(s8)src + + The ``NEG`` instruction is only defined when the source bit is clear (``K``). @@ -404,15 +436,17 @@ only and do not use a separate source register or immediate value. For ``ALU``, the 1-bit source operand field in the opcode is used to select what byte order the operation converts from or to. For ``ALU64``, the 1-bit source operand field in the opcode is reserved -and must be set to 0. +and MUST be set to 0. + +.. table:: Byte swap instructions -===== ======== ===== ================================================= -class source value description -===== ======== ===== ================================================= -ALU TO_LE 0 convert between host byte order and little endian -ALU TO_BE 1 convert between host byte order and big endian -ALU64 Reserved 0 do byte swap unconditionally -===== ======== ===== ================================================= + ===== ======== ===== ================================================= + class source value description + ===== ======== ===== ================================================= + ALU LE 0 convert between host byte order and little endian + ALU BE 1 convert between host byte order and big endian + ALU64 Reserved 0 do byte swap unconditionally + ===== ======== ===== ================================================= The 'imm' field encodes the width of the swap operations. The following widths are supported: 16, 32 and 64. Width 64 operations belong to the base64 @@ -421,19 +455,19 @@ conformance group. Examples: -``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means:: +``{END, LE, ALU}`` with 'imm' = 16/32/64 means:: - dst = htole16(dst) - dst = htole32(dst) - dst = htole64(dst) + dst = le16(dst) + dst = le32(dst) + dst = le64(dst) -``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means:: +``{END, BE, ALU}`` with 'imm' = 16/32/64 means:: - dst = htobe16(dst) - dst = htobe32(dst) - dst = htobe64(dst) + dst = be16(dst) + dst = be32(dst) + dst = be64(dst) -``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means:: +``{END, TO, ALU64}`` with 'imm' = 16/32/64 means:: dst = bswap16(dst) dst = bswap32(dst) @@ -448,27 +482,29 @@ otherwise identical operations, and indicates the base64 conformance group unless otherwise specified. The 'code' field encodes the operation as below: -======== ===== ======= ================================= =================================================== -code value src_reg description notes -======== ===== ======= ================================= =================================================== -JA 0x0 0x0 PC += offset {JA, K, JMP} only -JA 0x0 0x0 PC += imm {JA, K, JMP32} only -JEQ 0x1 any PC += offset if dst == src -JGT 0x2 any PC += offset if dst > src unsigned -JGE 0x3 any PC += offset if dst >= src unsigned -JSET 0x4 any PC += offset if dst & src -JNE 0x5 any PC += offset if dst != src -JSGT 0x6 any PC += offset if dst > src signed -JSGE 0x7 any PC += offset if dst >= src signed -CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_ -CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_ -CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_ -EXIT 0x9 0x0 return {CALL, K, JMP} only -JLT 0xa any PC += offset if dst < src unsigned -JLE 0xb any PC += offset if dst <= src unsigned -JSLT 0xc any PC += offset if dst < src signed -JSLE 0xd any PC += offset if dst <= src signed -======== ===== ======= ================================= =================================================== +.. table:: Jump instructions + + ======== ===== ======= ================================= =================================================== + code value src_reg description notes + ======== ===== ======= ================================= =================================================== + JA 0x0 0x0 PC += offset {JA, K, JMP} only + JA 0x0 0x0 PC += imm {JA, K, JMP32} only + JEQ 0x1 any PC += offset if dst == src + JGT 0x2 any PC += offset if dst > src unsigned + JGE 0x3 any PC += offset if dst >= src unsigned + JSET 0x4 any PC += offset if dst & src + JNE 0x5 any PC += offset if dst != src + JSGT 0x6 any PC += offset if dst > src signed + JSGE 0x7 any PC += offset if dst >= src signed + CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_ + CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_ + CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_ + EXIT 0x9 0x0 return {CALL, K, JMP} only + JLT 0xa any PC += offset if dst < src unsigned + JLE 0xb any PC += offset if dst <= src unsigned + JSLT 0xc any PC += offset if dst < src signed + JSLE 0xd any PC += offset if dst <= src signed + ======== ===== ======= ================================= =================================================== where 'PC' denotes the program counter, and the offset to increment by is in units of 64-bit instructions relative to the instruction following @@ -476,9 +512,6 @@ the jump instruction. Thus 'PC += 1' skips execution of the next instruction if it's a basic instruction or results in undefined behavior if the next instruction is a 128-bit wide instruction. -The BPF program needs to store the return value into register R0 before doing an -``EXIT``. - Example: ``{JSGE, X, JMP32}`` means:: @@ -487,6 +520,10 @@ Example: where 's>=' indicates a signed '>=' comparison. +``{JLE, K, JMP}`` means:: + + if dst <= (u64)(s64)imm goto +offset + ``{JA, K, JMP32}`` means:: gotol +imm @@ -510,19 +547,25 @@ Helper functions are a concept whereby BPF programs can call into a set of function calls exposed by the underlying platform. Historically, each helper function was identified by a static ID -encoded in the 'imm' field. The available helper functions may differ -for each program type, but static IDs are unique across all program types. +encoded in the 'imm' field. Further documentation of helper functions +is outside the scope of this document and standardization is left for +future work, but use is widely deployed and more information can be +found in platform-specific documentation (e.g., Linux kernel documentation). Platforms that support the BPF Type Format (BTF) support identifying a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID -identifies the helper name and type. +identifies the helper name and type. Further documentation of BTF +is outside the scope of this document and standardization is left for +future work, but use is widely deployed and more information can be +found in platform-specific documentation (e.g., Linux kernel documentation). Program-local functions ~~~~~~~~~~~~~~~~~~~~~~~ Program-local functions are functions exposed by the same BPF program as the -caller, and are referenced by offset from the call instruction, similar to -``JA``. The offset is encoded in the 'imm' field of the call instruction. -An ``EXIT`` within the program-local function will return to the caller. +caller, and are referenced by offset from the instruction following the call +instruction, similar to ``JA``. The offset is encoded in the 'imm' field of +the call instruction. An ``EXIT`` within the program-local function will +return to the caller. Load and store instructions =========================== @@ -537,6 +580,8 @@ For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the **mode** The mode modifier is one of: + .. table:: Mode modifier + ============= ===== ==================================== ============= mode modifier value description reference ============= ===== ==================================== ============= @@ -551,6 +596,8 @@ For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the **sz (size)** The size modifier is one of: + .. table:: Size modifier + ==== ===== ===================== size value description ==== ===== ===================== @@ -619,14 +666,16 @@ 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: -======== ===== =========== -imm value description -======== ===== =========== -ADD 0x00 atomic add -OR 0x40 atomic or -AND 0x50 atomic and -XOR 0xa0 atomic xor -======== ===== =========== +.. table:: Simple atomic operations + + ======== ===== =========== + imm value description + ======== ===== =========== + ADD 0x00 atomic add + OR 0x40 atomic or + AND 0x50 atomic and + XOR 0xa0 atomic xor + ======== ===== =========== ``{ATOMIC, W, STX}`` with 'imm' = ADD means:: @@ -640,13 +689,15 @@ XOR 0xa0 atomic xor In addition to the simple atomic operations, there also is a modifier and two complex atomic operations: -=========== ================ =========================== -imm value description -=========== ================ =========================== -FETCH 0x01 modifier: return old value -XCHG 0xe0 | FETCH atomic exchange -CMPXCHG 0xf0 | FETCH atomic compare and exchange -=========== ================ =========================== +.. table:: Complex atomic operations + + =========== ================ =========================== + imm value description + =========== ================ =========================== + FETCH 0x01 modifier: return old value + XCHG 0xe0 | FETCH atomic exchange + CMPXCHG 0xf0 | FETCH atomic compare and exchange + =========== ================ =========================== The ``FETCH`` modifier is optional for simple atomic operations, and always set for the complex atomic operations. If the ``FETCH`` flag @@ -673,17 +724,19 @@ The following table defines a set of ``{IMM, DW, LD}`` instructions with opcode subtypes in the 'src_reg' field, using new terms such as "map" defined further below: -======= ========================================= =========== ============== -src_reg pseudocode imm type dst type -======= ========================================= =========== ============== -0x0 dst = (next_imm << 32) | imm integer integer -0x1 dst = map_by_fd(imm) map fd map -0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address -0x3 dst = var_addr(imm) variable id data address -0x4 dst = code_addr(imm) integer code address -0x5 dst = map_by_idx(imm) map index map -0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address -======= ========================================= =========== ============== +.. table:: 64-bit immediate instructions + + ======= ========================================= =========== ============== + src_reg pseudocode imm type dst type + ======= ========================================= =========== ============== + 0x0 dst = (next_imm << 32) | imm integer integer + 0x1 dst = map_by_fd(imm) map fd map + 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address + 0x3 dst = var_addr(imm) variable id data address + 0x4 dst = code_addr(imm) integer code address + 0x5 dst = map_by_idx(imm) map index map + 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address + ======= ========================================= =========== ============== where @@ -725,5 +778,5 @@ carried over from classic BPF. These instructions used an instruction class of ``LD``, a size modifier of ``W``, ``H``, or ``B``, and a mode modifier of ``ABS`` or ``IND``. The 'dst_reg' and 'offset' fields were set to zero, and 'src_reg' was set to zero for ``ABS``. However, these -instructions are deprecated and should no longer be used. All legacy packet +instructions are deprecated and SHOULD no longer be used. All legacy packet access instructions belong to the "packet" conformance group. diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml new file mode 100644 index 000000000000..c578637c5826 --- /dev/null +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/airoha,en7581-eth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha EN7581 Frame Engine Ethernet controller + +maintainers: + - Lorenzo Bianconi <lorenzo@kernel.org> + +description: + The frame engine ethernet controller can be found on Airoha SoCs. + These SoCs have multi-GMAC ports. + +properties: + compatible: + enum: + - airoha,en7581-eth + + reg: + items: + - description: Frame engine base address + - description: QDMA0 base address + - description: QDMA1 base address + + reg-names: + items: + - const: fe + - const: qdma0 + - const: qdma1 + + interrupts: + items: + - description: QDMA lan irq0 + - description: QDMA lan irq1 + - description: QDMA lan irq2 + - description: QDMA lan irq3 + - description: QDMA wan irq0 + - description: QDMA wan irq1 + - description: QDMA wan irq2 + - description: QDMA wan irq3 + - description: FE error irq + - description: PDMA irq + + resets: + maxItems: 8 + + reset-names: + items: + - const: fe + - const: pdma + - const: qdma + - const: xsi-mac + - const: hsi0-mac + - const: hsi1-mac + - const: hsi-mac + - const: xfp-mac + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^ethernet@[1-4]$": + type: object + unevaluatedProperties: false + $ref: ethernet-controller.yaml# + description: + Ethernet GMAC port associated to the MAC controller + properties: + compatible: + const: airoha,eth-mac + + reg: + minimum: 1 + maximum: 4 + description: GMAC port identifier + + required: + - reg + - compatible + +required: + - compatible + - reg + - interrupts + - resets + - reset-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/en7523-clk.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + eth: ethernet@1fb50000 { + compatible = "airoha,en7581-eth"; + reg = <0 0x1fb50000 0 0x2600>, + <0 0x1fb54000 0 0x2000>, + <0 0x1fb56000 0 0x2000>; + reg-names = "fe", "qdma0", "qdma1"; + + resets = <&scuclk 44>, + <&scuclk 30>, + <&scuclk 31>, + <&scuclk 6>, + <&scuclk 15>, + <&scuclk 16>, + <&scuclk 17>, + <&scuclk 26>; + reset-names = "fe", "pdma", "qdma", "xsi-mac", + "hsi0-mac", "hsi1-mac", "hsi-mac", + "xfp-mac"; + + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; + + #address-cells = <1>; + #size-cells = <0>; + + mac: ethernet@1 { + compatible = "airoha,eth-mac"; + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt deleted file mode 100644 index c73a0e9c625e..000000000000 --- a/Documentation/devicetree/bindings/net/arc_emac.txt +++ /dev/null @@ -1,46 +0,0 @@ -* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC) - -Required properties: -- compatible: Should be "snps,arc-emac" -- reg: Address and length of the register set for the device -- interrupts: Should contain the EMAC interrupts -- max-speed: see ethernet.txt file in the same directory. -- phy: see ethernet.txt file in the same directory. - -Optional properties: -- phy-reset-gpios : Should specify the gpio for phy reset -- phy-reset-duration : Reset duration in milliseconds. Should present - only if property "phy-reset-gpios" is available. Missing the property - will have the duration be 1 millisecond. Numbers greater than 1000 are - invalid and 1 millisecond will be used instead. - -Clock handling: -The clock frequency is needed to calculate and set polling period of EMAC. -It must be provided by one of: -- clock-frequency: CPU frequency. -- clocks: reference to the clock supplying the EMAC. - -Child nodes of the driver are the individual PHY devices connected to the -MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus. - -Examples: - - ethernet@c0fc2000 { - compatible = "snps,arc-emac"; - reg = <0xc0fc2000 0x3c>; - interrupts = <6>; - mac-address = [ 00 11 22 33 44 55 ]; - - clock-frequency = <80000000>; - /* or */ - clocks = <&emac_clock>; - - max-speed = <100>; - phy = <&phy0>; - - #address-cells = <1>; - #size-cells = <0>; - phy0: ethernet-phy@0 { - reg = <1>; - }; - }; diff --git a/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7622-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7622-bluetooth.yaml new file mode 100644 index 000000000000..3f9e69208127 --- /dev/null +++ b/Documentation/devicetree/bindings/net/bluetooth/mediatek,mt7622-bluetooth.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/bluetooth/mediatek,mt7622-bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek SoC built-in Bluetooth + +description: + This device is a serial attached device to BTIF device and thus it must be a + child node of the serial node with BTIF. The dt-bindings details for BTIF + device can be known via Documentation/devicetree/bindings/serial/8250.yaml. + +maintainers: + - Sean Wang <sean.wang@mediatek.com> + +allOf: + - $ref: bluetooth-controller.yaml# + +properties: + compatible: + const: mediatek,mt7622-bluetooth + + clocks: + maxItems: 1 + + clock-names: + const: ref + + power-domains: + maxItems: 1 + +required: + - clocks + - clock-names + - power-domains + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/power/mt7622-power.h> + + serial { + bluetooth { + compatible = "mediatek,mt7622-bluetooth"; + power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>; + clocks = <&clk25m>; + clock-names = "ref"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml index f01a3988538c..37a65badb448 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/nxp,88w8987-bt.yaml @@ -31,6 +31,9 @@ properties: This property depends on the module vendor's configuration. + firmware-name: + maxItems: 1 + required: - compatible @@ -42,5 +45,6 @@ examples: bluetooth { compatible = "nxp,88w8987-bt"; fw-init-baudrate = <3000000>; + firmware-name = "uartuart8987_bt_v0.bin"; }; }; diff --git a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml index 055a3351880b..68c5ed111417 100644 --- a/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml +++ b/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml @@ -62,6 +62,9 @@ properties: vdddig-supply: description: VDD_DIG supply regulator handle + vddbtcmx-supply: + description: VDD_BT_CMX supply regulator handle + vddbtcxmx-supply: description: VDD_BT_CXMX supply regulator handle @@ -74,6 +77,9 @@ properties: vddrfa1p7-supply: description: VDD_RFA_1P7 supply regulator handle + vddrfa1p8-supply: + description: VDD_RFA_1P8 supply regulator handle + vddrfa1p2-supply: description: VDD_RFA_1P2 supply regulator handle @@ -86,6 +92,12 @@ properties: vddasd-supply: description: VDD_ASD supply regulator handle + vddwlcx-supply: + description: VDD_WLCX supply regulator handle + + vddwlmx-supply: + description: VDD_WLMX supply regulator handle + max-speed: description: see Documentation/devicetree/bindings/serial/serial.yaml @@ -176,14 +188,27 @@ allOf: - qcom,wcn7850-bt then: required: - - enable-gpios - - swctrl-gpios - - vddio-supply + - vddrfacmn-supply + - vddaon-supply + - vddwlcx-supply + - vddwlmx-supply + - vddrfa0p8-supply + - vddrfa1p2-supply + - vddrfa1p8-supply + - if: + properties: + compatible: + contains: + enum: + - qcom,qca6390-bt + then: + required: + - vddrfacmn-supply - vddaon-supply - - vdddig-supply + - vddbtcmx-supply - vddrfa0p8-supply - vddrfa1p2-supply - - vddrfa1p9-supply + - vddrfa1p7-supply examples: - | diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml index 8d4e5af6fd6c..40835497050a 100644 --- a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml +++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml @@ -5,7 +5,7 @@ $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 + Xilinx CAN and CANFD controller maintainers: - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index 2c71e2cf3a2f..3c30dd23cd4e 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -146,6 +146,7 @@ patternProperties: magic-packet: type: boolean + deprecated: true description: Indicates that the hardware supports waking up via magic packet. diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml new file mode 100644 index 000000000000..f3154b19af78 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml @@ -0,0 +1,202 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/lantiq,gswip.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lantiq GSWIP Ethernet switches + +allOf: + - $ref: dsa.yaml#/$defs/ethernet-ports + +maintainers: + - Hauke Mehrtens <hauke@hauke-m.de> + +properties: + compatible: + enum: + - lantiq,xrx200-gswip + - lantiq,xrx300-gswip + - lantiq,xrx330-gswip + + reg: + minItems: 3 + maxItems: 3 + + reg-names: + items: + - const: switch + - const: mdio + - const: mii + + mdio: + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false + + properties: + compatible: + const: lantiq,xrx200-mdio + + required: + - compatible + + gphy-fw: + type: object + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + compatible: + items: + - enum: + - lantiq,xrx200-gphy-fw + - lantiq,xrx300-gphy-fw + - lantiq,xrx330-gphy-fw + - const: lantiq,gphy-fw + + lantiq,rcu: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the RCU syscon + + patternProperties: + "^gphy@[0-9a-f]{1,2}$": + type: object + + additionalProperties: false + + properties: + reg: + minimum: 0 + maximum: 255 + description: + Offset of the GPHY firmware register in the RCU register range + + resets: + items: + - description: GPHY reset line + + reset-names: + items: + - const: gphy + + required: + - reg + + required: + - compatible + - lantiq,rcu + + additionalProperties: false + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + switch@e108000 { + compatible = "lantiq,xrx200-gswip"; + reg = <0xe108000 0x3100>, /* switch */ + <0xe10b100 0xd8>, /* mdio */ + <0xe10b1d8 0x130>; /* mii */ + dsa,member = <0 0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan3"; + phy-mode = "rgmii"; + phy-handle = <&phy0>; + }; + + port@1 { + reg = <1>; + label = "lan4"; + phy-mode = "rgmii"; + phy-handle = <&phy1>; + }; + + port@2 { + reg = <2>; + label = "lan2"; + phy-mode = "internal"; + phy-handle = <&phy11>; + }; + + port@4 { + reg = <4>; + label = "lan1"; + phy-mode = "internal"; + phy-handle = <&phy13>; + }; + + port@5 { + reg = <5>; + label = "wan"; + phy-mode = "rgmii"; + phy-handle = <&phy5>; + }; + + port@6 { + reg = <0x6>; + phy-mode = "internal"; + ethernet = <ð0>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + compatible = "lantiq,xrx200-mdio"; + + phy0: ethernet-phy@0 { + reg = <0x0>; + }; + phy1: ethernet-phy@1 { + reg = <0x1>; + }; + phy5: ethernet-phy@5 { + reg = <0x5>; + }; + phy11: ethernet-phy@11 { + reg = <0x11>; + }; + phy13: ethernet-phy@13 { + reg = <0x13>; + }; + }; + + gphy-fw { + #address-cells = <1>; + #size-cells = <0>; + compatible = "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw"; + lantiq,rcu = <&rcu0>; + + gphy@20 { + reg = <0x20>; + + resets = <&reset0 31 30>; + reset-names = "gphy"; + }; + + gphy@68 { + reg = <0x68>; + + resets = <&reset0 29 28>; + reset-names = "gphy"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt b/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt deleted file mode 100644 index 8bb1eff21cb1..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/lantiq-gswip.txt +++ /dev/null @@ -1,146 +0,0 @@ -Lantiq GSWIP Ethernet switches -================================== - -Required properties for GSWIP core: - -- compatible : "lantiq,xrx200-gswip" for the embedded GSWIP in the - xRX200 SoC - "lantiq,xrx300-gswip" for the embedded GSWIP in the - xRX300 SoC - "lantiq,xrx330-gswip" for the embedded GSWIP in the - xRX330 SoC -- reg : memory range of the GSWIP core registers - : memory range of the GSWIP MDIO registers - : memory range of the GSWIP MII registers - -See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of -additional required and optional properties. - - -Required properties for MDIO bus: -- compatible : "lantiq,xrx200-mdio" for the MDIO bus inside the GSWIP - core of the xRX200 SoC and the PHYs connected to it. - -See Documentation/devicetree/bindings/net/mdio.txt for a list of additional -required and optional properties. - - -Required properties for GPHY firmware loading: -- compatible : "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw" - "lantiq,xrx300-gphy-fw", "lantiq,gphy-fw" - "lantiq,xrx330-gphy-fw", "lantiq,gphy-fw" - for the loading of the firmware into the embedded - GPHY core of the SoC. -- lantiq,rcu : reference to the rcu syscon - -The GPHY firmware loader has a list of GPHY entries, one for each -embedded GPHY - -- reg : Offset of the GPHY firmware register in the RCU - register range -- resets : list of resets of the embedded GPHY -- reset-names : list of names of the resets - -Example: - -Ethernet switch on the VRX200 SoC: - -switch@e108000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "lantiq,xrx200-gswip"; - reg = < 0xe108000 0x3100 /* switch */ - 0xe10b100 0xd8 /* mdio */ - 0xe10b1d8 0x130 /* mii */ - >; - dsa,member = <0 0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - label = "lan3"; - phy-mode = "rgmii"; - phy-handle = <&phy0>; - }; - - port@1 { - reg = <1>; - label = "lan4"; - phy-mode = "rgmii"; - phy-handle = <&phy1>; - }; - - port@2 { - reg = <2>; - label = "lan2"; - phy-mode = "internal"; - phy-handle = <&phy11>; - }; - - port@4 { - reg = <4>; - label = "lan1"; - phy-mode = "internal"; - phy-handle = <&phy13>; - }; - - port@5 { - reg = <5>; - label = "wan"; - phy-mode = "rgmii"; - phy-handle = <&phy5>; - }; - - port@6 { - reg = <0x6>; - ethernet = <ð0>; - }; - }; - - mdio { - #address-cells = <1>; - #size-cells = <0>; - compatible = "lantiq,xrx200-mdio"; - reg = <0>; - - phy0: ethernet-phy@0 { - reg = <0x0>; - }; - phy1: ethernet-phy@1 { - reg = <0x1>; - }; - phy5: ethernet-phy@5 { - reg = <0x5>; - }; - phy11: ethernet-phy@11 { - reg = <0x11>; - }; - phy13: ethernet-phy@13 { - reg = <0x13>; - }; - }; - - gphy-fw { - compatible = "lantiq,xrx200-gphy-fw", "lantiq,gphy-fw"; - lantiq,rcu = <&rcu0>; - #address-cells = <1>; - #size-cells = <0>; - - gphy@20 { - reg = <0x20>; - - resets = <&reset0 31 30>; - reset-names = "gphy"; - }; - - gphy@68 { - reg = <0x68>; - - resets = <&reset0 29 28>; - reset-names = "gphy"; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml index 1c2444121e60..7e405ad96eb2 100644 --- a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml @@ -22,16 +22,16 @@ description: | The MT7988 SoC comes with a built-in switch similar to MT7531 as well as four Gigabit Ethernet PHYs. The switch registers are directly mapped into the SoC's - memory map rather than using MDIO. The switch got an internally connected 10G + memory map rather than using MDIO. The switch has an internally connected 10G CPU port and 4 user ports connected to the built-in Gigabit Ethernet PHYs. - MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has got 10/100 PHYs + The MT7530 in MT7620AN, MT7620DA, MT7620DAN and MT7620NN SoCs has 10/100 PHYs and the switch registers are directly mapped into SoC's memory map rather than using MDIO. The DSA driver currently doesn't support MT7620 variants. There is only the standalone version of MT7531. - Port 5 on MT7530 has got various ways of configuration: + Port 5 on MT7530 supports various configurations: - Port 5 can be used as a CPU port. diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt deleted file mode 100644 index 258bef483673..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.txt +++ /dev/null @@ -1,129 +0,0 @@ -Vitesse VSC73xx Switches -======================== - -This defines device tree bindings for the Vitesse VSC73xx switch chips. -The Vitesse company has been acquired by Microsemi and Microsemi has -been acquired Microchip but retains this vendor branding. - -The currently supported switch chips are: -Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch -Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch -Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch -Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch - -This switch could have two different management interface. - -If SPI interface is used, the device tree node is an SPI device so it must -reside inside a SPI bus device tree node, see spi/spi-bus.txt - -When the chip is connected to a parallel memory bus and work in memory-mapped -I/O mode, a platform device is used to represent the vsc73xx. In this case it -must reside inside a platform bus device tree node. - -Required properties: - -- compatible: must be exactly one of: - "vitesse,vsc7385" - "vitesse,vsc7388" - "vitesse,vsc7395" - "vitesse,vsc7398" -- gpio-controller: indicates that this switch is also a GPIO controller, - see gpio/gpio.txt -- #gpio-cells: this must be set to <2> and indicates that we are a twocell - GPIO controller, see gpio/gpio.txt - -Optional properties: - -- reset-gpios: a handle to a GPIO line that can issue reset of the chip. - It should be tagged as active low. - -Required subnodes: - -See net/dsa/dsa.txt for a list of additional required and optional properties -and subnodes of DSA switches. - -Examples: - -SPI: -switch@0 { - compatible = "vitesse,vsc7395"; - reg = <0>; - /* Specified for 2.5 MHz or below */ - spi-max-frequency = <2500000>; - gpio-controller; - #gpio-cells = <2>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - label = "lan1"; - }; - port@1 { - reg = <1>; - label = "lan2"; - }; - port@2 { - reg = <2>; - label = "lan3"; - }; - port@3 { - reg = <3>; - label = "lan4"; - }; - vsc: port@6 { - reg = <6>; - ethernet = <&gmac1>; - phy-mode = "rgmii"; - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - }; -}; - -Platform: -switch@2,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "vitesse,vsc7385"; - reg = <0x2 0x0 0x20000>; - reset-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - label = "lan1"; - }; - port@1 { - reg = <1>; - label = "lan2"; - }; - port@2 { - reg = <2>; - label = "lan3"; - }; - port@3 { - reg = <3>; - label = "lan4"; - }; - vsc: port@6 { - reg = <6>; - ethernet = <&enet0>; - phy-mode = "rgmii"; - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - }; - -}; diff --git a/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.yaml b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.yaml new file mode 100644 index 000000000000..b99d7a694b70 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/vitesse,vsc73xx.yaml @@ -0,0 +1,162 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/vitesse,vsc73xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Vitesse VSC73xx DSA Switches + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: + The Vitesse DSA Switches were produced in the early-to-mid 2000s. + + The Vitesse company has been acquired by Microsemi and Microsemi has + been acquired Microchip but the new owner retains this vendor branding. + + The currently supported switch chips are + Vitesse VSC7385 SparX-G5 5+1-port Integrated Gigabit Ethernet Switch + Vitesse VSC7388 SparX-G8 8-port Integrated Gigabit Ethernet Switch + Vitesse VSC7395 SparX-G5e 5+1-port Integrated Gigabit Ethernet Switch + Vitesse VSC7398 SparX-G8e 8-port Integrated Gigabit Ethernet Switch + + This switch can use one of two different management interfaces. + + If SPI interface is used, the device tree node is an SPI device so it must + reside inside a SPI bus device tree node, see spi/spi-bus.txt + + When the chip is connected to a parallel memory bus and work in memory-mapped + I/O mode, a platform device is used to represent the vsc73xx. In this case it + must reside inside a platform bus device tree node. + +properties: + compatible: + enum: + - vitesse,vsc7385 + - vitesse,vsc7388 + - vitesse,vsc7395 + - vitesse,vsc7398 + + reg: + maxItems: 1 + + gpio-controller: true + "#gpio-cells": + const: 2 + + reset-gpios: + description: GPIO to be used to reset the whole device + maxItems: 1 + +allOf: + - $ref: dsa.yaml#/$defs/ethernet-ports + +# This checks if reg is a chipselect so the device is on an SPI +# bus, the if-clause will fail if reg is a tuple such as for a +# platform device. +if: + properties: + reg: + minimum: 0 + maximum: 256 +then: + $ref: /schemas/spi/spi-peripheral-props.yaml# + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-switch@0 { + compatible = "vitesse,vsc7395"; + reg = <0>; + spi-max-frequency = <2500000>; + gpio-controller; + #gpio-cells = <2>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-port@0 { + reg = <0>; + label = "lan1"; + }; + ethernet-port@1 { + reg = <1>; + label = "lan2"; + }; + ethernet-port@2 { + reg = <2>; + label = "lan3"; + }; + ethernet-port@3 { + reg = <3>; + label = "lan4"; + }; + ethernet-port@6 { + reg = <6>; + ethernet = <&gmac1>; + phy-mode = "rgmii"; + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + }; + }; + + bus { + #address-cells = <1>; + #size-cells = <1>; + + ethernet-switch@10000000 { + compatible = "vitesse,vsc7385"; + reg = <0x10000000 0x20000>; + reset-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-port@0 { + reg = <0>; + label = "lan1"; + }; + ethernet-port@1 { + reg = <1>; + label = "lan2"; + }; + ethernet-port@2 { + reg = <2>; + label = "lan3"; + }; + ethernet-port@3 { + reg = <3>; + label = "lan4"; + }; + ethernet-port@6 { + reg = <6>; + ethernet = <&enet0>; + phy-mode = "rgmii"; + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index b2785b03139f..45819b235800 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -103,6 +103,7 @@ properties: - usxgmii - 10gbase-r - 25gbase-r + - 10g-qxgmii phy-mode: $ref: "#/properties/phy-connection-type" diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 8fb2a6ee7e5b..d9b62741a225 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -93,6 +93,14 @@ properties: the turn around line low at end of the control phase of the MDIO transaction. + brr-mode: + $ref: /schemas/types.yaml#/definitions/flag + description: + If set, indicates the network cable interface is an alternative one as + defined in the BroadR-Reach link mode specification under 1BR-100 and + 1BR-10 names. The PHY must be configured to operate in BroadR-Reach mode + by software. + clocks: maxItems: 1 description: diff --git a/Documentation/devicetree/bindings/net/fsl,enetc-ierb.yaml b/Documentation/devicetree/bindings/net/fsl,enetc-ierb.yaml new file mode 100644 index 000000000000..c8a654310b90 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,enetc-ierb.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,enetc-ierb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Integrated Endpoint Register Block + +description: + The fsl_enetc driver can probe on the Integrated Endpoint Register Block, + which preconfigures the FIFO limits for the ENETC ports. + +maintainers: + - Frank Li <Frank.Li@nxp.com> + - Vladimir Oltean <vladimir.oltean@nxp.com> + - Wei Fang <wei.fang@nxp.com> + - Claudiu Manoil <claudiu.manoil@nxp.com> + +properties: + compatible: + enum: + - fsl,ls1028a-enetc-ierb + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + endpoint-config@f0800000 { + compatible = "fsl,ls1028a-enetc-ierb"; + reg = <0xf0800000 0x10000>; + }; diff --git a/Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml b/Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml new file mode 100644 index 000000000000..c1dd6aa04321 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,enetc-mdio.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,enetc-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ENETC external MDIO PCIe endpoint device + +description: + NETC provides an external master MDIO interface (EMDIO) for managing external + devices (PHYs). EMDIO supports both Clause 22 and 45 protocols. And the EMDIO + provides a means for different software modules to share a single set of MDIO + signals to access their PHYs. + +maintainers: + - Frank Li <Frank.Li@nxp.com> + - Vladimir Oltean <vladimir.oltean@nxp.com> + - Wei Fang <wei.fang@nxp.com> + - Claudiu Manoil <claudiu.manoil@nxp.com> + +properties: + compatible: + items: + - enum: + - pci1957,ee01 + - const: fsl,enetc-mdio + + reg: + maxItems: 1 + +required: + - compatible + - reg + +allOf: + - $ref: mdio.yaml + - $ref: /schemas/pci/pci-device.yaml + +unevaluatedProperties: false + +examples: + - | + pcie{ + #address-cells = <3>; + #size-cells = <2>; + + mdio@0,3 { + compatible = "pci1957,ee01", "fsl,enetc-mdio"; + reg = <0x000300 0 0 0 0>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@2 { + reg = <0x2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/fsl,enetc.yaml b/Documentation/devicetree/bindings/net/fsl,enetc.yaml new file mode 100644 index 000000000000..e152c93998fe --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,enetc.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,enetc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: The NIC functionality of NXP NETC + +description: + The NIC functionality in NETC is known as EtherNET Controller (ENETC). ENETC + supports virtualization/isolation based on PCIe Single Root IO Virtualization + (SR-IOV), advanced QoS with 8 traffic classes and 4 drop resilience levels, + and a full range of TSN standards and NIC offload capabilities + +maintainers: + - Frank Li <Frank.Li@nxp.com> + - Vladimir Oltean <vladimir.oltean@nxp.com> + - Wei Fang <wei.fang@nxp.com> + - Claudiu Manoil <claudiu.manoil@nxp.com> + +properties: + compatible: + items: + - enum: + - pci1957,e100 + - const: fsl,enetc + + reg: + maxItems: 1 + + mdio: + $ref: mdio.yaml + unevaluatedProperties: false + description: Optional child node for ENETC instance, otherwise use NETC EMDIO. + +required: + - compatible + - reg + +allOf: + - $ref: /schemas/pci/pci-device.yaml + - $ref: ethernet-controller.yaml + +unevaluatedProperties: false + +examples: + - | + pcie { + #address-cells = <3>; + #size-cells = <2>; + + ethernet@0,0 { + compatible = "pci1957,e100", "fsl,enetc"; + reg = <0x000000 0 0 0 0>; + phy-handle = <&sgmii_phy0>; + phy-connection-type = "sgmii"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + phy@2 { + reg = <0x2>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/fsl,fman-mdio.yaml b/Documentation/devicetree/bindings/net/fsl,fman-mdio.yaml new file mode 100644 index 000000000000..6b2c0aa407a2 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,fman-mdio.yaml @@ -0,0 +1,123 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,fman-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Frame Manager MDIO Device + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: FMan MDIO Node. + The MDIO is a bus to which the PHY devices are connected. + +properties: + compatible: + enum: + - fsl,fman-mdio + - fsl,fman-xmdio + - fsl,fman-memac-mdio + description: + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2. + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2. + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from + FMan v3. + + reg: + maxItems: 1 + + clocks: + items: + - description: A reference to the input clock of the controller + from which the MDC frequency is derived. + + interrupts: + maxItems: 1 + + fsl,fman-internal-mdio: + $ref: /schemas/types.yaml#/definitions/flag + description: + Fman has internal MDIO for internal PCS(Physical + Coding Sublayer) PHYs and external MDIO for external PHYs. + The settings and programming routines for internal/external + MDIO are different. Must be included for internal MDIO. + + fsl,erratum-a009885: + $ref: /schemas/types.yaml#/definitions/flag + description: Indicates the presence of the A009885 + erratum describing that the contents of MDIO_DATA may + become corrupt unless it is read within 16 MDC cycles + of MDIO_CFG[BSY] being cleared, when performing an + MDIO read operation. + + fsl,erratum-a011043: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicates the presence of the A011043 erratum + describing that the MDIO_CFG[MDIO_RD_ER] bit may be falsely + set when reading internal PCS registers. MDIO reads to + internal PCS registers may result in having the + MDIO_CFG[MDIO_RD_ER] bit set, even when there is no error and + read data (MDIO_DATA[MDIO_DATA]) is correct. + Software may get false read error when reading internal + PCS registers through MDIO. As a workaround, all internal + MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit. + + For internal PHY device on internal mdio bus, a PHY node should be created. + See the definition of the PHY node in booting-without-of.txt for an + example of how to define a PHY (Internal PHY has no interrupt line). + - For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY. + - For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY. + The PCS PHY address should correspond to the value of the appropriate + MDEV_PORT. + + little-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: + IP block is little-endian mode. The default endian mode is big-endian. + +required: + - compatible + - reg + +allOf: + - $ref: mdio.yaml# + +unevaluatedProperties: false + +examples: + - | + mdio@f1000 { + compatible = "fsl,fman-xmdio"; + reg = <0xf1000 0x1000>; + interrupts = <101 2 0 0>; + }; + + - | + mdio@e3120 { + compatible = "fsl,fman-mdio"; + reg = <0xe3120 0xee0>; + fsl,fman-internal-mdio; + #address-cells = <1>; + #size-cells = <0>; + + tbi-phy@8 { + reg = <0x8>; + device_type = "tbi-phy"; + }; + }; + + - | + mdio@f1000 { + compatible = "fsl,fman-memac-mdio"; + reg = <0xf1000 0x1000>; + fsl,fman-internal-mdio; + #address-cells = <1>; + #size-cells = <0>; + + pcsphy6: ethernet-phy@0 { + reg = <0x0>; + }; + }; + diff --git a/Documentation/devicetree/bindings/net/fsl,fman-muram.yaml b/Documentation/devicetree/bindings/net/fsl,fman-muram.yaml new file mode 100644 index 000000000000..aa71acc7fa5b --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,fman-muram.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,fman-muram.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Frame Manager MURAM Device + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: | + FMan Internal memory - shared between all the FMan modules. + It contains data structures that are common and written to or read by + the modules. + + FMan internal memory is split into the following parts: + Packet buffering (Tx/Rx FIFOs) + Frames internal context + +properties: + compatible: + enum: + - fsl,fman-muram + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + muram@0 { + compatible = "fsl,fman-muram"; + reg = <0x0 0x28000>; + }; diff --git a/Documentation/devicetree/bindings/net/fsl,fman-port.yaml b/Documentation/devicetree/bindings/net/fsl,fman-port.yaml new file mode 100644 index 000000000000..9de445307830 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,fman-port.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,fman-port.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Frame Manager Port Device + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: | + The Frame Manager (FMan) supports several types of hardware ports: + Ethernet receiver (RX) + Ethernet transmitter (TX) + Offline/Host command (O/H) + +properties: + compatible: + enum: + - fsl,fman-v2-port-oh + - fsl,fman-v2-port-rx + - fsl,fman-v2-port-tx + - fsl,fman-v3-port-oh + - fsl,fman-v3-port-rx + - fsl,fman-v3-port-tx + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Specifies the hardware port id. + Each hardware port on the FMan has its own hardware PortID. + Super set of all hardware Port IDs available at FMan Reference + Manual under "FMan Hardware Ports in Freescale Devices" table. + + Each hardware port is assigned a 4KB, port-specific page in + the FMan hardware port memory region (which is part of the + FMan memory map). The first 4 KB in the FMan hardware ports + memory region is used for what are called common registers. + The subsequent 63 4KB pages are allocated to the hardware + ports. + The page of a specific port is determined by the cell-index. + + reg: + items: + - description: There is one reg region describing the port + configuration registers. + + fsl,fman-10g-port: + $ref: /schemas/types.yaml#/definitions/flag + description: The default port rate is 1G. + If this property exists, the port is s 10G port. + + fsl,fman-best-effort-port: + $ref: /schemas/types.yaml#/definitions/flag + description: The default port rate is 1G. + Can be defined only if 10G-support is set. + This property marks a best-effort 10G port (10G port that + may not be capable of line rate). + +required: + - compatible + - reg + - cell-index + +additionalProperties: false + +examples: + - | + port@a8000 { + compatible = "fsl,fman-v2-port-tx"; + reg = <0xa8000 0x1000>; + cell-index = <0x28>; + }; + diff --git a/Documentation/devicetree/bindings/net/fsl,fman.yaml b/Documentation/devicetree/bindings/net/fsl,fman.yaml new file mode 100644 index 000000000000..9bbf39ef31a2 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,fman.yaml @@ -0,0 +1,210 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,fman.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Frame Manager Device + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: + Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs, + etc.) the FMan node will have child nodes for each of them. + +properties: + compatible: + enum: + - fsl,fman + description: + FMan version can be determined via FM_IP_REV_1 register in the + FMan block. The offset is 0xc4 from the beginning of the + Frame Processing Manager memory map (0xc3000 from the + beginning of the FMan node). + + cell-index: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Specifies the index of the FMan unit. + + The cell-index value may be used by the SoC, to identify the + FMan unit in the SoC memory map. In the table below, + there's a description of the cell-index use in each SoC: + + - P1023: + register[bit] FMan unit cell-index + ============================================================ + DEVDISR[1] 1 0 + + - P2041, P3041, P4080 P5020, P5040: + register[bit] FMan unit cell-index + ============================================================ + DCFG_DEVDISR2[6] 1 0 + DCFG_DEVDISR2[14] 2 1 + (Second FM available only in P4080 and P5040) + + - B4860, T1040, T2080, T4240: + register[bit] FMan unit cell-index + ============================================================ + DCFG_CCSR_DEVDISR2[24] 1 0 + DCFG_CCSR_DEVDISR2[25] 2 1 + (Second FM available only in T4240) + + DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in + the specific SoC "Device Configuration/Pin Control" Memory + Map. + + reg: + items: + - description: BMI configuration registers. + - description: QMI configuration registers. + - description: DMA configuration registers. + - description: FPM configuration registers. + - description: FMan controller configuration registers. + minItems: 1 + + ranges: true + + clocks: + maxItems: 1 + + clock-names: + items: + - const: fmanclk + + interrupts: + items: + - description: The first element is associated with the event interrupts. + - description: the second element is associated with the error interrupts. + + dma-coherent: true + + ptimer-handle: + $ref: /schemas/types.yaml#/definitions/phandle + description: see ptp/fsl,ptp.yaml + + fsl,qman-channel-range: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + Specifies the range of the available dedicated + channels in the FMan. The first cell specifies the beginning + of the range and the second cell specifies the number of + channels + items: + - description: The first cell specifies the beginning of the range. + - description: | + The second cell specifies the number of channels. + Further information available at: + "Work Queue (WQ) Channel Assignments in the QMan" section + in DPAA Reference Manual. + + fsl,qman: + $ref: /schemas/types.yaml#/definitions/phandle + description: See soc/fsl/qman.txt + + fsl,bman: + $ref: /schemas/types.yaml#/definitions/phandle + description: See soc/fsl/bman.txt + + fsl,erratum-a050385: + $ref: /schemas/types.yaml#/definitions/flag + description: A boolean property. Indicates the presence of the + erratum A050385 which indicates that DMA transactions that are + split can result in a FMan lock. + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + +patternProperties: + '^muram@[a-f0-9]+$': + $ref: fsl,fman-muram.yaml + + '^port@[a-f0-9]+$': + $ref: fsl,fman-port.yaml + + '^ethernet@[a-f0-9]+$': + $ref: fsl,fman-dtsec.yaml + + '^mdio@[a-f0-9]+$': + $ref: fsl,fman-mdio.yaml + + '^phc@[a-f0-9]+$': + $ref: /schemas/ptp/fsl,ptp.yaml + +required: + - compatible + - cell-index + - reg + - ranges + - clocks + - clock-names + - interrupts + - fsl,qman-channel-range + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + fman@400000 { + compatible = "fsl,fman"; + reg = <0x400000 0x100000>; + ranges = <0 0x400000 0x100000>; + #address-cells = <1>; + #size-cells = <1>; + cell-index = <1>; + clocks = <&fman_clk>; + clock-names = "fmanclk"; + interrupts = <96 IRQ_TYPE_EDGE_FALLING>, + <16 IRQ_TYPE_EDGE_FALLING>; + fsl,qman-channel-range = <0x40 0xc>; + + muram@0 { + compatible = "fsl,fman-muram"; + reg = <0x0 0x28000>; + }; + + port@81000 { + cell-index = <1>; + compatible = "fsl,fman-v2-port-oh"; + reg = <0x81000 0x1000>; + }; + + fman1_rx_0x8: port@88000 { + cell-index = <0x8>; + compatible = "fsl,fman-v2-port-rx"; + reg = <0x88000 0x1000>; + }; + + fman1_tx_0x28: port@a8000 { + cell-index = <0x28>; + compatible = "fsl,fman-v2-port-tx"; + reg = <0xa8000 0x1000>; + }; + + ethernet@e0000 { + compatible = "fsl,fman-dtsec"; + cell-index = <0>; + reg = <0xe0000 0x1000>; + ptp-timer = <&ptp_timer>; + fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>; + tbi-handle = <&tbi5>; + }; + + ptp_timer: phc@fe000 { + compatible = "fsl,fman-ptp-timer"; + reg = <0xfe000 0x1000>; + interrupts = <12 IRQ_TYPE_LEVEL_LOW>; + }; + + mdio@f1000 { + compatible = "fsl,fman-xmdio"; + reg = <0xf1000 0x1000>; + interrupts = <101 IRQ_TYPE_EDGE_FALLING>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt deleted file mode 100644 index 9b9a3f197e2d..000000000000 --- a/Documentation/devicetree/bindings/net/fsl-enetc.txt +++ /dev/null @@ -1,119 +0,0 @@ -* ENETC ethernet device tree bindings - -Depending on board design and ENETC port type (internal or -external) there are two supported link modes specified by -below device tree bindings. - -Required properties: - -- reg : Specifies PCIe Device Number and Function - Number of the ENETC endpoint device, according - to parent node bindings. -- compatible : Should be "fsl,enetc". - -1. The ENETC external port is connected to a MDIO configurable phy - -1.1. Using the local ENETC Port MDIO interface - -In this case, the ENETC node should include a "mdio" sub-node -that in turn should contain the "ethernet-phy" node describing the -external phy. Below properties are required, their bindings -already defined in Documentation/devicetree/bindings/net/ethernet.txt or -Documentation/devicetree/bindings/net/phy.txt. - -Required: - -- phy-handle : Phandle to a PHY on the MDIO bus. - Defined in ethernet.txt. - -- phy-connection-type : Defined in ethernet.txt. - -- mdio : "mdio" node, defined in mdio.txt. - -- ethernet-phy : "ethernet-phy" node, defined in phy.txt. - -Example: - - ethernet@0,0 { - compatible = "fsl,enetc"; - reg = <0x000000 0 0 0 0>; - phy-handle = <&sgmii_phy0>; - phy-connection-type = "sgmii"; - - mdio { - #address-cells = <1>; - #size-cells = <0>; - sgmii_phy0: ethernet-phy@2 { - reg = <0x2>; - }; - }; - }; - -1.2. Using the central MDIO PCIe endpoint device - -In this case, the mdio node should be defined as another PCIe -endpoint node, at the same level with the ENETC port nodes. - -Required properties: - -- reg : Specifies PCIe Device Number and Function - Number of the ENETC endpoint device, according - to parent node bindings. -- compatible : Should be "fsl,enetc-mdio". - -The remaining required mdio bus properties are standard, their bindings -already defined in Documentation/devicetree/bindings/net/mdio.txt. - -Example: - - ethernet@0,0 { - compatible = "fsl,enetc"; - reg = <0x000000 0 0 0 0>; - phy-handle = <&sgmii_phy0>; - phy-connection-type = "sgmii"; - }; - - mdio@0,3 { - compatible = "fsl,enetc-mdio"; - reg = <0x000300 0 0 0 0>; - #address-cells = <1>; - #size-cells = <0>; - sgmii_phy0: ethernet-phy@2 { - reg = <0x2>; - }; - }; - -2. The ENETC port is an internal port or has a fixed-link external -connection - -In this case, the ENETC port node defines a fixed link connection, -as specified by Documentation/devicetree/bindings/net/fixed-link.txt. - -Required: - -- fixed-link : "fixed-link" node, defined in "fixed-link.txt". - -Example: - ethernet@0,2 { - compatible = "fsl,enetc"; - reg = <0x000200 0 0 0 0>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - -* Integrated Endpoint Register Block bindings - -Optionally, the fsl_enetc driver can probe on the Integrated Endpoint Register -Block, which preconfigures the FIFO limits for the ENETC ports. This is a node -with the following properties: - -- reg : Specifies the address in the SoC memory space. -- compatible : Must be "fsl,ls1028a-enetc-ierb". - -Example: - ierb@1f0800000 { - compatible = "fsl,ls1028a-enetc-ierb"; - reg = <0x01 0xf0800000 0x0 0x10000>; - }; diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt deleted file mode 100644 index bda4b41af074..000000000000 --- a/Documentation/devicetree/bindings/net/fsl-fman.txt +++ /dev/null @@ -1,548 +0,0 @@ -============================================================================= -Freescale Frame Manager Device Bindings - -CONTENTS - - FMan Node - - FMan Port Node - - FMan MURAM Node - - FMan dTSEC/XGEC/mEMAC Node - - FMan IEEE 1588 Node - - FMan MDIO Node - - Example - -============================================================================= -FMan Node - -DESCRIPTION - -Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs, -etc.) the FMan node will have child nodes for each of them. - -PROPERTIES - -- compatible - Usage: required - Value type: <stringlist> - Definition: Must include "fsl,fman" - FMan version can be determined via FM_IP_REV_1 register in the - FMan block. The offset is 0xc4 from the beginning of the - Frame Processing Manager memory map (0xc3000 from the - beginning of the FMan node). - -- cell-index - Usage: required - Value type: <u32> - Definition: Specifies the index of the FMan unit. - - The cell-index value may be used by the SoC, to identify the - FMan unit in the SoC memory map. In the table below, - there's a description of the cell-index use in each SoC: - - - P1023: - register[bit] FMan unit cell-index - ============================================================ - DEVDISR[1] 1 0 - - - P2041, P3041, P4080 P5020, P5040: - register[bit] FMan unit cell-index - ============================================================ - DCFG_DEVDISR2[6] 1 0 - DCFG_DEVDISR2[14] 2 1 - (Second FM available only in P4080 and P5040) - - - B4860, T1040, T2080, T4240: - register[bit] FMan unit cell-index - ============================================================ - DCFG_CCSR_DEVDISR2[24] 1 0 - DCFG_CCSR_DEVDISR2[25] 2 1 - (Second FM available only in T4240) - - DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in - the specific SoC "Device Configuration/Pin Control" Memory - Map. - -- reg - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. Specifies the offset of the - following configuration registers: - - BMI configuration registers. - - QMI configuration registers. - - DMA configuration registers. - - FPM configuration registers. - - FMan controller configuration registers. - -- ranges - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. - -- clocks - Usage: required - Value type: <prop-encoded-array> - Definition: phandle for the fman input clock. - -- clock-names - usage: required - Value type: <stringlist> - Definition: "fmanclk" for the fman input clock. - -- interrupts - Usage: required - Value type: <prop-encoded-array> - Definition: A pair of IRQs are specified in this property. - The first element is associated with the event interrupts and - the second element is associated with the error interrupts. - -- fsl,qman-channel-range - Usage: required - Value type: <prop-encoded-array> - Definition: Specifies the range of the available dedicated - channels in the FMan. The first cell specifies the beginning - of the range and the second cell specifies the number of - channels. - Further information available at: - "Work Queue (WQ) Channel Assignments in the QMan" section - in DPAA Reference Manual. - -- fsl,qman -- fsl,bman - Usage: required - Definition: See soc/fsl/qman.txt and soc/fsl/bman.txt - -- fsl,erratum-a050385 - Usage: optional - Value type: boolean - Definition: A boolean property. Indicates the presence of the - erratum A050385 which indicates that DMA transactions that are - split can result in a FMan lock. - -============================================================================= -FMan MURAM Node - -DESCRIPTION - -FMan Internal memory - shared between all the FMan modules. -It contains data structures that are common and written to or read by -the modules. -FMan internal memory is split into the following parts: - Packet buffering (Tx/Rx FIFOs) - Frames internal context - -PROPERTIES - -- compatible - Usage: required - Value type: <stringlist> - Definition: Must include "fsl,fman-muram" - -- ranges - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. - Specifies the multi-user memory offset and the size within - the FMan. - -EXAMPLE - -muram@0 { - compatible = "fsl,fman-muram"; - ranges = <0 0x000000 0x28000>; -}; - -============================================================================= -FMan Port Node - -DESCRIPTION - -The Frame Manager (FMan) supports several types of hardware ports: - Ethernet receiver (RX) - Ethernet transmitter (TX) - Offline/Host command (O/H) - -PROPERTIES - -- compatible - Usage: required - Value type: <stringlist> - Definition: A standard property. - Must include one of the following: - - "fsl,fman-v2-port-oh" for FManV2 OH ports - - "fsl,fman-v2-port-rx" for FManV2 RX ports - - "fsl,fman-v2-port-tx" for FManV2 TX ports - - "fsl,fman-v3-port-oh" for FManV3 OH ports - - "fsl,fman-v3-port-rx" for FManV3 RX ports - - "fsl,fman-v3-port-tx" for FManV3 TX ports - -- cell-index - Usage: required - Value type: <u32> - Definition: Specifies the hardware port id. - Each hardware port on the FMan has its own hardware PortID. - Super set of all hardware Port IDs available at FMan Reference - Manual under "FMan Hardware Ports in Freescale Devices" table. - - Each hardware port is assigned a 4KB, port-specific page in - the FMan hardware port memory region (which is part of the - FMan memory map). The first 4 KB in the FMan hardware ports - memory region is used for what are called common registers. - The subsequent 63 4KB pages are allocated to the hardware - ports. - The page of a specific port is determined by the cell-index. - -- reg - Usage: required - Value type: <prop-encoded-array> - Definition: There is one reg region describing the port - configuration registers. - -- fsl,fman-10g-port - Usage: optional - Value type: boolean - Definition: The default port rate is 1G. - If this property exists, the port is s 10G port. - -- fsl,fman-best-effort-port - Usage: optional - Value type: boolean - Definition: Can be defined only if 10G-support is set. - This property marks a best-effort 10G port (10G port that - may not be capable of line rate). - -EXAMPLE - -port@a8000 { - cell-index = <0x28>; - compatible = "fsl,fman-v2-port-tx"; - reg = <0xa8000 0x1000>; -}; - -port@88000 { - cell-index = <0x8>; - compatible = "fsl,fman-v2-port-rx"; - reg = <0x88000 0x1000>; -}; - -port@81000 { - cell-index = <0x1>; - compatible = "fsl,fman-v2-port-oh"; - reg = <0x81000 0x1000>; -}; - -============================================================================= -FMan dTSEC/XGEC/mEMAC Node - -Refer to Documentation/devicetree/bindings/net/fsl,fman-dtsec.yaml - -============================================================================ -FMan IEEE 1588 Node - -Refer to Documentation/devicetree/bindings/ptp/ptp-qoriq.txt - -============================================================================= -FMan MDIO Node - -DESCRIPTION - -The MDIO is a bus to which the PHY devices are connected. - -PROPERTIES - -- compatible - Usage: required - Value type: <stringlist> - Definition: A standard property. - Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2. - Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2. - Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from - FMan v3. - -- reg - Usage: required - Value type: <prop-encoded-array> - Definition: A standard property. - -- clocks - Usage: optional - Value type: <phandle> - Definition: A reference to the input clock of the controller - from which the MDC frequency is derived. - -- clock-frequency - Usage: optional - Value type: <u32> - Definition: Specifies the external MDC frequency, in Hertz, to - be used. Requires that the input clock is specified in the - "clocks" property. See also: mdio.yaml. - -- suppress-preamble - Usage: optional - Value type: <boolean> - Definition: Disable generation of preamble bits. See also: - mdio.yaml. - -- interrupts - Usage: required for external MDIO - Value type: <prop-encoded-array> - Definition: Event interrupt of external MDIO controller. - -- fsl,fman-internal-mdio - Usage: required for internal MDIO - Value type: boolean - Definition: Fman has internal MDIO for internal PCS(Physical - Coding Sublayer) PHYs and external MDIO for external PHYs. - The settings and programming routines for internal/external - MDIO are different. Must be included for internal MDIO. - -- fsl,erratum-a009885 - Usage: optional - Value type: <boolean> - Definition: Indicates the presence of the A009885 - erratum describing that the contents of MDIO_DATA may - become corrupt unless it is read within 16 MDC cycles - of MDIO_CFG[BSY] being cleared, when performing an - MDIO read operation. - -- fsl,erratum-a011043 - Usage: optional - Value type: <boolean> - Definition: Indicates the presence of the A011043 erratum - describing that the MDIO_CFG[MDIO_RD_ER] bit may be falsely - set when reading internal PCS registers. MDIO reads to - internal PCS registers may result in having the - MDIO_CFG[MDIO_RD_ER] bit set, even when there is no error and - read data (MDIO_DATA[MDIO_DATA]) is correct. - Software may get false read error when reading internal - PCS registers through MDIO. As a workaround, all internal - MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit. - -For internal PHY device on internal mdio bus, a PHY node should be created. -See the definition of the PHY node in booting-without-of.txt for an -example of how to define a PHY (Internal PHY has no interrupt line). -- For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY. -- For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY. - The PCS PHY address should correspond to the value of the appropriate - MDEV_PORT. - -EXAMPLE - -Example for FMan v2 external MDIO: - -mdio@f1000 { - compatible = "fsl,fman-xmdio"; - reg = <0xf1000 0x1000>; - interrupts = <101 2 0 0>; -}; - -Example for FMan v2 internal MDIO: - -mdio@e3120 { - compatible = "fsl,fman-mdio"; - reg = <0xe3120 0xee0>; - fsl,fman-internal-mdio; - - tbi1: tbi-phy@8 { - reg = <0x8>; - device_type = "tbi-phy"; - }; -}; - -Example for FMan v3 internal MDIO: - -mdio@f1000 { - compatible = "fsl,fman-memac-mdio"; - reg = <0xf1000 0x1000>; - fsl,fman-internal-mdio; - - pcsphy6: ethernet-phy@0 { - reg = <0x0>; - }; -}; - -============================================================================= -Example - -fman@400000 { - #address-cells = <1>; - #size-cells = <1>; - cell-index = <1>; - compatible = "fsl,fman" - ranges = <0 0x400000 0x100000>; - reg = <0x400000 0x100000>; - clocks = <&fman_clk>; - clock-names = "fmanclk"; - interrupts = < - 96 2 0 0 - 16 2 1 1>; - fsl,qman-channel-range = <0x40 0xc>; - - muram@0 { - compatible = "fsl,fman-muram"; - reg = <0x0 0x28000>; - }; - - port@81000 { - cell-index = <1>; - compatible = "fsl,fman-v2-port-oh"; - reg = <0x81000 0x1000>; - }; - - port@82000 { - cell-index = <2>; - compatible = "fsl,fman-v2-port-oh"; - reg = <0x82000 0x1000>; - }; - - port@83000 { - cell-index = <3>; - compatible = "fsl,fman-v2-port-oh"; - reg = <0x83000 0x1000>; - }; - - port@84000 { - cell-index = <4>; - compatible = "fsl,fman-v2-port-oh"; - reg = <0x84000 0x1000>; - }; - - port@85000 { - cell-index = <5>; - compatible = "fsl,fman-v2-port-oh"; - reg = <0x85000 0x1000>; - }; - - port@86000 { - cell-index = <6>; - compatible = "fsl,fman-v2-port-oh"; - reg = <0x86000 0x1000>; - }; - - fman1_rx_0x8: port@88000 { - cell-index = <0x8>; - compatible = "fsl,fman-v2-port-rx"; - reg = <0x88000 0x1000>; - }; - - fman1_rx_0x9: port@89000 { - cell-index = <0x9>; - compatible = "fsl,fman-v2-port-rx"; - reg = <0x89000 0x1000>; - }; - - fman1_rx_0xa: port@8a000 { - cell-index = <0xa>; - compatible = "fsl,fman-v2-port-rx"; - reg = <0x8a000 0x1000>; - }; - - fman1_rx_0xb: port@8b000 { - cell-index = <0xb>; - compatible = "fsl,fman-v2-port-rx"; - reg = <0x8b000 0x1000>; - }; - - fman1_rx_0xc: port@8c000 { - cell-index = <0xc>; - compatible = "fsl,fman-v2-port-rx"; - reg = <0x8c000 0x1000>; - }; - - fman1_rx_0x10: port@90000 { - cell-index = <0x10>; - compatible = "fsl,fman-v2-port-rx"; - reg = <0x90000 0x1000>; - }; - - fman1_tx_0x28: port@a8000 { - cell-index = <0x28>; - compatible = "fsl,fman-v2-port-tx"; - reg = <0xa8000 0x1000>; - }; - - fman1_tx_0x29: port@a9000 { - cell-index = <0x29>; - compatible = "fsl,fman-v2-port-tx"; - reg = <0xa9000 0x1000>; - }; - - fman1_tx_0x2a: port@aa000 { - cell-index = <0x2a>; - compatible = "fsl,fman-v2-port-tx"; - reg = <0xaa000 0x1000>; - }; - - fman1_tx_0x2b: port@ab000 { - cell-index = <0x2b>; - compatible = "fsl,fman-v2-port-tx"; - reg = <0xab000 0x1000>; - }; - - fman1_tx_0x2c: port@ac0000 { - cell-index = <0x2c>; - compatible = "fsl,fman-v2-port-tx"; - reg = <0xac000 0x1000>; - }; - - fman1_tx_0x30: port@b0000 { - cell-index = <0x30>; - compatible = "fsl,fman-v2-port-tx"; - reg = <0xb0000 0x1000>; - }; - - ethernet@e0000 { - compatible = "fsl,fman-dtsec"; - cell-index = <0>; - reg = <0xe0000 0x1000>; - fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>; - tbi-handle = <&tbi5>; - }; - - ethernet@e2000 { - compatible = "fsl,fman-dtsec"; - cell-index = <1>; - reg = <0xe2000 0x1000>; - fsl,fman-ports = <&fman1_rx_0x9 &fman1_tx_0x29>; - tbi-handle = <&tbi6>; - }; - - ethernet@e4000 { - compatible = "fsl,fman-dtsec"; - cell-index = <2>; - reg = <0xe4000 0x1000>; - fsl,fman-ports = <&fman1_rx_0xa &fman1_tx_0x2a>; - tbi-handle = <&tbi7>; - }; - - ethernet@e6000 { - compatible = "fsl,fman-dtsec"; - cell-index = <3>; - reg = <0xe6000 0x1000>; - fsl,fman-ports = <&fman1_rx_0xb &fman1_tx_0x2b>; - tbi-handle = <&tbi8>; - }; - - ethernet@e8000 { - compatible = "fsl,fman-dtsec"; - cell-index = <4>; - reg = <0xf0000 0x1000>; - fsl,fman-ports = <&fman1_rx_0xc &fman1_tx_0x2c>; - tbi-handle = <&tbi9>; - - ethernet@f0000 { - cell-index = <8>; - compatible = "fsl,fman-xgec"; - reg = <0xf0000 0x1000>; - fsl,fman-ports = <&fman1_rx_0x10 &fman1_tx_0x30>; - }; - - ptp-timer@fe000 { - compatible = "fsl,fman-ptp-timer"; - reg = <0xfe000 0x1000>; - }; - - mdio@f1000 { - compatible = "fsl,fman-xmdio"; - reg = <0xf1000 0x1000>; - interrupts = <101 2 0 0>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index 047bdf7bdd2f..9c9668c1b6a2 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -86,4 +86,4 @@ Example: * Gianfar PTP clock nodes -Refer to Documentation/devicetree/bindings/ptp/ptp-qoriq.txt +Refer to Documentation/devicetree/bindings/ptp/fsl,ptp.yaml diff --git a/Documentation/devicetree/bindings/net/mediatek,net.yaml b/Documentation/devicetree/bindings/net/mediatek,net.yaml index 3202dc7967c5..686b5c2fae40 100644 --- a/Documentation/devicetree/bindings/net/mediatek,net.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,net.yaml @@ -68,6 +68,17 @@ properties: Phandle to the syscon node that handles the path from GMAC to PHY variants. + mediatek,pcie-mirror: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the mediatek pcie-mirror controller. + + mediatek,pctl: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon node that handles the ports slew rate and + driver current. + mediatek,sgmiisys: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 @@ -131,15 +142,12 @@ allOf: mediatek,infracfg: false - mediatek,pctl: - $ref: /schemas/types.yaml#/definitions/phandle - description: - Phandle to the syscon node that handles the ports slew rate and - driver current. - mediatek,wed: false mediatek,wed-pcie: false + else: + properties: + mediatek,pctl: false - if: properties: @@ -201,12 +209,10 @@ allOf: minItems: 1 maxItems: 1 - mediatek,pcie-mirror: - $ref: /schemas/types.yaml#/definitions/phandle - description: - Phandle to the mediatek pcie-mirror controller. - mediatek,wed-pcie: false + else: + properties: + mediatek,pcie-mirror: false - if: properties: diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt index 9ef5bacda8c1..988c72685cbf 100644 --- a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt @@ -1,39 +1,3 @@ -MediaTek SoC built-in Bluetooth Devices -================================== - -This device is a serial attached device to BTIF device and thus it must be a -child node of the serial node with BTIF. The dt-bindings details for BTIF -device can be known via Documentation/devicetree/bindings/serial/8250.yaml. - -Required properties: - -- compatible: Must be - "mediatek,mt7622-bluetooth": for MT7622 SoC -- clocks: Should be the clock specifiers corresponding to the entry in - clock-names property. -- clock-names: Should contain "ref" entries. -- power-domains: Phandle to the power domain that the device is part of - -Example: - - btif: serial@1100c000 { - compatible = "mediatek,mt7622-btif", - "mediatek,mtk-btif"; - reg = <0 0x1100c000 0 0x1000>; - interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_LOW>; - clocks = <&pericfg CLK_PERI_BTIF_PD>; - clock-names = "main"; - reg-shift = <2>; - reg-io-width = <4>; - - bluetooth { - compatible = "mediatek,mt7622-bluetooth"; - power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>; - clocks = <&clk25m>; - clock-names = "ref"; - }; - }; - MediaTek UART based Bluetooth Devices ================================== diff --git a/Documentation/devicetree/bindings/net/mscc,miim.yaml b/Documentation/devicetree/bindings/net/mscc,miim.yaml index 5b292e7c9e46..792f26b06b06 100644 --- a/Documentation/devicetree/bindings/net/mscc,miim.yaml +++ b/Documentation/devicetree/bindings/net/mscc,miim.yaml @@ -38,6 +38,16 @@ properties: clock-frequency: true + resets: + items: + - description: + Reset shared with all blocks attached to the Switch Core Register + Bus (CSR) including VRAP slave. + + reset-names: + items: + - const: switch + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml b/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml new file mode 100644 index 000000000000..e77eec9ac9ee --- /dev/null +++ b/Documentation/devicetree/bindings/net/pcs/snps,dw-xpcs.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/pcs/snps,dw-xpcs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare Ethernet PCS + +maintainers: + - Serge Semin <fancer.lancer@gmail.com> + +description: + Synopsys DesignWare Ethernet Physical Coding Sublayer provides an interface + between Media Access Control and Physical Medium Attachment Sublayer through + the Media Independent Interface (XGMII, USXGMII, XLGMII, GMII, etc) + controlled by means of the IEEE std. Clause 45 registers set. The PCS can be + optionally synthesized with a vendor-specific interface connected to + Synopsys PMA (also called DesignWare Consumer/Enterprise PHY) although in + general it can be used to communicate with any compatible PHY. + + The PCS CSRs can be accessible either over the Ethernet MDIO bus or directly + by means of the APB3/MCI interfaces. In the later case the XPCS can be mapped + right to the system IO memory space. + +properties: + compatible: + oneOf: + - description: Synopsys DesignWare XPCS with none or unknown PMA + const: snps,dw-xpcs + - description: Synopsys DesignWare XPCS with Consumer Gen1 3G PMA + const: snps,dw-xpcs-gen1-3g + - description: Synopsys DesignWare XPCS with Consumer Gen2 3G PMA + const: snps,dw-xpcs-gen2-3g + - description: Synopsys DesignWare XPCS with Consumer Gen2 6G PMA + const: snps,dw-xpcs-gen2-6g + - description: Synopsys DesignWare XPCS with Consumer Gen4 3G PMA + const: snps,dw-xpcs-gen4-3g + - description: Synopsys DesignWare XPCS with Consumer Gen4 6G PMA + const: snps,dw-xpcs-gen4-6g + - description: Synopsys DesignWare XPCS with Consumer Gen5 10G PMA + const: snps,dw-xpcs-gen5-10g + - description: Synopsys DesignWare XPCS with Consumer Gen5 12G PMA + const: snps,dw-xpcs-gen5-12g + + reg: + items: + - description: + In case of the MDIO management interface this just a 5-bits ID + of the MDIO bus device. If DW XPCS CSRs space is accessed over the + MCI or APB3 management interfaces, then the space mapping can be + either 'direct' or 'indirect'. In the former case all Clause 45 + registers are contiguously mapped within the address space + MMD '[20:16]', Reg '[15:0]'. In the later case the space is divided + to the multiple 256 register sets. There is a special viewport CSR + which is responsible for the set selection. The upper part of + the CSR address MMD+REG[20:8] is supposed to be written in there + so the corresponding subset would be mapped to the lowest 255 CSRs. + + reg-names: + items: + - enum: [ direct, indirect ] + + reg-io-width: + description: + The way the CSRs are mapped to the memory is platform depended. Since + each Clause 45 CSR is of 16-bits wide the access instructions must be + two bytes aligned at least. + default: 2 + enum: [ 2, 4 ] + + interrupts: + description: + System interface interrupt output (sbd_intr_o) indicating Clause 73/37 + auto-negotiation events':' Page received, AN is completed or incompatible + link partner. + maxItems: 1 + + clocks: + description: + The MCI and APB3 interfaces are supposed to be equipped with a clock + source connected to the clk_csr_i line. + + PCS/PMA layer can be clocked by an internal reference clock source + (phyN_core_refclk) or by an externally connected (phyN_pad_refclk) clock + generator. Both clocks can be supplied at a time. + minItems: 1 + maxItems: 3 + + clock-names: + oneOf: + - minItems: 1 + items: # MDIO + - enum: [core, pad] + - const: pad + - minItems: 1 + items: # MCI or APB + - const: csr + - enum: [core, pad] + - const: pad + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + ethernet-pcs@1f05d000 { + compatible = "snps,dw-xpcs"; + reg = <0x1f05d000 0x1000>; + reg-names = "indirect"; + + reg-io-width = <4>; + + interrupts = <79 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&ccu_pclk>, <&ccu_core>, <&ccu_pad>; + clock-names = "csr", "core", "pad"; + }; + - | + mdio-bus { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-pcs@0 { + compatible = "snps,dw-xpcs"; + reg = <0>; + + clocks = <&ccu_core>, <&ccu_pad>; + clock-names = "core", "pad"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml index bb94a2388520..d248a08a2136 100644 --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml @@ -14,10 +14,32 @@ maintainers: description: Bindings for Realtek RTL82xx PHYs -allOf: - - $ref: ethernet-phy.yaml# - properties: + compatible: + enum: + - ethernet-phy-id001c.c800 + - ethernet-phy-id001c.c816 + - ethernet-phy-id001c.c838 + - ethernet-phy-id001c.c840 + - ethernet-phy-id001c.c848 + - ethernet-phy-id001c.c849 + - ethernet-phy-id001c.c84a + - ethernet-phy-id001c.c862 + - ethernet-phy-id001c.c878 + - ethernet-phy-id001c.c880 + - ethernet-phy-id001c.c910 + - ethernet-phy-id001c.c912 + - ethernet-phy-id001c.c913 + - ethernet-phy-id001c.c914 + - ethernet-phy-id001c.c915 + - ethernet-phy-id001c.c916 + - ethernet-phy-id001c.c942 + - ethernet-phy-id001c.c961 + - ethernet-phy-id001c.cad0 + - ethernet-phy-id001c.cb00 + + leds: true + realtek,clkout-disable: type: boolean description: @@ -31,6 +53,18 @@ properties: unevaluatedProperties: false +allOf: + - $ref: ethernet-phy.yaml# + - if: + not: + properties: + compatible: + contains: + const: ethernet-phy-id001c.c916 + then: + properties: + leds: false + examples: - | mdio { diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 21cc27e75f50..3eb65e63fdae 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -76,6 +76,7 @@ properties: - rockchip,rk3128-gmac - rockchip,rk3228-gmac - rockchip,rk3288-gmac + - rockchip,rk3308-gmac - rockchip,rk3328-gmac - rockchip,rk3366-gmac - rockchip,rk3368-gmac @@ -435,6 +436,32 @@ properties: description: Use Address-Aligned Beats + snps,pbl: + description: + Programmable Burst Length (tx and rx) + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16, 32] + + snps,txpbl: + description: + Tx Programmable Burst Length. If set, DMA tx will use this + value rather than snps,pbl. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16, 32] + + snps,rxpbl: + description: + Rx Programmable Burst Length. If set, DMA rx will use this + value rather than snps,pbl. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16, 32] + + snps,no-pbl-x8: + $ref: /schemas/types.yaml#/definitions/flag + description: + Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core + rev < 3.50, don\'t multiply the values by 4. + snps,fixed-burst: $ref: /schemas/types.yaml#/definitions/flag description: @@ -485,6 +512,12 @@ properties: description: Frequency division factor for MDC clock. + snps,tso: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enables the TSO feature otherwise it will be managed by MAC HW capability + register. + mdio: $ref: mdio.yaml# unevaluatedProperties: false @@ -568,95 +601,38 @@ allOf: - if: properties: compatible: - contains: - enum: - - allwinner,sun7i-a20-gmac - - allwinner,sun8i-a83t-emac - - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-gmac - - allwinner,sun8i-v3s-emac - - allwinner,sun50i-a64-emac - - ingenic,jz4775-mac - - ingenic,x1000-mac - - ingenic,x1600-mac - - ingenic,x1830-mac - - ingenic,x2000-mac - - qcom,sa8775p-ethqos - - qcom,sc8280xp-ethqos - - snps,dwmac-3.50a - - snps,dwmac-4.10a - - snps,dwmac-4.20a - - snps,dwmac-5.20 - - snps,dwxgmac - - snps,dwxgmac-2.10 - - st,spear600-gmac - - then: - properties: - snps,pbl: - description: - Programmable Burst Length (tx and rx) - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [1, 2, 4, 8, 16, 32] - - snps,txpbl: - description: - Tx Programmable Burst Length. If set, DMA tx will use this - value rather than snps,pbl. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [1, 2, 4, 8, 16, 32] - - snps,rxpbl: - description: - Rx Programmable Burst Length. If set, DMA rx will use this - value rather than snps,pbl. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [1, 2, 4, 8, 16, 32] - - snps,no-pbl-x8: - $ref: /schemas/types.yaml#/definitions/flag - description: - Don\'t multiply the pbl/txpbl/rxpbl values by 8. For core - rev < 3.50, don\'t multiply the values by 4. - - - if: - properties: - compatible: - contains: - enum: - - allwinner,sun7i-a20-gmac - - allwinner,sun8i-a83t-emac - - allwinner,sun8i-h3-emac - - allwinner,sun8i-r40-gmac - - allwinner,sun8i-v3s-emac - - allwinner,sun50i-a64-emac - - loongson,ls2k-dwmac - - loongson,ls7a-dwmac - - ingenic,jz4775-mac - - ingenic,x1000-mac - - ingenic,x1600-mac - - ingenic,x1830-mac - - ingenic,x2000-mac - - qcom,qcs404-ethqos - - qcom,sa8775p-ethqos - - qcom,sc8280xp-ethqos - - qcom,sm8150-ethqos - - snps,dwmac-4.00 - - snps,dwmac-4.10a - - snps,dwmac-4.20a - - snps,dwmac-5.10a - - snps,dwmac-5.20 - - snps,dwxgmac - - snps,dwxgmac-2.10 - - st,spear600-gmac + not: + contains: + enum: + - allwinner,sun7i-a20-gmac + - allwinner,sun8i-a83t-emac + - allwinner,sun8i-h3-emac + - allwinner,sun8i-r40-gmac + - allwinner,sun8i-v3s-emac + - allwinner,sun50i-a64-emac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac + - qcom,qcs404-ethqos + - qcom,sa8775p-ethqos + - qcom,sc8280xp-ethqos + - qcom,sm8150-ethqos + - snps,dwmac-4.00 + - snps,dwmac-4.10a + - snps,dwmac-4.20a + - snps,dwmac-5.10a + - snps,dwmac-5.20 + - snps,dwxgmac + - snps,dwxgmac-2.10 + - st,spear600-gmac then: properties: - snps,tso: - $ref: /schemas/types.yaml#/definitions/flag - description: - Enables the TSO feature otherwise it will be managed by - MAC HW capability register. + snps,tso: false additionalProperties: true diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 7ccf75676b6d..bf23838fe6e8 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -22,18 +22,22 @@ select: enum: - st,stm32-dwmac - st,stm32mp1-dwmac + - st,stm32mp13-dwmac + - st,stm32mp25-dwmac required: - compatible -allOf: - - $ref: snps,dwmac.yaml# - properties: compatible: oneOf: - items: - enum: + - st,stm32mp25-dwmac + - const: snps,dwmac-5.20 + - items: + - enum: - st,stm32mp1-dwmac + - st,stm32mp13-dwmac - const: snps,dwmac-4.20a - items: - enum: @@ -75,12 +79,15 @@ properties: st,syscon: $ref: /schemas/types.yaml#/definitions/phandle-array items: - - items: + - minItems: 2 + items: - description: phandle to the syscon node which encompases the glue register - description: offset of the control register + - description: field to set mask in register description: Should be phandle/offset pair. The phandle to the syscon node which - encompases the glue register, and the offset of the control register + encompases the glue register, the offset of the control register and + the mask to set bitfield in control register st,ext-phyclk: description: @@ -112,12 +119,40 @@ required: unevaluatedProperties: false +allOf: + - $ref: snps,dwmac.yaml# + - if: + properties: + compatible: + contains: + enum: + - st,stm32-dwmac + - st,stm32mp1-dwmac + - st,stm32mp25-dwmac + then: + properties: + st,syscon: + items: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - st,stm32mp13-dwmac + then: + properties: + st,syscon: + items: + minItems: 3 + maxItems: 3 + examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/stm32mp1-clks.h> - #include <dt-bindings/reset/stm32mp1-resets.h> - #include <dt-bindings/mfd/stm32h7-rcc.h> //Example 1 ethernet0: ethernet@5800a000 { compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a"; diff --git a/Documentation/devicetree/bindings/net/ti,icss-iep.yaml b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml index f5c22d6dcaee..e36e3a622904 100644 --- a/Documentation/devicetree/bindings/net/ti,icss-iep.yaml +++ b/Documentation/devicetree/bindings/net/ti,icss-iep.yaml @@ -28,6 +28,15 @@ properties: maxItems: 1 description: phandle to the IEP source clock + interrupts: + maxItems: 1 + description: + Interrupt specifier for capture/compare IRQ. + + interrupt-names: + items: + - const: iep_cap_cmp + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml index e253fa786092..c296e5711848 100644 --- a/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml +++ b/Documentation/devicetree/bindings/net/ti,icssg-prueth.yaml @@ -55,6 +55,14 @@ properties: description: phandle to MII_RT module's syscon regmap + ti,pa-stats: + $ref: /schemas/types.yaml#/definitions/phandle + description: + phandle to PA_STATS module's syscon regmap. PA_STATS is a set of + registers where different statistics related to ICSSG, are dumped by + ICSSG firmware. PA_STATS module's syscon regmap will help the device to + access/read/write those statistics. + ti,iep: $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 2 @@ -194,6 +202,7 @@ examples: "tx1-0", "tx1-1", "tx1-2", "tx1-3", "rx0", "rx1"; ti,mii-g-rt = <&icssg2_mii_g_rt>; + ti,pa-stats = <&icssg2_pa_stats>; ti,iep = <&icssg2_iep0>, <&icssg2_iep1>; interrupt-parent = <&icssg2_intc>; interrupts = <24 0 2>, <25 1 3>; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml index 5c4498b762c8..070c4c9b8643 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml @@ -128,6 +128,11 @@ properties: Whether to skip executing an SCM call that reassigns the memory region ownership. + qcom,no-msa-ready-indicator: + type: boolean + description: + Don't wait for MSA_READY indicator to complete init. + qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array description: State bits used by the AP to signal the WLAN Q6. diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml index 41d023797d7d..8675d7d0215c 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k-pci.yaml @@ -17,6 +17,7 @@ description: | properties: compatible: enum: + - pci17cb,1101 # QCA6390 - pci17cb,1103 # WCN6855 reg: @@ -28,10 +29,55 @@ properties: string to uniquely identify variant of the calibration data for designs with colliding bus and device ids + vddrfacmn-supply: + description: VDD_RFA_CMN supply regulator handle + + vddaon-supply: + description: VDD_AON supply regulator handle + + vddwlcx-supply: + description: VDD_WL_CX supply regulator handle + + vddwlmx-supply: + description: VDD_WL_MX supply regulator handle + + vddrfa0p8-supply: + description: VDD_RFA_0P8 supply regulator handle + + vddrfa1p2-supply: + description: VDD_RFA_1P2 supply regulator handle + + vddrfa1p7-supply: + description: VDD_RFA_1P7 supply regulator handle + + vddpcie0p9-supply: + description: VDD_PCIE_0P9 supply regulator handle + + vddpcie1p8-supply: + description: VDD_PCIE_1P8 supply regulator handle + required: - compatible - reg +allOf: + - if: + properties: + compatible: + contains: + const: pci17cb,1101 + then: + required: + - vddrfacmn-supply + - vddaon-supply + - vddwlcx-supply + - vddwlmx-supply + - vddrfa0p8-supply + - vddrfa1p2-supply + - vddrfa1p7-supply + - vddpcie0p9-supply + - vddpcie1p8-supply + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index a2d55bf4c7a5..ff5763dc66a8 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -265,15 +265,6 @@ allOf: examples: - | - - q6v5_wcss: remoteproc@cd00000 { - compatible = "qcom,ipq8074-wcss-pil"; - reg = <0xcd00000 0x4040>, - <0x4ab000 0x20>; - reg-names = "qdsp6", - "rmb"; - }; - wifi0: wifi@c000000 { compatible = "qcom,ipq8074-wifi"; reg = <0xc000000 0x2000000>; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml new file mode 100644 index 000000000000..1b5884015b15 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2024 Linaro Limited +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/wireless/qcom,ath12k.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies ath12k wireless devices (PCIe) + +maintainers: + - Jeff Johnson <quic_jjohnson@quicinc.com> + - Kalle Valo <kvalo@kernel.org> + +description: + Qualcomm Technologies IEEE 802.11be PCIe devices. + +properties: + compatible: + enum: + - pci17cb,1107 # WCN7850 + + reg: + maxItems: 1 + + vddaon-supply: + description: VDD_AON supply regulator handle + + vddwlcx-supply: + description: VDD_WLCX supply regulator handle + + vddwlmx-supply: + description: VDD_WLMX supply regulator handle + + vddrfacmn-supply: + description: VDD_RFA_CMN supply regulator handle + + vddrfa0p8-supply: + description: VDD_RFA_0P8 supply regulator handle + + vddrfa1p2-supply: + description: VDD_RFA_1P2 supply regulator handle + + vddrfa1p8-supply: + description: VDD_RFA_1P8 supply regulator handle + + vddpcie0p9-supply: + description: VDD_PCIE_0P9 supply regulator handle + + vddpcie1p8-supply: + description: VDD_PCIE_1P8 supply regulator handle + +required: + - compatible + - reg + - vddaon-supply + - vddwlcx-supply + - vddwlmx-supply + - vddrfacmn-supply + - vddrfa0p8-supply + - vddrfa1p2-supply + - vddrfa1p8-supply + - vddpcie0p9-supply + - vddpcie1p8-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/gpio/gpio.h> + pcie { + #address-cells = <3>; + #size-cells = <2>; + + pcie@0 { + device_type = "pci"; + reg = <0x0 0x0 0x0 0x0 0x0>; + #address-cells = <3>; + #size-cells = <2>; + ranges; + + bus-range = <0x01 0xff>; + + wifi@0 { + compatible = "pci17cb,1107"; + reg = <0x10000 0x0 0x0 0x0 0x0>; + + vddaon-supply = <&vreg_pmu_aon_0p59>; + vddwlcx-supply = <&vreg_pmu_wlcx_0p8>; + vddwlmx-supply = <&vreg_pmu_wlmx_0p85>; + vddrfacmn-supply = <&vreg_pmu_rfa_cmn>; + vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>; + vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>; + vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>; + vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>; + vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml index 0f781dac6717..eb803ddd13e0 100644 --- a/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml +++ b/Documentation/devicetree/bindings/net/xlnx,gmii-to-rgmii.yaml @@ -31,6 +31,10 @@ properties: phy-handle: $ref: ethernet-controller.yaml#/properties/phy-handle + clocks: + items: + - description: 200/375 MHz free-running clock is used as input clock. + required: - compatible - reg @@ -51,5 +55,6 @@ examples: compatible = "xlnx,gmii-to-rgmii-1.0"; reg = <8>; phy-handle = <&phy>; + clocks = <&dummy>; }; }; diff --git a/Documentation/devicetree/bindings/ptp/fsl,ptp.yaml b/Documentation/devicetree/bindings/ptp/fsl,ptp.yaml new file mode 100644 index 000000000000..3bb8615e3e91 --- /dev/null +++ b/Documentation/devicetree/bindings/ptp/fsl,ptp.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ptp/fsl,ptp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale QorIQ 1588 timer based PTP clock + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +properties: + compatible: + enum: + - fsl,etsec-ptp + - fsl,fman-ptp-timer + - fsl,dpaa2-ptp + - fsl,enetc-ptp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + fsl,cksel: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Timer reference clock source. + + Reference clock source is determined by the value, which is holded + in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the + value, which will be directly written in those bits, that is why, + according to reference manual, the next clock sources can be used: + + For eTSEC, + <0> - external high precision timer reference clock (TSEC_TMR_CLK + input is used for this purpose); + <1> - eTSEC system clock; + <2> - eTSEC1 transmit clock; + <3> - RTC clock input. + + For DPAA FMan, + <0> - external high precision timer reference clock (TMR_1588_CLK) + <1> - MAC system clock (1/2 FMan clock) + <2> - reserved + <3> - RTC clock oscillator + + fsl,tclk-period: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Timer reference clock period in nanoseconds. + + fsl,tmr-prsc: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Prescaler, divides the output clock. + + fsl,tmr-add: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Frequency compensation value. + + fsl,tmr-fiper1: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Fixed interval period pulse generator. + + fsl,tmr-fiper2: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Fixed interval period pulse generator. + + fsl,tmr-fiper3: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Fixed interval period pulse generator. + Supported only on DPAA2 and ENETC hardware. + + fsl,max-adj: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum frequency adjustment in parts per billion. + + These properties set the operational parameters for the PTP + clock. You must choose these carefully for the clock to work right. + Here is how to figure good values: + + TimerOsc = selected reference clock MHz + tclk_period = desired clock period nanoseconds + NominalFreq = 1000 / tclk_period MHz + FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0) + tmr_add = ceil(2^32 / FreqDivRatio) + OutputClock = NominalFreq / tmr_prsc MHz + PulseWidth = 1 / OutputClock microseconds + FiperFreq1 = desired frequency in Hz + FiperDiv1 = 1000000 * OutputClock / FiperFreq1 + tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period + max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1 + + The calculation for tmr_fiper2 is the same as for tmr_fiper1. The + driver expects that tmr_fiper1 will be correctly set to produce a 1 + Pulse Per Second (PPS) signal, since this will be offered to the PPS + subsystem to synchronize the Linux clock. + + When this attribute is not used, the IEEE 1588 timer reference clock + will use the eTSEC system clock (for Gianfar) or the MAC system + clock (for DPAA). + + fsl,extts-fifo: + $ref: /schemas/types.yaml#/definitions/flag + description: + The presence of this property indicates hardware + support for the external trigger stamp FIFO + + little-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: + The presence of this property indicates the 1588 timer + support for the external trigger stamp FIFO. + IP block is little-endian mode. The default endian mode + is big-endian. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + phc@24e00 { + compatible = "fsl,etsec-ptp"; + reg = <0x24e00 0xb0>; + interrupts = <12 IRQ_TYPE_LEVEL_LOW>; + interrupt-parent = <&ipic>; + fsl,cksel = <1>; + fsl,tclk-period = <10>; + fsl,tmr-prsc = <100>; + fsl,tmr-add = <0x999999a4>; + fsl,tmr-fiper1 = <0x3b9ac9f6>; + fsl,tmr-fiper2 = <0x00018696>; + fsl,max-adj = <659999998>; + }; diff --git a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt b/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt deleted file mode 100644 index 743eda754e65..000000000000 --- a/Documentation/devicetree/bindings/ptp/ptp-qoriq.txt +++ /dev/null @@ -1,87 +0,0 @@ -* Freescale QorIQ 1588 timer based PTP clock - -General Properties: - - - compatible Should be "fsl,etsec-ptp" for eTSEC - Should be "fsl,fman-ptp-timer" for DPAA FMan - Should be "fsl,dpaa2-ptp" for DPAA2 - Should be "fsl,enetc-ptp" for ENETC - - reg Offset and length of the register set for the device - - interrupts There should be at least two interrupts. Some devices - have as many as four PTP related interrupts. - -Clock Properties: - - - fsl,cksel Timer reference clock source. - - fsl,tclk-period Timer reference clock period in nanoseconds. - - fsl,tmr-prsc Prescaler, divides the output clock. - - fsl,tmr-add Frequency compensation value. - - fsl,tmr-fiper1 Fixed interval period pulse generator. - - fsl,tmr-fiper2 Fixed interval period pulse generator. - - fsl,tmr-fiper3 Fixed interval period pulse generator. - Supported only on DPAA2 and ENETC hardware. - - fsl,max-adj Maximum frequency adjustment in parts per billion. - - fsl,extts-fifo The presence of this property indicates hardware - support for the external trigger stamp FIFO. - - little-endian The presence of this property indicates the 1588 timer - IP block is little-endian mode. The default endian mode - is big-endian. - - These properties set the operational parameters for the PTP - clock. You must choose these carefully for the clock to work right. - Here is how to figure good values: - - TimerOsc = selected reference clock MHz - tclk_period = desired clock period nanoseconds - NominalFreq = 1000 / tclk_period MHz - FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0) - tmr_add = ceil(2^32 / FreqDivRatio) - OutputClock = NominalFreq / tmr_prsc MHz - PulseWidth = 1 / OutputClock microseconds - FiperFreq1 = desired frequency in Hz - FiperDiv1 = 1000000 * OutputClock / FiperFreq1 - tmr_fiper1 = tmr_prsc * tclk_period * FiperDiv1 - tclk_period - max_adj = 1000000000 * (FreqDivRatio - 1.0) - 1 - - The calculation for tmr_fiper2 is the same as for tmr_fiper1. The - driver expects that tmr_fiper1 will be correctly set to produce a 1 - Pulse Per Second (PPS) signal, since this will be offered to the PPS - subsystem to synchronize the Linux clock. - - Reference clock source is determined by the value, which is holded - in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the - value, which will be directly written in those bits, that is why, - according to reference manual, the next clock sources can be used: - - For eTSEC, - <0> - external high precision timer reference clock (TSEC_TMR_CLK - input is used for this purpose); - <1> - eTSEC system clock; - <2> - eTSEC1 transmit clock; - <3> - RTC clock input. - - For DPAA FMan, - <0> - external high precision timer reference clock (TMR_1588_CLK) - <1> - MAC system clock (1/2 FMan clock) - <2> - reserved - <3> - RTC clock oscillator - - When this attribute is not used, the IEEE 1588 timer reference clock - will use the eTSEC system clock (for Gianfar) or the MAC system - clock (for DPAA). - -Example: - - ptp_clock@24e00 { - compatible = "fsl,etsec-ptp"; - reg = <0x24E00 0xB0>; - interrupts = <12 0x8 13 0x8>; - interrupt-parent = < &ipic >; - fsl,cksel = <1>; - fsl,tclk-period = <10>; - fsl,tmr-prsc = <100>; - fsl,tmr-add = <0x999999A4>; - fsl,tmr-fiper1 = <0x3B9AC9F6>; - fsl,tmr-fiper2 = <0x00018696>; - fsl,max-adj = <659999998>; - }; diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml index 95b0eb1486bf..94132d30e0e0 100644 --- a/Documentation/netlink/specs/dpll.yaml +++ b/Documentation/netlink/specs/dpll.yaml @@ -479,6 +479,7 @@ operations: name: pin-get doc: | Get list of pins and its attributes. + - dump request without any attributes given - list all the pins in the system - dump request with target dpll - list all the pins registered with diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml index 4510e8d1adcb..495e35fcfb21 100644 --- a/Documentation/netlink/specs/ethtool.yaml +++ b/Documentation/netlink/specs/ethtool.yaml @@ -20,6 +20,25 @@ definitions: name: header-flags type: flags entries: [ compact-bitsets, omit-reply, stats ] + - + name: module-fw-flash-status + type: enum + entries: [ started, in_progress, completed, error ] + - + name: c33-pse-ext-state + enum-name: + type: enum + name-prefix: ethtool-c33-pse-ext-state- + entries: + - none + - error-condition + - mr-mps-valid + - mr-pse-enable + - option-detect-ted + - option-vport-lim + - ovld-detected + - power-not-available + - short-detected attribute-sets: - @@ -415,6 +434,26 @@ attribute-sets: type: u32 - + name: irq-moderation + attributes: + - + name: usec + type: u32 + - + name: pkts + type: u32 + - + name: comps + type: u32 + - + name: profile + attributes: + - + name: irq-moderation + type: nest + multi-attr: true + nested-attributes: irq-moderation + - name: coalesce attributes: - @@ -502,6 +541,15 @@ attribute-sets: - name: tx-aggr-time-usecs type: u32 + - + name: rx-profile + type: nest + nested-attributes: profile + - + name: tx-profile + type: nest + nested-attributes: profile + - name: pause-stat attributes: @@ -892,6 +940,15 @@ attribute-sets: name: power-mode type: u8 - + name: c33-pse-pw-limit + attributes: + - + name: min + type: u32 + - + name: max + type: u32 + - name: pse attributes: - @@ -922,6 +979,33 @@ attribute-sets: name: c33-pse-pw-d-status type: u32 name-prefix: ethtool-a- + - + name: c33-pse-pw-class + type: u32 + name-prefix: ethtool-a- + - + name: c33-pse-actual-pw + type: u32 + name-prefix: ethtool-a- + - + name: c33-pse-ext-state + type: u32 + name-prefix: ethtool-a- + enum: c33-pse-ext-state + - + name: c33-pse-ext-substate + type: u32 + name-prefix: ethtool-a- + - + name: c33-pse-avail-pw-limit + type: u32 + name-prefix: ethtool-a- + - + name: c33-pse-pw-limit-ranges + name-prefix: ethtool-a- + type: nest + multi-attr: true + nested-attributes: c33-pse-pw-limit - name: rss attributes: @@ -975,6 +1059,32 @@ attribute-sets: - name: burst-tmr type: u32 + - + name: module-fw-flash + attributes: + - + name: header + type: nest + nested-attributes: header + - + name: file-name + type: string + - + name: password + type: u32 + - + name: status + type: u32 + enum: module-fw-flash-status + - + name: status-msg + type: string + - + name: done + type: uint + - + name: total + type: uint operations: enum-model: directional @@ -1325,6 +1435,8 @@ operations: - tx-aggr-max-bytes - tx-aggr-max-frames - tx-aggr-time-usecs + - rx-profile + - tx-profile dump: *coalesce-get-op - name: coalesce-set @@ -1611,6 +1723,12 @@ operations: - c33-pse-admin-state - c33-pse-admin-control - c33-pse-pw-d-status + - c33-pse-pw-class + - c33-pse-actual-pw + - c33-pse-ext-state + - c33-pse-ext-substate + - c33-pse-avail-pw-limit + - c33-pse-pw-limit-ranges dump: *pse-get-op - name: pse-set @@ -1624,6 +1742,7 @@ operations: - header - podl-pse-admin-control - c33-pse-admin-control + - c33-pse-avail-pw-limit - name: rss-get doc: Get RSS params. @@ -1733,3 +1852,28 @@ operations: name: mm-ntf doc: Notification for change in MAC Merge configuration. notify: mm-get + - + name: module-fw-flash-act + doc: Flash transceiver module firmware. + + attribute-set: module-fw-flash + + do: + request: + attributes: + - header + - file-name + - password + - + name: module-fw-flash-ntf + doc: Notification for firmware flashing progress and status. + + attribute-set: module-fw-flash + + event: + attributes: + - header + - status + - status-msg + - done + - total diff --git a/Documentation/netlink/specs/ovs_flow.yaml b/Documentation/netlink/specs/ovs_flow.yaml index 4fdfc6b5cae9..46f5d1cd8a5f 100644 --- a/Documentation/netlink/specs/ovs_flow.yaml +++ b/Documentation/netlink/specs/ovs_flow.yaml @@ -727,6 +727,12 @@ attribute-sets: name: dec-ttl type: nest nested-attributes: dec-ttl-attrs + - + name: psample + type: nest + nested-attributes: psample-attrs + doc: | + Sends a packet sample to psample for external observation. - name: tunnel-key-attrs enum-name: ovs-tunnel-key-attr @@ -938,6 +944,17 @@ attribute-sets: - name: gbp type: u32 + - + name: psample-attrs + enum-name: ovs-psample-attr + name-prefix: ovs-psample-attr- + attributes: + - + name: group + type: u32 + - + name: cookie + type: binary operations: name-prefix: ovs-flow-cmd- diff --git a/Documentation/netlink/specs/tc.yaml b/Documentation/netlink/specs/tc.yaml index 8c01e4e13195..b02d59a0349c 100644 --- a/Documentation/netlink/specs/tc.yaml +++ b/Documentation/netlink/specs/tc.yaml @@ -42,6 +42,16 @@ definitions: - not-in-nw - verbose - + name: tc-flower-key-ctrl-flags + type: flags + entries: + - frag + - firstfrag + - tuncsum + - tundf + - tunoam + - tuncrit + - name: tc-stats type: struct members: @@ -2536,10 +2546,14 @@ attribute-sets: name: key-flags type: u32 byte-order: big-endian + enum: tc-flower-key-ctrl-flags + enum-as-flags: true - name: key-flags-mask type: u32 byte-order: big-endian + enum: tc-flower-key-ctrl-flags + enum-as-flags: true - name: key-icmpv4-code type: u8 @@ -2749,6 +2763,18 @@ attribute-sets: name: key-spi-mask type: u32 byte-order: big-endian + - + name: key-enc-flags + type: u32 + byte-order: big-endian + enum: tc-flower-key-ctrl-flags + enum-as-flags: true + - + name: key-enc-flags-mask + type: u32 + byte-order: big-endian + enum: tc-flower-key-ctrl-flags + enum-as-flags: true - name: tc-flower-key-enc-opts-attrs attributes: diff --git a/Documentation/netlink/specs/tcp_metrics.yaml b/Documentation/netlink/specs/tcp_metrics.yaml new file mode 100644 index 000000000000..1bd94f43e526 --- /dev/null +++ b/Documentation/netlink/specs/tcp_metrics.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) + +name: tcp_metrics + +protocol: genetlink-legacy + +doc: | + Management interface for TCP metrics. + +c-family-name: tcp-metrics-genl-name +c-version-name: tcp-metrics-genl-version +max-by-define: true +kernel-policy: global + +definitions: + - + name: tcp-fastopen-cookie-max + type: const + value: 16 + +attribute-sets: + - + name: tcp-metrics + name-prefix: tcp-metrics-attr- + attributes: + - + name: addr-ipv4 + type: u32 + byte-order: big-endian + display-hint: ipv4 + - + name: addr-ipv6 + type: binary + checks: + min-len: 16 + byte-order: big-endian + display-hint: ipv6 + - + name: age + type: u64 + - + name: tw-tsval + type: u32 + doc: unused + - + name: tw-ts-stamp + type: s32 + doc: unused + - + name: vals + type: nest + nested-attributes: metrics + - + name: fopen-mss + type: u16 + - + name: fopen-syn-drops + type: u16 + - + name: fopen-syn-drop-ts + type: u64 + - + name: fopen-cookie + type: binary + checks: + min-len: tcp-fastopen-cookie-max + - + name: saddr-ipv4 + type: u32 + byte-order: big-endian + display-hint: ipv4 + - + name: saddr-ipv6 + type: binary + checks: + min-len: 16 + byte-order: big-endian + display-hint: ipv6 + - + name: pad + type: pad + + - + name: metrics + # Intentionally don't define the name-prefix, see below. + doc: | + Attributes with metrics. Note that the values here do not match + the TCP_METRIC_* defines in the kernel, because kernel defines + are off-by one (e.g. rtt is defined as enum 0, while netlink carries + attribute type 1). + attributes: + - + name: rtt + type: u32 + doc: | + Round Trip Time (RTT), in msecs with 3 bits fractional + (left-shift by 3 to get the msec value). + - + name: rttvar + type: u32 + doc: | + Round Trip Time VARiance (RTT), in msecs with 2 bits fractional + (left-shift by 2 to get the msec value). + - + name: ssthresh + type: u32 + doc: Slow Start THRESHold. + - + name: cwnd + type: u32 + doc: Congestion Window. + - + name: reodering + type: u32 + doc: Reodering metric. + - + name: rtt-us + type: u32 + doc: | + Round Trip Time (RTT), in usecs, with 3 bits fractional + (left-shift by 3 to get the msec value). + - + name: rttvar-us + type: u32 + doc: | + Round Trip Time (RTT), in usecs, with 2 bits fractional + (left-shift by 3 to get the msec value). + +operations: + list: + - + name: get + doc: Retrieve metrics. + attribute-set: tcp-metrics + + dont-validate: [ strict, dump ] + + do: + request: &sel_attrs + attributes: + - addr-ipv4 + - addr-ipv6 + - saddr-ipv4 + - saddr-ipv6 + reply: &all_attrs + attributes: + - addr-ipv4 + - addr-ipv6 + - saddr-ipv4 + - saddr-ipv6 + - age + - vals + - fopen-mss + - fopen-syn-drops + - fopen-syn-drop-ts + - fopen-cookie + dump: + reply: *all_attrs + + - + name: del + doc: Delete metrics. + attribute-set: tcp-metrics + + dont-validate: [ strict, dump ] + flags: [ admin-perm ] + + do: + request: *sel_attrs diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst index fed821ef9b09..3bd72577af9a 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst @@ -189,22 +189,19 @@ the software port. * - `rx[i]_gro_packets` - Number of received packets processed using hardware-accelerated GRO. The - number of hardware GRO offloaded packets received on ring i. + number of hardware GRO offloaded packets received on ring i. Only true GRO + packets are counted: only packets that are in an SKB with a GRO count > 1. - Acceleration * - `rx[i]_gro_bytes` - Number of received bytes processed using hardware-accelerated GRO. The - number of hardware GRO offloaded bytes received on ring i. + number of hardware GRO offloaded bytes received on ring i. Only true GRO + packets are counted: only packets that are in an SKB with a GRO count > 1. - Acceleration * - `rx[i]_gro_skbs` - - The number of receive SKBs constructed while performing - hardware-accelerated GRO. - - Informative - - * - `rx[i]_gro_match_packets` - - Number of received packets processed using hardware-accelerated GRO that - met the flow table match criteria. + - The number of GRO SKBs constructed from hardware-accelerated GRO. Only SKBs + with a GRO count > 1 are counted. - Informative * - `rx[i]_gro_large_hds` @@ -212,6 +209,15 @@ the software port. headers that require additional memory to be allocated. - Informative + * - `rx[i]_hds_nodata_packets` + - Number of header only packets in header/data split mode [#accel]_. + - Informative + + * - `rx[i]_hds_nodata_bytes` + - Number of bytes for header only packets in header/data split mode + [#accel]_. + - Informative + * - `rx[i]_lro_packets` - The number of LRO packets received on ring i [#accel]_. - Acceleration diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index 830c04354222..e3972d03cea0 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -11,6 +11,7 @@ Parameters ========== .. list-table:: Generic parameters implemented + :widths: 5 5 90 * - Name - Mode @@ -68,6 +69,30 @@ Parameters To verify that value has been set: $ devlink dev param show pci/0000:16:00.0 name tx_scheduling_layers +.. list-table:: Driver specific parameters implemented + :widths: 5 5 90 + + * - Name + - Mode + - Description + * - ``local_forwarding`` + - runtime + - Controls loopback behavior by tuning scheduler bandwidth. + It impacts all kinds of functions: physical, virtual and + subfunctions. + Supported values are: + + ``enabled`` - loopback traffic is allowed on port + + ``disabled`` - loopback traffic is not allowed on this port + + ``prioritized`` - loopback traffic is prioritized on this port + + Default value of ``local_forwarding`` parameter is ``enabled``. + ``prioritized`` provides ability to adjust loopback traffic rate to increase + one port capacity at cost of the another. User needs to disable + local forwarding on one of the ports in order have increased capacity + on the ``prioritized`` port. Info versions ============= diff --git a/Documentation/networking/devlink/octeontx2.rst b/Documentation/networking/devlink/octeontx2.rst index 610de99b728a..d33a90dd44bf 100644 --- a/Documentation/networking/devlink/octeontx2.rst +++ b/Documentation/networking/devlink/octeontx2.rst @@ -40,3 +40,19 @@ The ``octeontx2 AF`` driver implements the following driver-specific parameters. - runtime - Use to set the quantum which hardware uses for scheduling among transmit queues. Hardware uses weighted DWRR algorithm to schedule among all transmit queues. + +The ``octeontx2 PF`` driver implements the following driver-specific parameters. + +.. list-table:: Driver-specific parameters implemented + :widths: 5 5 5 85 + + * - Name + - Type + - Mode + - Description + * - ``unicast_filter_count`` + - u8 + - runtime + - Set the maximum number of unicast filters that can be programmed for + the device. This can be used to achieve better device resource + utilization, avoiding over consumption of unused MCAM table entries. diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 160bfb0ae8ba..3ab423b80e91 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -228,6 +228,7 @@ Userspace to kernel: ``ETHTOOL_MSG_PLCA_GET_STATUS`` get PLCA RS status ``ETHTOOL_MSG_MM_GET`` get MAC merge layer state ``ETHTOOL_MSG_MM_SET`` set MAC merge layer parameters + ``ETHTOOL_MSG_MODULE_FW_FLASH_ACT`` flash transceiver module firmware ===================================== ================================= Kernel to userspace: @@ -274,6 +275,7 @@ Kernel to userspace: ``ETHTOOL_MSG_PLCA_GET_STATUS_REPLY`` PLCA RS status ``ETHTOOL_MSG_PLCA_NTF`` PLCA RS parameters ``ETHTOOL_MSG_MM_GET_REPLY`` MAC merge layer status + ``ETHTOOL_MSG_MODULE_FW_FLASH_NTF`` transceiver module flash updates ======================================== ================================= ``GET`` requests are sent by userspace applications to retrieve device @@ -1033,6 +1035,8 @@ Kernel response contents: ``ETHTOOL_A_COALESCE_TX_AGGR_MAX_BYTES`` u32 max aggr size, Tx ``ETHTOOL_A_COALESCE_TX_AGGR_MAX_FRAMES`` u32 max aggr packets, Tx ``ETHTOOL_A_COALESCE_TX_AGGR_TIME_USECS`` u32 time (us), aggr, Tx + ``ETHTOOL_A_COALESCE_RX_PROFILE`` nested profile of DIM, Rx + ``ETHTOOL_A_COALESCE_TX_PROFILE`` nested profile of DIM, Tx =========================================== ====== ======================= Attributes are only included in reply if their value is not zero or the @@ -1062,6 +1066,10 @@ block should be sent. This feature is mainly of interest for specific USB devices which does not cope well with frequent small-sized URBs transmissions. +``ETHTOOL_A_COALESCE_RX_PROFILE`` and ``ETHTOOL_A_COALESCE_TX_PROFILE`` refer +to DIM parameters, see `Generic Network Dynamic Interrupt Moderation (Net DIM) +<https://www.kernel.org/doc/Documentation/networking/net_dim.rst>`_. + COALESCE_SET ============ @@ -1098,6 +1106,8 @@ Request contents: ``ETHTOOL_A_COALESCE_TX_AGGR_MAX_BYTES`` u32 max aggr size, Tx ``ETHTOOL_A_COALESCE_TX_AGGR_MAX_FRAMES`` u32 max aggr packets, Tx ``ETHTOOL_A_COALESCE_TX_AGGR_TIME_USECS`` u32 time (us), aggr, Tx + ``ETHTOOL_A_COALESCE_RX_PROFILE`` nested profile of DIM, Rx + ``ETHTOOL_A_COALESCE_TX_PROFILE`` nested profile of DIM, Tx =========================================== ====== ======================= Request is rejected if it attributes declared as unsupported by driver (i.e. @@ -1720,17 +1730,28 @@ Request contents: Kernel response contents: - ====================================== ====== ============================= - ``ETHTOOL_A_PSE_HEADER`` nested reply header - ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` u32 Operational state of the PoDL - PSE functions - ``ETHTOOL_A_PODL_PSE_PW_D_STATUS`` u32 power detection status of the - PoDL PSE. - ``ETHTOOL_A_C33_PSE_ADMIN_STATE`` u32 Operational state of the PoE - PSE functions. - ``ETHTOOL_A_C33_PSE_PW_D_STATUS`` u32 power detection status of the - PoE PSE. - ====================================== ====== ============================= + ========================================== ====== ============================= + ``ETHTOOL_A_PSE_HEADER`` nested reply header + ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` u32 Operational state of the PoDL + PSE functions + ``ETHTOOL_A_PODL_PSE_PW_D_STATUS`` u32 power detection status of the + PoDL PSE. + ``ETHTOOL_A_C33_PSE_ADMIN_STATE`` u32 Operational state of the PoE + PSE functions. + ``ETHTOOL_A_C33_PSE_PW_D_STATUS`` u32 power detection status of the + PoE PSE. + ``ETHTOOL_A_C33_PSE_PW_CLASS`` u32 power class of the PoE PSE. + ``ETHTOOL_A_C33_PSE_ACTUAL_PW`` u32 actual power drawn on the + PoE PSE. + ``ETHTOOL_A_C33_PSE_EXT_STATE`` u32 power extended state of the + PoE PSE. + ``ETHTOOL_A_C33_PSE_EXT_SUBSTATE`` u32 power extended substatus of + the PoE PSE. + ``ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT`` u32 currently configured power + limit of the PoE PSE. + ``ETHTOOL_A_C33_PSE_PW_LIMIT_RANGES`` nested Supported power limit + configuration ranges. + ========================================== ====== ============================= When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_STATE`` attribute identifies the operational state of the PoDL PSE functions. The operational state of the @@ -1762,6 +1783,46 @@ The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_PW_D_STATUS`` implementing .. kernel-doc:: include/uapi/linux/ethtool.h :identifiers: ethtool_c33_pse_pw_d_status +When set, the optional ``ETHTOOL_A_C33_PSE_PW_CLASS`` attribute identifies +the power class of the C33 PSE. It depends on the class negotiated between +the PSE and the PD. This option is corresponding to ``IEEE 802.3-2022`` +30.9.1.1.8 aPSEPowerClassification. + +When set, the optional ``ETHTOOL_A_C33_PSE_ACTUAL_PW`` attribute identifies +This option is corresponding to ``IEEE 802.3-2022`` 30.9.1.1.23 aPSEActualPower. +Actual power is reported in mW. + +When set, the optional ``ETHTOOL_A_C33_PSE_EXT_STATE`` attribute identifies +the extended error state of the C33 PSE. Possible values are: + +.. kernel-doc:: include/uapi/linux/ethtool.h + :identifiers: ethtool_c33_pse_ext_state + +When set, the optional ``ETHTOOL_A_C33_PSE_EXT_SUBSTATE`` attribute identifies +the extended error state of the C33 PSE. Possible values are: +Possible values are: + +.. kernel-doc:: include/uapi/linux/ethtool.h + :identifiers: ethtool_c33_pse_ext_substate_class_num_events + ethtool_c33_pse_ext_substate_error_condition + ethtool_c33_pse_ext_substate_mr_pse_enable + ethtool_c33_pse_ext_substate_option_detect_ted + ethtool_c33_pse_ext_substate_option_vport_lim + ethtool_c33_pse_ext_substate_ovld_detected + ethtool_c33_pse_ext_substate_pd_dll_power_type + ethtool_c33_pse_ext_substate_power_not_available + ethtool_c33_pse_ext_substate_short_detected + +When set, the optional ``ETHTOOL_A_C33_PSE_AVAIL_PW_LIMIT`` attribute +identifies the C33 PSE power limit in mW. + +When set the optional ``ETHTOOL_A_C33_PSE_PW_LIMIT_RANGES`` nested attribute +identifies the C33 PSE power limit ranges through +``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_RANGE_MIN`` and +``ETHTOOL_A_C33_PSE_PWR_VAL_LIMIT_RANGE_MAX``. +If the controller works with fixed classes, the min and max values will be +equal. + PSE_SET ======= @@ -1773,6 +1834,8 @@ Request contents: ``ETHTOOL_A_PSE_HEADER`` nested request header ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` u32 Control PoDL PSE Admin state ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL`` u32 Control PSE Admin state + ``ETHTOOL_A_C33_PSE_AVAIL_PWR_LIMIT`` u32 Control PoE PSE available + power limit ====================================== ====== ============================= When set, the optional ``ETHTOOL_A_PODL_PSE_ADMIN_CONTROL`` attribute is used @@ -1783,6 +1846,18 @@ to control PoDL PSE Admin functions. This option is implementing The same goes for ``ETHTOOL_A_C33_PSE_ADMIN_CONTROL`` implementing ``IEEE 802.3-2022`` 30.9.1.2.1 acPSEAdminControl. +When set, the optional ``ETHTOOL_A_C33_PSE_AVAIL_PWR_LIMIT`` attribute is +used to control the available power value limit for C33 PSE in milliwatts. +This attribute corresponds to the `pse_available_power` variable described in +``IEEE 802.3-2022`` 33.2.4.4 Variables and `pse_avail_pwr` in 145.2.5.4 +Variables, which are described in power classes. + +It was decided to use milliwatts for this interface to unify it with other +power monitoring interfaces, which also use milliwatts, and to align with +various existing products that document power consumption in watts rather than +classes. If power limit configuration based on classes is needed, the +conversion can be done in user space, for example by ethtool. + RSS_GET ======= @@ -2033,6 +2108,73 @@ The attributes are propagated to the driver through the following structure: .. kernel-doc:: include/linux/ethtool.h :identifiers: ethtool_mm_cfg +MODULE_FW_FLASH_ACT +=================== + +Flashes transceiver module firmware. + +Request contents: + + ======================================= ====== =========================== + ``ETHTOOL_A_MODULE_FW_FLASH_HEADER`` nested request header + ``ETHTOOL_A_MODULE_FW_FLASH_FILE_NAME`` string firmware image file name + ``ETHTOOL_A_MODULE_FW_FLASH_PASSWORD`` u32 transceiver module password + ======================================= ====== =========================== + +The firmware update process consists of three logical steps: + +1. Downloading a firmware image to the transceiver module and validating it. +2. Running the firmware image. +3. Committing the firmware image so that it is run upon reset. + +When flash command is given, those three steps are taken in that order. + +This message merely schedules the update process and returns immediately +without blocking. The process then runs asynchronously. +Since it can take several minutes to complete, during the update process +notifications are emitted from the kernel to user space updating it about +the status and progress. + +The ``ETHTOOL_A_MODULE_FW_FLASH_FILE_NAME`` attribute encodes the firmware +image file name. The firmware image is downloaded to the transceiver module, +validated, run and committed. + +The optional ``ETHTOOL_A_MODULE_FW_FLASH_PASSWORD`` attribute encodes a password +that might be required as part of the transceiver module firmware update +process. + +The firmware update process can take several minutes to complete. Therefore, +during the update process notifications are emitted from the kernel to user +space updating it about the status and progress. + + + +Notification contents: + + +---------------------------------------------------+--------+----------------+ + | ``ETHTOOL_A_MODULE_FW_FLASH_HEADER`` | nested | reply header | + +---------------------------------------------------+--------+----------------+ + | ``ETHTOOL_A_MODULE_FW_FLASH_STATUS`` | u32 | status | + +---------------------------------------------------+--------+----------------+ + | ``ETHTOOL_A_MODULE_FW_FLASH_STATUS_MSG`` | string | status message | + +---------------------------------------------------+--------+----------------+ + | ``ETHTOOL_A_MODULE_FW_FLASH_DONE`` | uint | progress | + +---------------------------------------------------+--------+----------------+ + | ``ETHTOOL_A_MODULE_FW_FLASH_TOTAL`` | uint | total | + +---------------------------------------------------+--------+----------------+ + +The ``ETHTOOL_A_MODULE_FW_FLASH_STATUS`` attribute encodes the current status +of the firmware update process. Possible values are: + +.. kernel-doc:: include/uapi/linux/ethtool.h + :identifiers: ethtool_module_fw_flash_status + +The ``ETHTOOL_A_MODULE_FW_FLASH_STATUS_MSG`` attribute encodes a status message +string. + +The ``ETHTOOL_A_MODULE_FW_FLASH_DONE`` and ``ETHTOOL_A_MODULE_FW_FLASH_TOTAL`` +attributes encode the completed and total amount of work, respectively. + Request translation =================== @@ -2139,4 +2281,5 @@ are netlink only. n/a ``ETHTOOL_MSG_PLCA_GET_STATUS`` n/a ``ETHTOOL_MSG_MM_GET`` n/a ``ETHTOOL_MSG_MM_SET`` + n/a ``ETHTOOL_MSG_MODULE_FW_FLASH_ACT`` =================================== ===================================== diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 7664c0bfe461..d1af04b952f8 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -19,6 +19,7 @@ Contents: caif/index ethtool-netlink ieee802154 + iso15765-2 j1939 kapi msg_zerocopy @@ -72,6 +73,7 @@ Contents: mac80211-injection mctp mpls-sysctl + mptcp mptcp-sysctl multiqueue multi-pf-netdev @@ -104,6 +106,7 @@ Contents: seg6-sysctl skbuff smc-sysctl + sriov statistics strparser switchdev diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index bd50df6a5a42..3616389c8c2d 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -131,6 +131,20 @@ fib_multipath_hash_fields - UNSIGNED INTEGER Default: 0x0007 (source IP, destination IP and IP protocol) +fib_multipath_hash_seed - UNSIGNED INTEGER + The seed value used when calculating hash for multipath routes. Applies + to both IPv4 and IPv6 datapath. Only present for kernels built with + CONFIG_IP_ROUTE_MULTIPATH enabled. + + When set to 0, the seed value used for multipath routing defaults to an + internal random-generated one. + + The actual hashing algorithm is not specified -- there is no guarantee + that a next hop distribution effected by a given seed will keep stable + across kernel versions. + + Default: 0 (random) + fib_sync_mem - UNSIGNED INTEGER Amount of dirty memory from fib entries that can be backlogged before synchronize_rcu is forced. @@ -1196,6 +1210,19 @@ tcp_pingpong_thresh - INTEGER Default: 1 +tcp_rto_min_us - INTEGER + Minimal TCP retransmission timeout (in microseconds). Note that the + rto_min route option has the highest precedence for configuring this + setting, followed by the TCP_BPF_RTO_MIN socket option, followed by + this tcp_rto_min_us sysctl. + + The recommended practice is to use a value less or equal to 200000 + microseconds. + + Possible Values: 1 - INT_MAX + + Default: 200000 + UDP variables ============= diff --git a/Documentation/networking/iso15765-2.rst b/Documentation/networking/iso15765-2.rst new file mode 100644 index 000000000000..0e9d96074178 --- /dev/null +++ b/Documentation/networking/iso15765-2.rst @@ -0,0 +1,386 @@ +.. SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) + +==================== +ISO 15765-2 (ISO-TP) +==================== + +Overview +======== + +ISO 15765-2, also known as ISO-TP, is a transport protocol specifically defined +for diagnostic communication on CAN. It is widely used in the automotive +industry, for example as the transport protocol for UDSonCAN (ISO 14229-3) or +emission-related diagnostic services (ISO 15031-5). + +ISO-TP can be used both on CAN CC (aka Classical CAN) and CAN FD (CAN with +Flexible Datarate) based networks. It is also designed to be compatible with a +CAN network using SAE J1939 as data link layer (however, this is not a +requirement). + +Specifications used +------------------- + +* ISO 15765-2:2024 : Road vehicles - Diagnostic communication over Controller + Area Network (DoCAN). Part 2: Transport protocol and network layer services. + +Addressing +---------- + +In its simplest form, ISO-TP is based on two kinds of addressing modes for the +nodes connected to the same network: + +* physical addressing is implemented by two node-specific addresses and is used + in 1-to-1 communication. + +* functional addressing is implemented by one node-specific address and is used + in 1-to-N communication. + +Three different addressing formats can be employed: + +* "normal" : each address is represented simply by a CAN ID. + +* "extended": each address is represented by a CAN ID plus the first byte of + the CAN payload; both the CAN ID and the byte inside the payload shall be + different between two addresses. + +* "mixed": each address is represented by a CAN ID plus the first byte of + the CAN payload; the CAN ID is different between two addresses, but the + additional byte is the same. + +Transport protocol and associated frame types +--------------------------------------------- + +When transmitting data using the ISO-TP protocol, the payload can either fit +inside one single CAN message or not, also considering the overhead the protocol +is generating and the optional extended addressing. In the first case, the data +is transmitted at once using a so-called Single Frame (SF). In the second case, +ISO-TP defines a multi-frame protocol, in which the sender provides (through a +First Frame - FF) the PDU length which is to be transmitted and also asks for a +Flow Control (FC) frame, which provides the maximum supported size of a macro +data block (``blocksize``) and the minimum time between the single CAN messages +composing such block (``stmin``). Once this information has been received, the +sender starts to send frames containing fragments of the data payload (called +Consecutive Frames - CF), stopping after every ``blocksize``-sized block to wait +confirmation from the receiver which should then send another Flow Control +frame to inform the sender about its availability to receive more data. + +How to Use ISO-TP +================= + +As with others CAN protocols, the ISO-TP stack support is built into the +Linux network subsystem for the CAN bus, aka. Linux-CAN or SocketCAN, and +thus follows the same socket API. + +Creation and basic usage of an ISO-TP socket +-------------------------------------------- + +To use the ISO-TP stack, ``#include <linux/can/isotp.h>`` shall be used. A +socket can then be created using the ``PF_CAN`` protocol family, the +``SOCK_DGRAM`` type (as the underlying protocol is datagram-based by design) +and the ``CAN_ISOTP`` protocol: + +.. code-block:: C + + s = socket(PF_CAN, SOCK_DGRAM, CAN_ISOTP); + +After the socket has been successfully created, ``bind(2)`` shall be called to +bind the socket to the desired CAN interface; to do so: + +* a TX CAN ID shall be specified as part of the sockaddr supplied to the call + itself. + +* a RX CAN ID shall also be specified, unless broadcast flags have been set + through socket option (explained below). + +Once bound to an interface, the socket can be read from and written to using +the usual ``read(2)`` and ``write(2)`` system calls, as well as ``send(2)``, +``sendmsg(2)``, ``recv(2)`` and ``recvmsg(2)``. +Unlike the CAN_RAW socket API, only the ISO-TP data field (the actual payload) +is sent and received by the userspace application using these calls. The address +information and the protocol information are automatically filled by the ISO-TP +stack using the configuration supplied during socket creation. In the same way, +the stack will use the transport mechanism when required (i.e., when the size +of the data payload exceeds the MTU of the underlying CAN bus). + +The sockaddr structure used for SocketCAN has extensions for use with ISO-TP, +as specified below: + +.. code-block:: C + + struct sockaddr_can { + sa_family_t can_family; + int can_ifindex; + union { + struct { canid_t rx_id, tx_id; } tp; + ... + } can_addr; + } + +* ``can_family`` and ``can_ifindex`` serve the same purpose as for other + SocketCAN sockets. + +* ``can_addr.tp.rx_id`` specifies the receive (RX) CAN ID and will be used as + a RX filter. + +* ``can_addr.tp.tx_id`` specifies the transmit (TX) CAN ID + +ISO-TP socket options +--------------------- + +When creating an ISO-TP socket, reasonable defaults are set. Some options can +be modified with ``setsockopt(2)`` and/or read back with ``getsockopt(2)``. + +General options +~~~~~~~~~~~~~~~ + +General socket options can be passed using the ``CAN_ISOTP_OPTS`` optname: + +.. code-block:: C + + struct can_isotp_options opts; + ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_OPTS, &opts, sizeof(opts)) + +where the ``can_isotp_options`` structure has the following contents: + +.. code-block:: C + + struct can_isotp_options { + u32 flags; + u32 frame_txtime; + u8 ext_address; + u8 txpad_content; + u8 rxpad_content; + u8 rx_ext_address; + }; + +* ``flags``: modifiers to be applied to the default behaviour of the ISO-TP + stack. Following flags are available: + + * ``CAN_ISOTP_LISTEN_MODE``: listen only (do not send FC frames); normally + used as a testing feature. + + * ``CAN_ISOTP_EXTEND_ADDR``: use the byte specified in ``ext_address`` as an + additional address component. This enables the "mixed" addressing format if + used alone, or the "extended" addressing format if used in conjunction with + ``CAN_ISOTP_RX_EXT_ADDR``. + + * ``CAN_ISOTP_TX_PADDING``: enable padding for transmitted frames, using + ``txpad_content`` as value for the padding bytes. + + * ``CAN_ISOTP_RX_PADDING``: enable padding for the received frames, using + ``rxpad_content`` as value for the padding bytes. + + * ``CAN_ISOTP_CHK_PAD_LEN``: check for correct padding length on the received + frames. + + * ``CAN_ISOTP_CHK_PAD_DATA``: check padding bytes on the received frames + against ``rxpad_content``; if ``CAN_ISOTP_RX_PADDING`` is not specified, + this flag is ignored. + + * ``CAN_ISOTP_HALF_DUPLEX``: force ISO-TP socket in half duplex mode + (that is, transport mechanism can only be incoming or outgoing at the same + time, not both). + + * ``CAN_ISOTP_FORCE_TXSTMIN``: ignore stmin from received FC; normally + used as a testing feature. + + * ``CAN_ISOTP_FORCE_RXSTMIN``: ignore CFs depending on rx stmin; normally + used as a testing feature. + + * ``CAN_ISOTP_RX_EXT_ADDR``: use ``rx_ext_address`` instead of ``ext_address`` + as extended addressing byte on the reception path. If used in conjunction + with ``CAN_ISOTP_EXTEND_ADDR``, this flag effectively enables the "extended" + addressing format. + + * ``CAN_ISOTP_WAIT_TX_DONE``: wait until the frame is sent before returning + from ``write(2)`` and ``send(2)`` calls (i.e., blocking write operations). + + * ``CAN_ISOTP_SF_BROADCAST``: use 1-to-N functional addressing (cannot be + specified alongside ``CAN_ISOTP_CF_BROADCAST``). + + * ``CAN_ISOTP_CF_BROADCAST``: use 1-to-N transmission without flow control + (cannot be specified alongside ``CAN_ISOTP_SF_BROADCAST``). + NOTE: this is not covered by the ISO 15765-2 standard. + + * ``CAN_ISOTP_DYN_FC_PARMS``: enable dynamic update of flow control + parameters. + +* ``frame_txtime``: frame transmission time (defined as N_As/N_Ar inside the + ISO standard); if ``0``, the default (or the last set value) is used. + To set the transmission time to ``0``, the ``CAN_ISOTP_FRAME_TXTIME_ZERO`` + macro (equal to 0xFFFFFFFF) shall be used. + +* ``ext_address``: extended addressing byte, used if the + ``CAN_ISOTP_EXTEND_ADDR`` flag is specified. + +* ``txpad_content``: byte used as padding value for transmitted frames. + +* ``rxpad_content``: byte used as padding value for received frames. + +* ``rx_ext_address``: extended addressing byte for the reception path, used if + the ``CAN_ISOTP_RX_EXT_ADDR`` flag is specified. + +Flow Control options +~~~~~~~~~~~~~~~~~~~~ + +Flow Control (FC) options can be passed using the ``CAN_ISOTP_RECV_FC`` optname +to provide the communication parameters for receiving ISO-TP PDUs. + +.. code-block:: C + + struct can_isotp_fc_options fc_opts; + ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_RECV_FC, &fc_opts, sizeof(fc_opts)); + +where the ``can_isotp_fc_options`` structure has the following contents: + +.. code-block:: C + + struct can_isotp_options { + u8 bs; + u8 stmin; + u8 wftmax; + }; + +* ``bs``: blocksize provided in flow control frames. + +* ``stmin``: minimum separation time provided in flow control frames; can + have the following values (others are reserved): + + * 0x00 - 0x7F : 0 - 127 ms + + * 0xF1 - 0xF9 : 100 us - 900 us + +* ``wftmax``: maximum number of wait frames provided in flow control frames. + +Link Layer options +~~~~~~~~~~~~~~~~~~ + +Link Layer (LL) options can be passed using the ``CAN_ISOTP_LL_OPTS`` optname: + +.. code-block:: C + + struct can_isotp_ll_options ll_opts; + ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_LL_OPTS, &ll_opts, sizeof(ll_opts)); + +where the ``can_isotp_ll_options`` structure has the following contents: + +.. code-block:: C + + struct can_isotp_ll_options { + u8 mtu; + u8 tx_dl; + u8 tx_flags; + }; + +* ``mtu``: generated and accepted CAN frame type, can be equal to ``CAN_MTU`` + for classical CAN frames or ``CANFD_MTU`` for CAN FD frames. + +* ``tx_dl``: maximum payload length for transmitted frames, can have one value + among: 8, 12, 16, 20, 24, 32, 48, 64. Values above 8 only apply to CAN FD + traffic (i.e.: ``mtu = CANFD_MTU``). + +* ``tx_flags``: flags set into ``struct canfd_frame.flags`` at frame creation. + Only applies to CAN FD traffic (i.e.: ``mtu = CANFD_MTU``). + +Transmission stmin +~~~~~~~~~~~~~~~~~~ + +The transmission minimum separation time (stmin) can be forced using the +``CAN_ISOTP_TX_STMIN`` optname and providing an stmin value in microseconds as +a 32bit unsigned integer; this will overwrite the value sent by the receiver in +flow control frames: + +.. code-block:: C + + uint32_t stmin; + ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_TX_STMIN, &stmin, sizeof(stmin)); + +Reception stmin +~~~~~~~~~~~~~~~ + +The reception minimum separation time (stmin) can be forced using the +``CAN_ISOTP_RX_STMIN`` optname and providing an stmin value in microseconds as +a 32bit unsigned integer; received Consecutive Frames (CF) which timestamps +differ less than this value will be ignored: + +.. code-block:: C + + uint32_t stmin; + ret = setsockopt(s, SOL_CAN_ISOTP, CAN_ISOTP_RX_STMIN, &stmin, sizeof(stmin)); + +Multi-frame transport support +----------------------------- + +The ISO-TP stack contained inside the Linux kernel supports the multi-frame +transport mechanism defined by the standard, with the following constraints: + +* the maximum size of a PDU is defined by a module parameter, with an hard + limit imposed at build time. + +* when a transmission is in progress, subsequent calls to ``write(2)`` will + block, while calls to ``send(2)`` will either block or fail depending on the + presence of the ``MSG_DONTWAIT`` flag. + +* no support is present for sending "wait frames": whether a PDU can be fully + received or not is decided when the First Frame is received. + +Errors +------ + +Following errors are reported to userspace: + +RX path errors +~~~~~~~~~~~~~~ + +============ =============================================================== +-ETIMEDOUT timeout of data reception +-EILSEQ sequence number mismatch during a multi-frame reception +-EBADMSG data reception with wrong padding +============ =============================================================== + +TX path errors +~~~~~~~~~~~~~~ + +========== ================================================================= +-ECOMM flow control reception timeout +-EMSGSIZE flow control reception overflow +-EBADMSG flow control reception with wrong layout/padding +========== ================================================================= + +Examples +======== + +Basic node example +------------------ + +Following example implements a node using "normal" physical addressing, with +RX ID equal to 0x18DAF142 and a TX ID equal to 0x18DA42F1. All options are left +to their default. + +.. code-block:: C + + int s; + struct sockaddr_can addr; + int ret; + + s = socket(PF_CAN, SOCK_DGRAM, CAN_ISOTP); + if (s < 0) + exit(1); + + addr.can_family = AF_CAN; + addr.can_ifindex = if_nametoindex("can0"); + addr.tp.tx_id = 0x18DA42F1 | CAN_EFF_FLAG; + addr.tp.rx_id = 0x18DAF142 | CAN_EFF_FLAG; + + ret = bind(s, (struct sockaddr *)&addr, sizeof(addr)); + if (ret < 0) + exit(1); + + /* Data can now be received using read(s, ...) and sent using write(s, ...) */ + +Additional examples +------------------- + +More complete (and complex) examples can be found inside the ``isotp*`` userland +tools, distributed as part of the ``can-utils`` utilities at: +https://github.com/linux-can/can-utils diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 69975ce25a02..fd514bba8c43 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -7,14 +7,6 @@ MPTCP Sysfs variables /proc/sys/net/mptcp/* Variables =============================== -enabled - BOOLEAN - Control whether MPTCP sockets can be created. - - MPTCP sockets can be created if the value is 1. This is a - per-namespace sysctl. - - Default: 1 (enabled) - add_addr_timeout - INTEGER (seconds) Set the timeout after which an ADD_ADDR control message will be resent to an MPTCP peer that has not acknowledged a previous @@ -25,16 +17,22 @@ add_addr_timeout - INTEGER (seconds) Default: 120 -close_timeout - INTEGER (seconds) - Set the make-after-break timeout: in absence of any close or - shutdown syscall, MPTCP sockets will maintain the status - unchanged for such time, after the last subflow removal, before - moving to TCP_CLOSE. +allow_join_initial_addr_port - BOOLEAN + Allow peers to send join requests to the IP address and port number used + by the initial subflow if the value is 1. This controls a flag that is + sent to the peer at connection time, and whether such join requests are + accepted or denied. - The default value matches TCP_TIMEWAIT_LEN. This is a per-namespace - sysctl. + Joins to addresses advertised with ADD_ADDR are not affected by this + value. - Default: 60 + This is a per-namespace sysctl. + + Default: 1 + +available_schedulers - STRING + Shows the available schedulers choices that are registered. More packet + schedulers may be available, but not loaded. checksum_enabled - BOOLEAN Control whether DSS checksum can be enabled. @@ -44,18 +42,24 @@ checksum_enabled - BOOLEAN Default: 0 -allow_join_initial_addr_port - BOOLEAN - Allow peers to send join requests to the IP address and port number used - by the initial subflow if the value is 1. This controls a flag that is - sent to the peer at connection time, and whether such join requests are - accepted or denied. +close_timeout - INTEGER (seconds) + Set the make-after-break timeout: in absence of any close or + shutdown syscall, MPTCP sockets will maintain the status + unchanged for such time, after the last subflow removal, before + moving to TCP_CLOSE. - Joins to addresses advertised with ADD_ADDR are not affected by this - value. + The default value matches TCP_TIMEWAIT_LEN. This is a per-namespace + sysctl. - This is a per-namespace sysctl. + Default: 60 - Default: 1 +enabled - BOOLEAN + Control whether MPTCP sockets can be created. + + MPTCP sockets can be created if the value is 1. This is a + per-namespace sysctl. + + Default: 1 (enabled) pm_type - INTEGER Set the default path manager type to use for each new MPTCP @@ -74,6 +78,14 @@ pm_type - INTEGER Default: 0 +scheduler - STRING + Select the scheduler of your choice. + + Support for selection of different schedulers. This is a per-namespace + sysctl. + + Default: "default" + stale_loss_cnt - INTEGER The number of MPTCP-level retransmission intervals with no traffic and pending outstanding data on a given subflow required to declare it stale. @@ -85,11 +97,3 @@ stale_loss_cnt - INTEGER This is a per-namespace sysctl. Default: 4 - -scheduler - STRING - Select the scheduler of your choice. - - Support for selection of different schedulers. This is a per-namespace - sysctl. - - Default: "default" diff --git a/Documentation/networking/mptcp.rst b/Documentation/networking/mptcp.rst new file mode 100644 index 000000000000..17f2bab61164 --- /dev/null +++ b/Documentation/networking/mptcp.rst @@ -0,0 +1,156 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Multipath TCP (MPTCP) +===================== + +Introduction +============ + +Multipath TCP or MPTCP is an extension to the standard TCP and is described in +`RFC 8684 (MPTCPv1) <https://www.rfc-editor.org/rfc/rfc8684.html>`_. It allows a +device to make use of multiple interfaces at once to send and receive TCP +packets over a single MPTCP connection. MPTCP can aggregate the bandwidth of +multiple interfaces or prefer the one with the lowest latency. It also allows a +fail-over if one path is down, and the traffic is seamlessly reinjected on other +paths. + +For more details about Multipath TCP in the Linux kernel, please see the +official website: `mptcp.dev <https://www.mptcp.dev>`_. + + +Use cases +========= + +Thanks to MPTCP, being able to use multiple paths in parallel or simultaneously +brings new use-cases, compared to TCP: + +- Seamless handovers: switching from one path to another while preserving + established connections, e.g. to be used in mobility use-cases, like on + smartphones. +- Best network selection: using the "best" available path depending on some + conditions, e.g. latency, losses, cost, bandwidth, etc. +- Network aggregation: using multiple paths at the same time to have a higher + throughput, e.g. to combine fixed and mobile networks to send files faster. + + +Concepts +======== + +Technically, when a new socket is created with the ``IPPROTO_MPTCP`` protocol +(Linux-specific), a *subflow* (or *path*) is created. This *subflow* consists of +a regular TCP connection that is used to transmit data through one interface. +Additional *subflows* can be negotiated later between the hosts. For the remote +host to be able to detect the use of MPTCP, a new field is added to the TCP +*option* field of the underlying TCP *subflow*. This field contains, amongst +other things, a ``MP_CAPABLE`` option that tells the other host to use MPTCP if +it is supported. If the remote host or any middlebox in between does not support +it, the returned ``SYN+ACK`` packet will not contain MPTCP options in the TCP +*option* field. In that case, the connection will be "downgraded" to plain TCP, +and it will continue with a single path. + +This behavior is made possible by two internal components: the path manager, and +the packet scheduler. + +Path Manager +------------ + +The Path Manager is in charge of *subflows*, from creation to deletion, and also +address announcements. Typically, it is the client side that initiates subflows, +and the server side that announces additional addresses via the ``ADD_ADDR`` and +``REMOVE_ADDR`` options. + +Path managers are controlled by the ``net.mptcp.pm_type`` sysctl knob -- see +mptcp-sysctl.rst. There are two types: the in-kernel one (type ``0``) where the +same rules are applied for all the connections (see: ``ip mptcp``) ; and the +userspace one (type ``1``), controlled by a userspace daemon (i.e. `mptcpd +<https://mptcpd.mptcp.dev/>`_) where different rules can be applied for each +connection. The path managers can be controlled via a Netlink API; see +netlink_spec/mptcp_pm.rst. + +To be able to use multiple IP addresses on a host to create multiple *subflows* +(paths), the default in-kernel MPTCP path-manager needs to know which IP +addresses can be used. This can be configured with ``ip mptcp endpoint`` for +example. + +Packet Scheduler +---------------- + +The Packet Scheduler is in charge of selecting which available *subflow(s)* to +use to send the next data packet. It can decide to maximize the use of the +available bandwidth, only to pick the path with the lower latency, or any other +policy depending on the configuration. + +Packet schedulers are controlled by the ``net.mptcp.scheduler`` sysctl knob -- +see mptcp-sysctl.rst. + + +Sockets API +=========== + +Creating MPTCP sockets +---------------------- + +On Linux, MPTCP can be used by selecting MPTCP instead of TCP when creating the +``socket``: + +.. code-block:: C + + int sd = socket(AF_INET(6), SOCK_STREAM, IPPROTO_MPTCP); + +Note that ``IPPROTO_MPTCP`` is defined as ``262``. + +If MPTCP is not supported, ``errno`` will be set to: + +- ``EINVAL``: (*Invalid argument*): MPTCP is not available, on kernels < 5.6. +- ``EPROTONOSUPPORT`` (*Protocol not supported*): MPTCP has not been compiled, + on kernels >= v5.6. +- ``ENOPROTOOPT`` (*Protocol not available*): MPTCP has been disabled using + ``net.mptcp.enabled`` sysctl knob; see mptcp-sysctl.rst. + +MPTCP is then opt-in: applications need to explicitly request it. Note that +applications can be forced to use MPTCP with different techniques, e.g. +``LD_PRELOAD`` (see ``mptcpize``), eBPF (see ``mptcpify``), SystemTAP, +``GODEBUG`` (``GODEBUG=multipathtcp=1``), etc. + +Switching to ``IPPROTO_MPTCP`` instead of ``IPPROTO_TCP`` should be as +transparent as possible for the userspace applications. + +Socket options +-------------- + +MPTCP supports most socket options handled by TCP. It is possible some less +common options are not supported, but contributions are welcome. + +Generally, the same value is propagated to all subflows, including the ones +created after the calls to ``setsockopt()``. eBPF can be used to set different +values per subflow. + +There are some MPTCP specific socket options at the ``SOL_MPTCP`` (284) level to +retrieve info. They fill the ``optval`` buffer of the ``getsockopt()`` system +call: + +- ``MPTCP_INFO``: Uses ``struct mptcp_info``. +- ``MPTCP_TCPINFO``: Uses ``struct mptcp_subflow_data``, followed by an array of + ``struct tcp_info``. +- ``MPTCP_SUBFLOW_ADDRS``: Uses ``struct mptcp_subflow_data``, followed by an + array of ``mptcp_subflow_addrs``. +- ``MPTCP_FULL_INFO``: Uses ``struct mptcp_full_info``, with one pointer to an + array of ``struct mptcp_subflow_info`` (including the + ``struct mptcp_subflow_addrs``), and one pointer to an array of + ``struct tcp_info``, followed by the content of ``struct mptcp_info``. + +Note that at the TCP level, ``TCP_IS_MPTCP`` socket option can be used to know +if MPTCP is currently being used: the value will be set to 1 if it is. + + +Design choices +============== + +A new socket type has been added for MPTCP for the userspace-facing socket. The +kernel is in charge of creating subflow sockets: they are TCP sockets where the +behavior is modified using TCP-ULP. + +MPTCP listen sockets will create "plain" *accepted* TCP sockets if the +connection request from the client didn't ask for MPTCP, making the performance +impact minimal when MPTCP is enabled by default. diff --git a/Documentation/networking/net_dim.rst b/Documentation/networking/net_dim.rst index 3bed9fd95336..8908fd7b0a8d 100644 --- a/Documentation/networking/net_dim.rst +++ b/Documentation/networking/net_dim.rst @@ -169,6 +169,48 @@ usage is not complete but it should make the outline of the usage clear. ... } + +Tuning DIM +========== + +Net DIM serves a range of network devices and delivers excellent acceleration +benefits. Yet, it has been observed that some preset configurations of DIM may +not align seamlessly with the varying specifications of network devices, and +this discrepancy has been identified as a factor to the suboptimal performance +outcomes of DIM-enabled network devices, related to a mismatch in profiles. + +To address this issue, Net DIM introduces a per-device control to modify and +access a device's ``rx-profile`` and ``tx-profile`` parameters: +Assume that the target network device is named ethx, and ethx only declares +support for RX profile setting and supports modification of ``usec`` field +and ``pkts`` field (See the data structure: +:c:type:`struct dim_cq_moder <dim_cq_moder>`). + +You can use ethtool to modify the current RX DIM profile where all +values are 64:: + + $ ethtool -C ethx rx-profile 1,1,n_2,2,n_3,n,n_n,4,n_n,n,n + +``n`` means do not modify this field, and ``_`` separates structure +elements of the profile array. + +Querying the current profiles using:: + + $ ethtool -c ethx + ... + rx-profile: + {.usec = 1, .pkts = 1, .comps = n/a,}, + {.usec = 2, .pkts = 2, .comps = n/a,}, + {.usec = 3, .pkts = 64, .comps = n/a,}, + {.usec = 64, .pkts = 4, .comps = n/a,}, + {.usec = 64, .pkts = 64, .comps = n/a,} + tx-profile: n/a + +If the network device does not support specific fields of DIM profiles, +the corresponding ``n/a`` will display. If the ``n/a`` field is being +modified, error messages will be reported. + + Dynamic Interrupt Moderation (DIM) library API ============================================== diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index 1283240d7620..f64641417c54 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -327,6 +327,12 @@ Some of the interface modes are described below: This is the Penta SGMII mode, it is similar to QSGMII but it combines 5 SGMII lines into a single link compared to 4 on QSGMII. +``PHY_INTERFACE_MODE_10G_QXGMII`` + Represents the 10G-QXGMII PHY-MAC interface as defined by the Cisco USXGMII + Multiport Copper Interface document. It supports 4 ports over a 10.3125 GHz + SerDes lane, each port having speeds of 2.5G / 1G / 100M / 10M achieved + through symbol replication. The PCS expects the standard USXGMII code word. + Pause frames / flow control =========================== diff --git a/Documentation/networking/sriov.rst b/Documentation/networking/sriov.rst new file mode 100644 index 000000000000..5deb4ff3154f --- /dev/null +++ b/Documentation/networking/sriov.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +NIC SR-IOV APIs +=============== + +Modern NICs are strongly encouraged to focus on implementing the ``switchdev`` +model (see :ref:`switchdev`) to configure forwarding and security of SR-IOV +functionality. + +Legacy API +========== + +The old SR-IOV API is implemented in ``rtnetlink`` Netlink family as part of +the ``RTM_GETLINK`` and ``RTM_SETLINK`` commands. On the driver side +it consists of a number of ``ndo_set_vf_*`` and ``ndo_get_vf_*`` callbacks. + +Since the legacy APIs do not integrate well with the rest of the stack +the API is considered frozen; no new functionality or extensions +will be accepted. New drivers should not implement the uncommon callbacks; +namely the following callbacks are off limits: + + - ``ndo_get_vf_port`` + - ``ndo_set_vf_port`` + - ``ndo_set_vf_rss_query_en`` diff --git a/Documentation/networking/tcp_ao.rst b/Documentation/networking/tcp_ao.rst index 8a58321acce7..e96e62d1dab3 100644 --- a/Documentation/networking/tcp_ao.rst +++ b/Documentation/networking/tcp_ao.rst @@ -337,6 +337,15 @@ TCP-AO per-socket counters are also duplicated with per-netns counters, exposed with SNMP. Those are ``TCPAOGood``, ``TCPAOBad``, ``TCPAOKeyNotFound``, ``TCPAORequired`` and ``TCPAODroppedIcmps``. +For monitoring purposes, there are following TCP-AO trace events: +``tcp_hash_bad_header``, ``tcp_hash_ao_required``, ``tcp_ao_handshake_failure``, +``tcp_ao_wrong_maclen``, ``tcp_ao_wrong_maclen``, ``tcp_ao_key_not_found``, +``tcp_ao_rnext_request``, ``tcp_ao_synack_no_key``, ``tcp_ao_snd_sne_update``, +``tcp_ao_rcv_sne_update``. It's possible to separately enable any of them and +one can filter them by net-namespace, 4-tuple, family, L3 index, and TCP header +flags. If a segment has a TCP-AO header, the filters may also include +keyid, rnext, and maclen. SNE updates include the rolled-over numbers. + RFC 5925 very permissively specifies how TCP port matching can be done for MKTs:: |