armbian/linux-cix
0
0
Fork 0
mirror of https://github.com/armbian/linux-cix.git synced 2026-01-06 12:30:45 -08:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source 
Pull networking changes from Paolo Abeni:
 "Core:

   - Refactor the forward memory allocation to better cope with memory
     pressure with many open sockets, moving from a per socket cache to
     a per-CPU one

   - Replace rwlocks with RCU for better fairness in ping, raw sockets
     and IP multicast router.

   - Network-side support for IO uring zero-copy send.

   - A few skb drop reason improvements, including codegen the source
     file with string mapping instead of using macro magic.

   - Rename reference tracking helpers to a more consistent netdev_*
     schema.

   - Adapt u64_stats_t type to address load/store tearing issues.

   - Refine debug helper usage to reduce the log noise caused by bots.

  BPF:

   - Improve socket map performance, avoiding skb cloning on read
     operation.

   - Add support for 64 bits enum, to match types exposed by kernel.

   - Introduce support for sleepable uprobes program.

   - Introduce support for enum textual representation in libbpf.

   - New helpers to implement synproxy with eBPF/XDP.

   - Improve loop performances, inlining indirect calls when possible.

   - Removed all the deprecated libbpf APIs.

   - Implement new eBPF-based LSM flavor.

   - Add type match support, which allow accurate queries to the eBPF
     used types.

   - A few TCP congetsion control framework usability improvements.

   - Add new infrastructure to manipulate CT entries via eBPF programs.

   - Allow for livepatch (KLP) and BPF trampolines to attach to the same
     kernel function.

  Protocols:

   - Introduce per network namespace lookup tables for unix sockets,
     increasing scalability and reducing contention.

   - Preparation work for Wi-Fi 7 Multi-Link Operation (MLO) support.

   - Add support to forciby close TIME_WAIT TCP sockets via user-space
     tools.

   - Significant performance improvement for the TLS 1.3 receive path,
     both for zero-copy and not-zero-copy.

   - Support for changing the initial MTPCP subflow priority/backup
     status

   - Introduce virtually contingus buffers for sockets over RDMA, to
     cope better with memory pressure.

   - Extend CAN ethtool support with timestamping capabilities

   - Refactor CAN build infrastructure to allow building only the needed
     features.

  Driver API:

   - Remove devlink mutex to allow parallel commands on multiple links.

   - Add support for pause stats in distributed switch.

   - Implement devlink helpers to query and flash line cards.

   - New helper for phy mode to register conversion.

  New hardware / drivers:

   - Ethernet DSA driver for the rockchip mt7531 on BPI-R2 Pro.

   - Ethernet DSA driver for the Renesas RZ/N1 A5PSW switch.

   - Ethernet DSA driver for the Microchip LAN937x switch.

   - Ethernet PHY driver for the Aquantia AQR113C EPHY.

   - CAN driver for the OBD-II ELM327 interface.

   - CAN driver for RZ/N1 SJA1000 CAN controller.

   - Bluetooth: Infineon CYW55572 Wi-Fi plus Bluetooth combo device.

  Drivers:

   - Intel Ethernet NICs:
      - i40e: add support for vlan pruning
      - i40e: add support for XDP framented packets
      - ice: improved vlan offload support
      - ice: add support for PPPoE offload

   - Mellanox Ethernet (mlx5)
      - refactor packet steering offload for performance and scalability
      - extend support for TC offload
      - refactor devlink code to clean-up the locking schema
      - support stacked vlans for bridge offloads
      - use TLS objects pool to improve connection rate

   - Netronome Ethernet NICs (nfp):
      - extend support for IPv6 fields mangling offload
      - add support for vepa mode in HW bridge
      - better support for virtio data path acceleration (VDPA)
      - enable TSO by default

   - Microsoft vNIC driver (mana)
      - add support for XDP redirect

   - Others Ethernet drivers:
      - bonding: add per-port priority support
      - microchip lan743x: extend phy support
      - Fungible funeth: support UDP segmentation offload and XDP xmit
      - Solarflare EF100: add support for virtual function representors
      - MediaTek SoC: add XDP support

   - Mellanox Ethernet/IB switch (mlxsw):
      - dropped support for unreleased H/W (XM router).
      - improved stats accuracy
      - unified bridge model coversion improving scalability (parts 1-6)
      - support for PTP in Spectrum-2 asics

   - Broadcom PHYs
      - add PTP support for BCM54210E
      - add support for the BCM53128 internal PHY

   - Marvell Ethernet switches (prestera):
      - implement support for multicast forwarding offload

   - Embedded Ethernet switches:
      - refactor OcteonTx MAC filter for better scalability
      - improve TC H/W offload for the Felix driver
      - refactor the Microchip ksz8 and ksz9477 drivers to share the
        probe code (parts 1, 2), add support for phylink mac
        configuration

   - Other WiFi:
      - Microchip wilc1000: diable WEP support and enable WPA3
      - Atheros ath10k: encapsulation offload support

  Old code removal:

   - Neterion vxge ethernet driver: this is untouched since more than 10 years"

* tag 'net-next-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1890 commits)
  doc: sfp-phylink: Fix a broken reference
  wireguard: selftests: support UML
  wireguard: allowedips: don't corrupt stack when detecting overflow
  wireguard: selftests: update config fragments
  wireguard: ratelimiter: use hrtimer in selftest
  net/mlx5e: xsk: Discard unaligned XSK frames on striding RQ
  net: usb: ax88179_178a: Bind only to vendor-specific interface
  selftests: net: fix IOAM test skip return code
  net: usb: make USB_RTL8153_ECM non user configurable
  net: marvell: prestera: remove reduntant code
  octeontx2-pf: Reduce minimum mtu size to 60
  net: devlink: Fix missing mutex_unlock() call
  net/tls: Remove redundant workqueue flush before destroy
  net: txgbe: Fix an error handling path in txgbe_probe()
  net: dsa: Fix spelling mistakes and cleanup code
  Documentation: devlink: add add devlink-selftests to the table of contents
  dccp: put dccp_qpolicy_full() and dccp_qpolicy_push() in the same lock
  net: ionic: fix error check for vlan flags in ionic_set_nic_features()
  net: ice: fix error NETIF_F_HW_VLAN_CTAG_FILTER check in ice_vsi_sync_fltr()
  nfp: flower: add support for tunnel offload without key ID
  ...
This commit is contained in:
Linus Torvalds
2022-08-03 16:29:08 -07:00
parent 526942b813 7c6327c77d
commit f86d1fbbe7
1753 changed files with 93378 additions and 64340 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
Documentation/ABI/testing/sysfs-devices-platform-soc-ipa
View File

