diff options
Diffstat (limited to 'Documentation')
38 files changed, 935 insertions, 766 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-class-net-batman-adv b/Documentation/ABI/obsolete/sysfs-class-net-batman-adv deleted file mode 100644 index 5bdbc8d40256..000000000000 --- a/Documentation/ABI/obsolete/sysfs-class-net-batman-adv +++ /dev/null @@ -1,32 +0,0 @@ -This ABI is deprecated and will be removed after 2021. It is -replaced with the batadv generic netlink family. - -What: /sys/class/net/<iface>/batman-adv/elp_interval -Date: Feb 2014 -Contact: Linus Lüssing <linus.luessing@web.de> -Description: - Defines the interval in milliseconds in which batman - emits probing packets for neighbor sensing (ELP). - -What: /sys/class/net/<iface>/batman-adv/iface_status -Date: May 2010 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - Indicates the status of <iface> as it is seen by batman. - -What: /sys/class/net/<iface>/batman-adv/mesh_iface -Date: May 2010 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - The /sys/class/net/<iface>/batman-adv/mesh_iface file - displays the batman mesh interface this <iface> - currently is associated with. - -What: /sys/class/net/<iface>/batman-adv/throughput_override -Date: Feb 2014 -Contact: Antonio Quartulli <a@unstable.cc> -description: - Defines the throughput value to be used by B.A.T.M.A.N. V - when estimating the link throughput using this interface. - If the value is set to 0 then batman-adv will try to - estimate the throughput by itself. diff --git a/Documentation/ABI/obsolete/sysfs-class-net-mesh b/Documentation/ABI/obsolete/sysfs-class-net-mesh deleted file mode 100644 index 04c1a2932507..000000000000 --- a/Documentation/ABI/obsolete/sysfs-class-net-mesh +++ /dev/null @@ -1,110 +0,0 @@ -This ABI is deprecated and will be removed after 2021. It is -replaced with the batadv generic netlink family. - -What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms -Date: May 2010 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - Indicates whether the batman protocol messages of the - mesh <mesh_iface> shall be aggregated or not. - -What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation -Date: May 2011 -Contact: Antonio Quartulli <a@unstable.cc> -Description: - Indicates whether the data traffic going from a - wireless client to another wireless client will be - silently dropped. <vlan_subdir> is empty when referring - to the untagged lan. - -What: /sys/class/net/<mesh_iface>/mesh/bonding -Date: June 2010 -Contact: Simon Wunderlich <sw@simonwunderlich.de> -Description: - Indicates whether the data traffic going through the - mesh will be sent using multiple interfaces at the - same time (if available). - -What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance -Date: November 2011 -Contact: Simon Wunderlich <sw@simonwunderlich.de> -Description: - Indicates whether the bridge loop avoidance feature - is enabled. This feature detects and avoids loops - between the mesh and devices bridged with the soft - interface <mesh_iface>. - -What: /sys/class/net/<mesh_iface>/mesh/fragmentation -Date: October 2010 -Contact: Andreas Langer <an.langer@gmx.de> -Description: - Indicates whether the data traffic going through the - mesh will be fragmented or silently discarded if the - packet size exceeds the outgoing interface MTU. - -What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth -Date: October 2010 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - Defines the bandwidth which is propagated by this - node if gw_mode was set to 'server'. - -What: /sys/class/net/<mesh_iface>/mesh/gw_mode -Date: October 2010 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - Defines the state of the gateway features. Can be - either 'off', 'client' or 'server'. - -What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class -Date: October 2010 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - Defines the selection criteria this node will use - to choose a gateway if gw_mode was set to 'client'. - -What: /sys/class/net/<mesh_iface>/mesh/hop_penalty -Date: Oct 2010 -Contact: Linus Lüssing <linus.luessing@web.de> -Description: - Defines the penalty which will be applied to an - originator message's tq-field on every hop. - -What: /sys/class/net/<mesh_iface>/mesh/isolation_mark -Date: Nov 2013 -Contact: Antonio Quartulli <a@unstable.cc> -Description: - Defines the isolation mark (and its bitmask) which - is used to classify clients as "isolated" by the - Extended Isolation feature. - -What: /sys/class/net/<mesh_iface>/mesh/multicast_mode -Date: Feb 2014 -Contact: Linus Lüssing <linus.luessing@web.de> -Description: - Indicates whether multicast optimizations are enabled - or disabled. If set to zero then all nodes in the - mesh are going to use classic flooding for any - multicast packet with no optimizations. - -What: /sys/class/net/<mesh_iface>/mesh/network_coding -Date: Nov 2012 -Contact: Martin Hundeboll <martin@hundeboll.net> -Description: - Controls whether Network Coding (using some magic - to send fewer wifi packets but still the same - content) is enabled or not. - -What: /sys/class/net/<mesh_iface>/mesh/orig_interval -Date: May 2010 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - Defines the interval in milliseconds in which batman - sends its protocol messages. - -What: /sys/class/net/<mesh_iface>/mesh/routing_algo -Date: Dec 2011 -Contact: Marek Lindner <mareklindner@neomailbox.ch> -Description: - Defines the routing procotol this mesh instance - uses to find the optimal paths through the mesh. diff --git a/Documentation/ABI/testing/sysfs-kernel-btf b/Documentation/ABI/testing/sysfs-kernel-btf index 2c9744b2cd59..fe96efdc9b6c 100644 --- a/Documentation/ABI/testing/sysfs-kernel-btf +++ b/Documentation/ABI/testing/sysfs-kernel-btf @@ -15,3 +15,11 @@ Description: information with description of all internal kernel types. See Documentation/bpf/btf.rst for detailed description of format itself. + +What: /sys/kernel/btf/<module-name> +Date: Nov 2020 +KernelVersion: 5.11 +Contact: bpf@vger.kernel.org +Description: + Read-only binary attribute exposing kernel module's BTF type + information as an add-on to the kernel's BTF (/sys/kernel/btf/vmlinux). diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 041636de29ab..423116c4e787 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -120,7 +120,6 @@ configure specific aspects of kernel behavior to your liking. unicode vga-softcursor video-output - wimax/index xfs .. only:: subproject and html diff --git a/Documentation/admin-guide/wimax/i2400m.rst b/Documentation/admin-guide/wimax/i2400m.rst deleted file mode 100644 index 194388c0c351..000000000000 --- a/Documentation/admin-guide/wimax/i2400m.rst +++ /dev/null @@ -1,283 +0,0 @@ -.. include:: <isonum.txt> - -==================================================== -Driver for the Intel Wireless Wimax Connection 2400m -==================================================== - -:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com > - - This provides a driver for the Intel Wireless WiMAX Connection 2400m - and a basic Linux kernel WiMAX stack. - -1. Requirements -=============== - - * Linux installation with Linux kernel 2.6.22 or newer (if building - from a separate tree) - * Intel i2400m Echo Peak or Baxter Peak; this includes the Intel - Wireless WiMAX/WiFi Link 5x50 series. - * build tools: - - + Linux kernel development package for the target kernel; to - build against your currently running kernel, you need to have - the kernel development package corresponding to the running - image installed (usually if your kernel is named - linux-VERSION, the development package is called - linux-dev-VERSION or linux-headers-VERSION). - + GNU C Compiler, make - -2. Compilation and installation -=============================== - -2.1. Compilation of the drivers included in the kernel ------------------------------------------------------- - - Configure the kernel; to enable the WiMAX drivers select Drivers > - Networking Drivers > WiMAX device support. Enable all of them as - modules (easier). - - If USB or SDIO are not enabled in the kernel configuration, the options - to build the i2400m USB or SDIO drivers will not show. Enable said - subsystems and go back to the WiMAX menu to enable the drivers. - - Compile and install your kernel as usual. - -2.2. Compilation of the drivers distributed as an standalone module -------------------------------------------------------------------- - - To compile:: - - $ cd source/directory - $ make - - Once built you can load and unload using the provided load.sh script; - load.sh will load the modules, load.sh u will unload them. - - To install in the default kernel directories (and enable auto loading - when the device is plugged):: - - $ make install - $ depmod -a - - If your kernel development files are located in a non standard - directory or if you want to build for a kernel that is not the - currently running one, set KDIR to the right location:: - - $ make KDIR=/path/to/kernel/dev/tree - - For more information, please contact linux-wimax@intel.com. - -3. Installing the firmware --------------------------- - - The firmware can be obtained from http://linuxwimax.org or might have - been supplied with your hardware. - - It has to be installed in the target system:: - - $ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf - - * NOTE: if your firmware came in an .rpm or .deb file, just install - it as normal, with the rpm (rpm -i FIRMWARE.rpm) or dpkg - (dpkg -i FIRMWARE.deb) commands. No further action is needed. - * BUSTYPE will be usb or sdio, depending on the hardware you have. - Each hardware type comes with its own firmware and will not work - with other types. - -4. Design -========= - - This package contains two major parts: a WiMAX kernel stack and a - driver for the Intel i2400m. - - The WiMAX stack is designed to provide for common WiMAX control - services to current and future WiMAX devices from any vendor; please - see README.wimax for details. - - The i2400m kernel driver is broken up in two main parts: the bus - generic driver and the bus-specific drivers. The bus generic driver - forms the drivercore and contain no knowledge of the actual method we - use to connect to the device. The bus specific drivers are just the - glue to connect the bus-generic driver and the device. Currently only - USB and SDIO are supported. See drivers/net/wimax/i2400m/i2400m.h for - more information. - - The bus generic driver is logically broken up in two parts: OS-glue and - hardware-glue. The OS-glue interfaces with Linux. The hardware-glue - interfaces with the device on using an interface provided by the - bus-specific driver. The reason for this breakup is to be able to - easily reuse the hardware-glue to write drivers for other OSes; note - the hardware glue part is written as a native Linux driver; no - abstraction layers are used, so to port to another OS, the Linux kernel - API calls should be replaced with the target OS's. - -5. Usage -======== - - To load the driver, follow the instructions in the install section; - once the driver is loaded, plug in the device (unless it is permanently - plugged in). The driver will enumerate the device, upload the firmware - and output messages in the kernel log (dmesg, /var/log/messages or - /var/log/kern.log) such as:: - - ... - i2400m_usb 5-4:1.0: firmware interface version 8.0.0 - i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready - - At this point the device is ready to work. - - Current versions require the Intel WiMAX Network Service in userspace - to make things work. See the network service's README for instructions - on how to scan, connect and disconnect. - -5.1. Module parameters ----------------------- - - Module parameters can be set at kernel or module load time or by - echoing values:: - - $ echo VALUE > /sys/module/MODULENAME/parameters/PARAMETERNAME - - To make changes permanent, for example, for the i2400m module, you can - also create a file named /etc/modprobe.d/i2400m containing:: - - options i2400m idle_mode_disabled=1 - - To find which parameters are supported by a module, run:: - - $ modinfo path/to/module.ko - - During kernel bootup (if the driver is linked in the kernel), specify - the following to the kernel command line:: - - i2400m.PARAMETER=VALUE - -5.1.1. i2400m: idle_mode_disabled -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - The i2400m module supports a parameter to disable idle mode. This - parameter, once set, will take effect only when the device is - reinitialized by the driver (eg: following a reset or a reconnect). - -5.2. Debug operations: debugfs entries --------------------------------------- - - The driver will register debugfs entries that allow the user to tweak - debug settings. There are three main container directories where - entries are placed, which correspond to the three blocks a i2400m WiMAX - driver has: - - * /sys/kernel/debug/wimax:DEVNAME/ for the generic WiMAX stack - controls - * /sys/kernel/debug/wimax:DEVNAME/i2400m for the i2400m generic - driver controls - * /sys/kernel/debug/wimax:DEVNAME/i2400m-usb (or -sdio) for the - bus-specific i2400m-usb or i2400m-sdio controls). - - Of course, if debugfs is mounted in a directory other than - /sys/kernel/debug, those paths will change. - -5.2.1. Increasing debug output -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - The files named *dl_* indicate knobs for controlling the debug output - of different submodules:: - - # find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\* - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_tx - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_rx - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_notif - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_fw - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_usb - /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx - /sys/kernel/debug/wimax:wmx0/i2400m/dl_rx - /sys/kernel/debug/wimax:wmx0/i2400m/dl_rfkill - /sys/kernel/debug/wimax:wmx0/i2400m/dl_netdev - /sys/kernel/debug/wimax:wmx0/i2400m/dl_fw - /sys/kernel/debug/wimax:wmx0/i2400m/dl_debugfs - /sys/kernel/debug/wimax:wmx0/i2400m/dl_driver - /sys/kernel/debug/wimax:wmx0/i2400m/dl_control - /sys/kernel/debug/wimax:wmx0/wimax_dl_stack - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg - /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table - /sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs - - By reading the file you can obtain the current value of said debug - level; by writing to it, you can set it. - - To increase the debug level of, for example, the i2400m's generic TX - engine, just write:: - - $ echo 3 > /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx - - Increasing numbers yield increasing debug information; for details of - what is printed and the available levels, check the source. The code - uses 0 for disabled and increasing values until 8. - -5.2.2. RX and TX statistics -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - The i2400m/rx_stats and i2400m/tx_stats provide statistics about the - data reception/delivery from the device:: - - $ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats - 45 1 3 34 3104 48 480 - - The numbers reported are: - - * packets/RX-buffer: total, min, max - * RX-buffers: total RX buffers received, accumulated RX buffer size - in bytes, min size received, max size received - - Thus, to find the average buffer size received, divide accumulated - RX-buffer / total RX-buffers. - - To clear the statistics back to 0, write anything to the rx_stats file:: - - $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats - - Likewise for TX. - - Note the packets this debug file refers to are not network packet, but - packets in the sense of the device-specific protocol for communication - to the host. See drivers/net/wimax/i2400m/tx.c. - -5.2.3. Tracing messages received from user space -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - To echo messages received from user space into the trace pipe that the - i2400m driver creates, set the debug file i2400m/trace_msg_from_user to - 1:: - - $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user - -5.2.4. Performing a device reset -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - By writing a 0, a 1 or a 2 to the file - /sys/kernel/debug/wimax:wmx0/reset, the driver performs a warm (without - disconnecting from the bus), cold (disconnecting from the bus) or bus - (bus specific) reset on the device. - -5.2.5. Asking the device to enter power saving mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - By writing any value to the /sys/kernel/debug/wimax:wmx0 file, the - device will attempt to enter power saving mode. - -6. Troubleshooting -================== - -6.1. Driver complains about ``i2400m-fw-usb-1.2.sbcf: request failed`` ----------------------------------------------------------------------- - - If upon connecting the device, the following is output in the kernel - log:: - - i2400m_usb 5-4:1.0: fw i2400m-fw-usb-1.3.sbcf: request failed: -2 - - This means that the driver cannot locate the firmware file named - /lib/firmware/i2400m-fw-usb-1.2.sbcf. Check that the file is present in - the right location. diff --git a/Documentation/admin-guide/wimax/index.rst b/Documentation/admin-guide/wimax/index.rst deleted file mode 100644 index fdf7c1f99ff5..000000000000 --- a/Documentation/admin-guide/wimax/index.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=============== -WiMAX subsystem -=============== - -.. toctree:: - :maxdepth: 2 - - wimax - - i2400m - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/admin-guide/wimax/wimax.rst b/Documentation/admin-guide/wimax/wimax.rst deleted file mode 100644 index 817ee8ba2732..000000000000 --- a/Documentation/admin-guide/wimax/wimax.rst +++ /dev/null @@ -1,89 +0,0 @@ -.. include:: <isonum.txt> - -======================== -Linux kernel WiMAX stack -======================== - -:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com > - - This provides a basic Linux kernel WiMAX stack to provide a common - control API for WiMAX devices, usable from kernel and user space. - -1. Design -========= - - The WiMAX stack is designed to provide for common WiMAX control - services to current and future WiMAX devices from any vendor. - - Because currently there is only one and we don't know what would be the - common services, the APIs it currently provides are very minimal. - However, it is done in such a way that it is easily extensible to - accommodate future requirements. - - The stack works by embedding a struct wimax_dev in your device's - control structures. This provides a set of callbacks that the WiMAX - stack will call in order to implement control operations requested by - the user. As well, the stack provides API functions that the driver - calls to notify about changes of state in the device. - - The stack exports the API calls needed to control the device to user - space using generic netlink as a marshalling mechanism. You can access - them using your own code or use the wrappers provided for your - convenience in libwimax (in the wimax-tools package). - - For detailed information on the stack, please see - include/linux/wimax.h. - -2. Usage -======== - - For usage in a driver (registration, API, etc) please refer to the - instructions in the header file include/linux/wimax.h. - - When a device is registered with the WiMAX stack, a set of debugfs - files will appear in /sys/kernel/debug/wimax:wmxX can tweak for - control. - -2.1. Obtaining debug information: debugfs entries -------------------------------------------------- - - The WiMAX stack is compiled, by default, with debug messages that can - be used to diagnose issues. By default, said messages are disabled. - - The drivers will register debugfs entries that allow the user to tweak - debug settings. - - Each driver, when registering with the stack, will cause a debugfs - directory named wimax:DEVICENAME to be created; optionally, it might - create more subentries below it. - -2.1.1. Increasing debug output ------------------------------- - - The files named *dl_* indicate knobs for controlling the debug output - of different submodules of the WiMAX stack:: - - # find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\* - /sys/kernel/debug/wimax:wmx0/wimax_dl_stack - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg - /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table - /sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs - /sys/kernel/debug/wimax:wmx0/.... # other driver specific files - - NOTE: - Of course, if debugfs is mounted in a directory other than - /sys/kernel/debug, those paths will change. - - By reading the file you can obtain the current value of said debug - level; by writing to it, you can set it. - - To increase the debug level of, for example, the id-table submodule, - just write: - - $ echo 3 > /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table - - Increasing numbers yield increasing debug information; for details of - what is printed and the available levels, check the source. The code - uses 0 for disabled and increasing values until 8. diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml index 13875eab2ed6..0d2df30f19db 100644 --- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -57,6 +57,7 @@ properties: - const: per clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 description: | The oscillator frequency driving the flexcan device, filled in by the boot loader. This property should only be used the used operating system @@ -99,7 +100,7 @@ properties: by default. 0: clock source 0 (oscillator clock) 1: clock source 1 (peripheral clock) - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint8 default: 1 minimum: 0 maximum: 1 @@ -124,7 +125,7 @@ examples: interrupts = <48 0x2>; interrupt-parent = <&mpic>; clock-frequency = <200000000>; - fsl,clk-source = <0>; + fsl,clk-source = /bits/ 8 <0>; }; - | #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml new file mode 100644 index 000000000000..5592f58fa6f0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml @@ -0,0 +1,127 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/hirschmann,hellcreek.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hirschmann Hellcreek TSN Switch Device Tree Bindings + +allOf: + - $ref: dsa.yaml# + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Florian Fainelli <f.fainelli@gmail.com> + - Vivien Didelot <vivien.didelot@gmail.com> + - Kurt Kanzenbach <kurt@linutronix.de> + +description: + The Hellcreek TSN Switch IP is a 802.1Q Ethernet compliant switch. It supports + the Precision Time Protocol, Hardware Timestamping as well the Time Aware + Shaper. + +properties: + compatible: + items: + - const: hirschmann,hellcreek-de1soc-r1 + + reg: + description: + The physical base address and size of TSN and PTP memory base + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: tsn + - const: ptp + + leds: + type: object + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^led@[01]$": + type: object + description: Hellcreek leds + $ref: ../../leds/common.yaml# + + properties: + reg: + items: + - enum: [0, 1] + description: Led number + + label: true + + default-state: true + + required: + - reg + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + - ethernet-ports + - leds + +unevaluatedProperties: false + +examples: + - | + switch0: switch@ff240000 { + compatible = "hirschmann,hellcreek-de1soc-r1"; + reg = <0xff240000 0x1000>, + <0xff250000 0x1000>; + reg-names = "tsn", "ptp"; + dsa,member = <0 0>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "cpu"; + ethernet = <&gmac0>; + }; + + port@2 { + reg = <2>; + label = "lan0"; + phy-handle = <&phy1>; + }; + + port@3 { + reg = <3>; + label = "lan1"; + phy-handle = <&phy2>; + }; + }; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + label = "sync_good"; + default-state = "on"; + }; + + led@1 { + reg = <1>; + label = "is_gm"; + default-state = "off"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/ksz.txt b/Documentation/devicetree/bindings/net/dsa/ksz.txt deleted file mode 100644 index 95e91e84151c..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/ksz.txt +++ /dev/null @@ -1,125 +0,0 @@ -Microchip KSZ Series Ethernet switches -================================== - -Required properties: - -- compatible: For external switch chips, compatible string must be exactly one - of the following: - - "microchip,ksz8765" - - "microchip,ksz8794" - - "microchip,ksz8795" - - "microchip,ksz9477" - - "microchip,ksz9897" - - "microchip,ksz9896" - - "microchip,ksz9567" - - "microchip,ksz8565" - - "microchip,ksz9893" - - "microchip,ksz9563" - - "microchip,ksz8563" - -Optional properties: - -- reset-gpios : Should be a gpio specifier for a reset line -- microchip,synclko-125 : Set if the output SYNCLKO frequency should be set to - 125MHz instead of 25MHz. - -See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional -required and optional properties. - -Examples: - -Ethernet switch connected via SPI to the host, CPU port wired to eth0: - - eth0: ethernet@10001000 { - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - - spi1: spi@f8008000 { - pinctrl-0 = <&pinctrl_spi_ksz>; - cs-gpios = <&pioC 25 0>; - id = <1>; - - ksz9477: ksz9477@0 { - compatible = "microchip,ksz9477"; - reg = <0>; - - spi-max-frequency = <44000000>; - spi-cpha; - spi-cpol; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan1"; - }; - port@1 { - reg = <1>; - label = "lan2"; - }; - port@2 { - reg = <2>; - label = "lan3"; - }; - port@3 { - reg = <3>; - label = "lan4"; - }; - port@4 { - reg = <4>; - label = "lan5"; - }; - port@5 { - reg = <5>; - label = "cpu"; - ethernet = <ð0>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; - ksz8565: ksz8565@0 { - compatible = "microchip,ksz8565"; - reg = <0>; - - spi-max-frequency = <44000000>; - spi-cpha; - spi-cpol; - - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - reg = <0>; - label = "lan1"; - }; - port@1 { - reg = <1>; - label = "lan2"; - }; - port@2 { - reg = <2>; - label = "lan3"; - }; - port@3 { - reg = <3>; - label = "lan4"; - }; - port@6 { - reg = <6>; - label = "cpu"; - ethernet = <ð0>; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml new file mode 100644 index 000000000000..9f7d131bbcef --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml @@ -0,0 +1,148 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/microchip,ksz.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip KSZ Series Ethernet switches + +maintainers: + - Marek Vasut <marex@denx.de> + - Woojung Huh <Woojung.Huh@microchip.com> + +allOf: + - $ref: dsa.yaml# + +properties: + # See Documentation/devicetree/bindings/net/dsa/dsa.yaml for a list of additional + # required and optional properties. + compatible: + enum: + - microchip,ksz8765 + - microchip,ksz8794 + - microchip,ksz8795 + - microchip,ksz9477 + - microchip,ksz9897 + - microchip,ksz9896 + - microchip,ksz9567 + - microchip,ksz8565 + - microchip,ksz9893 + - microchip,ksz9563 + - microchip,ksz8563 + + reset-gpios: + description: + Should be a gpio specifier for a reset line. + maxItems: 1 + + microchip,synclko-125: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if the output SYNCLKO frequency should be set to 125MHz instead of 25MHz. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + // Ethernet switch connected via SPI to the host, CPU port wired to eth0: + eth0 { + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + pinctrl-0 = <&pinctrl_spi_ksz>; + cs-gpios = <&pioC 25 0>; + id = <1>; + + ksz9477: switch@0 { + compatible = "microchip,ksz9477"; + reg = <0>; + reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>; + + spi-max-frequency = <44000000>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + label = "lan1"; + }; + port@1 { + reg = <1>; + label = "lan2"; + }; + port@2 { + reg = <2>; + label = "lan3"; + }; + port@3 { + reg = <3>; + label = "lan4"; + }; + port@4 { + reg = <4>; + label = "lan5"; + }; + port@5 { + reg = <5>; + label = "cpu"; + ethernet = <ð0>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + + ksz8565: switch@1 { + compatible = "microchip,ksz8565"; + reg = <1>; + + spi-max-frequency = <44000000>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + label = "lan1"; + }; + port@1 { + reg = <1>; + label = "lan2"; + }; + port@2 { + reg = <2>; + label = "lan3"; + }; + port@3 { + reg = <3>; + label = "lan4"; + }; + port@6 { + reg = <6>; + label = "cpu"; + ethernet = <ð0>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/ftgmac100.txt b/Documentation/devicetree/bindings/net/ftgmac100.txt index f878c1103463..29234021f601 100644 --- a/Documentation/devicetree/bindings/net/ftgmac100.txt +++ b/Documentation/devicetree/bindings/net/ftgmac100.txt @@ -15,6 +15,7 @@ Required properties: - interrupts: Should contain ethernet controller interrupt Optional properties: +- phy-handle: See ethernet.txt file in the same directory. - phy-mode: See ethernet.txt file in the same directory. If the property is absent, "rgmii" is assumed. Supported values are "rgmii*" and "rmii" for aspeed parts. Other (unknown) parts will accept any value. @@ -32,6 +33,9 @@ Optional properties: - "MACCLK": The MAC IP clock - "RCLK": Clock gate for the RMII RCLK +Optional subnodes: +- mdio: See mdio.txt file in the same directory. + Example: mac0: ethernet@1e660000 { @@ -40,3 +44,24 @@ Example: interrupts = <2>; use-ncsi; }; + +Example with phy-handle: + + mac1: ethernet@1e680000 { + compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; + reg = <0x1e680000 0x180>; + interrupts = <2>; + + phy-handle = <&phy>; + phy-mode = "rgmii"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy: ethernet-phy@1 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 0b61a90f1592..e08c5a9d53da 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -16,6 +16,8 @@ Required properties: Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC. Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC. Use "sifive,fu540-c000-gem" for SiFive FU540-C000 SoC. + Use "microchip,sama7g5-emac" for Microchip SAMA7G5 ethernet interface. + Use "microchip,sama7g5-gem" for Microchip SAMA7G5 gigabit ethernet interface. Or the generic form: "cdns,emac". - reg: Address and length of the register set for the device For "sifive,fu540-c000-gem", second range is required to specify the diff --git a/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt b/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt index 9e4dc510a40a..285a37c2f189 100644 --- a/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt +++ b/Documentation/devicetree/bindings/net/nfc/nxp-nci.txt @@ -6,11 +6,11 @@ Required properties: - reg: address on the bus - interrupts: GPIO interrupt to which the chip is connected - enable-gpios: Output GPIO pin used for enabling/disabling the chip -- firmware-gpios: Output GPIO pin used to enter firmware download mode Optional SoC Specific Properties: - pinctrl-names: Contains only one value - "default". - pintctrl-0: Specifies the pin control groups used for this controller. +- firmware-gpios: Output GPIO pin used to enter firmware download mode Example (for ARM-based BeagleBone with NPC100 NFC controller on I2C2): diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index cb0b8a560282..477066e2b821 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -12,7 +12,9 @@ maintainers: properties: compatible: - const: samsung,s3fwrn5-i2c + enum: + - samsung,s3fwrn5-i2c + - samsung,s3fwrn82 en-gpios: maxItems: 1 @@ -47,10 +49,19 @@ additionalProperties: false required: - compatible - en-gpios - - interrupts - - reg - wake-gpios +allOf: + - if: + properties: + compatible: + contains: + const: samsung,s3fwrn5-i2c + then: + required: + - interrupts + - reg + examples: - | #include <dt-bindings/gpio/gpio.h> @@ -65,9 +76,23 @@ examples: reg = <0x27>; interrupt-parent = <&gpa1>; - interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <3 IRQ_TYPE_EDGE_RISING>; en-gpios = <&gpf1 4 GPIO_ACTIVE_HIGH>; wake-gpios = <&gpj0 2 GPIO_ACTIVE_HIGH>; }; }; + # UART example on Raspberry Pi + - | + uart0 { + status = "okay"; + + nfc { + compatible = "samsung,s3fwrn82"; + + en-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>; + wake-gpios = <&gpio 16 GPIO_ACTIVE_HIGH>; + + status = "okay"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index 4b365c9d9378..6af999191559 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -144,6 +144,12 @@ properties: * reg * reg-names + qcom,ath11k-calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: + string to uniquely identify variant of the calibration data in the + board-2.bin for designs with colliding bus and device specific ids + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 772b148795f4..44f008de77fa 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -443,6 +443,8 @@ patternProperties: description: HiDeep Inc. "^himax,.*": description: Himax Technologies, Inc. + "^hirschmann,.*": + description: Hirschmann Automation and Control GmbH "^hisilicon,.*": description: Hisilicon Limited. "^hit,.*": diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst new file mode 100644 index 000000000000..2312506b0674 --- /dev/null +++ b/Documentation/driver-api/auxiliary_bus.rst @@ -0,0 +1,234 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= +Auxiliary Bus +============= + +In some subsystems, the functionality of the core device (PCI/ACPI/other) is +too complex for a single device to be managed by a monolithic driver +(e.g. Sound Open Firmware), multiple devices might implement a common +intersection of functionality (e.g. NICs + RDMA), or a driver may want to +export an interface for another subsystem to drive (e.g. SIOV Physical Function +export Virtual Function management). A split of the functinoality into child- +devices representing sub-domains of functionality makes it possible to +compartmentalize, layer, and distribute domain-specific concerns via a Linux +device-driver model. + +An example for this kind of requirement is the audio subsystem where a single +IP is handling multiple entities such as HDMI, Soundwire, local devices such as +mics/speakers etc. The split for the core's functionality can be arbitrary or +be defined by the DSP firmware topology and include hooks for test/debug. This +allows for the audio core device to be minimal and focused on hardware-specific +control and communication. + +Each auxiliary_device represents a part of its parent functionality. The +generic behavior can be extended and specialized as needed by encapsulating an +auxiliary_device within other domain-specific structures and the use of .ops +callbacks. Devices on the auxiliary bus do not share any structures and the use +of a communication channel with the parent is domain-specific. + +Note that ops are intended as a way to augment instance behavior within a class +of auxiliary devices, it is not the mechanism for exporting common +infrastructure from the parent. Consider EXPORT_SYMBOL_NS() to convey +infrastructure from the parent module to the auxiliary module(s). + + +When Should the Auxiliary Bus Be Used +===================================== + +The auxiliary bus is to be used when a driver and one or more kernel modules, +who share a common header file with the driver, need a mechanism to connect and +provide access to a shared object allocated by the auxiliary_device's +registering driver. The registering driver for the auxiliary_device(s) and the +kernel module(s) registering auxiliary_drivers can be from the same subsystem, +or from multiple subsystems. + +The emphasis here is on a common generic interface that keeps subsystem +customization out of the bus infrastructure. + +One example is a PCI network device that is RDMA-capable and exports a child +device to be driven by an auxiliary_driver in the RDMA subsystem. The PCI +driver allocates and registers an auxiliary_device for each physical +function on the NIC. The RDMA driver registers an auxiliary_driver that claims +each of these auxiliary_devices. This conveys data/ops published by the parent +PCI device/driver to the RDMA auxiliary_driver. + +Another use case is for the PCI device to be split out into multiple sub +functions. For each sub function an auxiliary_device is created. A PCI sub +function driver binds to such devices that creates its own one or more class +devices. A PCI sub function auxiliary device is likely to be contained in a +struct with additional attributes such as user defined sub function number and +optional attributes such as resources and a link to the parent device. These +attributes could be used by systemd/udev; and hence should be initialized +before a driver binds to an auxiliary_device. + +A key requirement for utilizing the auxiliary bus is that there is no +dependency on a physical bus, device, register accesses or regmap support. +These individual devices split from the core cannot live on the platform bus as +they are not physical devices that are controlled by DT/ACPI. The same +argument applies for not using MFD in this scenario as MFD relies on individual +function devices being physical devices. + +Auxiliary Device +================ + +An auxiliary_device represents a part of its parent device's functionality. It +is given a name that, combined with the registering drivers KBUILD_MODNAME, +creates a match_name that is used for driver binding, and an id that combined +with the match_name provide a unique name to register with the bus subsystem. + +Registering an auxiliary_device is a two-step process. First call +auxiliary_device_init(), which checks several aspects of the auxiliary_device +struct and performs a device_initialize(). After this step completes, any +error state must have a call to auxiliary_device_uninit() in its resolution path. +The second step in registering an auxiliary_device is to perform a call to +auxiliary_device_add(), which sets the name of the device and add the device to +the bus. + +Unregistering an auxiliary_device is also a two-step process to mirror the +register process. First call auxiliary_device_delete(), then call +auxiliary_device_uninit(). + +.. code-block:: c + + struct auxiliary_device { + struct device dev; + const char *name; + u32 id; + }; + +If two auxiliary_devices both with a match_name "mod.foo" are registered onto +the bus, they must have unique id values (e.g. "x" and "y") so that the +registered devices names are "mod.foo.x" and "mod.foo.y". If match_name + id +are not unique, then the device_add fails and generates an error message. + +The auxiliary_device.dev.type.release or auxiliary_device.dev.release must be +populated with a non-NULL pointer to successfully register the auxiliary_device. + +The auxiliary_device.dev.parent must also be populated. + +Auxiliary Device Memory Model and Lifespan +------------------------------------------ + +The registering driver is the entity that allocates memory for the +auxiliary_device and register it on the auxiliary bus. It is important to note +that, as opposed to the platform bus, the registering driver is wholly +responsible for the management for the memory used for the driver object. + +A parent object, defined in the shared header file, contains the +auxiliary_device. It also contains a pointer to the shared object(s), which +also is defined in the shared header. Both the parent object and the shared +object(s) are allocated by the registering driver. This layout allows the +auxiliary_driver's registering module to perform a container_of() call to go +from the pointer to the auxiliary_device, that is passed during the call to the +auxiliary_driver's probe function, up to the parent object, and then have +access to the shared object(s). + +The memory for the auxiliary_device is freed only in its release() callback +flow as defined by its registering driver. + +The memory for the shared object(s) must have a lifespan equal to, or greater +than, the lifespan of the memory for the auxiliary_device. The auxiliary_driver +should only consider that this shared object is valid as long as the +auxiliary_device is still registered on the auxiliary bus. It is up to the +registering driver to manage (e.g. free or keep available) the memory for the +shared object beyond the life of the auxiliary_device. + +The registering driver must unregister all auxiliary devices before its own +driver.remove() is completed. + +Auxiliary Drivers +================= + +Auxiliary drivers follow the standard driver model convention, where +discovery/enumeration is handled by the core, and drivers +provide probe() and remove() methods. They support power management +and shutdown notifications using the standard conventions. + +.. code-block:: c + + struct auxiliary_driver { + int (*probe)(struct auxiliary_device *, + const struct auxiliary_device_id *id); + void (*remove)(struct auxiliary_device *); + void (*shutdown)(struct auxiliary_device *); + int (*suspend)(struct auxiliary_device *, pm_message_t); + int (*resume)(struct auxiliary_device *); + struct device_driver driver; + const struct auxiliary_device_id *id_table; + }; + +Auxiliary drivers register themselves with the bus by calling +auxiliary_driver_register(). The id_table contains the match_names of auxiliary +devices that a driver can bind with. + +Example Usage +============= + +Auxiliary devices are created and registered by a subsystem-level core device +that needs to break up its functionality into smaller fragments. One way to +extend the scope of an auxiliary_device is to encapsulate it within a domain- +pecific structure defined by the parent device. This structure contains the +auxiliary_device and any associated shared data/callbacks needed to establish +the connection with the parent. + +An example is: + +.. code-block:: c + + struct foo { + struct auxiliary_device auxdev; + void (*connect)(struct auxiliary_device *auxdev); + void (*disconnect)(struct auxiliary_device *auxdev); + void *data; + }; + +The parent device then registers the auxiliary_device by calling +auxiliary_device_init(), and then auxiliary_device_add(), with the pointer to +the auxdev member of the above structure. The parent provides a name for the +auxiliary_device that, combined with the parent's KBUILD_MODNAME, creates a +match_name that is be used for matching and binding with a driver. + +Whenever an auxiliary_driver is registered, based on the match_name, the +auxiliary_driver's probe() is invoked for the matching devices. The +auxiliary_driver can also be encapsulated inside custom drivers that make the +core device's functionality extensible by adding additional domain-specific ops +as follows: + +.. code-block:: c + + struct my_ops { + void (*send)(struct auxiliary_device *auxdev); + void (*receive)(struct auxiliary_device *auxdev); + }; + + + struct my_driver { + struct auxiliary_driver auxiliary_drv; + const struct my_ops ops; + }; + +An example of this type of usage is: + +.. code-block:: c + + const struct auxiliary_device_id my_auxiliary_id_table[] = { + { .name = "foo_mod.foo_dev" }, + { }, + }; + + const struct my_ops my_custom_ops = { + .send = my_tx, + .receive = my_rx, + }; + + const struct my_driver my_drv = { + .auxiliary_drv = { + .name = "myauxiliarydrv", + .id_table = my_auxiliary_id_table, + .probe = my_probe, + .remove = my_remove, + .shutdown = my_shutdown, + }, + .ops = my_custom_ops, + }; diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 08c32952fce3..2456d0a97ed8 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -73,6 +73,7 @@ available subsections can be seen below. thermal/index fpga/index acpi/index + auxiliary_bus backlight/lp855x-driver.rst connector console diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst index ff05cbd05e0d..f8dae662e454 100644 --- a/Documentation/networking/can.rst +++ b/Documentation/networking/can.rst @@ -228,20 +228,36 @@ send(2), sendto(2), sendmsg(2) and the recv* counterpart operations on the socket as usual. There are also CAN specific socket options described below. -The basic CAN frame structure and the sockaddr structure are defined -in include/linux/can.h: +The Classical CAN frame structure (aka CAN 2.0B), the CAN FD frame structure +and the sockaddr structure are defined in include/linux/can.h: .. code-block:: C struct can_frame { canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ - __u8 can_dlc; /* frame payload length in byte (0 .. 8) */ + union { + /* CAN frame payload length in byte (0 .. CAN_MAX_DLEN) + * was previously named can_dlc so we need to carry that + * name for legacy support + */ + __u8 len; + __u8 can_dlc; /* deprecated */ + }; __u8 __pad; /* padding */ __u8 __res0; /* reserved / padding */ - __u8 __res1; /* reserved / padding */ + __u8 len8_dlc; /* optional DLC for 8 byte payload length (9 .. 15) */ __u8 data[8] __attribute__((aligned(8))); }; +Remark: The len element contains the payload length in bytes and should be +used instead of can_dlc. The deprecated can_dlc was misleadingly named as +it always contained the plain payload length in bytes and not the so called +'data length code' (DLC). + +To pass the raw DLC from/to a Classical CAN network device the len8_dlc +element can contain values 9 .. 15 when the len element is 8 (the real +payload length for all DLC values greater or equal to 8). + The alignment of the (linear) payload data[] to a 64bit boundary allows the user to define their own structs and unions to easily access the CAN payload. There is no given byteorder on the CAN bus by @@ -260,6 +276,23 @@ PF_PACKET socket, that also binds to a specific interface: /* transport protocol class address info (e.g. ISOTP) */ struct { canid_t rx_id, tx_id; } tp; + /* J1939 address information */ + struct { + /* 8 byte name when using dynamic addressing */ + __u64 name; + + /* pgn: + * 8 bit: PS in PDU2 case, else 0 + * 8 bit: PF + * 1 bit: DP + * 1 bit: reserved + */ + __u32 pgn; + + /* 1 byte address */ + __u8 addr; + } j1939; + /* reserved for future CAN protocols address information */ } can_addr; }; @@ -371,7 +404,7 @@ kernel interfaces (ABI) which heavily rely on the CAN frame with fixed eight bytes of payload (struct can_frame) like the CAN_RAW socket. Therefore e.g. the CAN_RAW socket supports a new socket option CAN_RAW_FD_FRAMES that switches the socket into a mode that allows the handling of CAN FD frames -and (legacy) CAN frames simultaneously (see :ref:`socketcan-rawfd`). +and Classical CAN frames simultaneously (see :ref:`socketcan-rawfd`). The struct canfd_frame is defined in include/linux/can.h: @@ -397,7 +430,7 @@ code (DLC) of the struct can_frame was used as a length information as the length and the DLC has a 1:1 mapping in the range of 0 .. 8. To preserve the easy handling of the length information the canfd_frame.len element contains a plain length value from 0 .. 64. So both canfd_frame.len and -can_frame.can_dlc are equal and contain a length information and no DLC. +can_frame.len are equal and contain a length information and no DLC. For details about the distinction of CAN and CAN FD capable devices and the mapping to the bus-relevant data length code (DLC), see :ref:`socketcan-can-fd-driver`. @@ -407,7 +440,7 @@ definitions are specified for CAN specific MTUs in include/linux/can.h: .. code-block:: C - #define CAN_MTU (sizeof(struct can_frame)) == 16 => 'legacy' CAN frame + #define CAN_MTU (sizeof(struct can_frame)) == 16 => Classical CAN frame #define CANFD_MTU (sizeof(struct canfd_frame)) == 72 => CAN FD frame @@ -609,7 +642,7 @@ Example: printf("got CAN FD frame with length %d\n", cfd.len); /* cfd.flags contains valid data */ } else if (nbytes == CAN_MTU) { - printf("got legacy CAN frame with length %d\n", cfd.len); + printf("got Classical CAN frame with length %d\n", cfd.len); /* cfd.flags is undefined */ } else { fprintf(stderr, "read: invalid CAN(FD) frame\n"); @@ -623,7 +656,7 @@ Example: printf("%02X ", cfd.data[i]); When reading with size CANFD_MTU only returns CAN_MTU bytes that have -been received from the socket a legacy CAN frame has been read into the +been received from the socket a Classical CAN frame has been read into the provided CAN FD structure. Note that the canfd_frame.flags data field is not specified in the struct can_frame and therefore it is only valid in CANFD_MTU sized CAN FD frames. @@ -633,7 +666,7 @@ Implementation hint for new CAN applications: To build a CAN FD aware application use struct canfd_frame as basic CAN data structure for CAN_RAW based applications. When the application is executed on an older Linux kernel and switching the CAN_RAW_FD_FRAMES -socket option returns an error: No problem. You'll get legacy CAN frames +socket option returns an error: No problem. You'll get Classical CAN frames or CAN FD frames and can process them the same way. When sending to CAN devices make sure that the device is capable to handle @@ -842,6 +875,8 @@ TX_RESET_MULTI_IDX: RX_RTR_FRAME: Send reply for RTR-request (placed in op->frames[0]). +CAN_FD_FRAME: + The CAN frames following the bcm_msg_head are struct canfd_frame's Broadcast Manager Transmission Timers ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1026,7 +1061,7 @@ Additional procfs files in /proc/net/can:: stats - SocketCAN core statistics (rx/tx frames, match ratios, ...) reset_stats - manual statistic reset - version - prints the SocketCAN core version and the ABI version + version - prints SocketCAN core and ABI version (removed in Linux 5.10) Writing Own CAN Protocol Modules @@ -1070,7 +1105,7 @@ General Settings dev->type = ARPHRD_CAN; /* the netdevice hardware type */ dev->flags = IFF_NOARP; /* CAN has no arp */ - dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */ + dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> Classical CAN interface */ or alternative, when the controller supports CAN with flexible data rate: dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */ @@ -1184,6 +1219,7 @@ Setting CAN device properties:: [ fd { on | off } ] [ fd-non-iso { on | off } ] [ presume-ack { on | off } ] + [ cc-len8-dlc { on | off } ] [ restart-ms TIME-MS ] [ restart ] @@ -1326,22 +1362,22 @@ arbitration phase and the payload phase of the CAN FD frame. Therefore a second bit timing has to be specified in order to enable the CAN FD bitrate. Additionally CAN FD capable CAN controllers support up to 64 bytes of -payload. The representation of this length in can_frame.can_dlc and +payload. The representation of this length in can_frame.len and canfd_frame.len for userspace applications and inside the Linux network layer is a plain value from 0 .. 64 instead of the CAN 'data length code'. -The data length code was a 1:1 mapping to the payload length in the legacy +The data length code was a 1:1 mapping to the payload length in the Classical CAN frames anyway. The payload length to the bus-relevant DLC mapping is only performed inside the CAN drivers, preferably with the helper -functions can_dlc2len() and can_len2dlc(). +functions can_fd_dlc2len() and can_fd_len2dlc(). The CAN netdevice driver capabilities can be distinguished by the network devices maximum transfer unit (MTU):: - MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => 'legacy' CAN device + MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => Classical CAN device MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall. -N.B. CAN FD capable devices can also handle and send legacy CAN frames. +N.B. CAN FD capable devices can also handle and send Classical CAN frames. When configuring CAN FD capable CAN controllers an additional 'data' bitrate has to be set. This bitrate for the data phase of the CAN FD frame has to be diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index 88f508338c5f..d3fcf536d14e 100644 --- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst @@ -12,6 +12,7 @@ Contents - `Overview`_ - `Drivers`_ - `Basic packet flow`_ +- `Devlink health reporters`_ Overview ======== @@ -157,3 +158,52 @@ Egress 3. The SQ descriptor ring is maintained in buffers allocated from SQ mapped pool of NPA block LF. 4. NIX block transmits the pkt on the designated channel. 5. NPC MCAM entries can be installed to divert pkt onto a different channel. + +Devlink health reporters +======================== + +NPA Reporters +------------- +The NPA reporters are responsible for reporting and recovering the following group of errors +1. GENERAL events + - Error due to operation of unmapped PF. + - Error due to disabled alloc/free for other HW blocks (NIX, SSO, TIM, DPI and AURA). +2. ERROR events + - Fault due to NPA_AQ_INST_S read or NPA_AQ_RES_S write. + - AQ Doorbell Error. +3. RAS events + - RAS Error Reporting for NPA_AQ_INST_S/NPA_AQ_RES_S. +4. RVU events + - Error due to unmapped slot. + +Sample Output +------------- +~# devlink health +pci/0002:01:00.0: + reporter hw_npa_intr + state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_gen + state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_err + state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_ras + state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true + +Each reporter dumps the + - Error Type + - Error Register value + - Reason in words + +For eg: +~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen + NPA_AF_GENERAL: + NPA General Interrupt Reg : 1 + NIX0: free disabled RX +~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr + NPA_AF_RVU: + NPA RVU Interrupt Reg : 1 + Unmap Slot Error +~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err + NPA_AF_ERR: + NPA Error Interrupt Reg : 4096 + AQ Doorbell Error diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst index ef719ceac299..d875f3e1e9cf 100644 --- a/Documentation/networking/devlink/devlink-trap.rst +++ b/Documentation/networking/devlink/devlink-trap.rst @@ -476,6 +476,10 @@ be added to the following table: * - ``esp_parsing`` - ``drop`` - Traps packets dropped due to an error in the ESP header parsing + * - ``blackhole_nexthop`` + - ``drop`` + - Traps packets that the device decided to drop in case they hit a + blackhole nexthop Driver-specific Packet Traps ============================ diff --git a/Documentation/networking/devlink/netdevsim.rst b/Documentation/networking/devlink/netdevsim.rst index 2a266b7e7b38..02c2d20dc673 100644 --- a/Documentation/networking/devlink/netdevsim.rst +++ b/Documentation/networking/devlink/netdevsim.rst @@ -46,7 +46,7 @@ Resources ========= The ``netdevsim`` driver exposes resources to control the number of FIB -entries and FIB rule entries that the driver will allow. +entries, FIB rule entries and nexthops that the driver will allow. .. code:: shell @@ -54,6 +54,7 @@ entries and FIB rule entries that the driver will allow. $ devlink resource set netdevsim/netdevsim0 path /IPv4/fib-rules size 16 $ devlink resource set netdevsim/netdevsim0 path /IPv6/fib size 64 $ devlink resource set netdevsim/netdevsim0 path /IPv6/fib-rules size 16 + $ devlink resource set netdevsim/netdevsim0 path /nexthops size 16 $ devlink dev reload netdevsim/netdevsim0 Driver-specific Traps diff --git a/Documentation/networking/framerelay.rst b/Documentation/networking/framerelay.rst deleted file mode 100644 index 6d904399ec6d..000000000000 --- a/Documentation/networking/framerelay.rst +++ /dev/null @@ -1,44 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -================ -Frame Relay (FR) -================ - -Frame Relay (FR) support for linux is built into a two tiered system of device -drivers. The upper layer implements RFC1490 FR specification, and uses the -Data Link Connection Identifier (DLCI) as its hardware address. Usually these -are assigned by your network supplier, they give you the number/numbers of -the Virtual Connections (VC) assigned to you. - -Each DLCI is a point-to-point link between your machine and a remote one. -As such, a separate device is needed to accommodate the routing. Within the -net-tools archives is 'dlcicfg'. This program will communicate with the -base "DLCI" device, and create new net devices named 'dlci00', 'dlci01'... -The configuration script will ask you how many DLCIs you need, as well as -how many DLCIs you want to assign to each Frame Relay Access Device (FRAD). - -The DLCI uses a number of function calls to communicate with the FRAD, all -of which are stored in the FRAD's private data area. assoc/deassoc, -activate/deactivate and dlci_config. The DLCI supplies a receive function -to the FRAD to accept incoming packets. - -With this initial offering, only 1 FRAD driver is available. With many thanks -to Sangoma Technologies, David Mandelstam & Gene Kozin, the S502A, S502E & -S508 are supported. This driver is currently set up for only FR, but as -Sangoma makes more firmware modules available, it can be updated to provide -them as well. - -Configuration of the FRAD makes use of another net-tools program, 'fradcfg'. -This program makes use of a configuration file (which dlcicfg can also read) -to specify the types of boards to be configured as FRADs, as well as perform -any board specific configuration. The Sangoma module of fradcfg loads the -FR firmware into the card, sets the irq/port/memory information, and provides -an initial configuration. - -Additional FRAD device drivers can be added as hardware is available. - -At this time, the dlcicfg and fradcfg programs have not been incorporated into -the net-tools distribution. They can be found at ftp.invlogic.com, in -/pub/linux. Note that with OS/2 FTPD, you end up in /pub by default, so just -use 'cd linux'. v0.10 is for use on pre-2.0.3 and earlier, v0.15 is for -pre-2.0.4 and later. diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 63ef386afd0a..b8a29997d433 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -52,7 +52,6 @@ Contents: eql fib_trie filter - framerelay generic-hdlc generic_netlink gen_stats @@ -70,6 +69,7 @@ Contents: lapb-module mac80211-injection mpls-sysctl + mptcp-sysctl multiqueue netconsole netdev-features @@ -101,6 +101,7 @@ Contents: tcp-thin team timestamping + tipc tproxy tuntap udplite diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 25e6673a085a..dd2b12a32b73 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -1554,6 +1554,9 @@ igmpv3_unsolicited_report_interval - INTEGER Default: 1000 (1 seconds) +ignore_routes_with_linkdown - BOOLEAN + Ignore routes whose link is down when performing a FIB lookup. + promote_secondaries - BOOLEAN When a primary IP address is removed from this interface promote a corresponding secondary IP address instead of @@ -2642,6 +2645,37 @@ addr_scope_policy - INTEGER Default: 1 +udp_port - INTEGER + The listening port for the local UDP tunneling sock. Normally it's + using the IANA-assigned UDP port number 9899 (sctp-tunneling). + + This UDP sock is used for processing the incoming UDP-encapsulated + SCTP packets (from RFC6951), and shared by all applications in the + same net namespace. This UDP sock will be closed when the value is + set to 0. + + The value will also be used to set the src port of the UDP header + for the outgoing UDP-encapsulated SCTP packets. For the dest port, + please refer to 'encap_port' below. + + Default: 0 + +encap_port - INTEGER + The default remote UDP encapsulation port. + + This value is used to set the dest port of the UDP header for the + outgoing UDP-encapsulated SCTP packets by default. Users can also + change the value for each sock/asoc/transport by using setsockopt. + For further information, please refer to RFC6951. + + Note that when connecting to a remote server, the client should set + this to the port that the UDP tunneling sock on the peer server is + listening to and the local UDP tunneling sock on the client also + must be started. On the server, it would get the encap_port from + the incoming packet's source port. + + Default: 0 + ``/proc/sys/net/core/*`` ======================== diff --git a/Documentation/networking/j1939.rst b/Documentation/networking/j1939.rst index 0a4b73b03b99..b705d2801e9c 100644 --- a/Documentation/networking/j1939.rst +++ b/Documentation/networking/j1939.rst @@ -69,18 +69,56 @@ J1939 concepts PGN --- +The J1939 protocol uses the 29-bit CAN identifier with the following structure: + + ============ ============== ==================== + 29 bit CAN-ID + -------------------------------------------------- + Bit positions within the CAN-ID + -------------------------------------------------- + 28 ... 26 25 ... 8 7 ... 0 + ============ ============== ==================== + Priority PGN SA (Source Address) + ============ ============== ==================== + The PGN (Parameter Group Number) is a number to identify a packet. The PGN is composed as follows: -1 bit : Reserved Bit -1 bit : Data Page -8 bits : PF (PDU Format) -8 bits : PS (PDU Specific) + + ============ ============== ================= ================= + PGN + ------------------------------------------------------------------ + Bit positions within the CAN-ID + ------------------------------------------------------------------ + 25 24 23 ... 16 15 ... 8 + ============ ============== ================= ================= + R (Reserved) DP (Data Page) PF (PDU Format) PS (PDU Specific) + ============ ============== ================= ================= In J1939-21 distinction is made between PDU1 format (where PF < 240) and PDU2 format (where PF >= 240). Furthermore, when using the PDU2 format, the PS-field contains a so-called Group Extension, which is part of the PGN. When using PDU2 format, the Group Extension is set in the PS-field. + ============== ======================== + PDU1 Format (specific) (peer to peer) + ---------------------------------------- + Bit positions within the CAN-ID + ---------------------------------------- + 23 ... 16 15 ... 8 + ============== ======================== + 00h ... EFh DA (Destination address) + ============== ======================== + + ============== ======================== + PDU2 Format (global) (broadcast) + ---------------------------------------- + Bit positions within the CAN-ID + ---------------------------------------- + 23 ... 16 15 ... 8 + ============== ======================== + F0h ... FFh GE (Group Extenstion) + ============== ======================== + On the other hand, when using PDU1 format, the PS-field contains a so-called Destination Address, which is _not_ part of the PGN. When communicating a PGN from user space to kernel (or vice versa) and PDU2 format is used, the PS-field diff --git a/Documentation/networking/kapi.rst b/Documentation/networking/kapi.rst index d198fa5eaacd..ea55f462cefa 100644 --- a/Documentation/networking/kapi.rst +++ b/Documentation/networking/kapi.rst @@ -83,27 +83,6 @@ SUN RPC subsystem .. kernel-doc:: net/sunrpc/clnt.c :export: -WiMAX ------ - -.. kernel-doc:: net/wimax/op-msg.c - :export: - -.. kernel-doc:: net/wimax/op-reset.c - :export: - -.. kernel-doc:: net/wimax/op-rfkill.c - :export: - -.. kernel-doc:: net/wimax/stack.c - :export: - -.. kernel-doc:: include/net/wimax.h - :internal: - -.. kernel-doc:: include/uapi/linux/wimax.h - :internal: - Network device support ====================== diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst new file mode 100644 index 000000000000..6af0196c4297 --- /dev/null +++ b/Documentation/networking/mptcp-sysctl.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +MPTCP Sysfs variables +===================== + +/proc/sys/net/mptcp/* Variables +=============================== + +enabled - INTEGER + Control whether MPTCP sockets can be created. + + MPTCP sockets can be created if the value is nonzero. This is + a per-namespace sysctl. + + Default: 1 + +add_addr_timeout - INTEGER (seconds) + Set the timeout after which an ADD_ADDR control message will be + resent to an MPTCP peer that has not acknowledged a previous + ADD_ADDR message. + + The default value matches TCP_RTO_MAX. This is a per-namespace + sysctl. + + Default: 120 diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst index 43088ddf95e4..a147591ce203 100644 --- a/Documentation/networking/page_pool.rst +++ b/Documentation/networking/page_pool.rst @@ -97,6 +97,14 @@ a page will cause no race conditions is enough. * page_pool_get_dma_dir(): Retrieve the stored DMA direction. +* page_pool_put_page_bulk(): Tries to refill a number of pages into the + ptr_ring cache holding ptr_ring producer lock. If the ptr_ring is full, + page_pool_put_page_bulk() will release leftover pages to the page allocator. + page_pool_put_page_bulk() is suitable to be run inside the driver NAPI tx + completion loop for the XDP_REDIRECT use case. + Please note the caller must not use data area after running + page_pool_put_page_bulk(), as this function overwrites it. + Coding examples =============== diff --git a/Documentation/networking/ppp_generic.rst b/Documentation/networking/ppp_generic.rst index e60504377900..5a10abce5964 100644 --- a/Documentation/networking/ppp_generic.rst +++ b/Documentation/networking/ppp_generic.rst @@ -314,6 +314,22 @@ channel are: it is connected to. It will return an EINVAL error if the channel is not connected to an interface. +* PPPIOCBRIDGECHAN bridges a channel with another. The argument should + point to an int containing the channel number of the channel to bridge + to. Once two channels are bridged, frames presented to one channel by + ppp_input() are passed to the bridge instance for onward transmission. + This allows frames to be switched from one channel into another: for + example, to pass PPPoE frames into a PPPoL2TP session. Since channel + bridging interrupts the normal ppp_input() path, a given channel may + not be part of a bridge at the same time as being part of a unit. + This ioctl will return an EALREADY error if the channel is already + part of a bridge or unit, or ENXIO if the requested channel does not + exist. + +* PPPIOCUNBRIDGECHAN performs the inverse of PPPIOCBRIDGECHAN, unbridging + a channel pair. This ioctl will return an EINVAL error if the channel + does not form part of a bridge. + * All other ioctl commands are passed to the channel ioctl() function. The ioctl calls that are available on an instance that is attached to diff --git a/Documentation/networking/tipc.rst b/Documentation/networking/tipc.rst new file mode 100644 index 000000000000..76775f24cdc8 --- /dev/null +++ b/Documentation/networking/tipc.rst @@ -0,0 +1,100 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +Linux Kernel TIPC +================= + +TIPC (Transparent Inter Process Communication) is a protocol that is +specially designed for intra-cluster communication. + +For more information about TIPC, see http://tipc.sourceforge.net. + +TIPC Base Types +--------------- + +.. kernel-doc:: net/tipc/subscr.h + :internal: + +.. kernel-doc:: net/tipc/bearer.h + :internal: + +.. kernel-doc:: net/tipc/name_table.h + :internal: + +.. kernel-doc:: net/tipc/name_distr.h + :internal: + +.. kernel-doc:: net/tipc/bcast.c + :internal: + +TIPC Bearer Interfaces +---------------------- + +.. kernel-doc:: net/tipc/bearer.c + :internal: + +.. kernel-doc:: net/tipc/udp_media.c + :internal: + +TIPC Crypto Interfaces +---------------------- + +.. kernel-doc:: net/tipc/crypto.c + :internal: + +TIPC Discoverer Interfaces +-------------------------- + +.. kernel-doc:: net/tipc/discover.c + :internal: + +TIPC Link Interfaces +-------------------- + +.. kernel-doc:: net/tipc/link.c + :internal: + +TIPC msg Interfaces +------------------- + +.. kernel-doc:: net/tipc/msg.c + :internal: + +TIPC Name Interfaces +-------------------- + +.. kernel-doc:: net/tipc/name_table.c + :internal: + +.. kernel-doc:: net/tipc/name_distr.c + :internal: + +TIPC Node Management Interfaces +------------------------------- + +.. kernel-doc:: net/tipc/node.c + :internal: + +TIPC Socket Interfaces +---------------------- + +.. kernel-doc:: net/tipc/socket.c + :internal: + +TIPC Network Topology Interfaces +-------------------------------- + +.. kernel-doc:: net/tipc/subscr.c + :internal: + +TIPC Server Interfaces +---------------------- + +.. kernel-doc:: net/tipc/topsrv.c + :internal: + +TIPC Trace Interfaces +--------------------- + +.. kernel-doc:: net/tipc/trace.c + :internal: diff --git a/Documentation/networking/tls-offload.rst b/Documentation/networking/tls-offload.rst index 37773da2bee5..0f55c6d540f9 100644 --- a/Documentation/networking/tls-offload.rst +++ b/Documentation/networking/tls-offload.rst @@ -524,7 +524,13 @@ on TCP retransmissions to handle corner cases is not acceptable. TLS device features ------------------- -Drivers should ignore the changes to TLS the device feature flags. +Drivers should ignore the changes to the TLS device feature flags. These flags will be acted upon accordingly by the core ``ktls`` code. TLS device feature flags only control adding of new TLS connection offloads, old connections will remain active after flags are cleared. + +TLS encryption cannot be offloaded to devices without checksum calculation +offload. Hence, TLS TX device feature flag requires NETIF_F_HW_CSUM being set. +Disabling the latter implies clearing the former. Disabling TX checksum offload +should not affect old connections, and drivers should make sure checksum +calculation does not break for them. diff --git a/Documentation/networking/x25.rst b/Documentation/networking/x25.rst index 00e45d384ba0..e11d9ebdf9a3 100644 --- a/Documentation/networking/x25.rst +++ b/Documentation/networking/x25.rst @@ -19,13 +19,11 @@ implementation of LAPB. Therefore the LAPB modules would be called by unintelligent X.25 card drivers and not by intelligent ones, this would provide a uniform device driver interface, and simplify configuration. -To confuse matters a little, an 802.2 LLC implementation for Linux is being -written which will allow X.25 to be run over an Ethernet (or Token Ring) and -conform with the JNT "Pink Book", this will have a different interface to -the Packet Layer but there will be no confusion since the class of device -being served by the LLC will be completely separate from LAPB. The LLC -implementation is being done as part of another protocol project (SNA) and -by a different author. +To confuse matters a little, an 802.2 LLC implementation is also possible +which could allow X.25 to be run over an Ethernet (or Token Ring) and +conform with the JNT "Pink Book", this would have a different interface to +the Packet Layer but there would be no confusion since the class of device +being served by the LLC would be completely separate from LAPB. Just when you thought that it could not become more confusing, another option appeared, XOT. This allows X.25 Packet Layer frames to operate over diff --git a/Documentation/process/magic-number.rst b/Documentation/process/magic-number.rst index eee9b44553b3..e02ff5ffb653 100644 --- a/Documentation/process/magic-number.rst +++ b/Documentation/process/magic-number.rst @@ -84,7 +84,6 @@ PPP_MAGIC 0x5002 ppp ``include/linux/ SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` -X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h`` SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/process/magic-number.rst index 783e0de314a0..0243d32a0b59 100644 --- a/Documentation/translations/it_IT/process/magic-number.rst +++ b/Documentation/translations/it_IT/process/magic-number.rst @@ -90,7 +90,6 @@ PPP_MAGIC 0x5002 ppp ``include/linux/ SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` -X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h`` SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index ed5ab7e37f38..48bbd3ebad48 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -114,7 +114,6 @@ Todolist: unicode vga-softcursor video-output - wimax/index xfs .. only:: subproject and html diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst index e4c225996af0..de182bf4191c 100644 --- a/Documentation/translations/zh_CN/process/magic-number.rst +++ b/Documentation/translations/zh_CN/process/magic-number.rst @@ -73,7 +73,6 @@ PPP_MAGIC 0x5002 ppp ``include/linux/ SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` -X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h`` SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` |