Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next

Pull networking updates from David Miller:

 1) Support 6Ghz band in ath11k driver, from Rajkumar Manoharan.

 2) Support UDP segmentation in code TSO code, from Eric Dumazet.

 3) Allow flashing different flash images in cxgb4 driver, from Vishal
    Kulkarni.

 4) Add drop frames counter and flow status to tc flower offloading,
    from Po Liu.

 5) Support n-tuple filters in cxgb4, from Vishal Kulkarni.

 6) Various new indirect call avoidance, from Eric Dumazet and Brian
    Vazquez.

 7) Fix BPF verifier failures on 32-bit pointer arithmetic, from
    Yonghong Song.

 8) Support querying and setting hardware address of a port function via
    devlink, use this in mlx5, from Parav Pandit.

 9) Support hw ipsec offload on bonding slaves, from Jarod Wilson.

10) Switch qca8k driver over to phylink, from Jonathan McDowell.

11) In bpftool, show list of processes holding BPF FD references to
    maps, programs, links, and btf objects. From Andrii Nakryiko.

12) Several conversions over to generic power management, from Vaibhav
    Gupta.

13) Add support for SO_KEEPALIVE et al. to bpf_setsockopt(), from Dmitry
    Yakunin.

14) Various https url conversions, from Alexander A. Klimov.

15) Timestamping and PHC support for mscc PHY driver, from Antoine
    Tenart.

16) Support bpf iterating over tcp and udp sockets, from Yonghong Song.

17) Support 5GBASE-T i40e NICs, from Aleksandr Loktionov.

18) Add kTLS RX HW offload support to mlx5e, from Tariq Toukan.

19) Fix the ->ndo_start_xmit() return type to be netdev_tx_t in several
    drivers. From Luc Van Oostenryck.

20) XDP support for xen-netfront, from Denis Kirjanov.

21) Support receive buffer autotuning in MPTCP, from Florian Westphal.

22) Support EF100 chip in sfc driver, from Edward Cree.

23) Add XDP support to mvpp2 driver, from Matteo Croce.

24) Support MPTCP in sock_diag, from Paolo Abeni.

25) Commonize UDP tunnel offloading code by creating udp_tunnel_nic
    infrastructure, from Jakub Kicinski.

26) Several pci_ --> dma_ API conversions, from Christophe JAILLET.

27) Add FLOW_ACTION_POLICE support to mlxsw, from Ido Schimmel.

28) Add SK_LOOKUP bpf program type, from Jakub Sitnicki.

29) Refactor a lot of networking socket option handling code in order to
    avoid set_fs() calls, from Christoph Hellwig.

30) Add rfc4884 support to icmp code, from Willem de Bruijn.

31) Support TBF offload in dpaa2-eth driver, from Ioana Ciornei.

32) Support XDP_REDIRECT in qede driver, from Alexander Lobakin.

33) Support PCI relaxed ordering in mlx5 driver, from Aya Levin.

34) Support TCP syncookies in MPTCP, from Flowian Westphal.

35) Fix several tricky cases of PMTU handling wrt. briding, from Stefano
    Brivio.

* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (2056 commits)
  net: thunderx: initialize VF's mailbox mutex before first usage
  usb: hso: remove bogus check for EINPROGRESS
  usb: hso: no complaint about kmalloc failure
  hso: fix bailout in error case of probe
  ip_tunnel_core: Fix build for archs without _HAVE_ARCH_IPV6_CSUM
  selftests/net: relax cpu affinity requirement in msg_zerocopy test
  mptcp: be careful on subflow creation
  selftests: rtnetlink: make kci_test_encap() return sub-test result
  selftests: rtnetlink: correct the final return value for the test
  net: dsa: sja1105: use detected device id instead of DT one on mismatch
  tipc: set ub->ifindex for local ipv6 address
  ipv6: add ipv6_dev_find()
  net: openvswitch: silence suspicious RCU usage warning
  Revert "vxlan: fix tos value before xmit"
  ptp: only allow phase values lower than 1 period
  farsync: switch from 'pci_' to 'dma_' API
  wan: wanxl: switch from 'pci_' to 'dma_' API
  hv_netvsc: do not use VF device if link is down
  dpaa2-eth: Fix passing zero to 'PTR_ERR' warning
  net: macb: Properly handle phylink on at91sam9x
  ...
This commit is contained in:
Linus Torvalds 2020-08-05 20:13:21 -07:00
commit 47ec5303d7
2088 changed files with 117472 additions and 40981 deletions

View File

@ -691,6 +691,42 @@ kernel API, the ``insn_off`` is the instruction offset in the unit of ``struct
bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the
beginning of section (``btf_ext_info_sec->sec_name_off``).
4.2 .BTF_ids section
====================
The .BTF_ids section encodes BTF ID values that are used within the kernel.
This section is created during the kernel compilation with the help of
macros defined in ``include/linux/btf_ids.h`` header file. Kernel code can
use them to create lists and sets (sorted lists) of BTF ID values.
The ``BTF_ID_LIST`` and ``BTF_ID`` macros define unsorted list of BTF ID values,
with following syntax::
BTF_ID_LIST(list)
BTF_ID(type1, name1)
BTF_ID(type2, name2)
resulting in following layout in .BTF_ids section::
__BTF_ID__type1__name1__1:
.zero 4
__BTF_ID__type2__name2__2:
.zero 4
The ``u32 list[];`` variable is defined to access the list.
The ``BTF_ID_UNUSED`` macro defines 4 zero bytes. It's used when we
want to define unused entry in BTF_ID_LIST, like::
BTF_ID_LIST(bpf_skb_output_btf_ids)
BTF_ID(struct, sk_buff)
BTF_ID_UNUSED
BTF_ID(struct, task_struct)
All the BTF ID lists and sets are compiled in the .BTF_ids section and
resolved during the linking phase of kernel build by ``resolve_btfids`` tool.
5. Using BTF
************

View File

@ -5,10 +5,10 @@ BPF Documentation
This directory contains documentation for the BPF (Berkeley Packet
Filter) facility, with a focus on the extended BPF version (eBPF).
This kernel side documentation is still work in progress. The main
This kernel side documentation is still work in progress. The main
textual documentation is (for historical reasons) described in
`Documentation/networking/filter.rst`_, which describe both classical
and extended BPF instruction-set.
:ref:`networking-filter`, which describe both classical and extended
BPF instruction-set.
The Cilium project also maintains a `BPF and XDP Reference Guide`_
that goes into great technical depth about the BPF Architecture.
@ -48,6 +48,15 @@ Program types
bpf_lsm
Map types
=========
.. toctree::
:maxdepth: 1
map_cgroup_storage
Testing and debugging BPF
=========================
@ -67,7 +76,7 @@ Other
ringbuf
.. Links:
.. _Documentation/networking/filter.rst: ../networking/filter.txt
.. _networking-filter: ../networking/filter.rst
.. _man-pages: https://www.kernel.org/doc/man-pages/
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/

View File

