Merge 8ca5297e7e Merge tag 'kconfig-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild into android-mainline
A tiny step en route to v5.13-rc1 Signed-off-by: Lee Jones <lee.jones@linaro.org> Change-Id: I7eba2160e4a0e04beaf653dcce126a5b2e5a50ac
This commit is contained in:
Lee Jones
commit
92f282f338
|
|
@ -57,8 +57,10 @@ modules.order
|
|||
/tags
|
||||
/TAGS
|
||||
/linux
|
||||
/modules-only.symvers
|
||||
/vmlinux
|
||||
/vmlinux.32
|
||||
/vmlinux.map
|
||||
/vmlinux.symvers
|
||||
/vmlinux-gdb.py
|
||||
/vmlinuz
|
||||
|
|
|
|||
|
|
@ -378,3 +378,32 @@ Description:
|
|||
The value comes from the PCI kernel device state and can be one
|
||||
of: "unknown", "error", "D0", D1", "D2", "D3hot", "D3cold".
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/pci/devices/.../sriov_vf_total_msix
|
||||
Date: January 2021
|
||||
Contact: Leon Romanovsky <leonro@nvidia.com>
|
||||
Description:
|
||||
This file is associated with a SR-IOV physical function (PF).
|
||||
It contains the total number of MSI-X vectors available for
|
||||
assignment to all virtual functions (VFs) associated with PF.
|
||||
The value will be zero if the device doesn't support this
|
||||
functionality. For supported devices, the value will be
|
||||
constant and won't be changed after MSI-X vectors assignment.
|
||||
|
||||
What: /sys/bus/pci/devices/.../sriov_vf_msix_count
|
||||
Date: January 2021
|
||||
Contact: Leon Romanovsky <leonro@nvidia.com>
|
||||
Description:
|
||||
This file is associated with a SR-IOV virtual function (VF).
|
||||
It allows configuration of the number of MSI-X vectors for
|
||||
the VF. This allows devices that have a global pool of MSI-X
|
||||
vectors to optimally divide them between VFs based on VF usage.
|
||||
|
||||
The values accepted are:
|
||||
* > 0 - this number will be reported as the Table Size in the
|
||||
VF's MSI-X capability
|
||||
* < 0 - not valid
|
||||
* = 0 - will reset to the device default value
|
||||
|
||||
The file is writable if the PF is bound to a driver that
|
||||
implements ->sriov_set_msix_vec_count().
|
||||
|
|
|
|||
|
|
@ -51,3 +51,15 @@ Description:
|
|||
Boolean value indicating whether the PHY device is used in
|
||||
standalone mode, without a net_device associated, by PHYLINK.
|
||||
Attribute created only when this is the case.
|
||||
|
||||
What: /sys/class/mdio_bus/<bus>/<device>/phy_dev_flags
|
||||
Date: March 2021
|
||||
KernelVersion: 5.13
|
||||
Contact: netdev@vger.kernel.org
|
||||
Description:
|
||||
32-bit hexadecimal number representing a bit mask of the
|
||||
configuration bits passed from the consumer of the PHY
|
||||
(Ethernet MAC, switch, etc.) to the PHY driver. The flags are
|
||||
only used internally by the kernel and their placement are
|
||||
not meant to be stable across kernel versions. This is intended
|
||||
for facilitating the debugging of PHY drivers.
|
||||
|
|
|
|||
|
|
@ -311,6 +311,17 @@ permit to distribute the load on several cpus.
|
|||
If set to 1 (default), timestamps are sampled as soon as possible, before
|
||||
queueing.
|
||||
|
||||
netdev_unregister_timeout_secs
|
||||
------------------------------
|
||||
|
||||
Unregister network device timeout in seconds.
|
||||
This option controls the timeout (in seconds) used to issue a warning while
|
||||
waiting for a network device refcount to drop to 0 during device
|
||||
unregistration. A lower value may be useful during bisection to detect
|
||||
a leaked reference faster. A larger value may be useful to prevent false
|
||||
warnings on slow/loaded systems.
|
||||
Default value is 10, minimum 1, maximum 3600.
|
||||
|
||||
optmem_max
|
||||
----------
|
||||
|
||||
|
|
|
|||
|
|
@ -522,7 +522,7 @@ and the short name of the data device. They all can be found in:
|
|||
================ ===========
|
||||
xfs_iwalk-$pid Inode scans of the entire filesystem. Currently limited to
|
||||
mount time quotacheck.
|
||||
xfs-blockgc Background garbage collection of disk space that have been
|
||||
xfs-gc Background garbage collection of disk space that have been
|
||||
speculatively allocated beyond EOF or for staging copy on
|
||||
write operations.
|
||||
================ ===========
|
||||
|
|
|
|||
|
|
@ -258,3 +258,18 @@ Q: Can BPF functionality such as new program or map types, new
|
|||
helpers, etc be added out of kernel module code?
|
||||
|
||||
A: NO.
|
||||
|
||||
Q: Directly calling kernel function is an ABI?
|
||||
----------------------------------------------
|
||||
Q: Some kernel functions (e.g. tcp_slow_start) can be called
|
||||
by BPF programs. Do these kernel functions become an ABI?
|
||||
|
||||
A: NO.
|
||||
|
||||
The kernel function protos will change and the bpf programs will be
|
||||
rejected by the verifier. Also, for example, some of the bpf-callable
|
||||
kernel functions have already been used by other kernel tcp
|
||||
cc (congestion-control) implementations. If any of these kernel
|
||||
functions has changed, both the in-tree and out-of-tree kernel tcp cc
|
||||
implementations have to be changed. The same goes for the bpf
|
||||
programs and they have to be adjusted accordingly.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ list:
|
|||
This may also include issues related to XDP, BPF tracing, etc.
|
||||
|
||||
Given netdev has a high volume of traffic, please also add the BPF
|
||||
maintainers to Cc (from kernel MAINTAINERS_ file):
|
||||
maintainers to Cc (from kernel ``MAINTAINERS`` file):
|
||||
|
||||
* Alexei Starovoitov <ast@kernel.org>
|
||||
* Daniel Borkmann <daniel@iogearbox.net>
|
||||
|
|
@ -234,11 +234,11 @@ be subject to change.
|
|||
|
||||
Q: samples/bpf preference vs selftests?
|
||||
---------------------------------------
|
||||
Q: When should I add code to `samples/bpf/`_ and when to BPF kernel
|
||||
selftests_ ?
|
||||
Q: When should I add code to ``samples/bpf/`` and when to BPF kernel
|
||||
selftests_?
|
||||
|
||||
A: In general, we prefer additions to BPF kernel selftests_ rather than
|
||||
`samples/bpf/`_. The rationale is very simple: kernel selftests are
|
||||
``samples/bpf/``. The rationale is very simple: kernel selftests are
|
||||
regularly run by various bots to test for kernel regressions.
|
||||
|
||||
The more test cases we add to BPF selftests, the better the coverage
|
||||
|
|
@ -246,9 +246,9 @@ and the less likely it is that those could accidentally break. It is
|
|||
not that BPF kernel selftests cannot demo how a specific feature can
|
||||
be used.
|
||||
|
||||
That said, `samples/bpf/`_ may be a good place for people to get started,
|
||||
That said, ``samples/bpf/`` may be a good place for people to get started,
|
||||
so it might be advisable that simple demos of features could go into
|
||||
`samples/bpf/`_, but advanced functional and corner-case testing rather
|
||||
``samples/bpf/``, but advanced functional and corner-case testing rather
|
||||
into kernel selftests.
|
||||
|
||||
If your sample looks like a test case, then go for BPF kernel selftests
|
||||
|
|
@ -449,6 +449,19 @@ from source at
|
|||
|
||||
https://github.com/acmel/dwarves
|
||||
|
||||
pahole starts to use libbpf definitions and APIs since v1.13 after the
|
||||
commit 21507cd3e97b ("pahole: add libbpf as submodule under lib/bpf").
|
||||
It works well with the git repository because the libbpf submodule will
|
||||
use "git submodule update --init --recursive" to update.
|
||||
|
||||
Unfortunately, the default github release source code does not contain
|
||||
libbpf submodule source code and this will cause build issues, the tarball
|
||||
from https://git.kernel.org/pub/scm/devel/pahole/pahole.git/ is same with
|
||||
github, you can get the source tarball with corresponding libbpf submodule
|
||||
codes from
|
||||
|
||||
https://fedorapeople.org/~acme/dwarves
|
||||
|
||||
Some distros have pahole version 1.16 packaged already, e.g.
|
||||
Fedora, Gentoo.
|
||||
|
||||
|
|
@ -645,10 +658,9 @@ when:
|
|||
|
||||
.. Links
|
||||
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
|
||||
.. _MAINTAINERS: ../../MAINTAINERS
|
||||
.. _netdev-FAQ: ../networking/netdev-FAQ.rst
|
||||
.. _samples/bpf/: ../../samples/bpf/
|
||||
.. _selftests: ../../tools/testing/selftests/bpf/
|
||||
.. _selftests:
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/
|
||||
.. _Documentation/dev-tools/kselftest.rst:
|
||||
https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
|
||||
.. _Documentation/bpf/btf.rst: btf.rst
|
||||
|
|
|
|||
|
|
@ -84,6 +84,7 @@ sequentially and type id is assigned to each recognized type starting from id
|
|||
#define BTF_KIND_FUNC_PROTO 13 /* Function Proto */
|
||||
#define BTF_KIND_VAR 14 /* Variable */
|
||||
#define BTF_KIND_DATASEC 15 /* Section */
|
||||
#define BTF_KIND_FLOAT 16 /* Floating point */
|
||||
|
||||
Note that the type section encodes debug info, not just pure types.
|
||||
``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram.
|
||||
|
|
@ -95,8 +96,8 @@ Each type contains the following common data::
|
|||
/* "info" bits arrangement
|
||||
* bits 0-15: vlen (e.g. # of struct's members)
|
||||
* bits 16-23: unused
|
||||
* bits 24-27: kind (e.g. int, ptr, array...etc)
|
||||
* bits 28-30: unused
|
||||
* bits 24-28: kind (e.g. int, ptr, array...etc)
|
||||
* bits 29-30: unused
|
||||
* bit 31: kind_flag, currently used by
|
||||
* struct, union and fwd
|
||||
*/
|
||||
|
|
@ -452,6 +453,18 @@ map definition.
|
|||
* ``offset``: the in-section offset of the variable
|
||||
* ``size``: the size of the variable in bytes
|
||||
|
||||
2.2.16 BTF_KIND_FLOAT
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
``struct btf_type`` encoding requirement:
|
||||
* ``name_off``: any valid offset
|
||||
* ``info.kind_flag``: 0
|
||||
* ``info.kind``: BTF_KIND_FLOAT
|
||||
* ``info.vlen``: 0
|
||||
* ``size``: the size of the float type in bytes: 2, 4, 8, 12 or 16.
|
||||
|
||||
No additional type data follow ``btf_type``.
|
||||
|
||||
3. BTF Kernel API
|
||||
*****************
|
||||
|
||||
|
|
|
|||
|
|
@ -12,9 +12,6 @@ BPF instruction-set.
|
|||
The Cilium project also maintains a `BPF and XDP Reference Guide`_
|
||||
that goes into great technical depth about the BPF Architecture.
|
||||
|
||||
The primary info for the bpf syscall is available in the `man-pages`_
|
||||
for `bpf(2)`_.
|
||||
|
||||
BPF Type Format (BTF)
|
||||
=====================
|
||||
|
||||
|
|
@ -35,6 +32,12 @@ Two sets of Questions and Answers (Q&A) are maintained.
|
|||
bpf_design_QA
|
||||
bpf_devel_QA
|
||||
|
||||
Syscall API
|
||||
===========
|
||||
|
||||
The primary info for the bpf syscall is available in the `man-pages`_
|
||||
for `bpf(2)`_. For more information about the userspace API, see
|
||||
Documentation/userspace-api/ebpf/index.rst.
|
||||
|
||||
Helper functions
|
||||
================
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ define rule_chkdt
|
|||
$(call cmd,mk_schema)
|
||||
endef
|
||||
|
||||
DT_DOCS = $(shell $(find_cmd) | sed -e 's|^$(srctree)/||')
|
||||
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_cmd)))
|
||||
|
||||
override DTC_FLAGS := \
|
||||
-Wno-avoid_unnecessary_addr_size \
|
||||
|
|
|
|||
|
|
@ -47,7 +47,6 @@ examples:
|
|||
|
||||
spi-max-frequency = <3125000>;
|
||||
spi-3wire;
|
||||
spi-cs-high;
|
||||
|
||||
reset-gpios = <&gpe 2 GPIO_ACTIVE_LOW>;
|
||||
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ maintainers:
|
|||
- Jiaxun Yang <jiaxun.yang@flygoat.com>
|
||||
|
||||
description: |
|
||||
This interrupt controller is found in the Loongson-3 family of chips as the primary
|
||||
package interrupt controller which can route local I/O interrupt to interrupt lines
|
||||
of cores.
|
||||
This interrupt controller is found in the Loongson-3 family of chips and
|
||||
Loongson-2K1000 chip, as the primary package interrupt controller which
|
||||
can route local I/O interrupt to interrupt lines of cores.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/interrupt-controller.yaml#
|
||||
|
|
@ -22,9 +22,17 @@ properties:
|
|||
oneOf:
|
||||
- const: loongson,liointc-1.0
|
||||
- const: loongson,liointc-1.0a
|
||||
- const: loongson,liointc-2.0
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: main
|
||||
- const: isr0
|
||||
- const: isr1
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
|
|
@ -69,6 +77,26 @@ required:
|
|||
|
||||
unevaluatedProperties: false
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- loongson,liointc-2.0
|
||||
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
minItems: 3
|
||||
|
||||
required:
|
||||
- reg-names
|
||||
|
||||
else:
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
examples:
|
||||
- |
|
||||
iointc: interrupt-controller@3ff01400 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,92 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/actions,owl-emac.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Actions Semi Owl SoCs Ethernet MAC Controller
|
||||
|
||||
maintainers:
|
||||
- Cristian Ciocaltea <cristian.ciocaltea@gmail.com>
|
||||
|
||||
description: |
|
||||
This Ethernet MAC is used on the Owl family of SoCs from Actions Semi.
|
||||
It provides the RMII and SMII interfaces and is compliant with the
|
||||
IEEE 802.3 CSMA/CD standard, supporting both half-duplex and full-duplex
|
||||
operation modes at 10/100 Mb/s data transfer rates.
|
||||
|
||||
allOf:
|
||||
- $ref: "ethernet-controller.yaml#"
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: actions,owl-emac
|
||||
- items:
|
||||
- enum:
|
||||
- actions,s500-emac
|
||||
- const: actions,owl-emac
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
clock-names:
|
||||
additionalItems: false
|
||||
items:
|
||||
- const: eth
|
||||
- const: rmii
|
||||
|
||||
resets:
|
||||
maxItems: 1
|
||||
|
||||
actions,ethcfg:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to the device containing custom config.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- resets
|
||||
- phy-mode
|
||||
- phy-handle
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/actions,s500-cmu.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/reset/actions,s500-reset.h>
|
||||
|
||||
ethernet@b0310000 {
|
||||
compatible = "actions,s500-emac", "actions,owl-emac";
|
||||
reg = <0xb0310000 0x10000>;
|
||||
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cmu 59 /*CLK_ETHERNET*/>, <&cmu CLK_RMII_REF>;
|
||||
clock-names = "eth", "rmii";
|
||||
resets = <&cmu RESET_ETHERNET>;
|
||||
phy-mode = "rmii";
|
||||
phy-handle = <ð_phy>;
|
||||
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
eth_phy: ethernet-phy@3 {
|
||||
reg = <0x3>;
|
||||
interrupt-parent = <&sirq>;
|
||||
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -22,10 +22,18 @@ properties:
|
|||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
description: RX interrupt
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
items:
|
||||
- description: RX interrupt
|
||||
- description: TX interrupt
|
||||
|
||||
interrupt-names:
|
||||
const: rx
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
items:
|
||||
- const: rx
|
||||
- const: tx
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
|
@ -43,6 +51,7 @@ examples:
|
|||
compatible = "brcm,bcm4908-enet";
|
||||
reg = <0x80002000 0x1000>;
|
||||
|
||||
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "rx";
|
||||
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
|
||||
<GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "rx", "tx";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,76 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/brcm,bcm6368-mdio-mux.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Broadcom BCM6368 MDIO bus multiplexer
|
||||
|
||||
maintainers:
|
||||
- Álvaro Fernández Rojas <noltari@gmail.com>
|
||||
|
||||
description:
|
||||
This MDIO bus multiplexer defines buses that could be internal as well as
|
||||
external to SoCs. When child bus is selected, one needs to select these two
|
||||
properties as well to generate desired MDIO transaction on appropriate bus.
|
||||
|
||||
allOf:
|
||||
- $ref: "mdio.yaml#"
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: brcm,bcm6368-mdio-mux
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
patternProperties:
|
||||
'^mdio@[0-1]$':
|
||||
type: object
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- reg
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
mdio0: mdio@10e000b0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "brcm,bcm6368-mdio-mux";
|
||||
reg = <0x10e000b0 0x6>;
|
||||
|
||||
mdio_int: mdio@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
mdio_ext: mdio@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,56 +0,0 @@
|
|||
Broadcom Bluetooth Chips
|
||||
---------------------
|
||||
|
||||
This documents the binding structure and common properties for serial
|
||||
attached Broadcom devices.
|
||||
|
||||
Serial attached Broadcom devices shall be a child node of the host UART
|
||||
device the slave device is attached to.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should contain one of the following:
|
||||
* "brcm,bcm20702a1"
|
||||
* "brcm,bcm4329-bt"
|
||||
* "brcm,bcm4330-bt"
|
||||
* "brcm,bcm43438-bt"
|
||||
* "brcm,bcm4345c5"
|
||||
* "brcm,bcm43540-bt"
|
||||
* "brcm,bcm4335a0"
|
||||
|
||||
Optional properties:
|
||||
|
||||
- max-speed: see Documentation/devicetree/bindings/serial/serial.yaml
|
||||
- shutdown-gpios: GPIO specifier, used to enable the BT module
|
||||
- device-wakeup-gpios: GPIO specifier, used to wakeup the controller
|
||||
- host-wakeup-gpios: GPIO specifier, used to wakeup the host processor.
|
||||
deprecated, replaced by interrupts and
|
||||
"host-wakeup" interrupt-names
|
||||
- clocks: 1 or 2 clocks as defined in clock-names below, in that order
|
||||
- clock-names: names for clock inputs, matching the clocks given
|
||||
- "extclk": deprecated, replaced by "txco"
|
||||
- "txco": external reference clock (not a standalone crystal)
|
||||
- "lpo": external low power 32.768 kHz clock
|
||||
- vbat-supply: phandle to regulator supply for VBAT
|
||||
- vddio-supply: phandle to regulator supply for VDDIO
|
||||
- brcm,bt-pcm-int-params: configure PCM parameters via a 5-byte array
|
||||
- sco-routing: 0 = PCM, 1 = Transport, 2 = Codec, 3 = I2S
|
||||
- pcm-interface-rate: 128KBps, 256KBps, 512KBps, 1024KBps, 2048KBps
|
||||
- pcm-frame-type: short, long
|
||||
- pcm-sync-mode: slave, master
|
||||
- pcm-clock-mode: slave, master
|
||||
- interrupts: must be one, used to wakeup the host processor
|
||||
- interrupt-names: must be "host-wakeup"
|
||||
|
||||
Example:
|
||||
|
||||
&uart2 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&uart2_pins>;
|
||||
|
||||
bluetooth {
|
||||
compatible = "brcm,bcm43438-bt";
|
||||
max-speed = <921600>;
|
||||
brcm,bt-pcm-int-params = [01 02 00 01 01];
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,118 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/broadcom-bluetooth.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Broadcom Bluetooth Chips
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
|
||||
description:
|
||||
This binding describes Broadcom UART-attached bluetooth chips.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- brcm,bcm20702a1
|
||||
- brcm,bcm4329-bt
|
||||
- brcm,bcm4330-bt
|
||||
- brcm,bcm4334-bt
|
||||
- brcm,bcm43438-bt
|
||||
- brcm,bcm4345c5
|
||||
- brcm,bcm43540-bt
|
||||
- brcm,bcm4335a0
|
||||
|
||||
shutdown-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO specifier for the line BT_REG_ON used to
|
||||
power on the BT module
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO specifier for the line BT_RST_N used to
|
||||
reset the BT module. This should be marked as
|
||||
GPIO_ACTIVE_LOW.
|
||||
|
||||
device-wakeup-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO specifier for the line BT_WAKE used to
|
||||
wakeup the controller. This is using the BT_GPIO_0
|
||||
pin on the chip when in use.
|
||||
|
||||
host-wakeup-gpios:
|
||||
maxItems: 1
|
||||
deprecated: true
|
||||
description: GPIO specifier for the line HOST_WAKE used
|
||||
to wakeup the host processor. This is using he BT_GPIO_1
|
||||
pin on the chip when in use. This is deprecated and replaced
|
||||
by interrupts and "host-wakeup" interrupt-names
|
||||
|
||||
clocks:
|
||||
maxItems: 2
|
||||
description: 1 or 2 clocks as defined in clock-names below,
|
||||
in that order
|
||||
|
||||
clock-names:
|
||||
description: Names of the 1 to 2 supplied clocks
|
||||
items:
|
||||
- const: txco
|
||||
- const: lpo
|
||||
- const: extclk
|
||||
|
||||
vbat-supply:
|
||||
description: phandle to regulator supply for VBAT
|
||||
|
||||
vddio-supply:
|
||||
description: phandle to regulator supply for VDDIO
|
||||
|
||||
brcm,bt-pcm-int-params:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
minItems: 5
|
||||
maxItems: 5
|
||||
description: |-
|
||||
configure PCM parameters via a 5-byte array:
|
||||
sco-routing: 0 = PCM, 1 = Transport, 2 = Codec, 3 = I2S
|
||||
pcm-interface-rate: 128KBps, 256KBps, 512KBps, 1024KBps, 2048KBps
|
||||
pcm-frame-type: short, long
|
||||
pcm-sync-mode: slave, master
|
||||
pcm-clock-mode: slave, master
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: Handle to the line HOST_WAKE used to wake
|
||||
up the host processor. This uses the BT_GPIO_1 pin on
|
||||
the chip when in use.
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: host-wakeup
|
||||
|
||||
max-speed: true
|
||||
current-speed: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
uart {
|
||||
uart-has-rtscts;
|
||||
|
||||
bluetooth {
|
||||
compatible = "brcm,bcm4330-bt";
|
||||
max-speed = <921600>;
|
||||
brcm,bt-pcm-int-params = [01 02 00 01 01];
|
||||
shutdown-gpios = <&gpio 30 GPIO_ACTIVE_HIGH>;
|
||||
device-wakeup-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
|
||||
reset-gpios = <&gpio 9 GPIO_ACTIVE_LOW>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
|
||||
};
|
||||
};
|
||||
|
|
@ -19,7 +19,8 @@ Required properties:
|
|||
"renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC.
|
||||
"renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC.
|
||||
"renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC.
|
||||
"renesas,can-r8a7796" if CAN controller is a part of R8A7796 SoC.
|
||||
"renesas,can-r8a7796" if CAN controller is a part of R8A77960 SoC.
|
||||
"renesas,can-r8a77961" if CAN controller is a part of R8A77961 SoC.
|
||||
"renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC.
|
||||
"renesas,can-r8a77990" if CAN controller is a part of R8A77990 SoC.
|
||||
"renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC.
|
||||
|
|
@ -40,7 +41,7 @@ Required properties:
|
|||
- pinctrl-names: must be "default".
|
||||
|
||||
Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795,
|
||||
R8A7796, R8A77965, R8A77990, and R8A77995:
|
||||
R8A77960, R8A77961, R8A77965, R8A77990, and R8A77995:
|
||||
For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can
|
||||
be used by both CAN and CAN FD controller at the same time. It needs to be
|
||||
scaled to maximum frequency if any of these controllers use it. This is done
|
||||
|
|
|
|||
|
|
@ -70,6 +70,15 @@ patternProperties:
|
|||
device is what the switch port is connected to
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
dsa-tag-protocol:
|
||||
description:
|
||||
Instead of the default, the switch will use this tag protocol if
|
||||
possible. Useful when a device supports multiple protcols and
|
||||
the default is incompatible with the Ethernet device.
|
||||
enum:
|
||||
- dsa
|
||||
- edsa
|
||||
|
||||
phy-handle: true
|
||||
|
||||
phy-mode: true
|
||||
|
|
|
|||
|
|
@ -5,6 +5,10 @@ Required properties for GSWIP core:
|
|||
|
||||
- compatible : "lantiq,xrx200-gswip" for the embedded GSWIP in the
|
||||
xRX200 SoC
|
||||
"lantiq,xrx300-gswip" for the embedded GSWIP in the
|
||||
xRX300 SoC
|
||||
"lantiq,xrx330-gswip" for the embedded GSWIP in the
|
||||
xRX330 SoC
|
||||
- reg : memory range of the GSWIP core registers
|
||||
: memory range of the GSWIP MDIO registers
|
||||
: memory range of the GSWIP MII registers
|
||||
|
|
|
|||
|
|
@ -21,6 +21,8 @@ properties:
|
|||
- microchip,ksz8765
|
||||
- microchip,ksz8794
|
||||
- microchip,ksz8795
|
||||
- microchip,ksz8863
|
||||
- microchip,ksz8873
|
||||
- microchip,ksz9477
|
||||
- microchip,ksz9897
|
||||
- microchip,ksz9896
|
||||
|
|
|
|||
|
|
@ -102,3 +102,18 @@ Example:
|
|||
full-duplex;
|
||||
};
|
||||
};
|
||||
|
||||
* Integrated Endpoint Register Block bindings
|
||||
|
||||
Optionally, the fsl_enetc driver can probe on the Integrated Endpoint Register
|
||||
Block, which preconfigures the FIFO limits for the ENETC ports. This is a node
|
||||
with the following properties:
|
||||
|
||||
- reg : Specifies the address in the SoC memory space.
|
||||
- compatible : Must be "fsl,ls1028a-enetc-ierb".
|
||||
|
||||
Example:
|
||||
ierb@1f0800000 {
|
||||
compatible = "fsl,ls1028a-enetc-ierb";
|
||||
reg = <0x01 0xf0800000 0x0 0x10000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/idt,3243x-emac.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: IDT 79rc3243x Ethernet controller
|
||||
|
||||
description: Ethernet controller integrated into IDT 79RC3243x family SoCs
|
||||
|
||||
maintainers:
|
||||
- Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
||||
|
||||
allOf:
|
||||
- $ref: ethernet-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: idt,3243x-emac
|
||||
|
||||
reg:
|
||||
maxItems: 3
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: emac
|
||||
- const: dma_rx
|
||||
- const: dma_tx
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: RX interrupt
|
||||
- description: TX interrupt
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: rx
|
||||
- const: tx
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: mdioclk
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- reg-names
|
||||
- interrupts
|
||||
- interrupt-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
||||
ethernet@60000 {
|
||||
compatible = "idt,3243x-emac";
|
||||
|
||||
reg = <0x60000 0x10000>,
|
||||
<0x40000 0x14>,
|
||||
<0x40014 0x14>;
|
||||
reg-names = "emac", "dma_rx", "dma_tx";
|
||||
|
||||
interrupt-parent = <&rcpic3>;
|
||||
interrupts = <0>, <1>;
|
||||
interrupt-names = "rx", "tx";
|
||||
|
||||
clocks = <&iclk>;
|
||||
clock-names = "mdioclk";
|
||||
};
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
# Copyright 2018 Linaro Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/net/intel,ixp4xx-ethernet.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Intel IXP4xx ethernet
|
||||
|
||||
allOf:
|
||||
- $ref: "ethernet-controller.yaml#"
|
||||
|
||||
maintainers:
|
||||
- Linus Walleij <linus.walleij@linaro.org>
|
||||
|
||||
description: |
|
||||
The Intel IXP4xx ethernet makes use of the IXP4xx NPE (Network
|
||||
Processing Engine) and the IXP4xx Queue Manager to process
|
||||
the ethernet frames. It can optionally contain an MDIO bus to
|
||||
talk to PHYs.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: intel,ixp4xx-ethernet
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: Ethernet MMIO address range
|
||||
|
||||
queue-rx:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
maxItems: 1
|
||||
description: phandle to the RX queue on the NPE
|
||||
|
||||
queue-txready:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
maxItems: 1
|
||||
description: phandle to the TX READY queue on the NPE
|
||||
|
||||
phy-mode: true
|
||||
|
||||
phy-handle: true
|
||||
|
||||
intel,npe-handle:
|
||||
$ref: '/schemas/types.yaml#/definitions/phandle-array'
|
||||
maxItems: 1
|
||||
description: phandle to the NPE this ethernet instance is using
|
||||
and the instance to use in the second cell
|
||||
|
||||
mdio:
|
||||
type: object
|
||||
$ref: "mdio.yaml#"
|
||||
description: optional node for embedded MDIO controller
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- queue-rx
|
||||
- queue-txready
|
||||
- intel,npe-handle
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
npe: npe@c8006000 {
|
||||
compatible = "intel,ixp4xx-network-processing-engine";
|
||||
reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>;
|
||||
};
|
||||
|
||||
ethernet@c8009000 {
|
||||
compatible = "intel,ixp4xx-ethernet";
|
||||
reg = <0xc8009000 0x1000>;
|
||||
status = "disabled";
|
||||
queue-rx = <&qmgr 4>;
|
||||
queue-txready = <&qmgr 21>;
|
||||
intel,npe-handle = <&npe 1>;
|
||||
phy-mode = "rgmii";
|
||||
phy-handle = <&phy1>;
|
||||
};
|
||||
|
||||
ethernet@c800c000 {
|
||||
compatible = "intel,ixp4xx-ethernet";
|
||||
reg = <0xc800c000 0x1000>;
|
||||
status = "disabled";
|
||||
queue-rx = <&qmgr 3>;
|
||||
queue-txready = <&qmgr 20>;
|
||||
intel,npe-handle = <&npe 2>;
|
||||
phy-mode = "rgmii";
|
||||
phy-handle = <&phy2>;
|
||||
|
||||
mdio {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
phy1: ethernet-phy@1 {
|
||||
reg = <1>;
|
||||
};
|
||||
phy2: ethernet-phy@2 {
|
||||
reg = <2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -2,6 +2,7 @@ MDIO on GPIOs
|
|||
|
||||
Currently defined compatibles:
|
||||
- virtual,gpio-mdio
|
||||
- microchip,mdio-smi0
|
||||
|
||||
MDC and MDIO lines connected to GPIO controllers are listed in the
|
||||
gpios property as described in section VIII.1 in the following order:
|
||||
|
|
|
|||
|
|
@ -43,7 +43,12 @@ description:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
const: "qcom,sdm845-ipa"
|
||||
enum:
|
||||
- qcom,sc7180-ipa
|
||||
- qcom,sc7280-ipa
|
||||
- qcom,sdm845-ipa
|
||||
- qcom,sdx55-ipa
|
||||
- qcom,sm8350-ipa
|
||||
|
||||
reg:
|
||||
items:
|
||||
|
|
@ -120,6 +125,14 @@ properties:
|
|||
the firmware passed to Trust Zone for authentication. Required
|
||||
when Trust Zone (not the modem) performs early initialization.
|
||||
|
||||
firmware-name:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description:
|
||||
If present, name (or relative path) of the file within the
|
||||
firmware search path containing the firmware image used when
|
||||
initializing IPA hardware. Optional, and only used when
|
||||
Trust Zone performs early initialization.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- iommus
|
||||
|
|
@ -129,12 +142,23 @@ required:
|
|||
- interconnects
|
||||
- qcom,smem-states
|
||||
|
||||
# Either modem-init is present, or memory-region must be present.
|
||||
oneOf:
|
||||
- required:
|
||||
- modem-init
|
||||
- required:
|
||||
- memory-region
|
||||
|
||||
# If memory-region is present, firmware-name may optionally be present.
|
||||
# But if modem-init is present, firmware-name must not be present.
|
||||
if:
|
||||
required:
|
||||
- modem-init
|
||||
then:
|
||||
not:
|
||||
required:
|
||||
- firmware-name
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
|
|
|||
|
|
@ -50,7 +50,16 @@ properties:
|
|||
interrupt-names: true
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
items:
|
||||
- description: AVB functional clock
|
||||
- description: Optional TXC reference clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: fck
|
||||
- const: refclk
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -1,76 +0,0 @@
|
|||
Rockchip SoC RK3288 10/100/1000 Ethernet driver(GMAC)
|
||||
|
||||
The device node has following properties.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "rockchip,<name>-gamc"
|
||||
"rockchip,px30-gmac": found on PX30 SoCs
|
||||
"rockchip,rk3128-gmac": found on RK312x SoCs
|
||||
"rockchip,rk3228-gmac": found on RK322x SoCs
|
||||
"rockchip,rk3288-gmac": found on RK3288 SoCs
|
||||
"rockchip,rk3328-gmac": found on RK3328 SoCs
|
||||
"rockchip,rk3366-gmac": found on RK3366 SoCs
|
||||
"rockchip,rk3368-gmac": found on RK3368 SoCs
|
||||
"rockchip,rk3399-gmac": found on RK3399 SoCs
|
||||
"rockchip,rv1108-gmac": found on RV1108 SoCs
|
||||
- reg: addresses and length of the register sets for the device.
|
||||
- interrupts: Should contain the GMAC interrupts.
|
||||
- interrupt-names: Should contain the interrupt names "macirq".
|
||||
- rockchip,grf: phandle to the syscon grf used to control speed and mode.
|
||||
- clocks: <&cru SCLK_MAC>: clock selector for main clock, from PLL or PHY.
|
||||
<&cru SCLK_MAC_PLL>: PLL clock for SCLK_MAC
|
||||
<&cru SCLK_MAC_RX>: clock gate for RX
|
||||
<&cru SCLK_MAC_TX>: clock gate for TX
|
||||
<&cru SCLK_MACREF>: clock gate for RMII referce clock
|
||||
<&cru SCLK_MACREF_OUT> clock gate for RMII reference clock output
|
||||
<&cru ACLK_GMAC>: AXI clock gate for GMAC
|
||||
<&cru PCLK_GMAC>: APB clock gate for GMAC
|
||||
- clock-names: One name for each entry in the clocks property.
|
||||
- phy-mode: See ethernet.txt file in the same directory.
|
||||
- pinctrl-names: Names corresponding to the numbered pinctrl states.
|
||||
- pinctrl-0: pin-control mode. can be <&rgmii_pins> or <&rmii_pins>.
|
||||
- clock_in_out: For RGMII, it must be "input", means main clock(125MHz)
|
||||
is not sourced from SoC's PLL, but input from PHY; For RMII, "input" means
|
||||
PHY provides the reference clock(50MHz), "output" means GMAC provides the
|
||||
reference clock.
|
||||
- snps,reset-gpio gpio number for phy reset.
|
||||
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
|
||||
- assigned-clocks: main clock, should be <&cru SCLK_MAC>;
|
||||
- assigned-clock-parents = parent of main clock.
|
||||
can be <&ext_gmac> or <&cru SCLK_MAC_PLL>.
|
||||
|
||||
Optional properties:
|
||||
- tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default.
|
||||
- rx_delay: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as default.
|
||||
- phy-supply: phandle to a regulator if the PHY needs one
|
||||
|
||||
Example:
|
||||
|
||||
gmac: ethernet@ff290000 {
|
||||
compatible = "rockchip,rk3288-gmac";
|
||||
reg = <0xff290000 0x10000>;
|
||||
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "macirq";
|
||||
rockchip,grf = <&grf>;
|
||||
clocks = <&cru SCLK_MAC>,
|
||||
<&cru SCLK_MAC_RX>, <&cru SCLK_MAC_TX>,
|
||||
<&cru SCLK_MACREF>, <&cru SCLK_MACREF_OUT>,
|
||||
<&cru ACLK_GMAC>, <&cru PCLK_GMAC>;
|
||||
clock-names = "stmmaceth",
|
||||
"mac_clk_rx", "mac_clk_tx",
|
||||
"clk_mac_ref", "clk_mac_refout",
|
||||
"aclk_mac", "pclk_mac";
|
||||
phy-mode = "rgmii";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&rgmii_pins /*&rmii_pins*/>;
|
||||
|
||||
clock_in_out = "input";
|
||||
snps,reset-gpio = <&gpio4 7 0>;
|
||||
snps,reset-active-low;
|
||||
|
||||
assigned-clocks = <&cru SCLK_MAC>;
|
||||
assigned-clock-parents = <&ext_gmac>;
|
||||
tx_delay = <0x30>;
|
||||
rx_delay = <0x10>;
|
||||
|
||||
};
|
||||
|
|
@ -0,0 +1,120 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/net/rockchip-dwmac.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Rockchip 10/100/1000 Ethernet driver(GMAC)
|
||||
|
||||
maintainers:
|
||||
- David Wu <david.wu@rock-chips.com>
|
||||
|
||||
# We need a select here so we don't match all nodes with 'snps,dwmac'
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- rockchip,px30-gmac
|
||||
- rockchip,rk3128-gmac
|
||||
- rockchip,rk3228-gmac
|
||||
- rockchip,rk3288-gmac
|
||||
- rockchip,rk3328-gmac
|
||||
- rockchip,rk3366-gmac
|
||||
- rockchip,rk3368-gmac
|
||||
- rockchip,rk3399-gmac
|
||||
- rockchip,rv1108-gmac
|
||||
required:
|
||||
- compatible
|
||||
|
||||
allOf:
|
||||
- $ref: "snps,dwmac.yaml#"
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- rockchip,px30-gmac
|
||||
- rockchip,rk3128-gmac
|
||||
- rockchip,rk3228-gmac
|
||||
- rockchip,rk3288-gmac
|
||||
- rockchip,rk3328-gmac
|
||||
- rockchip,rk3366-gmac
|
||||
- rockchip,rk3368-gmac
|
||||
- rockchip,rk3399-gmac
|
||||
- rockchip,rv1108-gmac
|
||||
|
||||
clocks:
|
||||
minItems: 5
|
||||
maxItems: 8
|
||||
|
||||
clock-names:
|
||||
contains:
|
||||
enum:
|
||||
- stmmaceth
|
||||
- mac_clk_tx
|
||||
- mac_clk_rx
|
||||
- aclk_mac
|
||||
- pclk_mac
|
||||
- clk_mac_ref
|
||||
- clk_mac_refout
|
||||
- clk_mac_speed
|
||||
|
||||
clock_in_out:
|
||||
description:
|
||||
For RGMII, it must be "input", means main clock(125MHz)
|
||||
is not sourced from SoC's PLL, but input from PHY.
|
||||
For RMII, "input" means PHY provides the reference clock(50MHz),
|
||||
"output" means GMAC provides the reference clock.
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
enum: [input, output]
|
||||
|
||||
rockchip,grf:
|
||||
description: The phandle of the syscon node for the general register file.
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
tx_delay:
|
||||
description: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as default.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
rx_delay:
|
||||
description: Delay value for RXD timing. Range value is 0~0x7F, 0x10 as default.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
phy-supply:
|
||||
description: PHY regulator
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/rk3288-cru.h>
|
||||
|
||||
gmac: ethernet@ff290000 {
|
||||
compatible = "rockchip,rk3288-gmac";
|
||||
reg = <0xff290000 0x10000>;
|
||||
interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "macirq";
|
||||
clocks = <&cru SCLK_MAC>,
|
||||
<&cru SCLK_MAC_RX>, <&cru SCLK_MAC_TX>,
|
||||
<&cru SCLK_MACREF>, <&cru SCLK_MACREF_OUT>,
|
||||
<&cru ACLK_GMAC>, <&cru PCLK_GMAC>;
|
||||
clock-names = "stmmaceth",
|
||||
"mac_clk_rx", "mac_clk_tx",
|
||||
"clk_mac_ref", "clk_mac_refout",
|
||||
"aclk_mac", "pclk_mac";
|
||||
assigned-clocks = <&cru SCLK_MAC>;
|
||||
assigned-clock-parents = <&ext_gmac>;
|
||||
|
||||
rockchip,grf = <&grf>;
|
||||
phy-mode = "rgmii";
|
||||
clock_in_out = "input";
|
||||
tx_delay = <0x30>;
|
||||
rx_delay = <0x10>;
|
||||
};
|
||||
|
|
@ -56,6 +56,15 @@ properties:
|
|||
- amlogic,meson8m2-dwmac
|
||||
- amlogic,meson-gxbb-dwmac
|
||||
- amlogic,meson-axg-dwmac
|
||||
- rockchip,px30-gmac
|
||||
- rockchip,rk3128-gmac
|
||||
- rockchip,rk3228-gmac
|
||||
- rockchip,rk3288-gmac
|
||||
- rockchip,rk3328-gmac
|
||||
- rockchip,rk3366-gmac
|
||||
- rockchip,rk3368-gmac
|
||||
- rockchip,rk3399-gmac
|
||||
- rockchip,rv1108-gmac
|
||||
- snps,dwmac
|
||||
- snps,dwmac-3.50a
|
||||
- snps,dwmac-3.610
|
||||
|
|
@ -89,7 +98,7 @@ properties:
|
|||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 5
|
||||
maxItems: 8
|
||||
additionalItems: true
|
||||
items:
|
||||
- description: GMAC main clock
|
||||
|
|
@ -101,7 +110,7 @@ properties:
|
|||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 5
|
||||
maxItems: 8
|
||||
additionalItems: true
|
||||
contains:
|
||||
enum:
|
||||
|
|
|
|||
|
|
@ -1,24 +0,0 @@
|
|||
Common IEEE 802.11 properties
|
||||
|
||||
This provides documentation of common properties that are valid for all wireless
|
||||
devices.
|
||||
|
||||
Optional properties:
|
||||
- ieee80211-freq-limit : list of supported frequency ranges in KHz. This can be
|
||||
used for devices that in a given config support less channels than
|
||||
normally. It may happen chipset supports a wide wireless band but it is
|
||||
limited to some part of it due to used antennas or power amplifier.
|
||||
An example case for this can be tri-band wireless router with two
|
||||
identical chipsets used for two different 5 GHz subbands. Using them
|
||||
incorrectly could not work or decrease performance noticeably.
|
||||
|
||||
Example:
|
||||
|
||||
pcie@0,0 {
|
||||
reg = <0x0000 0 0 0 0>;
|
||||
wifi@0,0 {
|
||||
reg = <0x0000 0 0 0 0>;
|
||||
ieee80211-freq-limit = <2402000 2482000>,
|
||||
<5170000 5250000>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
|
||||
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/wireless/ieee80211.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Common IEEE 802.11 Binding
|
||||
|
||||
maintainers:
|
||||
- Lorenzo Bianconi <lorenzo@kernel.org>
|
||||
|
||||
description: |
|
||||
This provides documentation of common properties that are valid for
|
||||
all wireless devices
|
||||
|
||||
properties:
|
||||
ieee80211-freq-limit:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
items:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
description:
|
||||
List of supported frequency ranges in KHz. This can be used for devices
|
||||
that in a given config support less channels than normally. It may happen
|
||||
chipset supports a wide wireless band but it is limited to some part of
|
||||
it due to used antennas or power amplifier. An example case for this
|
||||
can be tri-band wireless router with two identical chipsets used for two
|
||||
different 5 GHz subbands. Using them incorrectly could not work or
|
||||
decrease performance noticeably
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
examples:
|
||||
- |
|
||||
pcie0 {
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
wifi@0,0 {
|
||||
reg = <0x0000 0 0 0 0>;
|
||||
ieee80211-freq-limit = <2402000 2482000>,
|
||||
<5170000 5250000>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
* MediaTek mt76xx devices
|
||||
|
||||
This node provides properties for configuring the MediaTek mt76xx wireless
|
||||
device. The node is expected to be specified as a child node of the PCI
|
||||
controller to which the wireless chip is connected.
|
||||
|
||||
Alternatively, it can specify the wireless part of the MT7628/MT7688 or
|
||||
MT7622 SoC. For SoC, use the following compatible strings:
|
||||
|
||||
compatible:
|
||||
- "mediatek,mt7628-wmac" for MT7628/MT7688
|
||||
- "mediatek,mt7622-wmac" for MT7622
|
||||
|
||||
properties:
|
||||
- reg: Address and length of the register set for the device.
|
||||
- interrupts: Main device interrupt
|
||||
|
||||
MT7622 specific properties:
|
||||
- power-domains: phandle to the power domain that the WMAC is part of
|
||||
- mediatek,infracfg: phandle to the infrastructure bus fabric syscon node
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ieee80211-freq-limit: See ieee80211.txt
|
||||
- mediatek,mtd-eeprom: Specify a MTD partition + offset containing EEPROM data
|
||||
- big-endian: if the radio eeprom partition is written in big-endian, specify
|
||||
this property
|
||||
- mediatek,eeprom-merge-otp: Merge EEPROM data with OTP data. Can be used on
|
||||
boards where the flash calibration data is generic and specific calibration
|
||||
data should be pulled from the OTP ROM
|
||||
|
||||
The MAC address can as well be set with corresponding optional properties
|
||||
defined in net/ethernet.txt.
|
||||
|
||||
Optional nodes:
|
||||
- led: Properties for a connected LED
|
||||
Optional properties:
|
||||
- led-sources: See Documentation/devicetree/bindings/leds/common.txt
|
||||
|
||||
&pcie {
|
||||
pcie0 {
|
||||
wifi@0,0 {
|
||||
compatible = "mediatek,mt76";
|
||||
reg = <0x0000 0 0 0 0>;
|
||||
ieee80211-freq-limit = <5000000 6000000>;
|
||||
mediatek,mtd-eeprom = <&factory 0x8000>;
|
||||
big-endian;
|
||||
|
||||
led {
|
||||
led-sources = <2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
MT7628 example:
|
||||
|
||||
wmac: wmac@10300000 {
|
||||
compatible = "mediatek,mt7628-wmac";
|
||||
reg = <0x10300000 0x100000>;
|
||||
|
||||
interrupt-parent = <&cpuintc>;
|
||||
interrupts = <6>;
|
||||
|
||||
mediatek,mtd-eeprom = <&factory 0x0000>;
|
||||
};
|
||||
|
||||
MT7622 example:
|
||||
|
||||
wmac: wmac@18000000 {
|
||||
compatible = "mediatek,mt7622-wmac";
|
||||
reg = <0 0x18000000 0 0x100000>;
|
||||
interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
mediatek,infracfg = <&infracfg>;
|
||||
|
||||
power-domains = <&scpsys MT7622_POWER_DOMAIN_WB>;
|
||||
};
|
||||
|
|
@ -0,0 +1,228 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright (c) 2018-2019 The Linux Foundation. All rights reserved.
|
||||
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/net/wireless/mediatek,mt76.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek mt76 wireless devices Generic Binding
|
||||
|
||||
maintainers:
|
||||
- Felix Fietkau <nbd@nbd.name>
|
||||
- Lorenzo Bianconi <lorenzo@kernel.org>
|
||||
- Ryder Lee <ryder.lee@mediatek.com>
|
||||
|
||||
description: |
|
||||
This node provides properties for configuring the MediaTek mt76xx
|
||||
wireless device. The node is expected to be specified as a child
|
||||
node of the PCI controller to which the wireless chip is connected.
|
||||
Alternatively, it can specify the wireless part of the MT7628/MT7688
|
||||
or MT7622 SoC.
|
||||
|
||||
allOf:
|
||||
- $ref: ieee80211.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- mediatek,mt76
|
||||
- mediatek,mt7628-wmac
|
||||
- mediatek,mt7622-wmac
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
mediatek,infracfg:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Phandle to the infrastructure bus fabric syscon node.
|
||||
This property is MT7622 specific
|
||||
|
||||
ieee80211-freq-limit: true
|
||||
|
||||
mediatek,mtd-eeprom:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
Phandle to a MTD partition + offset containing EEPROM data
|
||||
|
||||
big-endian:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
description:
|
||||
Specify if the radio eeprom partition is written in big-endian
|
||||
|
||||
mediatek,eeprom-merge-otp:
|
||||
type: boolean
|
||||
description:
|
||||
Merge EEPROM data with OTP data. Can be used on boards where the flash
|
||||
calibration data is generic and specific calibration data should be
|
||||
pulled from the OTP ROM
|
||||
|
||||
led:
|
||||
type: object
|
||||
$ref: /schemas/leds/common.yaml#
|
||||
additionalProperties: false
|
||||
properties:
|
||||
led-sources:
|
||||
maxItems: 1
|
||||
|
||||
power-limits:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
patternProperties:
|
||||
"^r[0-9]+":
|
||||
type: object
|
||||
additionalProperties: false
|
||||
properties:
|
||||
regdomain:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description:
|
||||
Regdomain refers to a legal regulatory region. Different
|
||||
countries define different levels of allowable transmitter
|
||||
power, time that a channel can be occupied, and different
|
||||
available channels
|
||||
enum:
|
||||
- FCC
|
||||
- ETSI
|
||||
- JP
|
||||
|
||||
patternProperties:
|
||||
"^txpower-[256]g$":
|
||||
type: object
|
||||
additionalProperties: false
|
||||
patternProperties:
|
||||
"^b[0-9]+$":
|
||||
type: object
|
||||
additionalProperties: false
|
||||
properties:
|
||||
channels:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
description:
|
||||
Pairs of first and last channel number of the selected
|
||||
band
|
||||
|
||||
rates-cck:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
minItems: 4
|
||||
maxItems: 4
|
||||
description:
|
||||
4 half-dBm per-rate power limit values
|
||||
|
||||
rates-ofdm:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-array
|
||||
minItems: 8
|
||||
maxItems: 8
|
||||
description:
|
||||
8 half-dBm per-rate power limit values
|
||||
|
||||
rates-mcs:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-matrix
|
||||
description:
|
||||
Sets of per-rate power limit values for 802.11n/802.11ac
|
||||
rates for multiple channel bandwidth settings.
|
||||
Each set starts with the number of channel bandwidth
|
||||
settings for which the rate set applies, followed by
|
||||
either 8 or 10 power limit values. The order of the
|
||||
channel bandwidth settings is 20, 40, 80 and 160 MHz.
|
||||
maxItems: 4
|
||||
items:
|
||||
minItems: 9
|
||||
maxItems: 11
|
||||
|
||||
rates-ru:
|
||||
$ref: /schemas/types.yaml#/definitions/uint8-matrix
|
||||
description:
|
||||
Sets of per-rate power limit values for 802.11ax rates
|
||||
for multiple channel bandwidth or resource unit settings.
|
||||
Each set starts with the number of channel bandwidth or
|
||||
resource unit settings for which the rate set applies,
|
||||
followed by 12 power limit values. The order of the
|
||||
channel resource unit settings is RU26, RU52, RU106,
|
||||
RU242/SU20, RU484/SU40, RU996/SU80 and RU2x996/SU160.
|
||||
items:
|
||||
minItems: 13
|
||||
maxItems: 13
|
||||
|
||||
txs-delta:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
description:
|
||||
Half-dBm power delta for different numbers of antennas
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
pcie0 {
|
||||
#address-cells = <3>;
|
||||
#size-cells = <2>;
|
||||
wifi@0,0 {
|
||||
compatible = "mediatek,mt76";
|
||||
reg = <0x0000 0 0 0 0>;
|
||||
ieee80211-freq-limit = <5000000 6000000>;
|
||||
mediatek,mtd-eeprom = <&factory 0x8000>;
|
||||
big-endian;
|
||||
|
||||
led {
|
||||
led-sources = <2>;
|
||||
};
|
||||
|
||||
power-limits {
|
||||
r0 {
|
||||
regdomain = "FCC";
|
||||
txpower-5g {
|
||||
b0 {
|
||||
channels = <36 48>;
|
||||
rates-ofdm = /bits/ 8 <23 23 23 23 23 23 23 23>;
|
||||
rates-mcs = /bits/ 8 <1 23 23 23 23 23 23 23 23 23 23>,
|
||||
<3 22 22 22 22 22 22 22 22 22 22>;
|
||||
rates-ru = /bits/ 8 <3 22 22 22 22 22 22 22 22 22 22 22 22>,
|
||||
<4 20 20 20 20 20 20 20 20 20 20 20 20>;
|
||||
};
|
||||
b1 {
|
||||
channels = <100 181>;
|
||||
rates-ofdm = /bits/ 8 <14 14 14 14 14 14 14 14>;
|
||||
rates-mcs = /bits/ 8 <4 14 14 14 14 14 14 14 14 14 14>;
|
||||
txs-delta = <12 9 6>;
|
||||
rates-ru = /bits/ 8 <7 14 14 14 14 14 14 14 14 14 14 14 14>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
wifi@10300000 {
|
||||
compatible = "mediatek,mt7628-wmac";
|
||||
reg = <0x10300000 0x100000>;
|
||||
|
||||
interrupt-parent = <&cpuintc>;
|
||||
interrupts = <6>;
|
||||
|
||||
mediatek,mtd-eeprom = <&factory 0x0>;
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
wifi@18000000 {
|
||||
compatible = "mediatek,mt7622-wmac";
|
||||
reg = <0x10300000 0x100000>;
|
||||
interrupts = <GIC_SPI 211 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
mediatek,infracfg = <&infracfg>;
|
||||
|
||||
power-domains = <&scpsys 3>;
|
||||
};
|
||||
|
|
@ -42,11 +42,23 @@ Optional properties:
|
|||
support both 1000BaseX and SGMII modes. If set, the phy-mode
|
||||
should be set to match the mode selected on core reset (i.e.
|
||||
by the basex_or_sgmii core input line).
|
||||
- clocks : AXI bus clock for the device. Refer to common clock bindings.
|
||||
Used to calculate MDIO clock divisor. If not specified, it is
|
||||
auto-detected from the CPU clock (but only on platforms where
|
||||
this is possible). New device trees should specify this - the
|
||||
auto detection is only for backward compatibility.
|
||||
- clock-names: Tuple listing input clock names. Possible clocks:
|
||||
s_axi_lite_clk: Clock for AXI register slave interface
|
||||
axis_clk: AXI4-Stream clock for TXD RXD TXC and RXS interfaces
|
||||
ref_clk: Ethernet reference clock, used by signal delay
|
||||
primitives and transceivers
|
||||
mgt_clk: MGT reference clock (used by optional internal
|
||||
PCS/PMA PHY)
|
||||
|
||||
Note that if s_axi_lite_clk is not specified by name, the
|
||||
first clock of any name is used for this. If that is also not
|
||||
specified, the clock rate is auto-detected from the CPU clock
|
||||
(but only on platforms where this is possible). New device
|
||||
trees should specify all applicable clocks by name - the
|
||||
fallbacks to an unnamed clock or to CPU clock are only for
|
||||
backward compatibility.
|
||||
- clocks: Phandles to input clocks matching clock-names. Refer to common
|
||||
clock bindings.
|
||||
- axistream-connected: Reference to another node which contains the resources
|
||||
for the AXI DMA controller used by this device.
|
||||
If this is specified, the DMA-related resources from that
|
||||
|
|
@ -62,7 +74,8 @@ Example:
|
|||
device_type = "network";
|
||||
interrupt-parent = <µblaze_0_axi_intc>;
|
||||
interrupts = <2 0 1>;
|
||||
clocks = <&axi_clk>;
|
||||
clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
|
||||
clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
|
||||
phy-mode = "mii";
|
||||
reg = <0x40c00000 0x40000 0x50c00000 0x40000>;
|
||||
xlnx,rxcsum = <0x2>;
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ examples:
|
|||
bluetooth {
|
||||
compatible = "brcm,bcm4330-bt";
|
||||
reset-gpios = <&gpf 8 GPIO_ACTIVE_HIGH>;
|
||||
vcc-supply = <&wlan0_power>;
|
||||
vbat-supply = <&wlan0_power>;
|
||||
device-wakeup-gpios = <&gpf 5 GPIO_ACTIVE_HIGH>;
|
||||
host-wakeup-gpios = <&gpf 6 GPIO_ACTIVE_HIGH>;
|
||||
shutdown-gpios = <&gpf 4 GPIO_ACTIVE_LOW>;
|
||||
|
|
|
|||
|
|
@ -178,6 +178,7 @@ mktables
|
|||
mktree
|
||||
mkutf8data
|
||||
modpost
|
||||
modules-only.symvers
|
||||
modules.builtin
|
||||
modules.builtin.modinfo
|
||||
modules.nsdeps
|
||||
|
|
@ -252,6 +253,7 @@ vmlinux-*
|
|||
vmlinux.aout
|
||||
vmlinux.bin.all
|
||||
vmlinux.lds
|
||||
vmlinux.map
|
||||
vmlinux.symvers
|
||||
vmlinuz
|
||||
voffset.h
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig
|
||||
#
|
||||
# The recursive limitations with Kconfig has some non intuitive implications on
|
||||
# kconfig sematics which are documented here. One known practical implication
|
||||
# kconfig semantics which are documented here. One known practical implication
|
||||
# of the recursive limitation is that drivers cannot negate features from other
|
||||
# drivers if they share a common core requirement and use disjoint semantics to
|
||||
# annotate those requirements, ie, some drivers use "depends on" while others
|
||||
|
|
|
|||
|
|
@ -223,25 +223,10 @@ applicable everywhere (see syntax).
|
|||
the indentation level, this means it ends at the first line which has
|
||||
a smaller indentation than the first line of the help text.
|
||||
|
||||
- misc options: "option" <symbol>[=<value>]
|
||||
|
||||
Various less common options can be defined via this option syntax,
|
||||
which can modify the behaviour of the menu entry and its config
|
||||
symbol. These options are currently possible:
|
||||
|
||||
- "defconfig_list"
|
||||
This declares a list of default entries which can be used when
|
||||
looking for the default configuration (which is used when the main
|
||||
.config doesn't exists yet.)
|
||||
|
||||
- "modules"
|
||||
This declares the symbol to be used as the MODULES symbol, which
|
||||
enables the third modular state for all config symbols.
|
||||
At most one symbol may have the "modules" option set.
|
||||
|
||||
- "allnoconfig_y"
|
||||
This declares the symbol as one that should have the value y when
|
||||
using "allnoconfig". Used for symbols that hide other symbols.
|
||||
- module attribute: "modules"
|
||||
This declares the symbol to be used as the MODULES symbol, which
|
||||
enables the third modular state for all config symbols.
|
||||
At most one symbol may have the "modules" option set.
|
||||
|
||||
Menu dependencies
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -41,6 +41,14 @@ KCONFIG_CONFIG
|
|||
This environment variable can be used to specify a default kernel config
|
||||
file name to override the default name of ".config".
|
||||
|
||||
KCONFIG_DEFCONFIG_LIST
|
||||
----------------------
|
||||
|
||||
This environment variable specifies a list of config files which can be used
|
||||
as a base configuration in case the .config does not exist yet. Entries in
|
||||
the list are separated with whitespaces to each other, and the first one
|
||||
that exists is used.
|
||||
|
||||
KCONFIG_OVERWRITECONFIG
|
||||
-----------------------
|
||||
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
|
||||
|
|
|
|||
|
|
@ -608,6 +608,8 @@ demand:
|
|||
setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
|
||||
&recv_own_msgs, sizeof(recv_own_msgs));
|
||||
|
||||
Note that reception of a socket's own CAN frames are subject to the same
|
||||
filtering as other CAN frames (see :ref:`socketcan-rawfilter`).
|
||||
|
||||
.. _socketcan-rawfd:
|
||||
|
||||
|
|
|
|||
|
|
@ -183,6 +183,40 @@ User command examples:
|
|||
values:
|
||||
cmode driverinit value true
|
||||
|
||||
esw_port_metadata: Eswitch port metadata state
|
||||
----------------------------------------------
|
||||
When applicable, disabling Eswitch metadata can increase packet rate
|
||||
up to 20% depending on the use case and packet sizes.
|
||||
|
||||
Eswitch port metadata state controls whether to internally tag packets with
|
||||
metadata. Metadata tagging must be enabled for multi-port RoCE, failover
|
||||
between representors and stacked devices.
|
||||
By default metadata is enabled on the supported devices in E-switch.
|
||||
Metadata is applicable only for E-switch in switchdev mode and
|
||||
users may disable it when NONE of the below use cases will be in use:
|
||||
1. HCA is in Dual/multi-port RoCE mode.
|
||||
2. VF/SF representor bonding (Usually used for Live migration)
|
||||
3. Stacked devices
|
||||
|
||||
When metadata is disabled, the above use cases will fail to initialize if
|
||||
users try to enable them.
|
||||
|
||||
- Show eswitch port metadata::
|
||||
|
||||
$ devlink dev param show pci/0000:06:00.0 name esw_port_metadata
|
||||
pci/0000:06:00.0:
|
||||
name esw_port_metadata type driver-specific
|
||||
values:
|
||||
cmode runtime value true
|
||||
|
||||
- Disable eswitch port metadata::
|
||||
|
||||
$ devlink dev param set pci/0000:06:00.0 name esw_port_metadata value false cmode runtime
|
||||
|
||||
- Change eswitch mode to switchdev mode where after choosing the metadata value::
|
||||
|
||||
$ devlink dev eswitch set pci/0000:06:00.0 mode switchdev
|
||||
|
||||
mlx5 subfunction
|
||||
================
|
||||
mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface.
|
||||
|
|
|
|||
|
|
@ -87,11 +87,15 @@ Receive Buffer
|
|||
contain one or more packets. The number of receive sections may be changed
|
||||
via ethtool Rx ring parameters.
|
||||
|
||||
There is a similar send buffer which is used to aggregate packets for sending.
|
||||
The send area is broken into chunks of 6144 bytes, each of section may
|
||||
contain one or more packets. The send buffer is an optimization, the driver
|
||||
will use slower method to handle very large packets or if the send buffer
|
||||
area is exhausted.
|
||||
There is a similar send buffer which is used to aggregate packets
|
||||
for sending. The send area is broken into chunks, typically of 6144
|
||||
bytes, each of section may contain one or more packets. Small
|
||||
packets are usually transmitted via copy to the send buffer. However,
|
||||
if the buffer is temporarily exhausted, or the packet to be transmitted is
|
||||
an LSO packet, the driver will provide the host with pointers to the data
|
||||
from the SKB. This attempts to achieve a balance between the overhead of
|
||||
data copy and the impact of remapping VM memory to be accessible by the
|
||||
host.
|
||||
|
||||
XDP support
|
||||
-----------
|
||||
|
|
|
|||
|
|
@ -60,4 +60,4 @@ To do:
|
|||
|
||||
Both success and failure reports are welcome.
|
||||
|
||||
Maciej W. Rozycki <macro@linux-mips.org>
|
||||
Maciej W. Rozycki <macro@orcam.me.uk>
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ attributes of the health reporting and recovery procedures.
|
|||
|
||||
The ``devlink`` health reporter:
|
||||
Device driver creates a "health reporter" per each error/health type.
|
||||
Error/Health type can be a known/generic (eg pci error, fw error, rx/tx error)
|
||||
Error/Health type can be a known/generic (e.g. PCI error, fw error, rx/tx error)
|
||||
or unknown (driver specific).
|
||||
For each registered health reporter a driver can issue error/health reports
|
||||
asynchronously. All health reports handling is done by ``devlink``.
|
||||
|
|
@ -48,6 +48,7 @@ Once an error is reported, devlink health will perform the following actions:
|
|||
* Object dump is being taken and saved at the reporter instance (as long as
|
||||
there is no other dump which is already stored)
|
||||
* Auto recovery attempt is being done. Depends on:
|
||||
|
||||
- Auto-recovery configuration
|
||||
- Grace period vs. time passed since last recover
|
||||
|
||||
|
|
@ -72,14 +73,18 @@ via ``devlink``, e.g per error type (per health reporter):
|
|||
* - ``DEVLINK_CMD_HEALTH_REPORTER_SET``
|
||||
- Allows reporter-related configuration setting.
|
||||
* - ``DEVLINK_CMD_HEALTH_REPORTER_RECOVER``
|
||||
- Triggers a reporter's recovery procedure.
|
||||
- Triggers reporter's recovery procedure.
|
||||
* - ``DEVLINK_CMD_HEALTH_REPORTER_TEST``
|
||||
- Triggers a fake health event on the reporter. The effects of the test
|
||||
event in terms of recovery flow should follow closely that of a real
|
||||
event.
|
||||
* - ``DEVLINK_CMD_HEALTH_REPORTER_DIAGNOSE``
|
||||
- Retrieves diagnostics data from a reporter on a device.
|
||||
- Retrieves current device state related to the reporter.
|
||||
* - ``DEVLINK_CMD_HEALTH_REPORTER_DUMP_GET``
|
||||
- Retrieves the last stored dump. Devlink health
|
||||
saves a single dump. If an dump is not already stored by the devlink
|
||||
saves a single dump. If an dump is not already stored by devlink
|
||||
for this reporter, devlink generates a new dump.
|
||||
dump output is defined by the reporter.
|
||||
Dump output is defined by the reporter.
|
||||
* - ``DEVLINK_CMD_HEALTH_REPORTER_DUMP_CLEAR``
|
||||
- Clears the last saved dump file for the specified reporter.
|
||||
|
||||
|
|
@ -93,7 +98,7 @@ The following diagram provides a general overview of ``devlink-health``::
|
|||
+--------------------------+
|
||||
|request for ops
|
||||
|(diagnose,
|
||||
mlx5_core devlink |recover,
|
||||
driver devlink |recover,
|
||||
|dump)
|
||||
+--------+ +--------------------------+
|
||||
| | | reporter| |
|
||||
|
|
|
|||
|
|
@ -34,8 +34,15 @@ interface. The CPU port is the switch port connected to an Ethernet MAC chip.
|
|||
The corresponding linux Ethernet interface is called the master interface.
|
||||
All other corresponding linux interfaces are called slave interfaces.
|
||||
|
||||
The slave interfaces depend on the master interface. They can only brought up,
|
||||
when the master interface is up.
|
||||
The slave interfaces depend on the master interface being up in order for them
|
||||
to send or receive traffic. Prior to kernel v5.12, the state of the master
|
||||
interface had to be managed explicitly by the user. Starting with kernel v5.12,
|
||||
the behavior is as follows:
|
||||
|
||||
- when a DSA slave interface is brought up, the master interface is
|
||||
automatically brought up.
|
||||
- when the master interface is brought down, all DSA slave interfaces are
|
||||
automatically brought down.
|
||||
|
||||
In this documentation the following Ethernet interfaces are used:
|
||||
|
||||
|
|
@ -78,79 +85,76 @@ The tagging based configuration is desired and supported by the majority of
|
|||
DSA switches. These switches are capable to tag incoming and outgoing traffic
|
||||
without using a VLAN based configuration.
|
||||
|
||||
single port
|
||||
~~~~~~~~~~~
|
||||
*single port*
|
||||
.. code-block:: sh
|
||||
|
||||
.. code-block:: sh
|
||||
# configure each interface
|
||||
ip addr add 192.0.2.1/30 dev lan1
|
||||
ip addr add 192.0.2.5/30 dev lan2
|
||||
ip addr add 192.0.2.9/30 dev lan3
|
||||
|
||||
# configure each interface
|
||||
ip addr add 192.0.2.1/30 dev lan1
|
||||
ip addr add 192.0.2.5/30 dev lan2
|
||||
ip addr add 192.0.2.9/30 dev lan3
|
||||
# For kernels earlier than v5.12, the master interface needs to be
|
||||
# brought up manually before the slave ports.
|
||||
ip link set eth0 up
|
||||
|
||||
# The master interface needs to be brought up before the slave ports.
|
||||
ip link set eth0 up
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
*bridge*
|
||||
.. code-block:: sh
|
||||
|
||||
bridge
|
||||
~~~~~~
|
||||
# For kernels earlier than v5.12, the master interface needs to be
|
||||
# brought up manually before the slave ports.
|
||||
ip link set eth0 up
|
||||
|
||||
.. code-block:: sh
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
|
||||
# The master interface needs to be brought up before the slave ports.
|
||||
ip link set eth0 up
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
# add ports to bridge
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
ip link set dev lan3 master br0
|
||||
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
# configure the bridge
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
|
||||
# add ports to bridge
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
ip link set dev lan3 master br0
|
||||
# bring up the bridge
|
||||
ip link set dev br0 up
|
||||
|
||||
# configure the bridge
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
*gateway*
|
||||
.. code-block:: sh
|
||||
|
||||
# bring up the bridge
|
||||
ip link set dev br0 up
|
||||
# For kernels earlier than v5.12, the master interface needs to be
|
||||
# brought up manually before the slave ports.
|
||||
ip link set eth0 up
|
||||
|
||||
gateway
|
||||
~~~~~~~
|
||||
# bring up the slave interfaces
|
||||
ip link set wan up
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
|
||||
.. code-block:: sh
|
||||
# configure the upstream port
|
||||
ip addr add 192.0.2.1/30 dev wan
|
||||
|
||||
# The master interface needs to be brought up before the slave ports.
|
||||
ip link set eth0 up
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
|
||||
# bring up the slave interfaces
|
||||
ip link set wan up
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
# add ports to bridge
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
|
||||
# configure the upstream port
|
||||
ip addr add 192.0.2.1/30 dev wan
|
||||
# configure the bridge
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
|
||||
# add ports to bridge
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
|
||||
# configure the bridge
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
|
||||
# bring up the bridge
|
||||
ip link set dev br0 up
|
||||
# bring up the bridge
|
||||
ip link set dev br0 up
|
||||
|
||||
.. _dsa-vlan-configuration:
|
||||
|
||||
|
|
@ -161,132 +165,130 @@ A minority of switches are not capable to use a taging protocol
|
|||
(DSA_TAG_PROTO_NONE). These switches can be configured by a VLAN based
|
||||
configuration.
|
||||
|
||||
single port
|
||||
~~~~~~~~~~~
|
||||
The configuration can only be set up via VLAN tagging and bridge setup.
|
||||
*single port*
|
||||
The configuration can only be set up via VLAN tagging and bridge setup.
|
||||
|
||||
.. code-block:: sh
|
||||
.. code-block:: sh
|
||||
|
||||
# tag traffic on CPU port
|
||||
ip link add link eth0 name eth0.1 type vlan id 1
|
||||
ip link add link eth0 name eth0.2 type vlan id 2
|
||||
ip link add link eth0 name eth0.3 type vlan id 3
|
||||
# tag traffic on CPU port
|
||||
ip link add link eth0 name eth0.1 type vlan id 1
|
||||
ip link add link eth0 name eth0.2 type vlan id 2
|
||||
ip link add link eth0 name eth0.3 type vlan id 3
|
||||
|
||||
# The master interface needs to be brought up before the slave ports.
|
||||
ip link set eth0 up
|
||||
ip link set eth0.1 up
|
||||
ip link set eth0.2 up
|
||||
ip link set eth0.3 up
|
||||
# For kernels earlier than v5.12, the master interface needs to be
|
||||
# brought up manually before the slave ports.
|
||||
ip link set eth0 up
|
||||
ip link set eth0.1 up
|
||||
ip link set eth0.2 up
|
||||
ip link set eth0.3 up
|
||||
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
|
||||
# activate VLAN filtering
|
||||
ip link set dev br0 type bridge vlan_filtering 1
|
||||
# activate VLAN filtering
|
||||
ip link set dev br0 type bridge vlan_filtering 1
|
||||
|
||||
# add ports to bridges
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
ip link set dev lan3 master br0
|
||||
# add ports to bridges
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
ip link set dev lan3 master br0
|
||||
|
||||
# tag traffic on ports
|
||||
bridge vlan add dev lan1 vid 1 pvid untagged
|
||||
bridge vlan add dev lan2 vid 2 pvid untagged
|
||||
bridge vlan add dev lan3 vid 3 pvid untagged
|
||||
# tag traffic on ports
|
||||
bridge vlan add dev lan1 vid 1 pvid untagged
|
||||
bridge vlan add dev lan2 vid 2 pvid untagged
|
||||
bridge vlan add dev lan3 vid 3 pvid untagged
|
||||
|
||||
# configure the VLANs
|
||||
ip addr add 192.0.2.1/30 dev eth0.1
|
||||
ip addr add 192.0.2.5/30 dev eth0.2
|
||||
ip addr add 192.0.2.9/30 dev eth0.3
|
||||
# configure the VLANs
|
||||
ip addr add 192.0.2.1/30 dev eth0.1
|
||||
ip addr add 192.0.2.5/30 dev eth0.2
|
||||
ip addr add 192.0.2.9/30 dev eth0.3
|
||||
|
||||
# bring up the bridge devices
|
||||
ip link set br0 up
|
||||
# bring up the bridge devices
|
||||
ip link set br0 up
|
||||
|
||||
|
||||
bridge
|
||||
~~~~~~
|
||||
*bridge*
|
||||
.. code-block:: sh
|
||||
|
||||
.. code-block:: sh
|
||||
# tag traffic on CPU port
|
||||
ip link add link eth0 name eth0.1 type vlan id 1
|
||||
|
||||
# tag traffic on CPU port
|
||||
ip link add link eth0 name eth0.1 type vlan id 1
|
||||
# For kernels earlier than v5.12, the master interface needs to be
|
||||
# brought up manually before the slave ports.
|
||||
ip link set eth0 up
|
||||
ip link set eth0.1 up
|
||||
|
||||
# The master interface needs to be brought up before the slave ports.
|
||||
ip link set eth0 up
|
||||
ip link set eth0.1 up
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
|
||||
# bring up the slave interfaces
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
ip link set lan3 up
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
# activate VLAN filtering
|
||||
ip link set dev br0 type bridge vlan_filtering 1
|
||||
|
||||
# activate VLAN filtering
|
||||
ip link set dev br0 type bridge vlan_filtering 1
|
||||
# add ports to bridge
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
ip link set dev lan3 master br0
|
||||
ip link set eth0.1 master br0
|
||||
|
||||
# add ports to bridge
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
ip link set dev lan3 master br0
|
||||
ip link set eth0.1 master br0
|
||||
# tag traffic on ports
|
||||
bridge vlan add dev lan1 vid 1 pvid untagged
|
||||
bridge vlan add dev lan2 vid 1 pvid untagged
|
||||
bridge vlan add dev lan3 vid 1 pvid untagged
|
||||
|
||||
# tag traffic on ports
|
||||
bridge vlan add dev lan1 vid 1 pvid untagged
|
||||
bridge vlan add dev lan2 vid 1 pvid untagged
|
||||
bridge vlan add dev lan3 vid 1 pvid untagged
|
||||
# configure the bridge
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
|
||||
# configure the bridge
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
# bring up the bridge
|
||||
ip link set dev br0 up
|
||||
|
||||
# bring up the bridge
|
||||
ip link set dev br0 up
|
||||
*gateway*
|
||||
.. code-block:: sh
|
||||
|
||||
gateway
|
||||
~~~~~~~
|
||||
# tag traffic on CPU port
|
||||
ip link add link eth0 name eth0.1 type vlan id 1
|
||||
ip link add link eth0 name eth0.2 type vlan id 2
|
||||
|
||||
.. code-block:: sh
|
||||
# For kernels earlier than v5.12, the master interface needs to be
|
||||
# brought up manually before the slave ports.
|
||||
ip link set eth0 up
|
||||
ip link set eth0.1 up
|
||||
ip link set eth0.2 up
|
||||
|
||||
# tag traffic on CPU port
|
||||
ip link add link eth0 name eth0.1 type vlan id 1
|
||||
ip link add link eth0 name eth0.2 type vlan id 2
|
||||
# bring up the slave interfaces
|
||||
ip link set wan up
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
|
||||
# The master interface needs to be brought up before the slave ports.
|
||||
ip link set eth0 up
|
||||
ip link set eth0.1 up
|
||||
ip link set eth0.2 up
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
|
||||
# bring up the slave interfaces
|
||||
ip link set wan up
|
||||
ip link set lan1 up
|
||||
ip link set lan2 up
|
||||
# activate VLAN filtering
|
||||
ip link set dev br0 type bridge vlan_filtering 1
|
||||
|
||||
# create bridge
|
||||
ip link add name br0 type bridge
|
||||
# add ports to bridges
|
||||
ip link set dev wan master br0
|
||||
ip link set eth0.1 master br0
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
|
||||
# activate VLAN filtering
|
||||
ip link set dev br0 type bridge vlan_filtering 1
|
||||
# tag traffic on ports
|
||||
bridge vlan add dev lan1 vid 1 pvid untagged
|
||||
bridge vlan add dev lan2 vid 1 pvid untagged
|
||||
bridge vlan add dev wan vid 2 pvid untagged
|
||||
|
||||
# add ports to bridges
|
||||
ip link set dev wan master br0
|
||||
ip link set eth0.1 master br0
|
||||
ip link set dev lan1 master br0
|
||||
ip link set dev lan2 master br0
|
||||
# configure the VLANs
|
||||
ip addr add 192.0.2.1/30 dev eth0.2
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
|
||||
# tag traffic on ports
|
||||
bridge vlan add dev lan1 vid 1 pvid untagged
|
||||
bridge vlan add dev lan2 vid 1 pvid untagged
|
||||
bridge vlan add dev wan vid 2 pvid untagged
|
||||
|
||||
# configure the VLANs
|
||||
ip addr add 192.0.2.1/30 dev eth0.2
|
||||
ip addr add 192.0.2.129/25 dev br0
|
||||
|
||||
# bring up the bridge devices
|
||||
ip link set br0 up
|
||||
# bring up the bridge devices
|
||||
ip link set br0 up
|
||||
|
|
|
|||
|
|
@ -65,14 +65,8 @@ Note that DSA does not currently create network interfaces for the "cpu" and
|
|||
Switch tagging protocols
|
||||
------------------------
|
||||
|
||||
DSA currently supports 5 different tagging protocols, and a tag-less mode as
|
||||
well. The different protocols are implemented in:
|
||||
|
||||
- ``net/dsa/tag_trailer.c``: Marvell's 4 trailer tag mode (legacy)
|
||||
- ``net/dsa/tag_dsa.c``: Marvell's original DSA tag
|
||||
- ``net/dsa/tag_edsa.c``: Marvell's enhanced DSA tag
|
||||
- ``net/dsa/tag_brcm.c``: Broadcom's 4 bytes tag
|
||||
- ``net/dsa/tag_qca.c``: Qualcomm's 2 bytes tag
|
||||
DSA supports many vendor-specific tagging protocols, one software-defined
|
||||
tagging protocol, and a tag-less mode as well (``DSA_TAG_PROTO_NONE``).
|
||||
|
||||
The exact format of the tag protocol is vendor specific, but in general, they
|
||||
all contain something which:
|
||||
|
|
@ -80,6 +74,144 @@ all contain something which:
|
|||
- identifies which port the Ethernet frame came from/should be sent to
|
||||
- provides a reason why this frame was forwarded to the management interface
|
||||
|
||||
All tagging protocols are in ``net/dsa/tag_*.c`` files and implement the
|
||||
methods of the ``struct dsa_device_ops`` structure, which are detailed below.
|
||||
|
||||
Tagging protocols generally fall in one of three categories:
|
||||
|
||||
1. The switch-specific frame header is located before the Ethernet header,
|
||||
shifting to the right (from the perspective of the DSA master's frame
|
||||
parser) the MAC DA, MAC SA, EtherType and the entire L2 payload.
|
||||
2. The switch-specific frame header is located before the EtherType, keeping
|
||||
the MAC DA and MAC SA in place from the DSA master's perspective, but
|
||||
shifting the 'real' EtherType and L2 payload to the right.
|
||||
3. The switch-specific frame header is located at the tail of the packet,
|
||||
keeping all frame headers in place and not altering the view of the packet
|
||||
that the DSA master's frame parser has.
|
||||
|
||||
A tagging protocol may tag all packets with switch tags of the same length, or
|
||||
the tag length might vary (for example packets with PTP timestamps might
|
||||
require an extended switch tag, or there might be one tag length on TX and a
|
||||
different one on RX). Either way, the tagging protocol driver must populate the
|
||||
``struct dsa_device_ops::overhead`` with the length in octets of the longest
|
||||
switch frame header. The DSA framework will automatically adjust the MTU of the
|
||||
master interface to accomodate for this extra size in order for DSA user ports
|
||||
to support the standard MTU (L2 payload length) of 1500 octets. The ``overhead``
|
||||
is also used to request from the network stack, on a best-effort basis, the
|
||||
allocation of packets with a ``needed_headroom`` or ``needed_tailroom``
|
||||
sufficient such that the act of pushing the switch tag on transmission of a
|
||||
packet does not cause it to reallocate due to lack of memory.
|
||||
|
||||
Even though applications are not expected to parse DSA-specific frame headers,
|
||||
the format on the wire of the tagging protocol represents an Application Binary
|
||||
Interface exposed by the kernel towards user space, for decoders such as
|
||||
``libpcap``. The tagging protocol driver must populate the ``proto`` member of
|
||||
``struct dsa_device_ops`` with a value that uniquely describes the
|
||||
characteristics of the interaction required between the switch hardware and the
|
||||
data path driver: the offset of each bit field within the frame header and any
|
||||
stateful processing required to deal with the frames (as may be required for
|
||||
PTP timestamping).
|
||||
|
||||
From the perspective of the network stack, all switches within the same DSA
|
||||
switch tree use the same tagging protocol. In case of a packet transiting a
|
||||
fabric with more than one switch, the switch-specific frame header is inserted
|
||||
by the first switch in the fabric that the packet was received on. This header
|
||||
typically contains information regarding its type (whether it is a control
|
||||
frame that must be trapped to the CPU, or a data frame to be forwarded).
|
||||
Control frames should be decapsulated only by the software data path, whereas
|
||||
data frames might also be autonomously forwarded towards other user ports of
|
||||
other switches from the same fabric, and in this case, the outermost switch
|
||||
ports must decapsulate the packet.
|
||||
|
||||
Note that in certain cases, it might be the case that the tagging format used
|
||||
by a leaf switch (not connected directly to the CPU) to not be the same as what
|
||||
the network stack sees. This can be seen with Marvell switch trees, where the
|
||||
CPU port can be configured to use either the DSA or the Ethertype DSA (EDSA)
|
||||
format, but the DSA links are configured to use the shorter (without Ethertype)
|
||||
DSA frame header, in order to reduce the autonomous packet forwarding overhead.
|
||||
It still remains the case that, if the DSA switch tree is configured for the
|
||||
EDSA tagging protocol, the operating system sees EDSA-tagged packets from the
|
||||
leaf switches that tagged them with the shorter DSA header. This can be done
|
||||
because the Marvell switch connected directly to the CPU is configured to
|
||||
perform tag translation between DSA and EDSA (which is simply the operation of
|
||||
adding or removing the ``ETH_P_EDSA`` EtherType and some padding octets).
|
||||
|
||||
It is possible to construct cascaded setups of DSA switches even if their
|
||||
tagging protocols are not compatible with one another. In this case, there are
|
||||
no DSA links in this fabric, and each switch constitutes a disjoint DSA switch
|
||||
tree. The DSA links are viewed as simply a pair of a DSA master (the out-facing
|
||||
port of the upstream DSA switch) and a CPU port (the in-facing port of the
|
||||
downstream DSA switch).
|
||||
|
||||
The tagging protocol of the attached DSA switch tree can be viewed through the
|
||||
``dsa/tagging`` sysfs attribute of the DSA master::
|
||||
|
||||
cat /sys/class/net/eth0/dsa/tagging
|
||||
|
||||
If the hardware and driver are capable, the tagging protocol of the DSA switch
|
||||
tree can be changed at runtime. This is done by writing the new tagging
|
||||
protocol name to the same sysfs device attribute as above (the DSA master and
|
||||
all attached switch ports must be down while doing this).
|
||||
|
||||
It is desirable that all tagging protocols are testable with the ``dsa_loop``
|
||||
mockup driver, which can be attached to any network interface. The goal is that
|
||||
any network interface should be capable of transmitting the same packet in the
|
||||
same way, and the tagger should decode the same received packet in the same way
|
||||
regardless of the driver used for the switch control path, and the driver used
|
||||
for the DSA master.
|
||||
|
||||
The transmission of a packet goes through the tagger's ``xmit`` function.
|
||||
The passed ``struct sk_buff *skb`` has ``skb->data`` pointing at
|
||||
``skb_mac_header(skb)``, i.e. at the destination MAC address, and the passed
|
||||
``struct net_device *dev`` represents the virtual DSA user network interface
|
||||
whose hardware counterpart the packet must be steered to (i.e. ``swp0``).
|
||||
The job of this method is to prepare the skb in a way that the switch will
|
||||
understand what egress port the packet is for (and not deliver it towards other
|
||||
ports). Typically this is fulfilled by pushing a frame header. Checking for
|
||||
insufficient size in the skb headroom or tailroom is unnecessary provided that
|
||||
the ``overhead`` and ``tail_tag`` properties were filled out properly, because
|
||||
DSA ensures there is enough space before calling this method.
|
||||
|
||||
The reception of a packet goes through the tagger's ``rcv`` function. The
|
||||
passed ``struct sk_buff *skb`` has ``skb->data`` pointing at
|
||||
``skb_mac_header(skb) + ETH_ALEN`` octets, i.e. to where the first octet after
|
||||
the EtherType would have been, were this frame not tagged. The role of this
|
||||
method is to consume the frame header, adjust ``skb->data`` to really point at
|
||||
the first octet after the EtherType, and to change ``skb->dev`` to point to the
|
||||
virtual DSA user network interface corresponding to the physical front-facing
|
||||
switch port that the packet was received on.
|
||||
|
||||
Since tagging protocols in category 1 and 2 break software (and most often also
|
||||
hardware) packet dissection on the DSA master, features such as RPS (Receive
|
||||
Packet Steering) on the DSA master would be broken. The DSA framework deals
|
||||
with this by hooking into the flow dissector and shifting the offset at which
|
||||
the IP header is to be found in the tagged frame as seen by the DSA master.
|
||||
This behavior is automatic based on the ``overhead`` value of the tagging
|
||||
protocol. If not all packets are of equal size, the tagger can implement the
|
||||
``flow_dissect`` method of the ``struct dsa_device_ops`` and override this
|
||||
default behavior by specifying the correct offset incurred by each individual
|
||||
RX packet. Tail taggers do not cause issues to the flow dissector.
|
||||
|
||||
Due to various reasons (most common being category 1 taggers being associated
|
||||
with DSA-unaware masters, mangling what the master perceives as MAC DA), the
|
||||
tagging protocol may require the DSA master to operate in promiscuous mode, to
|
||||
receive all frames regardless of the value of the MAC DA. This can be done by
|
||||
setting the ``promisc_on_master`` property of the ``struct dsa_device_ops``.
|
||||
Note that this assumes a DSA-unaware master driver, which is the norm.
|
||||
|
||||
Hardware manufacturers are strongly discouraged to do this, but some tagging
|
||||
protocols might not provide source port information on RX for all packets, but
|
||||
e.g. only for control traffic (link-local PDUs). In this case, by implementing
|
||||
the ``filter`` method of ``struct dsa_device_ops``, the tagger might select
|
||||
which packets are to be redirected on RX towards the virtual DSA user network
|
||||
interfaces, and which are to be left in the DSA master's RX data path.
|
||||
|
||||
It might also happen (although silicon vendors are strongly discouraged to
|
||||
produce hardware like this) that a tagging protocol splits the switch-specific
|
||||
information into a header portion and a tail portion, therefore not falling
|
||||
cleanly into any of the above 3 categories. DSA does not support this
|
||||
configuration.
|
||||
|
||||
Master network devices
|
||||
----------------------
|
||||
|
||||
|
|
@ -172,23 +304,34 @@ Graphical representation
|
|||
Summarized, this is basically how DSA looks like from a network device
|
||||
perspective::
|
||||
|
||||
|
||||
|---------------------------
|
||||
| CPU network device (eth0)|
|
||||
----------------------------
|
||||
| <tag added by switch |
|
||||
| |
|
||||
| |
|
||||
| tag added by CPU> |
|
||||
|--------------------------------------------|
|
||||
| Switch driver |
|
||||
|--------------------------------------------|
|
||||
|| || ||
|
||||
|-------| |-------| |-------|
|
||||
| sw0p0 | | sw0p1 | | sw0p2 |
|
||||
|-------| |-------| |-------|
|
||||
|
||||
|
||||
Unaware application
|
||||
opens and binds socket
|
||||
| ^
|
||||
| |
|
||||
+-----------v--|--------------------+
|
||||
|+------+ +------+ +------+ +------+|
|
||||
|| swp0 | | swp1 | | swp2 | | swp3 ||
|
||||
|+------+-+------+-+------+-+------+|
|
||||
| DSA switch driver |
|
||||
+-----------------------------------+
|
||||
| ^
|
||||
Tag added by | | Tag consumed by
|
||||
switch driver | | switch driver
|
||||
v |
|
||||
+-----------------------------------+
|
||||
| Unmodified host interface driver | Software
|
||||
--------+-----------------------------------+------------
|
||||
| Host interface (eth0) | Hardware
|
||||
+-----------------------------------+
|
||||
| ^
|
||||
Tag consumed by | | Tag added by
|
||||
switch hardware | | switch hardware
|
||||
v |
|
||||
+-----------------------------------+
|
||||
| Switch |
|
||||
|+------+ +------+ +------+ +------+|
|
||||
|| swp0 | | swp1 | | swp2 | | swp3 ||
|
||||
++------+-+------+-+------+-+------++
|
||||
|
||||
Slave MDIO bus
|
||||
--------------
|
||||
|
|
@ -239,14 +382,6 @@ DSA data structures are defined in ``include/net/dsa.h`` as well as
|
|||
Design limitations
|
||||
==================
|
||||
|
||||
Limits on the number of devices and ports
|
||||
-----------------------------------------
|
||||
|
||||
DSA currently limits the number of maximum switches within a tree to 4
|
||||
(``DSA_MAX_SWITCHES``), and the number of ports per switch to 12 (``DSA_MAX_PORTS``).
|
||||
These limits could be extended to support larger configurations would this need
|
||||
arise.
|
||||
|
||||
Lack of CPU/DSA network devices
|
||||
-------------------------------
|
||||
|
||||
|
|
@ -281,6 +416,7 @@ DSA currently leverages the following subsystems:
|
|||
- MDIO/PHY library: ``drivers/net/phy/phy.c``, ``mdio_bus.c``
|
||||
- Switchdev:``net/switchdev/*``
|
||||
- Device Tree for various of_* functions
|
||||
- Devlink: ``net/core/devlink.c``
|
||||
|
||||
MDIO/PHY library
|
||||
----------------
|
||||
|
|
@ -317,14 +453,39 @@ SWITCHDEV
|
|||
|
||||
DSA directly utilizes SWITCHDEV when interfacing with the bridge layer, and
|
||||
more specifically with its VLAN filtering portion when configuring VLANs on top
|
||||
of per-port slave network devices. Since DSA primarily deals with
|
||||
MDIO-connected switches, although not exclusively, SWITCHDEV's
|
||||
prepare/abort/commit phases are often simplified into a prepare phase which
|
||||
checks whether the operation is supported by the DSA switch driver, and a commit
|
||||
phase which applies the changes.
|
||||
of per-port slave network devices. As of today, the only SWITCHDEV objects
|
||||
supported by DSA are the FDB and VLAN objects.
|
||||
|
||||
As of today, the only SWITCHDEV objects supported by DSA are the FDB and VLAN
|
||||
objects.
|
||||
Devlink
|
||||
-------
|
||||
|
||||
DSA registers one devlink device per physical switch in the fabric.
|
||||
For each devlink device, every physical port (i.e. user ports, CPU ports, DSA
|
||||
links or unused ports) is exposed as a devlink port.
|
||||
|
||||
DSA drivers can make use of the following devlink features:
|
||||
|
||||
- Regions: debugging feature which allows user space to dump driver-defined
|
||||
areas of hardware information in a low-level, binary format. Both global
|
||||
regions as well as per-port regions are supported. It is possible to export
|
||||
devlink regions even for pieces of data that are already exposed in some way
|
||||
to the standard iproute2 user space programs (ip-link, bridge), like address
|
||||
tables and VLAN tables. For example, this might be useful if the tables
|
||||
contain additional hardware-specific details which are not visible through
|
||||
the iproute2 abstraction, or it might be useful to inspect these tables on
|
||||
the non-user ports too, which are invisible to iproute2 because no network
|
||||
interface is registered for them.
|
||||
- Params: a feature which enables user to configure certain low-level tunable
|
||||
knobs pertaining to the device. Drivers may implement applicable generic
|
||||
devlink params, or may add new device-specific devlink params.
|
||||
- Resources: a monitoring feature which enables users to see the degree of
|
||||
utilization of certain hardware tables in the device, such as FDB, VLAN, etc.
|
||||
- Shared buffers: a QoS feature for adjusting and partitioning memory and frame
|
||||
reservations per port and per traffic class, in the ingress and egress
|
||||
directions, such that low-priority bulk traffic does not impede the
|
||||
processing of high-priority critical traffic.
|
||||
|
||||
For more details, consult ``Documentation/networking/devlink/``.
|
||||
|
||||
Device Tree
|
||||
-----------
|
||||
|
|
@ -490,6 +651,17 @@ Bridge layer
|
|||
computing a STP state change based on current and asked parameters and perform
|
||||
the relevant ageing based on the intersection results
|
||||
|
||||
- ``port_bridge_flags``: bridge layer function invoked when a port must
|
||||
configure its settings for e.g. flooding of unknown traffic or source address
|
||||
learning. The switch driver is responsible for initial setup of the
|
||||
standalone ports with address learning disabled and egress flooding of all
|
||||
types of traffic, then the DSA core notifies of any change to the bridge port
|
||||
flags when the port joins and leaves a bridge. DSA does not currently manage
|
||||
the bridge port flags for the CPU port. The assumption is that address
|
||||
learning should be statically enabled (if supported by the hardware) on the
|
||||
CPU port, and flooding towards the CPU port should also be enabled, due to a
|
||||
lack of an explicit address filtering mechanism in the DSA core.
|
||||
|
||||
Bridge VLAN filtering
|
||||
---------------------
|
||||
|
||||
|
|
@ -503,14 +675,10 @@ Bridge VLAN filtering
|
|||
accept any 802.1Q frames irrespective of their VLAN ID, and untagged frames are
|
||||
allowed.
|
||||
|
||||
- ``port_vlan_prepare``: bridge layer function invoked when the bridge prepares the
|
||||
configuration of a VLAN on the given port. If the operation is not supported
|
||||
by the hardware, this function should return ``-EOPNOTSUPP`` to inform the bridge
|
||||
code to fallback to a software implementation. No hardware setup must be done
|
||||
in this function. See port_vlan_add for this and details.
|
||||
|
||||
- ``port_vlan_add``: bridge layer function invoked when a VLAN is configured
|
||||
(tagged or untagged) for the given switch port
|
||||
(tagged or untagged) for the given switch port. If the operation is not
|
||||
supported by the hardware, this function should return ``-EOPNOTSUPP`` to
|
||||
inform the bridge code to fallback to a software implementation.
|
||||
|
||||
- ``port_vlan_del``: bridge layer function invoked when a VLAN is removed from the
|
||||
given switch port
|
||||
|
|
@ -538,14 +706,10 @@ Bridge VLAN filtering
|
|||
function that the driver has to call for each MAC address known to be behind
|
||||
the given port. A switchdev object is used to carry the VID and FDB info.
|
||||
|
||||
- ``port_mdb_prepare``: bridge layer function invoked when the bridge prepares the
|
||||
installation of a multicast database entry. If the operation is not supported,
|
||||
this function should return ``-EOPNOTSUPP`` to inform the bridge code to fallback
|
||||
to a software implementation. No hardware setup must be done in this function.
|
||||
See ``port_fdb_add`` for this and details.
|
||||
|
||||
- ``port_mdb_add``: bridge layer function invoked when the bridge wants to install
|
||||
a multicast database entry, the switch hardware should be programmed with the
|
||||
a multicast database entry. If the operation is not supported, this function
|
||||
should return ``-EOPNOTSUPP`` to inform the bridge code to fallback to a
|
||||
software implementation. The switch hardware should be programmed with the
|
||||
specified address in the specified VLAN ID in the forwarding database
|
||||
associated with this VLAN ID.
|
||||
|
||||
|
|
@ -561,6 +725,101 @@ Bridge VLAN filtering
|
|||
function that the driver has to call for each MAC address known to be behind
|
||||
the given port. A switchdev object is used to carry the VID and MDB info.
|
||||
|
||||
Link aggregation
|
||||
----------------
|
||||
|
||||
Link aggregation is implemented in the Linux networking stack by the bonding
|
||||
and team drivers, which are modeled as virtual, stackable network interfaces.
|
||||
DSA is capable of offloading a link aggregation group (LAG) to hardware that
|
||||
supports the feature, and supports bridging between physical ports and LAGs,
|
||||
as well as between LAGs. A bonding/team interface which holds multiple physical
|
||||
ports constitutes a logical port, although DSA has no explicit concept of a
|
||||
logical port at the moment. Due to this, events where a LAG joins/leaves a
|
||||
bridge are treated as if all individual physical ports that are members of that
|
||||
LAG join/leave the bridge. Switchdev port attributes (VLAN filtering, STP
|
||||
state, etc) and objects (VLANs, MDB entries) offloaded to a LAG as bridge port
|
||||
are treated similarly: DSA offloads the same switchdev object / port attribute
|
||||
on all members of the LAG. Static bridge FDB entries on a LAG are not yet
|
||||
supported, since the DSA driver API does not have the concept of a logical port
|
||||
ID.
|
||||
|
||||
- ``port_lag_join``: function invoked when a given switch port is added to a
|
||||
LAG. The driver may return ``-EOPNOTSUPP``, and in this case, DSA will fall
|
||||
back to a software implementation where all traffic from this port is sent to
|
||||
the CPU.
|
||||
- ``port_lag_leave``: function invoked when a given switch port leaves a LAG
|
||||
and returns to operation as a standalone port.
|
||||
- ``port_lag_change``: function invoked when the link state of any member of
|
||||
the LAG changes, and the hashing function needs rebalancing to only make use
|
||||
of the subset of physical LAG member ports that are up.
|
||||
|
||||
Drivers that benefit from having an ID associated with each offloaded LAG
|
||||
can optionally populate ``ds->num_lag_ids`` from the ``dsa_switch_ops::setup``
|
||||
method. The LAG ID associated with a bonding/team interface can then be
|
||||
retrieved by a DSA switch driver using the ``dsa_lag_id`` function.
|
||||
|
||||
IEC 62439-2 (MRP)
|
||||
-----------------
|
||||
|
||||
The Media Redundancy Protocol is a topology management protocol optimized for
|
||||
fast fault recovery time for ring networks, which has some components
|
||||
implemented as a function of the bridge driver. MRP uses management PDUs
|
||||
(Test, Topology, LinkDown/Up, Option) sent at a multicast destination MAC
|
||||
address range of 01:15:4e:00:00:0x and with an EtherType of 0x88e3.
|
||||
Depending on the node's role in the ring (MRM: Media Redundancy Manager,
|
||||
MRC: Media Redundancy Client, MRA: Media Redundancy Automanager), certain MRP
|
||||
PDUs might need to be terminated locally and others might need to be forwarded.
|
||||
An MRM might also benefit from offloading to hardware the creation and
|
||||
transmission of certain MRP PDUs (Test).
|
||||
|
||||
Normally an MRP instance can be created on top of any network interface,
|
||||
however in the case of a device with an offloaded data path such as DSA, it is
|
||||
necessary for the hardware, even if it is not MRP-aware, to be able to extract
|
||||
the MRP PDUs from the fabric before the driver can proceed with the software
|
||||
implementation. DSA today has no driver which is MRP-aware, therefore it only
|
||||
listens for the bare minimum switchdev objects required for the software assist
|
||||
to work properly. The operations are detailed below.
|
||||
|
||||
- ``port_mrp_add`` and ``port_mrp_del``: notifies driver when an MRP instance
|
||||
with a certain ring ID, priority, primary port and secondary port is
|
||||
created/deleted.
|
||||
- ``port_mrp_add_ring_role`` and ``port_mrp_del_ring_role``: function invoked
|
||||
when an MRP instance changes ring roles between MRM or MRC. This affects
|
||||
which MRP PDUs should be trapped to software and which should be autonomously
|
||||
forwarded.
|
||||
|
||||
IEC 62439-3 (HSR/PRP)
|
||||
---------------------
|
||||
|
||||
The Parallel Redundancy Protocol (PRP) is a network redundancy protocol which
|
||||
works by duplicating and sequence numbering packets through two independent L2
|
||||
networks (which are unaware of the PRP tail tags carried in the packets), and
|
||||
eliminating the duplicates at the receiver. The High-availability Seamless
|
||||
Redundancy (HSR) protocol is similar in concept, except all nodes that carry
|
||||
the redundant traffic are aware of the fact that it is HSR-tagged (because HSR
|
||||
uses a header with an EtherType of 0x892f) and are physically connected in a
|
||||
ring topology. Both HSR and PRP use supervision frames for monitoring the
|
||||
health of the network and for discovery of other nodes.
|
||||
|
||||
In Linux, both HSR and PRP are implemented in the hsr driver, which
|
||||
instantiates a virtual, stackable network interface with two member ports.
|
||||
The driver only implements the basic roles of DANH (Doubly Attached Node
|
||||
implementing HSR) and DANP (Doubly Attached Node implementing PRP); the roles
|
||||
of RedBox and QuadBox are not implemented (therefore, bridging a hsr network
|
||||
interface with a physical switch port does not produce the expected result).
|
||||
|
||||
A driver which is able of offloading certain functions of a DANP or DANH should
|
||||
declare the corresponding netdev features as indicated by the documentation at
|
||||
``Documentation/networking/netdev-features.rst``. Additionally, the following
|
||||
methods must be implemented:
|
||||
|
||||
- ``port_hsr_join``: function invoked when a given switch port is added to a
|
||||
DANP/DANH. The driver may return ``-EOPNOTSUPP`` and in this case, DSA will
|
||||
fall back to a software implementation where all traffic from this port is
|
||||
sent to the CPU.
|
||||
- ``port_hsr_leave``: function invoked when a given switch port leaves a
|
||||
DANP/DANH and returns to normal operation as a standalone port.
|
||||
|
||||
TODO
|
||||
====
|
||||
|
||||
|
|
@ -576,8 +835,5 @@ two subsystems and get the best of both worlds.
|
|||
Other hanging fruits
|
||||
--------------------
|
||||
|
||||
- making the number of ports fully dynamic and not dependent on ``DSA_MAX_PORTS``
|
||||
- allowing more than one CPU/management interface:
|
||||
http://comments.gmane.org/gmane.linux.network/365657
|
||||
- porting more drivers from other vendors:
|
||||
http://comments.gmane.org/gmane.linux.network/365510
|
||||
|
|
|
|||
|
|
@ -208,41 +208,49 @@ Userspace to kernel:
|
|||
``ETHTOOL_MSG_CABLE_TEST_ACT`` action start cable test
|
||||
``ETHTOOL_MSG_CABLE_TEST_TDR_ACT`` action start raw TDR cable test
|
||||
``ETHTOOL_MSG_TUNNEL_INFO_GET`` get tunnel offload info
|
||||
``ETHTOOL_MSG_FEC_GET`` get FEC settings
|
||||
``ETHTOOL_MSG_FEC_SET`` set FEC settings
|
||||
``ETHTOOL_MSG_MODULE_EEPROM_GET`` read SFP module EEPROM
|
||||
``ETHTOOL_MSG_STATS_GET`` get standard statistics
|
||||
===================================== ================================
|
||||
|
||||
Kernel to userspace:
|
||||
|
||||
===================================== =================================
|
||||
``ETHTOOL_MSG_STRSET_GET_REPLY`` string set contents
|
||||
``ETHTOOL_MSG_LINKINFO_GET_REPLY`` link settings
|
||||
``ETHTOOL_MSG_LINKINFO_NTF`` link settings notification
|
||||
``ETHTOOL_MSG_LINKMODES_GET_REPLY`` link modes info
|
||||
``ETHTOOL_MSG_LINKMODES_NTF`` link modes notification
|
||||
``ETHTOOL_MSG_LINKSTATE_GET_REPLY`` link state info
|
||||
``ETHTOOL_MSG_DEBUG_GET_REPLY`` debugging settings
|
||||
``ETHTOOL_MSG_DEBUG_NTF`` debugging settings notification
|
||||
``ETHTOOL_MSG_WOL_GET_REPLY`` wake-on-lan settings
|
||||
``ETHTOOL_MSG_WOL_NTF`` wake-on-lan settings notification
|
||||
``ETHTOOL_MSG_FEATURES_GET_REPLY`` device features
|
||||
``ETHTOOL_MSG_FEATURES_SET_REPLY`` optional reply to FEATURES_SET
|
||||
``ETHTOOL_MSG_FEATURES_NTF`` netdev features notification
|
||||
``ETHTOOL_MSG_PRIVFLAGS_GET_REPLY`` private flags
|
||||
``ETHTOOL_MSG_PRIVFLAGS_NTF`` private flags
|
||||
``ETHTOOL_MSG_RINGS_GET_REPLY`` ring sizes
|
||||
``ETHTOOL_MSG_RINGS_NTF`` ring sizes
|
||||
``ETHTOOL_MSG_CHANNELS_GET_REPLY`` channel counts
|
||||
``ETHTOOL_MSG_CHANNELS_NTF`` channel counts
|
||||
``ETHTOOL_MSG_COALESCE_GET_REPLY`` coalescing parameters
|
||||
``ETHTOOL_MSG_COALESCE_NTF`` coalescing parameters
|
||||
``ETHTOOL_MSG_PAUSE_GET_REPLY`` pause parameters
|
||||
``ETHTOOL_MSG_PAUSE_NTF`` pause parameters
|
||||
``ETHTOOL_MSG_EEE_GET_REPLY`` EEE settings
|
||||
``ETHTOOL_MSG_EEE_NTF`` EEE settings
|
||||
``ETHTOOL_MSG_TSINFO_GET_REPLY`` timestamping info
|
||||
``ETHTOOL_MSG_CABLE_TEST_NTF`` Cable test results
|
||||
``ETHTOOL_MSG_CABLE_TEST_TDR_NTF`` Cable test TDR results
|
||||
``ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY`` tunnel offload info
|
||||
===================================== =================================
|
||||
======================================== =================================
|
||||
``ETHTOOL_MSG_STRSET_GET_REPLY`` string set contents
|
||||
``ETHTOOL_MSG_LINKINFO_GET_REPLY`` link settings
|
||||
``ETHTOOL_MSG_LINKINFO_NTF`` link settings notification
|
||||
``ETHTOOL_MSG_LINKMODES_GET_REPLY`` link modes info
|
||||
``ETHTOOL_MSG_LINKMODES_NTF`` link modes notification
|
||||
``ETHTOOL_MSG_LINKSTATE_GET_REPLY`` link state info
|
||||
``ETHTOOL_MSG_DEBUG_GET_REPLY`` debugging settings
|
||||
``ETHTOOL_MSG_DEBUG_NTF`` debugging settings notification
|
||||
``ETHTOOL_MSG_WOL_GET_REPLY`` wake-on-lan settings
|
||||
``ETHTOOL_MSG_WOL_NTF`` wake-on-lan settings notification
|
||||
``ETHTOOL_MSG_FEATURES_GET_REPLY`` device features
|
||||
``ETHTOOL_MSG_FEATURES_SET_REPLY`` optional reply to FEATURES_SET
|
||||
``ETHTOOL_MSG_FEATURES_NTF`` netdev features notification
|
||||
``ETHTOOL_MSG_PRIVFLAGS_GET_REPLY`` private flags
|
||||
``ETHTOOL_MSG_PRIVFLAGS_NTF`` private flags
|
||||
``ETHTOOL_MSG_RINGS_GET_REPLY`` ring sizes
|
||||
``ETHTOOL_MSG_RINGS_NTF`` ring sizes
|
||||
``ETHTOOL_MSG_CHANNELS_GET_REPLY`` channel counts
|
||||
``ETHTOOL_MSG_CHANNELS_NTF`` channel counts
|
||||
``ETHTOOL_MSG_COALESCE_GET_REPLY`` coalescing parameters
|
||||
``ETHTOOL_MSG_COALESCE_NTF`` coalescing parameters
|
||||
``ETHTOOL_MSG_PAUSE_GET_REPLY`` pause parameters
|
||||
``ETHTOOL_MSG_PAUSE_NTF`` pause parameters
|
||||
``ETHTOOL_MSG_EEE_GET_REPLY`` EEE settings
|
||||
``ETHTOOL_MSG_EEE_NTF`` EEE settings
|
||||
``ETHTOOL_MSG_TSINFO_GET_REPLY`` timestamping info
|
||||
``ETHTOOL_MSG_CABLE_TEST_NTF`` Cable test results
|
||||
``ETHTOOL_MSG_CABLE_TEST_TDR_NTF`` Cable test TDR results
|
||||
``ETHTOOL_MSG_TUNNEL_INFO_GET_REPLY`` tunnel offload info
|
||||
``ETHTOOL_MSG_FEC_GET_REPLY`` FEC settings
|
||||
``ETHTOOL_MSG_FEC_NTF`` FEC settings
|
||||
``ETHTOOL_MSG_MODULE_EEPROM_GET_REPLY`` read SFP module EEPROM
|
||||
``ETHTOOL_MSG_STATS_GET_REPLY`` standard statistics
|
||||
======================================== =================================
|
||||
|
||||
``GET`` requests are sent by userspace applications to retrieve device
|
||||
information. They usually do not contain any message specific attributes.
|
||||
|
|
@ -1280,6 +1288,193 @@ Kernel response contents:
|
|||
For UDP tunnel table empty ``ETHTOOL_A_TUNNEL_UDP_TABLE_TYPES`` indicates that
|
||||
the table contains static entries, hard-coded by the NIC.
|
||||
|
||||
FEC_GET
|
||||
=======
|
||||
|
||||
Gets FEC configuration and state like ``ETHTOOL_GFECPARAM`` ioctl request.
|
||||
|
||||
Request contents:
|
||||
|
||||
===================================== ====== ==========================
|
||||
``ETHTOOL_A_FEC_HEADER`` nested request header
|
||||
===================================== ====== ==========================
|
||||
|
||||
Kernel response contents:
|
||||
|
||||
===================================== ====== ==========================
|
||||
``ETHTOOL_A_FEC_HEADER`` nested request header
|
||||
``ETHTOOL_A_FEC_MODES`` bitset configured modes
|
||||
``ETHTOOL_A_FEC_AUTO`` bool FEC mode auto selection
|
||||
``ETHTOOL_A_FEC_ACTIVE`` u32 index of active FEC mode
|
||||
``ETHTOOL_A_FEC_STATS`` nested FEC statistics
|
||||
===================================== ====== ==========================
|
||||
|
||||
``ETHTOOL_A_FEC_ACTIVE`` is the bit index of the FEC link mode currently
|
||||
active on the interface. This attribute may not be present if device does
|
||||
not support FEC.
|
||||
|
||||
``ETHTOOL_A_FEC_MODES`` and ``ETHTOOL_A_FEC_AUTO`` are only meaningful when
|
||||
autonegotiation is disabled. If ``ETHTOOL_A_FEC_AUTO`` is non-zero driver will
|
||||
select the FEC mode automatically based on the parameters of the SFP module.
|
||||
This is equivalent to the ``ETHTOOL_FEC_AUTO`` bit of the ioctl interface.
|
||||
``ETHTOOL_A_FEC_MODES`` carry the current FEC configuration using link mode
|
||||
bits (rather than old ``ETHTOOL_FEC_*`` bits).
|
||||
|
||||
``ETHTOOL_A_FEC_STATS`` are reported if ``ETHTOOL_FLAG_STATS`` was set in
|
||||
``ETHTOOL_A_HEADER_FLAGS``.
|
||||
Each attribute carries an array of 64bit statistics. First entry in the array
|
||||
contains the total number of events on the port, while the following entries
|
||||
are counters corresponding to lanes/PCS instances. The number of entries in
|
||||
the array will be:
|
||||
|
||||
+--------------+---------------------------------------------+
|
||||
| `0` | device does not support FEC statistics |
|
||||
+--------------+---------------------------------------------+
|
||||
| `1` | device does not support per-lane break down |
|
||||
+--------------+---------------------------------------------+
|
||||
| `1 + #lanes` | device has full support for FEC stats |
|
||||
+--------------+---------------------------------------------+
|
||||
|
||||
Drivers fill in the statistics in the following structure:
|
||||
|
||||
.. kernel-doc:: include/linux/ethtool.h
|
||||
:identifiers: ethtool_fec_stats
|
||||
|
||||
FEC_SET
|
||||
=======
|
||||
|
||||
Sets FEC parameters like ``ETHTOOL_SFECPARAM`` ioctl request.
|
||||
|
||||
Request contents:
|
||||
|
||||
===================================== ====== ==========================
|
||||
``ETHTOOL_A_FEC_HEADER`` nested request header
|
||||
``ETHTOOL_A_FEC_MODES`` bitset configured modes
|
||||
``ETHTOOL_A_FEC_AUTO`` bool FEC mode auto selection
|
||||
===================================== ====== ==========================
|
||||
|
||||
``FEC_SET`` is only meaningful when autonegotiation is disabled. Otherwise
|
||||
FEC mode is selected as part of autonegotiation.
|
||||
|
||||
``ETHTOOL_A_FEC_MODES`` selects which FEC mode should be used. It's recommended
|
||||
to set only one bit, if multiple bits are set driver may choose between them
|
||||
in an implementation specific way.
|
||||
|
||||
``ETHTOOL_A_FEC_AUTO`` requests the driver to choose FEC mode based on SFP
|
||||
module parameters. This does not mean autonegotiation.
|
||||
|
||||
MODULE_EEPROM
|
||||
=============
|
||||
|
||||
Fetch module EEPROM data dump.
|
||||
This interface is designed to allow dumps of at most 1/2 page at once. This
|
||||
means only dumps of 128 (or less) bytes are allowed, without crossing half page
|
||||
boundary located at offset 128. For pages other than 0 only high 128 bytes are
|
||||
accessible.
|
||||
|
||||
Request contents:
|
||||
|
||||
======================================= ====== ==========================
|
||||
``ETHTOOL_A_MODULE_EEPROM_HEADER`` nested request header
|
||||
``ETHTOOL_A_MODULE_EEPROM_OFFSET`` u32 offset within a page
|
||||
``ETHTOOL_A_MODULE_EEPROM_LENGTH`` u32 amount of bytes to read
|
||||
``ETHTOOL_A_MODULE_EEPROM_PAGE`` u8 page number
|
||||
``ETHTOOL_A_MODULE_EEPROM_BANK`` u8 bank number
|
||||
``ETHTOOL_A_MODULE_EEPROM_I2C_ADDRESS`` u8 page I2C address
|
||||
======================================= ====== ==========================
|
||||
|
||||
Kernel response contents:
|
||||
|
||||
+---------------------------------------------+--------+---------------------+
|
||||
| ``ETHTOOL_A_MODULE_EEPROM_HEADER`` | nested | reply header |
|
||||
+---------------------------------------------+--------+---------------------+
|
||||
| ``ETHTOOL_A_MODULE_EEPROM_DATA`` | nested | array of bytes from |
|
||||
| | | module EEPROM |
|
||||
+---------------------------------------------+--------+---------------------+
|
||||
|
||||
``ETHTOOL_A_MODULE_EEPROM_DATA`` has an attribute length equal to the amount of
|
||||
bytes driver actually read.
|
||||
|
||||
STATS_GET
|
||||
=========
|
||||
|
||||
Get standard statistics for the interface. Note that this is not
|
||||
a re-implementation of ``ETHTOOL_GSTATS`` which exposed driver-defined
|
||||
stats.
|
||||
|
||||
Request contents:
|
||||
|
||||
======================================= ====== ==========================
|
||||
``ETHTOOL_A_STATS_HEADER`` nested request header
|
||||
``ETHTOOL_A_STATS_GROUPS`` bitset requested groups of stats
|
||||
======================================= ====== ==========================
|
||||
|
||||
Kernel response contents:
|
||||
|
||||
+-----------------------------------+--------+--------------------------------+
|
||||
| ``ETHTOOL_A_STATS_HEADER`` | nested | reply header |
|
||||
+-----------------------------------+--------+--------------------------------+
|
||||
| ``ETHTOOL_A_STATS_GRP`` | nested | one or more group of stats |
|
||||
+-+---------------------------------+--------+--------------------------------+
|
||||
| | ``ETHTOOL_A_STATS_GRP_ID`` | u32 | group ID - ``ETHTOOL_STATS_*`` |
|
||||
+-+---------------------------------+--------+--------------------------------+
|
||||
| | ``ETHTOOL_A_STATS_GRP_SS_ID`` | u32 | string set ID for names |
|
||||
+-+---------------------------------+--------+--------------------------------+
|
||||
| | ``ETHTOOL_A_STATS_GRP_STAT`` | nested | nest containing a statistic |
|
||||
+-+---------------------------------+--------+--------------------------------+
|
||||
| | ``ETHTOOL_A_STATS_GRP_HIST_RX`` | nested | histogram statistic (Rx) |
|
||||
+-+---------------------------------+--------+--------------------------------+
|
||||
| | ``ETHTOOL_A_STATS_GRP_HIST_TX`` | nested | histogram statistic (Tx) |
|
||||
+-+---------------------------------+--------+--------------------------------+
|
||||
|
||||
Users specify which groups of statistics they are requesting via
|
||||
the ``ETHTOOL_A_STATS_GROUPS`` bitset. Currently defined values are:
|
||||
|
||||
====================== ======== ===============================================
|
||||
ETHTOOL_STATS_ETH_MAC eth-mac Basic IEEE 802.3 MAC statistics (30.3.1.1.*)
|
||||
ETHTOOL_STATS_ETH_PHY eth-phy Basic IEEE 802.3 PHY statistics (30.3.2.1.*)
|
||||
ETHTOOL_STATS_ETH_CTRL eth-ctrl Basic IEEE 802.3 MAC Ctrl statistics (30.3.3.*)
|
||||
ETHTOOL_STATS_RMON rmon RMON (RFC 2819) statistics
|
||||
====================== ======== ===============================================
|
||||
|
||||
Each group should have a corresponding ``ETHTOOL_A_STATS_GRP`` in the reply.
|
||||
``ETHTOOL_A_STATS_GRP_ID`` identifies which group's statistics nest contains.
|
||||
``ETHTOOL_A_STATS_GRP_SS_ID`` identifies the string set ID for the names of
|
||||
the statistics in the group, if available.
|
||||
|
||||
Statistics are added to the ``ETHTOOL_A_STATS_GRP`` nest under
|
||||
``ETHTOOL_A_STATS_GRP_STAT``. ``ETHTOOL_A_STATS_GRP_STAT`` should contain
|
||||
single 8 byte (u64) attribute inside - the type of that attribute is
|
||||
the statistic ID and the value is the value of the statistic.
|
||||
Each group has its own interpretation of statistic IDs.
|
||||
Attribute IDs correspond to strings from the string set identified
|
||||
by ``ETHTOOL_A_STATS_GRP_SS_ID``. Complex statistics (such as RMON histogram
|
||||
entries) are also listed inside ``ETHTOOL_A_STATS_GRP`` and do not have
|
||||
a string defined in the string set.
|
||||
|
||||
RMON "histogram" counters count number of packets within given size range.
|
||||
Because RFC does not specify the ranges beyond the standard 1518 MTU devices
|
||||
differ in definition of buckets. For this reason the definition of packet ranges
|
||||
is left to each driver.
|
||||
|
||||
``ETHTOOL_A_STATS_GRP_HIST_RX`` and ``ETHTOOL_A_STATS_GRP_HIST_TX`` nests
|
||||
contain the following attributes:
|
||||
|
||||
================================= ====== ===================================
|
||||
ETHTOOL_A_STATS_RMON_HIST_BKT_LOW u32 low bound of the packet size bucket
|
||||
ETHTOOL_A_STATS_RMON_HIST_BKT_HI u32 high bound of the bucket
|
||||
ETHTOOL_A_STATS_RMON_HIST_VAL u64 packet counter
|
||||
================================= ====== ===================================
|
||||
|
||||
Low and high bounds are inclusive, for example:
|
||||
|
||||
============================= ==== ====
|
||||
RFC statistic low high
|
||||
============================= ==== ====
|
||||
etherStatsPkts64Octets 0 64
|
||||
etherStatsPkts512to1023Octets 512 1023
|
||||
============================= ==== ====
|
||||
|
||||
Request translation
|
||||
===================
|
||||
|
||||
|
|
@ -1357,8 +1552,8 @@ are netlink only.
|
|||
``ETHTOOL_GET_DUMP_FLAG`` n/a
|
||||
``ETHTOOL_GET_DUMP_DATA`` n/a
|
||||
``ETHTOOL_GET_TS_INFO`` ``ETHTOOL_MSG_TSINFO_GET``
|
||||
``ETHTOOL_GMODULEINFO`` n/a
|
||||
``ETHTOOL_GMODULEEEPROM`` n/a
|
||||
``ETHTOOL_GMODULEINFO`` ``ETHTOOL_MSG_MODULE_EEPROM_GET``
|
||||
``ETHTOOL_GMODULEEEPROM`` ``ETHTOOL_MSG_MODULE_EEPROM_GET``
|
||||
``ETHTOOL_GEEE`` ``ETHTOOL_MSG_EEE_GET``
|
||||
``ETHTOOL_SEEE`` ``ETHTOOL_MSG_EEE_SET``
|
||||
``ETHTOOL_GRSSH`` n/a
|
||||
|
|
@ -1373,9 +1568,9 @@ are netlink only.
|
|||
``ETHTOOL_MSG_LINKMODES_SET``
|
||||
``ETHTOOL_PHY_GTUNABLE`` n/a
|
||||
``ETHTOOL_PHY_STUNABLE`` n/a
|
||||
``ETHTOOL_GFECPARAM`` n/a
|
||||
``ETHTOOL_SFECPARAM`` n/a
|
||||
n/a ''ETHTOOL_MSG_CABLE_TEST_ACT''
|
||||
n/a ''ETHTOOL_MSG_CABLE_TEST_TDR_ACT''
|
||||
``ETHTOOL_GFECPARAM`` ``ETHTOOL_MSG_FEC_GET``
|
||||
``ETHTOOL_SFECPARAM`` ``ETHTOOL_MSG_FEC_SET``
|
||||
n/a ``ETHTOOL_MSG_CABLE_TEST_ACT``
|
||||
n/a ``ETHTOOL_MSG_CABLE_TEST_TDR_ACT``
|
||||
n/a ``ETHTOOL_MSG_TUNNEL_INFO_GET``
|
||||
=================================== =====================================
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ Examples for low-level BPF:
|
|||
ret #-1
|
||||
drop: ret #0
|
||||
|
||||
**icmp random packet sampling, 1 in 4**:
|
||||
**icmp random packet sampling, 1 in 4**::
|
||||
|
||||
ldh [12]
|
||||
jne #0x800, drop
|
||||
|
|
|
|||
|
|
@ -76,6 +76,7 @@ Contents:
|
|||
netdevices
|
||||
netfilter-sysctl
|
||||
netif-msg
|
||||
nexthop-group-resilient
|
||||
nf_conntrack-sysctl
|
||||
nf_flowtable
|
||||
openvswitch
|
||||
|
|
|
|||
|
|
@ -1073,7 +1073,9 @@ ip_local_reserved_ports - list of comma separated ranges
|
|||
|
||||
although this is redundant. However such a setting is useful
|
||||
if later the port range is changed to a value that will
|
||||
include the reserved ports.
|
||||
include the reserved ports. Also keep in mind, that overlapping
|
||||
of these ranges may affect probability of selecting ephemeral
|
||||
ports which are right after block of reserved ports.
|
||||
|
||||
Default: Empty
|
||||
|
||||
|
|
@ -1143,6 +1145,12 @@ icmp_echo_ignore_all - BOOLEAN
|
|||
|
||||
Default: 0
|
||||
|
||||
icmp_echo_enable_probe - BOOLEAN
|
||||
If set to one, then the kernel will respond to RFC 8335 PROBE
|
||||
requests sent to it.
|
||||
|
||||
Default: 0
|
||||
|
||||
icmp_echo_ignore_broadcasts - BOOLEAN
|
||||
If set non-zero, then the kernel will ignore all ICMP ECHO and
|
||||
TIMESTAMP requests sent to it via broadcast/multicast.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,293 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========================
|
||||
Resilient Next-hop Groups
|
||||
=========================
|
||||
|
||||
Resilient groups are a type of next-hop group that is aimed at minimizing
|
||||
disruption in flow routing across changes to the group composition and
|
||||
weights of constituent next hops.
|
||||
|
||||
The idea behind resilient hashing groups is best explained in contrast to
|
||||
the legacy multipath next-hop group, which uses the hash-threshold
|
||||
algorithm, described in RFC 2992.
|
||||
|
||||
To select a next hop, hash-threshold algorithm first assigns a range of
|
||||
hashes to each next hop in the group, and then selects the next hop by
|
||||
comparing the SKB hash with the individual ranges. When a next hop is
|
||||
removed from the group, the ranges are recomputed, which leads to
|
||||
reassignment of parts of hash space from one next hop to another. RFC 2992
|
||||
illustrates it thus::
|
||||
|
||||
+-------+-------+-------+-------+-------+
|
||||
| 1 | 2 | 3 | 4 | 5 |
|
||||
+-------+-+-----+---+---+-----+-+-------+
|
||||
| 1 | 2 | 4 | 5 |
|
||||
+---------+---------+---------+---------+
|
||||
|
||||
Before and after deletion of next hop 3
|
||||
under the hash-threshold algorithm.
|
||||
|
||||
Note how next hop 2 gave up part of the hash space in favor of next hop 1,
|
||||
and 4 in favor of 5. While there will usually be some overlap between the
|
||||
previous and the new distribution, some traffic flows change the next hop
|
||||
that they resolve to.
|
||||
|
||||
If a multipath group is used for load-balancing between multiple servers,
|
||||
this hash space reassignment causes an issue that packets from a single
|
||||
flow suddenly end up arriving at a server that does not expect them. This
|
||||
can result in TCP connections being reset.
|
||||
|
||||
If a multipath group is used for load-balancing among available paths to
|
||||
the same server, the issue is that different latencies and reordering along
|
||||
the way causes the packets to arrive in the wrong order, resulting in
|
||||
degraded application performance.
|
||||
|
||||
To mitigate the above-mentioned flow redirection, resilient next-hop groups
|
||||
insert another layer of indirection between the hash space and its
|
||||
constituent next hops: a hash table. The selection algorithm uses SKB hash
|
||||
to choose a hash table bucket, then reads the next hop that this bucket
|
||||
contains, and forwards traffic there.
|
||||
|
||||
This indirection brings an important feature. In the hash-threshold
|
||||
algorithm, the range of hashes associated with a next hop must be
|
||||
continuous. With a hash table, mapping between the hash table buckets and
|
||||
the individual next hops is arbitrary. Therefore when a next hop is deleted
|
||||
the buckets that held it are simply reassigned to other next hops::
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|1|1|1|1|2|2|2|2|3|3|3|3|4|4|4|4|5|5|5|5|
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
v v v v
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|1|1|1|1|2|2|2|2|1|2|4|5|4|4|4|4|5|5|5|5|
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
Before and after deletion of next hop 3
|
||||
under the resilient hashing algorithm.
|
||||
|
||||
When weights of next hops in a group are altered, it may be possible to
|
||||
choose a subset of buckets that are currently not used for forwarding
|
||||
traffic, and use those to satisfy the new next-hop distribution demands,
|
||||
keeping the "busy" buckets intact. This way, established flows are ideally
|
||||
kept being forwarded to the same endpoints through the same paths as before
|
||||
the next-hop group change.
|
||||
|
||||
Algorithm
|
||||
---------
|
||||
|
||||
In a nutshell, the algorithm works as follows. Each next hop deserves a
|
||||
certain number of buckets, according to its weight and the number of
|
||||
buckets in the hash table. In accordance with the source code, we will call
|
||||
this number a "wants count" of a next hop. In case of an event that might
|
||||
cause bucket allocation change, the wants counts for individual next hops
|
||||
are updated.
|
||||
|
||||
Next hops that have fewer buckets than their wants count, are called
|
||||
"underweight". Those that have more are "overweight". If there are no
|
||||
overweight (and therefore no underweight) next hops in the group, it is
|
||||
said to be "balanced".
|
||||
|
||||
Each bucket maintains a last-used timer. Every time a packet is forwarded
|
||||
through a bucket, this timer is updated to current jiffies value. One
|
||||
attribute of a resilient group is then the "idle timer", which is the
|
||||
amount of time that a bucket must not be hit by traffic in order for it to
|
||||
be considered "idle". Buckets that are not idle are busy.
|
||||
|
||||
After assigning wants counts to next hops, an "upkeep" algorithm runs. For
|
||||
buckets:
|
||||
|
||||
1) that have no assigned next hop, or
|
||||
2) whose next hop has been removed, or
|
||||
3) that are idle and their next hop is overweight,
|
||||
|
||||
upkeep changes the next hop that the bucket references to one of the
|
||||
underweight next hops. If, after considering all buckets in this manner,
|
||||
there are still underweight next hops, another upkeep run is scheduled to a
|
||||
future time.
|
||||
|
||||
There may not be enough "idle" buckets to satisfy the updated wants counts
|
||||
of all next hops. Another attribute of a resilient group is the "unbalanced
|
||||
timer". This timer can be set to 0, in which case the table will stay out
|
||||
of balance until idle buckets do appear, possibly never. If set to a
|
||||
non-zero value, the value represents the period of time that the table is
|
||||
permitted to stay out of balance.
|
||||
|
||||
With this in mind, we update the above list of conditions with one more
|
||||
item. Thus buckets:
|
||||
|
||||
4) whose next hop is overweight, and the amount of time that the table has
|
||||
been out of balance exceeds the unbalanced timer, if that is non-zero,
|
||||
|
||||
\... are migrated as well.
|
||||
|
||||
Offloading & Driver Feedback
|
||||
----------------------------
|
||||
|
||||
When offloading resilient groups, the algorithm that distributes buckets
|
||||
among next hops is still the one in SW. Drivers are notified of updates to
|
||||
next hop groups in the following three ways:
|
||||
|
||||
- Full group notification with the type
|
||||
``NH_NOTIFIER_INFO_TYPE_RES_TABLE``. This is used just after the group is
|
||||
created and buckets populated for the first time.
|
||||
|
||||
- Single-bucket notifications of the type
|
||||
``NH_NOTIFIER_INFO_TYPE_RES_BUCKET``, which is used for notifications of
|
||||
individual migrations within an already-established group.
|
||||
|
||||
- Pre-replace notification, ``NEXTHOP_EVENT_RES_TABLE_PRE_REPLACE``. This
|
||||
is sent before the group is replaced, and is a way for the driver to veto
|
||||
the group before committing anything to the HW.
|
||||
|
||||
Some single-bucket notifications are forced, as indicated by the "force"
|
||||
flag in the notification. Those are used for the cases where e.g. the next
|
||||
hop associated with the bucket was removed, and the bucket really must be
|
||||
migrated.
|
||||
|
||||
Non-forced notifications can be overridden by the driver by returning an
|
||||
error code. The use case for this is that the driver notifies the HW that a
|
||||
bucket should be migrated, but the HW discovers that the bucket has in fact
|
||||
been hit by traffic.
|
||||
|
||||
A second way for the HW to report that a bucket is busy is through the
|
||||
``nexthop_res_grp_activity_update()`` API. The buckets identified this way
|
||||
as busy are treated as if traffic hit them.
|
||||
|
||||
Offloaded buckets should be flagged as either "offload" or "trap". This is
|
||||
done through the ``nexthop_bucket_set_hw_flags()`` API.
|
||||
|
||||
Netlink UAPI
|
||||
------------
|
||||
|
||||
Resilient Group Replacement
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Resilient groups are configured using the ``RTM_NEWNEXTHOP`` message in the
|
||||
same manner as other multipath groups. The following changes apply to the
|
||||
attributes passed in the netlink message:
|
||||
|
||||
=================== =========================================================
|
||||
``NHA_GROUP_TYPE`` Should be ``NEXTHOP_GRP_TYPE_RES`` for resilient group.
|
||||
``NHA_RES_GROUP`` A nest that contains attributes specific to resilient
|
||||
groups.
|
||||
=================== =========================================================
|
||||
|
||||
``NHA_RES_GROUP`` payload:
|
||||
|
||||
=================================== =========================================
|
||||
``NHA_RES_GROUP_BUCKETS`` Number of buckets in the hash table.
|
||||
``NHA_RES_GROUP_IDLE_TIMER`` Idle timer in units of clock_t.
|
||||
``NHA_RES_GROUP_UNBALANCED_TIMER`` Unbalanced timer in units of clock_t.
|
||||
=================================== =========================================
|
||||
|
||||
Next Hop Get
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Requests to get resilient next-hop groups use the ``RTM_GETNEXTHOP``
|
||||
message in exactly the same way as other next hop get requests. The
|
||||
response attributes match the replacement attributes cited above, except
|
||||
``NHA_RES_GROUP`` payload will include the following attribute:
|
||||
|
||||
=================================== =========================================
|
||||
``NHA_RES_GROUP_UNBALANCED_TIME`` How long has the resilient group been out
|
||||
of balance, in units of clock_t.
|
||||
=================================== =========================================
|
||||
|
||||
Bucket Get
|
||||
^^^^^^^^^^
|
||||
|
||||
The message ``RTM_GETNEXTHOPBUCKET`` without the ``NLM_F_DUMP`` flag is
|
||||
used to request a single bucket. The attributes recognized at get requests
|
||||
are:
|
||||
|
||||
=================== =========================================================
|
||||
``NHA_ID`` ID of the next-hop group that the bucket belongs to.
|
||||
``NHA_RES_BUCKET`` A nest that contains attributes specific to bucket.
|
||||
=================== =========================================================
|
||||
|
||||
``NHA_RES_BUCKET`` payload:
|
||||
|
||||
======================== ====================================================
|
||||
``NHA_RES_BUCKET_INDEX`` Index of bucket in the resilient table.
|
||||
======================== ====================================================
|
||||
|
||||
Bucket Dumps
|
||||
^^^^^^^^^^^^
|
||||
|
||||
The message ``RTM_GETNEXTHOPBUCKET`` with the ``NLM_F_DUMP`` flag is used
|
||||
to request a dump of matching buckets. The attributes recognized at dump
|
||||
requests are:
|
||||
|
||||
=================== =========================================================
|
||||
``NHA_ID`` If specified, limits the dump to just the next-hop group
|
||||
with this ID.
|
||||
``NHA_OIF`` If specified, limits the dump to buckets that contain
|
||||
next hops that use the device with this ifindex.
|
||||
``NHA_MASTER`` If specified, limits the dump to buckets that contain
|
||||
next hops that use a device in the VRF with this ifindex.
|
||||
``NHA_RES_BUCKET`` A nest that contains attributes specific to bucket.
|
||||
=================== =========================================================
|
||||
|
||||
``NHA_RES_BUCKET`` payload:
|
||||
|
||||
======================== ====================================================
|
||||
``NHA_RES_BUCKET_NH_ID`` If specified, limits the dump to just the buckets
|
||||
that contain the next hop with this ID.
|
||||
======================== ====================================================
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
To illustrate the usage, consider the following commands::
|
||||
|
||||
# ip nexthop add id 1 via 192.0.2.2 dev eth0
|
||||
# ip nexthop add id 2 via 192.0.2.3 dev eth0
|
||||
# ip nexthop add id 10 group 1/2 type resilient \
|
||||
buckets 8 idle_timer 60 unbalanced_timer 300
|
||||
|
||||
The last command creates a resilient next-hop group. It will have 8 buckets
|
||||
(which is unusually low number, and used here for demonstration purposes
|
||||
only), each bucket will be considered idle when no traffic hits it for at
|
||||
least 60 seconds, and if the table remains out of balance for 300 seconds,
|
||||
it will be forcefully brought into balance.
|
||||
|
||||
Changing next-hop weights leads to change in bucket allocation::
|
||||
|
||||
# ip nexthop replace id 10 group 1,3/2 type resilient
|
||||
|
||||
This can be confirmed by looking at individual buckets::
|
||||
|
||||
# ip nexthop bucket show id 10
|
||||
id 10 index 0 idle_time 5.59 nhid 1
|
||||
id 10 index 1 idle_time 5.59 nhid 1
|
||||
id 10 index 2 idle_time 8.74 nhid 2
|
||||
id 10 index 3 idle_time 8.74 nhid 2
|
||||
id 10 index 4 idle_time 8.74 nhid 1
|
||||
id 10 index 5 idle_time 8.74 nhid 1
|
||||
id 10 index 6 idle_time 8.74 nhid 1
|
||||
id 10 index 7 idle_time 8.74 nhid 1
|
||||
|
||||
Note the two buckets that have a shorter idle time. Those are the ones that
|
||||
were migrated after the next-hop replace command to satisfy the new demand
|
||||
that next hop 1 be given 6 buckets instead of 4.
|
||||
|
||||
Netdevsim
|
||||
---------
|
||||
|
||||
The netdevsim driver implements a mock offload of resilient groups, and
|
||||
exposes debugfs interface that allows marking individual buckets as busy.
|
||||
For example, the following will mark bucket 23 in next-hop group 10 as
|
||||
active::
|
||||
|
||||
# echo 10 23 > /sys/kernel/debug/netdevsim/netdevsim10/fib/nexthop_bucket_activity
|
||||
|
||||
In addition, another debugfs interface can be used to configure that the
|
||||
next attempt to migrate a bucket should fail::
|
||||
|
||||
# echo 1 > /sys/kernel/debug/netdevsim/netdevsim10/fib/fail_nexthop_bucket_replace
|
||||
|
||||
Besides serving as an example, the interfaces that netdevsim exposes are
|
||||
useful in automated testing, and
|
||||
``tools/testing/selftests/drivers/net/netdevsim/nexthop.sh`` makes use of
|
||||
them to test the algorithm.
|
||||
|
|
@ -4,35 +4,38 @@
|
|||
Netfilter's flowtable infrastructure
|
||||
====================================
|
||||
|
||||
This documentation describes the software flowtable infrastructure available in
|
||||
Netfilter since Linux kernel 4.16.
|
||||
This documentation describes the Netfilter flowtable infrastructure which allows
|
||||
you to define a fastpath through the flowtable datapath. This infrastructure
|
||||
also provides hardware offload support. The flowtable supports for the layer 3
|
||||
IPv4 and IPv6 and the layer 4 TCP and UDP protocols.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Initial packets follow the classic forwarding path, once the flow enters the
|
||||
established state according to the conntrack semantics (ie. we have seen traffic
|
||||
in both directions), then you can decide to offload the flow to the flowtable
|
||||
from the forward chain via the 'flow offload' action available in nftables.
|
||||
Once the first packet of the flow successfully goes through the IP forwarding
|
||||
path, from the second packet on, you might decide to offload the flow to the
|
||||
flowtable through your ruleset. The flowtable infrastructure provides a rule
|
||||
action that allows you to specify when to add a flow to the flowtable.
|
||||
|
||||
Packets that find an entry in the flowtable (ie. flowtable hit) are sent to the
|
||||
output netdevice via neigh_xmit(), hence, they bypass the classic forwarding
|
||||
path (the visible effect is that you do not see these packets from any of the
|
||||
netfilter hooks coming after the ingress). In case of flowtable miss, the packet
|
||||
follows the classic forward path.
|
||||
A packet that finds a matching entry in the flowtable (ie. flowtable hit) is
|
||||
transmitted to the output netdevice via neigh_xmit(), hence, packets bypass the
|
||||
classic IP forwarding path (the visible effect is that you do not see these
|
||||
packets from any of the Netfilter hooks coming after ingress). In case that
|
||||
there is no matching entry in the flowtable (ie. flowtable miss), the packet
|
||||
follows the classic IP forwarding path.
|
||||
|
||||
The flowtable uses a resizable hashtable, lookups are based on the following
|
||||
7-tuple selectors: source, destination, layer 3 and layer 4 protocols, source
|
||||
and destination ports and the input interface (useful in case there are several
|
||||
conntrack zones in place).
|
||||
The flowtable uses a resizable hashtable. Lookups are based on the following
|
||||
n-tuple selectors: layer 2 protocol encapsulation (VLAN and PPPoE), layer 3
|
||||
source and destination, layer 4 source and destination ports and the input
|
||||
interface (useful in case there are several conntrack zones in place).
|
||||
|
||||
Flowtables are populated via the 'flow offload' nftables action, so the user can
|
||||
selectively specify what flows are placed into the flow table. Hence, packets
|
||||
follow the classic forwarding path unless the user explicitly instruct packets
|
||||
to use this new alternative forwarding path via nftables policy.
|
||||
The 'flow add' action allows you to populate the flowtable, the user selectively
|
||||
specifies what flows are placed into the flowtable. Hence, packets follow the
|
||||
classic IP forwarding path unless the user explicitly instruct flows to use this
|
||||
new alternative forwarding path via policy.
|
||||
|
||||
This is represented in Fig.1, which describes the classic forwarding path
|
||||
including the Netfilter hooks and the flowtable fastpath bypass.
|
||||
The flowtable datapath is represented in Fig.1, which describes the classic IP
|
||||
forwarding path including the Netfilter hooks and the flowtable fastpath bypass.
|
||||
|
||||
::
|
||||
|
||||
|
|
@ -67,11 +70,13 @@ including the Netfilter hooks and the flowtable fastpath bypass.
|
|||
Fig.1 Netfilter hooks and flowtable interactions
|
||||
|
||||
The flowtable entry also stores the NAT configuration, so all packets are
|
||||
mangled according to the NAT policy that matches the initial packets that went
|
||||
through the classic forwarding path. The TTL is decremented before calling
|
||||
neigh_xmit(). Fragmented traffic is passed up to follow the classic forwarding
|
||||
path given that the transport selectors are missing, therefore flowtable lookup
|
||||
is not possible.
|
||||
mangled according to the NAT policy that is specified from the classic IP
|
||||
forwarding path. The TTL is decremented before calling neigh_xmit(). Fragmented
|
||||
traffic is passed up to follow the classic IP forwarding path given that the
|
||||
transport header is missing, in this case, flowtable lookups are not possible.
|
||||
TCP RST and FIN packets are also passed up to the classic IP forwarding path to
|
||||
release the flow gracefully. Packets that exceed the MTU are also passed up to
|
||||
the classic forwarding path to report packet-too-big ICMP errors to the sender.
|
||||
|
||||
Example configuration
|
||||
---------------------
|
||||
|
|
@ -85,7 +90,7 @@ flowtable and add one rule to your forward chain::
|
|||
}
|
||||
chain y {
|
||||
type filter hook forward priority 0; policy accept;
|
||||
ip protocol tcp flow offload @f
|
||||
ip protocol tcp flow add @f
|
||||
counter packets 0 bytes 0
|
||||
}
|
||||
}
|
||||
|
|
@ -103,6 +108,119 @@ flow is offloaded, you will observe that the counter rule in the example above
|
|||
does not get updated for the packets that are being forwarded through the
|
||||
forwarding bypass.
|
||||
|
||||
You can identify offloaded flows through the [OFFLOAD] tag when listing your
|
||||
connection tracking table.
|
||||
|
||||
::
|
||||
|
||||
# conntrack -L
|
||||
tcp 6 src=10.141.10.2 dst=192.168.10.2 sport=52728 dport=5201 src=192.168.10.2 dst=192.168.10.1 sport=5201 dport=52728 [OFFLOAD] mark=0 use=2
|
||||
|
||||
|
||||
Layer 2 encapsulation
|
||||
---------------------
|
||||
|
||||
Since Linux kernel 5.13, the flowtable infrastructure discovers the real
|
||||
netdevice behind VLAN and PPPoE netdevices. The flowtable software datapath
|
||||
parses the VLAN and PPPoE layer 2 headers to extract the ethertype and the
|
||||
VLAN ID / PPPoE session ID which are used for the flowtable lookups. The
|
||||
flowtable datapath also deals with layer 2 decapsulation.
|
||||
|
||||
You do not need to add the PPPoE and the VLAN devices to your flowtable,
|
||||
instead the real device is sufficient for the flowtable to track your flows.
|
||||
|
||||
Bridge and IP forwarding
|
||||
------------------------
|
||||
|
||||
Since Linux kernel 5.13, you can add bridge ports to the flowtable. The
|
||||
flowtable infrastructure discovers the topology behind the bridge device. This
|
||||
allows the flowtable to define a fastpath bypass between the bridge ports
|
||||
(represented as eth1 and eth2 in the example figure below) and the gateway
|
||||
device (represented as eth0) in your switch/router.
|
||||
|
||||
::
|
||||
|
||||
fastpath bypass
|
||||
.-------------------------.
|
||||
/ \
|
||||
| IP forwarding |
|
||||
| / \ \/
|
||||
| br0 eth0 ..... eth0
|
||||
. / \ *host B*
|
||||
-> eth1 eth2
|
||||
. *switch/router*
|
||||
.
|
||||
.
|
||||
eth0
|
||||
*host A*
|
||||
|
||||
The flowtable infrastructure also supports for bridge VLAN filtering actions
|
||||
such as PVID and untagged. You can also stack a classic VLAN device on top of
|
||||
your bridge port.
|
||||
|
||||
If you would like that your flowtable defines a fastpath between your bridge
|
||||
ports and your IP forwarding path, you have to add your bridge ports (as
|
||||
represented by the real netdevice) to your flowtable definition.
|
||||
|
||||
Counters
|
||||
--------
|
||||
|
||||
The flowtable can synchronize packet and byte counters with the existing
|
||||
connection tracking entry by specifying the counter statement in your flowtable
|
||||
definition, e.g.
|
||||
|
||||
::
|
||||
|
||||
table inet x {
|
||||
flowtable f {
|
||||
hook ingress priority 0; devices = { eth0, eth1 };
|
||||
counter
|
||||
}
|
||||
}
|
||||
|
||||
Counter support is available since Linux kernel 5.7.
|
||||
|
||||
Hardware offload
|
||||
----------------
|
||||
|
||||
If your network device provides hardware offload support, you can turn it on by
|
||||
means of the 'offload' flag in your flowtable definition, e.g.
|
||||
|
||||
::
|
||||
|
||||
table inet x {
|
||||
flowtable f {
|
||||
hook ingress priority 0; devices = { eth0, eth1 };
|
||||
flags offload;
|
||||
}
|
||||
}
|
||||
|
||||
There is a workqueue that adds the flows to the hardware. Note that a few
|
||||
packets might still run over the flowtable software path until the workqueue has
|
||||
a chance to offload the flow to the network device.
|
||||
|
||||
You can identify hardware offloaded flows through the [HW_OFFLOAD] tag when
|
||||
listing your connection tracking table. Please, note that the [OFFLOAD] tag
|
||||
refers to the software offload mode, so there is a distinction between [OFFLOAD]
|
||||
which refers to the software flowtable fastpath and [HW_OFFLOAD] which refers
|
||||
to the hardware offload datapath being used by the flow.
|
||||
|
||||
The flowtable hardware offload infrastructure also supports for the DSA
|
||||
(Distributed Switch Architecture).
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
|
||||
The flowtable behaves like a cache. The flowtable entries might get stale if
|
||||
either the destination MAC address or the egress netdevice that is used for
|
||||
transmission changes.
|
||||
|
||||
This might be a problem if:
|
||||
|
||||
- You run the flowtable in software mode and you combine bridge and IP
|
||||
forwarding in your setup.
|
||||
- Hardware offload is enabled.
|
||||
|
||||
More reading
|
||||
------------
|
||||
|
||||
|
|
|
|||
|
|
@ -80,8 +80,8 @@ values of phy_interface_t must be understood from the perspective of the PHY
|
|||
device itself, leading to the following:
|
||||
|
||||
* PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
|
||||
internal delay by itself, it assumes that either the Ethernet MAC (if capable
|
||||
or the PCB traces) insert the correct 1.5-2ns delay
|
||||
internal delay by itself, it assumes that either the Ethernet MAC (if capable)
|
||||
or the PCB traces insert the correct 1.5-2ns delay
|
||||
|
||||
* PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay
|
||||
for the transmit data lines (TXD[3:0]) processed by the PHY device
|
||||
|
|
|
|||
|
|
@ -44,8 +44,27 @@ If `-s` is specified once the detailed errors won't be shown.
|
|||
Protocol-specific statistics
|
||||
----------------------------
|
||||
|
||||
Some of the interfaces used for configuring devices are also able
|
||||
to report related statistics. For example ethtool interface used
|
||||
Protocol-specific statistics are exposed via relevant interfaces,
|
||||
the same interfaces as are used to configure them.
|
||||
|
||||
ethtool
|
||||
~~~~~~~
|
||||
|
||||
Ethtool exposes common low-level statistics.
|
||||
All the standard statistics are expected to be maintained
|
||||
by the device, not the driver (as opposed to driver-defined stats
|
||||
described in the next section which mix software and hardware stats).
|
||||
For devices which contain unmanaged
|
||||
switches (e.g. legacy SR-IOV or multi-host NICs) the events counted
|
||||
may not pertain exclusively to the packets destined to
|
||||
the local host interface. In other words the events may
|
||||
be counted at the network port (MAC/PHY blocks) without separation
|
||||
for different host side (PCIe) devices. Such ambiguity must not
|
||||
be present when internal switch is managed by Linux (so called
|
||||
switchdev mode for NICs).
|
||||
|
||||
Standard ethtool statistics can be accessed via the interfaces used
|
||||
for configuration. For example ethtool interface used
|
||||
to configure pause frames can report corresponding hardware counters::
|
||||
|
||||
$ ethtool --include-statistics -a eth0
|
||||
|
|
@ -57,6 +76,27 @@ to configure pause frames can report corresponding hardware counters::
|
|||
tx_pause_frames: 1
|
||||
rx_pause_frames: 1
|
||||
|
||||
General Ethernet statistics not associated with any particular
|
||||
functionality are exposed via ``ethtool -S $ifc`` by specifying
|
||||
the ``--groups`` parameter::
|
||||
|
||||
$ ethtool -S eth0 --groups eth-phy eth-mac eth-ctrl rmon
|
||||
Stats for eth0:
|
||||
eth-phy-SymbolErrorDuringCarrier: 0
|
||||
eth-mac-FramesTransmittedOK: 1
|
||||
eth-mac-FrameTooLongErrors: 1
|
||||
eth-ctrl-MACControlFramesTransmitted: 1
|
||||
eth-ctrl-MACControlFramesReceived: 0
|
||||
eth-ctrl-UnsupportedOpcodesReceived: 1
|
||||
rmon-etherStatsUndersizePkts: 1
|
||||
rmon-etherStatsJabbers: 0
|
||||
rmon-rx-etherStatsPkts64Octets: 1
|
||||
rmon-rx-etherStatsPkts65to127Octets: 0
|
||||
rmon-rx-etherStatsPkts128to255Octets: 0
|
||||
rmon-tx-etherStatsPkts64Octets: 2
|
||||
rmon-tx-etherStatsPkts65to127Octets: 3
|
||||
rmon-tx-etherStatsPkts128to255Octets: 0
|
||||
|
||||
Driver-defined statistics
|
||||
-------------------------
|
||||
|
||||
|
|
@ -130,6 +170,7 @@ the `ETHTOOL_FLAG_STATS` flag in `ETHTOOL_A_HEADER_FLAGS`. Currently
|
|||
statistics are supported in the following commands:
|
||||
|
||||
- `ETHTOOL_MSG_PAUSE_GET`
|
||||
- `ETHTOOL_MSG_FEC_GET`
|
||||
|
||||
debugfs
|
||||
-------
|
||||
|
|
@ -176,3 +217,4 @@ translated to netlink attributes when dumped. Drivers must not overwrite
|
|||
the statistics they don't report with 0.
|
||||
|
||||
- ethtool_pause_stats()
|
||||
- ethtool_fec_stats()
|
||||
|
|
|
|||
|
|
@ -181,18 +181,41 @@ To offloading L2 bridging, the switchdev driver/device should support:
|
|||
Static FDB Entries
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The switchdev driver should implement ndo_fdb_add, ndo_fdb_del and ndo_fdb_dump
|
||||
to support static FDB entries installed to the device. Static bridge FDB
|
||||
entries are installed, for example, using iproute2 bridge cmd::
|
||||
A driver which implements the ``ndo_fdb_add``, ``ndo_fdb_del`` and
|
||||
``ndo_fdb_dump`` operations is able to support the command below, which adds a
|
||||
static bridge FDB entry::
|
||||
|
||||
bridge fdb add ADDR dev DEV [vlan VID] [self]
|
||||
bridge fdb add dev DEV ADDRESS [vlan VID] [self] static
|
||||
|
||||
The driver should use the helper switchdev_port_fdb_xxx ops for ndo_fdb_xxx
|
||||
ops, and handle add/delete/dump of SWITCHDEV_OBJ_ID_PORT_FDB object using
|
||||
switchdev_port_obj_xxx ops.
|
||||
(the "static" keyword is non-optional: if not specified, the entry defaults to
|
||||
being "local", which means that it should not be forwarded)
|
||||
|
||||
XXX: what should be done if offloading this rule to hardware fails (for
|
||||
example, due to full capacity in hardware tables) ?
|
||||
The "self" keyword (optional because it is implicit) has the role of
|
||||
instructing the kernel to fulfill the operation through the ``ndo_fdb_add``
|
||||
implementation of the ``DEV`` device itself. If ``DEV`` is a bridge port, this
|
||||
will bypass the bridge and therefore leave the software database out of sync
|
||||
with the hardware one.
|
||||
|
||||
To avoid this, the "master" keyword can be used::
|
||||
|
||||
bridge fdb add dev DEV ADDRESS [vlan VID] master static
|
||||
|
||||
The above command instructs the kernel to search for a master interface of
|
||||
``DEV`` and fulfill the operation through the ``ndo_fdb_add`` method of that.
|
||||
This time, the bridge generates a ``SWITCHDEV_FDB_ADD_TO_DEVICE`` notification
|
||||
which the port driver can handle and use it to program its hardware table. This
|
||||
way, the software and the hardware database will both contain this static FDB
|
||||
entry.
|
||||
|
||||
Note: for new switchdev drivers that offload the Linux bridge, implementing the
|
||||
``ndo_fdb_add`` and ``ndo_fdb_del`` bridge bypass methods is strongly
|
||||
discouraged: all static FDB entries should be added on a bridge port using the
|
||||
"master" flag. The ``ndo_fdb_dump`` is an exception and can be implemented to
|
||||
visualize the hardware tables, if the device does not have an interrupt for
|
||||
notifying the operating system of newly learned/forgotten dynamic FDB
|
||||
addresses. In that case, the hardware FDB might end up having entries that the
|
||||
software FDB does not, and implementing ``ndo_fdb_dump`` is the only way to see
|
||||
them.
|
||||
|
||||
Note: by default, the bridge does not filter on VLAN and only bridges untagged
|
||||
traffic. To enable VLAN support, turn on VLAN filtering::
|
||||
|
|
@ -385,3 +408,156 @@ The driver can monitor for updates to arp_tbl using the netevent notifier
|
|||
NETEVENT_NEIGH_UPDATE. The device can be programmed with resolved nexthops
|
||||
for the routes as arp_tbl updates. The driver implements ndo_neigh_destroy
|
||||
to know when arp_tbl neighbor entries are purged from the port.
|
||||
|
||||
Device driver expected behavior
|
||||
-------------------------------
|
||||
|
||||
Below is a set of defined behavior that switchdev enabled network devices must
|
||||
adhere to.
|
||||
|
||||
Configuration-less state
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Upon driver bring up, the network devices must be fully operational, and the
|
||||
backing driver must configure the network device such that it is possible to
|
||||
send and receive traffic to this network device and it is properly separated
|
||||
from other network devices/ports (e.g.: as is frequent with a switch ASIC). How
|
||||
this is achieved is heavily hardware dependent, but a simple solution can be to
|
||||
use per-port VLAN identifiers unless a better mechanism is available
|
||||
(proprietary metadata for each network port for instance).
|
||||
|
||||
The network device must be capable of running a full IP protocol stack
|
||||
including multicast, DHCP, IPv4/6, etc. If necessary, it should program the
|
||||
appropriate filters for VLAN, multicast, unicast etc. The underlying device
|
||||
driver must effectively be configured in a similar fashion to what it would do
|
||||
when IGMP snooping is enabled for IP multicast over these switchdev network
|
||||
devices and unsolicited multicast must be filtered as early as possible in
|
||||
the hardware.
|
||||
|
||||
When configuring VLANs on top of the network device, all VLANs must be working,
|
||||
irrespective of the state of other network devices (e.g.: other ports being part
|
||||
of a VLAN-aware bridge doing ingress VID checking). See below for details.
|
||||
|
||||
If the device implements e.g.: VLAN filtering, putting the interface in
|
||||
promiscuous mode should allow the reception of all VLAN tags (including those
|
||||
not present in the filter(s)).
|
||||
|
||||
Bridged switch ports
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When a switchdev enabled network device is added as a bridge member, it should
|
||||
not disrupt any functionality of non-bridged network devices and they
|
||||
should continue to behave as normal network devices. Depending on the bridge
|
||||
configuration knobs below, the expected behavior is documented.
|
||||
|
||||
Bridge VLAN filtering
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The Linux bridge allows the configuration of a VLAN filtering mode (statically,
|
||||
at device creation time, and dynamically, during run time) which must be
|
||||
observed by the underlying switchdev network device/hardware:
|
||||
|
||||
- with VLAN filtering turned off: the bridge is strictly VLAN unaware and its
|
||||
data path will process all Ethernet frames as if they are VLAN-untagged.
|
||||
The bridge VLAN database can still be modified, but the modifications should
|
||||
have no effect while VLAN filtering is turned off. Frames ingressing the
|
||||
device with a VID that is not programmed into the bridge/switch's VLAN table
|
||||
must be forwarded and may be processed using a VLAN device (see below).
|
||||
|
||||
- with VLAN filtering turned on: the bridge is VLAN-aware and frames ingressing
|
||||
the device with a VID that is not programmed into the bridges/switch's VLAN
|
||||
table must be dropped (strict VID checking).
|
||||
|
||||
When there is a VLAN device (e.g: sw0p1.100) configured on top of a switchdev
|
||||
network device which is a bridge port member, the behavior of the software
|
||||
network stack must be preserved, or the configuration must be refused if that
|
||||
is not possible.
|
||||
|
||||
- with VLAN filtering turned off, the bridge will process all ingress traffic
|
||||
for the port, except for the traffic tagged with a VLAN ID destined for a
|
||||
VLAN upper. The VLAN upper interface (which consumes the VLAN tag) can even
|
||||
be added to a second bridge, which includes other switch ports or software
|
||||
interfaces. Some approaches to ensure that the forwarding domain for traffic
|
||||
belonging to the VLAN upper interfaces are managed properly:
|
||||
|
||||
* If forwarding destinations can be managed per VLAN, the hardware could be
|
||||
configured to map all traffic, except the packets tagged with a VID
|
||||
belonging to a VLAN upper interface, to an internal VID corresponding to
|
||||
untagged packets. This internal VID spans all ports of the VLAN-unaware
|
||||
bridge. The VID corresponding to the VLAN upper interface spans the
|
||||
physical port of that VLAN interface, as well as the other ports that
|
||||
might be bridged with it.
|
||||
* Treat bridge ports with VLAN upper interfaces as standalone, and let
|
||||
forwarding be handled in the software data path.
|
||||
|
||||
- with VLAN filtering turned on, these VLAN devices can be created as long as
|
||||
the bridge does not have an existing VLAN entry with the same VID on any
|
||||
bridge port. These VLAN devices cannot be enslaved into the bridge since they
|
||||
duplicate functionality/use case with the bridge's VLAN data path processing.
|
||||
|
||||
Non-bridged network ports of the same switch fabric must not be disturbed in any
|
||||
way by the enabling of VLAN filtering on the bridge device(s). If the VLAN
|
||||
filtering setting is global to the entire chip, then the standalone ports
|
||||
should indicate to the network stack that VLAN filtering is required by setting
|
||||
'rx-vlan-filter: on [fixed]' in the ethtool features.
|
||||
|
||||
Because VLAN filtering can be turned on/off at runtime, the switchdev driver
|
||||
must be able to reconfigure the underlying hardware on the fly to honor the
|
||||
toggling of that option and behave appropriately. If that is not possible, the
|
||||
switchdev driver can also refuse to support dynamic toggling of the VLAN
|
||||
filtering knob at runtime and require a destruction of the bridge device(s) and
|
||||
creation of new bridge device(s) with a different VLAN filtering value to
|
||||
ensure VLAN awareness is pushed down to the hardware.
|
||||
|
||||
Even when VLAN filtering in the bridge is turned off, the underlying switch
|
||||
hardware and driver may still configure itself in a VLAN-aware mode provided
|
||||
that the behavior described above is observed.
|
||||
|
||||
The VLAN protocol of the bridge plays a role in deciding whether a packet is
|
||||
treated as tagged or not: a bridge using the 802.1ad protocol must treat both
|
||||
VLAN-untagged packets, as well as packets tagged with 802.1Q headers, as
|
||||
untagged.
|
||||
|
||||
The 802.1p (VID 0) tagged packets must be treated in the same way by the device
|
||||
as untagged packets, since the bridge device does not allow the manipulation of
|
||||
VID 0 in its database.
|
||||
|
||||
When the bridge has VLAN filtering enabled and a PVID is not configured on the
|
||||
ingress port, untagged and 802.1p tagged packets must be dropped. When the bridge
|
||||
has VLAN filtering enabled and a PVID exists on the ingress port, untagged and
|
||||
priority-tagged packets must be accepted and forwarded according to the
|
||||
bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering
|
||||
disabled, the presence/lack of a PVID should not influence the packet
|
||||
forwarding decision.
|
||||
|
||||
Bridge IGMP snooping
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The Linux bridge allows the configuration of IGMP snooping (statically, at
|
||||
interface creation time, or dynamically, during runtime) which must be observed
|
||||
by the underlying switchdev network device/hardware in the following way:
|
||||
|
||||
- when IGMP snooping is turned off, multicast traffic must be flooded to all
|
||||
ports within the same bridge that have mcast_flood=true. The CPU/management
|
||||
port should ideally not be flooded (unless the ingress interface has
|
||||
IFF_ALLMULTI or IFF_PROMISC) and continue to learn multicast traffic through
|
||||
the network stack notifications. If the hardware is not capable of doing that
|
||||
then the CPU/management port must also be flooded and multicast filtering
|
||||
happens in software.
|
||||
|
||||
- when IGMP snooping is turned on, multicast traffic must selectively flow
|
||||
to the appropriate network ports (including CPU/management port). Flooding of
|
||||
unknown multicast should be only towards the ports connected to a multicast
|
||||
router (the local device may also act as a multicast router).
|
||||
|
||||
The switch must adhere to RFC 4541 and flood multicast traffic accordingly
|
||||
since that is what the Linux bridge implementation does.
|
||||
|
||||
Because IGMP snooping can be turned on/off at runtime, the switchdev driver
|
||||
must be able to reconfigure the underlying hardware on the fly to honor the
|
||||
toggling of that option and behave appropriately.
|
||||
|
||||
A switchdev driver can also refuse to support dynamic toggling of the multicast
|
||||
snooping knob at runtime and require the destruction of the bridge device(s)
|
||||
and creation of a new bridge device(s) with a different multicast snooping
|
||||
value.
|
||||
|
|
|
|||
|
|
@ -630,30 +630,45 @@ hardware timestamping on it. This is because the SO_TIMESTAMPING API does not
|
|||
allow the delivery of multiple hardware timestamps for the same packet, so
|
||||
anybody else except for the DSA switch port must be prevented from doing so.
|
||||
|
||||
In code, DSA provides for most of the infrastructure for timestamping already,
|
||||
in generic code: a BPF classifier (``ptp_classify_raw``) is used to identify
|
||||
PTP event messages (any other packets, including PTP general messages, are not
|
||||
timestamped), and provides two hooks to drivers:
|
||||
In the generic layer, DSA provides the following infrastructure for PTP
|
||||
timestamping:
|
||||
|
||||
- ``.port_txtstamp()``: The driver is passed a clone of the timestampable skb
|
||||
to be transmitted, before actually transmitting it. Typically, a switch will
|
||||
have a PTP TX timestamp register (or sometimes a FIFO) where the timestamp
|
||||
becomes available. There may be an IRQ that is raised upon this timestamp's
|
||||
availability, or the driver might have to poll after invoking
|
||||
``dev_queue_xmit()`` towards the host interface. Either way, in the
|
||||
``.port_txtstamp()`` method, the driver only needs to save the clone for
|
||||
later use (when the timestamp becomes available). Each skb is annotated with
|
||||
a pointer to its clone, in ``DSA_SKB_CB(skb)->clone``, to ease the driver's
|
||||
job of keeping track of which clone belongs to which skb.
|
||||
- ``.port_txtstamp()``: a hook called prior to the transmission of
|
||||
packets with a hardware TX timestamping request from user space.
|
||||
This is required for two-step timestamping, since the hardware
|
||||
timestamp becomes available after the actual MAC transmission, so the
|
||||
driver must be prepared to correlate the timestamp with the original
|
||||
packet so that it can re-enqueue the packet back into the socket's
|
||||
error queue. To save the packet for when the timestamp becomes
|
||||
available, the driver can call ``skb_clone_sk`` , save the clone pointer
|
||||
in skb->cb and enqueue a tx skb queue. Typically, a switch will have a
|
||||
PTP TX timestamp register (or sometimes a FIFO) where the timestamp
|
||||
becomes available. In case of a FIFO, the hardware might store
|
||||
key-value pairs of PTP sequence ID/message type/domain number and the
|
||||
actual timestamp. To perform the correlation correctly between the
|
||||
packets in a queue waiting for timestamping and the actual timestamps,
|
||||
drivers can use a BPF classifier (``ptp_classify_raw``) to identify
|
||||
the PTP transport type, and ``ptp_parse_header`` to interpret the PTP
|
||||
header fields. There may be an IRQ that is raised upon this
|
||||
timestamp's availability, or the driver might have to poll after
|
||||
invoking ``dev_queue_xmit()`` towards the host interface.
|
||||
One-step TX timestamping do not require packet cloning, since there is
|
||||
no follow-up message required by the PTP protocol (because the
|
||||
TX timestamp is embedded into the packet by the MAC), and therefore
|
||||
user space does not expect the packet annotated with the TX timestamp
|
||||
to be re-enqueued into its socket's error queue.
|
||||
|
||||
- ``.port_rxtstamp()``: The original (and only) timestampable skb is provided
|
||||
to the driver, for it to annotate it with a timestamp, if that is immediately
|
||||
available, or defer to later. On reception, timestamps might either be
|
||||
available in-band (through metadata in the DSA header, or attached in other
|
||||
ways to the packet), or out-of-band (through another RX timestamping FIFO).
|
||||
Deferral on RX is typically necessary when retrieving the timestamp needs a
|
||||
sleepable context. In that case, it is the responsibility of the DSA driver
|
||||
to call ``netif_rx_ni()`` on the freshly timestamped skb.
|
||||
- ``.port_rxtstamp()``: On RX, the BPF classifier is run by DSA to
|
||||
identify PTP event messages (any other packets, including PTP general
|
||||
messages, are not timestamped). The original (and only) timestampable
|
||||
skb is provided to the driver, for it to annotate it with a timestamp,
|
||||
if that is immediately available, or defer to later. On reception,
|
||||
timestamps might either be available in-band (through metadata in the
|
||||
DSA header, or attached in other ways to the packet), or out-of-band
|
||||
(through another RX timestamping FIFO). Deferral on RX is typically
|
||||
necessary when retrieving the timestamp needs a sleepable context. In
|
||||
that case, it is the responsibility of the DSA driver to call
|
||||
``netif_rx_ni()`` on the freshly timestamped skb.
|
||||
|
||||
3.2.2 Ethernet PHYs
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
|
|
|||
|
|
@ -70,60 +70,13 @@ First Byte = 0x03 (X25_IFACE_PARAMS)
|
|||
LAPB parameters. To be defined.
|
||||
|
||||
|
||||
Requirements for the device driver
|
||||
----------------------------------
|
||||
|
||||
Possible Problems
|
||||
=================
|
||||
Packets should not be reordered or dropped when delivering between the
|
||||
Packet Layer and the device driver.
|
||||
|
||||
(Henner Eisen, 2000-10-28)
|
||||
|
||||
The X.25 packet layer protocol depends on a reliable datalink service.
|
||||
The LAPB protocol provides such reliable service. But this reliability
|
||||
is not preserved by the Linux network device driver interface:
|
||||
|
||||
- With Linux 2.4.x (and above) SMP kernels, packet ordering is not
|
||||
preserved. Even if a device driver calls netif_rx(skb1) and later
|
||||
netif_rx(skb2), skb2 might be delivered to the network layer
|
||||
earlier that skb1.
|
||||
- Data passed upstream by means of netif_rx() might be dropped by the
|
||||
kernel if the backlog queue is congested.
|
||||
|
||||
The X.25 packet layer protocol will detect this and reset the virtual
|
||||
call in question. But many upper layer protocols are not designed to
|
||||
handle such N-Reset events gracefully. And frequent N-Reset events
|
||||
will always degrade performance.
|
||||
|
||||
Thus, driver authors should make netif_rx() as reliable as possible:
|
||||
|
||||
SMP re-ordering will not occur if the driver's interrupt handler is
|
||||
always executed on the same CPU. Thus,
|
||||
|
||||
- Driver authors should use irq affinity for the interrupt handler.
|
||||
|
||||
The probability of packet loss due to backlog congestion can be
|
||||
reduced by the following measures or a combination thereof:
|
||||
|
||||
(1) Drivers for kernel versions 2.4.x and above should always check the
|
||||
return value of netif_rx(). If it returns NET_RX_DROP, the
|
||||
driver's LAPB protocol must not confirm reception of the frame
|
||||
to the peer.
|
||||
This will reliably suppress packet loss. The LAPB protocol will
|
||||
automatically cause the peer to re-transmit the dropped packet
|
||||
later.
|
||||
The lapb module interface was modified to support this. Its
|
||||
data_indication() method should now transparently pass the
|
||||
netif_rx() return value to the (lapb module) caller.
|
||||
(2) Drivers for kernel versions 2.2.x should always check the global
|
||||
variable netdev_dropping when a new frame is received. The driver
|
||||
should only call netif_rx() if netdev_dropping is zero. Otherwise
|
||||
the driver should not confirm delivery of the frame and drop it.
|
||||
Alternatively, the driver can queue the frame internally and call
|
||||
netif_rx() later when netif_dropping is 0 again. In that case, delivery
|
||||
confirmation should also be deferred such that the internal queue
|
||||
cannot grow to much.
|
||||
This will not reliably avoid packet loss, but the probability
|
||||
of packet loss in netif_rx() path will be significantly reduced.
|
||||
(3) Additionally, driver authors might consider to support
|
||||
CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up
|
||||
when a previously congested backlog queue becomes empty again.
|
||||
The driver could uses this for flow-controlling the peer by means
|
||||
of the LAPB protocol's flow-control service.
|
||||
To avoid packets from being reordered or dropped when delivering from
|
||||
the device driver to the Packet Layer, the device driver should not
|
||||
call "netif_rx" to deliver the received packets. Instead, it should
|
||||
call "netif_receive_skb_core" from softirq context to deliver them.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
eBPF Userspace API
|
||||
==================
|
||||
|
||||
eBPF is a kernel mechanism to provide a sandboxed runtime environment in the
|
||||
Linux kernel for runtime extension and instrumentation without changing kernel
|
||||
source code or loading kernel modules. eBPF programs can be attached to various
|
||||
kernel subsystems, including networking, tracing and Linux security modules
|
||||
(LSM).
|
||||
|
||||
For internal kernel documentation on eBPF, see Documentation/bpf/index.rst.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
syscall
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
eBPF Syscall
|
||||
------------
|
||||
|
||||
:Authors: - Alexei Starovoitov <ast@kernel.org>
|
||||
- Joe Stringer <joe@wand.net.nz>
|
||||
- Michael Kerrisk <mtk.manpages@gmail.com>
|
||||
|
||||
The primary info for the bpf syscall is available in the `man-pages`_
|
||||
for `bpf(2)`_.
|
||||
|
||||
bpf() subcommand reference
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. kernel-doc:: include/uapi/linux/bpf.h
|
||||
:doc: eBPF Syscall Preamble
|
||||
|
||||
.. kernel-doc:: include/uapi/linux/bpf.h
|
||||
:doc: eBPF Syscall Commands
|
||||
|
||||
.. Links:
|
||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||
.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
|
||||
|
|
@ -21,6 +21,7 @@ place where this information is gathered.
|
|||
unshare
|
||||
spec_ctrl
|
||||
accelerators/ocxl
|
||||
ebpf/index
|
||||
ioctl/index
|
||||
iommu
|
||||
media/index
|
||||
|
|
|
|||
32
MAINTAINERS
32
MAINTAINERS
|
|
@ -1533,6 +1533,7 @@ F: Documentation/devicetree/bindings/dma/owl-dma.yaml
|
|||
F: Documentation/devicetree/bindings/i2c/i2c-owl.yaml
|
||||
F: Documentation/devicetree/bindings/interrupt-controller/actions,owl-sirq.yaml
|
||||
F: Documentation/devicetree/bindings/mmc/owl-mmc.yaml
|
||||
F: Documentation/devicetree/bindings/net/actions,owl-emac.yaml
|
||||
F: Documentation/devicetree/bindings/pinctrl/actions,*
|
||||
F: Documentation/devicetree/bindings/power/actions,owl-sps.txt
|
||||
F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt
|
||||
|
|
@ -1545,6 +1546,7 @@ F: drivers/dma/owl-dma.c
|
|||
F: drivers/i2c/busses/i2c-owl.c
|
||||
F: drivers/irqchip/irq-owl-sirq.c
|
||||
F: drivers/mmc/host/owl-mmc.c
|
||||
F: drivers/net/ethernet/actions/
|
||||
F: drivers/pinctrl/actions/*
|
||||
F: drivers/soc/actions/
|
||||
F: include/dt-bindings/power/owl-*
|
||||
|
|
@ -3285,6 +3287,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
|
||||
F: Documentation/bpf/
|
||||
F: Documentation/networking/filter.rst
|
||||
F: Documentation/userspace-api/ebpf/
|
||||
F: arch/*/net/*
|
||||
F: include/linux/bpf*
|
||||
F: include/linux/filter.h
|
||||
|
|
@ -3299,6 +3302,7 @@ F: net/core/filter.c
|
|||
F: net/sched/act_bpf.c
|
||||
F: net/sched/cls_bpf.c
|
||||
F: samples/bpf/
|
||||
F: scripts/bpf_doc.py
|
||||
F: tools/bpf/
|
||||
F: tools/lib/bpf/
|
||||
F: tools/testing/selftests/bpf/
|
||||
|
|
@ -5555,11 +5559,11 @@ F: drivers/net/ethernet/freescale/dpaa2/dpmac*
|
|||
F: drivers/net/ethernet/freescale/dpaa2/dpni*
|
||||
|
||||
DPAA2 ETHERNET SWITCH DRIVER
|
||||
M: Ioana Radulescu <ruxandra.radulescu@nxp.com>
|
||||
M: Ioana Ciornei <ioana.ciornei@nxp.com>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/staging/fsl-dpaa2/ethsw
|
||||
F: drivers/net/ethernet/freescale/dpaa2/dpaa2-switch*
|
||||
F: drivers/net/ethernet/freescale/dpaa2/dpsw*
|
||||
|
||||
DPT_I2O SCSI RAID DRIVER
|
||||
M: Adaptec OEM Raid Solutions <aacraid@microsemi.com>
|
||||
|
|
@ -8370,11 +8374,12 @@ S: Maintained
|
|||
T: git git://linuxtv.org/media_tree.git
|
||||
F: drivers/media/i2c/hi556.c
|
||||
|
||||
Hyper-V CORE AND DRIVERS
|
||||
Hyper-V/Azure CORE AND DRIVERS
|
||||
M: "K. Y. Srinivasan" <kys@microsoft.com>
|
||||
M: Haiyang Zhang <haiyangz@microsoft.com>
|
||||
M: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
M: Wei Liu <wei.liu@kernel.org>
|
||||
M: Dexuan Cui <decui@microsoft.com>
|
||||
L: linux-hyperv@vger.kernel.org
|
||||
S: Supported
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
|
||||
|
|
@ -8391,6 +8396,7 @@ F: drivers/hid/hid-hyperv.c
|
|||
F: drivers/hv/
|
||||
F: drivers/input/serio/hyperv-keyboard.c
|
||||
F: drivers/iommu/hyperv-iommu.c
|
||||
F: drivers/net/ethernet/microsoft/
|
||||
F: drivers/net/hyperv/
|
||||
F: drivers/pci/controller/pci-hyperv-intf.c
|
||||
F: drivers/pci/controller/pci-hyperv.c
|
||||
|
|
@ -8633,7 +8639,6 @@ IBM Power SRIOV Virtual NIC Device Driver
|
|||
M: Dany Madden <drt@linux.ibm.com>
|
||||
M: Sukadev Bhattiprolu <sukadev@linux.ibm.com>
|
||||
R: Thomas Falcon <tlfalcon@linux.ibm.com>
|
||||
R: Lijun Pan <lijunp213@gmail.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/ibm/ibmvnic.*
|
||||
|
|
@ -9846,6 +9851,7 @@ F: scripts/*vmlinux*
|
|||
F: scripts/Kbuild*
|
||||
F: scripts/Makefile*
|
||||
F: scripts/basic/
|
||||
F: scripts/dummy-tools/
|
||||
F: scripts/mk*
|
||||
F: scripts/mod/
|
||||
F: scripts/package/
|
||||
|
|
@ -10865,6 +10871,7 @@ F: include/linux/mv643xx.h
|
|||
|
||||
MARVELL MV88X3310 PHY DRIVER
|
||||
M: Russell King <linux@armlinux.org.uk>
|
||||
M: Marek Behun <marek.behun@nic.cz>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/phy/marvell10g.c
|
||||
|
|
@ -11087,7 +11094,7 @@ T: git git://linuxtv.org/media_tree.git
|
|||
F: drivers/media/radio/radio-maxiradio*
|
||||
|
||||
MCAN MMIO DEVICE DRIVER
|
||||
M: Pankaj Sharma <pankj.sharma@samsung.com>
|
||||
M: Chandrasekar Ramakrishnan <rcsekar@samsung.com>
|
||||
L: linux-can@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
|
||||
|
|
@ -12756,6 +12763,7 @@ W: https://github.com/multipath-tcp/mptcp_net-next/wiki
|
|||
B: https://github.com/multipath-tcp/mptcp_net-next/issues
|
||||
F: Documentation/networking/mptcp-sysctl.rst
|
||||
F: include/net/mptcp.h
|
||||
F: include/trace/events/mptcp.h
|
||||
F: include/uapi/linux/mptcp.h
|
||||
F: net/mptcp/
|
||||
F: tools/testing/selftests/net/mptcp/
|
||||
|
|
@ -13046,6 +13054,12 @@ F: drivers/nvmem/
|
|||
F: include/linux/nvmem-consumer.h
|
||||
F: include/linux/nvmem-provider.h
|
||||
|
||||
NXP C45 TJA11XX PHY DRIVER
|
||||
M: Radu Pirea <radu-nicolae.pirea@oss.nxp.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/phy/nxp-c45-tja11xx.c
|
||||
|
||||
NXP FSPI DRIVER
|
||||
M: Ashish Kumar <ashish.kumar@nxp.com>
|
||||
R: Yogesh Gaur <yogeshgaur.83@gmail.com>
|
||||
|
|
@ -18235,12 +18249,6 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
|||
S: Odd Fixes
|
||||
F: sound/soc/codecs/tas571x*
|
||||
|
||||
TI TCAN4X5X DEVICE DRIVER
|
||||
L: linux-can@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/devicetree/bindings/net/can/tcan4x5x.txt
|
||||
F: drivers/net/can/m_can/tcan4x5x*
|
||||
|
||||
TI TRF7970A NFC DRIVER
|
||||
M: Mark Greer <mgreer@animalcreek.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
|
|
|
|||
236
Makefile
236
Makefile
|
|
@ -278,6 +278,10 @@ no-dot-config-targets := $(clean-targets) \
|
|||
$(version_h) headers headers_% archheaders archscripts \
|
||||
%asm-generic kernelversion %src-pkg dt_binding_check \
|
||||
outputmakefile
|
||||
# Installation targets should not require compiler. Unfortunately, vdso_install
|
||||
# is an exception where build artifacts may be updated. This must be fixed.
|
||||
no-compiler-targets := $(no-dot-config-targets) install dtbs_install \
|
||||
headers_install modules_install kernelrelease image_name
|
||||
no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease \
|
||||
image_name
|
||||
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
|
||||
|
|
@ -285,6 +289,7 @@ single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
|
|||
config-build :=
|
||||
mixed-build :=
|
||||
need-config := 1
|
||||
need-compiler := 1
|
||||
may-sync-config := 1
|
||||
single-build :=
|
||||
|
||||
|
|
@ -294,6 +299,12 @@ ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
|
|||
endif
|
||||
endif
|
||||
|
||||
ifneq ($(filter $(no-compiler-targets), $(MAKECMDGOALS)),)
|
||||
ifeq ($(filter-out $(no-compiler-targets), $(MAKECMDGOALS)),)
|
||||
need-compiler :=
|
||||
endif
|
||||
endif
|
||||
|
||||
ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
|
||||
ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
|
||||
may-sync-config :=
|
||||
|
|
@ -353,14 +364,14 @@ __build_one_by_one:
|
|||
|
||||
else # !mixed-build
|
||||
|
||||
include scripts/Kbuild.include
|
||||
include $(srctree)/scripts/Kbuild.include
|
||||
|
||||
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
|
||||
KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
|
||||
KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
|
||||
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
|
||||
|
||||
include scripts/subarch.include
|
||||
include $(srctree)/scripts/subarch.include
|
||||
|
||||
# Cross compiling and selecting different set of gcc/bin-utils
|
||||
# ---------------------------------------------------------------------------
|
||||
|
|
@ -407,12 +418,14 @@ ifeq ($(ARCH),sh64)
|
|||
SRCARCH := sh
|
||||
endif
|
||||
|
||||
export cross_compiling :=
|
||||
ifneq ($(SRCARCH),$(SUBARCH))
|
||||
cross_compiling := 1
|
||||
endif
|
||||
|
||||
KCONFIG_CONFIG ?= .config
|
||||
export KCONFIG_CONFIG
|
||||
|
||||
# Default file for 'make defconfig'. This may be overridden by arch-Makefile.
|
||||
export KBUILD_DEFCONFIG := defconfig
|
||||
|
||||
# SHELL used by kbuild
|
||||
CONFIG_SHELL := sh
|
||||
|
||||
|
|
@ -578,20 +591,18 @@ endif
|
|||
# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
|
||||
# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
|
||||
# and from include/config/auto.conf.cmd to detect the compiler upgrade.
|
||||
CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g')
|
||||
CC_VERSION_TEXT = $(subst $(pound),,$(shell $(CC) --version 2>/dev/null | head -n 1))
|
||||
|
||||
ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
|
||||
ifneq ($(CROSS_COMPILE),)
|
||||
CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))
|
||||
endif
|
||||
ifeq ($(LLVM_IAS),1)
|
||||
CLANG_FLAGS += -integrated-as
|
||||
else
|
||||
CLANG_FLAGS += -no-integrated-as
|
||||
GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
|
||||
CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
|
||||
GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..)
|
||||
endif
|
||||
ifneq ($(GCC_TOOLCHAIN),)
|
||||
CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN)
|
||||
endif
|
||||
ifneq ($(LLVM_IAS),1)
|
||||
CLANG_FLAGS += -no-integrated-as
|
||||
endif
|
||||
CLANG_FLAGS += -Werror=unknown-warning-option
|
||||
KBUILD_CFLAGS += $(CLANG_FLAGS)
|
||||
|
|
@ -599,6 +610,12 @@ KBUILD_AFLAGS += $(CLANG_FLAGS)
|
|||
export CLANG_FLAGS
|
||||
endif
|
||||
|
||||
# Include this also for config targets because some architectures need
|
||||
# cc-cross-prefix to determine CROSS_COMPILE.
|
||||
ifdef need-compiler
|
||||
include $(srctree)/scripts/Makefile.compiler
|
||||
endif
|
||||
|
||||
ifdef config-build
|
||||
# ===========================================================================
|
||||
# *config targets only - make sure prerequisites are updated, and descend
|
||||
|
|
@ -607,7 +624,7 @@ ifdef config-build
|
|||
# Read arch specific Makefile to set KBUILD_DEFCONFIG as needed.
|
||||
# KBUILD_DEFCONFIG may point out an alternative default configuration
|
||||
# used for 'make defconfig'
|
||||
include arch/$(SRCARCH)/Makefile
|
||||
include $(srctree)/arch/$(SRCARCH)/Makefile
|
||||
export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
|
||||
|
||||
config: outputmakefile scripts_basic FORCE
|
||||
|
|
@ -696,7 +713,7 @@ RETPOLINE_VDSO_CFLAGS := $(call cc-option,$(RETPOLINE_VDSO_CFLAGS_GCC),$(call cc
|
|||
export RETPOLINE_CFLAGS
|
||||
export RETPOLINE_VDSO_CFLAGS
|
||||
|
||||
include arch/$(SRCARCH)/Makefile
|
||||
include $(srctree)/arch/$(SRCARCH)/Makefile
|
||||
|
||||
ifdef need-config
|
||||
ifdef may-sync-config
|
||||
|
|
@ -925,7 +942,7 @@ endif
|
|||
ifdef CONFIG_LTO_CLANG
|
||||
ifdef CONFIG_LTO_CLANG_THIN
|
||||
CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
|
||||
KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod-prefix).thinlto-cache
|
||||
KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod_prefix).thinlto-cache
|
||||
else
|
||||
CC_FLAGS_LTO := -flto
|
||||
endif
|
||||
|
|
@ -1086,47 +1103,6 @@ export INSTALL_DTBS_PATH ?= $(INSTALL_PATH)/dtbs/$(KERNELRELEASE)
|
|||
MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
|
||||
export MODLIB
|
||||
|
||||
#
|
||||
# INSTALL_MOD_STRIP, if defined, will cause modules to be
|
||||
# stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
|
||||
# the default option --strip-debug will be used. Otherwise,
|
||||
# INSTALL_MOD_STRIP value will be used as the options to the strip command.
|
||||
|
||||
ifdef INSTALL_MOD_STRIP
|
||||
ifeq ($(INSTALL_MOD_STRIP),1)
|
||||
mod_strip_cmd = $(STRIP) --strip-debug
|
||||
else
|
||||
mod_strip_cmd = $(STRIP) $(INSTALL_MOD_STRIP)
|
||||
endif # INSTALL_MOD_STRIP=1
|
||||
else
|
||||
mod_strip_cmd = true
|
||||
endif # INSTALL_MOD_STRIP
|
||||
export mod_strip_cmd
|
||||
|
||||
# CONFIG_MODULE_COMPRESS, if defined, will cause module to be compressed
|
||||
# after they are installed in agreement with CONFIG_MODULE_COMPRESS_GZIP
|
||||
# or CONFIG_MODULE_COMPRESS_XZ.
|
||||
|
||||
mod_compress_cmd = true
|
||||
ifdef CONFIG_MODULE_COMPRESS
|
||||
ifdef CONFIG_MODULE_COMPRESS_GZIP
|
||||
mod_compress_cmd = $(KGZIP) -n -f
|
||||
endif # CONFIG_MODULE_COMPRESS_GZIP
|
||||
ifdef CONFIG_MODULE_COMPRESS_XZ
|
||||
mod_compress_cmd = $(XZ) --lzma2=dict=2MiB -f
|
||||
endif # CONFIG_MODULE_COMPRESS_XZ
|
||||
endif # CONFIG_MODULE_COMPRESS
|
||||
export mod_compress_cmd
|
||||
|
||||
ifdef CONFIG_MODULE_SIG_ALL
|
||||
$(eval $(call config_filename,MODULE_SIG_KEY))
|
||||
|
||||
mod_sign_cmd = scripts/sign-file $(CONFIG_MODULE_SIG_HASH) $(MODULE_SIG_KEY_SRCPREFIX)$(CONFIG_MODULE_SIG_KEY) certs/signing_key.x509
|
||||
else
|
||||
mod_sign_cmd = true
|
||||
endif
|
||||
export mod_sign_cmd
|
||||
|
||||
HOST_LIBELF_LIBS = $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
|
||||
|
||||
has_libelf := $(call try-run,\
|
||||
|
|
@ -1165,9 +1141,9 @@ endif # CONFIG_BPF
|
|||
|
||||
PHONY += prepare0
|
||||
|
||||
extmod-prefix = $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)
|
||||
export MODORDER := $(extmod-prefix)modules.order
|
||||
export MODULES_NSDEPS := $(extmod-prefix)modules.nsdeps
|
||||
export extmod_prefix = $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)
|
||||
export MODORDER := $(extmod_prefix)modules.order
|
||||
export MODULES_NSDEPS := $(extmod_prefix)modules.nsdeps
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Kernel headers
|
||||
|
|
@ -1271,7 +1247,7 @@ cmd_link-vmlinux = \
|
|||
|
||||
ifndef KBUILD_MIXED_TREE
|
||||
vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE
|
||||
+$(call if_changed,link-vmlinux)
|
||||
+$(call if_changed_dep,link-vmlinux)
|
||||
endif
|
||||
|
||||
targets := vmlinux
|
||||
|
|
@ -1396,7 +1372,11 @@ headerdep:
|
|||
# Deprecated. It is no-op now.
|
||||
PHONY += headers_check
|
||||
headers_check:
|
||||
@:
|
||||
@echo >&2 "=================== WARNING ==================="
|
||||
@echo >&2 "Since Linux 5.5, 'make headers_check' is no-op,"
|
||||
@echo >&2 "and will be removed after Linux 5.15 release."
|
||||
@echo >&2 "Please remove headers_check from your scripts."
|
||||
@echo >&2 "==============================================="
|
||||
|
||||
ifdef CONFIG_HEADERS_INSTALL
|
||||
prepare: headers
|
||||
|
|
@ -1496,11 +1476,6 @@ PHONY += modules
|
|||
# if KBUILD_BUILTIN && !KBUILD_MIXED_TREE, depend on vmlinux
|
||||
modules: $(if $(KBUILD_BUILTIN), $(if $(KBUILD_MIXED_TREE),,vmlinux))
|
||||
modules: modules_check modules_prepare
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
||||
|
||||
PHONY += modules_check
|
||||
modules_check: modules.order
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules-check.sh $<
|
||||
|
||||
cmd_modules_order = $(AWK) '!x[$$0]++' $(real-prereqs) > $@
|
||||
|
||||
|
|
@ -1514,12 +1489,28 @@ PHONY += modules_prepare
|
|||
modules_prepare: prepare
|
||||
$(Q)$(MAKE) $(build)=scripts scripts/module.lds
|
||||
|
||||
# Target to install modules
|
||||
PHONY += modules_install
|
||||
modules_install: _modinst_ _modinst_post
|
||||
export modules_sign_only :=
|
||||
|
||||
PHONY += _modinst_
|
||||
_modinst_:
|
||||
ifeq ($(CONFIG_MODULE_SIG),y)
|
||||
PHONY += modules_sign
|
||||
modules_sign: modules_install
|
||||
@:
|
||||
|
||||
# modules_sign is a subset of modules_install.
|
||||
# 'make modules_install modules_sign' is equivalent to 'make modules_install'.
|
||||
ifeq ($(filter modules_install,$(MAKECMDGOALS)),)
|
||||
modules_sign_only := y
|
||||
endif
|
||||
endif
|
||||
|
||||
modinst_pre :=
|
||||
ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
|
||||
modinst_pre := __modinst_pre
|
||||
endif
|
||||
|
||||
modules_install: $(modinst_pre)
|
||||
PHONY += __modinst_pre
|
||||
__modinst_pre:
|
||||
@rm -rf $(MODLIB)/kernel
|
||||
@rm -f $(MODLIB)/source
|
||||
@mkdir -p $(MODLIB)/kernel
|
||||
|
|
@ -1531,34 +1522,6 @@ _modinst_:
|
|||
@sed 's:^:kernel/:' modules.order > $(MODLIB)/modules.order
|
||||
@cp -f $(mixed-build-prefix)modules.builtin $(MODLIB)/
|
||||
@cp -f $(or $(mixed-build-prefix),$(objtree)/)modules.builtin.modinfo $(MODLIB)/
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
|
||||
|
||||
# This depmod is only for convenience to give the initial
|
||||
# boot a modules.dep even before / is mounted read-write. However the
|
||||
# boot script depmod is the master version.
|
||||
PHONY += _modinst_post
|
||||
_modinst_post: _modinst_
|
||||
$(call cmd,depmod)
|
||||
|
||||
ifeq ($(CONFIG_MODULE_SIG), y)
|
||||
PHONY += modules_sign
|
||||
modules_sign:
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modsign
|
||||
endif
|
||||
|
||||
else # CONFIG_MODULES
|
||||
|
||||
# Modules not configured
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
PHONY += modules modules_install
|
||||
modules modules_install:
|
||||
@echo >&2
|
||||
@echo >&2 "The present kernel configuration has modules disabled."
|
||||
@echo >&2 "Type 'make config' and enable loadable module support."
|
||||
@echo >&2 "Then build a kernel with module support enabled."
|
||||
@echo >&2
|
||||
@exit 1
|
||||
|
||||
endif # CONFIG_MODULES
|
||||
|
||||
|
|
@ -1570,7 +1533,7 @@ endif # CONFIG_MODULES
|
|||
# make distclean Remove editor backup files, patch leftover files and the like
|
||||
|
||||
# Directories & files removed with 'make clean'
|
||||
CLEAN_FILES += include/ksym vmlinux.symvers \
|
||||
CLEAN_FILES += include/ksym vmlinux.symvers modules-only.symvers \
|
||||
modules.builtin modules.builtin.modinfo modules.nsdeps \
|
||||
compile_commands.json .thinlto-cache
|
||||
|
||||
|
|
@ -1807,27 +1770,10 @@ KBUILD_BUILTIN :=
|
|||
KBUILD_MODULES := 1
|
||||
|
||||
build-dirs := $(KBUILD_EXTMOD)
|
||||
PHONY += modules
|
||||
modules: $(MODORDER)
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
||||
|
||||
$(MODORDER): descend
|
||||
@:
|
||||
|
||||
PHONY += modules_install
|
||||
modules_install: _emodinst_ _emodinst_post
|
||||
|
||||
install-dir := $(if $(INSTALL_MOD_DIR),$(INSTALL_MOD_DIR),extra)
|
||||
PHONY += _emodinst_
|
||||
_emodinst_:
|
||||
$(Q)mkdir -p $(MODLIB)/$(install-dir)
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
|
||||
|
||||
PHONY += _emodinst_post
|
||||
_emodinst_post: _emodinst_
|
||||
$(call cmd,depmod)
|
||||
|
||||
compile_commands.json: $(extmod-prefix)compile_commands.json
|
||||
compile_commands.json: $(extmod_prefix)compile_commands.json
|
||||
PHONY += compile_commands.json
|
||||
|
||||
clean-dirs := $(KBUILD_EXTMOD)
|
||||
|
|
@ -1851,6 +1797,43 @@ PHONY += prepare modules_prepare
|
|||
|
||||
endif # KBUILD_EXTMOD
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Modules
|
||||
|
||||
PHONY += modules modules_install
|
||||
|
||||
ifdef CONFIG_MODULES
|
||||
|
||||
modules: modules_check
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
||||
|
||||
PHONY += modules_check
|
||||
modules_check: $(MODORDER)
|
||||
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules-check.sh $<
|
||||
|
||||
quiet_cmd_depmod = DEPMOD $(MODLIB)
|
||||
cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
|
||||
$(KERNELRELEASE)
|
||||
|
||||
modules_install:
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
|
||||
$(call cmd,depmod)
|
||||
|
||||
else # CONFIG_MODULES
|
||||
|
||||
# Modules not configured
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
modules modules_install:
|
||||
@echo >&2 '***'
|
||||
@echo >&2 '*** The present kernel configuration has modules disabled.'
|
||||
@echo >&2 '*** To use the module feature, please run "make menuconfig" etc.'
|
||||
@echo >&2 '*** to enable CONFIG_MODULES.'
|
||||
@echo >&2 '***'
|
||||
@exit 1
|
||||
|
||||
endif # CONFIG_MODULES
|
||||
|
||||
# Single targets
|
||||
# ---------------------------------------------------------------------------
|
||||
# To build individual files in subdirectories, you can do like this:
|
||||
|
|
@ -1882,12 +1865,12 @@ endif
|
|||
|
||||
PHONY += single_modpost
|
||||
single_modpost: $(single-no-ko) modules_prepare
|
||||
$(Q){ $(foreach m, $(single-ko), echo $(extmod-prefix)$m;) } > $(MODORDER)
|
||||
$(Q){ $(foreach m, $(single-ko), echo $(extmod_prefix)$m;) } > $(MODORDER)
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
||||
|
||||
KBUILD_MODULES := 1
|
||||
|
||||
export KBUILD_SINGLE_TARGETS := $(addprefix $(extmod-prefix), $(single-no-ko))
|
||||
export KBUILD_SINGLE_TARGETS := $(addprefix $(extmod_prefix), $(single-no-ko))
|
||||
|
||||
# trim unrelated directories
|
||||
build-dirs := $(foreach d, $(build-dirs), \
|
||||
|
|
@ -1956,12 +1939,12 @@ nsdeps: modules
|
|||
quiet_cmd_gen_compile_commands = GEN $@
|
||||
cmd_gen_compile_commands = $(PYTHON3) $< -a $(AR) -o $@ $(filter-out $<, $(real-prereqs))
|
||||
|
||||
$(extmod-prefix)compile_commands.json: scripts/clang-tools/gen_compile_commands.py \
|
||||
$(extmod_prefix)compile_commands.json: scripts/clang-tools/gen_compile_commands.py \
|
||||
$(if $(KBUILD_EXTMOD),,$(KBUILD_VMLINUX_OBJS) $(KBUILD_VMLINUX_LIBS)) \
|
||||
$(if $(CONFIG_MODULES), $(MODORDER)) FORCE
|
||||
$(call if_changed,gen_compile_commands)
|
||||
|
||||
targets += $(extmod-prefix)compile_commands.json
|
||||
targets += $(extmod_prefix)compile_commands.json
|
||||
|
||||
PHONY += clang-tidy clang-analyzer
|
||||
|
||||
|
|
@ -1969,7 +1952,7 @@ ifdef CONFIG_CC_IS_CLANG
|
|||
quiet_cmd_clang_tools = CHECK $<
|
||||
cmd_clang_tools = $(PYTHON3) $(srctree)/scripts/clang-tools/run-clang-tools.py $@ $<
|
||||
|
||||
clang-tidy clang-analyzer: $(extmod-prefix)compile_commands.json
|
||||
clang-tidy clang-analyzer: $(extmod_prefix)compile_commands.json
|
||||
$(call cmd,clang_tools)
|
||||
else
|
||||
clang-tidy clang-analyzer:
|
||||
|
|
@ -2040,11 +2023,6 @@ tools/%: FORCE
|
|||
quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN $(wildcard $(rm-files)))
|
||||
cmd_rmfiles = rm -rf $(rm-files)
|
||||
|
||||
# Run depmod only if we have System.map and depmod is executable
|
||||
quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
|
||||
cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
|
||||
$(KERNELRELEASE) $(mixed-build-prefix)
|
||||
|
||||
# read saved command lines for existing targets
|
||||
existing-targets := $(wildcard $(sort $(targets)))
|
||||
|
||||
|
|
|
|||
|
|
@ -631,8 +631,7 @@ config ARCH_SUPPORTS_LTO_CLANG_THIN
|
|||
config HAS_LTO_CLANG
|
||||
def_bool y
|
||||
# Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
|
||||
depends on CC_IS_CLANG && CLANG_VERSION >= 110000 && LD_IS_LLD
|
||||
depends on $(success,test $(LLVM_IAS) -eq 1)
|
||||
depends on CC_IS_CLANG && CLANG_VERSION >= 110000 && LD_IS_LLD && AS_IS_LLVM
|
||||
depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
|
||||
depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
|
||||
depends on ARCH_SUPPORTS_LTO_CLANG
|
||||
|
|
|
|||
|
|
@ -6,20 +6,14 @@ _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \
|
|||
$(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
|
||||
|
||||
syscall := $(src)/syscall.tbl
|
||||
syshdr := $(srctree)/$(src)/syscallhdr.sh
|
||||
systbl := $(srctree)/$(src)/syscalltbl.sh
|
||||
syshdr := $(srctree)/scripts/syscallhdr.sh
|
||||
systbl := $(srctree)/scripts/syscalltbl.sh
|
||||
|
||||
quiet_cmd_syshdr = SYSHDR $@
|
||||
cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \
|
||||
'$(syshdr_abis_$(basetarget))' \
|
||||
'$(syshdr_pfx_$(basetarget))' \
|
||||
'$(syshdr_offset_$(basetarget))'
|
||||
cmd_syshdr = $(CONFIG_SHELL) $(syshdr) --emit-nr $< $@
|
||||
|
||||
quiet_cmd_systbl = SYSTBL $@
|
||||
cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \
|
||||
'$(systbl_abis_$(basetarget))' \
|
||||
'$(systbl_abi_$(basetarget))' \
|
||||
'$(systbl_offset_$(basetarget))'
|
||||
cmd_systbl = $(CONFIG_SHELL) $(systbl) $< $@
|
||||
|
||||
$(uapi)/unistd_32.h: $(syscall) $(syshdr) FORCE
|
||||
$(call if_changed,syshdr)
|
||||
|
|
|
|||
|
|
@ -482,3 +482,4 @@
|
|||
550 common process_madvise sys_process_madvise
|
||||
551 common epoll_pwait2 sys_epoll_pwait2
|
||||
552 common mount_setattr sys_mount_setattr
|
||||
553 common quotactl_path sys_quotactl_path
|
||||
|
|
|
|||
|
|
@ -1,36 +0,0 @@
|
|||
#!/bin/sh
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
in="$1"
|
||||
out="$2"
|
||||
my_abis=`echo "($3)" | tr ',' '|'`
|
||||
prefix="$4"
|
||||
offset="$5"
|
||||
|
||||
fileguard=_UAPI_ASM_ALPHA_`basename "$out" | sed \
|
||||
-e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
|
||||
-e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g'`
|
||||
grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
|
||||
printf "#ifndef %s\n" "${fileguard}"
|
||||
printf "#define %s\n" "${fileguard}"
|
||||
printf "\n"
|
||||
|
||||
nxt=0
|
||||
while read nr abi name entry ; do
|
||||
if [ -z "$offset" ]; then
|
||||
printf "#define __NR_%s%s\t%s\n" \
|
||||
"${prefix}" "${name}" "${nr}"
|
||||
else
|
||||
printf "#define __NR_%s%s\t(%s + %s)\n" \
|
||||
"${prefix}" "${name}" "${offset}" "${nr}"
|
||||
fi
|
||||
nxt=$((nr+1))
|
||||
done
|
||||
|
||||
printf "\n"
|
||||
printf "#ifdef __KERNEL__\n"
|
||||
printf "#define __NR_syscalls\t%s\n" "${nxt}"
|
||||
printf "#endif\n"
|
||||
printf "\n"
|
||||
printf "#endif /* %s */\n" "${fileguard}"
|
||||
) > "$out"
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
#!/bin/sh
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
in="$1"
|
||||
out="$2"
|
||||
my_abis=`echo "($3)" | tr ',' '|'`
|
||||
my_abi="$4"
|
||||
offset="$5"
|
||||
|
||||
emit() {
|
||||
t_nxt="$1"
|
||||
t_nr="$2"
|
||||
t_entry="$3"
|
||||
|
||||
while [ $t_nxt -lt $t_nr ]; do
|
||||
printf "__SYSCALL(%s, sys_ni_syscall, )\n" "${t_nxt}"
|
||||
t_nxt=$((t_nxt+1))
|
||||
done
|
||||
printf "__SYSCALL(%s, %s, )\n" "${t_nxt}" "${t_entry}"
|
||||
}
|
||||
|
||||
grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
|
||||
nxt=0
|
||||
if [ -z "$offset" ]; then
|
||||
offset=0
|
||||
fi
|
||||
|
||||
while read nr abi name entry ; do
|
||||
emit $((nxt+offset)) $((nr+offset)) $entry
|
||||
nxt=$((nr+1))
|
||||
done
|
||||
) > "$out"
|
||||
|
|
@ -7,10 +7,9 @@
|
|||
|
||||
#include <asm/unistd.h>
|
||||
|
||||
#define __SYSCALL(nr, entry, nargs) .quad entry
|
||||
#define __SYSCALL(nr, entry) .quad entry
|
||||
.data
|
||||
.align 3
|
||||
.globl sys_call_table
|
||||
sys_call_table:
|
||||
#include <asm/syscall_table.h>
|
||||
#undef __SYSCALL
|
||||
|
|
|
|||
|
|
@ -583,7 +583,7 @@ eth: ethernet@65000000 {
|
|||
clocks = <&sys_clk 6>;
|
||||
reset-names = "ether";
|
||||
resets = <&sys_rst 6>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
local-mac-address = [00 00 00 00 00 00];
|
||||
socionext,syscon-phy-mode = <&soc_glue 0>;
|
||||
|
||||
|
|
|
|||
|
|
@ -84,6 +84,7 @@ static void __init kirkwood_dt_eth_fixup(void)
|
|||
struct device_node *pnp = of_get_parent(np);
|
||||
struct clk *clk;
|
||||
struct property *pmac;
|
||||
u8 tmpmac[ETH_ALEN];
|
||||
void __iomem *io;
|
||||
u8 *macaddr;
|
||||
u32 reg;
|
||||
|
|
@ -93,7 +94,7 @@ static void __init kirkwood_dt_eth_fixup(void)
|
|||
|
||||
/* skip disabled nodes or nodes with valid MAC address*/
|
||||
if (!of_device_is_available(pnp) ||
|
||||
!IS_ERR(of_get_mac_address(np)))
|
||||
!of_get_mac_address(np, tmpmac))
|
||||
goto eth_fixup_skip;
|
||||
|
||||
clk = of_clk_get(pnp, 0);
|
||||
|
|
|
|||
|
|
@ -456,3 +456,4 @@
|
|||
440 common process_madvise sys_process_madvise
|
||||
441 common epoll_pwait2 sys_epoll_pwait2
|
||||
442 common mount_setattr sys_mount_setattr
|
||||
443 common quotactl_path sys_quotactl_path
|
||||
|
|
|
|||
|
|
@ -525,6 +525,9 @@ config ARM64_ERRATUM_843419
|
|||
|
||||
If unsure, say Y.
|
||||
|
||||
config ARM64_LD_HAS_FIX_ERRATUM_843419
|
||||
def_bool $(ld-option,--fix-cortex-a53-843419)
|
||||
|
||||
config ARM64_ERRATUM_1024718
|
||||
bool "Cortex-A55: 1024718: Update of DBM/AP bits without break before make might result in incorrect update"
|
||||
default y
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ LDFLAGS_vmlinux += -shared -Bsymbolic -z notext \
|
|||
endif
|
||||
|
||||
ifeq ($(CONFIG_ARM64_ERRATUM_843419),y)
|
||||
ifeq ($(call ld-option, --fix-cortex-a53-843419),)
|
||||
ifneq ($(CONFIG_ARM64_LD_HAS_FIX_ERRATUM_843419),y)
|
||||
$(warning ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum)
|
||||
else
|
||||
LDFLAGS_vmlinux += --fix-cortex-a53-843419
|
||||
|
|
|
|||
|
|
@ -1118,6 +1118,12 @@ rcec@1f,0 {
|
|||
};
|
||||
};
|
||||
|
||||
/* Integrated Endpoint Register Block */
|
||||
ierb@1f0800000 {
|
||||
compatible = "fsl,ls1028a-enetc-ierb";
|
||||
reg = <0x01 0xf0800000 0x0 0x10000>;
|
||||
};
|
||||
|
||||
rcpm: power-controller@1e34040 {
|
||||
compatible = "fsl,ls1028a-rcpm", "fsl,qoriq-rcpm-2.1+";
|
||||
reg = <0x0 0x1e34040 0x0 0x1c>;
|
||||
|
|
|
|||
|
|
@ -916,8 +916,8 @@ gmac2phy: ethernet@ff550000 {
|
|||
"mac_clk_tx", "clk_mac_ref",
|
||||
"aclk_mac", "pclk_mac",
|
||||
"clk_macphy";
|
||||
resets = <&cru SRST_GMAC2PHY_A>, <&cru SRST_MACPHY>;
|
||||
reset-names = "stmmaceth", "mac-phy";
|
||||
resets = <&cru SRST_GMAC2PHY_A>;
|
||||
reset-names = "stmmaceth";
|
||||
phy-mode = "rmii";
|
||||
phy-handle = <&phy>;
|
||||
snps,txpbl = <0x4>;
|
||||
|
|
|
|||
|
|
@ -734,7 +734,7 @@ eth: ethernet@65000000 {
|
|||
clocks = <&sys_clk 6>;
|
||||
reset-names = "ether";
|
||||
resets = <&sys_rst 6>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
local-mac-address = [00 00 00 00 00 00];
|
||||
socionext,syscon-phy-mode = <&soc_glue 0>;
|
||||
|
||||
|
|
|
|||
|
|
@ -564,7 +564,7 @@ eth0: ethernet@65000000 {
|
|||
clocks = <&sys_clk 6>;
|
||||
reset-names = "ether";
|
||||
resets = <&sys_rst 6>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
local-mac-address = [00 00 00 00 00 00];
|
||||
socionext,syscon-phy-mode = <&soc_glue 0>;
|
||||
|
||||
|
|
@ -585,7 +585,7 @@ eth1: ethernet@65200000 {
|
|||
clocks = <&sys_clk 7>;
|
||||
reset-names = "ether";
|
||||
resets = <&sys_rst 7>;
|
||||
phy-mode = "rgmii";
|
||||
phy-mode = "rgmii-id";
|
||||
local-mac-address = [00 00 00 00 00 00];
|
||||
socionext,syscon-phy-mode = <&soc_glue 1>;
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
#define __ARM_NR_compat_set_tls (__ARM_NR_COMPAT_BASE + 5)
|
||||
#define __ARM_NR_COMPAT_END (__ARM_NR_COMPAT_BASE + 0x800)
|
||||
|
||||
#define __NR_compat_syscalls 443
|
||||
#define __NR_compat_syscalls 444
|
||||
#endif
|
||||
|
||||
#define __ARCH_WANT_SYS_CLONE
|
||||
|
|
|
|||
|
|
@ -893,6 +893,8 @@ __SYSCALL(__NR_process_madvise, sys_process_madvise)
|
|||
__SYSCALL(__NR_epoll_pwait2, compat_sys_epoll_pwait2)
|
||||
#define __NR_mount_setattr 442
|
||||
__SYSCALL(__NR_mount_setattr, sys_mount_setattr)
|
||||
#define __NR_quotactl_path 443
|
||||
__SYSCALL(__NR_quotactl_path, sys_quotactl_path)
|
||||
|
||||
/*
|
||||
* Please add new compat syscalls above this comment and update
|
||||
|
|
|
|||
|
|
@ -1420,10 +1420,9 @@ END(ftrace_stub)
|
|||
|
||||
#endif /* CONFIG_FUNCTION_TRACER */
|
||||
|
||||
#define __SYSCALL(nr, entry, nargs) data8 entry
|
||||
#define __SYSCALL(nr, entry) data8 entry
|
||||
.rodata
|
||||
.align 8
|
||||
.globl sys_call_table
|
||||
sys_call_table:
|
||||
#include <asm/syscall_table.h>
|
||||
#undef __SYSCALL
|
||||
|
|
|
|||
|
|
@ -6,26 +6,18 @@ _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \
|
|||
$(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
|
||||
|
||||
syscall := $(src)/syscall.tbl
|
||||
syshdr := $(srctree)/$(src)/syscallhdr.sh
|
||||
systbl := $(srctree)/$(src)/syscalltbl.sh
|
||||
syshdr := $(srctree)/scripts/syscallhdr.sh
|
||||
systbl := $(srctree)/scripts/syscalltbl.sh
|
||||
|
||||
quiet_cmd_syshdr = SYSHDR $@
|
||||
cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \
|
||||
'$(syshdr_abis_$(basetarget))' \
|
||||
'$(syshdr_pfx_$(basetarget))' \
|
||||
'$(syshdr_offset_$(basetarget))'
|
||||
cmd_syshdr = $(CONFIG_SHELL) $(syshdr) --emit-nr --offset __NR_Linux $< $@
|
||||
|
||||
quiet_cmd_systbl = SYSTBL $@
|
||||
cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \
|
||||
'$(systbl_abis_$(basetarget))' \
|
||||
'$(systbl_abi_$(basetarget))' \
|
||||
'$(systbl_offset_$(basetarget))'
|
||||
cmd_systbl = $(CONFIG_SHELL) $(systbl) $< $@
|
||||
|
||||
syshdr_offset_unistd_64 := __NR_Linux
|
||||
$(uapi)/unistd_64.h: $(syscall) $(syshdr) FORCE
|
||||
$(call if_changed,syshdr)
|
||||
|
||||
systbl_offset_syscall_table := 1024
|
||||
$(kapi)/syscall_table.h: $(syscall) $(systbl) FORCE
|
||||
$(call if_changed,systbl)
|
||||
|
||||
|
|
|
|||
|
|
@ -363,3 +363,4 @@
|
|||
440 common process_madvise sys_process_madvise
|
||||
441 common epoll_pwait2 sys_epoll_pwait2
|
||||
442 common mount_setattr sys_mount_setattr
|
||||
443 common quotactl_path sys_quotactl_path
|
||||
|
|
|
|||
|
|
@ -1,36 +0,0 @@
|
|||
#!/bin/sh
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
in="$1"
|
||||
out="$2"
|
||||
my_abis=`echo "($3)" | tr ',' '|'`
|
||||
prefix="$4"
|
||||
offset="$5"
|
||||
|
||||
fileguard=_UAPI_ASM_IA64_`basename "$out" | sed \
|
||||
-e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
|
||||
-e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g'`
|
||||
grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
|
||||
printf "#ifndef %s\n" "${fileguard}"
|
||||
printf "#define %s\n" "${fileguard}"
|
||||
printf "\n"
|
||||
|
||||
nxt=0
|
||||
while read nr abi name entry ; do
|
||||
if [ -z "$offset" ]; then
|
||||
printf "#define __NR_%s%s\t%s\n" \
|
||||
"${prefix}" "${name}" "${nr}"
|
||||
else
|
||||
printf "#define __NR_%s%s\t(%s + %s)\n" \
|
||||
"${prefix}" "${name}" "${offset}" "${nr}"
|
||||
fi
|
||||
nxt=$((nr+1))
|
||||
done
|
||||
|
||||
printf "\n"
|
||||
printf "#ifdef __KERNEL__\n"
|
||||
printf "#define __NR_syscalls\t%s\n" "${nxt}"
|
||||
printf "#endif\n"
|
||||
printf "\n"
|
||||
printf "#endif /* %s */\n" "${fileguard}"
|
||||
) > "$out"
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
#!/bin/sh
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
in="$1"
|
||||
out="$2"
|
||||
my_abis=`echo "($3)" | tr ',' '|'`
|
||||
my_abi="$4"
|
||||
offset="$5"
|
||||
|
||||
emit() {
|
||||
t_nxt="$1"
|
||||
t_nr="$2"
|
||||
t_entry="$3"
|
||||
|
||||
while [ $t_nxt -lt $t_nr ]; do
|
||||
printf "__SYSCALL(%s, sys_ni_syscall, )\n" "${t_nxt}"
|
||||
t_nxt=$((t_nxt+1))
|
||||
done
|
||||
printf "__SYSCALL(%s, %s, )\n" "${t_nxt}" "${t_entry}"
|
||||
}
|
||||
|
||||
grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
|
||||
nxt=0
|
||||
if [ -z "$offset" ]; then
|
||||
offset=0
|
||||
fi
|
||||
|
||||
while read nr abi name entry ; do
|
||||
emit $((nxt+offset)) $((nr+offset)) $entry
|
||||
nxt=$((nr+1))
|
||||
done
|
||||
) > "$out"
|
||||
|
|
@ -442,3 +442,4 @@
|
|||
440 common process_madvise sys_process_madvise
|
||||
441 common epoll_pwait2 sys_epoll_pwait2
|
||||
442 common mount_setattr sys_mount_setattr
|
||||
443 common quotactl_path sys_quotactl_path
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
/* SPDX-License-Identifier: GPL-2.0 */
|
||||
|
||||
#define __SYSCALL(nr, entry, nargs) .long entry
|
||||
#define __SYSCALL(nr, entry) .long entry
|
||||
ENTRY(sys_call_table)
|
||||
#include <asm/syscall_table.h>
|
||||
#undef __SYSCALL
|
||||
|
|
|
|||
|
|
@ -6,20 +6,14 @@ _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \
|
|||
$(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)')
|
||||
|
||||
syscall := $(src)/syscall.tbl
|
||||
syshdr := $(srctree)/$(src)/syscallhdr.sh
|
||||
systbl := $(srctree)/$(src)/syscalltbl.sh
|
||||
syshdr := $(srctree)/scripts/syscallhdr.sh
|
||||
systbl := $(srctree)/scripts/syscalltbl.sh
|
||||
|
||||
quiet_cmd_syshdr = SYSHDR $@
|
||||
cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \
|
||||
'$(syshdr_abis_$(basetarget))' \
|
||||
'$(syshdr_pfx_$(basetarget))' \
|
||||
'$(syshdr_offset_$(basetarget))'
|
||||
cmd_syshdr = $(CONFIG_SHELL) $(syshdr) --emit-nr $< $@
|
||||
|
||||
quiet_cmd_systbl = SYSTBL $@
|
||||
cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \
|
||||
'$(systbl_abis_$(basetarget))' \
|
||||
'$(systbl_abi_$(basetarget))' \
|
||||
'$(systbl_offset_$(basetarget))'
|
||||
cmd_systbl = $(CONFIG_SHELL) $(systbl) $< $@
|
||||
|
||||
$(uapi)/unistd_32.h: $(syscall) $(syshdr) FORCE
|
||||
$(call if_changed,syshdr)
|
||||
|
|
|
|||
|
|
@ -448,3 +448,4 @@
|
|||
440 common process_madvise sys_process_madvise
|
||||
441 common epoll_pwait2 sys_epoll_pwait2
|
||||
442 common mount_setattr sys_mount_setattr
|
||||
443 common quotactl_path sys_quotactl_path
|
||||
|
|
|
|||
|
|
@ -1,36 +0,0 @@
|
|||
#!/bin/sh
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
in="$1"
|
||||
out="$2"
|
||||
my_abis=`echo "($3)" | tr ',' '|'`
|
||||
prefix="$4"
|
||||
offset="$5"
|
||||
|
||||
fileguard=_UAPI_ASM_MICROBLAZE_`basename "$out" | sed \
|
||||
-e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
|
||||
-e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g'`
|
||||
grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
|
||||
printf "#ifndef %s\n" "${fileguard}"
|
||||
printf "#define %s\n" "${fileguard}"
|
||||
printf "\n"
|
||||
|
||||
nxt=0
|
||||
while read nr abi name entry ; do
|
||||
if [ -z "$offset" ]; then
|
||||
printf "#define __NR_%s%s\t%s\n" \
|
||||
"${prefix}" "${name}" "${nr}"
|
||||
else
|
||||
printf "#define __NR_%s%s\t(%s + %s)\n" \
|
||||
"${prefix}" "${name}" "${offset}" "${nr}"
|
||||
fi
|
||||
nxt=$((nr+1))
|
||||
done
|
||||
|
||||
printf "\n"
|
||||
printf "#ifdef __KERNEL__\n"
|
||||
printf "#define __NR_syscalls\t%s\n" "${nxt}"
|
||||
printf "#endif\n"
|
||||
printf "\n"
|
||||
printf "#endif /* %s */\n" "${fileguard}"
|
||||
) > "$out"
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
#!/bin/sh
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
in="$1"
|
||||
out="$2"
|
||||
my_abis=`echo "($3)" | tr ',' '|'`
|
||||
my_abi="$4"
|
||||
offset="$5"
|
||||
|
||||
emit() {
|
||||
t_nxt="$1"
|
||||
t_nr="$2"
|
||||
t_entry="$3"
|
||||
|
||||
while [ $t_nxt -lt $t_nr ]; do
|
||||
printf "__SYSCALL(%s, sys_ni_syscall, )\n" "${t_nxt}"
|
||||
t_nxt=$((t_nxt+1))
|
||||
done
|
||||
printf "__SYSCALL(%s, %s, )\n" "${t_nxt}" "${t_entry}"
|
||||
}
|
||||
|
||||
grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
|
||||
nxt=0
|
||||
if [ -z "$offset" ]; then
|
||||
offset=0
|
||||
fi
|
||||
|
||||
while read nr abi name entry ; do
|
||||
emit $((nxt+offset)) $((nr+offset)) $entry
|
||||
nxt=$((nr+1))
|
||||
done
|
||||
) > "$out"
|
||||
|
|
@ -68,9 +68,11 @@ void *memcpy(void *v_dst, const void *v_src, __kernel_size_t c)
|
|||
case 1:
|
||||
*dst++ = *src++;
|
||||
--c;
|
||||
fallthrough;
|
||||
case 2:
|
||||
*dst++ = *src++;
|
||||
--c;
|
||||
fallthrough;
|
||||
case 3:
|
||||
*dst++ = *src++;
|
||||
--c;
|
||||
|
|
@ -176,8 +178,10 @@ void *memcpy(void *v_dst, const void *v_src, __kernel_size_t c)
|
|||
switch (c) {
|
||||
case 3:
|
||||
*dst++ = *src++;
|
||||
fallthrough;
|
||||
case 2:
|
||||
*dst++ = *src++;
|
||||
fallthrough;
|
||||
case 1:
|
||||
*dst++ = *src++;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -90,9 +90,11 @@ void *memmove(void *v_dst, const void *v_src, __kernel_size_t c)
|
|||
case 3:
|
||||
*--dst = *--src;
|
||||
--c;
|
||||
fallthrough;
|
||||
case 2:
|
||||
*--dst = *--src;
|
||||
--c;
|
||||
fallthrough;
|
||||
case 1:
|
||||
*--dst = *--src;
|
||||
--c;
|
||||
|
|
@ -201,10 +203,13 @@ void *memmove(void *v_dst, const void *v_src, __kernel_size_t c)
|
|||
switch (c) {
|
||||
case 4:
|
||||
*--dst = *--src;
|
||||
fallthrough;
|
||||
case 3:
|
||||
*--dst = *--src;
|
||||
fallthrough;
|
||||
case 2:
|
||||
*--dst = *--src;
|
||||
fallthrough;
|
||||
case 1:
|
||||
*--dst = *--src;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -69,9 +69,11 @@ void *memset(void *v_src, int c, __kernel_size_t n)
|
|||
case 1:
|
||||
*src++ = c;
|
||||
--n;
|
||||
fallthrough;
|
||||
case 2:
|
||||
*src++ = c;
|
||||
--n;
|
||||
fallthrough;
|
||||
case 3:
|
||||
*src++ = c;
|
||||
--n;
|
||||
|
|
|
|||
|
|
@ -188,7 +188,7 @@ w2: sw r4, r5, r3
|
|||
.text
|
||||
|
||||
.align 4 /* Alignment is important to keep icache happy */
|
||||
page: /* Create room on stack and save registers for storign values */
|
||||
page: /* Create room on stack and save registers for storing values */
|
||||
addik r1, r1, -40
|
||||
swi r5, r1, 0
|
||||
swi r6, r1, 4
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ static void __init highmem_init(void)
|
|||
pkmap_page_table = virt_to_kpte(PKMAP_BASE);
|
||||
}
|
||||
|
||||
static void highmem_setup(void)
|
||||
static void __meminit highmem_setup(void)
|
||||
{
|
||||
unsigned long pfn;
|
||||
|
||||
|
|
|
|||
|
|
@ -4,13 +4,15 @@ config MIPS
|
|||
default y
|
||||
select ARCH_32BIT_OFF_T if !64BIT
|
||||
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
|
||||
select ARCH_HAS_DEBUG_VIRTUAL if !64BIT
|
||||
select ARCH_HAS_FORTIFY_SOURCE
|
||||
select ARCH_HAS_KCOV
|
||||
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE if !EVA
|
||||
select ARCH_HAS_PTE_SPECIAL if !(32BIT && CPU_HAS_RIXI)
|
||||
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
|
||||
select ARCH_HAS_UBSAN_SANITIZE_ALL
|
||||
select ARCH_HAS_GCOV_PROFILE_ALL
|
||||
select ARCH_KEEP_MEMBLOCK if DEBUG_KERNEL
|
||||
select ARCH_KEEP_MEMBLOCK
|
||||
select ARCH_SUPPORTS_UPROBES
|
||||
select ARCH_USE_BUILTIN_BSWAP
|
||||
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
|
||||
|
|
@ -26,6 +28,7 @@ config MIPS
|
|||
select GENERIC_ATOMIC64 if !64BIT
|
||||
select GENERIC_CMOS_UPDATE
|
||||
select GENERIC_CPU_AUTOPROBE
|
||||
select GENERIC_FIND_FIRST_BIT
|
||||
select GENERIC_GETTIMEOFDAY
|
||||
select GENERIC_IOMAP
|
||||
select GENERIC_IRQ_PROBE
|
||||
|
|
@ -91,7 +94,6 @@ config MIPS
|
|||
select PERF_USE_VMALLOC
|
||||
select PCI_MSI_ARCH_FALLBACKS if PCI_MSI
|
||||
select RTC_LIB
|
||||
select SET_FS
|
||||
select SYSCTL_EXCEPTION_TRACE
|
||||
select VIRT_TO_BUS
|
||||
select ARCH_HAS_ELFCORE_COMPAT
|
||||
|
|
@ -712,6 +714,7 @@ config SGI_IP27
|
|||
select ARC_CMDLINE_ONLY
|
||||
select BOOT_ELF64
|
||||
select DEFAULT_SGI_PARTITION
|
||||
select FORCE_PCI
|
||||
select SYS_HAS_EARLY_PRINTK
|
||||
select HAVE_PCI
|
||||
select IRQ_MIPS_CPU
|
||||
|
|
@ -774,6 +777,7 @@ config SGI_IP30
|
|||
select BOOT_ELF64
|
||||
select CEVT_R4K
|
||||
select CSRC_R4K
|
||||
select FORCE_PCI
|
||||
select SYNC_R4K if SMP
|
||||
select ZONE_DMA32
|
||||
select HAVE_PCI
|
||||
|
|
@ -998,6 +1002,7 @@ config CAVIUM_OCTEON_SOC
|
|||
select NR_CPUS_DEFAULT_64
|
||||
select MIPS_NR_CPU_NR_MAP_1024
|
||||
select BUILTIN_DTB
|
||||
select MTD
|
||||
select MTD_COMPLEX_MAPPINGS
|
||||
select SWIOTLB
|
||||
select SYS_SUPPORTS_RELOCATABLE
|
||||
|
|
@ -2118,7 +2123,7 @@ config CPU_MIPS32
|
|||
config CPU_MIPS64
|
||||
bool
|
||||
default y if CPU_MIPS64_R1 || CPU_MIPS64_R2 || CPU_MIPS64_R5 || \
|
||||
CPU_MIPS64_R6
|
||||
CPU_MIPS64_R6 || CPU_LOONGSON64 || CPU_CAVIUM_OCTEON
|
||||
|
||||
#
|
||||
# These indicate the revision of the architecture
|
||||
|
|
@ -2185,7 +2190,8 @@ config CPU_SUPPORTS_HUGEPAGES
|
|||
depends on !(32BIT && (ARCH_PHYS_ADDR_T_64BIT || EVA))
|
||||
config MIPS_PGD_C0_CONTEXT
|
||||
bool
|
||||
default y if 64BIT && (CPU_MIPSR2 || CPU_MIPSR6) && !CPU_XLP
|
||||
depends on 64BIT
|
||||
default y if (CPU_MIPSR2 || CPU_MIPSR6) && !CPU_XLP
|
||||
|
||||
#
|
||||
# Set to y for ptrace access to watch registers.
|
||||
|
|
@ -2219,23 +2225,6 @@ config 64BIT
|
|||
|
||||
endchoice
|
||||
|
||||
config KVM_GUEST
|
||||
bool "KVM Guest Kernel"
|
||||
depends on CPU_MIPS32_R2
|
||||
depends on !64BIT && BROKEN_ON_SMP
|
||||
help
|
||||
Select this option if building a guest kernel for KVM (Trap & Emulate)
|
||||
mode.
|
||||
|
||||
config KVM_GUEST_TIMER_FREQ
|
||||
int "Count/Compare Timer Frequency (MHz)"
|
||||
depends on KVM_GUEST
|
||||
default 100
|
||||
help
|
||||
Set this to non-zero if building a guest kernel for KVM to skip RTC
|
||||
emulation when determining guest CPU Frequency. Instead, the guest's
|
||||
timer frequency is specified directly.
|
||||
|
||||
config MIPS_VA_BITS_48
|
||||
bool "48 bits virtual memory"
|
||||
depends on 64BIT
|
||||
|
|
|
|||
|
|
@ -77,6 +77,7 @@ config CMDLINE_OVERRIDE
|
|||
config SB1XXX_CORELIS
|
||||
bool "Corelis Debugger"
|
||||
depends on SIBYTE_SB1xxx_SOC
|
||||
select DEBUG_KERNEL if !COMPILE_TEST
|
||||
select DEBUG_INFO if !COMPILE_TEST
|
||||
help
|
||||
Select compile flags that produce code that can be processed by the
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ static struct clk_aliastable {
|
|||
/* access locks to SYS_FREQCTRL0/1 and SYS_CLKSRC registers */
|
||||
static spinlock_t alchemy_clk_fg0_lock;
|
||||
static spinlock_t alchemy_clk_fg1_lock;
|
||||
static spinlock_t alchemy_clk_csrc_lock;
|
||||
static DEFINE_SPINLOCK(alchemy_clk_csrc_lock);
|
||||
|
||||
/* CPU Core clock *****************************************************/
|
||||
|
||||
|
|
@ -996,7 +996,6 @@ static int __init alchemy_clk_setup_imux(int ctype)
|
|||
if (!a)
|
||||
return -ENOMEM;
|
||||
|
||||
spin_lock_init(&alchemy_clk_csrc_lock);
|
||||
ret = 0;
|
||||
|
||||
for (i = 0; i < 6; i++) {
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ static struct clk clk_enet_misc = {
|
|||
};
|
||||
|
||||
/*
|
||||
* Ethernet MAC clocks: only revelant on 6358, silently enable misc
|
||||
* Ethernet MAC clocks: only relevant on 6358, silently enable misc
|
||||
* clocks
|
||||
*/
|
||||
static void enetx_set(struct clk *clk, int enable)
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue