tmakin/ack-tegra
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge b85966adbf ("Merge tag 'net-next-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") into android-mainline

Browse Source 
Steps on the way to v7.2-rc1

Change-Id: I38164ed17f4e48f944d99c3402b89610c332bb97
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This commit is contained in:
Carlos Llamas committed 2026-07-29 21:29:55 +00:00
2 parents a7350f99bf b85966adbf
commit 8da54d82b3
1913 files changed
+85554 -49966
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.mailmap
+1
View File
@@ -402,6 +402,7 @@ Jesper Dangaard Brouer <hawk@kernel.org> <hawk@comx.dk>
Jesper Dangaard Brouer <hawk@kernel.org> <jbrouer@redhat.com>
Jesper Dangaard Brouer <hawk@kernel.org> <jdb@comx.dk>
Jesper Dangaard Brouer <hawk@kernel.org> <netoptimizer@brouer.com>
Jesse Brandeburg <jbrandeb@kernel.org> <jesse.brandeburg@intel.com>
Jessica Zhang <jesszhan0024@gmail.com> <jesszhan@codeaurora.org>
Jessica Zhang <jesszhan0024@gmail.com> <quic_jesszhan@quicinc.com>
Jessica Zhang <jesszhan0024@gmail.com> <jessica.zhang@oss.qualcomm.com>
Documentation/ABI/testing/sysfs-class-ieee80211-rtw89
+24
View File
@@ -0,0 +1,24 @@
What: /sys/class/ieee80211/phyX/rtw89_usb/serial_number
Date: May 2026
Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-wireless@vger.kernel.org
Description: (Read) Serial number burned into EFUSE of the RTL8852CU-based
USB Wi-Fi adapter. Only present on devices that set the
RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
PID 0x2432).
Format: %10phN (5 raw bytes printed as 10 lowercase hex
digits, no separators).
Example: 3642000123
What: /sys/class/ieee80211/phyX/rtw89_usb/uuid
Date: May 2026
Contact: Johnson Tsai <wenjie.tsai@realtek.com>, linux-wireless@vger.kernel.org
Description: (Read) UUID burned into EFUSE of the RTL8852CU-based USB Wi-Fi
adapter. Only present on devices that set the
RTW89_QUIRK_HW_INFO_SYSFS quirk (currently VID 0x28de /
PID 0x2432).
Format: %pUb (RFC 4122 UUID in lowercase with hyphens).
Example: aaec2b7c-0a55-4727-8de0-b30febccbbaa
Documentation/admin-guide/kernel-parameters.txt
+1 -19
View File
@@ -556,9 +556,6 @@ Kernel parameters
1 -- enable.
Default value is set via kernel config option.
arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
Format: <io>,<irq>,<nodeID>
arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of
32 bit applications.
@@ -891,17 +888,6 @@ Kernel parameters
Sets the size of memory pool for coherent, atomic dma
allocations, by default set to 256K.
com20020= [HW,NET] ARCnet - COM20020 chipset
Format:
<io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]]
com90io= [HW,NET] ARCnet - COM90xx chipset (IO-mapped buffers)
Format: <io>[,<irq>]
com90xx= [HW,NET]
ARCnet - COM90xx chipset (memory-mapped buffers)
Format: <io>[,<irq>[,<memstart>]]
condev= [HW,S390] console device
conmode=
@@ -4258,12 +4244,8 @@ Kernel parameters
n2= [NET] SDL Inc. RISCom/N2 synchronous serial card
netdev= [NET] Network devices parameters
netdev= [NET] NE2000 ISA network devices parameters
Format: <irq>,<io>,<mem_start>,<mem_end>,<name>
Note that mem_start is often overloaded to mean
something different and driver-specific.
This usage is only documented in each driver source
file if at all.
netpoll.carrier_timeout=
[NET] Specifies amount of time (in seconds) that
Documentation/admin-guide/sysctl/net.rst
+1 -45
View File
@@ -474,51 +474,7 @@ Please see: Documentation/networking/ip-sysctl.rst and
Documentation/admin-guide/sysctl/net.rst for descriptions of these entries.
4. Appletalk
------------
The /proc/sys/net/appletalk directory holds the Appletalk configuration data
when Appletalk is loaded. The configurable parameters are:
aarp-expiry-time
----------------
The amount of time we keep an ARP entry before expiring it. Used to age out
old hosts.
aarp-resolve-time
-----------------
The amount of time we will spend trying to resolve an Appletalk address.
aarp-retransmit-limit
---------------------
The number of times we will retransmit a query before giving up.
aarp-tick-time
--------------
Controls the rate at which expires are checked.
The directory /proc/net/appletalk holds the list of active Appletalk sockets
on a machine.
The fields indicate the DDP type, the local address (in network:node format)
the remote address, the size of the transmit pending queue, the size of the
received queue (bytes waiting for applications to read) the state and the uid
owning the socket.
/proc/net/atalk_iface lists all the interfaces configured for appletalk.It
shows the name of the interface, its Appletalk address, the network range on
that address (or network number for phase 1 networks), and the status of the
interface.
/proc/net/atalk_route lists each known network route. It lists the target
(network) that the route leads to, the router (may be directly connected), the
route flags, and the device the route is using.
5. TIPC
4. TIPC
-------
tipc_rmem
Documentation/arch/m68k/kernel-options.rst
+4 -20
View File
@@ -244,23 +244,7 @@ drive (with "root=").
3) General Device Options (Amiga and Atari)
===========================================
3.1) ether=
-----------
:Syntax: ether=[<irq>[,<base_addr>[,<mem_start>[,<mem_end>]]]],<dev-name>
<dev-name> is the name of a net driver, as specified in
drivers/net/Space.c in the Linux source. Most prominent are eth0, ...
eth3, sl0, ... sl3, ppp0, ..., ppp3, dummy, and lo.
The non-ethernet drivers (sl, ppp, dummy, lo) obviously ignore the
settings by this options. Also, the existing ethernet drivers for
Linux/m68k (ariadne, a2065, hydra) don't use them because Zorro boards
are really Plug-'n-Play, so the "ether=" option is useless altogether
for Linux/m68k.
3.2) hd=
3.1) hd=
--------
:Syntax: hd=<cylinders>,<heads>,<sectors>
@@ -273,7 +257,7 @@ itself. It exists just for the case that this fails for one of your
disks.
3.3) max_scsi_luns=
3.2) max_scsi_luns=
-------------------
:Syntax: max_scsi_luns=<n>
@@ -284,7 +268,7 @@ be scanned. Valid values for <n> are between 1 and 8. Default is 8 if
configuration, else 1.
3.4) st=
3.3) st=
--------
:Syntax: st=<buffer_size>,[<write_thres>,[<max_buffers>]]
@@ -297,7 +281,7 @@ total number of buffers. <max_buffer> limits the total number of
buffers allocated for all tape devices.
3.5) dmasound=
3.4) dmasound=
--------------
:Syntax: dmasound=[<buffers>,<buffer-size>[,<catch-radius>]]
Documentation/devicetree/bindings/net/airoha,an8801.yaml
+120
View File
@@ -0,0 +1,120 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/airoha,an8801.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Airoha AN8801R Series PHY
maintainers:
- AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
description:
The Airoha AN8801R is a low power single-port Ethernet PHY Transceiver
with Single-port serdes interface for 1000Base-X/RGMII; this chip is
compliant with 10Base-T, 100Base-TX and 1000Base-T IEEE 802.3(u,ab)
and supports Energy Efficient Ethernet (802.3az), Full Duplex Control
Flow (802.3x), auto-negotiation, crossover detect and autocorrection,
Wake-on-LAN with Magic Packet, and Jumbo Frame up to 9 Kilobytes.
This PHY also supports up to three user-configurable LEDs, which are
usually used for LAN Activity, 100M, 1000M indication.
allOf:
- $ref: ethernet-phy.yaml#
properties:
compatible:
enum:
- ethernet-phy-idc0ff.0421
reg:
maxItems: 1
leds:
type: object
description:
Describes the LEDs associated to the PHY
properties:
"#address-cells":
const: 1
"#size-cells":
const: 0
patternProperties:
"^led@[0-2]$":
type: object
description: PHY LEDs
$ref: /schemas/leds/common.yaml#
properties:
reg:
enum: [0, 1, 2]
function-enumerator:
enum: [0, 1, 2]
description: |
Specifies a function for offloading LED functionality to the PHY:
0 - No offloading
1 - Link Availability
2 - Network Activity
required:
- reg
unevaluatedProperties: false
additionalProperties: false
wakeup-source:
$ref: /schemas/types.yaml#/definitions/flag
description:
Enable Wake-on-LAN support
required:
- reg
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/leds/common.h>
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethernet-phy@0 {
compatible = "ethernet-phy-idc0ff.0421";
reg = <0>;
leds {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_LAN;
default-state = "keep";
};
led@1 {
reg = <1>;
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_LAN;
function-enumerator = <1>;
default-state = "keep";
};
led@2 {
reg = <2>;
color = <LED_COLOR_ID_YELLOW>;
function = LED_FUNCTION_LAN;
function-enumerator = <2>;
default-state = "keep";
};
};
};
};
Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
+55 -1
View File
@@ -130,6 +130,42 @@ patternProperties:
maximum: 4
description: GMAC port identifier
allOf:
- if:
properties:
reg:
contains:
items:
- enum:
- 3
- 4
then:
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
patternProperties:
"^ethernet@[0-5]$":
type: object
unevaluatedProperties: false
$ref: ethernet-controller.yaml#
description: External ethernet port ID available on the GDM port
properties:
compatible:
const: airoha,eth-port
reg:
maximum: 5
description: External ethernet port identifier
required:
- reg
- compatible
required:
- reg
- compatible
@@ -191,9 +227,27 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
mac: ethernet@1 {
ethernet@1 {
compatible = "airoha,eth-mac";
reg = <1>;
};
ethernet@4 {
compatible = "airoha,eth-mac";
reg = <4>;
#address-cells = <1>;
#size-cells = <0>;
ethernet@0 {
compatible = "airoha,eth-port";
reg = <0>;
};
ethernet@1 {
compatible = "airoha,eth-port";
reg = <1>;
};
};
};
};
Documentation/devicetree/bindings/net/dsa/dsa.txt
-4
View File
@@ -1,4 +0,0 @@
Distributed Switch Architecture Device Tree Bindings
----------------------------------------------------
See Documentation/devicetree/bindings/net/dsa/dsa.yaml for the documentation.
Documentation/devicetree/bindings/net/dsa/dsa.yaml
+5 -1
View File
@@ -28,7 +28,11 @@ properties:
A two element list indicates which DSA cluster, and position within the
cluster a switch takes. <0 0> is cluster 0, switch 0. <0 1> is cluster 0,
switch 1. <1 0> is cluster 1, switch 0. A switch not part of any cluster
(single device hanging off a CPU port) must not specify this property
(single device hanging off a CPU port) does not usually need to specify
this property, and then it becomes cluster 0, switch 0. For a topology
aware switch, its switch index can be specified through this property,
even if it is not part of any cluster. Also, topology-unaware switches
must always be defined as index 0 of their cluster.
$ref: /schemas/types.yaml#/definitions/uint32-array
additionalProperties: true
Documentation/devicetree/bindings/net/dsa/lan9303.txt
-100
View File
@@ -1,100 +0,0 @@
SMSC/MicroChip LAN9303 three port ethernet switch
-------------------------------------------------
Required properties:
- compatible: should be
- "smsc,lan9303-i2c" for I2C managed mode
or
- "smsc,lan9303-mdio" for mdio managed mode
Optional properties:
- reset-gpios: GPIO to be used to reset the whole device
- reset-duration: reset duration in milliseconds, defaults to 200 ms
Subnodes:
The integrated switch subnode should be specified according to the binding
described in dsa/dsa.txt. The CPU port of this switch is always port 0.
Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
configured to use 1/2/3 instead. This hardware configuration will be
auto-detected and mapped accordingly.
Example:
I2C managed mode:
master: masterdevice@X {
fixed-link { /* RMII fixed link to LAN9303 */
speed = <100>;
full-duplex;
};
};
switch: switch@a {
compatible = "smsc,lan9303-i2c";
reg = <0xa>;
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
reset-duration = <200>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 { /* RMII fixed link to master */
reg = <0>;
ethernet = <&master>;
};
port@1 { /* external port 1 */
reg = <1>;
label = "lan1";
};
port@2 { /* external port 2 */
reg = <2>;
label = "lan2";
};
};
};
MDIO managed mode:
master: masterdevice@X {
phy-handle = <&switch>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
switch: switch-phy@0 {
compatible = "smsc,lan9303-mdio";
reg = <0>;
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
reset-duration = <100>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
ethernet = <&master>;
};
port@1 { /* external port 1 */
reg = <1>;
label = "lan1";
};
port@2 { /* external port 2 */
reg = <2>;
label = "lan2";
};
};
};
};
};
Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
+131
View File
@@ -0,0 +1,131 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NETC Switch family
description: >
The NETC presents itself as a multi-function PCIe Root Complex Integrated
Endpoint (RCiEP) and provides full 802.1Q Ethernet switch functionality,
advanced QoS with 8 traffic classes and 4 drop resilience levels, and a
full range of TSN standards capabilities.
The CPU port of the switch connects to an internal ENETC. The switch and
the internal ENETC are fully integrated into the NETC IP, a back-to-back
MAC is not required. Instead, a light-weight "pseudo MAC" provides the
delineation between the switch and ENETC. This translates to lower power
(less logic and memory) and lower delay (as there is no serialization
delay across this link).
maintainers:
- Wei Fang <wei.fang@nxp.com>
properties:
compatible:
enum:
- pci1131,eef2
reg:
maxItems: 1
dsa,member:
description: >
The property indicates DSA cluster and switch index. For NETC switch,
the valid range of the switch index is 1 ~ 7, the index is reflected
in the switch tag as an indication of the switch ID where the frame
originated. The value 0 is reserved for ENETC VEPA switch, whose ID
is hardwired to zero.
items:
- true
- minimum: 1
maximum: 7
ethernet-ports:
type: object
patternProperties:
"^ethernet-port@[0-9a-f]$":
type: object
$ref: dsa-port.yaml#
properties:
clocks:
items:
- description: MAC transmit/receive reference clock.
clock-names:
items:
- const: ref
mdio:
$ref: /schemas/net/mdio.yaml#
unevaluatedProperties: false
description:
Optional child node for switch port, otherwise use NETC EMDIO.
unevaluatedProperties: false
required:
- compatible
- reg
- dsa,member
- ethernet-ports
allOf:
- $ref: /schemas/pci/pci-device.yaml
- $ref: dsa.yaml#
unevaluatedProperties: false
examples:
- |
pcie {
#address-cells = <3>;
#size-cells = <2>;
ethernet-switch@0,2 {
compatible = "pci1131,eef2";
reg = <0x200 0 0 0 0>;
dsa,member = <0 1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_switch>;
ethernet-ports {
#address-cells = <1>;
#size-cells = <0>;
ethernet-port@0 {
reg = <0>;
phy-handle = <&ethphy0>;
phy-mode = "mii";
};
ethernet-port@1 {
reg = <1>;
phy-handle = <&ethphy1>;
phy-mode = "mii";
};
ethernet-port@2 {
reg = <2>;
clocks = <&scmi_clk 103>;
clock-names = "ref";
phy-handle = <&ethphy2>;
phy-mode = "rgmii-id";
};
ethernet-port@3 {
reg = <3>;
ethernet = <&enetc3>;
phy-mode = "internal";
fixed-link {
speed = <2500>;
full-duplex;
pause;
};
};
};
};
};
Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
+123
View File
@@ -0,0 +1,123 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/dsa/smsc,lan9303.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: SMSC/MicroChip LAN9303 three port ethernet switch
maintainers:
- Frank Li <Frank.Li@nxp.com>
description:
The LAN9303 is a three port ethernet switch with integrated PHYs for the
two external ports. The third port is an RMII/MII interface to a host
processor. The device can be managed via I2C or MDIO.
Note - always use 'reg = <0/1/2>;' for the three DSA ports, even if the
device is configured to use 1/2/3 instead. This hardware configuration
will be auto-detected and mapped accordingly.
properties:
compatible:
enum:
- smsc,lan9303-i2c
- smsc,lan9303-mdio
reg:
maxItems: 1
reset-gpios:
description:
GPIO to be used to reset the whole device
maxItems: 1
reset-duration:
description:
Reset duration in milliseconds
default: 200
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible
- reg
unevaluatedProperties: false
allOf:
- $ref: dsa.yaml#
examples:
- |
#include <dt-bindings/gpio/gpio.h>
/* I2C managed mode */
i2c {
#address-cells = <1>;
#size-cells = <0>;
switch@a {
compatible = "smsc,lan9303-i2c";
reg = <0xa>;
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
reset-duration = <200>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&master>;
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
};
};
};
- |
#include <dt-bindings/gpio/gpio.h>
/* MDIO managed mode */
mdio {
#address-cells = <1>;
#size-cells = <0>;
switch@0 {
compatible = "smsc,lan9303-mdio";
reg = <0>;
reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
reset-duration = <100>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&master>;
};
port@1 {
reg = <1>;
label = "lan1";
};
port@2 {
reg = <2>;
label = "lan2";
};
};
};
};
Documentation/devicetree/bindings/net/ethernet-phy.yaml
+6 -3
View File
@@ -106,10 +106,13 @@ properties:
by software.
clocks:
maxItems: 1
minItems: 1
maxItems: 2
description:
External clock connected to the PHY. If not specified it is assumed
that the PHY uses a fixed crystal or an internal oscillator.
External clock connected to the PHY or RX and TX clocks that the PHY
requires to enable explicitly. If not specified it is assumed
that the PHY uses a fixed crystal or an internal oscillator or that the
RX/TX clocks are hardware enabled by default.
enet-phy-lane-swap:
$ref: /schemas/types.yaml#/definitions/flag
Documentation/devicetree/bindings/net/mdio.txt
-1
View File
@@ -1 +0,0 @@
This file has moved to mdio.yaml.
Documentation/devicetree/bindings/net/microchip,lan8650.yaml
+1 -1
View File
@@ -67,7 +67,7 @@ examples:
pinctrl-names = "default";
pinctrl-0 = <&eth0_pins>;
interrupt-parent = <&gpio>;
interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
local-mac-address = [04 05 06 01 02 03];
spi-max-frequency = <15000000>;
};
Documentation/devicetree/bindings/net/microchip,lan95xx.yaml
+2
View File
@@ -20,6 +20,8 @@ properties:
compatible:
items:
- enum:
- usb424,7500 # SMSC LAN7500 USB Ethernet Device
- usb424,7505 # SMSC LAN7505 USB Ethernet Device
- usb424,9500 # SMSC9500 USB Ethernet Device
- usb424,9505 # SMSC9505 USB Ethernet Device
- usb424,9530 # SMSC LAN9530 USB Ethernet Device
Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml
+5 -5
View File
@@ -17,7 +17,7 @@ description: |
properties:
$nodename:
pattern: "^switch@[0-9a-f]+$"
pattern: "^(ethernet-)?switch@[0-9a-f]+$"
compatible:
const: microchip,lan966x-switch
@@ -70,7 +70,7 @@ properties:
additionalProperties: false
patternProperties:
"^port@[0-9a-f]+$":
"^(ethernet-)?port@[0-9a-f]+$":
type: object
$ref: /schemas/net/ethernet-controller.yaml#
@@ -138,7 +138,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
switch: switch@e0000000 {
switch: ethernet-switch@e0000000 {
compatible = "microchip,lan966x-switch";
reg = <0xe0000000 0x0100000>,
<0xe2000000 0x0800000>;
@@ -151,14 +151,14 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
port0: port@0 {
port0: ethernet-port@0 {
reg = <0>;
phy-handle = <&phy0>;
phys = <&serdes 0 0>;
phy-mode = "gmii";
};
port1: port@1 {
port1: ethernet-port@1 {
reg = <1>;
sfp = <&sfp_eth1>;
managed = "in-band-status";
Documentation/devicetree/bindings/net/pse-pd/microchip,pd692x0.yaml
+4
View File
@@ -22,6 +22,10 @@ properties:
reg:
maxItems: 1
disable-ports-gpios:
description: GPIO pin to disable PoE on all ports
maxItems: 1
vdd-supply:
description: Regulator that provides 3.3V VDD power supply.
Documentation/devicetree/bindings/net/qca,ar803x.yaml
+19
View File
@@ -28,6 +28,16 @@ allOf:
reg:
const: 7 # This PHY is always at MDIO address 7 in the IPQ5018 SoC
clocks:
items:
- description: RX clock
- description: TX clock
clock-names:
items:
- const: rx
- const: tx
resets:
items:
- description:
@@ -42,6 +52,11 @@ allOf:
of this PHY are directly connected to an RJ45 connector.
type: boolean
required:
- clocks
- clock-names
- resets
properties:
compatible:
enum:
@@ -162,6 +177,7 @@ examples:
};
};
- |
#include <dt-bindings/clock/qcom,gcc-ipq5018.h>
#include <dt-bindings/reset/qcom,gcc-ipq5018.h>
mdio {
@@ -172,6 +188,9 @@ examples:
compatible = "ethernet-phy-id004d.d0c0";
reg = <7>;
clocks = <&gcc GCC_GEPHY_RX_CLK>,
<&gcc GCC_GEPHY_TX_CLK>;
clock-names = "rx", "tx";
resets = <&gcc GCC_GEPHY_MISC_ARES>;
};
};
Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
+8 -1
View File
@@ -18,7 +18,14 @@ properties:
- realtek,rtl9302c-mdio
- realtek,rtl9303-mdio
- const: realtek,rtl9301-mdio
- const: realtek,rtl9301-mdio
- items:
- enum:
- realtek,rtl9312-mdio
- realtek,rtl9313-mdio
- const: realtek,rtl9311-mdio
- enum:
- realtek,rtl9301-mdio
- realtek,rtl9311-mdio
'#address-cells':
const: 1
Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+20 -11
View File
@@ -31,7 +31,7 @@ properties:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
- items:
- const: starfive,jh8100-dwmac
- const: starfive,jhb100-dwmac
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
@@ -39,20 +39,24 @@ properties:
maxItems: 1
clocks:
minItems: 5
items:
- description: GMAC main clock
- description: GMAC AHB clock
- description: PTP clock
- description: TX clock
- description: GTX clock
- description: SGMII RX clock
clock-names:
minItems: 5
items:
- const: stmmaceth
- const: pclk
- const: ptp_ref
- const: tx
- const: gtx
- const: sgmii_rx
starfive,tx-use-rgmii-clk:
description:
@@ -111,22 +115,19 @@ allOf:
contains:
const: starfive,jh7110-dwmac
then:
properties:
interrupts:
minItems: 3
maxItems: 3
interrupt-names:
minItems: 3
maxItems: 3
if:
properties:
compatible:
contains:
const: starfive,jh8100-dwmac
const: starfive,jhb100-dwmac
then:
properties:
interrupts:
maxItems: 1
interrupt-names:
const: macirq
resets:
maxItems: 1
@@ -134,6 +135,14 @@ allOf:
const: stmmaceth
else:
properties:
interrupts:
minItems: 3
maxItems: 3
interrupt-names:
minItems: 3
maxItems: 3
resets:
minItems: 2
Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
+61
View File
@@ -0,0 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/wireless/st,stlc4560.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ST/Intersil/Conexant stlc45xx/p54spi/cx3110x SPI wireless device
maintainers:
- Christian Lamparter <chunkeey@gmail.com>
description:
The SPI variant of the Intersil Prism54 wireless device was sold
under a variety of names, including Conexant CX3110x and
ST Microelectronics STLC5460.
allOf:
- $ref: ieee80211.yaml#
- $ref: /schemas/spi/spi-peripheral-props.yaml#
properties:
compatible:
oneOf:
- const: st,stlc4560
- items:
- enum:
- cnxt,3110x
- isil,p54spi
- st,stlc4550
- const: st,stlc4560
reg:
maxItems: 1
interrupts:
maxItems: 1
powerdown-gpios:
maxItems: 1
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
wifi@0 {
compatible = "st,stlc4560";
reg = <0>;
spi-max-frequency = <48000000>;
interrupts-extended = <&gpio 23>;
powerdown-gpios = <&gpio 1>;
};
};
Documentation/driver-api/dpll.rst
+43 -15
View File
@@ -65,35 +65,43 @@ request, where user provides attributes that result in single pin match.
Pin selection
=============
In general, selected pin (the one which signal is driving the dpll
device) can be obtained from ``DPLL_A_PIN_STATE`` attribute, and only
one pin shall be in ``DPLL_PIN_STATE_CONNECTED`` state for any dpll
device.
Pin state (``DPLL_A_PIN_STATE``) reflects the administrative intent set
by the user. Pin operational state (``DPLL_A_PIN_OPERSTATE``) reflects
what the hardware is actually doing with the pin.
Pin selection can be done either manually or automatically, depending
on hardware capabilities and active dpll device work mode
(``DPLL_A_MODE`` attribute). The consequence is that there are
differences for each mode in terms of available pin states, as well as
for the states the user can request for a dpll device.
differences for each mode in terms of available pin states the user can
request for a dpll device.
In manual mode (``DPLL_MODE_MANUAL``) the user can request or receive
one of following pin states:
In manual mode (``DPLL_MODE_MANUAL``) the user can request one of
following pin states:
- ``DPLL_PIN_STATE_CONNECTED`` - the pin is used to drive dpll device
- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin is not used to drive dpll
- ``DPLL_PIN_STATE_CONNECTED`` - the pin is selected to drive dpll
device
- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin is not selected to drive
dpll device
In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can request or
receive one of following pin states:
In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can request one of
following pin states:
- ``DPLL_PIN_STATE_SELECTABLE`` - the pin shall be considered as valid
input for automatic selection algorithm
- ``DPLL_PIN_STATE_DISCONNECTED`` - the pin shall be not considered as
a valid input for automatic selection algorithm
In automatic mode (``DPLL_MODE_AUTOMATIC``) the user can only receive
pin state ``DPLL_PIN_STATE_CONNECTED`` once automatic selection
algorithm locks a dpll device with one of the inputs.
The actual hardware status of a pin is reported via the operational
state (``DPLL_A_PIN_OPERSTATE``) attribute nested under the parent
device:
- ``DPLL_PIN_OPERSTATE_ACTIVE`` - pin is qualified and actively used
by the DPLL
- ``DPLL_PIN_OPERSTATE_STANDBY`` - pin is qualified but not actively
used by the DPLL
- ``DPLL_PIN_OPERSTATE_NO_SIGNAL`` - pin does not have a valid signal
- ``DPLL_PIN_OPERSTATE_QUAL_FAILED`` - pin signal failed qualification
checks
Shared pins
===========
@@ -250,6 +258,26 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
=============================== ========================
Fractional frequency offset
===========================
The fractional frequency offset (FFO) is reported through two attributes
that carry the same measurement at different precisions:
- ``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET`` in PPM (parts per million)
- ``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT`` in PPT (parts per trillion)
Both attributes appear at the top level of a pin and inside each
``pin-parent-device`` nest. Two FFO types are defined:
- ``DPLL_FFO_PORT_RXTX_RATE`` - RX vs TX symbol rate offset (top-level)
- ``DPLL_FFO_PIN_DEVICE`` - pin vs parent DPLL offset (per-parent)
The driver declares which types it supports via the ``supported_ffo``
bitmask in ``struct dpll_pin_ops``. The core only calls the ``ffo_get``
callback for types the driver has opted into. The requested type is
passed to the driver in the ``struct dpll_ffo_param``.
Frequency monitor
=================
Documentation/firmware-guide/acpi/dsd/motorcomm-yt8xxx-phy.rst
+107
View File
@@ -0,0 +1,107 @@
.. SPDX-License-Identifier: GPL-2.0
======================================
Motorcomm yt8xxx PHY properties (_DSD)
======================================
This document describes ACPI _DSD device properties for Motorcomm yt8xxx
Ethernet PHYs supported by the in-kernel driver in
``drivers/net/phy/motorcomm.c``.
The properties are exposed on the PHY device object under the MDIO bus ACPI
device (the same objects that are registered via
``fwnode_mdiobus_register_phy()``). MAC-side connection properties such as
``phy-handle`` and ``phy-mode`` are documented in [acpi-mdio-phy]_.
Property names and semantics are intentionally aligned with the Devicetree
binding [motorcomm-yt8xxx]_ so that the same driver code path
(``device_property_*`` on ``&phydev->mdio.dev``) can consume firmware
described either as Devicetree or ACPI _DSD.
UUID and placement
==================
Per [acpi-dsd-properties-rules]_ and [acpi-mdio-phy]_, properties must be
placed in an _DSD package using the standard Device Properties UUID::
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
Properties
==========
Unless noted otherwise, integer properties use the same allowed values and
defaults as [motorcomm-yt8xxx]_.
``rx-internal-delay-ps`` (u32, optional)
RGMII RX internal delay in picoseconds. Only meaningful when the link is
using RGMII modes with RX internal delay; see [motorcomm-yt8xxx]_.
``tx-internal-delay-ps`` (u32, optional)
RGMII TX internal delay in picoseconds. Only meaningful when the link is
using RGMII modes with TX internal delay; see [motorcomm-yt8xxx]_.
``motorcomm,clk-out-frequency-hz`` (u32, optional)
Clock output frequency on the PHY clock output pin. Allowed values and
default are defined in [motorcomm-yt8xxx]_.
``motorcomm,keep-pll-enabled`` (boolean, optional)
If true, keep the PLL enabled even when there is no link (useful for using
the clock output without an Ethernet link). See [motorcomm-yt8xxx]_.
``motorcomm,auto-sleep-disabled`` (boolean, optional)
If true, disable the PHY auto-sleep behavior described in
[motorcomm-yt8xxx]_.
``motorcomm,rx-clk-drv-microamp`` (u32, optional)
Drive strength for the ``rx_clk`` RGMII pad in microamps. Allowed values
depend on the configured RGMII LDO voltage; see [motorcomm-yt8xxx]_.
``motorcomm,rx-data-drv-microamp`` (u32, optional)
Drive strength for the ``rx_data`` and ``rx_ctl`` RGMII pads in microamps.
See [motorcomm-yt8xxx]_.
``motorcomm,tx-clk-adj-enabled`` (boolean, optional)
Enables adjustments related to ``motorcomm,tx-clk-*-inverted`` usage; see
[motorcomm-yt8xxx]_.
``motorcomm,tx-clk-10-inverted`` (boolean, optional)
``motorcomm,tx-clk-100-inverted`` (boolean, optional)
``motorcomm,tx-clk-1000-inverted`` (boolean, optional)
Per-speed TX clock inversion options; see [motorcomm-yt8xxx]_.
ASL example (illustrative)
==========================
The example below only shows PHY-local _DSD properties. A real platform
still needs a MAC ``phy-handle`` and ``phy-mode`` package as in
[acpi-mdio-phy]_.
.. code-block:: none
Scope (\_SB.MDI0)
{
Device (PHY4)
{
Name (_ADR, 0x4)
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "rx-internal-delay-ps", 2100 },
Package (2) { "tx-internal-delay-ps", 150 },
Package (2) { "motorcomm,clk-out-frequency-hz", 0 },
Package (2) { "motorcomm,keep-pll-enabled", 1 },
Package (2) { "motorcomm,auto-sleep-disabled", 1 },
}
})
}
}
References
==========
.. [acpi-mdio-phy] Documentation/firmware-guide/acpi/dsd/phy.rst
.. [acpi-dsd-properties-rules]
Documentation/firmware-guide/acpi/DSD-properties-rules.rst
.. [motorcomm-yt8xxx]
Documentation/devicetree/bindings/net/motorcomm,yt8xxx.yaml
Documentation/firmware-guide/acpi/index.rst
+1
View File
@@ -11,6 +11,7 @@ ACPI Support
dsd/graph
dsd/data-node-references
dsd/leds
dsd/motorcomm-yt8xxx-phy
dsd/phy
enumeration
osi
Documentation/netlink/specs/devlink.yaml
+4
View File
@@ -234,6 +234,10 @@ definitions:
value: 10
-
name: binary
-
name: u64-array
value: 129
-
name: rate-tc-index-max
type: const
Documentation/netlink/specs/dpll.yaml
+52 -10
View File
@@ -138,6 +138,9 @@ definitions:
-
name: eec
doc: dpll drives the Ethernet Equipment Clock
-
name: generic
doc: generic dpll type for devices outside PPS/EEC classes
render-max: true
-
type: enum
@@ -212,6 +215,27 @@ definitions:
name: selectable
doc: pin enabled for automatic input selection
render-max: true
-
type: enum
name: pin-operstate
doc: |
defines possible operational states of a pin with respect to its
parent DPLL device, valid values for DPLL_A_PIN_OPERSTATE attribute
entries:
-
name: active
doc: pin is qualified and actively used by the DPLL
value: 1
-
name: standby
doc: pin is qualified but not actively used by the DPLL
-
name: no-signal
doc: pin does not have a valid signal
-
name: qual-failed
doc: pin signal failed qualification (e.g. frequency or phase monitor)
render-max: true
-
type: flags
name: pin-capabilities
@@ -427,12 +451,14 @@ attribute-sets:
name: fractional-frequency-offset
type: sint
doc: |
The FFO (Fractional Frequency Offset) between the RX and TX
symbol rate on the media associated with the pin:
(rx_frequency-tx_frequency)/rx_frequency
The FFO (Fractional Frequency Offset) of the pin.
At top level this represents the RX vs TX symbol rate
offset on the media associated with the pin. Inside
the pin-parent-device nest it represents the frequency
offset between the pin and its parent DPLL device.
Value is in PPM (parts per million).
This may be implemented for example for pin of type
PIN_TYPE_SYNCE_ETH_PORT.
This is a lower-precision version of
fractional-frequency-offset-ppt.
-
name: esync-frequency
type: u64
@@ -471,12 +497,14 @@ attribute-sets:
name: fractional-frequency-offset-ppt
type: sint
doc: |
The FFO (Fractional Frequency Offset) of the pin with respect to
the nominal frequency.
Value = (frequency_measured - frequency_nominal) / frequency_nominal
The FFO (Fractional Frequency Offset) of the pin.
At top level this represents the RX vs TX symbol rate
offset on the media associated with the pin. Inside
the pin-parent-device nest it represents the frequency
offset between the pin and its parent DPLL device.
Value is in PPT (parts per trillion, 10^-12).
Note: This attribute provides higher resolution than the standard
fractional-frequency-offset (which is in PPM).
This is a higher-precision version of
fractional-frequency-offset.
-
name: measured-frequency
type: u64
@@ -488,6 +516,14 @@ attribute-sets:
Value of (DPLL_A_PIN_MEASURED_FREQUENCY %
DPLL_PIN_MEASURED_FREQUENCY_DIVIDER) is a fractional part
of a measured frequency value.
-
name: operstate
type: u32
enum: pin-operstate
doc: |
Operational state of the pin with respect to its parent DPLL
device. Unlike state (which reflects the administrative intent),
operstate reflects the actual hardware status.
-
name: pin-parent-device
@@ -501,8 +537,14 @@ attribute-sets:
name: prio
-
name: state
-
name: operstate
-
name: phase-offset
-
name: fractional-frequency-offset
-
name: fractional-frequency-offset-ppt
-
name: pin-parent-pin
subset-of: pin
Documentation/netlink/specs/handshake.yaml
+1
View File
@@ -125,6 +125,7 @@ operations:
name: done
doc: Handler reports handshake completion
attribute-set: done
flags: [admin-perm]
do:
request:
attributes:
Documentation/netlink/specs/netdev.yaml
+15 -2
View File
@@ -127,7 +127,14 @@ attribute-sets:
enum: xsk-flags
-
name: io-uring-provider-info
attributes: []
attributes:
-
name: rx-buf-len
type: uint
doc: |
RX buffer length in bytes for this io_uring memory provider.
Reflects the rx_buf_len passed at io_uring zerocopy rx
registration time.
-
name: page-pool
attributes:
@@ -649,6 +656,9 @@ operations:
- dmabuf
- io-uring
dump:
request:
attributes:
- ifindex
reply: *pp-reply
config-cond: page-pool
-
@@ -692,6 +702,9 @@ operations:
- recycle-ring-full
- recycle-released-refcnt
dump:
request:
attributes:
- info
reply: *pp-stats-reply
config-cond: page-pool-stats
-
@@ -792,7 +805,7 @@ operations:
name: bind-rx
doc: Bind dmabuf to netdev
attribute-set: dmabuf
flags: [admin-perm]
flags: [uns-admin-perm]
do:
request:
attributes:
Documentation/netlink/specs/ovs_packet.yaml
+130
View File
@@ -0,0 +1,130 @@
# SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
---
name: ovs_packet
version: 1
protocol: genetlink-legacy
uapi-header: linux/openvswitch.h
doc: |
OVS packet execution over generic netlink.
Only OVS_PACKET_CMD_EXECUTE is exposed as a genl operation.
OVS_PACKET_CMD_MISS and OVS_PACKET_CMD_ACTION are kernel-to-userspace
upcalls sent via genlmsg_unicast() to the vport's upcall_pid and have
no associated genl_ops or multicast group.
Several attributes in the attribute set (userdata, egress-tun-key, len)
exist for the upcall path and are not used by the EXECUTE operation.
For EXECUTE, packet, key, and actions are mandatory (kernel returns
-EINVAL without them).
definitions:
-
name: ovs-header
type: struct
members:
-
name: dp-ifindex
type: u32
attribute-sets:
-
name: packet
name-prefix: ovs-packet-attr-
enum-name: ovs-packet-attr
attributes:
-
name: packet
type: binary
doc: Packet data, from the start of the Ethernet header.
checks:
min-len: 14
-
name: key
type: binary
doc: |
Nested OVS_KEY_ATTR_* attributes, extracted flow key.
Defined as binary because the key attribute-set belongs to the
ovs_flow family spec; cross-spec references are not supported.
-
name: actions
type: binary
doc: |
Nested OVS_ACTION_ATTR_* attributes.
Defined as binary for the same reason as key.
-
name: userdata
type: binary
doc: Opaque userspace cookie from OVS_USERSPACE_ATTR_USERDATA.
-
name: egress-tun-key
type: binary
doc: Nested OVS_TUNNEL_KEY_ATTR_* for output tunnel metadata.
-
name: unused1
type: unused
-
name: unused2
type: unused
-
name: probe
type: flag
doc: Packet operation is a feature probe, error logging suppressed.
-
name: mru
type: u16
doc: Maximum received IP fragment size.
-
name: len
type: u32
doc: Packet size before truncation.
-
name: hash
type: u64
doc: Packet hash, low 32 bits are skb hash, upper bits are flags.
-
name: upcall-pid
type: u32
doc: Netlink PID to use for upcalls during EXECUTE processing.
operations:
fixed-header: ovs-header
name-prefix: ovs-packet-cmd-
list:
-
name: miss
doc: Notify userspace of a flow table miss for a received packet.
value: 1
attribute-set: packet
event:
attributes: &event-attrs
- packet
- key
- userdata
- actions
- egress-tun-key
- mru
- len
- hash
-
name: action
doc: Notify userspace as requested by an OVS_ACTION_ATTR_USERSPACE action.
value: 2
attribute-set: packet
event:
attributes: *event-attrs
-
name: execute
doc: Apply actions to a packet.
value: 3
attribute-set: packet
do:
request:
attributes:
- packet
- key
- actions
- probe
- mru
- hash
- upcall-pid
Documentation/netlink/specs/psp.yaml
+70 -3
View File
@@ -13,6 +13,17 @@ definitions:
hdr0-aes-gmac-128, hdr0-aes-gmac-256]
attribute-sets:
-
name: assoc-dev-info
attributes:
-
name: ifindex
doc: ifindex of an associated network device.
type: u32
-
name: nsid
doc: Network namespace ID of the associated device.
type: s32
-
name: dev
attributes:
@@ -24,7 +35,9 @@ attribute-sets:
min: 1
-
name: ifindex
doc: ifindex of the main netdevice linked to the PSP device.
doc: |
ifindex of the main netdevice linked to the PSP device,
or the ifindex to associate with the PSP device.
type: u32
-
name: psp-versions-cap
@@ -38,6 +51,28 @@ attribute-sets:
type: u32
enum: version
enum-as-flags: true
-
name: assoc-list
doc: List of associated virtual devices.
type: nest
nested-attributes: assoc-dev-info
multi-attr: true
-
name: nsid
doc: |
Network namespace ID for the device to associate/disassociate.
Optional for dev-assoc and dev-disassoc; if not present, the
device is looked up in the caller's network namespace.
type: s32
-
name: by-association
doc: |
Flag indicating the PSP device is an associated device from a
different network namespace.
Present when in associated namespace, absent when in primary/host
namespace.
type: flag
-
name: assoc
attributes:
@@ -170,6 +205,8 @@ operations:
- ifindex
- psp-versions-cap
- psp-versions-ena
- assoc-list
- by-association
pre: psp-device-get-locked
post: psp-device-unlock
dump:
@@ -196,7 +233,7 @@ operations:
- psp-versions-ena
reply:
attributes: []
pre: psp-device-get-locked
pre: psp-device-get-locked-admin
post: psp-device-unlock
-
name: dev-change-ntf
@@ -216,7 +253,7 @@ operations:
reply:
attributes:
- id
pre: psp-device-get-locked
pre: psp-device-get-locked-admin
post: psp-device-unlock
-
name: key-rotate-ntf
@@ -281,6 +318,36 @@ operations:
post: psp-device-unlock
dump:
reply: *stats-all
-
name: dev-assoc
doc: Associate a network device with a PSP device.
attribute-set: dev
flags: [admin-perm]
do:
request:
attributes:
- id
- ifindex
- nsid
reply:
attributes: []
pre: psp-device-get-locked-dev-assoc
post: psp-device-unlock
-
name: dev-disassoc
doc: Disassociate a network device from a PSP device.
attribute-set: dev
flags: [admin-perm]
do:
request:
attributes:
- id
- ifindex
- nsid
reply:
attributes: []
pre: psp-device-get-locked
post: psp-device-unlock
mcast-groups:
list:
Documentation/netlink/specs/rt-link.yaml
+24 -4
View File
@@ -880,19 +880,21 @@ attribute-sets:
struct: rtnl-link-stats
-
name: cost
type: string
type: unused
-
name: priority
type: string
type: unused
-
name: master
type: u32
-
name: wireless
type: string
type: binary
doc: struct iw_event
-
name: protinfo
type: string
type: binary
doc: A nest of ifla6-attrs or linkinfo-brport-attrs
-
name: txqlen
type: u32
@@ -1351,6 +1353,12 @@ attribute-sets:
-
name: coupled-control
type: u8
-
name: broadcast-neigh
type: u8
-
name: lacp-strict
type: u8
-
name: bond-ad-info-attrs
name-prefix: ifla-bond-ad-info-
@@ -1700,6 +1708,9 @@ attribute-sets:
-
name: backup-nhid
type: u32
-
name: neigh-forward-grat
type: u8
-
name: linkinfo-gre-attrs
name-prefix: ifla-gre-
@@ -1936,6 +1947,15 @@ attribute-sets:
-
name: gro-hint
type: flag
-
name: local
type: u32
byte-order: big-endian
display-hint: ipv4
-
name: local6
type: binary
display-hint: ipv6
-
name: linkinfo-hsr-attrs
name-prefix: ifla-hsr-
Documentation/networking/arcnet-hardware.rst
+27 -2952
View File
File diff suppressed because it is too large. Load diff
Documentation/networking/arcnet.rst
+33 -202
View File
@@ -8,30 +8,10 @@ ARCnet
.. note::
See also arcnet-hardware.txt in this directory for jumper-setting
See also arcnet-hardware.rst in this directory for jumper-setting
and cabling information if you're like many of us and didn't happen to get a
manual with your ARCnet card.
Since no one seems to listen to me otherwise, perhaps a poem will get your
attention::
This driver's getting fat and beefy,
But my cat is still named Fifi.
Hmm, I think I'm allowed to call that a poem, even though it's only two
lines. Hey, I'm in Computer Science, not English. Give me a break.
The point is: I REALLY REALLY REALLY REALLY REALLY want to hear from you if
you test this and get it working. Or if you don't. Or anything.
ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
nice, but after that even FEWER people started writing to me because they
didn't even have to install the patch. <sigh>
Come on, be a sport! Send me a success report!
(hey, that was even better than my original poem... this is getting bad!)
----
These are the ARCnet drivers for Linux.
@@ -62,183 +42,47 @@ netdev@vger.kernel.org and make sure to Cc: maintainer listed in
Other Drivers and Info
----------------------
You can try my ARCNET page on the World Wide Web at:
You can try JoAnne Schmitz's ARCNET page on the World Wide Web at:
http://www.qis.net/~jschmitz/arcnet/
Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
might be interested in, which includes several drivers for various cards
including ARCnet. Try:
http://www.smc.com/
Performance Technologies makes various network software that supports
ARCnet:
http://www.perftech.com/ or ftp to ftp.perftech.com.
Novell makes a networking stack for DOS which includes ARCnet drivers. Try
FTPing to ftp.novell.com.
You can get the Crynwr packet driver collection (including arcether.com, the
one you'll want to use with ARCnet cards) from
oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
without patches, though, and also doesn't like several cards. Fixed
versions are available on my WWW page, or via e-mail if you don't have WWW
access.
https://www.qis.net/~jschmitz/arcnet/
Installing the Driver
---------------------
Supported Hardware
------------------
All you will need to do in order to install the driver is::
Only PCI and PCI Express devices based on the COM20020 chipset are supported.
This is the newest chipset from SMC with support for promiscuous mode (packet
sniffing), extra diagnostic information, etc. These devices use the com20020_pci
driver.
make config
(be sure to choose ARCnet in the network devices
and at least one chipset driver.)
make clean
make zImage
Support for older chipsets and ISA and PCMCIA devices was previously available
but has been removed.
If you obtained this ARCnet package as an upgrade to the ARCnet driver in
your current kernel, you will need to first copy arcnet.c over the one in
the linux/drivers/net directory.
You will know the driver is installed properly if you get some ARCnet
messages when you reboot into the new Linux kernel.
Configuring the Driver
----------------------
There are four chipset options:
The COM20020 driver will be loaded automatically at boot if a supported card is
detected.
1. Standard ARCnet COM90xx chipset.
If the com20020_pci driver was compiled as a loadable module, the options are::
This is the normal ARCnet card, which you've probably got. This is the only
chipset driver which will autoprobe if not told where the card is.
It following options on the command line::
node=<node_ID> backplane=<backplane> clockp=<CKP> clockm=<CKM>
timeout=<timeout> device=<interface_name>
com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
If the driver was compiled into the kernel, the same options can be specified on
the kernel command line by prefixing them with `com20020_pci.`, as in the
following example::
If you load the chipset support as a module, the options are::
io=<io> irq=<irq> shmem=<shmem> device=<name>
To disable the autoprobe, just specify "com90xx=" on the kernel command line.
To specify the name alone, but allow autoprobe, just put "com90xx=<name>"
2. ARCnet COM20020 chipset.
This is the new chipset from SMC with support for promiscuous mode (packet
sniffing), extra diagnostic information, etc. Unfortunately, there is no
sensible method of autoprobing for these cards. You must specify the I/O
address on the kernel command line.
The command line options are::
com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
If you load the chipset support as a module, the options are::
io=<io> irq=<irq> node=<node_ID> backplane=<backplane> clock=<CKP>
timeout=<timeout> device=<name>
com20020_pci.device=eth1
The COM20020 chipset allows you to set the node ID in software, overriding the
default which is still set in DIP switches on the card. If you don't have the
COM20020 data sheets, and you don't know what the other three options refer
COM20020 data sheets, and you don't know what the other options refer
to, then they won't interest you - forget them.
3. ARCnet COM90xx chipset in IO-mapped mode.
This will also work with the normal ARCnet cards, but doesn't use the shared
memory. It performs less well than the above driver, but is provided in case
you have a card which doesn't support shared memory, or (strangely) in case
you have so many ARCnet cards in your machine that you run out of shmem slots.
If you don't give the IO address on the kernel command line, then the driver
will not find the card.
The command line options are::
com90io=<io>[,<irq>][,<name>]
If you load the chipset support as a module, the options are:
io=<io> irq=<irq> device=<name>
4. ARCnet RIM I cards.
These are COM90xx chips which are _completely_ memory mapped. The support for
these is not tested. If you have one, please mail the author with a success
report. All options must be specified, except the device name.
Command line options::
arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
If you load the chipset support as a module, the options are::
shmem=<shmem> irq=<irq> node=<node_ID> device=<name>
Loadable Module Support
-----------------------
Configure and rebuild Linux. When asked, answer 'm' to "Generic ARCnet
support" and to support for your ARCnet chipset if you want to use the
loadable module. You can also say 'y' to "Generic ARCnet support" and 'm'
to the chipset support if you wish.
::
make config
make clean
make zImage
make modules
If you're using a loadable module, you need to use insmod to load it, and
you can specify various characteristics of your card on the command
line. (In recent versions of the driver, autoprobing is much more reliable
and works as a module, so most of this is now unnecessary.)
For example::
cd /usr/src/linux/modules
insmod arcnet.o
insmod com90xx.o
insmod com20020.o io=0x2e0 device=eth1
Using the Driver
----------------
If you build your kernel with ARCnet COM90xx support included, it should
probe for your card automatically when you boot. If you use a different
chipset driver complied into the kernel, you must give the necessary options
on the kernel command line, as detailed above.
Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
available where you picked up this driver. Think of your ARCnet as a
souped-up (or down, as the case may be) Ethernet card.
By the way, be sure to change all references from "eth0" to "arc0" in the
HOWTOs. Remember that ARCnet isn't a "true" Ethernet, and the device name
is DIFFERENT.
Multiple Cards in One Computer
------------------------------
Linux has pretty good support for this now, but since I've been busy, the
ARCnet driver has somewhat suffered in this respect. COM90xx support, if
compiled into the kernel, will (try to) autodetect all the installed cards.
If you have other cards, with support compiled into the kernel, then you can
just repeat the options on the kernel command line, e.g.::
LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
If you have the chipset support built as a loadable module, then you need to
do something like this::
insmod -o arc0 com90xx
insmod -o arc1 com20020 io=0x2e0
insmod -o arc2 com90xx
The ARCnet drivers will now sort out their names automatically.
Otherwise, ARCnet can be configured in a similar way to Ethernet, with the
exception that ARCnet interface names begin with `arc`.
How do I get it to work with...?
@@ -276,9 +120,8 @@ LAN Manager and Windows for Workgroups:
are incompatible with the Internet standard. They try to pretend
the cards are Ethernet, and confuse everyone else on the network.
However, v2.00 and higher of the Linux ARCnet driver supports this
protocol via the 'arc0e' device. See the section on "Multiprotocol
Support" for more information.
The Linux ARCnet driver supports this protocol via the 'arc0e' device.
See the section on "Multiprotocol Support" for more information.
Using the freeware Samba server and clients for Linux, you can now
interface quite nicely with TCP/IP-based WfWg or Lan Manager
@@ -313,7 +156,7 @@ NetBSD/AmiTCP:
Using Multiprotocol ARCnet
--------------------------
The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
The ARCnet driver supports three protocols, each on its own
"virtual network device":
====== ===============================================================
@@ -505,7 +348,7 @@ can set up your network then:
It works: what now?
-------------------
Send mail following :ref:`arcnet-netdev`. Describe your setup, preferably
:ref:`Send an email to netdev <arcnet-netdev>`. Describe your setup, preferably
including driver version, kernel version, ARCnet card model, CPU type, number
of systems on your network, and list of software in use.
@@ -524,10 +367,6 @@ first! D_DURING displays 4-5 lines for each packet sent or received. D_TX,
D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,
which is obviously quite big.
Starting with v2.40 ALPHA, the autoprobe routines have changed
significantly. In particular, they won't tell you why the card was not
found unless you turn on the D_INIT_REASONS debugging flag.
Once the driver is running, you can run the arcdump shell script (available
from me or in the full ARCnet package, if you have it) as root to list the
contents of the arcnet buffers at any time. To make any sense at all out of
@@ -548,21 +387,13 @@ out which bytes are being used by a packet.
You can change the debug level without recompiling the kernel by typing::
ifconfig arc0 down metric 1xxx
/etc/rc.d/rc.inet1
ifconfig arc0 up
where "xxx" is the debug level you want. For example, "metric 1015" would put
you at debug level 15. Debug level 7 is currently the default.
Note that the debug level is (starting with v1.90 ALPHA) a binary
combination of different debug flags; so debug level 7 is really 1+2+4 or
D_NORMAL+D_EXTRA+D_INIT. To include D_DURING, you would add 16 to this,
resulting in debug level 23.
Note that the debug level is a binary combination of different debug flags;
debug level 7 is really 1+2+4 or D_NORMAL+D_EXTRA+D_INIT. To include D_DURING,
you would add 16 to this, resulting in debug level 23.
If you don't understand that, you probably don't want to know anyway.
E-mail me about your problem.
I want to send money: what now?
-------------------------------
Go take a nap or something. You'll feel better in the morning.
Documentation/networking/bonding.rst
+23
View File
@@ -619,6 +619,29 @@ min_links
aggregator cannot be active without at least one available link,
setting this option to 0 or to 1 has the exact same effect.
lacp_strict
Specifies the fallback behavior of a bonding when LACP negotiation
fails on all slave links, i.e. when no slave is in the
Collecting_Distributing state, while at least `min_links` link still
reports carrier up.
This option is only applicable to 802.3ad mode (mode 4).
Valid values are:
off or 0
One interface of the bond is selected to be active, in order to
facilitate communication with peer devices that do not implement
LACP.
on or 1
Interfaces are only permitted to be made active if they have an
active LACP partner and have successfully reached
Collecting_Distributing state.
The default value is 0 (off).
mode
Specifies one of the bonding policies. The default is
Documentation/networking/checksum-offloads.rst
+41 -26
View File
@@ -19,17 +19,14 @@ The following technologies are described:
Things that should be documented here but aren't yet:
* RX Checksum Offload
* CHECKSUM_UNNECESSARY conversion
TX Checksum Offload
===================
The interface for offloading a transmit checksum to a device is explained in
detail in comments near the top of include/linux/skbuff.h.
In brief, it allows to request the device fill in a single ones-complement
In brief, Tx checksum offload allows to request the device fill in a single
ones-complement
checksum defined by the sk_buff fields skb->csum_start and skb->csum_offset.
The device should compute the 16-bit ones-complement checksum (i.e. the
'IP-style' checksum) from csum_start to the end of the packet, and fill in the
@@ -45,9 +42,10 @@ encapsulation is used, the packet may have multiple checksum fields in
different header layers, and the rest will have to be handled by another
mechanism such as LCO or RCO.
CRC32c can also be offloaded using this interface, by means of filling
skb->csum_start and skb->csum_offset as described above, and setting
skb->csum_not_inet: see skbuff.h comment (section 'D') for more details.
SCTP CRC32c can also be offloaded using this interface, by means of filling
skb->csum_start and skb->csum_offset as described above, setting
skb->csum_not_inet, and advertising NETIF_F_SCTP_CRC. Drivers must not treat
ordinary IP checksum offload as SCTP CRC32c support.
No offloading of the IP header checksum is performed; it is always done in
software. This is OK because when we build the IP header, we obviously have it
@@ -55,18 +53,15 @@ in cache, so summing it isn't expensive. It's also rather short.
The requirements for GSO are more complicated, because when segmenting an
encapsulated packet both the inner and outer checksums may need to be edited or
recomputed for each resulting segment. See the skbuff.h comment (section 'E')
for more details.
recomputed for each resulting segment.
A driver declares its offload capabilities in netdev->hw_features; see
Documentation/networking/netdev-features.rst for more. Note that a device
which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start and
csum_offset given in the SKB; if it tries to deduce these itself in hardware
(as some NICs do) the driver should check that the values in the SKB match
those which the hardware will deduce, and if not, fall back to checksumming in
software instead (with skb_csum_hwoffload_help() or one of the
skb_checksum_help() / skb_crc32c_csum_help functions, as mentioned in
include/linux/skbuff.h).
Documentation/networking/netdev-features.rst for more. NETIF_F_IP_CSUM and
NETIF_F_IPV6_CSUM are restricted legacy features and are being deprecated in
favor of NETIF_F_HW_CSUM. New devices should use NETIF_F_HW_CSUM to advertise
generic checksum offload. The skb_csum_hwoffload_help() helper can resolve
CHECKSUM_PARTIAL according to the device's advertised checksum capabilities,
falling back to software when needed.
The stack should, for the most part, assume that checksum offload is supported
by the underlying device. The only place that should check is
@@ -108,11 +103,9 @@ LCO is performed by the stack when constructing an outer UDP header for an
encapsulation such as VXLAN or GENEVE, in udp_set_csum(). Similarly for the
IPv6 equivalents, in udp6_set_csum().
It is also performed when constructing an IPv4 GRE header, in
net/ipv4/ip_gre.c:build_header(). It is *not* currently performed when
constructing an IPv6 GRE header; the GRE checksum is computed over the whole
packet in net/ipv6/ip6_gre.c:ip6gre_xmit2(), but it should be possible to use
LCO here as IPv6 GRE still uses an IP-style checksum.
It is also performed when constructing GRE headers with the shared
gre_build_header() helper in include/net/gre.h, which is used by both IPv4 and
IPv6 GRE.
All of the LCO implementations use a helper function lco_csum(), in
include/linux/skbuff.h.
@@ -138,6 +131,28 @@ RCO is detailed in the following Internet-Drafts:
* https://tools.ietf.org/html/draft-herbert-vxlan-rco-00
In Linux, RCO is implemented individually in each encapsulation protocol, and
most tunnel types have flags controlling its use. For instance, VXLAN has the
flag VXLAN_F_REMCSUM_TX (per struct vxlan_rdst) to indicate that RCO should be
used when transmitting to a given remote destination.
most tunnel types have flags controlling its use. For instance, VXLAN has the
configuration flag VXLAN_F_REMCSUM_TX to indicate that RCO should be used when
transmitting.
RX Checksum Offload
===================
RX checksum offload is controlled via NETIF_F_RXCSUM. When disabled the driver
must not set skb->ip_summed on ingress packets. As mentioned, IPv4 checksum
is not offloaded, the RXCSUM feature controls the offload of verification of
transport layer checksums.
Note that packets with bad TCP/UDP checksums must still be passed
to the stack. skb->ip_summed of such packets can be set to ``CHECKSUM_COMPLETE``
or left at ``CHECKSUM_NONE``. Drivers **must not discard** packets with
bad TCP/UDP checksum and must not configure the device to drop them.
Checksum validation is relatively inexpensive and having bad packets reflected
in SNMP counters is crucial for network monitoring.
skb checksum documentation
==========================
.. kernel-doc:: include/linux/skbuff.h
:doc: skb checksums
Documentation/networking/device_drivers/ethernet/cirrus/cs89x0.rst
-647
View File
@@ -1,647 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
================================================
Cirrus Logic LAN CS8900/CS8920 Ethernet Adapters
================================================
.. note::
This document was contributed by Cirrus Logic for kernel 2.2.5. This version
has been updated for 2.3.48 by Andrew Morton.
Still, this is too outdated! A major cleanup is needed here.
Cirrus make a copy of this driver available at their website, as
described below. In general, you should use the driver version which
comes with your Linux distribution.
Linux Network Interface Driver ver. 2.00 <kernel 2.3.48>
.. TABLE OF CONTENTS
1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
1.1 Product Overview
1.2 Driver Description
1.2.1 Driver Name
1.2.2 File in the Driver Package
1.3 System Requirements
1.4 Licensing Information
2.0 ADAPTER INSTALLATION and CONFIGURATION
2.1 CS8900-based Adapter Configuration
2.2 CS8920-based Adapter Configuration
3.0 LOADING THE DRIVER AS A MODULE
4.0 COMPILING THE DRIVER
4.1 Compiling the Driver as a Loadable Module
4.2 Compiling the driver to support memory mode
4.3 Compiling the driver to support Rx DMA
5.0 TESTING AND TROUBLESHOOTING
5.1 Known Defects and Limitations
5.2 Testing the Adapter
5.2.1 Diagnostic Self-Test
5.2.2 Diagnostic Network Test
5.3 Using the Adapter's LEDs
5.4 Resolving I/O Conflicts
6.0 TECHNICAL SUPPORT
6.1 Contacting Cirrus Logic's Technical Support
6.2 Information Required Before Contacting Technical Support
6.3 Obtaining the Latest Driver Version
6.4 Current maintainer
6.5 Kernel boot parameters
1. Cirrus Logic LAN CS8900/CS8920 Ethernet Adapters
===================================================
1.1. Product Overview
=====================
The CS8900-based ISA Ethernet Adapters from Cirrus Logic follow
IEEE 802.3 standards and support half or full-duplex operation in ISA bus
computers on 10 Mbps Ethernet networks. The adapters are designed for operation
in 16-bit ISA or EISA bus expansion slots and are available in
10BaseT-only or 3-media configurations (10BaseT, 10Base2, and AUI for 10Base-5
or fiber networks).
CS8920-based adapters are similar to the CS8900-based adapter with additional
features for Plug and Play (PnP) support and Wakeup Frame recognition. As
such, the configuration procedures differ somewhat between the two types of
adapters. Refer to the "Adapter Configuration" section for details on
configuring both types of adapters.
1.2. Driver Description
=======================
The CS8900/CS8920 Ethernet Adapter driver for Linux supports the Linux
v2.3.48 or greater kernel. It can be compiled directly into the kernel
or loaded at run-time as a device driver module.
1.2.1 Driver Name: cs89x0
1.2.2 Files in the Driver Archive:
The files in the driver at Cirrus' website include:
=================== ====================================================
readme.txt this file
build batch file to compile cs89x0.c.
cs89x0.c driver C code
cs89x0.h driver header file
cs89x0.o pre-compiled module (for v2.2.5 kernel)
config/Config.in sample file to include cs89x0 driver in the kernel.
config/Makefile sample file to include cs89x0 driver in the kernel.
config/Space.c sample file to include cs89x0 driver in the kernel.
=================== ====================================================
1.3. System Requirements
------------------------
The following hardware is required:
* Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter
* IBM or IBM-compatible PC with:
* An 80386 or higher processor
* 16 bytes of contiguous IO space available between 210h - 370h
* One available IRQ (5,10,11,or 12 for the CS8900, 3-7,9-15 for CS8920).
* Appropriate cable (and connector for AUI, 10BASE-2) for your network
topology.
The following software is required:
* LINUX kernel version 2.3.48 or higher
* CS8900/20 Setup Utility (DOS-based)
* LINUX kernel sources for your kernel (if compiling into kernel)
* GNU Toolkit (gcc and make) v2.6 or above (if compiling into kernel
or a module)
1.4. Licensing Information
--------------------------
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, version 1.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
For a full copy of the GNU General Public License, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
2. Adapter Installation and Configuration
=========================================
Both the CS8900 and CS8920-based adapters can be configured using parameters
stored in an on-board EEPROM. You must use the DOS-based CS8900/20 Setup
Utility if you want to change the adapter's configuration in EEPROM.
When loading the driver as a module, you can specify many of the adapter's
configuration parameters on the command-line to override the EEPROM's settings
or for interface configuration when an EEPROM is not used. (CS8920-based
adapters must use an EEPROM.) See Section 3.0 LOADING THE DRIVER AS A MODULE.
Since the CS8900/20 Setup Utility is a DOS-based application, you must install
and configure the adapter in a DOS-based system using the CS8900/20 Setup
Utility before installation in the target LINUX system. (Not required if
installing a CS8900-based adapter and the default configuration is acceptable.)
2.1. CS8900-based Adapter Configuration
---------------------------------------
CS8900-based adapters shipped from Cirrus Logic have been configured
with the following "default" settings::
Operation Mode: Memory Mode
IRQ: 10
Base I/O Address: 300
Memory Base Address: D0000
Optimization: DOS Client
Transmission Mode: Half-duplex
BootProm: None
Media Type: Autodetect (3-media cards) or
10BASE-T (10BASE-T only adapter)
You should only change the default configuration settings if conflicts with
another adapter exists. To change the adapter's configuration, run the
CS8900/20 Setup Utility.
2.2. CS8920-based Adapter Configuration
---------------------------------------
CS8920-based adapters are shipped from Cirrus Logic configured as Plug
and Play (PnP) enabled. However, since the cs89x0 driver does NOT
support PnP, you must install the CS8920 adapter in a DOS-based PC and
run the CS8900/20 Setup Utility to disable PnP and configure the
adapter before installation in the target Linux system. Failure to do
this will leave the adapter inactive and the driver will be unable to
communicate with the adapter.
::
****************************************************************
* CS8920-BASED ADAPTERS: *
* *
* CS8920-BASED ADAPTERS ARE PLUG and PLAY ENABLED BY DEFAULT. *
* THE CS89X0 DRIVER DOES NOT SUPPORT PnP. THEREFORE, YOU MUST *
* RUN THE CS8900/20 SETUP UTILITY TO DISABLE PnP SUPPORT AND *
* TO ACTIVATE THE ADAPTER. *
****************************************************************
3. Loading the Driver as a Module
=================================
If the driver is compiled as a loadable module, you can load the driver module
with the 'modprobe' command. Many of the adapter's configuration parameters can
be specified as command-line arguments to the load command. This facility
provides a means to override the EEPROM's settings or for interface
configuration when an EEPROM is not used.
Example::
insmod cs89x0.o io=0x200 irq=0xA media=aui
This example loads the module and configures the adapter to use an IO port base
address of 200h, interrupt 10, and use the AUI media connection. The following
configuration options are available on the command line::
io=### - specify IO address (200h-360h)
irq=## - specify interrupt level
use_dma=1 - Enable DMA
dma=# - specify dma channel (Driver is compiled to support
Rx DMA only)
dmasize=# (16 or 64) - DMA size 16K or 64K. Default value is set to 16.
media=rj45 - specify media type
or media=bnc
or media=aui
or media=auto
duplex=full - specify forced half/full/autonegotiate duplex
or duplex=half
or duplex=auto
debug=# - debug level (only available if the driver was compiled
for debugging)
**Notes:**
a) If an EEPROM is present, any specified command-line parameter
will override the corresponding configuration value stored in
EEPROM.
b) The "io" parameter must be specified on the command-line.
c) The driver's hardware probe routine is designed to avoid
writing to I/O space until it knows that there is a cs89x0
card at the written addresses. This could cause problems
with device probing. To avoid this behaviour, add one
to the ``io=`` module parameter. This doesn't actually change
the I/O address, but it is a flag to tell the driver
to partially initialise the hardware before trying to
identify the card. This could be dangerous if you are
not sure that there is a cs89x0 card at the provided address.
For example, to scan for an adapter located at IO base 0x300,
specify an IO address of 0x301.
d) The "duplex=auto" parameter is only supported for the CS8920.
e) The minimum command-line configuration required if an EEPROM is
not present is:
io
irq
media type (no autodetect)
f) The following additional parameters are CS89XX defaults (values
used with no EEPROM or command-line argument).
* DMA Burst = enabled
* IOCHRDY Enabled = enabled
* UseSA = enabled
* CS8900 defaults to half-duplex if not specified on command-line
* CS8920 defaults to autoneg if not specified on command-line
* Use reset defaults for other config parameters
* dma_mode = 0
g) You can use ifconfig to set the adapter's Ethernet address.
h) Many Linux distributions use the 'modprobe' command to load
modules. This program uses the '/etc/conf.modules' file to
determine configuration information which is passed to a driver
module when it is loaded. All the configuration options which are
described above may be placed within /etc/conf.modules.
For example::
> cat /etc/conf.modules
...
alias eth0 cs89x0
options cs89x0 io=0x0200 dma=5 use_dma=1
...
In this example we are telling the module system that the
ethernet driver for this machine should use the cs89x0 driver. We
are asking 'modprobe' to pass the 'io', 'dma' and 'use_dma'
arguments to the driver when it is loaded.
i) Cirrus recommend that the cs89x0 use the ISA DMA channels 5, 6 or
7. You will probably find that other DMA channels will not work.
j) The cs89x0 supports DMA for receiving only. DMA mode is
significantly more efficient. Flooding a 400 MHz Celeron machine
with large ping packets consumes 82% of its CPU capacity in non-DMA
mode. With DMA this is reduced to 45%.
k) If your Linux kernel was compiled with inbuilt plug-and-play
support you will be able to find information about the cs89x0 card
with the command::
cat /proc/isapnp
l) If during DMA operation you find erratic behavior or network data
corruption you should use your PC's BIOS to slow the EISA bus clock.
m) If the cs89x0 driver is compiled directly into the kernel
(non-modular) then its I/O address is automatically determined by
ISA bus probing. The IRQ number, media options, etc are determined
from the card's EEPROM.
n) If the cs89x0 driver is compiled directly into the kernel, DMA
mode may be selected by providing the kernel with a boot option
'cs89x0_dma=N' where 'N' is the desired DMA channel number (5, 6 or 7).
Kernel boot options may be provided on the LILO command line::
LILO boot: linux cs89x0_dma=5
or they may be placed in /etc/lilo.conf::
image=/boot/bzImage-2.3.48
append="cs89x0_dma=5"
label=linux
root=/dev/hda5
read-only
The DMA Rx buffer size is hardwired to 16 kbytes in this mode.
(64k mode is not available).
4. Compiling the Driver
=======================
The cs89x0 driver can be compiled directly into the kernel or compiled into
a loadable device driver module.
Just use the standard way to configure the driver and compile the Kernel.
4.1. Compiling the Driver to Support Rx DMA
-------------------------------------------
The compile-time optionality for DMA was removed in the 2.3 kernel
series. DMA support is now unconditionally part of the driver. It is
enabled by the 'use_dma=1' module option.
5. Testing and Troubleshooting
==============================
5.1. Known Defects and Limitations
----------------------------------
Refer to the RELEASE.TXT file distributed as part of this archive for a list of
known defects, driver limitations, and work arounds.
5.2. Testing the Adapter
------------------------
Once the adapter has been installed and configured, the diagnostic option of
the CS8900/20 Setup Utility can be used to test the functionality of the
adapter and its network connection. Use the diagnostics 'Self Test' option to
test the functionality of the adapter with the hardware configuration you have
assigned. You can use the diagnostics 'Network Test' to test the ability of the
adapter to communicate across the Ethernet with another PC equipped with a
CS8900/20-based adapter card (it must also be running the CS8900/20 Setup
Utility).
.. note::
The Setup Utility's diagnostics are designed to run in a
DOS-only operating system environment. DO NOT run the diagnostics
from a DOS or command prompt session under Windows 95, Windows NT,
OS/2, or other operating system.
To run the diagnostics tests on the CS8900/20 adapter:
1. Boot DOS on the PC and start the CS8900/20 Setup Utility.
2. The adapter's current configuration is displayed. Hit the ENTER key to
get to the main menu.
4. Select 'Diagnostics' (ALT-G) from the main menu.
* Select 'Self-Test' to test the adapter's basic functionality.
* Select 'Network Test' to test the network connection and cabling.
5.2.1. Diagnostic Self-test
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The diagnostic self-test checks the adapter's basic functionality as well as
its ability to communicate across the ISA bus based on the system resources
assigned during hardware configuration. The following tests are performed:
* IO Register Read/Write Test
The IO Register Read/Write test insures that the CS8900/20 can be
accessed in IO mode, and that the IO base address is correct.
* Shared Memory Test
The Shared Memory test insures the CS8900/20 can be accessed in memory
mode and that the range of memory addresses assigned does not conflict
with other devices in the system.
* Interrupt Test
The Interrupt test insures there are no conflicts with the assigned IRQ
signal.
* EEPROM Test
The EEPROM test insures the EEPROM can be read.
* Chip RAM Test
The Chip RAM test insures the 4K of memory internal to the CS8900/20 is
working properly.
* Internal Loop-back Test
The Internal Loop Back test insures the adapter's transmitter and
receiver are operating properly. If this test fails, make sure the
adapter's cable is connected to the network (check for LED activity for
example).
* Boot PROM Test
The Boot PROM test insures the Boot PROM is present, and can be read.
Failure indicates the Boot PROM was not successfully read due to a
hardware problem or due to a conflicts on the Boot PROM address
assignment. (Test only applies if the adapter is configured to use the
Boot PROM option.)
Failure of a test item indicates a possible system resource conflict with
another device on the ISA bus. In this case, you should use the Manual Setup
option to reconfigure the adapter by selecting a different value for the system
resource that failed.
5.2.2. Diagnostic Network Test
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The Diagnostic Network Test verifies a working network connection by
transferring data between two CS8900/20 adapters installed in different PCs
on the same network. (Note: the diagnostic network test should not be run
between two nodes across a router.)
This test requires that each of the two PCs have a CS8900/20-based adapter
installed and have the CS8900/20 Setup Utility running. The first PC is
configured as a Responder and the other PC is configured as an Initiator.
Once the Initiator is started, it sends data frames to the Responder which
returns the frames to the Initiator.
The total number of frames received and transmitted are displayed on the
Initiator's display, along with a count of the number of frames received and
transmitted OK or in error. The test can be terminated anytime by the user at
either PC.
To setup the Diagnostic Network Test:
1. Select a PC with a CS8900/20-based adapter and a known working network
connection to act as the Responder. Run the CS8900/20 Setup Utility
and select 'Diagnostics -> Network Test -> Responder' from the main
menu. Hit ENTER to start the Responder.
2. Return to the PC with the CS8900/20-based adapter you want to test and
start the CS8900/20 Setup Utility.
3. From the main menu, Select 'Diagnostic -> Network Test -> Initiator'.
Hit ENTER to start the test.
You may stop the test on the Initiator at any time while allowing the Responder
to continue running. In this manner, you can move to additional PCs and test
them by starting the Initiator on another PC without having to stop/start the
Responder.
5.3. Using the Adapter's LEDs
-----------------------------
The 2 and 3-media adapters have two LEDs visible on the back end of the board
located near the 10Base-T connector.
Link Integrity LED: A "steady" ON of the green LED indicates a valid 10Base-T
connection. (Only applies to 10Base-T. The green LED has no significance for
a 10Base-2 or AUI connection.)
TX/RX LED: The yellow LED lights briefly each time the adapter transmits or
receives data. (The yellow LED will appear to "flicker" on a typical network.)
5.4. Resolving I/O Conflicts
----------------------------
An IO conflict occurs when two or more adapter use the same ISA resource (IO
address, memory address or IRQ). You can usually detect an IO conflict in one
of four ways after installing and or configuring the CS8900/20-based adapter:
1. The system does not boot properly (or at all).
2. The driver cannot communicate with the adapter, reporting an "Adapter
not found" error message.
3. You cannot connect to the network or the driver will not load.
4. If you have configured the adapter to run in memory mode but the driver
reports it is using IO mode when loading, this is an indication of a
memory address conflict.
If an IO conflict occurs, run the CS8900/20 Setup Utility and perform a
diagnostic self-test. Normally, the ISA resource in conflict will fail the
self-test. If so, reconfigure the adapter selecting another choice for the
resource in conflict. Run the diagnostics again to check for further IO
conflicts.
In some cases, such as when the PC will not boot, it may be necessary to remove
the adapter and reconfigure it by installing it in another PC to run the
CS8900/20 Setup Utility. Once reinstalled in the target system, run the
diagnostics self-test to ensure the new configuration is free of conflicts
before loading the driver again.
When manually configuring the adapter, keep in mind the typical ISA system
resource usage as indicated in the tables below.
::
I/O Address Device IRQ Device
----------- -------- --- --------
200-20F Game I/O adapter 3 COM2, Bus Mouse
230-23F Bus Mouse 4 COM1
270-27F LPT3: third parallel port 5 LPT2
2F0-2FF COM2: second serial port 6 Floppy Disk controller
320-32F Fixed disk controller 7 LPT1
8 Real-time Clock
9 EGA/VGA display adapter
12 Mouse (PS/2)
Memory Address Device 13 Math Coprocessor
-------------- --------------------- 14 Hard Disk controller
A000-BFFF EGA Graphics Adapter
A000-C7FF VGA Graphics Adapter
B000-BFFF Mono Graphics Adapter
B800-BFFF Color Graphics Adapter
E000-FFFF AT BIOS
6. Technical Support
====================
6.1. Contacting Cirrus Logic's Technical Support
------------------------------------------------
Cirrus Logic's CS89XX Technical Application Support can be reached at::
Telephone :(800) 888-5016 (from inside U.S. and Canada)
:(512) 442-7555 (from outside the U.S. and Canada)
Fax :(512) 912-3871
Email :ethernet@crystal.cirrus.com
WWW :http://www.cirrus.com
6.2. Information Required before Contacting Technical Support
-------------------------------------------------------------
Before contacting Cirrus Logic for technical support, be prepared to provide as
Much of the following information as possible.
1.) Adapter type (CRD8900, CDB8900, CDB8920, etc.)
2.) Adapter configuration
* IO Base, Memory Base, IO or memory mode enabled, IRQ, DMA channel
* Plug and Play enabled/disabled (CS8920-based adapters only)
* Configured for media auto-detect or specific media type (which type).
3.) PC System's Configuration
* Plug and Play system (yes/no)
* BIOS (make and version)
* System make and model
* CPU (type and speed)
* System RAM
* SCSI Adapter
4.) Software
* CS89XX driver and version
* Your network operating system and version
* Your system's OS version
* Version of all protocol support files
5.) Any Error Message displayed.
6.3 Obtaining the Latest Driver Version
---------------------------------------
You can obtain the latest CS89XX drivers and support software from Cirrus Logic's
Web site. You can also contact Cirrus Logic's Technical Support (email:
ethernet@crystal.cirrus.com) and request that you be registered for automatic
software-update notification.
Cirrus Logic maintains a web page at http://www.cirrus.com with the
latest drivers and technical publications.
6.4. Current maintainer
-----------------------
In February 2000 the maintenance of this driver was assumed by Andrew
Morton.
6.5 Kernel module parameters
----------------------------
For use in embedded environments with no cs89x0 EEPROM, the kernel boot
parameter ``cs89x0_media=`` has been implemented. Usage is::
cs89x0_media=rj45 or
cs89x0_media=aui or
cs89x0_media=bnc
Documentation/networking/device_drivers/ethernet/index.rst
-1
View File
@@ -19,7 +19,6 @@ Contents:
amd/pds_vfio_pci
aquantia/atlantic
chelsio/cxgb
cirrus/cs89x0
dlink/dl2k
davicom/dm9000
dec/dmfe
Documentation/networking/devlink/devlink-health.rst
+8 -4
View File
@@ -33,7 +33,9 @@ Device driver can provide specific callbacks for each "health reporter", e.g.:
* Recovery procedures
* Diagnostics procedures
* Object dump procedures
* Out Of Box initial parameters
Drivers also provide default values for generic reporter parameters when
creating a health reporter.
Different parts of the driver can register different types of health reporters
with different handlers.
@@ -45,8 +47,9 @@ Once an error is reported, devlink health will perform the following actions:
* A log is being send to the kernel trace events buffer
* Health status and statistics are being updated for the reporter instance
* Object dump is being taken and saved at the reporter instance (as long as
auto-dump is set and there is no other dump which is already stored)
* Object dump is being taken and saved at the reporter instance. This is
best effort and skipped when recovery is aborted, auto-dump is disabled,
no dump callback is registered, or a dump is already stored.
* Auto recovery attempt is being done. Depends on:
- Auto-recovery configuration
@@ -75,7 +78,8 @@ User Interface
==============
User can access/change each reporter's parameters and driver specific callbacks
via ``devlink``, e.g per error type (per health reporter):
via ``devlink``, e.g. per error type (per health reporter). Reporters may be
registered for the whole devlink instance or for a specific devlink port.
* Configure reporter's generic parameters (like: disable/enable auto recovery)
* Invoke recovery procedure
Documentation/networking/devlink/devlink-params.rst
+1 -1
View File
@@ -122,7 +122,7 @@ own name.
* - ``enable_iwarp``
- Boolean
- Enable handling of iWARP traffic in the device.
* - ``internal_err_reset``
* - ``internal_error_reset``
- Boolean
- When enabled, the device driver will reset the device on internal
errors.
Documentation/networking/devlink/devlink-port.rst
+4 -1
View File
@@ -38,7 +38,7 @@ Devlink port flavours are described below.
- This indicates an eswitch port representing a port of PCI
subfunction (SF).
* - ``DEVLINK_PORT_FLAVOUR_VIRTUAL``
- This indicates a virtual port for the PCI virtual function.
- Any virtual port facing the user.
Devlink port can have a different type based on the link layer described below.
@@ -134,6 +134,9 @@ Users may also set the IPsec crypto capability of the function using
Users may also set the IPsec packet capability of the function using
`devlink port function set ipsec_packet` command.
The ``migratable`` attribute may be set only on ports with
``DEVLINK_PORT_FLAVOUR_PCI_VF``.
Users may also set the maximum IO event queues of the function
using `devlink port function set max_io_eqs` command.
Documentation/networking/devlink/devlink-trap.rst
+5 -3
View File
@@ -516,9 +516,11 @@ Generic Packet Trap Groups
Generic packet trap groups are used to aggregate logically related packet
traps. These groups allow the user to batch operations such as setting the trap
action of all member traps. In addition, ``devlink-trap`` can report aggregated
per-group packets and bytes statistics, in case per-trap statistics are too
narrow. The description of these groups must be added to the following table:
action of all member drop traps whose action may legally change. Exception and
control traps remain unchanged. In addition, ``devlink-trap`` can report
aggregated per-group packets and bytes statistics, in case per-trap statistics
are too narrow. The description of these groups must be added to the following
table:
.. list-table:: List of Generic Packet Trap Groups
:widths: 10 90
Documentation/networking/devlink/index.rst
+5 -5
View File
@@ -13,8 +13,8 @@ new APIs prefixed by ``devl_*``. The older APIs handle all the locking
in devlink core, but don't allow registration of most sub-objects once
the main devlink object is itself registered. The newer ``devl_*`` APIs assume
the devlink instance lock is already held. Drivers can take the instance
lock by calling ``devl_lock()``. It is also held all callbacks of devlink
netlink commands.
lock by calling ``devl_lock()``. It is also held across all callbacks of
devlink netlink commands.
Drivers are encouraged to use the devlink instance lock for their own needs.
@@ -33,11 +33,11 @@ sure to respect following rules:
lock of both nested and parent instances at the same time, devlink
instance lock of the parent instance should be taken first, only then
instance lock of the nested instance could be taken.
- Driver should use object-specific helpers to setup the
nested relationship:
- Driver should use object-specific helpers to setup the nested relationship
before registering the nested devlink instance:
- ``devl_nested_devlink_set()`` - called to setup devlink -> nested
devlink relationship (could be user for multiple nested instances.
devlink relationship (could be used for multiple nested instances).
- ``devl_port_fn_devlink_set()`` - called to setup port function ->
nested devlink relationship.
- ``devlink_linecard_nested_dl_set()`` - called to setup linecard ->
Documentation/networking/devlink/stmmac.rst
+1 -1
View File
@@ -24,7 +24,7 @@ The ``stmmac`` driver implements the following driver-specific parameters.
- runtime
- Enable the Coarse timestamping mode, as defined in the DWMAC TRM.
A detailed explanation of this timestamping mode can be found in the
Socfpga Functionnal Description [1].
Socfpga Functional Description [1].
In Coarse mode, the ptp clock is expected to be fed by a high-precision
clock that is externally adjusted, and the subsecond increment used for
Documentation/networking/devmem.rst
+11 -16
View File
@@ -103,24 +103,22 @@ The user must bind a dmabuf to any number of RX queues on a given NIC using
the netlink API::
/* Bind dmabuf to NIC RX queue 15 */
struct netdev_queue *queues;
queues = malloc(sizeof(*queues) * 1);
struct netdev_queue_id *queues;
queues[0]._present.type = 1;
queues[0]._present.idx = 1;
queues[0].type = NETDEV_RX_QUEUE_TYPE_RX;
queues[0].idx = 15;
queues = netdev_queue_id_alloc(1);
netdev_queue_id_set_type(&queues[0], NETDEV_QUEUE_TYPE_RX);
netdev_queue_id_set_id(&queues[0], 15);
*ys = ynl_sock_create(&ynl_netdev_family, &yerr);
req = netdev_bind_rx_req_alloc();
netdev_bind_rx_req_set_ifindex(req, 1 /* ifindex */);
netdev_bind_rx_req_set_dmabuf_fd(req, dmabuf_fd);
__netdev_bind_rx_req_set_queues(req, queues, n_queue_index);
netdev_bind_rx_req_set_fd(req, dmabuf_fd);
__netdev_bind_rx_req_set_queues(req, queues, 1);
rsp = netdev_bind_rx(*ys, req);
dmabuf_id = rsp->dmabuf_id;
dmabuf_id = rsp->id;
The netlink API returns a dmabuf_id: a unique ID that refers to this dmabuf
@@ -302,13 +300,12 @@ The user should create a msghdr where,
* iov_base is set to the offset into the dmabuf to start sending from
* iov_len is set to the number of bytes to be sent from the dmabuf
The user passes the dma-buf id to send from via the dmabuf_tx_cmsg.dmabuf_id.
The user passes the dma-buf id to send from as a u32 cmsg payload.
The example below sends 1024 bytes from offset 100 into the dmabuf, and 2048
from offset 2000 into the dmabuf. The dmabuf to send from is tx_dmabuf_id::
char ctrl_data[CMSG_SPACE(sizeof(struct dmabuf_tx_cmsg))];
struct dmabuf_tx_cmsg ddmabuf;
char ctrl_data[CMSG_SPACE(sizeof(__u32))];
struct msghdr msg = {};
struct cmsghdr *cmsg;
struct iovec iov[2];
@@ -327,11 +324,9 @@ from offset 2000 into the dmabuf. The dmabuf to send from is tx_dmabuf_id::
cmsg = CMSG_FIRSTHDR(&msg);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_DEVMEM_DMABUF;
cmsg->cmsg_len = CMSG_LEN(sizeof(struct dmabuf_tx_cmsg));
cmsg->cmsg_len = CMSG_LEN(sizeof(__u32));
ddmabuf.dmabuf_id = tx_dmabuf_id;
*((struct dmabuf_tx_cmsg *)CMSG_DATA(cmsg)) = ddmabuf;
*((__u32 *)CMSG_DATA(cmsg)) = tx_dmabuf_id;
sendmsg(socket_fd, &msg, MSG_ZEROCOPY);
Documentation/networking/driver.rst
+18 -2
View File
@@ -51,7 +51,7 @@ for a driver implementing scatter-gather this means:
{
u32 used = READ_ONCE(dr->prod) - READ_ONCE(dr->cons);
return dr->tx_ring_size - (used & bp->tx_ring_mask);
return dr->tx_ring_size - (used & dr->tx_ring_mask);
}
static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
@@ -69,7 +69,7 @@ for a driver implementing scatter-gather this means:
//...
/* This should be a very rare race - log it. */
if (drv_tx_avail(dr) <= skb_shinfo(skb)->nr_frags + 1) {
netif_stop_queue(dev);
netif_tx_stop_queue(txq);
netdev_warn(dev, "Tx Ring full when queue awake!\n");
return NETDEV_TX_BUSY;
}
@@ -103,6 +103,9 @@ Lockless queue stop / wake helper macros
.. kernel-doc:: include/net/netdev_queues.h
:doc: Lockless queue stopping / waking helpers.
The standard macros like netif_txq_maybe_stop(), netif_txq_try_stop() etc.
are well tested, prefer them over local synchronization schemes.
No exclusive ownership
----------------------
@@ -125,3 +128,16 @@ to be freed up.
If you return NETDEV_TX_BUSY from the ndo_start_xmit method, you
must not keep any reference to that SKB and you must not attempt
to free it up.
Error message reporting
=======================
A number of driver configuration interfaces pass a Netlink extended ACK
(``extack``) object to the driver (either directly as an argument or
as a member of a parameter struct). The drivers should try to report
most errors via the ``extack`` object. System level exceptions,
indicating that system or device is misbehaving or is in bad state,
should continue to be reported to system logs.
Messages should be passed **either** via ``extack`` **or** to system logs.
Drivers should not try to report the same information to both.
Documentation/networking/dsa/dsa.rst
+1 -1
View File
@@ -509,7 +509,7 @@ Device Tree
-----------
DSA features a standardized binding which is documented in
``Documentation/devicetree/bindings/net/dsa/dsa.txt``. PHY/MDIO library helper
``Documentation/devicetree/bindings/net/dsa/dsa.yaml``. PHY/MDIO library helper
functions such as ``of_get_phy_mode()``, ``of_phy_connect()`` are also used to query
per-port PHY specific details: interface connection, MDIO bus location, etc.
Documentation/networking/dsa/lan9303.rst
+1 -1
View File
@@ -12,7 +12,7 @@ Driver details
The driver is implemented as a DSA driver, see ``Documentation/networking/dsa/dsa.rst``.
See ``Documentation/devicetree/bindings/net/dsa/lan9303.txt`` for device tree
See ``Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml`` for device tree
binding.
The LAN9303 can be managed both via MDIO and I2C, both supported by this driver.
Documentation/networking/ip-sysctl.rst
+6 -2
View File
@@ -489,7 +489,7 @@ tcp_ecn - INTEGER
tcp_ecn_option - INTEGER
Control Accurate ECN (AccECN) option sending when AccECN has been
successfully negotiated during handshake. Send logic inhibits
sending AccECN options regarless of this setting when no AccECN
sending AccECN options regardless of this setting when no AccECN
option has been seen for the reverse direction.
Possible values are:
@@ -2444,7 +2444,11 @@ fib_multipath_hash_policy - INTEGER
Possible values:
- 0 - Layer 3 (source and destination addresses plus flow label)
- 0 - Layer 3 (source and destination addresses plus flow label).
For IPv6 TCP, the local ECMP path is selected from the socket
txhash rather than the flow label, and may change after a TCP
rehash event (such as a retransmission timeout) to recover from
path failure. The on-wire flow label is unaffected.
- 1 - Layer 4 (standard 5-tuple)
- 2 - Layer 3 or inner Layer 3 if present
- 3 - Custom multipath hash. Fields used for multipath hash calculation
Documentation/networking/ipvs-sysctl.rst
+44
View File
@@ -56,6 +56,50 @@ conn_lfactor - INTEGER
-4: grow if load goes above 6% (buckets = nodes * 16)
2: grow if load goes above 400% (buckets = nodes / 4)
conn_max - INTEGER
Limit for number of connections, per netns.
Controls the soft and hard limit for number of connections.
Initially, the platform specific limit is assigned for init_net.
The value can be changed and later the soft limit propagated
to other networking namespaces.
Privileged admin can change both limits up to the value of the
platform limit while the unprivileged admin can change only the
soft limit up to the value of the hard limit.
For setups using conntrack=1 (CONFIG_IP_VS_NFCT for
Netfilter connection tracking) the connections can be
limited also by nf_conntrack_max.
Limits for init_net:
======================= =============== =============
\ soft limit hard limit
======================= =============== =============
create netns platform platform
priv admin 0 .. platform 0 .. platform
======================= =============== =============
Limits for new netns:
======================= =============== =============
\ soft limit hard limit
======================= =============== =============
create netns init_net:soft init_net:soft
priv admin 0 .. platform 0 .. platform
unpriv admin 0 .. hard N/A
======================= =============== =============
Limits per platform:
- 1,073,741,824 (2^30 for 64-bit)
- 16,777,216 (2^24 for 32-bit)
Possible values: 0 .. platform limit
Default: platform limit
conn_reuse_mode - INTEGER
1 - default
Documentation/networking/mptcp-sysctl.rst
+13
View File
@@ -21,6 +21,19 @@ add_addr_timeout - INTEGER (seconds)
Default: 120
add_addr_v6_port_drop_ts - BOOLEAN
Control whether preparing an ADD_ADDR with an IPv6 address and a port
should drop the TCP timestamps option to have enough option space to
send the signal.
If there is not enough option space, and the TCP timestamps option
cannot be dropped, the signal cannot be sent. Note that dropping the TCP
timestamps option for one packet of the connection could disrupt some
middleboxes: even if it should be unlikely, they could drop the packet
or block the connection. This is a per-namespace sysctl.
Default: 1 (enabled)
allow_join_initial_addr_port - BOOLEAN
Allow peers to send join requests to the IP address and port number used
by the initial subflow if the value is 1. This controls a flag that is
Documentation/networking/napi.rst
+8 -3
View File
@@ -49,7 +49,11 @@ instance to be released.
The control APIs are not idempotent. Control API calls are safe against
concurrent use of datapath APIs but an incorrect sequence of control API
calls may result in crashes, deadlocks, or race conditions. For example,
calling napi_disable() multiple times in a row will deadlock.
calling napi_disable() multiple times in a row will hang waiting for
ownership of the NAPI instance to be released.
Drivers using the netdev instance lock may need to use the ``_locked()``
variants of the control APIs when that lock is already held.
Datapath API
------------
@@ -190,7 +194,8 @@ User API
========
User interactions with NAPI depend on NAPI instance ID. The instance IDs
are only visible to the user thru the ``SO_INCOMING_NAPI_ID`` socket option.
are visible to the user through the ``SO_INCOMING_NAPI_ID`` socket option
and the netdev Netlink API.
Users can query NAPI IDs for a device or device queue using netlink. This can
be done programmatically in a user application or by using a script included in
@@ -371,7 +376,7 @@ To use this mechanism:
the application has stalled. This value should be chosen so that it covers
the amount of time the user application needs to process data from its
call to epoll_wait, noting that applications can control how much data
they retrieve by setting ``max_events`` when calling epoll_wait.
they retrieve by setting ``maxevents`` when calling epoll_wait.
2. The sysfs parameter or per-NAPI config parameters ``gro_flush_timeout``
and ``napi_defer_hard_irqs`` can be set to low values. They will be used
Documentation/networking/net_cachelines/net_device.rst
+1 -3
View File
@@ -10,7 +10,7 @@ Type Name fastpath_tx_acce
=================================== =========================== =================== =================== ===================================================================================
unsigned_long:32 priv_flags read_mostly __dev_queue_xmit(tx)
unsigned_long:1 lltx read_mostly HARD_TX_LOCK,HARD_TX_TRYLOCK,HARD_TX_UNLOCK(tx)
unsigned long:1 netmem_tx:1; read_mostly
unsigned_long:2 netmem_tx:2; read_mostly
char name[16]
struct netdev_name_node* name_node
struct dev_ifalias* ifalias
@@ -90,8 +90,6 @@ struct inet6_dev* ip6_ptr read_mostly
struct vlan_info* vlan_info
struct dsa_port* dsa_ptr
struct tipc_bearer* tipc_ptr
void* atalk_ptr
void* ax25_ptr
struct wireless_dev* ieee80211_ptr
struct wpan_dev* ieee802154_ptr
struct mpls_dev* mpls_ptr
Documentation/networking/net_cachelines/tcp_sock.rst
+5 -5
View File
@@ -13,16 +13,16 @@ u16 tcp_header_len read_mostly read_m
u16 gso_segs read_mostly tcp_xmit_size_goal
__be32 pred_flags read_write read_mostly tcp_select_window(tx);tcp_rcv_established(rx)
u64 bytes_received read_write tcp_rcv_nxt_update(rx)
u32 segs_in read_write tcp_v6_rcv(rx)
u32 segs_in read_write read_write tcp_segs_in(),tcp_v6_rcv(rx),tcp_v4_rcv()
u32 data_segs_in read_write tcp_v6_rcv(rx)
u32 rcv_nxt read_mostly read_write tcp_cleanup_rbuf,tcp_send_ack,tcp_inq_hint,tcp_transmit_skb,tcp_receive_window(tx);tcp_v6_do_rcv,tcp_rcv_established,tcp_data_queue,tcp_receive_window,tcp_rcv_nxt_update(write)(rx)
u32 copied_seq read_mostly tcp_cleanup_rbuf,tcp_rcv_space_adjust,tcp_inq_hint
u32 rcv_wup read_write __tcp_cleanup_rbuf,tcp_receive_window,tcp_receive_established
u32 snd_nxt read_write read_mostly tcp_rate_check_app_limited,__tcp_transmit_skb,tcp_event_new_data_sent(write)(tx);tcp_rcv_established,tcp_ack,tcp_clean_rtx_queue(rx)
u32 segs_out read_write __tcp_transmit_skb
u32 segs_out read_write read_write __tcp_transmit_skb
u32 data_segs_out read_write __tcp_transmit_skb,tcp_update_skb_after_send
u64 bytes_sent read_write __tcp_transmit_skb
u64 bytes_acked read_write tcp_snd_una_update/tcp_ack
u64 bytes_acked read_write tcp_snd_una_update/tcp_ack
u32 dsack_dups
u32 snd_una read_mostly read_write tcp_wnd_end,tcp_urg_mode,tcp_minshall_check,tcp_cwnd_validate(tx);tcp_ack,tcp_may_update_window,tcp_clean_rtx_queue(write),tcp_ack_tstamp(rx)
u32 snd_sml read_write tcp_minshall_check,tcp_minshall_update
@@ -99,8 +99,8 @@ u32 snd_cwnd_stamp
u32 prior_cwnd
u32 prr_delivered
u32 prr_out read_mostly read_mostly tcp_rate_skb_sent,tcp_newly_delivered(tx);tcp_ack,tcp_rate_gen,tcp_clean_rtx_queue(rx)
u32 delivered read_mostly read_write tcp_rate_skb_sent, tcp_newly_delivered(tx);tcp_ack, tcp_rate_gen, tcp_clean_rtx_queue (rx)
u32 delivered_ce read_mostly read_write tcp_rate_skb_sent(tx);tcp_rate_gen(rx)
u32 delivered read_write tcp_rate_skb_sent, tcp_newly_delivered(tx);tcp_ack, tcp_rate_gen, tcp_clean_rtx_queue (rx)
u32 delivered_ce read_write tcp_rate_skb_sent(tx);tcp_rate_gen(rx)
u32 received_ce read_mostly read_write
u32[3] received_ecn_bytes read_mostly read_write
u8:4 received_ce_pending read_mostly read_write
Documentation/networking/netdev-features.rst
+45 -20
View File
@@ -18,29 +18,38 @@ that relieve an OS of various tasks like generating and checking checksums,
splitting packets, classifying them. Those capabilities and their state
are commonly referred to as netdev features in Linux kernel world.
There are currently three sets of features relevant to the driver, and
one used internally by network core:
There are currently three main sets of features on each netdevice,
first and second are initialized by the driver:
1. netdev->hw_features set contains features whose state may possibly
be changed (enabled or disabled) for a particular device by user's
request. This set should be initialized in ndo_init callback and not
changed later.
request. Drivers normally initialize this set before registration or
in the ndo_init callback. Changes after registration should be made
very carefully as other parts of the code may assume hw_features are
static. At the very least changes must be made under rtnl_lock and
the netdev instance lock, and followed by netdev_update_features().
2. netdev->features set contains features which are currently enabled
for a device. This should be changed only by network core or in
error paths of ndo_set_features callback.
3. netdev->vlan_features set contains features whose state is inherited
by child VLAN devices (limits netdev->features set). This is currently
used for all VLAN devices whether tags are stripped or inserted in
hardware or software.
4. netdev->wanted_features set contains feature set requested by user.
3. netdev->wanted_features set contains feature set requested by user.
This set is filtered by ndo_fix_features callback whenever it or
some device-specific conditions change. This set is internal to
networking core and should not be referenced in drivers.
On top of those three main sets, each netdev has:
1. Sets which control features inherited by child devices (VLAN, MPLS,
hw_enc for L3/L4 tunnels). These sets allow the driver to limit which
netdev->features are propagated, in case HW cannot perform the offloads
with the extra headers present.
2. netdev->mangleid_features, TSO features which are supported only when
IP ID field can be mangled (constant instead of incrementing) during TSO.
3. netdev->gso_partial_features, additional TSO features which HW can
support via NETIF_F_GSO_PARTIAL.
Part II: Controlling enabled features
=====================================
@@ -62,11 +71,22 @@ ndo_*_features callbacks are called with rtnl_lock held. Missing callbacks
are treated as always returning success.
A driver that wants to trigger recalculation must do so by calling
netdev_update_features() while holding rtnl_lock. This should not be done
from ndo_*_features callbacks. netdev->features should not be modified by
driver except by means of ndo_fix_features callback.
netdev_update_features() while holding rtnl_lock. If the device uses the
netdev instance lock, that lock must be held as well. This should not be
done from ndo_*_features callbacks. netdev->features should not be modified
by driver except by means of ndo_fix_features callback.
For "ops locked" drivers (see Documentation/networking/netdevices.rst),
ethtool callbacks that may end up invoking netdev_update_features() must
opt back into rtnl_lock by setting the matching ETHTOOL_OP_NEEDS_RTNL_*
bit in ``ethtool_ops::op_needs_rtnl``. The ethtool core then keeps
rtnl_lock held across those SET callbacks so the contract above still
holds.
ndo_features_check is called for each skb before that skb is passed to
ndo_start_xmit. Driver may perform any non-trivial checks (e.g. exact
header geometry / length) and withdraw features like HW_CSUM or TSO,
requesting the networking stack to fall back to the software implementation.
Part III: Implementation hints
==============================
@@ -83,8 +103,9 @@ stateless). It can be called multiple times between successive
ndo_set_features calls.
Callback must not alter features contained in NETIF_F_SOFT_FEATURES or
NETIF_F_NEVER_CHANGE sets. The exception is NETIF_F_VLAN_CHALLENGED but
care must be taken as the change won't affect already configured VLANs.
NETIF_F_NEVER_CHANGE, except that NETIF_F_VLAN_CHALLENGED may be changed.
Care must be taken as changes to NETIF_F_VLAN_CHALLENGED won't affect already
configured VLANs.
* ndo_set_features:
@@ -186,10 +207,14 @@ Redundancy) frames from one port to another in hardware.
* hsr-dup-offload
This should be set for devices which duplicate outgoing HSR (High-availability
Seamless Redundancy) or PRP (Parallel Redundancy Protocol) tags automatically
frames in hardware.
Seamless Redundancy) or PRP (Parallel Redundancy Protocol) frames
automatically in hardware.
* netmem-tx
Part V: Related device flags
============================
This should be set for devices which support netmem TX. See
Documentation/networking/netmem.rst
* netdev->netmem_tx
This is not a netdev feature bit. Drivers support netmem TX by setting
netdev->netmem_tx to one of the values in enum netmem_tx_mode.
See Documentation/networking/netmem.rst.
Documentation/networking/netdevices.rst
+28 -21
View File
@@ -21,13 +21,14 @@ by free_netdev(). This is required to handle the pathological case cleanly
alloc_netdev_mqs() / alloc_netdev() reserve extra space for driver
private data which gets freed when the network device is freed. If
separately allocated data is attached to the network device
(netdev_priv()) then it is up to the module exit handler to free that.
(extra pointers stored in the device private struct) then it is up
to the module exit handler to free that.
There are two groups of APIs for registering struct net_device.
First group can be used in normal contexts where ``rtnl_lock`` is not already
held: register_netdev(), unregister_netdev().
Second group can be used when ``rtnl_lock`` is already held:
register_netdevice(), unregister_netdevice(), free_netdevice().
register_netdevice(), unregister_netdevice(), free_netdev().
Simple drivers
--------------
@@ -58,6 +59,7 @@ the register_netdev(), and unregister_netdev() functions:
goto err_undo;
/* net_device is visible to the user! */
return 0;
err_undo:
/* ... undo the device setup ... */
@@ -73,7 +75,7 @@ the register_netdev(), and unregister_netdev() functions:
Note that after calling register_netdev() the device is visible in the system.
Users can open it and start sending / receiving traffic immediately,
or run any other callback, so all initialization must be done prior to
or run any other callback, so all initialization must be **complete** prior to
registration.
unregister_netdev() closes the device and waits for all users to be done
@@ -157,7 +159,7 @@ register_netdevice() fails. The callback may be invoked with or without
There is no explicit constructor callback, driver "constructs" the private
netdev state after allocating it and before registration.
Setting struct net_device.needs_free_netdev makes core call free_netdevice()
Setting struct net_device.needs_free_netdev makes core call free_netdev()
automatically after unregister_netdevice() when all references to the device
are gone. It only takes effect after a successful call to register_netdevice()
so if register_netdevice() fails driver is responsible for calling
@@ -256,7 +258,7 @@ ndo_eth_ioctl:
lock if the driver implements queue management or shaper API.
Context: process
ndo_get_stats:
ndo_get_stats / ndo_get_stats64:
Synchronization: RCU (can be called concurrently with the stats
update path).
Context: atomic (can't sleep under RCU)
@@ -264,12 +266,9 @@ ndo_get_stats:
ndo_start_xmit:
Synchronization: __netif_tx_lock spinlock.
When the driver sets dev->lltx this will be
called without holding netif_tx_lock. In this case the driver
has to lock by itself when needed.
The locking there should also properly protect against
set_rx_mode. WARNING: use of dev->lltx is deprecated.
Don't use it for new drivers.
When the driver sets dev->lltx this will be called without holding
netif_tx_lock. dev->lltx is meant for software drivers only, since
they often have no per-queue state.
Context: Process with BHs disabled or BH (timer),
will be called with interrupts disabled by netconsole.
@@ -304,11 +303,15 @@ ndo_change_rx_flags:
lock if the driver implements queue management or shaper API.
ndo_setup_tc:
``TC_SETUP_BLOCK`` and ``TC_SETUP_FT`` are running under NFT locks
(i.e. no ``rtnl_lock`` and no device instance lock). The rest of
``tc_setup_type`` types run under netdev instance lock if the driver
Locking depends on ``tc_setup_type``. For most types the callback
is invoked under ``rtnl_lock`` and netdev instance lock if the driver
implements queue management or shaper API.
For ``TC_SETUP_BLOCK`` and ``TC_SETUP_FT`` ``rtnl_lock`` may or
may not be held, and the netdev instance lock is not held.
``TC_SETUP_BLOCK`` runs under ``block->cb_lock`` and ``TC_SETUP_FT``
runs under ``flowtable->flow_block_lock``.
Most ndo callbacks not specified in the list above are running
under ``rtnl_lock``. In addition, netdev instance lock is taken as well if
the driver implements queue management or shaper API.
@@ -348,10 +351,6 @@ virtual and the physical device. To prevent deadlocks, the virtual device's
lock must always be acquired before the physical device's (see
``netdev_nl_queue_create_doit``).
In the future, there will be an option for individual
drivers to opt out of using ``rtnl_lock`` and instead perform their control
operations directly under the netdev instance lock.
Device drivers are encouraged to rely on the instance lock where possible.
For the (mostly software) drivers that need to interact with the core stack,
@@ -372,9 +371,16 @@ the instance lock.
struct ethtool_ops
------------------
Similarly to ``ndos`` the instance lock is only held for select drivers.
For "ops locked" drivers all ethtool ops without exceptions should
be called under the instance lock.
For non-"ops locked" drivers ethtool_ops are executed under ``rtnl_lock``.
For "ops locked" drivers, ``ethtool_ops``, unlike ``ndos``, run under
the instance lock **only**. Drivers may request that ``rtnl_lock``
is held around specific operations (both SET and GET) by setting
appropriate bits in ``ethtool_ops::op_needs_rtnl`` (if the necessary
``ETHTOOL_OP_NEEDS_RTNL_*`` bit doesn't exist, just add it).
Commonly used core helpers which force drivers to selectively opt-in to
``rtnl_lock`` protection include ``netdev_update_features()``,
``netif_set_real_num_tx_queues()``, and phylink helpers.
struct netdev_stat_ops
----------------------
@@ -412,6 +418,7 @@ The following netdev notifiers are always run under the instance lock:
For devices with locked ops, currently only the following notifiers are
running under the lock:
* ``NETDEV_CHANGE``
* ``NETDEV_CHANGENAME``
* ``NETDEV_REGISTER``
* ``NETDEV_UP``
Documentation/networking/netmem.rst
+7 -1
View File
@@ -95,4 +95,10 @@ Driver TX Requirements
netdev@, or reach out to the maintainers and/or almasrymina@google.com for
help adding the netmem API.
2. Driver should declare support by setting `netdev->netmem_tx = true`
2. Driver should declare support by setting `netdev->netmem_tx` to the
appropriate mode:
- `NETMEM_TX_DMA`: for physical devices that perform DMA.
- `NETMEM_TX_NO_DMA`: for virtual or passthrough devices that do
not DMA, but still support handling of netmem-backed skbs.
Documentation/networking/page_pool.rst
+21 -39
View File
@@ -43,18 +43,32 @@ Architecture overview
Monitoring
==========
Information about page pools on the system can be accessed via the netdev
genetlink family (see Documentation/netlink/specs/netdev.yaml).
Information about allocated page pools, their memory use, recycling statistics
etc. can be accessed via the netdev genetlink family
(see Documentation/netlink/specs/netdev.yaml).
Statistics
----------
.. kernel-doc:: include/net/page_pool/types.h
:identifiers: struct page_pool_recycle_stats
struct page_pool_alloc_stats
struct page_pool_stats
API interface
=============
The number of pools created **must** match the number of hardware queues
The number of pools created **must** match the number of NAPI contexts / queues
unless hardware restrictions make that impossible. This would otherwise beat the
purpose of page pool, which is allocate pages fast from cache without locking.
This lockless guarantee naturally comes from running under a NAPI softirq.
The protection doesn't strictly have to be NAPI, any guarantee that allocating
a page will cause no race conditions is enough.
If ``params.napi`` is set, the NAPI instance must be the sole consumer
context for pages allocated from the pool. In other words, when running in
that NAPI context, the page pool may safely access consumer-side resources
**without any additional locking**.
.. kernel-doc:: net/core/page_pool.c
:identifiers: page_pool_create
@@ -69,7 +83,7 @@ a page will cause no race conditions is enough.
page_pool_get_dma_addr page_pool_get_dma_dir
.. kernel-doc:: net/core/page_pool.c
:identifiers: page_pool_put_page_bulk page_pool_get_stats
:identifiers: page_pool_put_page_bulk
DMA sync
--------
@@ -98,29 +112,12 @@ If in doubt set ``offset`` to 0, ``max_len`` to ``PAGE_SIZE`` and
pass -1 as ``dma_sync_size``. That combination of arguments is always
correct.
Note that the syncing parameters are for the entire page.
This is important to remember when using fragments (``PP_FLAG_PAGE_FRAG``),
where allocated buffers may be smaller than a full page.
Note that the syncing parameters are for the **entire page**, even if
the driver allocates fragments (e.g. via ``page_pool_dev_alloc_frag()``).
Unless the driver author really understands page pool internals
it's recommended to always use ``offset = 0``, ``max_len = PAGE_SIZE``
with fragmented page pools.
Stats API and structures
------------------------
If the kernel is configured with ``CONFIG_PAGE_POOL_STATS=y``, the API
page_pool_get_stats() and structures described below are available.
It takes a pointer to a ``struct page_pool`` and a pointer to a struct
page_pool_stats allocated by the caller.
Older drivers expose page pool statistics via ethtool or debugfs.
The same statistics are accessible via the netlink netdev family
in a driver-independent fashion.
.. kernel-doc:: include/net/page_pool/types.h
:identifiers: struct page_pool_recycle_stats
struct page_pool_alloc_stats
struct page_pool_stats
Coding examples
===============
@@ -140,7 +137,7 @@ Registration
pp_params.pool_size = DESC_NUM;
pp_params.nid = NUMA_NO_NODE;
pp_params.dev = priv->dev;
pp_params.napi = napi; /* only if locking is tied to NAPI */
pp_params.napi = napi; /* only if this NAPI is the sole consumer, see above */
pp_params.dma_dir = xdp_prog ? DMA_BIDIRECTIONAL : DMA_FROM_DEVICE;
page_pool = page_pool_create(&pp_params);
@@ -174,21 +171,6 @@ NAPI poller
}
}
Stats
-----
.. code-block:: c
#ifdef CONFIG_PAGE_POOL_STATS
/* retrieve stats */
struct page_pool_stats stats = { 0 };
if (page_pool_get_stats(page_pool, &stats)) {
/* perhaps the driver reports statistics with ethool */
ethtool_print_allocation_stats(&stats.alloc_stats);
ethtool_print_recycle_stats(&stats.recycle_stats);
}
#endif
Driver unload
-------------
Documentation/networking/segmentation-offloads.rst
+36 -1
View File
@@ -14,10 +14,13 @@ to take advantage of segmentation offload capabilities of various NICs.
The following technologies are described:
* TCP Segmentation Offload - TSO
* UDP Fragmentation Offload - UFO
* UDP Segmentation Offload - USO
* IPIP, SIT, GRE, and UDP Tunnel Offloads
* Generic Segmentation Offload - GSO
* Generic Receive Offload - GRO
* Partial Generic Segmentation Offload - GSO_PARTIAL
* ESP Segmentation Offload
* Fraglist Generic Segmentation Offload - GSO_FRAGLIST
* SCTP acceleration with GSO - GSO_BY_FRAGS
@@ -38,7 +41,8 @@ In order to support TCP segmentation offload it is necessary to populate
the network and transport header offsets of the skbuff so that the device
drivers will be able determine the offsets of the IP or IPv6 header and the
TCP header. In addition as CHECKSUM_PARTIAL is required csum_start should
also point to the TCP header of the packet.
also point to the TCP header of the packet, or to the inner transport header
for encapsulated TSO.
For IPv4 segmentation we support one of two types in terms of the IP ID.
The default behavior is to increment the IP ID with every segment. If the
@@ -57,6 +61,10 @@ DF bit is not set on the outer header, in which case the device driver must
guarantee that the IP ID field is incremented in the outer header with every
segment.
SKB_GSO_TCP_ACCECN is a modifier used with TCP segmentation offload for
AccECN packets where the CWR bit must not be cleared during segmentation.
Devices advertise support for this using NETIF_F_GSO_ACCECN.
UDP Fragmentation Offload
=========================
@@ -71,6 +79,16 @@ still receive them from tuntap and similar devices. Offload of UDP-based
tunnel protocols is still supported.
UDP Segmentation Offload
========================
UDP segmentation offload allows a device to segment a large UDP packet into
multiple UDP datagrams. Unlike UFO, these are not IP fragments. The payload
size of each datagram is specified in skb_shinfo()->gso_size and the GSO type
is SKB_GSO_UDP_L4. Devices advertise support for this using
NETIF_F_GSO_UDP_L4.
IPIP, SIT, GRE, UDP Tunnel, and Remote Checksum Offloads
========================================================
@@ -154,6 +172,23 @@ that the IPv4 ID field is incremented in the case that a given header does
not have the DF bit set.
ESP Segmentation Offload
========================
ESP segmentation offload uses SKB_GSO_ESP to mark packets that require
IPsec ESP segmentation. This type is set by the XFRM output path for GSO
packets handled by ESP hardware offload.
Fraglist Generic Segmentation Offload
=====================================
Fraglist GSO uses SKB_GSO_FRAGLIST to mark packets whose segments are
already arranged as a list of skbs. The segmentation path splits the skb
based on that list rather than by creating segments of skb_shinfo()->gso_size
bytes from the linear and page-fragment data.
SCTP acceleration with GSO
===========================
Documentation/networking/skbuff.rst
-6
View File
@@ -29,9 +29,3 @@ dataref and headerless skbs
.. kernel-doc:: include/linux/skbuff.h
:doc: dataref and headerless skbs
Checksum information
--------------------
.. kernel-doc:: include/linux/skbuff.h
:doc: skb checksums
Documentation/networking/smc-sysctl.rst
+4 -4
View File
@@ -86,7 +86,7 @@ smcr_max_send_wr - INTEGER
Please be aware that all the buffers need to be allocated as a physically
continuous array in which each element is a single buffer and has the size
of SMC_WR_BUF_SIZE (48) bytes. If the allocation fails, we keep retrying
with half of the buffer count until it is ether successful or (unlikely)
with half of the buffer count until it is either successful or (unlikely)
we dip below the old hard coded value which is 16 where we give up much
like before having this control.
@@ -100,14 +100,14 @@ smcr_max_recv_wr - INTEGER
depending on the workload it can be a bottleneck in a sense that threads
have to wait for work request buffers to become available. Before the
introduction of this control the maximal number of work request buffers
available on the receive path used to be hard coded to 16. With this control
available on the receive path used to be hard coded to 48. With this control
it becomes configurable. The acceptable range is between 2 and 2048.
Please be aware that all the buffers need to be allocated as a physically
continuous array in which each element is a single buffer and has the size
of SMC_WR_BUF_SIZE (48) bytes. If the allocation fails, we keep retrying
with half of the buffer count until it is ether successful or (unlikely)
we dip below the old hard coded value which is 16 where we give up much
with half of the buffer count until it is either successful or (unlikely)
we dip below the old hard coded value which is 48 where we give up much
like before having this control.
Default: 48
Documentation/networking/statistics.rst
+15 -4
View File
@@ -231,8 +231,19 @@ Kernel-internal data structures
-------------------------------
The following structures are internal to the kernel, their members are
translated to netlink attributes when dumped. Drivers must not overwrite
the statistics they don't report with 0.
translated to netlink attributes when dumped. Fields are pre-initialized
to ``ETHTOOL_STAT_NOT_SET`` (by ``ethtool_stats_init()``); drivers must
leave fields they do not report at that value rather than overwriting
them with 0.
- ethtool_pause_stats()
- ethtool_fec_stats()
- ``struct ethtool_eth_ctrl_stats``
- ``struct ethtool_eth_mac_stats``
- ``struct ethtool_eth_phy_stats``
- ``struct ethtool_fec_hist``
- ``struct ethtool_fec_stats``
- ``struct ethtool_link_ext_stats``
- ``struct ethtool_mm_stats``
- ``struct ethtool_pause_stats``
- ``struct ethtool_phy_stats``
- ``struct ethtool_rmon_stats``
- ``struct ethtool_ts_stats``
Documentation/networking/strparser.rst
+11 -11
View File
@@ -40,8 +40,8 @@ Functions
::
strp_init(struct strparser *strp, struct sock *sk,
const struct strp_callbacks *cb)
int strp_init(struct strparser *strp, struct sock *sk,
const struct strp_callbacks *cb)
Called to initialize a stream parser. strp is a struct of type
strparser that is allocated by the upper layer. sk is the TCP
@@ -95,7 +95,7 @@ Functions
void strp_data_ready(struct strparser *strp);
The upper layer calls strp_tcp_data_ready when data is ready on
The upper layer calls strp_data_ready when data is ready on
the lower socket for strparser to process. This should be called
from a data_ready callback that is set on the socket. Note that
maximum messages size is the limit of the receive socket
@@ -123,9 +123,9 @@ There are seven callbacks:
should parse the sk_buff as containing the headers for the
next application layer message in the stream.
The skb->cb in the input skb is a struct strp_msg. Only
the offset field is relevant in parse_msg and gives the offset
where the message starts in the skb.
The strparser metadata in the input skb can be accessed with
strp_msg(skb). Only the offset field is relevant in parse_msg and
gives the offset where the message starts in the skb.
The return values of this function are:
@@ -176,11 +176,11 @@ There are seven callbacks:
received in rcv_msg (see strp_pause above). This callback
must be set.
The skb->cb in the input skb is a struct strp_msg. This
struct contains two fields: offset and full_len. Offset is
where the message starts in the skb, and full_len is the
the length of the message. skb->len - offset may be greater
than full_len since strparser does not trim the skb.
The strparser metadata in the input skb can be accessed with
strp_msg(skb). This struct contains two fields: offset and full_len.
Offset is where the message starts in the skb, and full_len is
the length of the message. skb->len - offset may be greater than
full_len since strparser does not trim the skb.
::
Documentation/networking/tcp_ao.rst
+27 -11
View File
@@ -7,9 +7,9 @@ TCP Authentication Option Linux implementation (RFC5925)
TCP Authentication Option (TCP-AO) provides a TCP extension aimed at verifying
segments between trusted peers. It adds a new TCP header option with
a Message Authentication Code (MAC). MACs are produced from the content
of a TCP segment using a hashing function with a password known to both peers.
of a TCP segment using a key known to both peers.
The intent of TCP-AO is to deprecate TCP-MD5 providing better security,
key rotation and support for a variety of hashing algorithms.
key rotation and support for a variety of MAC algorithms.
1. Introduction
===============
@@ -19,16 +19,18 @@ key rotation and support for a variety of hashing algorithms.
+----------------------+------------------------+-----------------------+
| | TCP-MD5 | TCP-AO |
+======================+========================+=======================+
|Supported hashing |MD5 |Must support HMAC-SHA1 |
|algorithms |(cryptographically weak)|(chosen-prefix attacks)|
| | |and CMAC-AES-128 (only |
| | |side-channel attacks). |
| | |May support any hashing|
| | |algorithm. |
|Supported MAC |MD5 of data and key |HMAC-SHA-1-96 and |
|algorithms |(cryptographically weak)|AES-128-CMAC-96. |
| | |Implementations are |
| | |permitted to support |
| | |additional algorithms. |
+----------------------+------------------------+-----------------------+
|Length of MACs (bytes)|16 |Typically 12-16. |
| | |Other variants that fit|
| | |TCP header permitted. |
|Length of MACs (bytes)|16 |12 for HMAC-SHA-1-96 |
| | |and AES-128-CMAC-96. |
| | |Implementations are |
| | |permitted to support |
| | |any MAC length that |
| | |fits in the TCP header.|
+----------------------+------------------------+-----------------------+
|Number of keys per |1 |Many |
|TCP connection | | |
@@ -296,6 +298,20 @@ userspace manage TCP-AO on a per-socket basis. In order to add/delete MKTs
It is not allowed to add a key on an established non-TCP-AO connection
as well as to remove the last key from TCP-AO connection.
``TCP_AO_ADD_KEY`` allows the MAC algorithm and MAC length to be selected.
Linux supports the mandatory-to-implement algorithms HMAC-SHA-1-96 and
AES-128-CMAC-96. In addition, as Linux extensions, it supports:
- HMAC-SHA256. Linux uses HMAC-SHA256 in the same way as HMAC-SHA1; this
includes omitting an explicit entropy extraction step. To work around the
missing entropy extraction, users should provide keys with full entropy. The
implementation is interoperable with other implementations of HMAC-SHA256 for
TCP-AO only when they have implemented the key derivation the same way (and
also the same MAC length is selected on each side).
- Any MAC length for any of the supported MAC algorithms, provided it fits in
the TCP header and is at least 4 bytes.
``setsockopt(TCP_AO_DEL_KEY)`` command may specify ``tcp_ao_del::current_key``
+ ``tcp_ao_del::set_current`` and/or ``tcp_ao_del::rnext``
+ ``tcp_ao_del::set_rnext`` which makes such delete "forced": it
Documentation/networking/tls-offload.rst
+39 -13
View File
@@ -13,7 +13,7 @@ Layer Protocol (ULP) and install the cryptographic connection state.
For details regarding the user-facing interface refer to the TLS
documentation in :ref:`Documentation/networking/tls.rst <kernel_tls>`.
``ktls`` can operate in three modes:
``ktls`` can operate in two modes:
* Software crypto mode (``TLS_SW``) - CPU handles the cryptography.
In most basic cases only crypto operations synchronous with the CPU
@@ -26,11 +26,6 @@ documentation in :ref:`Documentation/networking/tls.rst <kernel_tls>`.
This mode integrates best with the kernel stack and is described in detail
in the remaining part of this document
(``ethtool`` flags ``tls-hw-tx-offload`` and ``tls-hw-rx-offload``).
* Full TCP NIC offload mode (``TLS_HW_RECORD``) - mode of operation where
NIC driver and firmware replace the kernel networking stack
with its own TCP handling, it is not usable in production environments
making use of the Linux networking stack for example any firewalling
abilities or QoS and packet scheduling (``ethtool`` flag ``tls-hw-record``).
The operation mode is selected automatically based on device configuration,
offload opt-in or opt-out on per-connection basis is not currently supported.
@@ -104,6 +99,29 @@ at the end of kernel structures (see :c:member:`driver_state` members
in ``include/net/tls.h``) to avoid additional allocations and pointer
dereferences.
When the offloaded connection is destroyed the core calls
the :c:member:`tls_dev_del` callback so the driver can release per-direction
state:
.. code-block:: c
void (*tls_dev_del)(struct net_device *netdev,
struct tls_context *ctx,
enum tls_offload_ctx_dir direction);
``tls_dev_del`` is mandatory whenever ``tls_dev_add`` is provided.
The third TLS device callback is :c:member:`tls_dev_resync`, called by the core
to synchronize the TCP stream with the record boundaries:
.. code-block:: c
int (*tls_dev_resync)(struct net_device *netdev,
struct sock *sk, u32 seq, u8 *rcd_sn,
enum tls_offload_ctx_dir direction);
See the `Resync handling`_ section for details.
TX
--
@@ -255,9 +273,9 @@ Following helper should be used to test if resync is complete:
bool tls_offload_tx_resync_pending(struct sock *sk)
Next time ``ktls`` pushes a record it will first send its TCP sequence number
and TLS record number to the driver. Stack will also make sure that
the new record will start on a segment boundary (like it does when
the connection is initially added).
and TLS record number to the driver via the ``tls_dev_resync`` callback.
The stack will also make sure that the new record will start on a segment
boundary (like it does when the connection is initially added).
RX
--
@@ -349,9 +367,10 @@ all TLS record headers that have been logged since the resync request
started.
The kernel confirms the guessed location was correct and tells the device
the record sequence number. Meanwhile, the device had been parsing
and counting all records since the just-confirmed one, it adds the number
of records it had seen to the record number provided by the kernel.
the record sequence number via the ``tls_dev_resync`` callback. Meanwhile,
the device had been parsing and counting all records since the just-confirmed
one, it adds the number of records it had seen to the record number provided
by the kernel.
At this point the device is in sync and can resume decryption at next
segment boundary.
@@ -375,12 +394,19 @@ schedules resynchronization after it has received two completely encrypted
records.
The stack waits for the socket to drain and informs the device about
the next expected record number and its TCP sequence number. If the
the next expected record number and its TCP sequence number via the
``tls_dev_resync`` callback. If the
records continue to be received fully encrypted stack retries the
synchronization with an exponential back off (first after 2 encrypted
records, then after 4 records, after 8, after 16... up until every
128 records).
Rekey
=====
Offload does not currently support TLS 1.3, therefore key rotation
is not a concern for offloaded connections at this point.
Error handling
==============
Documentation/networking/xdp-rx-metadata.rst
+1 -1
View File
@@ -36,7 +36,7 @@ metadata available in which case the driver returns ``-ENODATA``.
Not all kfuncs have to be implemented by the device driver; when not
implemented, the default ones that return ``-EOPNOTSUPP`` will be used
to indicate the device driver have not implemented this kfunc.
to indicate the device driver has not implemented this kfunc.
Within an XDP frame, the metadata layout (accessed via ``xdp_buff``) is
Documentation/networking/xfrm/index.rst
+1
View File
@@ -9,5 +9,6 @@ XFRM Framework
xfrm_device
xfrm_proc
xfrm_migrate_state
xfrm_sync
xfrm_sysctl
Documentation/networking/xfrm/xfrm_migrate_state.rst
+274
View File
@@ -0,0 +1,274 @@
.. SPDX-License-Identifier: GPL-2.0
=====================
XFRM SA Migrate State
=====================
Overview
========
``XFRM_MSG_MIGRATE_STATE`` migrates a single SA, looked up using SPI and
mark, without involving policies. Unlike ``XFRM_MSG_MIGRATE``, which couples
SA and policy migration and allows migrating multiple SAs in one call, this
interface identifies the SA unambiguously via SPI and supports changing
the reqid, addresses, encapsulation, selector, and offload.
Because IKE daemons can manage policies independently of
the kernel, this interface allows precise per-SA migration without
requiring policy involvement. Optional netlink attributes follow an
omit-to-inherit model: omitting an attribute preserves the value from
the old SA. The ``flags`` field controls two exceptions: hardware offload
is inherited by default and can be suppressed with
``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD`` or overridden with ``XFRMA_OFFLOAD_DEV``;
the new selector is taken from ``new_sel`` by default and can instead be
derived from the new addresses with ``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL``.
SA Identification
=================
The struct is defined in ``include/uapi/linux/xfrm.h``. The SA is looked
up using ``xfrm_state_lookup()`` with ``id.spi``,
``id.daddr``, ``id.proto``, ``id.family``, and
``old_mark.v & old_mark.m`` as the mark key::
struct xfrm_user_migrate_state {
struct xfrm_usersa_id id; /* spi, daddr, proto, family */
xfrm_address_t new_daddr;
xfrm_address_t new_saddr;
struct xfrm_mark old_mark; /* SA lookup: key = v & m */
struct xfrm_selector new_sel; /* new selector (see Flags) */
__u32 new_reqid;
__u32 flags; /* XFRM_MIGRATE_STATE_* */
__u16 new_family;
__u16 reserved; /* must be zero */
};
The ``reserved`` field must be set to zero; the kernel rejects any
other value with ``-EINVAL``.
Supported Attributes
====================
The following fields in ``xfrm_user_migrate_state`` are always explicit
and are not inherited from the existing SA. Passing zero is not equivalent
to "keep unchanged" — zero is used as-is:
- ``new_daddr`` - new destination address
- ``new_saddr`` - new source address
- ``new_family`` - new address family
- ``new_reqid`` - new reqid (0 = no reqid)
- ``new_sel`` - new selector; used when ``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL`` is
not set (see `Flags`_ below)
- ``flags`` - bitmask of ``XFRM_MIGRATE_STATE_*`` flags (see `Flags`_ below)
The following netlink attributes are also accepted. Omitting an attribute
inherits the value from the existing SA (omit-to-inherit).
.. list-table::
:widths: 30 70
:header-rows: 1
* - Attribute
- Description
* - ``XFRMA_MARK``
- Mark on the migrated SA (``struct xfrm_mark``). Absent inherits
``old_mark``. To use no mark on the new SA, send ``XFRMA_MARK``
with ``{0, 0}``.
* - ``XFRMA_ENCAP``
- UDP encapsulation template; only ``UDP_ENCAP_ESPINUDP`` is supported.
Set ``encap_type=0`` to remove encap.
* - ``XFRMA_OFFLOAD_DEV``
- Hardware offload configuration (``struct xfrm_user_offload``). Absent
copies offload from the existing SA. When
``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD`` is set in ``flags``, the new SA has
no offload; this flag is mutually exclusive with ``XFRMA_OFFLOAD_DEV``
and sending both returns ``-EINVAL``.
* - ``XFRMA_SET_MARK``
- Output mark on the migrated SA; pair with ``XFRMA_SET_MARK_MASK``.
Send 0 to clear.
* - ``XFRMA_NAT_KEEPALIVE_INTERVAL``
- NAT keepalive interval in seconds. Requires encap. Send 0 to clear.
Automatically cleared when encap is removed; setting a non-zero
value without encap returns ``-EINVAL``.
* - ``XFRMA_MTIMER_THRESH``
- Mapping maxage threshold. Only valid on input SAs; setting on an
output SA returns ``-EINVAL``. Requires encap. Send 0 to clear.
Automatically cleared when encap is removed; setting a non-zero
value without encap returns ``-EINVAL``.
The following SA properties are immutable and cannot be changed via
``XFRM_MSG_MIGRATE_STATE``: algorithms (``XFRMA_ALG_*``), replay state,
direction (``XFRMA_SA_DIR``), and security context (``XFRMA_SEC_CTX``).
Flags
=====
The ``flags`` field in ``xfrm_user_migrate_state`` controls optional
migration behaviour. Unknown flag bits are rejected with ``-EINVAL``; the
extended ACK message identifies the unrecognised bits (e.g. ``"Unknown flags:
0x4"``). Userspace can use ``XFRM_MIGRATE_STATE_KNOWN_FLAGS`` (defined in
``<linux/xfrm.h>``) to validate flags before sending; note that this constant
reflects the flags known to the header version userspace was compiled against,
which may differ from what the running kernel accepts.
.. list-table::
:widths: 40 60
:header-rows: 1
* - Flag
- Description
* - ``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD``
- When set, the new SA has no hardware offload even when
``XFRMA_OFFLOAD_DEV`` is absent. Without this flag, omitting
``XFRMA_OFFLOAD_DEV`` copies the existing offload to the new SA.
Mutually exclusive with ``XFRMA_OFFLOAD_DEV``; sending both
returns ``-EINVAL``.
* - ``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL``
- When set, the kernel validates that the existing SA selector is a
single-host entry matching the SA addresses (``prefixlen_s ==
prefixlen_d`` equal to 32 for IPv4 or 128 for IPv6, and addresses
matching ``id.daddr`` and ``props.saddr``). If the check passes,
the new selector is derived from ``new_daddr`` and ``new_saddr``
with the single-host mask for ``new_family``. A mismatch returns
``-EINVAL``. When this flag is not set, ``new_sel`` is used as-is
for the migrated SA.
Migration Steps
===============
Outgoing SA
-----------
To prevent cleartext traffic leaks, install a block policy before
migrating:
#. Install a block policy to drop traffic on the affected selector.
#. Remove the old policy.
#. Call ``XFRM_MSG_MIGRATE_STATE`` for each SA.
#. Reinstall the policies.
#. Remove the block policy.
If AES-GCM is in use, the block policy also prevents IV reuse during
the migration window. For other AEADs this step is not required for
IV safety, but skipping it allows a brief cleartext window.
Incoming SA
-----------
No block policy is needed. ``XFRM_MSG_MIGRATE_STATE`` atomically
transfers the sequence number and replay window from the old SA to
the new SA, so the new SA continues replay protection without a gap.
Call ``XFRM_MSG_MIGRATE_STATE`` for each SA directly.
When accepting incoming traffic, be liberal during the migration
window: packets sent by the remote peer before it completed its own
migration may arrive out of order or slightly late. Dropping them
unnecessarily causes packet loss. A generous replay window reduces
the impact of reordering during migration.
Block Policy and IV Safety
--------------------------
AES-GCM IV uniqueness is critical: reusing a (key, IV) pair allows
an attacker to recover the authentication subkey and forge
authentication tags, breaking both confidentiality and integrity.
This concern applies to outgoing SAs only — the remote peer controls
IV generation on incoming traffic.
``XFRM_MSG_MIGRATE_STATE`` atomically copies the sequence number and
replay window from the old SA to the new SA and deletes the old SA.
The block policy serves two purposes: it prevents cleartext traffic
leaks during the migration window, and for AES-GCM it prevents IV
reuse by ensuring no outgoing packets are sent under the same key.
The atomic copy of the sequence number and replay window complements
this — together they eliminate both risks during migration.
The atomic copy also serves incoming SAs, ensuring replay protection
continues without a gap across the migration.
Feature Detection
=================
Userspace can probe for kernel support by sending a minimal
``XFRM_MSG_MIGRATE_STATE`` message with a non-zero non-existent SPI:
- ``-EINVAL``: kernel predates ``XFRM_MSG_MIGRATE_STATE``; message type
is out of range
- ``-ENOPROTOOPT``: message type is known but ``CONFIG_XFRM_MIGRATE``
is not enabled
- ``-ESRCH``: supported (SPI not found)
Userspace Notification on Success
=================================
On successful migration the kernel multicasts an
``XFRM_MSG_MIGRATE_STATE`` message to the ``XFRMNLGRP_MIGRATE`` group.
The fixed header is ``struct xfrm_user_migrate_state`` copied from the
request, followed by the same set of netlink attributes that are
accepted as input, with the differences noted below.
Differences from the request
-----------------------------
.. list-table::
:widths: 25 75
:header-rows: 1
* - Field / Attribute
- Difference
* - ``new_sel``
- Contains the actual selector of the newly installed SA, not the
``new_sel`` from the request. When
``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL`` is set the kernel derives the
selector from ``new_daddr`` / ``new_saddr``; the caller's
``new_sel`` field is ignored in that case. The notification
always carries the real selector of the new SA.
* - ``XFRMA_SA_DIR``
- Present in the notification (set from the direction of the new
SA) but **not accepted as input** — direction is immutable.
* - ``flags``
- Echoed back as-is. ``XFRM_MIGRATE_STATE_CLEAR_OFFLOAD`` and
``XFRM_MIGRATE_STATE_UPDATE_H2H_SEL`` describe the request that was
made, not a property of the resulting SA.
Attributes in the notification
-------------------------------
.. list-table::
:widths: 30 70
:header-rows: 1
* - Attribute
- Description
* - ``XFRMA_ENCAP``
- UDP encapsulation template, if configured on the new SA.
* - ``XFRMA_OFFLOAD_DEV``
- Hardware offload configuration, if active on the new SA.
* - ``XFRMA_MARK``
- Mark on the new SA, if set.
* - ``XFRMA_SET_MARK``
- Output mark on the new SA, if set.
* - ``XFRMA_SET_MARK_MASK``
- Output mark mask, present together with ``XFRMA_SET_MARK``.
* - ``XFRMA_MTIMER_THRESH``
- Mapping maxage threshold, if non-zero.
* - ``XFRMA_NAT_KEEPALIVE_INTERVAL``
- NAT keepalive interval, if non-zero.
* - ``XFRMA_SA_DIR``
- Direction of the new SA.
Error Handling
==============
If the target SA tuple (new daddr, SPI, proto, new family) is already
occupied, the operation returns ``-EEXIST`` before the migration begins.
The old SA remains intact and the operation is safe to retry after
resolving the conflict.
If the target SA is deleted before the migration completes, the operation
returns ``-ESRCH``. No new SA is installed. Userspace should verify the
current SA state before retrying.
If the multicast notification (``XFRMNLGRP_MIGRATE``) fails to send,
the migration itself has already completed successfully and the new SA
is installed. The operation returns success, 0, with an extack warning,
but listeners will not receive the migration event.
Documentation/networking/xsk-tx-metadata.rst
+16 -14
View File
@@ -14,9 +14,9 @@ General Design
The headroom for the metadata is reserved via ``tx_metadata_len`` and
``XDP_UMEM_TX_METADATA_LEN`` flag in ``struct xdp_umem_reg``. The metadata
length is therefore the same for every socket that shares the same umem.
The metadata layout is a fixed UAPI, refer to ``union xsk_tx_metadata`` in
The metadata layout is a fixed UAPI, refer to ``struct xsk_tx_metadata`` in
``include/uapi/linux/if_xdp.h``. Thus, generally, the ``tx_metadata_len``
field above should contain ``sizeof(union xsk_tx_metadata)``.
field above should contain ``sizeof(struct xsk_tx_metadata)``.
Note that in the original implementation the ``XDP_UMEM_TX_METADATA_LEN``
flag was not required. Applications might attempt to create a umem
@@ -45,15 +45,16 @@ the metadata area is ignored by the kernel as well.
The flags field enables the particular offload:
- ``XDP_TXMD_FLAGS_TIMESTAMP``: requests the device to put transmission
timestamp into ``tx_timestamp`` field of ``union xsk_tx_metadata``.
timestamp into ``completion.tx_timestamp`` field of
``struct xsk_tx_metadata``.
- ``XDP_TXMD_FLAGS_CHECKSUM``: requests the device to calculate L4
checksum. ``csum_start`` specifies byte offset of where the checksumming
should start and ``csum_offset`` specifies byte offset where the
device should store the computed checksum.
checksum. ``request.csum_start`` specifies byte offset of where the
checksumming should start and ``request.csum_offset`` specifies byte offset
where the device should store the computed checksum.
- ``XDP_TXMD_FLAGS_LAUNCH_TIME``: requests the device to schedule the
packet for transmission at a pre-determined time called launch time. The
value of launch time is indicated by ``launch_time`` field of
``union xsk_tx_metadata``.
value of launch time is indicated by ``request.launch_time`` field of
``struct xsk_tx_metadata``.
Besides the flags above, in order to trigger the offloads, the first
packet's ``struct xdp_desc`` descriptor should set ``XDP_TX_METADATA``
@@ -63,9 +64,9 @@ only the first chunk should carry the metadata.
Software TX Checksum
====================
For development and testing purposes its possible to pass
For development and testing purposes it's possible to pass
``XDP_UMEM_TX_SW_CSUM`` flag to ``XDP_UMEM_REG`` UMEM registration call.
In this case, when running in ``XDK_COPY`` mode, the TX checksum
In this case, when running in ``XDP_COPY`` mode, the TX checksum
is calculated on the CPU. Do not enable this option in production because
it will negatively affect performance.
@@ -118,7 +119,7 @@ schedule with a 1-second cycle time, with all Tx Queues open at all times.
The value of the launch time that is programmed in the Advanced Transmit
Context Descriptor is a relative offset to the starting time of the Qbv
transmission window of the queue. The Frst flag of the descriptor can be
transmission window of the queue. The First flag of the descriptor can be
set to schedule the packet for the next Qbv cycle. Therefore, the horizon
of the launch time for i225 and i226 is the ending time of the next cycle
of the Qbv transmission window of the queue. For example, when the Qbv
@@ -129,9 +130,10 @@ running.
Querying Device Capabilities
============================
Every devices exports its offloads capabilities via netlink netdev family.
Refer to ``xsk-flags`` features bitmask in
``Documentation/netlink/specs/netdev.yaml``.
Every device exports its offload capabilities via the Netlink netdev family.
Query the ``xsk-features`` attribute in
``Documentation/netlink/specs/netdev.yaml``. Its bits are defined by the
``xsk-flags`` enum.
- ``tx-timestamp``: device supports ``XDP_TXMD_FLAGS_TIMESTAMP``
- ``tx-checksum``: device supports ``XDP_TXMD_FLAGS_CHECKSUM``
Documentation/translations/zh_CN/networking/netmem.rst
+6 -1
View File
@@ -89,4 +89,9 @@ dma-mapping API 去处理。
使用某个还不存在的 netmem API，你可以自行添加并提交到 netdev@，也可以联系维护
人员或者发送邮件至 almasrymina@google.com 寻求帮助。
2. 驱动程序应通过设置 netdev->netmem_tx = true 来表明自身支持 netmem 功能。
2. 驱动程序应将 `netdev->netmem_tx` 设置为适当的模式：
- `NETMEM_TX_DMA`：适用于执行 DMA 的物理设备。
- `NETMEM_TX_NO_DMA`：适用于不执行 DMA 的虚拟或透传设备，但仍支持
处理 netmem 支持的 skb。
Documentation/userspace-api/netlink/intro.rst
+2 -2
View File
@@ -526,8 +526,8 @@ of the recvmsg() system call, *not* a Netlink header).
Upon truncation the remaining part of the message is discarded.
Netlink expects that the user buffer will be at least 8kB or a page
size of the CPU architecture, whichever is bigger. Particular Netlink
Netlink expects that the user buffer will be at most 8kB or a page
size of the CPU architecture, whichever is smaller. Particular Netlink
families may, however, require a larger buffer. 32kB buffer is recommended
for most efficient handling of dumps (larger buffer fits more dumped
objects and therefore fewer recvmsg() calls are needed).
MAINTAINERS
+27 -7
View File
@@ -809,6 +809,14 @@ S: Maintained
F: Documentation/i2c/busses/i2c-ali1563.rst
F: drivers/i2c/busses/i2c-ali1563.c
ALIBABA ELASTIC ETHERNET ADAPTER DRIVER
M: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
M: Wen Gu <guwen@linux.alibaba.com>
R: Philo Lu <lulie@linux.alibaba.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/alibaba/eea
ALIBABA ELASTIC RDMA DRIVER
M: Cheng Xu <chengyou@linux.alibaba.com>
M: Kai Shen <kaishen@linux.alibaba.com>
@@ -1966,10 +1974,9 @@ F: drivers/hwmon/applesmc.c
APPLETALK NETWORK LAYER
L: netdev@vger.kernel.org
S: Odd fixes
F: include/linux/atalk.h
S: Obsolete
F: include/uapi/linux/atalk.h
F: net/appletalk/
F: include/uapi/linux/if_ltalk.h
APPLIED MICRO (APM) X-GENE DEVICE TREE SUPPORT
M: Khuong Dinh <khuong@os.amperecomputing.com>
@@ -4455,7 +4462,7 @@ W: https://www.open-mesh.org/
Q: https://patchwork.open-mesh.org/project/batman/list/
B: https://www.open-mesh.org/projects/batman-adv/issues
C: ircs://irc.hackint.org/batadv
T: git https://git.open-mesh.org/linux-merge.git
T: git https://git.open-mesh.org/batadv.git
F: Documentation/networking/batman-adv.rst
F: include/uapi/linux/batadv_packet.h
F: include/uapi/linux/batman_adv.h
@@ -15387,7 +15394,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git
F: Documentation/networking/mac80211-injection.rst
F: Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
F: drivers/net/wireless/virtual/mac80211_hwsim.[ch]
F: drivers/net/wireless/virtual/mac80211_hwsim*.[ch]
F: include/net/mac80211.h
F: net/mac80211/
@@ -18554,7 +18561,6 @@ F: include/linux/fddidevice.h
F: include/linux/if_*
F: include/linux/inetdevice.h
F: include/linux/netdev*
F: include/linux/platform_data/wiznet.h
F: include/uapi/linux/cn_proc.h
F: include/uapi/linux/ethtool_netlink*
F: include/uapi/linux/if_*
@@ -18702,6 +18708,7 @@ F: net/
F: samples/pktgen/
F: tools/net/
F: tools/testing/selftests/net/
X: Documentation/networking/batman-adv.rst
X: Documentation/networking/mac80211-injection.rst
X: Documentation/networking/mac80211_hwsim/
X: Documentation/networking/regulatory.rst
@@ -18712,6 +18719,7 @@ X: include/net/iw_handler.h
X: include/net/mac80211.h
X: include/net/wext.h
X: net/9p/
X: net/batman-adv/
X: net/bluetooth/
X: net/can/
X: net/ceph/
@@ -18944,7 +18952,7 @@ F: drivers/net/net_failover.c
F: include/net/net_failover.h
NFC SUBSYSTEM
M: David Heidelberg <david+nfc@ixit.cz>
M: David Heidelberg <david@ixit.cz>
L: oe-linux-nfc@lists.linux.dev
S: Maintained
T: git https://codeberg.org/linux-nfc/linux.git
@@ -19369,6 +19377,17 @@ F: Documentation/devicetree/bindings/clock/*imx*
F: drivers/clk/imx/
F: include/dt-bindings/clock/*imx*
NXP NETC ETHERNET SWITCH DRIVER
M: Wei Fang <wei.fang@nxp.com>
R: Clark Wang <xiaoning.wang@nxp.com>
L: imx@lists.linux.dev
L: netdev@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
F: drivers/net/dsa/netc/
F: include/linux/dsa/tag_netc.h
F: net/dsa/tag_netc.c
NXP NETC TIMER PTP CLOCK DRIVER
M: Wei Fang <wei.fang@nxp.com>
M: Clark Wang <xiaoning.wang@nxp.com>
@@ -20205,6 +20224,7 @@ M: Christian Lamparter <chunkeey@googlemail.com>
L: linux-wireless@vger.kernel.org
S: Maintained
W: https://wireless.wiki.kernel.org/en/users/Drivers/p54
F: Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
F: drivers/net/wireless/intersil/
PACKET SOCKETS
arch/arm/boot/dts/ti/omap/omap2.dtsi
+4
View File
@@ -129,6 +129,8 @@
};
mcspi1: spi@48098000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,omap2-mcspi";
ti,hwmods = "mcspi1";
reg = <0x48098000 0x100>;
@@ -140,6 +142,8 @@
};
mcspi2: spi@4809a000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,omap2-mcspi";
ti,hwmods = "mcspi2";
reg = <0x4809a000 0x100>;
arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi
+12
View File
@@ -109,3 +109,15 @@
};
};
};
&mcspi2 {
status = "okay";
wifi@0 {
reg = <0>;
compatible = "st,stlc4560";
spi-max-frequency = <48000000>;
interrupts-extended = <&gpio3 23 IRQ_TYPE_EDGE_RISING>;
powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>; /* gpio 97 */
};
};
arch/arm/configs/am200epdkit_defconfig
-1
View File
@@ -86,7 +86,6 @@ CONFIG_DEBUG_KERNEL=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_ARC4=m
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_PREEMPT is not set
arch/arm/configs/dove_defconfig
-1
View File
@@ -118,7 +118,6 @@ CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_SHA1=y
arch/arm/configs/ixp4xx_defconfig
-1
View File
@@ -55,7 +55,6 @@ CONFIG_ATM=y
CONFIG_ATM_BR2684=m
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
arch/arm/configs/multi_v5_defconfig
-1
View File
@@ -286,7 +286,6 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_UTF8=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
arch/arm/configs/mv78xx0_defconfig
-1
View File
@@ -111,7 +111,6 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
CONFIG_MAGIC_SYSRQ=y
arch/arm/configs/mvebu_v5_defconfig
-1
View File
@@ -185,7 +185,6 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_UTF8=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
arch/arm/configs/omap1_defconfig
-1
View File
@@ -215,7 +215,6 @@ CONFIG_NLS_UTF8=y
CONFIG_DEBUG_KERNEL=y
CONFIG_SECURITY=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_PCBC=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_LZO=y
CONFIG_FONTS=y
arch/arm/configs/orion5x_defconfig
-1
View File
@@ -134,7 +134,6 @@ CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
# CONFIG_DEBUG_BUGVERBOSE is not set
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
arch/arm/configs/pxa_defconfig
-5
View File
@@ -77,9 +77,6 @@ CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_BT_MRVL=m
@@ -640,14 +637,12 @@ CONFIG_CRYPTO_BENCHMARK=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
arch/arm/configs/spitz_defconfig
-3
View File
@@ -62,9 +62,6 @@ CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_PCCARD=y
arch/arm/configs/wpcm450_defconfig
-1
View File
@@ -181,7 +181,6 @@ CONFIG_FORTIFY_SOURCE=y
CONFIG_CRYPTO_RSA=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_CCM=y
CONFIG_CRYPTO_GCM=y
CONFIG_CRYPTO_CMAC=y
arch/arm/mach-omap2/board-n8x0.c
-18
View File
@@ -20,7 +20,6 @@
#include <linux/spi/spi.h>
#include <linux/usb/musb.h>
#include <linux/mmc/host.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <linux/platform_data/mmc-omap.h>
#include <linux/mfd/menelaus.h>
@@ -106,21 +105,6 @@ static void __init n8x0_usb_init(void) {}
#endif /*CONFIG_USB_MUSB_TUSB6010 */
static struct omap2_mcspi_device_config p54spi_mcspi_config = {
.turbo_mode = 0,
};
static struct spi_board_info n800_spi_board_info[] __initdata = {
{
.modalias = "p54spi",
.bus_num = 2,
.chip_select = 0,
.max_speed_hz = 48000000,
.controller_data = &p54spi_mcspi_config,
},
};
#if defined(CONFIG_MENELAUS) && IS_ENABLED(CONFIG_MMC_OMAP)
/*
@@ -524,7 +508,5 @@ omap_late_initcall(n8x0_late_initcall);
void * __init n8x0_legacy_init(void)
{
board_check_revision();
spi_register_board_info(n800_spi_board_info,
ARRAY_SIZE(n800_spi_board_info));
return &mmc1_data;
}
arch/loongarch/configs/loongson32_defconfig
-3
View File
@@ -383,9 +383,6 @@ CONFIG_BT_HCIUART_AG6XX=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIVHCI=m
CONFIG_BT_MRVL=m
CONFIG_BT_ATH3K=m
arch/loongarch/configs/loongson64_defconfig
-3
View File
@@ -399,9 +399,6 @@ CONFIG_BT_HCIUART_AG6XX=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIVHCI=m
CONFIG_BT_MRVL=m
CONFIG_BT_ATH3K=m
arch/m68k/configs/amiga_defconfig
-3
View File
@@ -236,7 +236,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -521,7 +520,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -533,7 +531,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/apollo_defconfig
-3
View File
@@ -232,7 +232,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -476,7 +475,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -488,7 +486,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/atari_defconfig
-3
View File
@@ -239,7 +239,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -499,7 +498,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -511,7 +509,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/bvme6000_defconfig
-3
View File
@@ -229,7 +229,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -468,7 +467,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -480,7 +478,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/hp300_defconfig
-3
View File
@@ -231,7 +231,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -478,7 +477,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -490,7 +488,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/mac_defconfig
-3
View File
@@ -230,7 +230,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -497,7 +496,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -509,7 +507,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/multi_defconfig
-3
View File
@@ -250,7 +250,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -584,7 +583,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -596,7 +594,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/mvme147_defconfig
-3
View File
@@ -228,7 +228,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -468,7 +467,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -480,7 +478,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/mvme16x_defconfig
-3
View File
@@ -229,7 +229,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -469,7 +468,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -481,7 +479,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/q40_defconfig
-3
View File
@@ -230,7 +230,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -487,7 +486,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -499,7 +497,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/sun3_defconfig
-3
View File
@@ -225,7 +225,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -466,7 +465,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -478,7 +476,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
arch/m68k/configs/sun3x_defconfig
-3
View File
@@ -226,7 +226,6 @@ CONFIG_RDS=m
CONFIG_RDS_TCP=m
CONFIG_L2TP=m
CONFIG_BRIDGE=m
CONFIG_ATALK=m
CONFIG_DNS_RESOLVER=y
CONFIG_BATMAN_ADV=m
# CONFIG_BATMAN_ADV_BATMAN_V is not set
@@ -466,7 +465,6 @@ CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
@@ -478,7 +476,6 @@ CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_HCTR2=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_AEGIS128=m
CONFIG_CRYPTO_CMAC=m
Loaded 100 of 1913 files, more files were not shown because too many files have changed in this diff. Show more