@ -0,0 +1,169 @@
.. SPDX-License-Identifier: GPL-2.0-only
.. Copyright (C) 2020 Google LLC.
===========================
BPF_MAP_TYPE_CGROUP_STORAGE
===========================
The ``BPF_MAP_TYPE_CGROUP_STORAGE`` map type represents a local fix-sized
storage. It is only available with ``CONFIG_CGROUP_BPF``, and to programs that
attach to cgroups; the programs are made available by the same Kconfig. The
storage is identified by the cgroup the program is attached to.
The map provide a local storage at the cgroup that the BPF program is attached
to. It provides a faster and simpler access than the general purpose hash
table, which performs a hash table lookups, and requires user to track live
cgroups on their own.
This document describes the usage and semantics of the
``BPF_MAP_TYPE_CGROUP_STORAGE`` map type. Some of its behaviors was changed in
Linux 5.9 and this document will describe the differences.
Usage
=====
The map uses key of type of either ``__u64 cgroup_inode_id`` or
``struct bpf_cgroup_storage_key``, declared in ``linux/bpf.h``::
struct bpf_cgroup_storage_key {
__u64 cgroup_inode_id;
__u32 attach_type;
};
``cgroup_inode_id`` is the inode id of the cgroup directory.
``attach_type`` is the the program's attach type.
Linux 5.9 added support for type ``__u64 cgroup_inode_id`` as the key type.
When this key type is used, then all attach types of the particular cgroup and
map will share the same storage. Otherwise, if the type is
``struct bpf_cgroup_storage_key``, then programs of different attach types
be isolated and see different storages.
To access the storage in a program, use ``bpf_get_local_storage``::
void *bpf_get_local_storage(void *map, u64 flags)
``flags`` is reserved for future use and must be 0.
There is no implicit synchronization. Storages of ``BPF_MAP_TYPE_CGROUP_STORAGE``
can be accessed by multiple programs across different CPUs, and user should
take care of synchronization by themselves. The bpf infrastructure provides
``struct bpf_spin_lock`` to synchronize the storage. See
``tools/testing/selftests/bpf/progs/test_spin_lock.c``.
Examples
========
Usage with key type as ``struct bpf_cgroup_storage_key``::
#include <bpf/bpf.h>
struct {
__uint(type, BPF_MAP_TYPE_CGROUP_STORAGE);
__type(key, struct bpf_cgroup_storage_key);
__type(value, __u32);
} cgroup_storage SEC(".maps");
int program(struct __sk_buff *skb)
{
__u32 *ptr = bpf_get_local_storage(&cgroup_storage, 0);
__sync_fetch_and_add(ptr, 1);
return 0;
}
Userspace accessing map declared above::
#include <linux/bpf.h>
#include <linux/libbpf.h>
__u32 map_lookup(struct bpf_map *map, __u64 cgrp, enum bpf_attach_type type)
{
struct bpf_cgroup_storage_key = {
.cgroup_inode_id = cgrp,
.attach_type = type,
};
__u32 value;
bpf_map_lookup_elem(bpf_map__fd(map), &key, &value);
// error checking omitted
return value;
}
Alternatively, using just ``__u64 cgroup_inode_id`` as key type::
#include <bpf/bpf.h>
struct {
__uint(type, BPF_MAP_TYPE_CGROUP_STORAGE);
__type(key, __u64);
__type(value, __u32);
} cgroup_storage SEC(".maps");
int program(struct __sk_buff *skb)
{
__u32 *ptr = bpf_get_local_storage(&cgroup_storage, 0);
__sync_fetch_and_add(ptr, 1);
return 0;
}
And userspace::
#include <linux/bpf.h>
#include <linux/libbpf.h>
__u32 map_lookup(struct bpf_map *map, __u64 cgrp, enum bpf_attach_type type)
{
__u32 value;
bpf_map_lookup_elem(bpf_map__fd(map), &cgrp, &value);
// error checking omitted
return value;
}
Semantics
=========
``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE`` is a variant of this map type. This
per-CPU variant will have different memory regions for each CPU for each
storage. The non-per-CPU will have the same memory region for each storage.
Prior to Linux 5.9, the lifetime of a storage is precisely per-attachment, and
for a single ``CGROUP_STORAGE`` map, there can be at most one program loaded
that uses the map. A program may be attached to multiple cgroups or have
multiple attach types, and each attach creates a fresh zeroed storage. The
storage is freed upon detach.
There is a one-to-one association between the map of each type (per-CPU and
non-per-CPU) and the BPF program during load verification time. As a result,
each map can only be used by one BPF program and each BPF program can only use
one storage map of each type. Because of map can only be used by one BPF
program, sharing of this cgroup's storage with other BPF programs were
impossible.
Since Linux 5.9, storage can be shared by multiple programs. When a program is
attached to a cgroup, the kernel would create a new storage only if the map
does not already contain an entry for the cgroup and attach type pair, or else
the old storage is reused for the new attachment. If the map is attach type
shared, then attach type is simply ignored during comparison. Storage is freed
only when either the map or the cgroup attached to is being freed. Detaching
will not directly free the storage, but it may cause the reference to the map
to reach zero and indirectly freeing all storage in the map.
The map is not associated with any BPF program, thus making sharing possible.
However, the BPF program can still only associate with one map of each type
(per-CPU and non-per-CPU). A BPF program cannot use more than one
``BPF_MAP_TYPE_CGROUP_STORAGE`` or more than one
``BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE``.
In all versions, userspace may use the the attach parameters of cgroup and
attach type pair in ``struct bpf_cgroup_storage_key`` as the key to the BPF map
APIs to read or update the storage for a given attachment. For Linux 5.9
attach type shared storages, only the first value in the struct, cgroup inode
id, is used during comparison, so userspace may just specify a ``__u64``
directly.
The storage is bound at attach time. Even if the program is attached to parent
and triggers in child, the storage still belongs to the parent.
Userspace cannot create a new entry in the map or delete an existing entry.
Program test runs always use a temporary storage.

View File

@ -10,7 +10,7 @@ such as network interfaces, crypto accelerator instances, L2 switches,
etc.
For an overview of the DPAA2 architecture and fsl-mc bus see:
Documentation/networking/device_drivers/freescale/dpaa2/overview.rst
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
As described in the above overview, all DPAA2 objects in a DPRC share the
same hardware "isolation context" and a 10-bit value called an ICID

View File

@ -22,6 +22,7 @@ select:
- amlogic,meson8m2-dwmac
- amlogic,meson-gxbb-dwmac
- amlogic,meson-axg-dwmac
- amlogic,meson-g12a-dwmac
required:
- compatible
@ -36,6 +37,7 @@ allOf:
- amlogic,meson8m2-dwmac
- amlogic,meson-gxbb-dwmac
- amlogic,meson-axg-dwmac
- amlogic,meson-g12a-dwmac
then:
properties:
@ -95,6 +97,7 @@ properties:
- amlogic,meson8m2-dwmac
- amlogic,meson-gxbb-dwmac
- amlogic,meson-axg-dwmac
- amlogic,meson-g12a-dwmac
contains:
enum:
- snps,dwmac-3.70a

View File