@@ -46,33 +46,69 @@ Description:
that is supported by the hardware. The possible values
are "MAPv4" or "MAPv5".
What: .../XXXXXXX.ipa/endpoint_id/
Date: July 2022
KernelVersion: v5.19
Contact: Alex Elder <elder@kernel.org>
Description:
The .../XXXXXXX.ipa/endpoint_id/ directory contains
attributes that define IDs associated with IPA
endpoints. The "rx" or "tx" in an endpoint name is
from the perspective of the AP. An endpoint ID is a
small unsigned integer.
What: .../XXXXXXX.ipa/endpoint_id/modem_rx
Date: July 2022
KernelVersion: v5.19
Contact: Alex Elder <elder@kernel.org>
Description:
The .../XXXXXXX.ipa/endpoint_id/modem_rx file contains
the ID of the AP endpoint on which packets originating
from the embedded modem are received.
What: .../XXXXXXX.ipa/endpoint_id/modem_tx
Date: July 2022
KernelVersion: v5.19
Contact: Alex Elder <elder@kernel.org>
Description:
The .../XXXXXXX.ipa/endpoint_id/modem_tx file contains
the ID of the AP endpoint on which packets destined
for the embedded modem are sent.
What: .../XXXXXXX.ipa/endpoint_id/monitor_rx
Date: July 2022
KernelVersion: v5.19
Contact: Alex Elder <elder@kernel.org>
Description:
The .../XXXXXXX.ipa/endpoint_id/monitor_rx file contains
the ID of the AP endpoint on which IPA "monitor" data is
received. The monitor endpoint supplies replicas of
packets that enter the IPA hardware for processing.
Each replicated packet is preceded by a fixed-size "ODL"
header (see .../XXXXXXX.ipa/feature/monitor, above).
Large packets are truncated, to reduce the bandwidth
required to provide the monitor function.
What: .../XXXXXXX.ipa/modem/
Date: June 2021
KernelVersion: v5.14
Contact: Alex Elder <elder@kernel.org>
Description:
The .../XXXXXXX.ipa/modem/ directory contains a set of
attributes describing properties of the modem execution
environment reachable by the IPA hardware.
The .../XXXXXXX.ipa/modem/ directory contains attributes
describing properties of the modem embedded in the SoC.
What: .../XXXXXXX.ipa/modem/rx_endpoint_id
Date: June 2021
KernelVersion: v5.14
Contact: Alex Elder <elder@kernel.org>
Description:
The .../XXXXXXX.ipa/feature/rx_endpoint_id file contains
the AP endpoint ID that receives packets originating from
the modem execution environment. The "rx" is from the
perspective of the AP; this endpoint is considered an "IPA
producer". An endpoint ID is a small unsigned integer.
The .../XXXXXXX.ipa/modem/rx_endpoint_id file duplicates
the value found in .../XXXXXXX.ipa/endpoint_id/modem_rx.
What: .../XXXXXXX.ipa/modem/tx_endpoint_id
Date: June 2021
KernelVersion: v5.14
Contact: Alex Elder <elder@kernel.org>
Description:
The .../XXXXXXX.ipa/feature/tx_endpoint_id file contains
the AP endpoint ID used to transmit packets destined for
the modem execution environment. The "tx" is from the
perspective of the AP; this endpoint is considered an "IPA
consumer". An endpoint ID is a small unsigned integer.
The .../XXXXXXX.ipa/modem/tx_endpoint_id file duplicates
the value found in .../XXXXXXX.ipa/endpoint_id/modem_tx.

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

@@ -391,6 +391,18 @@ GRO has decided not to coalesce, it is placed on a per-NAPI list. This
list is then passed to the stack when the number of segments reaches the
gro_normal_batch limit.
high_order_alloc_disable
------------------------
By default the allocator for page frags tries to use high order pages (order-3
on x86). While the default behavior gives good results in most cases, some users
might have hit a contention in page allocations/freeing. This was especially
true on older kernels (< 5.14) when high-order pages were not stored on per-cpu
lists. This allows to opt-in for order-0 allocation instead but is now mostly of
historical importance.
Default: 0
2. /proc/sys/net/unix - Parameters for Unix domain sockets
----------------------------------------------------------

49
Documentation/bpf/btf.rst
View File

