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
...
zero-sugar-mainline-defconfig
Linus Torvalds
commit
47ec5303d7
|
|
@ -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
|
||||
************
|
||||
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
...
|
||||
|
|
@ -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;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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()
|
||||
|
|
|
|||
|
|
@ -96,6 +96,7 @@ available subsections can be seen below.
|
|||
phy/index
|
||||
pti_intel_mid
|
||||
pwm
|
||||
pldmfw/index
|
||||
rfkill
|
||||
serial/index
|
||||
sm501
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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::
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
==============
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
@ -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`
|
||||
|
|
@ -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`
|
||||
|
|
@ -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`
|
||||
|
|
@ -4,8 +4,6 @@
|
|||
3Com Vortex device driver
|
||||
=========================
|
||||
|
||||
Documentation/networking/device_drivers/3com/vortex.rst
|
||||
|
||||
Andrew Morton
|
||||
|
||||
30 April 2000
|
||||
|
|
@ -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
|
||||
---------------
|
||||
|
|
@ -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
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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:
|
||||
|
|
@ -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`
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
===============
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
============================
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
===================
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,7 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. _networking-filter:
|
||||
|
||||
=======================================================
|
||||
Linux Socket Filtering aka Berkeley Packet Filter (BPF)
|
||||
=======================================================
|
||||
|
|
|
|||
|
|
@ -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
Loading…
Reference in New Issue