@ -1,257 +1,4 @@
Distributed Switch Architecture Device Tree Bindings
----------------------------------------------------
Switches are true Linux devices and can be probed by any means. Once
probed, they register to the DSA framework, passing a node
pointer. This node is expected to fulfil the following binding, and
may contain additional properties as required by the device it is
embedded within.
Required properties:
- ports : A container for child nodes representing switch ports.
Optional properties:
- dsa,member : A two element list indicates which DSA cluster, and position
within the cluster a switch takes. <0 0> is cluster 0,
switch 0. <0 1> is cluster 0, switch 1. <1 0> is cluster 1,
switch 0. A switch not part of any cluster (single device
hanging off a CPU port) must not specify this property
The ports container has the following properties
Required properties:
- #address-cells : Must be 1
- #size-cells : Must be 0
Each port children node must have the following mandatory properties:
- reg : Describes the port address in the switch
An uplink/downlink port between switches in the cluster has the following
mandatory property:
- link : Should be a list of phandles to other switch's DSA
port. This port is used as the outgoing port
towards the phandle ports. The full routing
information must be given, not just the one hop
routes to neighbouring switches.
A CPU port has the following mandatory property:
- ethernet : Should be a phandle to a valid Ethernet device node.
This host device is what the switch port is
connected to.
A user port has the following optional property:
- label : Describes the label associated with this port, which
will become the netdev name.
Port child nodes may also contain the following optional standardised
properties, described in binding documents:
- phy-handle : Phandle to a PHY on an MDIO bus. See
Documentation/devicetree/bindings/net/ethernet.txt
for details.
- phy-mode : See
Documentation/devicetree/bindings/net/ethernet.txt
for details.
- fixed-link : Fixed-link subnode describing a link to a non-MDIO
managed entity. See
Documentation/devicetree/bindings/net/fixed-link.txt
for details.
The MAC address will be determined using the optional properties
defined in ethernet.txt.
Example
The following example shows three switches on three MDIO busses,
linked into one DSA cluster.
&mdio1 {
#address-cells = <1>;
#size-cells = <0>;
switch0: switch0@0 {
compatible = "marvell,mv88e6085";
reg = <0>;
dsa,member = <0 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan0";
};
port@1 {
reg = <1>;
label = "lan1";
local-mac-address = [00 00 00 00 00 00];
};
port@2 {
reg = <2>;
label = "lan2";
};
switch0port5: port@5 {
reg = <5>;
phy-mode = "rgmii-txid";
link = <&switch1port6
&switch2port9>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
port@6 {
reg = <6>;
ethernet = <&fec1>;
fixed-link {
speed = <100>;
full-duplex;
};
};
};
};
};
&mdio2 {
#address-cells = <1>;
#size-cells = <0>;
switch1: switch1@0 {
compatible = "marvell,mv88e6085";
reg = <0>;
dsa,member = <0 1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan3";
phy-handle = <&switch1phy0>;
};
port@1 {
reg = <1>;
label = "lan4";
phy-handle = <&switch1phy1>;
};
port@2 {
reg = <2>;
label = "lan5";
phy-handle = <&switch1phy2>;
};
switch1port5: port@5 {
reg = <5>;
link = <&switch2port9>;
phy-mode = "rgmii-txid";
fixed-link {
speed = <1000>;
full-duplex;
};
};
switch1port6: port@6 {
reg = <6>;
phy-mode = "rgmii-txid";
link = <&switch0port5>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
switch1phy0: switch1phy0@0 {
reg = <0>;
};
switch1phy1: switch1phy0@1 {
reg = <1>;
};
switch1phy2: switch1phy0@2 {
reg = <2>;
};
};
};
};
&mdio4 {
#address-cells = <1>;
#size-cells = <0>;
switch2: switch2@0 {
compatible = "marvell,mv88e6085";
reg = <0>;
dsa,member = <0 2>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan6";
};
port@1 {
reg = <1>;
label = "lan7";
};
port@2 {
reg = <2>;
label = "lan8";
};
port@3 {
reg = <3>;
label = "optical3";
fixed-link {
speed = <1000>;
full-duplex;
link-gpios = <&gpio6 2
GPIO_ACTIVE_HIGH>;
};
};
port@4 {
reg = <4>;
label = "optical4";
fixed-link {
speed = <1000>;
full-duplex;
link-gpios = <&gpio6 3
GPIO_ACTIVE_HIGH>;
};
};
switch2port9: port@9 {
reg = <9>;
phy-mode = "rgmii-txid";
link = <&switch1port5
&switch0port5>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
See Documentation/devicetree/bindings/net/dsa/dsa.yaml for the documenation.

View File

@ -0,0 +1,92 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/dsa.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Ethernet Switch Device Tree Bindings
maintainers:
- Andrew Lunn <andrew@lunn.ch>
- Florian Fainelli <f.fainelli@gmail.com>
- Vivien Didelot <vivien.didelot@gmail.com>
description:
This binding represents Ethernet Switches which have a dedicated CPU
port. That port is usually connected to an Ethernet Controller of the
SoC. Such setups are typical for embedded devices.
select: false
properties:
$nodename:
pattern: "^switch(@.*)?$"
dsa,member:
minItems: 2
maxItems: 2
description:
A two element list indicates which DSA cluster, and position within the
cluster a switch takes. <0 0> is cluster 0, switch 0. <0 1> is cluster 0,
switch 1. <1 0> is cluster 1, switch 0. A switch not part of any cluster
(single device hanging off a CPU port) must not specify this property
$ref: /schemas/types.yaml#/definitions/uint32-array
patternProperties:
"^(ethernet-)?ports$":
type: object
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^(ethernet-)?port@[0-9]+$":
type: object
description: Ethernet switch ports
properties:
reg:
description: Port number
label:
description:
Describes the label associated with this port, which will become
the netdev name
$ref: /schemas/types.yaml#definitions/string
link:
description:
Should be a list of phandles to other switch's DSA port. This
port is used as the outgoing port towards the phandle ports. The
full routing information must be given, not just the one hop
routes to neighbouring switches
$ref: /schemas/types.yaml#definitions/phandle-array
ethernet:
description:
Should be a phandle to a valid Ethernet device node. This host
device is what the switch port is connected to
$ref: /schemas/types.yaml#definitions/phandle
phy-handle: true
phy-mode: true
fixed-link: true
mac-address: true
required:
- reg
additionalProperties: false
oneOf:
- required:
- ports
- required:
- ethernet-ports
...

View File

@ -4,10 +4,15 @@ Microchip Ocelot switch driver family
Felix
-----
The VSC9959 core is currently the only switch supported by the driver, and is
found in the NXP LS1028A. It is a PCI device, part of the larger ENETC root
complex. As a result, the ethernet-switch node is a sub-node of the PCIe root
complex node and its "reg" property conforms to the parent node bindings:
Currently the switches supported by the felix driver are:
- VSC9959 (Felix)
- VSC9953 (Seville)
The VSC9959 switch is found in the NXP LS1028A. It is a PCI device, part of the
larger ENETC root complex. As a result, the ethernet-switch node is a sub-node
of the PCIe root complex node and its "reg" property conforms to the parent
node bindings:
* reg: Specifies PCIe Device Number and Function Number of the endpoint device,
in this case for the Ethernet L2Switch it is PF5 (of device 0, bus 0).
@ -114,3 +119,95 @@ Example:
};
};
};
The VSC9953 switch is found inside NXP T1040. It is a platform device with the
following required properties:
- compatible:
Must be "mscc,vsc9953-switch".
Supported PHY interface types (appropriate SerDes protocol setting changes are
needed in the RCW binary):
* phy_mode = "internal": on ports 8 and 9
* phy_mode = "sgmii": on ports 0, 1, 2, 3, 4, 5, 6, 7
* phy_mode = "qsgmii": on ports 0, 1, 2, 3, 4, 5, 6, 7
Example:
&soc {
ethernet-switch@800000 {
#address-cells = <0x1>;
#size-cells = <0x0>;
compatible = "mscc,vsc9953-switch";
little-endian;
reg = <0x800000 0x290000>;
ports {
#address-cells = <0x1>;
#size-cells = <0x0>;
port@0 {
reg = <0x0>;
label = "swp0";
};
port@1 {
reg = <0x1>;
label = "swp1";
};
port@2 {
reg = <0x2>;
label = "swp2";
};
port@3 {
reg = <0x3>;
label = "swp3";
};
port@4 {
reg = <0x4>;
label = "swp4";
};
port@5 {
reg = <0x5>;
label = "swp5";
};
port@6 {
reg = <0x6>;
label = "swp6";
};
port@7 {
reg = <0x7>;
label = "swp7";
};
port@8 {
reg = <0x8>;
phy-mode = "internal";
ethernet = <&enet0>;
fixed-link {
speed = <2500>;
full-duplex;
};
};
port@9 {
reg = <0x9>;
phy-mode = "internal";
status = "disabled";
fixed-link {
speed = <2500>;
full-duplex;
};
};
};
};
};