@@ -74,7 +74,7 @@ sequentially and type id is assigned to each recognized type starting from id
#define BTF_KIND_ARRAY 3 /* Array */
#define BTF_KIND_STRUCT 4 /* Struct */
#define BTF_KIND_UNION 5 /* Union */
#define BTF_KIND_ENUM 6 /* Enumeration */
#define BTF_KIND_ENUM 6 /* Enumeration up to 32-bit values */
#define BTF_KIND_FWD 7 /* Forward */
#define BTF_KIND_TYPEDEF 8 /* Typedef */
#define BTF_KIND_VOLATILE 9 /* Volatile */
@@ -87,6 +87,7 @@ sequentially and type id is assigned to each recognized type starting from id
#define BTF_KIND_FLOAT 16 /* Floating point */
#define BTF_KIND_DECL_TAG 17 /* Decl Tag */
#define BTF_KIND_TYPE_TAG 18 /* Type Tag */
#define BTF_KIND_ENUM64 19 /* Enumeration up to 64-bit values */
Note that the type section encodes debug info, not just pure types.
``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram.
@@ -101,10 +102,10 @@ Each type contains the following common data::
* bits 24-28: kind (e.g. int, ptr, array...etc)
* bits 29-30: unused
* bit 31: kind_flag, currently used by
* struct, union and fwd
* struct, union, fwd, enum and enum64.
*/
__u32 info;
/* "size" is used by INT, ENUM, STRUCT and UNION.
/* "size" is used by INT, ENUM, STRUCT, UNION and ENUM64.
* "size" tells the size of the type it is describing.
*
* "type" is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT,
@@ -281,10 +282,10 @@ modes exist:
``struct btf_type`` encoding requirement:
* ``name_off``: 0 or offset to a valid C identifier
* ``info.kind_flag``: 0
* ``info.kind_flag``: 0 for unsigned, 1 for signed
* ``info.kind``: BTF_KIND_ENUM
* ``info.vlen``: number of enum values
* ``size``: 4
* ``size``: 1/2/4/8
``btf_type`` is followed by ``info.vlen`` number of ``struct btf_enum``.::
@@ -297,6 +298,10 @@ The ``btf_enum`` encoding:
* ``name_off``: offset to a valid C identifier
* ``val``: any value
If the original enum value is signed and the size is less than 4,
that value will be sign extended into 4 bytes. If the size is 8,
the value will be truncated into 4 bytes.
2.2.7 BTF_KIND_FWD
~~~~~~~~~~~~~~~~~~
@@ -364,7 +369,8 @@ No additional type data follow ``btf_type``.
* ``name_off``: offset to a valid C identifier
* ``info.kind_flag``: 0
* ``info.kind``: BTF_KIND_FUNC
* ``info.vlen``: 0
* ``info.vlen``: linkage information (BTF_FUNC_STATIC, BTF_FUNC_GLOBAL
or BTF_FUNC_EXTERN)
* ``type``: a BTF_KIND_FUNC_PROTO type
No additional type data follow ``btf_type``.
@@ -375,6 +381,9 @@ type. The BTF_KIND_FUNC may in turn be referenced by a func_info in the
:ref:`BTF_Ext_Section` (ELF) or in the arguments to :ref:`BPF_Prog_Load`
(ABI).
Currently, only linkage values of BTF_FUNC_STATIC and BTF_FUNC_GLOBAL are
supported in the kernel.
2.2.13 BTF_KIND_FUNC_PROTO
~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -493,7 +502,7 @@ the attribute is applied to a ``struct``/``union`` member or
a ``func`` argument, and ``btf_decl_tag.component_idx`` should be a
valid index (starting from 0) pointing to a member or an argument.
2.2.17 BTF_KIND_TYPE_TAG
2.2.18 BTF_KIND_TYPE_TAG
~~~~~~~~~~~~~~~~~~~~~~~~
``struct btf_type`` encoding requirement:
@@ -516,6 +525,32 @@ type_tag, then zero or more const/volatile/restrict/typedef
and finally the base type. The base type is one of
int, ptr, array, struct, union, enum, func_proto and float types.
2.2.19 BTF_KIND_ENUM64
~~~~~~~~~~~~~~~~~~~~~~
``struct btf_type`` encoding requirement:
* ``name_off``: 0 or offset to a valid C identifier
* ``info.kind_flag``: 0 for unsigned, 1 for signed
* ``info.kind``: BTF_KIND_ENUM64
* ``info.vlen``: number of enum values
* ``size``: 1/2/4/8
``btf_type`` is followed by ``info.vlen`` number of ``struct btf_enum64``.::
struct btf_enum64 {
__u32 name_off;
__u32 val_lo32;
__u32 val_hi32;
};
The ``btf_enum64`` encoding:
* ``name_off``: offset to a valid C identifier
* ``val_lo32``: lower 32-bit value for a 64-bit value
* ``val_hi32``: high 32-bit value for a 64-bit value
If the original enum value is signed and the size is less than 8,
that value will be sign extended into 8 bytes.
3. BTF Kernel API
=================

1
Documentation/bpf/index.rst
View File

@@ -19,6 +19,7 @@ that goes into great technical depth about the BPF Architecture.
faq
syscall_api
helpers
kfuncs
programs
maps
bpf_prog_run

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

@@ -127,7 +127,7 @@ BPF_XOR | BPF_K | BPF_ALU64 means::
Byte swap instructions
----------------------
The byte swap instructions use an instruction class of ``BFP_ALU`` and a 4-bit
The byte swap instructions use an instruction class of ``BPF_ALU`` and a 4-bit
code field of ``BPF_END``.
The byte swap instructions operate on the destination register
@@ -351,7 +351,7 @@ These instructions have seven implicit operands:
* Register R0 is an implicit output which contains the data fetched from
the packet.
* Registers R1-R5 are scratch registers that are clobbered after a call to
``BPF_ABS | BPF_LD`` or ``BPF_IND`` | BPF_LD instructions.
``BPF_ABS | BPF_LD`` or ``BPF_IND | BPF_LD`` instructions.
These instructions have an implicit program exit condition as well. When an
eBPF program is trying to access the data beyond the packet boundary, the

170
Documentation/bpf/kfuncs.rst Normal file
View File

@@ -0,0 +1,170 @@
=============================
BPF Kernel Functions (kfuncs)
=============================
1. Introduction
===============
BPF Kernel Functions or more commonly known as kfuncs are functions in the Linux
kernel which are exposed for use by BPF programs. Unlike normal BPF helpers,
kfuncs do not have a stable interface and can change from one kernel release to
another. Hence, BPF programs need to be updated in response to changes in the
kernel.
2. Defining a kfunc
===================
There are two ways to expose a kernel function to BPF programs, either make an
existing function in the kernel visible, or add a new wrapper for BPF. In both
cases, care must be taken that BPF program can only call such function in a
valid context. To enforce this, visibility of a kfunc can be per program type.
If you are not creating a BPF wrapper for existing kernel function, skip ahead
to :ref:`BPF_kfunc_nodef`.
2.1 Creating a wrapper kfunc
----------------------------
When defining a wrapper kfunc, the wrapper function should have extern linkage.
This prevents the compiler from optimizing away dead code, as this wrapper kfunc
is not invoked anywhere in the kernel itself. It is not necessary to provide a
prototype in a header for the wrapper kfunc.
An example is given below::
/* Disables missing prototype warnings */
__diag_push();
__diag_ignore_all("-Wmissing-prototypes",
"Global kfuncs as their definitions will be in BTF");
struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
{
return find_get_task_by_vpid(nr);
}
__diag_pop();
A wrapper kfunc is often needed when we need to annotate parameters of the
kfunc. Otherwise one may directly make the kfunc visible to the BPF program by
registering it with the BPF subsystem. See :ref:`BPF_kfunc_nodef`.
2.2 Annotating kfunc parameters
-------------------------------
Similar to BPF helpers, there is sometime need for additional context required
by the verifier to make the usage of kernel functions safer and more useful.
Hence, we can annotate a parameter by suffixing the name of the argument of the
kfunc with a __tag, where tag may be one of the supported annotations.
2.2.1 __sz Annotation
---------------------
This annotation is used to indicate a memory and size pair in the argument list.
An example is given below::
void bpf_memzero(void *mem, int mem__sz)
{
...
}
Here, the verifier will treat first argument as a PTR_TO_MEM, and second
argument as its size. By default, without __sz annotation, the size of the type
of the pointer is used. Without __sz annotation, a kfunc cannot accept a void
pointer.
.. _BPF_kfunc_nodef:
2.3 Using an existing kernel function
-------------------------------------
When an existing function in the kernel is fit for consumption by BPF programs,
it can be directly registered with the BPF subsystem. However, care must still
be taken to review the context in which it will be invoked by the BPF program
and whether it is safe to do so.
2.4 Annotating kfuncs
---------------------
In addition to kfuncs' arguments, verifier may need more information about the
type of kfunc(s) being registered with the BPF subsystem. To do so, we define
flags on a set of kfuncs as follows::
BTF_SET8_START(bpf_task_set)
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
BTF_SET8_END(bpf_task_set)
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
along with it. Ofcourse, it is also allowed to specify no flags.
2.4.1 KF_ACQUIRE flag
---------------------
The KF_ACQUIRE flag is used to indicate that the kfunc returns a pointer to a
refcounted object. The verifier will then ensure that the pointer to the object
is eventually released using a release kfunc, or transferred to a map using a
referenced kptr (by invoking bpf_kptr_xchg). If not, the verifier fails the
loading of the BPF program until no lingering references remain in all possible
explored states of the program.
2.4.2 KF_RET_NULL flag
----------------------
The KF_RET_NULL flag is used to indicate that the pointer returned by the kfunc
may be NULL. Hence, it forces the user to do a NULL check on the pointer
returned from the kfunc before making use of it (dereferencing or passing to
another helper). This flag is often used in pairing with KF_ACQUIRE flag, but
both are orthogonal to each other.
2.4.3 KF_RELEASE flag
---------------------
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
passed in to it. There can be only one referenced pointer that can be passed in.
All copies of the pointer being released are invalidated as a result of invoking
kfunc with this flag.
2.4.4 KF_KPTR_GET flag
----------------------
The KF_KPTR_GET flag is used to indicate that the kfunc takes the first argument
as a pointer to kptr, safely increments the refcount of the object it points to,
and returns a reference to the user. The rest of the arguments may be normal
arguments of a kfunc. The KF_KPTR_GET flag should be used in conjunction with
KF_ACQUIRE and KF_RET_NULL flags.
2.4.5 KF_TRUSTED_ARGS flag
--------------------------
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
indicates that the all pointer arguments will always be refcounted, and have
their offset set to 0. It can be used to enforce that a pointer to a refcounted
object acquired from a kfunc or BPF helper is passed as an argument to this
kfunc without any modifications (e.g. pointer arithmetic) such that it is
trusted and points to the original object. This flag is often used for kfuncs
that operate (change some property, perform some operation) on an object that
was obtained using an acquire kfunc. Such kfuncs need an unchanged pointer to
ensure the integrity of the operation being performed on the expected object.
2.5 Registering the kfuncs
--------------------------
Once the kfunc is prepared for use, the final step to making it visible is
registering it with the BPF subsystem. Registration is done per BPF program
type. An example is shown below::
BTF_SET8_START(bpf_task_set)
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
BTF_SET8_END(bpf_task_set)
static const struct btf_kfunc_id_set bpf_task_kfunc_set = {
.owner = THIS_MODULE,
.set = &bpf_task_set,
};
static int init_subsystem(void)
{
return register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &bpf_task_kfunc_set);
}
late_initcall(init_subsystem);

13
Documentation/bpf/libbpf/libbpf_naming_convention.rst
View File

@@ -9,8 +9,8 @@ described here. It's recommended to follow these conventions whenever a
new function or type is added to keep libbpf API clean and consistent.
All types and functions provided by libbpf API should have one of the
following prefixes: ``bpf_``, ``btf_``, ``libbpf_``, ``xsk_``,
``btf_dump_``, ``ring_buffer_``, ``perf_buffer_``.
following prefixes: ``bpf_``, ``btf_``, ``libbpf_``, ``btf_dump_``,
``ring_buffer_``, ``perf_buffer_``.
System call wrappers
--------------------
@@ -59,15 +59,6 @@ Auxiliary functions and types that don't fit well in any of categories
described above should have ``libbpf_`` prefix, e.g.
``libbpf_get_error`` or ``libbpf_prog_type_by_name``.
AF_XDP functions
-------------------
AF_XDP functions should have an ``xsk_`` prefix, e.g.
``xsk_umem__get_data`` or ``xsk_umem__create``. The interface consists
of both low-level ring access functions and high-level configuration
functions. These can be mixed and matched. Note that these functions
are not reentrant for performance reasons.
ABI
---

185
Documentation/bpf/map_hash.rst Normal file
View File

@@ -0,0 +1,185 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright (C) 2022 Red Hat, Inc.
===============================================
BPF_MAP_TYPE_HASH, with PERCPU and LRU Variants
===============================================
.. note::
- ``BPF_MAP_TYPE_HASH`` was introduced in kernel version 3.19
- ``BPF_MAP_TYPE_PERCPU_HASH`` was introduced in version 4.6
- Both ``BPF_MAP_TYPE_LRU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
were introduced in version 4.10
``BPF_MAP_TYPE_HASH`` and ``BPF_MAP_TYPE_PERCPU_HASH`` provide general
purpose hash map storage. Both the key and the value can be structs,
allowing for composite keys and values.
The kernel is responsible for allocating and freeing key/value pairs, up
to the max_entries limit that you specify. Hash maps use pre-allocation
of hash table elements by default. The ``BPF_F_NO_PREALLOC`` flag can be
used to disable pre-allocation when it is too memory expensive.
``BPF_MAP_TYPE_PERCPU_HASH`` provides a separate value slot per
CPU. The per-cpu values are stored internally in an array.
The ``BPF_MAP_TYPE_LRU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
variants add LRU semantics to their respective hash tables. An LRU hash
will automatically evict the least recently used entries when the hash
table reaches capacity. An LRU hash maintains an internal LRU list that
is used to select elements for eviction. This internal LRU list is
shared across CPUs but it is possible to request a per CPU LRU list with
the ``BPF_F_NO_COMMON_LRU`` flag when calling ``bpf_map_create``.
Usage
=====
.. c:function::
long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
Hash entries can be added or updated using the ``bpf_map_update_elem()``
helper. This helper replaces existing elements atomically. The ``flags``
parameter can be used to control the update behaviour:
- ``BPF_ANY`` will create a new element or update an existing element
- ``BPF_NOEXIST`` will create a new element only if one did not already
exist
- ``BPF_EXIST`` will update an existing element
``bpf_map_update_elem()`` returns 0 on success, or negative error in
case of failure.
.. c:function::
void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
Hash entries can be retrieved using the ``bpf_map_lookup_elem()``
helper. This helper returns a pointer to the value associated with
``key``, or ``NULL`` if no entry was found.
.. c:function::
long bpf_map_delete_elem(struct bpf_map *map, const void *key)
Hash entries can be deleted using the ``bpf_map_delete_elem()``
helper. This helper will return 0 on success, or negative error in case
of failure.
Per CPU Hashes
--------------
For ``BPF_MAP_TYPE_PERCPU_HASH`` and ``BPF_MAP_TYPE_LRU_PERCPU_HASH``
the ``bpf_map_update_elem()`` and ``bpf_map_lookup_elem()`` helpers
automatically access the hash slot for the current CPU.
.. c:function::
void *bpf_map_lookup_percpu_elem(struct bpf_map *map, const void *key, u32 cpu)
The ``bpf_map_lookup_percpu_elem()`` helper can be used to lookup the
value in the hash slot for a specific CPU. Returns value associated with
``key`` on ``cpu`` , or ``NULL`` if no entry was found or ``cpu`` is
invalid.
Concurrency
-----------
Values stored in ``BPF_MAP_TYPE_HASH`` can be accessed concurrently by
programs running on different CPUs. Since Kernel version 5.1, the BPF
infrastructure provides ``struct bpf_spin_lock`` to synchronise access.
See ``tools/testing/selftests/bpf/progs/test_spin_lock.c``.
Userspace
---------
.. c:function::
int bpf_map_get_next_key(int fd, const void *cur_key, void *next_key)
In userspace, it is possible to iterate through the keys of a hash using
libbpf's ``bpf_map_get_next_key()`` function. The first key can be fetched by
calling ``bpf_map_get_next_key()`` with ``cur_key`` set to
``NULL``. Subsequent calls will fetch the next key that follows the
current key. ``bpf_map_get_next_key()`` returns 0 on success, -ENOENT if
cur_key is the last key in the hash, or negative error in case of
failure.
Note that if ``cur_key`` gets deleted then ``bpf_map_get_next_key()``
will instead return the *first* key in the hash table which is
undesirable. It is recommended to use batched lookup if there is going
to be key deletion intermixed with ``bpf_map_get_next_key()``.
Examples
========
Please see the ``tools/testing/selftests/bpf`` directory for functional
examples. The code snippets below demonstrates API usage.
This example shows how to declare an LRU Hash with a struct key and a
struct value.
.. code-block:: c
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
struct key {
__u32 srcip;
};
struct value {
__u64 packets;
__u64 bytes;
};
struct {
__uint(type, BPF_MAP_TYPE_LRU_HASH);
__uint(max_entries, 32);
__type(key, struct key);
__type(value, struct value);
} packet_stats SEC(".maps");
This example shows how to create or update hash values using atomic
instructions:
.. code-block:: c
static void update_stats(__u32 srcip, int bytes)
{
struct key key = {
.srcip = srcip,
};
struct value *value = bpf_map_lookup_elem(&packet_stats, &key);
if (value) {
__sync_fetch_and_add(&value->packets, 1);
__sync_fetch_and_add(&value->bytes, bytes);
} else {
struct value newval = { 1, bytes };
bpf_map_update_elem(&packet_stats, &key, &newval, BPF_NOEXIST);
}
}
Userspace walking the map elements from the map declared above:
.. code-block:: c
#include <bpf/libbpf.h>
#include <bpf/bpf.h>
static void walk_hash_elements(int map_fd)
{
struct key *cur_key = NULL;
struct key next_key;
struct value value;
int err;
for (;;) {
err = bpf_map_get_next_key(map_fd, cur_key, &next_key);
if (err)
break;
bpf_map_lookup_elem(map_fd, &next_key, &value);
// Use key and value here
cur_key = &next_key;
}
}