View File

@ -162,6 +162,18 @@ properties:
description:
Specifies a reference to a node representing a SFP cage.
rx-internal-delay-ps:
description: |
RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
PHY's that have configurable RX internal delays. If this property is
present then the PHY applies the RX delay.
tx-internal-delay-ps:
description: |
RGMII Transmit PHY Clock Delay defined in pico seconds. This is used for
PHY's that have configurable TX internal delays. If this property is
present then the PHY applies the TX delay.
required:
- reg

View File

@ -39,6 +39,13 @@ properties:
and must therefore be appropriately determined based on all devices
requirements (maximum value of all per-device RESET pulse widths).
reset-post-delay-us:
description:
Delay after reset deassert in microseconds. It applies to all MDIO
devices and it's determined by how fast all devices are ready for
communication. This delay happens just before e.g. Ethernet PHY
type ID auto detection.
clock-frequency:
description:
Desired MDIO bus clock frequency in Hz. Values greater than IEEE 802.3

View File

@ -31,6 +31,8 @@ Optional properties:
VSC8531_LINK_100_ACTIVITY (2),
VSC8531_LINK_ACTIVITY (0) and
VSC8531_DUPLEX_COLLISION (8).
- load-save-gpios : GPIO used for the load/save operation of the PTP
hardware clock (PHC).
Table: 1 - Edge rate change
@ -67,4 +69,5 @@ Example:
vsc8531,edge-slowdown = <7>;
vsc8531,led-0-mode = <LINK_1000_ACTIVITY>;
vsc8531,led-1-mode = <LINK_100_ACTIVITY>;
load-save-gpios = <&gpio 10 GPIO_ACTIVE_HIGH>;
};

View File

@ -44,7 +44,7 @@ examples:
uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
uart-has-rtscts = <1>;
uart-has-rtscts;
bluetooth {
compatible = "realtek,rtl8723bs-bt";

View File

@ -24,7 +24,7 @@ description: |
IEEE 802.3 Standard Media Independent Interface (MII), the IEEE 802.3 Gigabit
Media Independent Interface (GMII) or Reduced GMII (RGMII).
Specifications about the charger can be found at:
Specifications about the Ethernet PHY can be found at:
https://www.ti.com/lit/gpn/dp83867ir
properties:

View File

@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: TI DP83869 ethernet PHY
allOf:
- $ref: "ethernet-controller.yaml#"
- $ref: "ethernet-phy.yaml#"
maintainers:
- Dan Murphy <dmurphy@ti.com>
@ -24,7 +24,7 @@ description: |
conversions. The DP83869HM can also support Bridge Conversion from RGMII to
SGMII and SGMII to RGMII.
Specifications about the charger can be found at:
Specifications about the Ethernet PHY can be found at:
http://www.ti.com/lit/ds/symlink/dp83869hm.pdf
properties:
@ -64,6 +64,18 @@ properties:
Operational mode for the PHY. If this is not set then the operational
mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
rx-internal-delay-ps:
description: Delay is in pico seconds
enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
3250, 3500, 3750, 4000 ]
default: 2000
tx-internal-delay-ps:
description: Delay is in pico seconds
enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
3250, 3500, 3750, 4000 ]
default: 2000
required:
- reg
@ -80,5 +92,7 @@ examples:
ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
ti,max-output-impedance = "true";
ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>;
rx-internal-delay-ps = <2000>;
tx-internal-delay-ps = <2000>;
};
};

View File

@ -342,7 +342,8 @@ LED
MDIO
devm_mdiobus_alloc()
devm_mdiobus_alloc_size()
devm_mdiobus_free()
devm_mdiobus_register()
devm_of_mdiobus_register()
MEM
devm_free_pages()

View File

@ -96,6 +96,7 @@ available subsections can be seen below.
phy/index
pti_intel_mid
pwm
pldmfw/index
rfkill
serial/index
sm501

View File

@ -0,0 +1,56 @@
.. SPDX-License-Identifier: GPL-2.0-only
=========================
Driver-specific callbacks
=========================
The ``pldmfw`` module relies on the device driver for implementing device
specific behavior using the following operations.
``.match_record``
-----------------
The ``.match_record`` operation is used to determine whether a given PLDM
record matches the device being updated. This requires comparing the record
descriptors in the record with information from the device. Many record
descriptors are defined by the PLDM standard, but it is also allowed for
devices to implement their own descriptors.
The ``.match_record`` operation should return true if a given record matches
the device.
``.send_package_data``
----------------------
The ``.send_package_data`` operation is used to send the device-specific
package data in a record to the device firmware. If the matching record
provides package data, ``pldmfw`` will call the ``.send_package_data``
function with a pointer to the package data and with the package data
length. The device driver should send this data to firmware.
``.send_component_table``
-------------------------
The ``.send_component_table`` operation is used to forward component
information to the device. It is called once for each applicable component,
that is, for each component indicated by the matching record. The
device driver should send the component information to the device firmware,
and wait for a response. The provided transfer flag indicates whether this
is the first, last, or a middle component, and is expected to be forwarded
to firmware as part of the component table information. The driver should an
error in the case when the firmware indicates that the component cannot be
updated, or return zero if the component can be updated.
``.flash_component``
--------------------
The ``.flash_component`` operation is used to inform the device driver to
flash a given component. The driver must perform any steps necessary to send
the component data to the device.
``.finalize_update``
--------------------
The ``.finalize_update`` operation is used by the ``pldmfw`` library in
order to allow the device driver to perform any remaining device specific
logic needed to finish the update.