25
Documentation/devicetree/bindings/net/broadcom-bluetooth.yaml
View File

@@ -23,6 +23,8 @@ properties:
- brcm,bcm4345c5
- brcm,bcm43540-bt
- brcm,bcm4335a0
- brcm,bcm4349-bt
- infineon,cyw55572-bt
shutdown-gpios:
maxItems: 1
@@ -92,6 +94,13 @@ properties:
pcm-sync-mode: slave, master
pcm-clock-mode: slave, master
brcm,requires-autobaud-mode:
type: boolean
description:
Set this property if autobaud mode is required. Autobaud mode is required
if the device's initial baud rate in normal mode is not supported by the
host or if the device requires autobaud mode startup before loading FW.
interrupts:
items:
- description: Handle to the line HOST_WAKE used to wake
@@ -108,6 +117,22 @@ properties:
required:
- compatible
dependencies:
brcm,requires-autobaud-mode: [ 'shutdown-gpios' ]
if:
not:
properties:
compatible:
contains:
enum:
- brcm,bcm20702a1
- brcm,bcm4329-bt
- brcm,bcm4330-bt
then:
properties:
reset-gpios: false
additionalProperties: false
examples:

45
Documentation/devicetree/bindings/net/can/microchip,mpfs-can.yaml Normal file
View File

@@ -0,0 +1,45 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/can/microchip,mpfs-can.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title:
Microchip PolarFire SoC (MPFS) can controller
maintainers:
- Conor Dooley <conor.dooley@microchip.com>
allOf:
- $ref: can-controller.yaml#
properties:
compatible:
const: microchip,mpfs-can
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
additionalProperties: false
examples:
- |
can@2010c000 {
compatible = "microchip,mpfs-can";
reg = <0x2010c000 0x1000>;
clocks = <&clkcfg 17>;
interrupt-parent = <&plic>;
interrupts = <56>;
};

132
Documentation/devicetree/bindings/net/can/nxp,sja1000.yaml Normal file
View File

@@ -0,0 +1,132 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/can/nxp,sja1000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Memory mapped SJA1000 CAN controller from NXP (formerly Philips)
maintainers:
- Wolfgang Grandegger <wg@grandegger.com>
properties:
compatible:
oneOf:
- enum:
- nxp,sja1000
- technologic,sja1000
- items:
- enum:
- renesas,r9a06g032-sja1000 # RZ/N1D
- renesas,r9a06g033-sja1000 # RZ/N1S
- const: renesas,rzn1-sja1000 # RZ/N1
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
reg-io-width:
$ref: /schemas/types.yaml#/definitions/uint32
description: I/O register width (in bytes) implemented by this device
default: 1
enum: [ 1, 2, 4 ]
nxp,external-clock-frequency:
$ref: /schemas/types.yaml#/definitions/uint32
default: 16000000
description: |
Frequency of the external oscillator clock in Hz.
The internal clock frequency used by the SJA1000 is half of that value.
nxp,tx-output-mode:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 0, 1, 2, 3 ]
default: 1
description: |
operation mode of the TX output control logic. Valid values are:
<0> : bi-phase output mode
<1> : normal output mode (default)
<2> : test output mode
<3> : clock output mode
nxp,tx-output-config:
$ref: /schemas/types.yaml#/definitions/uint32
default: 0x02
description: |
TX output pin configuration. Valid values are any one of the below
or combination of TX0 and TX1:
<0x01> : TX0 invert
<0x02> : TX0 pull-down (default)
<0x04> : TX0 pull-up
<0x06> : TX0 push-pull
<0x08> : TX1 invert
<0x10> : TX1 pull-down
<0x20> : TX1 pull-up
<0x30> : TX1 push-pull
nxp,clock-out-frequency:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
clock frequency in Hz on the CLKOUT pin.
If not specified or if the specified value is 0, the CLKOUT pin
will be disabled.
nxp,no-comparator-bypass:
type: boolean
description: Allows to disable the CAN input comparator.
required:
- compatible
- reg
- interrupts
allOf:
- $ref: can-controller.yaml#
- if:
properties:
compatible:
contains:
enum:
- technologic,sja1000
- renesas,rzn1-sja1000
then:
required:
- reg-io-width
- if:
properties:
compatible:
contains:
const: renesas,rzn1-sja1000
then:
required:
- clocks
unevaluatedProperties: false
examples:
- |
can@1a000 {
compatible = "technologic,sja1000";
reg = <0x1a000 0x100>;
interrupts = <1>;
reg-io-width = <2>;
nxp,tx-output-config = <0x06>;
nxp,external-clock-frequency = <24000000>;
};
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/r9a06g032-sysctrl.h>
can@52104000 {
compatible = "renesas,r9a06g032-sja1000", "renesas,rzn1-sja1000";
reg = <0x52104000 0x800>;
reg-io-width = <4>;
interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&sysctrl R9A06G032_HCLK_CAN0>;
};

58
Documentation/devicetree/bindings/net/can/sja1000.txt
View File

@@ -1,58 +0,0 @@
Memory mapped SJA1000 CAN controller from NXP (formerly Philips)
Required properties:
- compatible : should be one of "nxp,sja1000", "technologic,sja1000".
- reg : should specify the chip select, address offset and size required
to map the registers of the SJA1000. The size is usually 0x80.
- interrupts: property with a value describing the interrupt source
(number and sensitivity) required for the SJA1000.
Optional properties:
- reg-io-width : Specify the size (in bytes) of the IO accesses that
should be performed on the device. Valid value is 1, 2 or 4.
This property is ignored for technologic version.
Default to 1 (8 bits).
- nxp,external-clock-frequency : Frequency of the external oscillator
clock in Hz. Note that the internal clock frequency used by the
SJA1000 is half of that value. If not specified, a default value
of 16000000 (16 MHz) is used.
- nxp,tx-output-mode : operation mode of the TX output control logic:
<0x0> : bi-phase output mode
<0x1> : normal output mode (default)
<0x2> : test output mode
<0x3> : clock output mode
- nxp,tx-output-config : TX output pin configuration:
<0x01> : TX0 invert
<0x02> : TX0 pull-down (default)
<0x04> : TX0 pull-up
<0x06> : TX0 push-pull
<0x08> : TX1 invert
<0x10> : TX1 pull-down
<0x20> : TX1 pull-up
<0x30> : TX1 push-pull
- nxp,clock-out-frequency : clock frequency in Hz on the CLKOUT pin.
If not specified or if the specified value is 0, the CLKOUT pin
will be disabled.
- nxp,no-comparator-bypass : Allows to disable the CAN input comparator.
For further information, please have a look to the SJA1000 data sheet.
Examples:
can@3,100 {
compatible = "nxp,sja1000";
reg = <3 0x100 0x80>;
interrupts = <2 0>;
interrupt-parent = <&mpic>;
nxp,external-clock-frequency = <16000000>;
};

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

@@ -23,11 +23,20 @@ properties:
- cdns,zynq-gem # Xilinx Zynq-7xxx SoC
- cdns,zynqmp-gem # Xilinx Zynq Ultrascale+ MPSoC
- const: cdns,gem # Generic
deprecated: true
- items:
- enum:
- xlnx,versal-gem # Xilinx Versal
- xlnx,zynq-gem # Xilinx Zynq-7xxx SoC
- xlnx,zynqmp-gem # Xilinx Zynq Ultrascale+ MPSoC
- const: cdns,gem # Generic
- items:
- enum:
- cdns,at91sam9260-macb # Atmel at91sam9 SoCs
- cdns,sam9x60-macb # Microchip sam9x60 SoC
- microchip,mpfs-macb # Microchip PolarFire SoC
- const: cdns,macb # Generic
- items:
@@ -181,7 +190,7 @@ examples:
#address-cells = <2>;
#size-cells = <2>;
gem1: ethernet@ff0c0000 {
compatible = "cdns,zynqmp-gem", "cdns,gem";
compatible = "xlnx,zynqmp-gem", "cdns,gem";
interrupt-parent = <&gic>;
interrupts = <0 59 4>, <0 59 4>;
reg = <0x0 0xff0c0000 0x0 0x1000>;

2
Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml
View File

@@ -48,7 +48,7 @@ properties:
"^led@[01]$":
type: object
description: Hellcreek leds
$ref: ../../leds/common.yaml#
$ref: /schemas/leds/common.yaml#
properties:
reg:

407
Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml Normal file
View File

@@ -0,0 +1,407 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7530.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Mediatek MT7530 Ethernet switch
maintainers:
- Sean Wang <sean.wang@mediatek.com>
- Landen Chao <Landen.Chao@mediatek.com>
- DENG Qingfang <dqfext@gmail.com>
description: |
Port 5 of mt7530 and mt7621 switch is muxed between:
1. GMAC5: GMAC5 can interface with another external MAC or PHY.
2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC
of the SOC. Used in many setups where port 0/4 becomes the WAN port.
Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to
GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not
connected to external component!
Port 5 modes/configurations:
1. Port 5 is disabled and isolated: An external phy can interface to the 2nd
GMAC of the SOC.
In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd
GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC!
2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC.
It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode
and RGMII delay.
3. Port 5 is muxed to GMAC5 and can interface to an external phy.
Port 5 becomes an extra switch port.
Only works on platform where external phy TX<->RX lines are swapped.
Like in the Ubiquiti ER-X-SFP.
4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port.
Currently a 2nd CPU port is not supported by DSA code.
Depending on how the external PHY is wired:
1. normal: The PHY can only connect to 2nd GMAC but not to the switch
2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as
a ethernet port. But can't interface to the 2nd GMAC.
Based on the DT the port 5 mode is configured.
Driver tries to lookup the phy-handle of the 2nd GMAC of the master device.
When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2.
phy-mode must be set, see also example 2 below!
* mt7621: phy-mode = "rgmii-txid";
* mt7623: phy-mode = "rgmii";
CPU-Ports need a phy-mode property:
Allowed values on mt7530 and mt7621:
- "rgmii"
- "trgmii"
On mt7531:
- "1000base-x"
- "2500base-x"
- "rgmii"
- "sgmii"
properties:
compatible:
enum:
- mediatek,mt7530
- mediatek,mt7531
- mediatek,mt7621
reg:
maxItems: 1
core-supply:
description:
Phandle to the regulator node necessary for the core power.
"#gpio-cells":
const: 2
gpio-controller:
type: boolean
description:
if defined, MT7530's LED controller will run on GPIO mode.
"#interrupt-cells":
const: 1
interrupt-controller: true
interrupts:
maxItems: 1
io-supply:
description:
Phandle to the regulator node necessary for the I/O power.
See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
for details for the regulator setup on these boards.
mediatek,mcm:
type: boolean
description:
if defined, indicates that either MT7530 is the part on multi-chip
module belong to MT7623A has or the remotely standalone chip as the
function MT7623N reference board provided for.
reset-gpios:
maxItems: 1
reset-names:
const: mcm
resets:
description:
Phandle pointing to the system reset controller with line index for
the ethsys.
maxItems: 1
patternProperties:
"^(ethernet-)?ports$":
type: object
patternProperties:
"^(ethernet-)?port@[0-9]+$":
type: object
description: Ethernet switch ports
unevaluatedProperties: false
properties:
reg:
description:
Port address described must be 5 or 6 for CPU port and from 0
to 5 for user ports.
allOf:
- $ref: dsa-port.yaml#
- if:
properties:
label:
items:
- const: cpu
then:
required:
- reg
- phy-mode
required:
- compatible
- reg
allOf:
- $ref: "dsa.yaml#"
- if:
required:
- mediatek,mcm
then:
required:
- resets
- reset-names
- dependencies:
interrupt-controller: [ interrupts ]
- if:
properties:
compatible:
items:
- const: mediatek,mt7530
then:
required:
- core-supply
- io-supply
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
mdio {
#address-cells = <1>;
#size-cells = <0>;
switch@0 {
compatible = "mediatek,mt7530";
reg = <0>;
core-supply = <&mt6323_vpa_reg>;
io-supply = <&mt6323_vemc3v3_reg>;
reset-gpios = <&pio 33 GPIO_ACTIVE_HIGH>;
ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan3";
};
port@4 {
reg = <4>;
label = "wan";
};
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "trgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
- |
//Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
ethernet {
#address-cells = <1>;
#size-cells = <0>;
gmac0: mac@0 {
compatible = "mediatek,eth-mac";
reg = <0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
gmac1: mac@1 {
compatible = "mediatek,eth-mac";
reg = <1>;
phy-mode = "rgmii-txid";
phy-handle = <&phy4>;
};
mdio: mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
/* Internal phy */
phy4: ethernet-phy@4 {
reg = <4>;
};
mt7530: switch@1f {
compatible = "mediatek,mt7621";
reg = <0x1f>;
mediatek,mcm;
resets = <&rstctrl 2>;
reset-names = "mcm";
ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan3";
};
/* Commented out. Port 4 is handled by 2nd GMAC.
port@4 {
reg = <4>;
label = "lan4";
};
*/
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
};
};
};
- |
//Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY.
ethernet {
#address-cells = <1>;
#size-cells = <0>;
gmac_0: mac@0 {
compatible = "mediatek,eth-mac";
reg = <0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
mdio0: mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
/* External phy */
ephy5: ethernet-phy@7 {
reg = <7>;
};
switch@1f {
compatible = "mediatek,mt7621";
reg = <0x1f>;
mediatek,mcm;
resets = <&rstctrl 2>;
reset-names = "mcm";
ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan3";
};
port@4 {
reg = <4>;
label = "lan4";
};
port@5 {
reg = <5>;
label = "lan5";
phy-mode = "rgmii";
phy-handle = <&ephy5>;
};
cpu_port0: port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac_0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
};
};
};