View File

@ -0,0 +1,203 @@
.. SPDX-License-Identifier: GPL-2.0-only
==================================
PLDM Firmware file format overview
==================================
A PLDM firmware package is a binary file which contains a header that
describes the contents of the firmware package. This includes an initial
package header, one or more firmware records, and one or more components
describing the actual flash contents to program.
This diagram provides an overview of the file format::
overall file layout
+----------------------+
| |
| Package Header |
| |
+----------------------+
| |
| Device Records |
| |
+----------------------+
| |
| Component Info |
| |
+----------------------+
| |
| Package Header CRC |
| |
+----------------------+
| |
| Component Image 1 |
| |
+----------------------+
| |
| Component Image 2 |
| |
+----------------------+
| |
| ... |
| |
+----------------------+
| |
| Component Image N |
| |
+----------------------+
Package Header
==============
The package header begins with the UUID of the PLDM file format, and
contains information about the version of the format that the file uses. It
also includes the total header size, a release date, the size of the
component bitmap, and an overall package version.
The following diagram provides an overview of the package header::
header layout
+-------------------------+
| PLDM UUID |
+-------------------------+
| Format Revision |
+-------------------------+
| Header Size |
+-------------------------+
| Release Date |
+-------------------------+
| Component Bitmap Length |
+-------------------------+
| Package Version Info |
+-------------------------+
Device Records
==============
The device firmware records area starts with a count indicating the total
number of records in the file, followed by each record. A single device
record describes what device matches this record. All valid PLDM firmware
files must contain at least one record, but optionally may contain more than
one record if they support multiple devices.
Each record will identify the device it supports via TLVs that describe the
device, such as the PCI device and vendor information. It will also indicate
which set of components that are used by this device. It is possible that
only subset of provided components will be used by a given record. A record
may also optionally contain device-specific package data that will be used
by the device firmware during the update process.
The following diagram provides an overview of the device record area::
area layout
+---------------+
| |
| Record Count |
| |
+---------------+
| |
| Record 1 |
| |
+---------------+
| |
| Record 2 |
| |
+---------------+
| |
| ... |
| |
+---------------+
| |
| Record N |
| |
+---------------+
record layout
+-----------------------+
| Record Length |
+-----------------------+
| Descriptor Count |
+-----------------------+
| Option Flags |
+-----------------------+
| Version Settings |
+-----------------------+
| Package Data Length |
+-----------------------+
| Applicable Components |
+-----------------------+
| Version String |
+-----------------------+
| Descriptor TLVs |
+-----------------------+
| Package Data |
+-----------------------+
Component Info
==============
The component information area begins with a count of the number of
components. Following this count is a description for each component. The
component information points to the location in the file where the component
data is stored, and includes version data used to identify the version of
the component.
The following diagram provides an overview of the component area::
area layout
+-----------------+
| |
| Component Count |
| |
+-----------------+
| |
| Component 1 |
| |
+-----------------+
| |
| Component 2 |
| |
+-----------------+
| |
| ... |
| |
+-----------------+
| |
| Component N |
| |
+-----------------+
component layout
+------------------------+
| Classification |
+------------------------+
| Component Identifier |
+------------------------+
| Comparison Stamp |
+------------------------+
| Component Options |
+------------------------+
| Activation Method |
+------------------------+
| Location Offset |
+------------------------+
| Component Size |
+------------------------+
| Component Version Info |
+------------------------+
| Package Data |
+------------------------+
Package Header CRC
==================
Following the component information is a short 4-byte CRC calculated over
the contents of all of the header information.
Component Images
================
The component images follow the package header information in the PLDM
firmware file. Each of these is simply a binary chunk with its start and
size defined by the matching component structure in the component info area.

View File

@ -0,0 +1,72 @@
.. SPDX-License-Identifier: GPL-2.0-only
==================================
PLDM Firmware Flash Update Library
==================================
``pldmfw`` implements functionality for updating the flash on a device using
the PLDM for Firmware Update standard
<https://www.dmtf.org/documents/pmci/pldm-firmware-update-specification-100>.
.. toctree::
:maxdepth: 1
file-format
driver-ops
==================================
Overview of the ``pldmfw`` library
==================================
The ``pldmfw`` library is intended to be used by device drivers for
implementing device flash update based on firmware files following the PLDM
firwmare file format.
It is implemented using an ops table that allows device drivers to provide
the underlying device specific functionality.
``pldmfw`` implements logic to parse the packed binary format of the PLDM
firmware file into data structures, and then uses the provided function
operations to determine if the firmware file is a match for the device. If
so, it sends the record and component data to the firmware using the device
specific implementations provided by device drivers. Once the device
firmware indicates that the update may be performed, the firmware data is
sent to the device for programming.
Parsing the PLDM file
=====================
The PLDM file format uses packed binary data, with most multi-byte fields
stored in the Little Endian format. Several pieces of data are variable
length, including version strings and the number of records and components.
Due to this, it is not straight forward to index the record, record
descriptors, or components.
To avoid proliferating access to the packed binary data, the ``pldmfw``
library parses and extracts this data into simpler structures for ease of
access.
In order to safely process the firmware file, care is taken to avoid
unaligned access of multi-byte fields, and to properly convert from Little
Endian to CPU host format. Additionally the records, descriptors, and
components are stored in linked lists.
Performing a flash update
=========================
To perform a flash update, the ``pldmfw`` module performs the following
steps
1. Parse the firmware file for record and component information
2. Scan through the records and determine if the device matches any record
in the file. The first matched record will be used.
3. If the matching record provides package data, send this package data to
the device.
4. For each component that the record indicates, send the component data to
the device. For each component, the firmware may respond with an
indication of whether the update is suitable or not. If any component is
not suitable, the update is canceled.
5. For each component, send the binary data to the device firmware for
updating.
6. After all components are programmed, perform any final device-specific
actions to finalize the update.

View File

@ -185,13 +185,17 @@ byte offsets over a base for the register block.
If you want to dump an u32 array in debugfs, you can create file with::
struct debugfs_u32_array {
u32 *array;
u32 n_elements;
};
void debugfs_create_u32_array(const char *name, umode_t mode,
struct dentry *parent,
u32 *array, u32 elements);
struct debugfs_u32_array *array);
The "array" argument provides data, and the "elements" argument is
the number of elements in the array. Note: Once array is created its
size can not be changed.
The "array" argument wraps a pointer to the array's data and the number
of its elements. Note: Once array is created its size can not be changed.
There is a helper function to create device related seq_file::

View File