192
Documentation/devicetree/bindings/net/dsa/microchip,lan937x.yaml Normal file
View File

@@ -0,0 +1,192 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/microchip,lan937x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: LAN937x Ethernet Switch Series Tree Bindings
maintainers:
- UNGLinuxDriver@microchip.com
allOf:
- $ref: dsa.yaml#
properties:
compatible:
enum:
- microchip,lan9370
- microchip,lan9371
- microchip,lan9372
- microchip,lan9373
- microchip,lan9374
reg:
maxItems: 1
spi-max-frequency:
maximum: 50000000
reset-gpios:
description: Optional gpio specifier for a reset line
maxItems: 1
mdio:
$ref: /schemas/net/mdio.yaml#
unevaluatedProperties: false
patternProperties:
"^(ethernet-)?ports$":
patternProperties:
"^(ethernet-)?port@[0-9]+$":
allOf:
- if:
properties:
phy-mode:
contains:
enum:
- rgmii
- rgmii-id
- rgmii-txid
- rgmii-rxid
then:
properties:
rx-internal-delay-ps:
enum: [0, 2000]
default: 0
tx-internal-delay-ps:
enum: [0, 2000]
default: 0
required:
- compatible
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
macb0 {
#address-cells = <1>;
#size-cells = <0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
spi {
#address-cells = <1>;
#size-cells = <0>;
lan9374: switch@0 {
compatible = "microchip,lan9374";
reg = <0>;
spi-max-frequency = <44000000>;
ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
phy-mode = "internal";
phy-handle = <&t1phy0>;
};
port@1 {
reg = <1>;
label = "lan2";
phy-mode = "internal";
phy-handle = <&t1phy1>;
};
port@2 {
reg = <2>;
label = "lan4";
phy-mode = "internal";
phy-handle = <&t1phy2>;
};
port@3 {
reg = <3>;
label = "lan6";
phy-mode = "internal";
phy-handle = <&t1phy3>;
};
port@4 {
reg = <4>;
phy-mode = "rgmii";
tx-internal-delay-ps = <2000>;
rx-internal-delay-ps = <2000>;
ethernet = <&macb0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@5 {
reg = <5>;
label = "lan7";
phy-mode = "rgmii";
tx-internal-delay-ps = <2000>;
rx-internal-delay-ps = <2000>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@6 {
reg = <6>;
label = "lan5";
phy-mode = "internal";
phy-handle = <&t1phy6>;
};
port@7 {
reg = <7>;
label = "lan3";
phy-mode = "internal";
phy-handle = <&t1phy7>;
};
};
mdio {
#address-cells = <1>;
#size-cells = <0>;
t1phy0: ethernet-phy@0{
reg = <0x0>;
};
t1phy1: ethernet-phy@1{
reg = <0x1>;
};
t1phy2: ethernet-phy@2{
reg = <0x2>;
};
t1phy3: ethernet-phy@3{
reg = <0x3>;
};
t1phy6: ethernet-phy@6{
reg = <0x6>;
};
t1phy7: ethernet-phy@7{
reg = <0x7>;
};
};
};
};

327
Documentation/devicetree/bindings/net/dsa/mt7530.txt
View File

@@ -1,327 +0,0 @@
Mediatek MT7530 Ethernet switch
================================
Required properties:
- compatible: may be compatible = "mediatek,mt7530"
or compatible = "mediatek,mt7621"
or compatible = "mediatek,mt7531"
- #address-cells: Must be 1.
- #size-cells: Must be 0.
- mediatek,mcm: Boolean; if defined, indicates that either MT7530 is the part
on multi-chip module belong to MT7623A has or the remotely standalone
chip as the function MT7623N reference board provided for.
If compatible mediatek,mt7530 is set then the following properties are required
- core-supply: Phandle to the regulator node necessary for the core power.
- io-supply: Phandle to the regulator node necessary for the I/O power.
See Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
for details for the regulator setup on these boards.
If the property mediatek,mcm isn't defined, following property is required
- reset-gpios: Should be a gpio specifier for a reset line.
Else, following properties are required
- resets : Phandle pointing to the system reset controller with
line index for the ethsys.
- reset-names : Should be set to "mcm".
Required properties for the child nodes within ports container:
- reg: Port address described must be 6 for CPU port and from 0 to 5 for
user ports.
- phy-mode: String, the following values are acceptable for port labeled
"cpu":
If compatible mediatek,mt7530 or mediatek,mt7621 is set,
must be either "trgmii" or "rgmii"
If compatible mediatek,mt7531 is set,
must be either "sgmii", "1000base-x" or "2500base-x"
Port 5 of mt7530 and mt7621 switch is muxed between:
1. GMAC5: GMAC5 can interface with another external MAC or PHY.
2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC
of the SOC. Used in many setups where port 0/4 becomes the WAN port.
Note: On a MT7621 SOC with integrated switch: 2nd GMAC can only connected to
GMAC5 when the gpios for RGMII2 (GPIO 22-33) are not used and not
connected to external component!
Port 5 modes/configurations:
1. Port 5 is disabled and isolated: An external phy can interface to the 2nd
GMAC of the SOC.
In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd
GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC!
2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC.
It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode
and RGMII delay.
3. Port 5 is muxed to GMAC5 and can interface to an external phy.
Port 5 becomes an extra switch port.
Only works on platform where external phy TX<->RX lines are swapped.
Like in the Ubiquiti ER-X-SFP.
4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port.
Currently a 2nd CPU port is not supported by DSA code.
Depending on how the external PHY is wired:
1. normal: The PHY can only connect to 2nd GMAC but not to the switch
2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as
a ethernet port. But can't interface to the 2nd GMAC.
Based on the DT the port 5 mode is configured.
Driver tries to lookup the phy-handle of the 2nd GMAC of the master device.
When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2.
phy-mode must be set, see also example 2 below!
* mt7621: phy-mode = "rgmii-txid";
* mt7623: phy-mode = "rgmii";
Optional properties:
- gpio-controller: Boolean; if defined, MT7530's LED controller will run on
GPIO mode.
- #gpio-cells: Must be 2 if gpio-controller is defined.
- interrupt-controller: Boolean; Enables the internal interrupt controller.
If interrupt-controller is defined, the following properties are required.
- #interrupt-cells: Must be 1.
- interrupts: Parent interrupt for the interrupt controller.
See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
required, optional properties and how the integrated switch subnodes must
be specified.
Example:
&mdio0 {
switch@0 {
compatible = "mediatek,mt7530";
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
core-supply = <&mt6323_vpa_reg>;
io-supply = <&mt6323_vemc3v3_reg>;
reset-gpios = <&pio 33 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
port@0 {
reg = <0>;
label = "lan0";
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan3";
};
port@4 {
reg = <4>;
label = "wan";
};
port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "trgmii";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
&eth {
gmac0: mac@0 {
compatible = "mediatek,eth-mac";
reg = <0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
gmac1: mac@1 {
compatible = "mediatek,eth-mac";
reg = <1>;
phy-mode = "rgmii-txid";
phy-handle = <&phy4>;
};
mdio: mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
/* Internal phy */
phy4: ethernet-phy@4 {
reg = <4>;
};
mt7530: switch@1f {
compatible = "mediatek,mt7621";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x1f>;
pinctrl-names = "default";
mediatek,mcm;
resets = <&rstctrl 2>;
reset-names = "mcm";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan3";
};
/* Commented out. Port 4 is handled by 2nd GMAC.
port@4 {
reg = <4>;
label = "lan4";
};
*/
cpu_port0: port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
};
};
};
Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY.
&eth {
gmac0: mac@0 {
compatible = "mediatek,eth-mac";
reg = <0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
mdio: mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
/* External phy */
ephy5: ethernet-phy@7 {
reg = <7>;
};
mt7530: switch@1f {
compatible = "mediatek,mt7621";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x1f>;
pinctrl-names = "default";
mediatek,mcm;
resets = <&rstctrl 2>;
reset-names = "mcm";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan3";
};
port@4 {
reg = <4>;
label = "lan4";
};
port@5 {
reg = <5>;
label = "lan5";
phy-mode = "rgmii";
phy-handle = <&ephy5>;
};
cpu_port0: port@6 {
reg = <6>;
label = "cpu";
ethernet = <&gmac0>;
phy-mode = "rgmii";
fixed-link {
speed = <1000>;
full-duplex;
pause;
};
};
};
};
};
};