@ -73,7 +73,7 @@ lower value. This will make the mesh more responsive to topology changes, but
will also increase the overhead.
Information about the current state can be accessed via the batadv generic
netlink family. batctl provides human readable version via its debug tables
netlink family. batctl provides a human readable version via its debug tables
subcommands.
@ -115,8 +115,8 @@ are prefixed with "batman-adv:" So to see just these messages try::
$ dmesg | grep batman-adv
When investigating problems with your mesh network, it is sometimes necessary to
see more detail debug messages. This must be enabled when compiling the
batman-adv module. When building batman-adv as part of kernel, use "make
see more detailed debug messages. This must be enabled when compiling the
batman-adv module. When building batman-adv as part of the kernel, use "make
menuconfig" and enable the option ``B.A.T.M.A.N. debugging``
(``CONFIG_BATMAN_ADV_DEBUG=y``).
@ -160,7 +160,7 @@ IRC:
#batman on irc.freenode.org
Mailing-list:
b.a.t.m.a.n@open-mesh.org (optional subscription at
https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n)
https://lists.open-mesh.org/mailman3/postorius/lists/b.a.t.m.a.n.lists.open-mesh.org/)
You can also contact the Authors:

View File

@ -192,6 +192,9 @@ FIONREAD
Works as in udp(7): returns in the ``int`` argument pointer the size of
the next pending datagram in bytes, or 0 when no datagram is pending.
SIOCOUTQ
Returns the number of unsent data bytes in the socket send queue as ``int``
into the buffer specified by the argument pointer.
Other tunables
==============

View File

@ -0,0 +1,19 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
AppleTalk Device Drivers
========================
Contents:
.. toctree::
:maxdepth: 2
cops
ltpc
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -0,0 +1,20 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Asynchronous Transfer Mode (ATM) Device Drivers
===============================================
Contents:
.. toctree::
:maxdepth: 2
cxacru
fore200e
iphase
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -0,0 +1,18 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Cable Modem Device Drivers
==========================
Contents:
.. toctree::
:maxdepth: 2
sb1000
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -0,0 +1,18 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Cellular Modem Device Drivers
=============================
Contents:
.. toctree::
:maxdepth: 2
qualcomm/rmnet
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -4,8 +4,6 @@
3Com Vortex device driver
=========================
Documentation/networking/device_drivers/3com/vortex.rst
Andrew Morton
30 April 2000

View File

@ -19,8 +19,10 @@ pool management for network interfaces.
This document provides an overview the Linux DPIO driver, its
subcomponents, and its APIs.
See Documentation/networking/device_drivers/freescale/dpaa2/overview.rst for
a general overview of DPAA2 and the general DPAA2 driver architecture in Linux.
See
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
for a general overview of DPAA2 and the general DPAA2 driver architecture
in Linux.
Driver Overview
---------------

View File

@ -33,7 +33,8 @@ hardware resources, like queues, do not have a corresponding MC object and
are treated as internal resources of other objects.
For a more detailed description of the DPAA2 architecture and its object
abstractions see *Documentation/networking/device_drivers/freescale/dpaa2/overview.rst*.
abstractions see
*Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst*.
Each Linux net device is built on top of a Datapath Network Interface (DPNI)
object and uses Buffer Pools (DPBPs), I/O Portals (DPIOs) and Concentrators

View File

@ -0,0 +1,60 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Ethernet Device Drivers
=======================
Device drivers for Ethernet and Ethernet-based virtual function devices.
Contents:
.. toctree::
:maxdepth: 2
3com/3c509
3com/vortex
amazon/ena
altera/altera_tse
aquantia/atlantic
chelsio/cxgb
cirrus/cs89x0
dlink/dl2k
davicom/dm9000
dec/de4x5
dec/dmfe
freescale/dpaa
freescale/dpaa2/index
freescale/gianfar
google/gve
huawei/hinic
intel/e100
intel/e1000
intel/e1000e
intel/fm10k
intel/igb
intel/igbvf
intel/ixgb
intel/ixgbe
intel/ixgbevf
intel/i40e
intel/iavf
intel/ice
marvell/octeontx2
mellanox/mlx5
microsoft/netvsc
neterion/s2io
neterion/vxge
netronome/nfp
pensando/ionic
smsc/smc9
stmicro/stmmac
ti/cpsw
ti/cpsw_switchdev
ti/tlan
toshiba/spider_net
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -41,7 +41,7 @@ Identifying Your Adapter
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
http://www.intel.com/support
https://www.intel.com/support
Driver Configuration Parameters
===============================
@ -179,7 +179,7 @@ filtering by
Support
=======
For general information, go to the Intel support website at:
http://www.intel.com/support/
https://www.intel.com/support/
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000

View File

@ -22,7 +22,7 @@ Ethernet Multi-host Controller.
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
http://www.intel.com/support
https://www.intel.com/support
Flow Control

View File

@ -43,7 +43,7 @@ device.
For information on how to identify your adapter, and for the latest NVM/FW
images and Intel network drivers, refer to the Intel Support website:
http://www.intel.com/support
https://www.intel.com/support
Additional Features and Configurations

View File

@ -20,7 +20,7 @@ Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
http://www.intel.com/support
https://www.intel.com/support
Command Line Parameters

View File

@ -35,7 +35,7 @@ Identifying Your Adapter
========================
For information on how to identify your adapter, and for the latest Intel
network drivers, refer to the Intel Support website:
http://www.intel.com/support
https://www.intel.com/support
Additional Features and Configurations

View File

@ -203,7 +203,7 @@ With the 10 Gigabit server adapters, the default Linux configuration will
very likely limit the total available throughput artificially. There is a set
of configuration changes that, when applied together, will increase the ability
of Linux to transmit and receive data. The following enhancements were
originally acquired from settings published at http://www.spec.org/web99/ for
originally acquired from settings published at https://www.spec.org/web99/ for
various submitted results using Linux.
NOTE:

View File

@ -0,0 +1,19 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Fiber Distributed Data Interface (FDDI) Device Drivers
======================================================
Contents:
.. toctree::
:maxdepth: 2
defza
skfp
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -0,0 +1,19 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Amateur Radio Device Drivers
============================
Contents:
.. toctree::
:maxdepth: 2
baycom
z8530drv
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -1,56 +1,22 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Vendor Device Drivers
=====================
Hardware Device Drivers
=======================
Contents:
.. toctree::
:maxdepth: 2
freescale/dpaa2/index
intel/e100
intel/e1000
intel/e1000e
intel/fm10k
intel/igb
intel/igbvf
intel/ixgb
intel/ixgbe
intel/ixgbevf
intel/i40e
intel/iavf
intel/ice
google/gve
marvell/octeontx2
mellanox/mlx5
netronome/nfp
pensando/ionic
stmicro/stmmac
3com/3c509
3com/vortex
amazon/ena
aquantia/atlantic
chelsio/cxgb
cirrus/cs89x0
davicom/dm9000
dec/de4x5
dec/dmfe
dlink/dl2k
freescale/dpaa
freescale/gianfar
intel/ipw2100
intel/ipw2200
microsoft/netvsc
neterion/s2io
neterion/vxge
qualcomm/rmnet
sb1000
smsc/smc9
ti/cpsw_switchdev
ti/cpsw
ti/tlan
toshiba/spider_net
appletalk/index
atm/index
cable/index
cellular/index
ethernet/index
fddi/index
hamradio/index
wan/index
wifi/index
.. only:: subproject and html

View File

@ -0,0 +1,18 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Classic WAN Device Drivers
==========================
Contents:
.. toctree::
:maxdepth: 2
z8530book
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -0,0 +1,20 @@
.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Wi-Fi Device Drivers
====================
Contents:
.. toctree::
:maxdepth: 2
intel/ipw2100
intel/ipw2200
ray_cs
.. only:: subproject and html
Indices
=======
* :ref:`genindex`

View File

@ -78,7 +78,7 @@ such, if you are interested in deploying or shipping a driver as part of
solution intended to be used for purposes other than development, please
obtain a tested driver from Intel Customer Support at:
http://www.intel.com/support/wireless/sb/CS-006408.htm
https://www.intel.com/support/wireless/sb/CS-006408.htm
1. Introduction
===============

View File

@ -44,9 +44,11 @@ versions is generally discouraged - here, and via any other Linux API.
reported for two ports of the same device or on two hosts of
a multi-host device should be identical.
.. note:: ``devlink-info`` API should be extended with a new field
if devices want to report board/product serial number (often
reported in PCI *Vital Product Data* capability).
* - ``board.serial_number``
- Board serial number of the device.
This is usually the serial number of the board, often available in
PCI *Vital Product Data*.
* - ``fixed``
- Group for hardware identifiers, and versions of components
@ -201,10 +203,6 @@ Future work
The following extensions could be useful:
- product serial number - NIC boards often get labeled with a board serial
number rather than ASIC serial number; it'd be useful to add board serial
numbers to the API if they can be retrieved from the device;
- on-disk firmware file names - drivers list the file names of firmware they
may need to load onto devices via the ``MODULE_FIRMWARE()`` macro. These,
however, are per module, rather than per device. It'd be useful to list

View File