157
Documentation/devicetree/bindings/net/dsa/renesas,rzn1-a5psw.yaml Normal file
View File

@@ -0,0 +1,157 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/renesas,rzn1-a5psw.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1 Advanced 5 ports ethernet switch
maintainers:
- Clément Léger <clement.leger@bootlin.com>
description: |
The advanced 5 ports switch is present on the Renesas RZ/N1 SoC family and
handles 4 ports + 1 CPU management port.
allOf:
- $ref: dsa.yaml#
properties:
compatible:
items:
- enum:
- renesas,r9a06g032-a5psw
- const: renesas,rzn1-a5psw
reg:
maxItems: 1
interrupts:
items:
- description: Device Level Ring (DLR) interrupt
- description: Switch interrupt
- description: Parallel Redundancy Protocol (PRP) interrupt
- description: Integrated HUB module interrupt
- description: Receive Pattern Match interrupt
interrupt-names:
items:
- const: dlr
- const: switch
- const: prp
- const: hub
- const: ptrn
power-domains:
maxItems: 1
mdio:
$ref: /schemas/net/mdio.yaml#
unevaluatedProperties: false
clocks:
items:
- description: AHB clock used for the switch register interface
- description: Switch system clock
clock-names:
items:
- const: hclk
- const: clk
ethernet-ports:
type: object
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^(ethernet-)?port@[0-4]$":
type: object
description: Ethernet switch ports
properties:
pcs-handle:
description:
phandle pointing to a PCS sub-node compatible with
renesas,rzn1-miic.yaml#
$ref: /schemas/types.yaml#/definitions/phandle
unevaluatedProperties: false
required:
- compatible
- reg
- clocks
- clock-names
- power-domains
examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/clock/r9a06g032-sysctrl.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
switch@44050000 {
compatible = "renesas,r9a06g032-a5psw", "renesas,rzn1-a5psw";
reg = <0x44050000 0x10000>;
clocks = <&sysctrl R9A06G032_HCLK_SWITCH>, <&sysctrl R9A06G032_CLK_SWITCH>;
clock-names = "hclk", "clk";
power-domains = <&sysctrl>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "dlr", "switch", "prp", "hub", "ptrn";
dsa,member = <0 0>;
ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
phy-handle = <&switch0phy3>;
pcs-handle = <&mii_conv4>;
};
port@1 {
reg = <1>;
label = "lan1";
phy-handle = <&switch0phy1>;
pcs-handle = <&mii_conv3>;
};
port@4 {
reg = <4>;
ethernet = <&gmac2>;
label = "cpu";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
mdio {
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio0a 2 GPIO_ACTIVE_HIGH>;
reset-delay-us = <15>;
clock-frequency = <2500000>;
switch0phy1: ethernet-phy@1{
reg = <1>;
};
switch0phy3: ethernet-phy@3{
reg = <3>;
};
};
};

35
Documentation/devicetree/bindings/net/ethernet-controller.yaml
View File

@@ -133,12 +133,6 @@ properties:
and is useful for determining certain configuration settings
such as flow control thresholds.
rx-internal-delay-ps:
description: |
RGMII Receive Clock Delay defined in pico seconds.
This is used for controllers that have configurable RX internal delays.
If this property is present then the MAC applies the RX delay.
sfp:
$ref: /schemas/types.yaml#/definitions/phandle
description:
@@ -150,12 +144,6 @@ properties:
The size of the controller\'s transmit fifo in bytes. This
is used for components that can have configurable fifo sizes.
tx-internal-delay-ps:
description: |
RGMII Transmit Clock Delay defined in pico seconds.
This is used for controllers that have configurable TX internal delays.
If this property is present then the MAC applies the TX delay.
managed:
description:
Specifies the PHY management type. If auto is set and fixed-link
@@ -227,6 +215,29 @@ properties:
required:
- speed
allOf:
- if:
properties:
phy-mode:
contains:
enum:
- rgmii
- rgmii-rxid
- rgmii-txid
- rgmii-id
then:
properties:
rx-internal-delay-ps:
description:
RGMII Receive Clock Delay defined in pico seconds.This is used for
controllers that have configurable RX internal delays. If this
property is present then the MAC applies the RX delay.
tx-internal-delay-ps:
description:
RGMII Transmit Clock Delay defined in pico seconds.This is used for
controllers that have configurable TX internal delays. If this
property is present then the MAC applies the TX delay.
additionalProperties: true
...

11
Documentation/devicetree/bindings/net/fsl,fec.yaml
View File

@@ -58,6 +58,11 @@ properties:
- fsl,imx8qxp-fec
- const: fsl,imx8qm-fec
- const: fsl,imx6sx-fec
- items:
- enum:
- fsl,imx8ulp-fec
- const: fsl,imx6ul-fec
- const: fsl,imx6q-fec
reg:
maxItems: 1
@@ -121,6 +126,10 @@ properties:
mac-address: true
nvmem-cells: true
nvmem-cell-names: true
tx-internal-delay-ps:
enum: [0, 2000]
@@ -216,7 +225,7 @@ required:
# least undocumented properties. However, PHY may have a deprecated option to
# place PHY OF properties in the MAC node, such as Micrel PHY, and we can find
# these boards which is based on i.MX6QDL.
additionalProperties: false
unevaluatedProperties: false
examples:
- |

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