@ -405,6 +405,10 @@ be added to the following table:
- ``control``
- Traps packets logged during processing of flow action trap (e.g., via
tc's trap action)
* - ``early_drop``
- ``drop``
- Traps packets dropped due to the RED (Random Early Detection) algorithm
(i.e., early drops)
Driver-specific Packet Traps
============================

View File

@ -84,8 +84,20 @@ The ``ice`` driver reports the following versions
Regions
=======
The ``ice`` driver enables access to the contents of the Non Volatile Memory
flash chip via the ``nvm-flash`` region.
The ``ice`` driver implements the following regions for accessing internal
device data.
.. list-table:: regions implemented
:widths: 15 85
* - Name
- Description
* - ``nvm-flash``
- The contents of the entire flash chip, sometimes referred to as
the device's Non Volatile Memory.
* - ``device-caps``
- The contents of the device firmware's capabilities buffer. Useful to
determine the current state and configuration of the device.
Users can request an immediate capture of a snapshot via the
``DEVLINK_CMD_REGION_NEW``
@ -105,3 +117,42 @@ Users can request an immediate capture of a snapshot via the
0000000000000000 0014 95dc 0014 9514 0035 1670 0034 db30
$ devlink region delete pci/0000:01:00.0/nvm-flash snapshot 1
$ devlink region new pci/0000:01:00.0/device-caps snapshot 1
$ devlink region dump pci/0000:01:00.0/device-caps snapshot 1
0000000000000000 01 00 01 00 00 00 00 00 01 00 00 00 00 00 00 00
0000000000000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000020 02 00 02 01 32 03 00 00 0a 00 00 00 25 00 00 00
0000000000000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000040 04 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00
0000000000000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000060 05 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00
0000000000000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000080 06 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00
0000000000000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000000a0 08 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000000c0 12 00 01 00 01 00 00 00 01 00 01 00 00 00 00 00
00000000000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000000e0 13 00 01 00 00 01 00 00 00 00 00 00 00 00 00 00
00000000000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000100 14 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00
0000000000000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000120 15 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00
0000000000000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000140 16 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00
0000000000000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000160 17 00 01 00 06 00 00 00 00 00 00 00 00 00 00 00
0000000000000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000180 18 00 01 00 01 00 00 00 01 00 00 00 08 00 00 00
0000000000000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000001a0 22 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00
00000000000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000001c0 40 00 01 00 00 08 00 00 08 00 00 00 00 00 00 00
00000000000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000000000001e0 41 00 01 00 00 08 00 00 00 00 00 00 00 00 00 00
00000000000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000000000000200 42 00 01 00 00 08 00 00 00 00 00 00 00 00 00 00
0000000000000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
$ devlink region delete pci/0000:01:00.0/device-caps snapshot 1

View File

@ -443,10 +443,11 @@ supports.
LINKSTATE_GET
=============
Requests link state information. At the moment, only link up/down flag (as
provided by ``ETHTOOL_GLINK`` ioctl command) is provided but some future
extensions are planned (e.g. link down reason). This request does not have any
attributes.
Requests link state information. Link up/down flag (as provided by
``ETHTOOL_GLINK`` ioctl command) is provided. Optionally, extended state might
be provided as well. In general, extended state describes reasons for why a port
is down, or why it operates in some non-obvious mode. This request does not have
any attributes.
Request contents:
@ -461,16 +462,135 @@ Kernel response contents:
``ETHTOOL_A_LINKSTATE_LINK`` bool link state (up/down)
``ETHTOOL_A_LINKSTATE_SQI`` u32 Current Signal Quality Index
``ETHTOOL_A_LINKSTATE_SQI_MAX`` u32 Max support SQI value
``ETHTOOL_A_LINKSTATE_EXT_STATE`` u8 link extended state
``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE`` u8 link extended substate
==================================== ====== ============================
For most NIC drivers, the value of ``ETHTOOL_A_LINKSTATE_LINK`` returns
carrier flag provided by ``netif_carrier_ok()`` but there are drivers which
define their own handler.
``ETHTOOL_A_LINKSTATE_EXT_STATE`` and ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE`` are
optional values. ethtool core can provide either both
``ETHTOOL_A_LINKSTATE_EXT_STATE`` and ``ETHTOOL_A_LINKSTATE_EXT_SUBSTATE``,
or only ``ETHTOOL_A_LINKSTATE_EXT_STATE``, or none of them.
``LINKSTATE_GET`` allows dump requests (kernel returns reply messages for all
devices supporting the request).
Link extended states:
================================================ ============================================
``ETHTOOL_LINK_EXT_STATE_AUTONEG`` States relating to the autonegotiation or
issues therein
``ETHTOOL_LINK_EXT_STATE_LINK_TRAINING_FAILURE`` Failure during link training
``ETHTOOL_LINK_EXT_STATE_LINK_LOGICAL_MISMATCH`` Logical mismatch in physical coding sublayer
or forward error correction sublayer
``ETHTOOL_LINK_EXT_STATE_BAD_SIGNAL_INTEGRITY`` Signal integrity issues
``ETHTOOL_LINK_EXT_STATE_NO_CABLE`` No cable connected
``ETHTOOL_LINK_EXT_STATE_CABLE_ISSUE`` Failure is related to cable,
e.g., unsupported cable
``ETHTOOL_LINK_EXT_STATE_EEPROM_ISSUE`` Failure is related to EEPROM, e.g., failure
during reading or parsing the data
``ETHTOOL_LINK_EXT_STATE_CALIBRATION_FAILURE`` Failure during calibration algorithm
``ETHTOOL_LINK_EXT_STATE_POWER_BUDGET_EXCEEDED`` The hardware is not able to provide the
power required from cable or module
``ETHTOOL_LINK_EXT_STATE_OVERHEAT`` The module is overheated
================================================ ============================================
Link extended substates:
Autoneg substates:
=============================================================== ================================
``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTED`` Peer side is down
``ETHTOOL_LINK_EXT_SUBSTATE_AN_ACK_NOT_RECEIVED`` Ack not received from peer side
``ETHTOOL_LINK_EXT_SUBSTATE_AN_NEXT_PAGE_EXCHANGE_FAILED`` Next page exchange failed
``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_PARTNER_DETECTED_FORCE_MODE`` Peer side is down during force
mode or there is no agreement of
speed
``ETHTOOL_LINK_EXT_SUBSTATE_AN_FEC_MISMATCH_DURING_OVERRIDE`` Forward error correction modes
in both sides are mismatched
``ETHTOOL_LINK_EXT_SUBSTATE_AN_NO_HCD`` No Highest Common Denominator
=============================================================== ================================
Link training substates:
=========================================================================== ====================
``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_FRAME_LOCK_NOT_ACQUIRED`` Frames were not
recognized, the
lock failed
``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_INHIBIT_TIMEOUT`` The lock did not
occur before
timeout
``ETHTOOL_LINK_EXT_SUBSTATE_LT_KR_LINK_PARTNER_DID_NOT_SET_RECEIVER_READY`` Peer side did not
send ready signal
after training
process
``ETHTOOL_LINK_EXT_SUBSTATE_LT_REMOTE_FAULT`` Remote side is not
ready yet
=========================================================================== ====================
Link logical mismatch substates:
================================================================ ===============================
``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_BLOCK_LOCK`` Physical coding sublayer was
not locked in first phase -
block lock
``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_ACQUIRE_AM_LOCK`` Physical coding sublayer was
not locked in second phase -
alignment markers lock
``ETHTOOL_LINK_EXT_SUBSTATE_LLM_PCS_DID_NOT_GET_ALIGN_STATUS`` Physical coding sublayer did
not get align status
``ETHTOOL_LINK_EXT_SUBSTATE_LLM_FC_FEC_IS_NOT_LOCKED`` FC forward error correction is
not locked
``ETHTOOL_LINK_EXT_SUBSTATE_LLM_RS_FEC_IS_NOT_LOCKED`` RS forward error correction is
not locked
================================================================ ===============================
Bad signal integrity substates:
================================================================= =============================
``ETHTOOL_LINK_EXT_SUBSTATE_BSI_LARGE_NUMBER_OF_PHYSICAL_ERRORS`` Large number of physical
errors
``ETHTOOL_LINK_EXT_SUBSTATE_BSI_UNSUPPORTED_RATE`` The system attempted to
operate the cable at a rate
that is not formally
supported, which led to
signal integrity issues
================================================================= =============================
Cable issue substates:
=================================================== ============================================
``ETHTOOL_LINK_EXT_SUBSTATE_CI_UNSUPPORTED_CABLE`` Unsupported cable
``ETHTOOL_LINK_EXT_SUBSTATE_CI_CABLE_TEST_FAILURE`` Cable test failure
=================================================== ============================================
DEBUG_GET
=========
@ -1110,6 +1230,42 @@ used to report the amplitude of the reflection for a given pair.
| | | ``ETHTOOL_A_CABLE_AMPLITUDE_mV`` | s16 | Reflection amplitude |
+-+-+-----------------------------------------+--------+----------------------+
TUNNEL_INFO
===========
Gets information about the tunnel state NIC is aware of.
Request contents:
===================================== ====== ==========================
``ETHTOOL_A_TUNNEL_INFO_HEADER`` nested request header
===================================== ====== ==========================
Kernel response contents:
+---------------------------------------------+--------+---------------------+
| ``ETHTOOL_A_TUNNEL_INFO_HEADER`` | nested | reply header |
+---------------------------------------------+--------+---------------------+
| ``ETHTOOL_A_TUNNEL_INFO_UDP_PORTS`` | nested | all UDP port tables |
+-+-------------------------------------------+--------+---------------------+
| | ``ETHTOOL_A_TUNNEL_UDP_TABLE`` | nested | one UDP port table |
+-+-+-----------------------------------------+--------+---------------------+
| | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_SIZE`` | u32 | max size of the |
| | | | | table |
+-+-+-----------------------------------------+--------+---------------------+
| | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES`` | bitset | tunnel types which |
| | | | | table can hold |
+-+-+-----------------------------------------+--------+---------------------+
| | | ``ETHTOOL_A_TUNNEL_UDP_TABLE_ENTRY`` | nested | offloaded UDP port |
+-+-+-+---------------------------------------+--------+---------------------+
| | | | ``ETHTOOL_A_TUNNEL_UDP_ENTRY_PORT`` | be16 | UDP port |
+-+-+-+---------------------------------------+--------+---------------------+
| | | | ``ETHTOOL_A_TUNNEL_UDP_ENTRY_TYPE`` | u32 | tunnel type |
+-+-+-+---------------------------------------+--------+---------------------+
For UDP tunnel table empty ``ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES`` indicates that
the table contains static entries, hard-coded by the NIC.
Request translation
===================

View File

@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
.. _networking-filter:
=======================================================
Linux Socket Filtering aka Berkeley Packet Filter (BPF)
=======================================================

View File

@ -20,7 +20,6 @@ Contents:
ieee802154
j1939
kapi
z8530book
msg_zerocopy
failover
net_dim
@ -39,36 +38,28 @@ Contents:
nfc
6lowpan
6pack
altera_tse
arcnet-hardware
arcnet
atm
ax25
baycom
bonding
cdc_mbim
cops
cxacru
dccp
dctcp
decnet
defza
dns_resolver
driver
eql
fib_trie
filter
fore200e
framerelay
generic-hdlc
generic_netlink
gen_stats
gtp
hinic
ila
ipddp
ip_dynaddr
iphase
ipsec
ip-sysctl
ipv6
@ -77,7 +68,6 @@ Contents:
kcm
l2tp
lapb-module
ltpc
mac80211-injection
mpls-sysctl
multiqueue
@ -97,14 +87,12 @@ Contents:
ppp_generic
proc_net_tcp
radiotap-headers
ray_cs
rds
regulatory
rxrpc
sctp
secid
seg6-sysctl
skfp
strparser
switchdev
tc-actions-env-rules
@ -122,7 +110,6 @@ Contents:
xfrm_proc
xfrm_sync
xfrm_sysctl
z8530drv
.. only:: subproject and html

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