diff options
Diffstat (limited to 'Documentation/networking/device_drivers')
98 files changed, 11700 insertions, 4383 deletions
diff --git a/Documentation/networking/device_drivers/atm/cxacru-cf.py b/Documentation/networking/device_drivers/atm/cxacru-cf.py new file mode 100644 index 000000000000..b41d298398c8 --- /dev/null +++ b/Documentation/networking/device_drivers/atm/cxacru-cf.py @@ -0,0 +1,48 @@ +#!/usr/bin/env python +# Copyright 2009 Simon Arlott +# +# 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; either version 2 of the License, or (at your option) +# any later version. +# +# 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. +# +# You should have received a copy of the GNU General Public License along with +# this program; if not, write to the Free Software Foundation, Inc., 59 +# Temple Place - Suite 330, Boston, MA 02111-1307, USA. +# +# Usage: cxacru-cf.py < cxacru-cf.bin +# Output: values string suitable for the sysfs adsl_config attribute +# +# Warning: cxacru-cf.bin with MD5 hash cdbac2689969d5ed5d4850f117702110 +# contains mis-aligned values which will stop the modem from being able +# to make a connection. If the first and last two bytes are removed then +# the values become valid, but the modulation will be forced to ANSI +# T1.413 only which may not be appropriate. +# +# The original binary format is a packed list of le32 values. + +import sys +import struct + +i = 0 +while True: + buf = sys.stdin.read(4) + + if len(buf) == 0: + break + elif len(buf) != 4: + sys.stdout.write("\n") + sys.stderr.write("Error: read {0} not 4 bytes\n".format(len(buf))) + sys.exit(1) + + if i > 0: + sys.stdout.write(" ") + sys.stdout.write("{0:x}={1}".format(i, struct.unpack("<I", buf)[0])) + i += 1 + +sys.stdout.write("\n") diff --git a/Documentation/networking/device_drivers/atm/cxacru.rst b/Documentation/networking/device_drivers/atm/cxacru.rst new file mode 100644 index 000000000000..6088af2ffeda --- /dev/null +++ b/Documentation/networking/device_drivers/atm/cxacru.rst @@ -0,0 +1,120 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +ATM cxacru device driver +======================== + +Firmware is required for this device: http://accessrunner.sourceforge.net/ + +While it is capable of managing/maintaining the ADSL connection without the +module loaded, the device will sometimes stop responding after unloading the +driver and it is necessary to unplug/remove power to the device to fix this. + +Note: support for cxacru-cf.bin has been removed. It was not loaded correctly +so it had no effect on the device configuration. Fixing it could have stopped +existing devices working when an invalid configuration is supplied. + +There is a script cxacru-cf.py to convert an existing file to the sysfs form. + +Detected devices will appear as ATM devices named "cxacru". In /sys/class/atm/ +these are directories named cxacruN where N is the device number. A symlink +named device points to the USB interface device's directory which contains +several sysfs attribute files for retrieving device statistics: + +* adsl_controller_version + +* adsl_headend +* adsl_headend_environment + + - Information about the remote headend. + +* adsl_config + + - Configuration writing interface. + - Write parameters in hexadecimal format <index>=<value>, + separated by whitespace, e.g.: + + "1=0 a=5" + + - Up to 7 parameters at a time will be sent and the modem will restart + the ADSL connection when any value is set. These are logged for future + reference. + +* downstream_attenuation (dB) +* downstream_bits_per_frame +* downstream_rate (kbps) +* downstream_snr_margin (dB) + + - Downstream stats. + +* upstream_attenuation (dB) +* upstream_bits_per_frame +* upstream_rate (kbps) +* upstream_snr_margin (dB) +* transmitter_power (dBm/Hz) + + - Upstream stats. + +* downstream_crc_errors +* downstream_fec_errors +* downstream_hec_errors +* upstream_crc_errors +* upstream_fec_errors +* upstream_hec_errors + + - Error counts. + +* line_startable + + - Indicates that ADSL support on the device + is/can be enabled, see adsl_start. + +* line_status + + - "initialising" + - "down" + - "attempting to activate" + - "training" + - "channel analysis" + - "exchange" + - "waiting" + - "up" + + Changes between "down" and "attempting to activate" + if there is no signal. + +* link_status + + - "not connected" + - "connected" + - "lost" + +* mac_address + +* modulation + + - "" (when not connected) + - "ANSI T1.413" + - "ITU-T G.992.1 (G.DMT)" + - "ITU-T G.992.2 (G.LITE)" + +* startup_attempts + + - Count of total attempts to initialise ADSL. + +To enable/disable ADSL, the following can be written to the adsl_state file: + + - "start" + - "stop + - "restart" (stops, waits 1.5s, then starts) + - "poll" (used to resume status polling if it was disabled due to failure) + +Changes in adsl/line state are reported via kernel log messages:: + + [4942145.150704] ATM dev 0: ADSL state: running + [4942243.663766] ATM dev 0: ADSL line: down + [4942249.665075] ATM dev 0: ADSL line: attempting to activate + [4942253.654954] ATM dev 0: ADSL line: training + [4942255.666387] ATM dev 0: ADSL line: channel analysis + [4942259.656262] ATM dev 0: ADSL line: exchange + [2635357.696901] ATM dev 0: ADSL line: up (8128 kb/s down | 832 kb/s up) diff --git a/Documentation/networking/device_drivers/atm/fore200e.rst b/Documentation/networking/device_drivers/atm/fore200e.rst new file mode 100644 index 000000000000..55df9ec09ac8 --- /dev/null +++ b/Documentation/networking/device_drivers/atm/fore200e.rst @@ -0,0 +1,66 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================= +FORE Systems PCA-200E/SBA-200E ATM NIC driver +============================================= + +This driver adds support for the FORE Systems 200E-series ATM adapters +to the Linux operating system. It is based on the earlier PCA-200E driver +written by Uwe Dannowski. + +The driver simultaneously supports PCA-200E and SBA-200E adapters on +i386, alpha (untested), powerpc, sparc and sparc64 archs. + +The intent is to enable the use of different models of FORE adapters at the +same time, by hosts that have several bus interfaces (such as PCI+SBUS, +or PCI+EISA). + +Only PCI and SBUS devices are currently supported by the driver, but support +for other bus interfaces such as EISA should not be too hard to add. + + +Firmware Copyright Notice +------------------------- + +Please read the fore200e_firmware_copyright file present +in the linux/drivers/atm directory for details and restrictions. + + +Firmware Updates +---------------- + +The FORE Systems 200E-series driver is shipped with firmware data being +uploaded to the ATM adapters at system boot time or at module loading time. +The supplied firmware images should work with all adapters. + +However, if you encounter problems (the firmware doesn't start or the driver +is unable to read the PROM data), you may consider trying another firmware +version. Alternative binary firmware images can be found somewhere on the +ForeThought CD-ROM supplied with your adapter by FORE Systems. + +You can also get the latest firmware images from FORE Systems at +https://en.wikipedia.org/wiki/FORE_Systems. Register TACTics Online and go to +the 'software updates' pages. The firmware binaries are part of +the various ForeThought software distributions. + +Notice that different versions of the PCA-200E firmware exist, depending +on the endianness of the host architecture. The driver is shipped with +both little and big endian PCA firmware images. + +Name and location of the new firmware images can be set at kernel +configuration time: + +1. Copy the new firmware binary files (with .bin, .bin1 or .bin2 suffix) + to some directory, such as linux/drivers/atm. + +2. Reconfigure your kernel to set the new firmware name and location. + Expected pathnames are absolute or relative to the drivers/atm directory. + +3. Rebuild and re-install your kernel or your module. + + +Feedback +-------- + +Feedback is welcome. Please send success stories/bug reports/ +patches/improvement/comments/flames to <lizzi@cnam.fr>. diff --git a/Documentation/networking/device_drivers/atm/index.rst b/Documentation/networking/device_drivers/atm/index.rst new file mode 100644 index 000000000000..7b593f031a60 --- /dev/null +++ b/Documentation/networking/device_drivers/atm/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Asynchronous Transfer Mode (ATM) Device Drivers +=============================================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + cxacru + fore200e + iphase + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/atm/iphase.rst b/Documentation/networking/device_drivers/atm/iphase.rst new file mode 100644 index 000000000000..388c7101e2cb --- /dev/null +++ b/Documentation/networking/device_drivers/atm/iphase.rst @@ -0,0 +1,193 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +ATM (i)Chip IA Linux Driver Source +================================== + + READ ME FIRST + +-------------------------------------------------------------------------------- + + Read This Before You Begin! + +-------------------------------------------------------------------------------- + +Description +=========== + +This is the README file for the Interphase PCI ATM (i)Chip IA Linux driver +source release. + +The features and limitations of this driver are as follows: + + - A single VPI (VPI value of 0) is supported. + - Supports 4K VCs for the server board (with 512K control memory) and 1K + VCs for the client board (with 128K control memory). + - UBR, ABR and CBR service categories are supported. + - Only AAL5 is supported. + - Supports setting of PCR on the VCs. + - Multiple adapters in a system are supported. + - All variants of Interphase ATM PCI (i)Chip adapter cards are supported, + including x575 (OC3, control memory 128K , 512K and packet memory 128K, + 512K and 1M), x525 (UTP25) and x531 (DS3 and E3). See + http://www.iphase.com/ + for details. + - Only x86 platforms are supported. + - SMP is supported. + + +Before You Start +================ + + +Installation +------------ + +1. Installing the adapters in the system + + To install the ATM adapters in the system, follow the steps below. + + a. Login as root. + b. Shut down the system and power off the system. + c. Install one or more ATM adapters in the system. + d. Connect each adapter to a port on an ATM switch. The green 'Link' + LED on the front panel of the adapter will be on if the adapter is + connected to the switch properly when the system is powered up. + e. Power on and boot the system. + +2. [ Removed ] + +3. Rebuild kernel with ABR support + + [ a. and b. removed ] + + c. Reconfigure the kernel, choose the Interphase ia driver through "make + menuconfig" or "make xconfig". + d. Rebuild the kernel, loadable modules and the atm tools. + e. Install the new built kernel and modules and reboot. + +4. Load the adapter hardware driver (ia driver) if it is built as a module + + a. Login as root. + b. Change directory to /lib/modules/<kernel-version>/atm. + c. Run "insmod suni.o;insmod iphase.o" + The yellow 'status' LED on the front panel of the adapter will blink + while the driver is loaded in the system. + d. To verify that the 'ia' driver is loaded successfully, run the + following command:: + + cat /proc/atm/devices + + If the driver is loaded successfully, the output of the command will + be similar to the following lines:: + + Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ... + 0 ia xxxxxxxxx 0 ( 0 0 0 0 0 ) 5 ( 0 0 0 0 0 ) + + You can also check the system log file /var/log/messages for messages + related to the ATM driver. + +5. Ia Driver Configuration + +5.1 Configuration of adapter buffers + The (i)Chip boards have 3 different packet RAM size variants: 128K, 512K and + 1M. The RAM size decides the number of buffers and buffer size. The default + size and number of buffers are set as following: + + ========= ======= ====== ====== ====== ====== ====== + Total Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf + RAM size size size size size cnt cnt + ========= ======= ====== ====== ====== ====== ====== + 128K 64K 64K 10K 10K 6 6 + 512K 256K 256K 10K 10K 25 25 + 1M 512K 512K 10K 10K 51 51 + ========= ======= ====== ====== ====== ====== ====== + + These setting should work well in most environments, but can be + changed by typing the following command:: + + insmod <IA_DIR>/ia.o IA_RX_BUF=<RX_CNT> IA_RX_BUF_SZ=<RX_SIZE> \ + IA_TX_BUF=<TX_CNT> IA_TX_BUF_SZ=<TX_SIZE> + + Where: + + - RX_CNT = number of receive buffers in the range (1-128) + - RX_SIZE = size of receive buffers in the range (48-64K) + - TX_CNT = number of transmit buffers in the range (1-128) + - TX_SIZE = size of transmit buffers in the range (48-64K) + + 1. Transmit and receive buffer size must be a multiple of 4. + 2. Care should be taken so that the memory required for the + transmit and receive buffers is less than or equal to the + total adapter packet memory. + +5.2 Turn on ia debug trace + + When the ia driver is built with the CONFIG_ATM_IA_DEBUG flag, the driver + can provide more debug trace if needed. There is a bit mask variable, + IADebugFlag, which controls the output of the traces. You can find the bit + map of the IADebugFlag in iphase.h. + The debug trace can be turn on through the insmod command line option, for + example, "insmod iphase.o IADebugFlag=0xffffffff" can turn on all the debug + traces together with loading the driver. + +6. Ia Driver Test Using ttcp_atm and PVC + + For the PVC setup, the test machines can either be connected back-to-back or + through a switch. If connected through the switch, the switch must be + configured for the PVC(s). + + a. For UBR test: + + At the test machine intended to receive data, type:: + + ttcp_atm -r -a -s 0.100 + + At the other test machine, type:: + + ttcp_atm -t -a -s 0.100 -n 10000 + + Run "ttcp_atm -h" to display more options of the ttcp_atm tool. + b. For ABR test: + + It is the same as the UBR testing, but with an extra command option:: + + -Pabr:max_pcr=<xxx> + + where: + + xxx = the maximum peak cell rate, from 170 - 353207. + + This option must be set on both the machines. + + c. For CBR test: + + It is the same as the UBR testing, but with an extra command option:: + + -Pcbr:max_pcr=<xxx> + + where: + + xxx = the maximum peak cell rate, from 170 - 353207. + + This option may only be set on the transmit machine. + + +Outstanding Issues +================== + + + +Contact Information +------------------- + +:: + + Customer Support: + United States: Telephone: (214) 654-5555 + Fax: (214) 654-5500 + E-Mail: intouch@iphase.com + Europe: Telephone: 33 (0)1 41 15 44 00 + Fax: 33 (0)1 41 15 12 13 + World Wide Web: http://www.iphase.com + Anonymous FTP: ftp.iphase.com diff --git a/Documentation/networking/device_drivers/cable/index.rst b/Documentation/networking/device_drivers/cable/index.rst new file mode 100644 index 000000000000..cce3c4392972 --- /dev/null +++ b/Documentation/networking/device_drivers/cable/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Cable Modem Device Drivers +========================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + sb1000 + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/cable/sb1000.rst b/Documentation/networking/device_drivers/cable/sb1000.rst new file mode 100644 index 000000000000..c8582ca4034d --- /dev/null +++ b/Documentation/networking/device_drivers/cable/sb1000.rst @@ -0,0 +1,222 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +SB100 device driver +=================== + +sb1000 is a module network device driver for the General Instrument (also known +as NextLevel) SURFboard1000 internal cable modem board. This is an ISA card +which is used by a number of cable TV companies to provide cable modem access. +It's a one-way downstream-only cable modem, meaning that your upstream net link +is provided by your regular phone modem. + +This driver was written by Franco Venturi <fventuri@mediaone.net>. He deserves +a great deal of thanks for this wonderful piece of code! + +Needed tools +============ + +Support for this device is now a part of the standard Linux kernel. The +driver source code file is drivers/net/sb1000.c. In addition to this +you will need: + +1. The "cmconfig" program. This is a utility which supplements "ifconfig" + to configure the cable modem and network interface (usually called "cm0"); + +2. Several PPP scripts which live in /etc/ppp to make connecting via your + cable modem easy. + + These utilities can be obtained from: + + http://www.jacksonville.net/~fventuri/ + + in Franco's original source code distribution .tar.gz file. Support for + the sb1000 driver can be found at: + + - http://web.archive.org/web/%2E/http://home.adelphia.net/~siglercm/sb1000.html + - http://web.archive.org/web/%2E/http://linuxpower.cx/~cable/ + + along with these utilities. + +3. The standard isapnp tools. These are necessary to configure your SB1000 + card at boot time (or afterwards by hand) since it's a PnP card. + + If you don't have these installed as a standard part of your Linux + distribution, you can find them at: + + http://www.roestock.demon.co.uk/isapnptools/ + + or check your Linux distribution binary CD or their web site. For help with + isapnp, pnpdump, or /etc/isapnp.conf, go to: + + http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html + +Using the driver +================ + +To make the SB1000 card work, follow these steps: + +1. Run ``make config``, or ``make menuconfig``, or ``make xconfig``, whichever + you prefer, in the top kernel tree directory to set up your kernel + configuration. Make sure to say "Y" to "Prompt for development drivers" + and to say "M" to the sb1000 driver. Also say "Y" or "M" to all the standard + networking questions to get TCP/IP and PPP networking support. + +2. **BEFORE** you build the kernel, edit drivers/net/sb1000.c. Make sure + to redefine the value of READ_DATA_PORT to match the I/O address used + by isapnp to access your PnP cards. This is the value of READPORT in + /etc/isapnp.conf or given by the output of pnpdump. + +3. Build and install the kernel and modules as usual. + +4. Boot your new kernel following the usual procedures. + +5. Set up to configure the new SB1000 PnP card by capturing the output + of "pnpdump" to a file and editing this file to set the correct I/O ports, + IRQ, and DMA settings for all your PnP cards. Make sure none of the settings + conflict with one another. Then test this configuration by running the + "isapnp" command with your new config file as the input. Check for + errors and fix as necessary. (As an aside, I use I/O ports 0x110 and + 0x310 and IRQ 11 for my SB1000 card and these work well for me. YMMV.) + Then save the finished config file as /etc/isapnp.conf for proper + configuration on subsequent reboots. + +6. Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of + the others referenced above. As root, unpack it into a temporary directory + and do a ``make cmconfig`` and then ``install -c cmconfig /usr/local/sbin``. + Don't do ``make install`` because it expects to find all the utilities built + and ready for installation, not just cmconfig. + +7. As root, copy all the files under the ppp/ subdirectory in Franco's + tar file into /etc/ppp, being careful not to overwrite any files that are + already in there. Then modify ppp@gi-on to set the correct login name, + phone number, and frequency for the cable modem. Also edit pap-secrets + to specify your login name and password and any site-specific information + you need. + +8. Be sure to modify /etc/ppp/firewall to use ipchains instead of + the older ipfwadm commands from the 2.0.x kernels. There's a neat utility to + convert ipfwadm commands to ipchains commands: + + http://users.dhp.com/~whisper/ipfwadm2ipchains/ + + You may also wish to modify the firewall script to implement a different + firewalling scheme. + +9. Start the PPP connection via the script /etc/ppp/ppp@gi-on. You must be + root to do this. It's better to use a utility like sudo to execute + frequently used commands like this with root permissions if possible. If you + connect successfully the cable modem interface will come up and you'll see a + driver message like this at the console:: + + cm0: sb1000 at (0x110,0x310), csn 1, S/N 0x2a0d16d8, IRQ 11. + sb1000.c:v1.1.2 6/01/98 (fventuri@mediaone.net) + + The "ifconfig" command should show two new interfaces, ppp0 and cm0. + + The command "cmconfig cm0" will give you information about the cable modem + interface. + +10. Try pinging a site via ``ping -c 5 www.yahoo.com``, for example. You should + see packets received. + +11. If you can't get site names (like www.yahoo.com) to resolve into + IP addresses (like 204.71.200.67), be sure your /etc/resolv.conf file + has no syntax errors and has the right nameserver IP addresses in it. + If this doesn't help, try something like ``ping -c 5 204.71.200.67`` to + see if the networking is running but the DNS resolution is where the + problem lies. + +12. If you still have problems, go to the support web sites mentioned above + and read the information and documentation there. + +Common problems +=============== + +1. Packets go out on the ppp0 interface but don't come back on the cm0 + interface. It looks like I'm connected but I can't even ping any + numerical IP addresses. (This happens predominantly on Debian systems due + to a default boot-time configuration script.) + +Solution + As root ``echo 0 > /proc/sys/net/ipv4/conf/cm0/rp_filter`` so it + can share the same IP address as the ppp0 interface. Note that this + command should probably be added to the /etc/ppp/cablemodem script + *right*between* the "/sbin/ifconfig" and "/sbin/cmconfig" commands. + You may need to do this to /proc/sys/net/ipv4/conf/ppp0/rp_filter as well. + If you do this to /proc/sys/net/ipv4/conf/default/rp_filter on each reboot + (in rc.local or some such) then any interfaces can share the same IP + addresses. + +2. I get "unresolved symbol" error messages on executing ``insmod sb1000.o``. + +Solution + You probably have a non-matching kernel source tree and + /usr/include/linux and /usr/include/asm header files. Make sure you + install the correct versions of the header files in these two directories. + Then rebuild and reinstall the kernel. + +3. When isapnp runs it reports an error, and my SB1000 card isn't working. + +Solution + There's a problem with later versions of isapnp using the "(CHECK)" + option in the lines that allocate the two I/O addresses for the SB1000 card. + This first popped up on RH 6.0. Delete "(CHECK)" for the SB1000 I/O addresses. + Make sure they don't conflict with any other pieces of hardware first! Then + rerun isapnp and go from there. + +4. I can't execute the /etc/ppp/ppp@gi-on file. + +Solution + As root do ``chmod ug+x /etc/ppp/ppp@gi-on``. + +5. The firewall script isn't working (with 2.2.x and higher kernels). + +Solution + Use the ipfwadm2ipchains script referenced above to convert the + /etc/ppp/firewall script from the deprecated ipfwadm commands to ipchains. + +6. I'm getting *tons* of firewall deny messages in the /var/kern.log, + /var/messages, and/or /var/syslog files, and they're filling up my /var + partition!!! + +Solution + First, tell your ISP that you're receiving DoS (Denial of Service) + and/or portscanning (UDP connection attempts) attacks! Look over the deny + messages to figure out what the attack is and where it's coming from. Next, + edit /etc/ppp/cablemodem and make sure the ",nobroadcast" option is turned on + to the "cmconfig" command (uncomment that line). If you're not receiving these + denied packets on your broadcast interface (IP address xxx.yyy.zzz.255 + typically), then someone is attacking your machine in particular. Be careful + out there.... + +7. Everything seems to work fine but my computer locks up after a while + (and typically during a lengthy download through the cable modem)! + +Solution + You may need to add a short delay in the driver to 'slow down' the + SURFboard because your PC might not be able to keep up with the transfer rate + of the SB1000. To do this, it's probably best to download Franco's + sb1000-1.1.2.tar.gz archive and build and install sb1000.o manually. You'll + want to edit the 'Makefile' and look for the 'SB1000_DELAY' + define. Uncomment those 'CFLAGS' lines (and comment out the default ones) + and try setting the delay to something like 60 microseconds with: + '-DSB1000_DELAY=60'. Then do ``make`` and as root ``make install`` and try + it out. If it still doesn't work or you like playing with the driver, you may + try other numbers. Remember though that the higher the delay, the slower the + driver (which slows down the rest of the PC too when it is actively + used). Thanks to Ed Daiga for this tip! + +Credits +======= + +This README came from Franco Venturi's original README file which is +still supplied with his driver .tar.gz archive. I and all other sb1000 users +owe Franco a tremendous "Thank you!" Additional thanks goes to Carl Patten +and Ralph Bonnell who are now managing the Linux SB1000 web site, and to +the SB1000 users who reported and helped debug the common problems listed +above. + + + Clemmitt Sigler + csigler@vt.edu diff --git a/Documentation/networking/device_drivers/can/can327.rst b/Documentation/networking/device_drivers/can/can327.rst new file mode 100644 index 000000000000..b87bfbe5d51c --- /dev/null +++ b/Documentation/networking/device_drivers/can/can327.rst @@ -0,0 +1,331 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) + +can327: ELM327 driver for Linux SocketCAN +========================================== + +Authors +-------- + +Max Staudt <max@enpas.org> + + + +Motivation +----------- + +This driver aims to lower the initial cost for hackers interested in +working with CAN buses. + +CAN adapters are expensive, few, and far between. +ELM327 interfaces are cheap and plentiful. +Let's use ELM327s as CAN adapters. + + + +Introduction +------------- + +This driver is an effort to turn abundant ELM327 based OBD interfaces +into full fledged (as far as possible) CAN interfaces. + +Since the ELM327 was never meant to be a stand alone CAN controller, +the driver has to switch between its modes as quickly as possible in +order to fake full-duplex operation. + +As such, can327 is a best effort driver. However, this is more than +enough to implement simple request-response protocols (such as OBD II), +and to monitor broadcast messages on a bus (such as in a vehicle). + +Most ELM327s come as nondescript serial devices, attached via USB or +Bluetooth. The driver cannot recognize them by itself, and as such it +is up to the user to attach it in form of a TTY line discipline +(similar to PPP, SLIP, slcan, ...). + +This driver is meant for ELM327 versions 1.4b and up, see below for +known limitations in older controllers and clones. + + + +Data sheet +----------- + +The official data sheets can be found at ELM electronics' home page: + + https://www.elmelectronics.com/ + + + +How to attach the line discipline +---------------------------------- + +Every ELM327 chip is factory programmed to operate at a serial setting +of 38400 baud/s, 8 data bits, no parity, 1 stopbit. + +If you have kept this default configuration, the line discipline can +be attached on a command prompt as follows:: + + sudo ldattach \ + --debug \ + --speed 38400 \ + --eightbits \ + --noparity \ + --onestopbit \ + --iflag -ICRNL,INLCR,-IXOFF \ + 30 \ + /dev/ttyUSB0 + +To change the ELM327's serial settings, please refer to its data +sheet. This needs to be done before attaching the line discipline. + +Once the ldisc is attached, the CAN interface starts out unconfigured. +Set the speed before starting it:: + + # The interface needs to be down to change parameters + sudo ip link set can0 down + sudo ip link set can0 type can bitrate 500000 + sudo ip link set can0 up + +500000 bit/s is a common rate for OBD-II diagnostics. +If you're connecting straight to a car's OBD port, this is the speed +that most cars (but not all!) expect. + +After this, you can set out as usual with candump, cansniffer, etc. + + + +How to check the controller version +------------------------------------ + +Use a terminal program to attach to the controller. + +After issuing the "``AT WS``" command, the controller will respond with +its version:: + + >AT WS + + + ELM327 v1.4b + + > + +Note that clones may claim to be any version they like. +It is not indicative of their actual feature set. + + + + +Communication example +---------------------- + +This is a short and incomplete introduction on how to talk to an ELM327. +It is here to guide understanding of the controller's and the driver's +limitation (listed below) as well as manual testing. + + +The ELM327 has two modes: + +- Command mode +- Reception mode + +In command mode, it expects one command per line, terminated by CR. +By default, the prompt is a "``>``", after which a command can be +entered:: + + >ATE1 + OK + > + +The init script in the driver switches off several configuration options +that are only meaningful in the original OBD scenario the chip is meant +for, and are actually a hindrance for can327. + + +When a command is not recognized, such as by an older version of the +ELM327, a question mark is printed as a response instead of OK:: + + >ATUNKNOWN + ? + > + +At present, can327 does not evaluate this response. See the section +below on known limitations for details. + + +When a CAN frame is to be sent, the target address is configured, after +which the frame is sent as a command that consists of the data's hex +dump:: + + >ATSH123 + OK + >DEADBEEF12345678 + OK + > + +The above interaction sends the SFF frame "``DE AD BE EF 12 34 56 78``" +with (11 bit) CAN ID ``0x123``. +For this to function, the controller must be configured for SFF sending +mode (using "``AT PB``", see code or datasheet). + + +Once a frame has been sent and wait-for-reply mode is on (``ATR1``, +configured on ``listen-only=off``), or when the reply timeout expires +and the driver sets the controller into monitoring mode (``ATMA``), +the ELM327 will send one line for each received CAN frame, consisting +of CAN ID, DLC, and data:: + + 123 8 DEADBEEF12345678 + +For EFF (29 bit) CAN frames, the address format is slightly different, +which can327 uses to tell the two apart:: + + 12 34 56 78 8 DEADBEEF12345678 + +The ELM327 will receive both SFF and EFF frames - the current CAN +config (``ATPB``) does not matter. + + +If the ELM327's internal UART sending buffer runs full, it will abort +the monitoring mode, print "BUFFER FULL" and drop back into command +mode. Note that in this case, unlike with other error messages, the +error message may appear on the same line as the last (usually +incomplete) data frame:: + + 12 34 56 78 8 DEADBEEF123 BUFFER FULL + + + +Known limitations of the controller +------------------------------------ + +- Clone devices ("v1.5" and others) + + Sending RTR frames is not supported and will be dropped silently. + + Receiving RTR with DLC 8 will appear to be a regular frame with + the last received frame's DLC and payload. + + "``AT CSM``" (CAN Silent Monitoring, i.e. don't send CAN ACKs) is + not supported, and is hard coded to ON. Thus, frames are not ACKed + while listening: "``AT MA``" (Monitor All) will always be "silent". + However, immediately after sending a frame, the ELM327 will be in + "receive reply" mode, in which it *does* ACK any received frames. + Once the bus goes silent, or an error occurs (such as BUFFER FULL), + or the receive reply timeout runs out, the ELM327 will end reply + reception mode on its own and can327 will fall back to "``AT MA``" + in order to keep monitoring the bus. + + Other limitations may apply, depending on the clone and the quality + of its firmware. + + +- All versions + + No full duplex operation is supported. The driver will switch + between input/output mode as quickly as possible. + + The length of outgoing RTR frames cannot be set. In fact, some + clones (tested with one identifying as "``v1.5``") are unable to + send RTR frames at all. + + We don't have a way to get real-time notifications on CAN errors. + While there is a command (``AT CS``) to retrieve some basic stats, + we don't poll it as it would force us to interrupt reception mode. + + +- Versions prior to 1.4b + + These versions do not send CAN ACKs when in monitoring mode (AT MA). + However, they do send ACKs while waiting for a reply immediately + after sending a frame. The driver maximizes this time to make the + controller as useful as possible. + + Starting with version 1.4b, the ELM327 supports the "``AT CSM``" + command, and the "listen-only" CAN option will take effect. + + +- Versions prior to 1.4 + + These chips do not support the "``AT PB``" command, and thus cannot + change bitrate or SFF/EFF mode on-the-fly. This will have to be + programmed by the user before attaching the line discipline. See the + data sheet for details. + + +- Versions prior to 1.3 + + These chips cannot be used at all with can327. They do not support + the "``AT D1``" command, which is necessary to avoid parsing conflicts + on incoming data, as well as distinction of RTR frame lengths. + + Specifically, this allows for easy distinction of SFF and EFF + frames, and to check whether frames are complete. While it is possible + to deduce the type and length from the length of the line the ELM327 + sends us, this method fails when the ELM327's UART output buffer + overruns. It may abort sending in the middle of the line, which will + then be mistaken for something else. + + + +Known limitations of the driver +-------------------------------- + +- No 8/7 timing. + + ELM327 can only set CAN bitrates that are of the form 500000/n, where + n is an integer divisor. + However there is an exception: With a separate flag, it may set the + speed to be 8/7 of the speed indicated by the divisor. + This mode is not currently implemented. + +- No evaluation of command responses. + + The ELM327 will reply with OK when a command is understood, and with ? + when it is not. The driver does not currently check this, and simply + assumes that the chip understands every command. + The driver is built such that functionality degrades gracefully + nevertheless. See the section on known limitations of the controller. + +- No use of hardware CAN ID filtering + + An ELM327's UART sending buffer will easily overflow on heavy CAN bus + load, resulting in the "``BUFFER FULL``" message. Using the hardware + filters available through "``AT CF xxx``" and "``AT CM xxx``" would be + helpful here, however SocketCAN does not currently provide a facility + to make use of such hardware features. + + + +Rationale behind the chosen configuration +------------------------------------------ + +``AT E1`` + Echo on + + We need this to be able to get a prompt reliably. + +``AT S1`` + Spaces on + + We need this to distinguish 11/29 bit CAN addresses received. + + Note: + We can usually do this using the line length (odd/even), + but this fails if the line is not transmitted fully to + the host (BUFFER FULL). + +``AT D1`` + DLC on + + We need this to tell the "length" of RTR frames. + + + +A note on CAN bus termination +------------------------------ + +Your adapter may have resistors soldered in which are meant to terminate +the bus. This is correct when it is plugged into a OBD-II socket, but +not helpful when trying to tap into the middle of an existing CAN bus. + +If communications don't work with the adapter connected, check for the +termination resistors on its PCB and try removing them. diff --git a/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst new file mode 100644 index 000000000000..1661d13174d5 --- /dev/null +++ b/Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst @@ -0,0 +1,638 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +CTU CAN FD Driver +================= + +Author: Martin Jerabek <martin.jerabek01@gmail.com> + + +About CTU CAN FD IP Core +------------------------ + +`CTU CAN FD <https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_ +is an open source soft core written in VHDL. +It originated in 2015 as Ondrej Ille's project +at the `Department of Measurement <https://meas.fel.cvut.cz/>`_ +of `FEE <http://www.fel.cvut.cz/en/>`_ at `CTU <https://www.cvut.cz/en>`_. + +The SocketCAN driver for Xilinx Zynq SoC based MicroZed board +`Vivado integration <https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top>`_ +and Intel Cyclone V 5CSEMA4U23C6 based DE0-Nano-SoC Terasic board +`QSys integration <https://gitlab.fel.cvut.cz/canbus/intel-soc-ctucanfd>`_ +has been developed as well as support for +`PCIe integration <https://gitlab.fel.cvut.cz/canbus/pcie-ctucanfd>`_ of the core. + +In the case of Zynq, the core is connected via the APB system bus, which does +not have enumeration support, and the device must be specified in Device Tree. +This kind of devices is called platform device in the kernel and is +handled by a platform device driver. + +The basic functional model of the CTU CAN FD peripheral has been +accepted into QEMU mainline. See QEMU `CAN emulation support <https://www.qemu.org/docs/master/system/devices/can.html>`_ +for CAN FD buses, host connection and CTU CAN FD core emulation. The development +version of emulation support can be cloned from ctu-canfd branch of QEMU local +development `repository <https://gitlab.fel.cvut.cz/canbus/qemu-canbus>`_. + + +About SocketCAN +--------------- + +SocketCAN is a standard common interface for CAN devices in the Linux +kernel. As the name suggests, the bus is accessed via sockets, similarly +to common network devices. The reasoning behind this is in depth +described in `Linux SocketCAN <https://www.kernel.org/doc/html/latest/networking/can.html>`_. +In short, it offers a +natural way to implement and work with higher layer protocols over CAN, +in the same way as, e.g., UDP/IP over Ethernet. + +Device probe +~~~~~~~~~~~~ + +Before going into detail about the structure of a CAN bus device driver, +let's reiterate how the kernel gets to know about the device at all. +Some buses, like PCI or PCIe, support device enumeration. That is, when +the system boots, it discovers all the devices on the bus and reads +their configuration. The kernel identifies the device via its vendor ID +and device ID, and if there is a driver registered for this identifier +combination, its probe method is invoked to populate the driver's +instance for the given hardware. A similar situation goes with USB, only +it allows for device hot-plug. + +The situation is different for peripherals which are directly embedded +in the SoC and connected to an internal system bus (AXI, APB, Avalon, +and others). These buses do not support enumeration, and thus the kernel +has to learn about the devices from elsewhere. This is exactly what the +Device Tree was made for. + +Device tree +~~~~~~~~~~~ + +An entry in device tree states that a device exists in the system, how +it is reachable (on which bus it resides) and its configuration – +registers address, interrupts and so on. An example of such a device +tree is given in . + +:: + + / { + /* ... */ + amba: amba { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + + CTU_CAN_FD_0: CTU_CAN_FD@43c30000 { + compatible = "ctu,ctucanfd"; + interrupt-parent = <&intc>; + interrupts = <0 30 4>; + clocks = <&clkc 15>; + reg = <0x43c30000 0x10000>; + }; + }; + }; + + +.. _sec:socketcan:drv: + +Driver structure +~~~~~~~~~~~~~~~~ + +The driver can be divided into two parts – platform-dependent device +discovery and set up, and platform-independent CAN network device +implementation. + +.. _sec:socketcan:platdev: + +Platform device driver +^^^^^^^^^^^^^^^^^^^^^^ + +In the case of Zynq, the core is connected via the AXI system bus, which +does not have enumeration support, and the device must be specified in +Device Tree. This kind of devices is called *platform device* in the +kernel and is handled by a *platform device driver*\ [1]_. + +A platform device driver provides the following things: + +- A *probe* function + +- A *remove* function + +- A table of *compatible* devices that the driver can handle + +The *probe* function is called exactly once when the device appears (or +the driver is loaded, whichever happens later). If there are more +devices handled by the same driver, the *probe* function is called for +each one of them. Its role is to allocate and initialize resources +required for handling the device, as well as set up low-level functions +for the platform-independent layer, e.g., *read_reg* and *write_reg*. +After that, the driver registers the device to a higher layer, in our +case as a *network device*. + +The *remove* function is called when the device disappears, or the +driver is about to be unloaded. It serves to free the resources +allocated in *probe* and to unregister the device from higher layers. + +Finally, the table of *compatible* devices states which devices the +driver can handle. The Device Tree entry ``compatible`` is matched +against the tables of all *platform drivers*. + +.. code:: c + + /* Match table for OF platform binding */ + static const struct of_device_id ctucan_of_match[] = { + { .compatible = "ctu,canfd-2", }, + { .compatible = "ctu,ctucanfd", }, + { /* end of list */ }, + }; + MODULE_DEVICE_TABLE(of, ctucan_of_match); + + static int ctucan_probe(struct platform_device *pdev); + static int ctucan_remove(struct platform_device *pdev); + + static struct platform_driver ctucanfd_driver = { + .probe = ctucan_probe, + .remove = ctucan_remove, + .driver = { + .name = DRIVER_NAME, + .of_match_table = ctucan_of_match, + }, + }; + module_platform_driver(ctucanfd_driver); + + +.. _sec:socketcan:netdev: + +Network device driver +^^^^^^^^^^^^^^^^^^^^^ + +Each network device must support at least these operations: + +- Bring the device up: ``ndo_open`` + +- Bring the device down: ``ndo_close`` + +- Submit TX frames to the device: ``ndo_start_xmit`` + +- Signal TX completion and errors to the network subsystem: ISR + +- Submit RX frames to the network subsystem: ISR and NAPI + +There are two possible event sources: the device and the network +subsystem. Device events are usually signaled via an interrupt, handled +in an Interrupt Service Routine (ISR). Handlers for the events +originating in the network subsystem are then specified in +``struct net_device_ops``. + +When the device is brought up, e.g., by calling ``ip link set can0 up``, +the driver’s function ``ndo_open`` is called. It should validate the +interface configuration and configure and enable the device. The +analogous opposite is ``ndo_close``, called when the device is being +brought down, be it explicitly or implicitly. + +When the system should transmit a frame, it does so by calling +``ndo_start_xmit``, which enqueues the frame into the device. If the +device HW queue (FIFO, mailboxes or whatever the implementation is) +becomes full, the ``ndo_start_xmit`` implementation informs the network +subsystem that it should stop the TX queue (via ``netif_stop_queue``). +It is then re-enabled later in ISR when the device has some space +available again and is able to enqueue another frame. + +All the device events are handled in ISR, namely: + +#. **TX completion**. When the device successfully finishes transmitting + a frame, the frame is echoed locally. On error, an informative error + frame [2]_ is sent to the network subsystem instead. In both cases, + the software TX queue is resumed so that more frames may be sent. + +#. **Error condition**. If something goes wrong (e.g., the device goes + bus-off or RX overrun happens), error counters are updated, and + informative error frames are enqueued to SW RX queue. + +#. **RX buffer not empty**. In this case, read the RX frames and enqueue + them to SW RX queue. Usually NAPI is used as a middle layer (see ). + +.. _sec:socketcan:napi: + +NAPI +~~~~ + +The frequency of incoming frames can be high and the overhead to invoke +the interrupt service routine for each frame can cause significant +system load. There are multiple mechanisms in the Linux kernel to deal +with this situation. They evolved over the years of Linux kernel +development and enhancements. For network devices, the current standard +is NAPI – *the New API*. It is similar to classical top-half/bottom-half +interrupt handling in that it only acknowledges the interrupt in the ISR +and signals that the rest of the processing should be done in softirq +context. On top of that, it offers the possibility to *poll* for new +frames for a while. This has a potential to avoid the costly round of +enabling interrupts, handling an incoming IRQ in ISR, re-enabling the +softirq and switching context back to softirq. + +See :ref:`Documentation/networking/napi.rst <napi>` for more information. + +Integrating the core to Xilinx Zynq +----------------------------------- + +The core interfaces a simple subset of the Avalon +(search for Intel **Avalon Interface Specifications**) +bus as it was originally used on +Alterra FPGA chips, yet Xilinx natively interfaces with AXI +(search for ARM **AMBA AXI and ACE Protocol Specification AXI3, +AXI4, and AXI4-Lite, ACE and ACE-Lite**). +The most obvious solution would be to use +an Avalon/AXI bridge or implement some simple conversion entity. +However, the core’s interface is half-duplex with no handshake +signaling, whereas AXI is full duplex with two-way signaling. Moreover, +even AXI-Lite slave interface is quite resource-intensive, and the +flexibility and speed of AXI are not required for a CAN core. + +Thus a much simpler bus was chosen – APB (Advanced Peripheral Bus) +(search for ARM **AMBA APB Protocol Specification**). +APB-AXI bridge is directly available in +Xilinx Vivado, and the interface adaptor entity is just a few simple +combinatorial assignments. + +Finally, to be able to include the core in a block diagram as a custom +IP, the core, together with the APB interface, has been packaged as a +Vivado component. + +CTU CAN FD Driver design +------------------------ + +The general structure of a CAN device driver has already been examined +in . The next paragraphs provide a more detailed description of the CTU +CAN FD core driver in particular. + +Low-level driver +~~~~~~~~~~~~~~~~ + +The core is not intended to be used solely with SocketCAN, and thus it +is desirable to have an OS-independent low-level driver. This low-level +driver can then be used in implementations of OS driver or directly +either on bare metal or in a user-space application. Another advantage +is that if the hardware slightly changes, only the low-level driver +needs to be modified. + +The code [3]_ is in part automatically generated and in part written +manually by the core author, with contributions of the thesis’ author. +The low-level driver supports operations such as: set bit timing, set +controller mode, enable/disable, read RX frame, write TX frame, and so +on. + +Configuring bit timing +~~~~~~~~~~~~~~~~~~~~~~ + +On CAN, each bit is divided into four segments: SYNC, PROP, PHASE1, and +PHASE2. Their duration is expressed in multiples of a Time Quantum +(details in `CAN Specification, Version 2.0 <http://esd.cs.ucr.edu/webres/can20.pdf>`_, chapter 8). +When configuring +bitrate, the durations of all the segments (and time quantum) must be +computed from the bitrate and Sample Point. This is performed +independently for both the Nominal bitrate and Data bitrate for CAN FD. + +SocketCAN is fairly flexible and offers either highly customized +configuration by setting all the segment durations manually, or a +convenient configuration by setting just the bitrate and sample point +(and even that is chosen automatically per Bosch recommendation if not +specified). However, each CAN controller may have different base clock +frequency and different width of segment duration registers. The +algorithm thus needs the minimum and maximum values for the durations +(and clock prescaler) and tries to optimize the numbers to fit both the +constraints and the requested parameters. + +.. code:: c + + struct can_bittiming_const { + char name[16]; /* Name of the CAN controller hardware */ + __u32 tseg1_min; /* Time segment 1 = prop_seg + phase_seg1 */ + __u32 tseg1_max; + __u32 tseg2_min; /* Time segment 2 = phase_seg2 */ + __u32 tseg2_max; + __u32 sjw_max; /* Synchronisation jump width */ + __u32 brp_min; /* Bit-rate prescaler */ + __u32 brp_max; + __u32 brp_inc; + }; + + +[lst:can_bittiming_const] + +A curious reader will notice that the durations of the segments PROP_SEG +and PHASE_SEG1 are not determined separately but rather combined and +then, by default, the resulting TSEG1 is evenly divided between PROP_SEG +and PHASE_SEG1. In practice, this has virtually no consequences as the +sample point is between PHASE_SEG1 and PHASE_SEG2. In CTU CAN FD, +however, the duration registers ``PROP`` and ``PH1`` have different +widths (6 and 7 bits, respectively), so the auto-computed values might +overflow the shorter register and must thus be redistributed among the +two [4]_. + +Handling RX +~~~~~~~~~~~ + +Frame reception is handled in NAPI queue, which is enabled from ISR when +the RXNE (RX FIFO Not Empty) bit is set. Frames are read one by one +until either no frame is left in the RX FIFO or the maximum work quota +has been reached for the NAPI poll run (see ). Each frame is then passed +to the network interface RX queue. + +An incoming frame may be either a CAN 2.0 frame or a CAN FD frame. The +way to distinguish between these two in the kernel is to allocate either +``struct can_frame`` or ``struct canfd_frame``, the two having different +sizes. In the controller, the information about the frame type is stored +in the first word of RX FIFO. + +This brings us a chicken-egg problem: we want to allocate the ``skb`` +for the frame, and only if it succeeds, fetch the frame from FIFO; +otherwise keep it there for later. But to be able to allocate the +correct ``skb``, we have to fetch the first work of FIFO. There are +several possible solutions: + +#. Read the word, then allocate. If it fails, discard the rest of the + frame. When the system is low on memory, the situation is bad anyway. + +#. Always allocate ``skb`` big enough for an FD frame beforehand. Then + tweak the ``skb`` internals to look like it has been allocated for + the smaller CAN 2.0 frame. + +#. Add option to peek into the FIFO instead of consuming the word. + +#. If the allocation fails, store the read word into driver’s data. On + the next try, use the stored word instead of reading it again. + +Option 1 is simple enough, but not very satisfying if we could do +better. Option 2 is not acceptable, as it would require modifying the +private state of an integral kernel structure. The slightly higher +memory consumption is just a virtual cherry on top of the “cake”. Option +3 requires non-trivial HW changes and is not ideal from the HW point of +view. + +Option 4 seems like a good compromise, with its disadvantage being that +a partial frame may stay in the FIFO for a prolonged time. Nonetheless, +there may be just one owner of the RX FIFO, and thus no one else should +see the partial frame (disregarding some exotic debugging scenarios). +Basides, the driver resets the core on its initialization, so the +partial frame cannot be “adopted” either. In the end, option 4 was +selected [5]_. + +.. _subsec:ctucanfd:rxtimestamp: + +Timestamping RX frames +^^^^^^^^^^^^^^^^^^^^^^ + +The CTU CAN FD core reports the exact timestamp when the frame has been +received. The timestamp is by default captured at the sample point of +the last bit of EOF but is configurable to be captured at the SOF bit. +The timestamp source is external to the core and may be up to 64 bits +wide. At the time of writing, passing the timestamp from kernel to +userspace is not yet implemented, but is planned in the future. + +Handling TX +~~~~~~~~~~~ + +The CTU CAN FD core has 4 independent TX buffers, each with its own +state and priority. When the core wants to transmit, a TX buffer in +Ready state with the highest priority is selected. + +The priorities are 3bit numbers in register TX_PRIORITY +(nibble-aligned). This should be flexible enough for most use cases. +SocketCAN, however, supports only one FIFO queue for outgoing +frames [6]_. The buffer priorities may be used to simulate the FIFO +behavior by assigning each buffer a distinct priority and *rotating* the +priorities after a frame transmission is completed. + +In addition to priority rotation, the SW must maintain head and tail +pointers into the FIFO formed by the TX buffers to be able to determine +which buffer should be used for next frame (``txb_head``) and which +should be the first completed one (``txb_tail``). The actual buffer +indices are (obviously) modulo 4 (number of TX buffers), but the +pointers must be at least one bit wider to be able to distinguish +between FIFO full and FIFO empty – in this situation, +:math:`txb\_head \equiv txb\_tail\ (\textrm{mod}\ 4)`. An example of how +the FIFO is maintained, together with priority rotation, is depicted in + +| + ++------+---+---+---+---+ +| TXB# | 0 | 1 | 2 | 3 | ++======+===+===+===+===+ +| Seq | A | B | C | | ++------+---+---+---+---+ +| Prio | 7 | 6 | 5 | 4 | ++------+---+---+---+---+ +| | | T | | H | ++------+---+---+---+---+ + +| + ++------+---+---+---+---+ +| TXB# | 0 | 1 | 2 | 3 | ++======+===+===+===+===+ +| Seq | | B | C | | ++------+---+---+---+---+ +| Prio | 4 | 7 | 6 | 5 | ++------+---+---+---+---+ +| | | T | | H | ++------+---+---+---+---+ + +| + ++------+---+---+---+---+----+ +| TXB# | 0 | 1 | 2 | 3 | 0’ | ++======+===+===+===+===+====+ +| Seq | E | B | C | D | | ++------+---+---+---+---+----+ +| Prio | 4 | 7 | 6 | 5 | | ++------+---+---+---+---+----+ +| | | T | | | H | ++------+---+---+---+---+----+ + +| + +.. kernel-figure:: fsm_txt_buffer_user.svg + + TX Buffer states with possible transitions + +.. _subsec:ctucanfd:txtimestamp: + +Timestamping TX frames +^^^^^^^^^^^^^^^^^^^^^^ + +When submitting a frame to a TX buffer, one may specify the timestamp at +which the frame should be transmitted. The frame transmission may start +later, but not sooner. Note that the timestamp does not participate in +buffer prioritization – that is decided solely by the mechanism +described above. + +Support for time-based packet transmission was recently merged to Linux +v4.19 `Time-based packet transmission <https://lwn.net/Articles/748879/>`_, +but it remains yet to be researched +whether this functionality will be practical for CAN. + +Also similarly to retrieving the timestamp of RX frames, the core +supports retrieving the timestamp of TX frames – that is the time when +the frame was successfully delivered. The particulars are very similar +to timestamping RX frames and are described in . + +Handling RX buffer overrun +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When a received frame does no more fit into the hardware RX FIFO in its +entirety, RX FIFO overrun flag (STATUS[DOR]) is set and Data Overrun +Interrupt (DOI) is triggered. When servicing the interrupt, care must be +taken first to clear the DOR flag (via COMMAND[CDO]) and after that +clear the DOI interrupt flag. Otherwise, the interrupt would be +immediately [7]_ rearmed. + +**Note**: During development, it was discussed whether the internal HW +pipelining cannot disrupt this clear sequence and whether an additional +dummy cycle is necessary between clearing the flag and the interrupt. On +the Avalon interface, it indeed proved to be the case, but APB being +safe because it uses 2-cycle transactions. Essentially, the DOR flag +would be cleared, but DOI register’s Preset input would still be high +the cycle when the DOI clear request would also be applied (by setting +the register’s Reset input high). As Set had higher priority than Reset, +the DOI flag would not be reset. This has been already fixed by swapping +the Set/Reset priority (see issue #187). + +Reporting Error Passive and Bus Off conditions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It may be desirable to report when the node reaches *Error Passive*, +*Error Warning*, and *Bus Off* conditions. The driver is notified about +error state change by an interrupt (EPI, EWLI), and then proceeds to +determine the core’s error state by reading its error counters. + +There is, however, a slight race condition here – there is a delay +between the time when the state transition occurs (and the interrupt is +triggered) and when the error counters are read. When EPI is received, +the node may be either *Error Passive* or *Bus Off*. If the node goes +*Bus Off*, it obviously remains in the state until it is reset. +Otherwise, the node is *or was* *Error Passive*. However, it may happen +that the read state is *Error Warning* or even *Error Active*. It may be +unclear whether and what exactly to report in that case, but I +personally entertain the idea that the past error condition should still +be reported. Similarly, when EWLI is received but the state is later +detected to be *Error Passive*, *Error Passive* should be reported. + + +CTU CAN FD Driver Sources Reference +----------------------------------- + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd.h + :internal: + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_base.c + :internal: + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_pci.c + :internal: + +.. kernel-doc:: drivers/net/can/ctucanfd/ctucanfd_platform.c + :internal: + +CTU CAN FD IP Core and Driver Development Acknowledgment +--------------------------------------------------------- + +* Odrej Ille <ondrej.ille@gmail.com> + + * started the project as student at Department of Measurement, FEE, CTU + * invested great amount of personal time and enthusiasm to the project over years + * worked on more funded tasks + +* `Department of Measurement <https://meas.fel.cvut.cz/>`_, + `Faculty of Electrical Engineering <http://www.fel.cvut.cz/en/>`_, + `Czech Technical University <https://www.cvut.cz/en>`_ + + * is the main investor into the project over many years + * uses project in their CAN/CAN FD diagnostics framework for `Skoda Auto <https://www.skoda-auto.cz/>`_ + +* `Digiteq Automotive <https://www.digiteqautomotive.com/en>`_ + + * funding of the project CAN FD Open Cores Support Linux Kernel Based Systems + * negotiated and paid CTU to allow public access to the project + * provided additional funding of the work + +* `Department of Control Engineering <https://control.fel.cvut.cz/en>`_, + `Faculty of Electrical Engineering <http://www.fel.cvut.cz/en/>`_, + `Czech Technical University <https://www.cvut.cz/en>`_ + + * solving the project CAN FD Open Cores Support Linux Kernel Based Systems + * providing GitLab management + * virtual servers and computational power for continuous integration + * providing hardware for HIL continuous integration tests + +* `PiKRON Ltd. <http://pikron.com/>`_ + + * minor funding to initiate preparation of the project open-sourcing + +* Petr Porazil <porazil@pikron.com> + + * design of PCIe transceiver addon board and assembly of boards + * design and assembly of MZ_APO baseboard for MicroZed/Zynq based system + +* Martin Jerabek <martin.jerabek01@gmail.com> + + * Linux driver development + * continuous integration platform architect and GHDL updates + * thesis `Open-source and Open-hardware CAN FD Protocol Support <https://dspace.cvut.cz/bitstream/handle/10467/80366/F3-DP-2019-Jerabek-Martin-Jerabek-thesis-2019-canfd.pdf>`_ + +* Jiri Novak <jnovak@fel.cvut.cz> + + * project initiation, management and use at Department of Measurement, FEE, CTU + +* Pavel Pisa <pisa@cmp.felk.cvut.cz> + + * initiate open-sourcing, project coordination, management at Department of Control Engineering, FEE, CTU + +* Jaroslav Beran<jara.beran@gmail.com> + + * system integration for Intel SoC, core and driver testing and updates + +* Carsten Emde (`OSADL <https://www.osadl.org/>`_) + + * provided OSADL expertise to discuss IP core licensing + * pointed to possible deadlock for LGPL and CAN bus possible patent case which lead to relicense IP core design to BSD like license + +* Reiner Zitzmann and Holger Zeltwanger (`CAN in Automation <https://www.can-cia.org/>`_) + + * provided suggestions and help to inform community about the project and invited us to events focused on CAN bus future development directions + +* Jan Charvat + + * implemented CTU CAN FD functional model for QEMU which has been integrated into QEMU mainline (`docs/system/devices/can.rst <https://www.qemu.org/docs/master/system/devices/can.html>`_) + * Bachelor thesis Model of CAN FD Communication Controller for QEMU Emulator + +Notes +----- + + +.. [1] + Other buses have their own specific driver interface to set up the + device. + +.. [2] + Not to be mistaken with CAN Error Frame. This is a ``can_frame`` with + ``CAN_ERR_FLAG`` set and some error info in its ``data`` field. + +.. [3] + Available in CTU CAN FD repository + `<https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core>`_ + +.. [4] + As is done in the low-level driver functions + ``ctucan_hw_set_nom_bittiming`` and + ``ctucan_hw_set_data_bittiming``. + +.. [5] + At the time of writing this thesis, option 1 is still being used and + the modification is queued in gitlab issue #222 + +.. [6] + Strictly speaking, multiple CAN TX queues are supported since v4.19 + `can: enable multi-queue for SocketCAN devices <https://lore.kernel.org/patchwork/patch/913526/>`_ but no mainline driver is using + them yet. + +.. [7] + Or rather in the next clock cycle diff --git a/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg new file mode 100644 index 000000000000..381323423b4c --- /dev/null +++ b/Documentation/networking/device_drivers/can/ctu/fsm_txt_buffer_user.svg @@ -0,0 +1,151 @@ +<?xml version="1.0" encoding="UTF-8"?> +<svg width="113.611mm" height="86.6873mm" version="1.1" viewBox="0 0 113.611 86.6873" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> + <defs> + <marker id="marker3667" overflow="visible" orient="auto"> + <path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker3517" overflow="visible" orient="auto"> + <path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker3373" overflow="visible" orient="auto"> + <path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker3199" overflow="visible" orient="auto"> + <path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker3037" overflow="visible" orient="auto"> + <path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker2779" overflow="visible" orient="auto"> + <path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker2477" overflow="visible" orient="auto"> + <path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker2074" overflow="visible" orient="auto"> + <path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker1964" overflow="visible" orient="auto"> + <path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="marker1856" overflow="visible" orient="auto"> + <path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <marker id="Arrow2Mend" overflow="visible" orient="auto"> + <path transform="scale(.6) rotate(180) translate(0)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill-rule="evenodd" stroke="#000" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <filter id="filter1204" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <marker id="marker2074-3" overflow="visible" orient="auto"> + <path transform="scale(-.6)" d="m8.71859 4.03374-10.9259-4.01772 10.9259-4.01772c-1.7455 2.37206-1.73544 5.61745-6e-7 8.03544z" fill="#28a4ff" fill-rule="evenodd" stroke="#28a4ff" stroke-linejoin="round" stroke-width=".625"/> + </marker> + <filter id="filter1204-6" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <filter id="filter1204-6-9" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <filter id="filter1204-6-2" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <filter id="filter1204-6-2-9" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <filter id="filter1204-6-2-9-4" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <filter id="filter1204-6-2-9-1" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <filter id="filter1204-6-2-9-1-3" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + <filter id="filter1204-6-2-9-1-3-1" x="-4.19953e-6" y="-5.60084e-6" width="1.00001" height="1.00001" color-interpolation-filters="sRGB"> + <feGaussianBlur stdDeviation="0.00018829868"/> + </filter> + </defs> + <metadata> + <rdf:RDF> + <cc:Work rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/> + <dc:title/> + </cc:Work> + </rdf:RDF> + </metadata> + <g transform="translate(-49.0277 -104.823)"> + <g> + <path d="m130.534 165.429h-71.1816v-17.5315" fill="none" marker-end="url(#marker2477)" stroke="#28a4ff" stroke-width=".6"/> + <path d="m145.034 122.959v-11.5914h-43.1215" fill="none" marker-end="url(#marker3037)" stroke="#28a4ff" stroke-width=".6"/> + <rect x="130.679" y="122.933" width="28.2965" height="45.2319" rx="0" ry="0" fill="#e5e5e5" stroke="#717171" stroke-linecap="square" stroke-width=".499999"/> + <path d="m102.044 116.236h23.3126l-0.13388 18.8185h19.9383v3.66603" fill="none" marker-end="url(#marker3199)" stroke="#28a4ff" stroke-width=".6"/> + <path d="m59.5006 138.391v-24.2517h20.6338" fill="none" marker-end="url(#marker2779)" stroke="#28a4ff" stroke-width=".6"/> + <rect x="78.1389" y="126.411" width="28.0037" height="35.0443" rx="0" ry="0" fill="#e5e5e5" stroke="#717171" stroke-linecap="square" stroke-width=".5"/> + </g> + <g fill="#ffcb35" stroke="#000" stroke-linecap="square"> + <ellipse cx="92.1408" cy="114.239" rx="10.8866" ry="4.39308" stroke-width=".5"/> + <ellipse cx="92.1408" cy="134.185" rx="10.8866" ry="4.39308" stroke-width=".499999"/> + <ellipse cx="92.1408" cy="152.199" rx="10.8866" ry="4.39308" stroke-width=".499999"/> + </g> + <g fill="#28a4ff" stroke="#000" stroke-linecap="square" stroke-width=".499999"> + <ellipse cx="144.827" cy="143.316" rx="10.8866" ry="4.39308"/> + <ellipse cx="144.827" cy="159.143" rx="10.8866" ry="4.39308"/> + <ellipse cx="59.4364" cy="142.823" rx="7.36455" ry="4.39308"/> + <ellipse cx="144.827" cy="129.196" rx="10.8866" ry="4.39308"/> + <ellipse cx="143.077" cy="180.53" rx="10.8866" ry="4.39308"/> + </g> + <ellipse cx="110.386" cy="180.53" rx="10.8866" ry="4.39308" fill="#ffcb35" stroke="#000" stroke-linecap="square" stroke-width=".499999"/> + <text x="110.90907" y="179.42688" font-size="3.175px" xml:space="preserve"><tspan x="110.90907" y="179.42688" dy="0.60000002" text-align="center" text-anchor="middle">Accessible</tspan><tspan x="110.90907" y="183.39563"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text> + <text x="143.5869" y="179.52795" xml:space="preserve"><tspan x="143.5869" y="179.52795" dy="1 0 0 0 0 0" font-family="sans-serif" font-size="2.82222px" text-align="center" text-anchor="middle" style="font-variant-caps:normal;font-variant-east-asian:normal;font-variant-ligatures:normal;font-variant-numeric:normal">Inaccessible</tspan><tspan x="143.5869" y="183.36786" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">for S</tspan>W</tspan></text> + <g font-size="3.175px"> + <text x="91.95018" y="115.29005" xml:space="preserve"><tspan x="91.95018" y="115.29005" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Ready</tspan></tspan></text> + <text x="145.25127" y="130.49019" xml:space="preserve"><tspan x="145.25127" y="130.49019" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">TX OK</tspan></tspan></text> + <text x="145.31845" y="144.43121" xml:space="preserve"><tspan x="145.31845" y="144.43121" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Aborted</tspan></tspan></text> + <text x="145.40399" y="160.36035" xml:space="preserve"><tspan x="145.40399" y="160.36035" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">TX failed</tspan></tspan></text> + <text x="91.823967" y="133.53941" text-align="center" text-anchor="middle" style="line-height:0.9" xml:space="preserve"><tspan x="91.823967" y="133.53941" text-align="center"><tspan font-size="3.175px" text-align="center" text-anchor="middle">TX in</tspan></tspan><tspan x="91.823967" y="136.39691" text-align="center">progress</tspan></text> + <text x="91.648918" y="151.84813" text-align="center" text-anchor="middle" style="line-height:0.9" xml:space="preserve"><tspan x="91.648918" y="151.84813" text-align="center"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Abort in</tspan></tspan><tspan x="91.648918" y="154.70563" text-align="center">progress</tspan></text> + <text x="59.456043" y="143.91658" xml:space="preserve"><tspan x="59.456043" y="143.91658" font-size="3.175px"><tspan font-size="3.175px" text-align="center" text-anchor="middle">Empty</tspan></tspan></text> + </g> + <g fill="none"> + <g stroke="#000"> + <rect x="52.3943" y="171.63" width="106.581" height="16.601" rx="0" ry="0" stroke-linecap="square" stroke-width=".499999"/> + <g stroke-width=".6"> + <path d="m106.383 159.046h26.4967" marker-end="url(#Arrow2Mend)"/> + <path d="m103.138 152.268h41.5564v-3.92426" marker-end="url(#marker1856)"/> + <path d="m106.38 129.354h17.7785"/> + <path d="m125.818 129.359h7.2418" marker-end="url(#marker1964)"/> + </g> + <path d="m124.169 129.354a0.959514 0.97091 0 0 1 0.47587-0.84557 0.959514 0.97091 0 0 1 0.96164-3e-3 0.959514 0.97091 0 0 1 0.48149 0.84231" stroke-linecap="square" stroke-width=".600001"/> + <path d="m55.7026 180.832h34.8131" marker-end="url(#marker2074)" stroke-width=".6"/> + </g> + <g> + <path d="m55.6464 185.744h34.8131" marker-end="url(#marker2074-3)" stroke="#28a4ff" stroke-width=".600001"/> + <g stroke-width=".6"> + <path d="m94.0487 129.889v-10.6493" marker-end="url(#marker3373)" stroke="#000"/> + <path d="m89.7534 118.621v10.662" marker-end="url(#marker3517)" stroke="#000"/> + <path d="m92.119 138.812v7.9718" marker-end="url(#marker3667)" stroke="#28a4ff"/> + </g> + </g> + </g> + <text transform="matrix(.264583 0 0 .264583 91.8919 139.964)" x="26.959213" y="9.11724" fill="#2aa1ff" filter="url(#filter1204-6-2-9-1-3-1)" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle" style="line-height:1.1" xml:space="preserve"><tspan x="26.959213" y="9.11724" text-align="center">Set</tspan><tspan x="26.959213" y="22.31724" text-align="center">abort</tspan></text> + <text transform="translate(49.0277 104.823)" x="57.620724" y="16.855087" filter="url(#filter1204)" font-size="3.175px" text-align="center" text-anchor="middle" style="line-height:1.1" xml:space="preserve"><tspan x="57.620724" y="16.855087" text-align="center">Transmission</tspan><tspan x="57.620724" y="20.347588" text-align="center">unsuccessful</tspan></text> + <g font-size="12px" stroke-width="3.77953" text-anchor="middle"> + <text transform="matrix(.264583 0 0 .264583 68.5988 118.913)" x="38.824219" y="9.1171875" filter="url(#filter1204)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Transmission</tspan><tspan x="38.824219" y="22.317188" text-align="center">starts</tspan></text> + <text transform="matrix(.264583 0 0 .264583 106.802 130.509)" x="38.824219" y="9.1171875" filter="url(#filter1204)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Transmission</tspan><tspan x="38.824219" y="22.317188" text-align="center">successful</tspan></text> + <text transform="matrix(.264583 0 0 .264583 107.77 145.476)" x="38.824219" y="9.1171875" filter="url(#filter1204)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Transmission</tspan><tspan x="38.824219" y="22.317188" text-align="center">sborted</tspan></text> + </g> + <g stroke-width="3.77953" text-anchor="middle"> + <text transform="matrix(.264583 0 0 .264583 107.574 155.948)" x="38.824219" y="9.1171875" filter="url(#filter1204)" font-size="10.6667px" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824219" y="9.1171875" text-align="center">Retransmit</tspan><tspan x="38.824219" y="20.850557" text-align="center">limit reached or</tspan><tspan x="38.824219" y="32.583927" text-align="center">node went bus off</tspan><tspan x="38.824219" y="44.317299" text-align="center"/></text> + <text transform="matrix(.264583 0 0 .264583 60.7127 177.384)" x="38.824539" y="9.1173134" filter="url(#filter1204-6)" font-size="12px" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="38.824539" y="9.1173134" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Transmission result</tspan></text> + <text transform="matrix(.264583 0 0 .264583 45.6885 173.226)" x="57.727047" y="9.11724" filter="url(#filter1204-6-9)" font-size="12px" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="57.727047" y="9.11724" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Legend:</tspan></text> + </g> + <g fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-anchor="middle"> + <text transform="matrix(.264583 0 0 .264583 57.0045 182.079)" x="57.727047" y="9.11724" filter="url(#filter1204-6-2)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="57.727047" y="9.11724" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">SW command</tspan></text> + <text transform="matrix(.264583 0 0 .264583 57.7865 110.104)" x="40.822609" y="9.11724" filter="url(#filter1204-6-2-9)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="40.822609" y="9.11724" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set ready</tspan></text> + <text transform="matrix(.264583 0 0 .264583 116.893 107.491)" x="28.049065" y="9.1172523" filter="url(#filter1204-6-2-9-4)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="28.049065" y="9.1172523" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set ready</tspan></text> + <text transform="matrix(.264583 0 0 .264583 87.5687 166.324)" x="28.049065" y="9.1172523" filter="url(#filter1204-6-2-9-1)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="28.049065" y="9.1172523" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set empty</tspan></text> + <text transform="matrix(.264583 0 0 .264583 106.53 113.074)" x="30.228771" y="8.9063139" filter="url(#filter1204-6-2-9-1-3)" text-align="center" style="line-height:1.1" xml:space="preserve"><tspan x="30.228771" y="8.9063139" fill="#2aa1ff" font-size="12px" stroke-width="3.77953" text-align="center" text-anchor="middle">Set abort</tspan></text> + </g> + </g> +</svg> diff --git a/Documentation/networking/device_drivers/can/freescale/flexcan.rst b/Documentation/networking/device_drivers/can/freescale/flexcan.rst new file mode 100644 index 000000000000..106cd2890135 --- /dev/null +++ b/Documentation/networking/device_drivers/can/freescale/flexcan.rst @@ -0,0 +1,54 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +============================= +Flexcan CAN Controller driver +============================= + +Authors: Marc Kleine-Budde <mkl@pengutronix.de>, +Dario Binacchi <dario.binacchi@amarulasolutions.com> + +On/off RTR frames reception +=========================== + +For most flexcan IP cores the driver supports 2 RX modes: + +- FIFO +- mailbox + +The older flexcan cores (integrated into the i.MX25, i.MX28, i.MX35 +and i.MX53 SOCs) only receive RTR frames if the controller is +configured for RX-FIFO mode. + +The RX FIFO mode uses a hardware FIFO with a depth of 6 CAN frames, +while the mailbox mode uses a software FIFO with a depth of up to 62 +CAN frames. With the help of the bigger buffer, the mailbox mode +performs better under high system load situations. + +As reception of RTR frames is part of the CAN standard, all flexcan +cores come up in a mode where RTR reception is possible. + +With the "rx-rtr" private flag the ability to receive RTR frames can +be waived at the expense of losing the ability to receive RTR +messages. This trade off is beneficial in certain use cases. + +"rx-rtr" on + Receive RTR frames. (default) + + The CAN controller can and will receive RTR frames. + + On some IP cores the controller cannot receive RTR frames in the + more performant "RX mailbox" mode and will use "RX FIFO" mode + instead. + +"rx-rtr" off + + Waive ability to receive RTR frames. (not supported on all IP cores) + + This mode activates the "RX mailbox mode" for better performance, on + some IP cores RTR frames cannot be received anymore. + +The setting can only be changed if the interface is down:: + + ip link set dev can0 down + ethtool --set-priv-flags can0 rx-rtr {off|on} + ip link set dev can0 up diff --git a/Documentation/networking/device_drivers/can/index.rst b/Documentation/networking/device_drivers/can/index.rst new file mode 100644 index 000000000000..6a8a4f74fa26 --- /dev/null +++ b/Documentation/networking/device_drivers/can/index.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Controller Area Network (CAN) Device Drivers +============================================ + +Device drivers for CAN devices. + +Contents: + +.. toctree:: + :maxdepth: 2 + + can327 + ctu/ctucanfd-driver + freescale/flexcan + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/cellular/index.rst b/Documentation/networking/device_drivers/cellular/index.rst new file mode 100644 index 000000000000..fc1812d3fc70 --- /dev/null +++ b/Documentation/networking/device_drivers/cellular/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Cellular Modem Device Drivers +============================= + +Contents: + +.. toctree:: + :maxdepth: 2 + + qualcomm/rmnet + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst new file mode 100644 index 000000000000..289c146a8291 --- /dev/null +++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst @@ -0,0 +1,196 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +Rmnet Driver +============ + +1. Introduction +=============== + +rmnet driver is used for supporting the Multiplexing and aggregation +Protocol (MAP). This protocol is used by all recent chipsets using Qualcomm +Technologies, Inc. modems. + +This driver can be used to register onto any physical network device in +IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator. + +Multiplexing allows for creation of logical netdevices (rmnet devices) to +handle multiple private data networks (PDN) like a default internet, tethering, +multimedia messaging service (MMS) or IP media subsystem (IMS). Hardware sends +packets with MAP headers to rmnet. Based on the multiplexer id, rmnet +routes to the appropriate PDN after removing the MAP header. + +Aggregation is required to achieve high data rates. This involves hardware +sending aggregated bunch of MAP frames. rmnet driver will de-aggregate +these MAP frames and send them to appropriate PDN's. + +2. Packet format +================ + +a. MAP packet v1 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Reserved Pad Multiplexer ID Payload length + + Bit 32-x + Function Raw bytes + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Reserved bits must be zero when sent and ignored when received. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +b. Map packet v4 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Reserved Pad Multiplexer ID Payload length + + Bit 32-(x-33) (x-32)-x + Function Raw bytes Checksum offload header + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Reserved bits must be zero when sent and ignored when received. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +Checksum offload header, has the information about the checksum processing done +by the hardware.Checksum offload header fields are in big endian format. + +Packet format:: + + Bit 0-14 15 16-31 + Function Reserved Valid Checksum start offset + + Bit 31-47 48-64 + Function Checksum length Checksum value + +Reserved bits must be zero when sent and ignored when received. + +Valid bit indicates whether the partial checksum is calculated and is valid. +Set to 1, if its is valid. Set to 0 otherwise. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Checksum start offset, Indicates the offset in bytes from the beginning of the +IP header, from which modem computed checksum. + +Checksum length is the Length in bytes starting from CKSUM_START_OFFSET, +over which checksum is computed. + +Checksum value, indicates the checksum computed. + +c. MAP packet v5 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Next header Pad Multiplexer ID Payload length + + Bit 32-x + Function Raw bytes + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Next header is used to indicate the presence of another header, currently is +limited to checksum header. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +d. Checksum offload header v5 + +Checksum offload header fields are in big endian format. + + Bit 0 - 6 7 8-15 16-31 + Function Header Type Next Header Checksum Valid Reserved + +Header Type is to indicate the type of header, this usually is set to CHECKSUM + +Header types += ========================================== +0 Reserved +1 Reserved +2 checksum header + +Checksum Valid is to indicate whether the header checksum is valid. Value of 1 +implies that checksum is calculated on this packet and is valid, value of 0 +indicates that the calculated packet checksum is invalid. + +Reserved bits must be zero when sent and ignored when received. + +e. MAP packet v1/v5 (command specific):: + + Bit 0 1 2-7 8 - 15 16 - 31 + Function Command Reserved Pad Multiplexer ID Payload length + Bit 32 - 39 40 - 45 46 - 47 48 - 63 + Function Command name Reserved Command Type Reserved + Bit 64 - 95 + Function Transaction ID + Bit 96 - 127 + Function Command data + +Command 1 indicates disabling flow while 2 is enabling flow + +Command types + += ========================================== +0 for MAP command request +1 is to acknowledge the receipt of a command +2 is for unsupported commands +3 is for error during processing of commands += ========================================== + +f. Aggregation + +Aggregation is multiple MAP packets (can be data or command) delivered to +rmnet in a single linear skb. rmnet will process the individual +packets and either ACK the MAP command or deliver the IP packet to the +network stack as needed + +MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding.... + +MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad... + +3. Userspace configuration +========================== + +rmnet userspace configuration is done through netlink using iproute2 +https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/ + +The driver uses rtnl_link_ops for communication. diff --git a/Documentation/networking/device_drivers/dec/de4x5.txt b/Documentation/networking/device_drivers/dec/de4x5.txt deleted file mode 100644 index 452aac58341d..000000000000 --- a/Documentation/networking/device_drivers/dec/de4x5.txt +++ /dev/null @@ -1,178 +0,0 @@ - Originally, this driver was written for the Digital Equipment - Corporation series of EtherWORKS Ethernet cards: - - DE425 TP/COAX EISA - DE434 TP PCI - DE435 TP/COAX/AUI PCI - DE450 TP/COAX/AUI PCI - DE500 10/100 PCI Fasternet - - but it will now attempt to support all cards which conform to the - Digital Semiconductor SROM Specification. The driver currently - recognises the following chips: - - DC21040 (no SROM) - DC21041[A] - DC21140[A] - DC21142 - DC21143 - - So far the driver is known to work with the following cards: - - KINGSTON - Linksys - ZNYX342 - SMC8432 - SMC9332 (w/new SROM) - ZNYX31[45] - ZNYX346 10/100 4 port (can act as a 10/100 bridge!) - - The driver has been tested on a relatively busy network using the DE425, - DE434, DE435 and DE500 cards and benchmarked with 'ttcp': it transferred - 16M of data to a DECstation 5000/200 as follows: - - TCP UDP - TX RX TX RX - DE425 1030k 997k 1170k 1128k - DE434 1063k 995k 1170k 1125k - DE435 1063k 995k 1170k 1125k - DE500 1063k 998k 1170k 1125k in 10Mb/s mode - - All values are typical (in kBytes/sec) from a sample of 4 for each - measurement. Their error is +/-20k on a quiet (private) network and also - depend on what load the CPU has. - - ========================================================================= - - The ability to load this driver as a loadable module has been included - and used extensively during the driver development (to save those long - reboot sequences). Loadable module support under PCI and EISA has been - achieved by letting the driver autoprobe as if it were compiled into the - kernel. Do make sure you're not sharing interrupts with anything that - cannot accommodate interrupt sharing! - - To utilise this ability, you have to do 8 things: - - 0) have a copy of the loadable modules code installed on your system. - 1) copy de4x5.c from the /linux/drivers/net directory to your favourite - temporary directory. - 2) for fixed autoprobes (not recommended), edit the source code near - line 5594 to reflect the I/O address you're using, or assign these when - loading by: - - insmod de4x5 io=0xghh where g = bus number - hh = device number - - NB: autoprobing for modules is now supported by default. You may just - use: - - insmod de4x5 - - to load all available boards. For a specific board, still use - the 'io=?' above. - 3) compile de4x5.c, but include -DMODULE in the command line to ensure - that the correct bits are compiled (see end of source code). - 4) if you are wanting to add a new card, goto 5. Otherwise, recompile a - kernel with the de4x5 configuration turned off and reboot. - 5) insmod de4x5 [io=0xghh] - 6) run the net startup bits for your new eth?? interface(s) manually - (usually /etc/rc.inet[12] at boot time). - 7) enjoy! - - To unload a module, turn off the associated interface(s) - 'ifconfig eth?? down' then 'rmmod de4x5'. - - Automedia detection is included so that in principle you can disconnect - from, e.g. TP, reconnect to BNC and things will still work (after a - pause while the driver figures out where its media went). My tests - using ping showed that it appears to work.... - - By default, the driver will now autodetect any DECchip based card. - Should you have a need to restrict the driver to DIGITAL only cards, you - can compile with a DEC_ONLY define, or if loading as a module, use the - 'dec_only=1' parameter. - - I've changed the timing routines to use the kernel timer and scheduling - functions so that the hangs and other assorted problems that occurred - while autosensing the media should be gone. A bonus for the DC21040 - auto media sense algorithm is that it can now use one that is more in - line with the rest (the DC21040 chip doesn't have a hardware timer). - The downside is the 1 'jiffies' (10ms) resolution. - - IEEE 802.3u MII interface code has been added in anticipation that some - products may use it in the future. - - The SMC9332 card has a non-compliant SROM which needs fixing - I have - patched this driver to detect it because the SROM format used complies - to a previous DEC-STD format. - - I have removed the buffer copies needed for receive on Intels. I cannot - remove them for Alphas since the Tulip hardware only does longword - aligned DMA transfers and the Alphas get alignment traps with non - longword aligned data copies (which makes them really slow). No comment. - - I have added SROM decoding routines to make this driver work with any - card that supports the Digital Semiconductor SROM spec. This will help - all cards running the dc2114x series chips in particular. Cards using - the dc2104x chips should run correctly with the basic driver. I'm in - debt to <mjacob@feral.com> for the testing and feedback that helped get - this feature working. So far we have tested KINGSTON, SMC8432, SMC9332 - (with the latest SROM complying with the SROM spec V3: their first was - broken), ZNYX342 and LinkSys. ZNYX314 (dual 21041 MAC) and ZNYX 315 - (quad 21041 MAC) cards also appear to work despite their incorrectly - wired IRQs. - - I have added a temporary fix for interrupt problems when some SCSI cards - share the same interrupt as the DECchip based cards. The problem occurs - because the SCSI card wants to grab the interrupt as a fast interrupt - (runs the service routine with interrupts turned off) vs. this card - which really needs to run the service routine with interrupts turned on. - This driver will now add the interrupt service routine as a fast - interrupt if it is bounced from the slow interrupt. THIS IS NOT A - RECOMMENDED WAY TO RUN THE DRIVER and has been done for a limited time - until people sort out their compatibility issues and the kernel - interrupt service code is fixed. YOU SHOULD SEPARATE OUT THE FAST - INTERRUPT CARDS FROM THE SLOW INTERRUPT CARDS to ensure that they do not - run on the same interrupt. PCMCIA/CardBus is another can of worms... - - Finally, I think I have really fixed the module loading problem with - more than one DECchip based card. As a side effect, I don't mess with - the device structure any more which means that if more than 1 card in - 2.0.x is installed (4 in 2.1.x), the user will have to edit - linux/drivers/net/Space.c to make room for them. Hence, module loading - is the preferred way to use this driver, since it doesn't have this - limitation. - - Where SROM media detection is used and full duplex is specified in the - SROM, the feature is ignored unless lp->params.fdx is set at compile - time OR during a module load (insmod de4x5 args='eth??:fdx' [see - below]). This is because there is no way to automatically detect full - duplex links except through autonegotiation. When I include the - autonegotiation feature in the SROM autoconf code, this detection will - occur automatically for that case. - - Command line arguments are now allowed, similar to passing arguments - through LILO. This will allow a per adapter board set up of full duplex - and media. The only lexical constraints are: the board name (dev->name) - appears in the list before its parameters. The list of parameters ends - either at the end of the parameter list or with another board name. The - following parameters are allowed: - - fdx for full duplex - autosense to set the media/speed; with the following - sub-parameters: - TP, TP_NW, BNC, AUI, BNC_AUI, 100Mb, 10Mb, AUTO - - Case sensitivity is important for the sub-parameters. They *must* be - upper case. Examples: - - insmod de4x5 args='eth1:fdx autosense=BNC eth0:autosense=100Mb'. - - For a compiled in driver, in linux/drivers/net/CONFIG, place e.g. - DE4X5_OPTS = -DDE4X5_PARM='"eth0:fdx autosense=AUI eth2:autosense=TP"' - - Yes, I know full duplex isn't permissible on BNC or AUI; they're just - examples. By default, full duplex is turned off and AUTO is the default - autosense setting. In reality, I expect only the full duplex option to - be used. Note the use of single quotes in the two examples above and the - lack of commas to separate items. diff --git a/Documentation/networking/device_drivers/3com/3c509.txt b/Documentation/networking/device_drivers/ethernet/3com/3c509.rst index fbf722e15ac3..47f706bacdd9 100644 --- a/Documentation/networking/device_drivers/3com/3c509.txt +++ b/Documentation/networking/device_drivers/ethernet/3com/3c509.rst @@ -1,17 +1,21 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================================= Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher) ----------------------------------------------------------------------------- +============================================================================= This file contains the instructions and caveats for v1.18c and higher versions of the 3c509 driver. You should not use the driver without reading this file. release 1.0 + 28 February 2002 + Current maintainer (corrections to): David Ruggiero <jdr@farfalle.com> ----------------------------------------------------------------------------- - -(0) Introduction +Introduction +============ The following are notes and information on using the 3Com EtherLink III series ethercards in Linux. These cards are commonly known by the most widely-used @@ -21,11 +25,11 @@ be (but sometimes are) confused with the similarly-numbered PCI-bus "3c905" provided by the module 3c509.c, which has code to support all of the following models: - 3c509 (original ISA card) - 3c509B (later revision of the ISA card; supports full-duplex) - 3c589 (PCMCIA) - 3c589B (later revision of the 3c589; supports full-duplex) - 3c579 (EISA) + - 3c509 (original ISA card) + - 3c509B (later revision of the ISA card; supports full-duplex) + - 3c589 (PCMCIA) + - 3c589B (later revision of the 3c589; supports full-duplex) + - 3c579 (EISA) Large portions of this documentation were heavily borrowed from the guide written the original author of the 3c509 driver, Donald Becker. The master @@ -33,32 +37,34 @@ copy of that document, which contains notes on older versions of the driver, currently resides on Scyld web server: http://www.scyld.com/. -(1) Special Driver Features +Special Driver Features +======================= Overriding card settings The driver allows boot- or load-time overriding of the card's detected IOADDR, IRQ, and transceiver settings, although this capability shouldn't generally be needed except to enable full-duplex mode (see below). An example of the syntax -for LILO parameters for doing this: +for LILO parameters for doing this:: - ether=10,0x310,3,0x3c509,eth0 + ether=10,0x310,3,0x3c509,eth0 This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts with other card types when overriding the I/O address. When the driver is loaded as a module, only the IRQ may be overridden. For example, setting two cards to IRQ10 and IRQ11 is done by using the irq module -option: +option:: options 3c509 irq=10,11 -(2) Full-duplex mode +Full-duplex mode +================ The v1.18c driver added support for the 3c509B's full-duplex capabilities. In order to enable and successfully use full-duplex mode, three conditions -must be met: +must be met: (a) You must have a Etherlink III card model whose hardware supports full- duplex operations. Currently, the only members of the 3c509 family that are @@ -78,27 +84,32 @@ duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on another system that's connected directly to the 3c509B via a crossover cable. Full-duplex mode can be enabled using 'ethtool'. - -/////Extremely important caution concerning full-duplex mode///// -Understand that the 3c509B's hardware's full-duplex support is much more -limited than that provide by more modern network interface cards. Although -at the physical layer of the network it fully supports full-duplex operation, -the card was designed before the current Ethernet auto-negotiation (N-way) -spec was written. This means that the 3c509B family ***cannot and will not -auto-negotiate a full-duplex connection with its link partner under any -circumstances, no matter how it is initialized***. If the full-duplex mode -of the 3c509B is enabled, its link partner will very likely need to be -independently _forced_ into full-duplex mode as well; otherwise various nasty -failures will occur - at the very least, you'll see massive numbers of packet -collisions. This is one of very rare circumstances where disabling auto- -negotiation and forcing the duplex mode of a network interface card or switch -would ever be necessary or desirable. - - -(3) Available Transceiver Types + +.. warning:: + + Extremely important caution concerning full-duplex mode + + Understand that the 3c509B's hardware's full-duplex support is much more + limited than that provide by more modern network interface cards. Although + at the physical layer of the network it fully supports full-duplex operation, + the card was designed before the current Ethernet auto-negotiation (N-way) + spec was written. This means that the 3c509B family ***cannot and will not + auto-negotiate a full-duplex connection with its link partner under any + circumstances, no matter how it is initialized***. If the full-duplex mode + of the 3c509B is enabled, its link partner will very likely need to be + independently _forced_ into full-duplex mode as well; otherwise various nasty + failures will occur - at the very least, you'll see massive numbers of packet + collisions. This is one of very rare circumstances where disabling auto- + negotiation and forcing the duplex mode of a network interface card or switch + would ever be necessary or desirable. + + +Available Transceiver Types +=========================== For versions of the driver v1.18c and above, the available transceiver types are: - + +== ========================================================================= 0 transceiver type from EEPROM config (normally 10baseT); force half-duplex 1 AUI (thick-net / DB15 connector) 2 (undefined) @@ -106,6 +117,7 @@ For versions of the driver v1.18c and above, the available transceiver types are 4 10baseT (RJ-45 connector); force half-duplex mode 8 transceiver type and duplex mode taken from card's EEPROM config settings 12 10baseT (RJ-45 connector); force full-duplex mode +== ========================================================================= Prior to driver version 1.18c, only transceiver codes 0-4 were supported. Note that the new transceiver codes 8 and 12 are the *only* ones that will enable @@ -116,26 +128,30 @@ it must always be explicitly enabled via one of these code in order to be activated. The transceiver type can be changed using 'ethtool'. - -(4a) Interpretation of error messages and common problems + +Interpretation of error messages and common problems +---------------------------------------------------- Error Messages +^^^^^^^^^^^^^^ -eth0: Infinite loop in interrupt, status 2011. +eth0: Infinite loop in interrupt, status 2011. These are "mostly harmless" message indicating that the driver had too much work during that interrupt cycle. With a status of 0x2011 you are receiving packets faster than they can be removed from the card. This should be rare or impossible in normal operation. Possible causes of this error report are: - + - a "green" mode enabled that slows the processor down when there is no - keyboard activity. + keyboard activity. - some other device or device driver hogging the bus or disabling interrupts. Check /proc/interrupts for excessive interrupt counts. The timer tick - interrupt should always be incrementing faster than the others. + interrupt should always be incrementing faster than the others. + +No received packets +^^^^^^^^^^^^^^^^^^^ -No received packets If a 3c509, 3c562 or 3c589 can successfully transmit packets, but never receives packets (as reported by /proc/net/dev or 'ifconfig') you likely have an interrupt line problem. Check /proc/interrupts to verify that the @@ -146,26 +162,37 @@ or IRQ5, and the easiest solution is to move the 3c509 to a different interrupt line. If the device is receiving packets but 'ping' doesn't work, you have a routing problem. -Tx Carrier Errors Reported in /proc/net/dev +Tx Carrier Errors Reported in /proc/net/dev +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + If an EtherLink III appears to transmit packets, but the "Tx carrier errors" field in /proc/net/dev increments as quickly as the Tx packet count, you -likely have an unterminated network or the incorrect media transceiver selected. +likely have an unterminated network or the incorrect media transceiver selected. + +3c509B card is not detected on machines with an ISA PnP BIOS. +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -3c509B card is not detected on machines with an ISA PnP BIOS. While the updated driver works with most PnP BIOS programs, it does not work with all. This can be fixed by disabling PnP support using the 3Com-supplied -setup program. +setup program. + +3c509 card is not detected on overclocked machines +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -3c509 card is not detected on overclocked machines Increase the delay time in id_read_eeprom() from the current value, 500, -to an absurdly high value, such as 5000. +to an absurdly high value, such as 5000. + +Decoding Status and Error Messages +---------------------------------- -(4b) Decoding Status and Error Messages -The bits in the main status register are: +The bits in the main status register are: +===== ====================================== value description +===== ====================================== 0x01 Interrupt latch 0x02 Tx overrun, or Rx underrun 0x04 Tx complete @@ -174,30 +201,38 @@ value description 0x20 A Rx packet has started to arrive 0x40 The driver has requested an interrupt 0x80 Statistics counter nearly full +===== ====================================== -The bits in the transmit (Tx) status word are: +The bits in the transmit (Tx) status word are: -value description -0x02 Out-of-window collision. -0x04 Status stack overflow (normally impossible). -0x08 16 collisions. -0x10 Tx underrun (not enough PCI bus bandwidth). -0x20 Tx jabber. -0x40 Tx interrupt requested. -0x80 Status is valid (this should always be set). +===== ============================================ +value description +===== ============================================ +0x02 Out-of-window collision. +0x04 Status stack overflow (normally impossible). +0x08 16 collisions. +0x10 Tx underrun (not enough PCI bus bandwidth). +0x20 Tx jabber. +0x40 Tx interrupt requested. +0x80 Status is valid (this should always be set). +===== ============================================ -When a transmit error occurs the driver produces a status message such as +When a transmit error occurs the driver produces a status message such as:: eth0: Transmit error, Tx status register 82 The two values typically seen here are: -0x82 +0x82 +^^^^ + Out of window collision. This typically occurs when some other Ethernet -host is incorrectly set to full duplex on a half duplex network. +host is incorrectly set to full duplex on a half duplex network. + +0x88 +^^^^ -0x88 16 collisions. This typically occurs when the network is exceptionally busy or when another host doesn't correctly back off after a collision. If this error is mixed with 0x82 errors it is the result of a host incorrectly set @@ -207,7 +242,8 @@ Both of these errors are the result of network problems that should be corrected. They do not represent driver malfunction. -(5) Revision history (this file) +Revision history (this file) +============================ 28Feb02 v1.0 DR New; major portions based on Becker original 3c509 docs diff --git a/Documentation/networking/device_drivers/3com/vortex.txt b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst index 587f3fcfbcae..a060f84c4f96 100644 --- a/Documentation/networking/device_drivers/3com/vortex.txt +++ b/Documentation/networking/device_drivers/ethernet/3com/vortex.rst @@ -1,5 +1,11 @@ -Documentation/networking/device_drivers/3com/vortex.txt +.. SPDX-License-Identifier: GPL-2.0 + +========================= +3Com Vortex device driver +========================= + Andrew Morton + 30 April 2000 @@ -8,12 +14,12 @@ driver for Linux, 3c59x.c. The driver was written by Donald Becker <becker@scyld.com> -Don is no longer the prime maintainer of this version of the driver. +Don is no longer the prime maintainer of this version of the driver. Please report problems to one or more of: - Andrew Morton - Netdev mailing list <netdev@vger.kernel.org> - Linux kernel mailing list <linux-kernel@vger.kernel.org> +- Andrew Morton +- Netdev mailing list <netdev@vger.kernel.org> +- Linux kernel mailing list <linux-kernel@vger.kernel.org> Please note the 'Reporting and Diagnosing Problems' section at the end of this file. @@ -24,58 +30,58 @@ Since kernel 2.3.99-pre6, this driver incorporates the support for the This driver supports the following hardware: - 3c590 Vortex 10Mbps - 3c592 EISA 10Mbps Demon/Vortex - 3c597 EISA Fast Demon/Vortex - 3c595 Vortex 100baseTx - 3c595 Vortex 100baseT4 - 3c595 Vortex 100base-MII - 3c900 Boomerang 10baseT - 3c900 Boomerang 10Mbps Combo - 3c900 Cyclone 10Mbps TPO - 3c900 Cyclone 10Mbps Combo - 3c900 Cyclone 10Mbps TPC - 3c900B-FL Cyclone 10base-FL - 3c905 Boomerang 100baseTx - 3c905 Boomerang 100baseT4 - 3c905B Cyclone 100baseTx - 3c905B Cyclone 10/100/BNC - 3c905B-FX Cyclone 100baseFx - 3c905C Tornado - 3c920B-EMB-WNM (ATI Radeon 9100 IGP) - 3c980 Cyclone - 3c980C Python-T - 3cSOHO100-TX Hurricane - 3c555 Laptop Hurricane - 3c556 Laptop Tornado - 3c556B Laptop Hurricane - 3c575 [Megahertz] 10/100 LAN CardBus - 3c575 Boomerang CardBus - 3CCFE575BT Cyclone CardBus - 3CCFE575CT Tornado CardBus - 3CCFE656 Cyclone CardBus - 3CCFEM656B Cyclone+Winmodem CardBus - 3CXFEM656C Tornado+Winmodem CardBus - 3c450 HomePNA Tornado - 3c920 Tornado - 3c982 Hydra Dual Port A - 3c982 Hydra Dual Port B - 3c905B-T4 - 3c920B-EMB-WNM Tornado + - 3c590 Vortex 10Mbps + - 3c592 EISA 10Mbps Demon/Vortex + - 3c597 EISA Fast Demon/Vortex + - 3c595 Vortex 100baseTx + - 3c595 Vortex 100baseT4 + - 3c595 Vortex 100base-MII + - 3c900 Boomerang 10baseT + - 3c900 Boomerang 10Mbps Combo + - 3c900 Cyclone 10Mbps TPO + - 3c900 Cyclone 10Mbps Combo + - 3c900 Cyclone 10Mbps TPC + - 3c900B-FL Cyclone 10base-FL + - 3c905 Boomerang 100baseTx + - 3c905 Boomerang 100baseT4 + - 3c905B Cyclone 100baseTx + - 3c905B Cyclone 10/100/BNC + - 3c905B-FX Cyclone 100baseFx + - 3c905C Tornado + - 3c920B-EMB-WNM (ATI Radeon 9100 IGP) + - 3c980 Cyclone + - 3c980C Python-T + - 3cSOHO100-TX Hurricane + - 3c555 Laptop Hurricane + - 3c556 Laptop Tornado + - 3c556B Laptop Hurricane + - 3c575 [Megahertz] 10/100 LAN CardBus + - 3c575 Boomerang CardBus + - 3CCFE575BT Cyclone CardBus + - 3CCFE575CT Tornado CardBus + - 3CCFE656 Cyclone CardBus + - 3CCFEM656B Cyclone+Winmodem CardBus + - 3CXFEM656C Tornado+Winmodem CardBus + - 3c450 HomePNA Tornado + - 3c920 Tornado + - 3c982 Hydra Dual Port A + - 3c982 Hydra Dual Port B + - 3c905B-T4 + - 3c920B-EMB-WNM Tornado Module parameters ================= There are several parameters which may be provided to the driver when -its module is loaded. These are usually placed in /etc/modprobe.d/*.conf -configuration files. Example: +its module is loaded. These are usually placed in ``/etc/modprobe.d/*.conf`` +configuration files. Example:: -options 3c59x debug=3 rx_copybreak=300 + options 3c59x debug=3 rx_copybreak=300 If you are using the PCMCIA tools (cardmgr) then the options may be -placed in /etc/pcmcia/config.opts: +placed in /etc/pcmcia/config.opts:: -module "3c59x" opts "debug=3 rx_copybreak=300" + module "3c59x" opts "debug=3 rx_copybreak=300" The supported parameters are: @@ -89,7 +95,7 @@ options=N1,N2,N3,... Each number in the list provides an option to the corresponding network card. So if you have two 3c905's and you wish to provide - them with option 0x204 you would use: + them with option 0x204 you would use:: options=0x204,0x204 @@ -97,6 +103,8 @@ options=N1,N2,N3,... have the following meanings: Possible media type settings + + == ================================= 0 10baseT 1 10Mbs AUI 2 undefined @@ -108,17 +116,20 @@ options=N1,N2,N3,... 8 Autonegotiate 9 External MII 10 Use default setting from EEPROM + == ================================= When generating a value for the 'options' setting, the above media selection values may be OR'ed (or added to) the following: + ====== ============================================= 0x8000 Set driver debugging level to 7 0x4000 Set driver debugging level to 2 0x0400 Enable Wake-on-LAN 0x0200 Force full duplex mode. 0x0010 Bus-master enable bit (Old Vortex cards only) + ====== ============================================= - For example: + For example:: insmod 3c59x options=0x204 @@ -127,14 +138,14 @@ options=N1,N2,N3,... global_options=N - Sets the `options' parameter for all 3c59x NICs in the machine. - Entries in the `options' array above will override any setting of + Sets the ``options`` parameter for all 3c59x NICs in the machine. + Entries in the ``options`` array above will override any setting of this. full_duplex=N1,N2,N3... Similar to bit 9 of 'options'. Forces the corresponding card into - full-duplex mode. Please use this in preference to the `options' + full-duplex mode. Please use this in preference to the ``options`` parameter. In fact, please don't use this at all! You're better off getting @@ -143,13 +154,13 @@ full_duplex=N1,N2,N3... global_full_duplex=N1 Sets full duplex mode for all 3c59x NICs in the machine. Entries - in the `full_duplex' array above will override any setting of this. + in the ``full_duplex`` array above will override any setting of this. flow_ctrl=N1,N2,N3... Use 802.3x MAC-layer flow control. The 3com cards only support the PAUSE command, which means that they will stop sending packets for a - short period if they receive a PAUSE frame from the link partner. + short period if they receive a PAUSE frame from the link partner. The driver only allows flow control on a link which is operating in full duplex mode. @@ -170,14 +181,14 @@ rx_copybreak=M This is a speed/space tradeoff. - The value of rx_copybreak is used to decide when to make the copy. - If the packet size is less than rx_copybreak, the packet is copied. + The value of rx_copybreak is used to decide when to make the copy. + If the packet size is less than rx_copybreak, the packet is copied. The default value for rx_copybreak is 200 bytes. max_interrupt_work=N The driver's interrupt service routine can handle many receive and - transmit packets in a single invocation. It does this in a loop. + transmit packets in a single invocation. It does this in a loop. The value of max_interrupt_work governs how many times the interrupt service routine will loop. The default value is 32 loops. If this is exceeded the interrupt service routine gives up and generates a @@ -186,7 +197,7 @@ max_interrupt_work=N hw_checksums=N1,N2,N3,... Recent 3com NICs are able to generate IPv4, TCP and UDP checksums - in hardware. Linux has used the Rx checksumming for a long time. + in hardware. Linux has used the Rx checksumming for a long time. The "zero copy" patch which is planned for the 2.4 kernel series allows you to make use of the NIC's DMA scatter/gather and transmit checksumming as well. @@ -196,11 +207,11 @@ hw_checksums=N1,N2,N3,... This module parameter has been provided so you can override this decision. If you think that Tx checksums are causing a problem, you - may disable the feature with `hw_checksums=0'. + may disable the feature with ``hw_checksums=0``. If you think your NIC should be performing Tx checksumming and the driver isn't enabling it, you can force the use of hardware Tx - checksumming with `hw_checksums=1'. + checksumming with ``hw_checksums=1``. The driver drops a message in the logfiles to indicate whether or not it is using hardware scatter/gather and hardware Tx checksums. @@ -210,8 +221,8 @@ hw_checksums=N1,N2,N3,... decrease in throughput for send(). There is no effect upon receive efficiency. -compaq_ioaddr=N -compaq_irq=N +compaq_ioaddr=N, +compaq_irq=N, compaq_device_id=N "Variables to work-around the Compaq PCI BIOS32 problem".... @@ -219,7 +230,7 @@ compaq_device_id=N watchdog=N Sets the time duration (in milliseconds) after which the kernel - decides that the transmitter has become stuck and needs to be reset. + decides that the transmitter has become stuck and needs to be reset. This is mainly for debugging purposes, although it may be advantageous to increase this value on LANs which have very high collision rates. The default value is 5000 (5.0 seconds). @@ -227,7 +238,7 @@ watchdog=N enable_wol=N1,N2,N3,... Enable Wake-on-LAN support for the relevant interface. Donald - Becker's `ether-wake' application may be used to wake suspended + Becker's ``ether-wake`` application may be used to wake suspended machines. Also enables the NIC's power management support. @@ -235,7 +246,7 @@ enable_wol=N1,N2,N3,... global_enable_wol=N Sets enable_wol mode for all 3c59x NICs in the machine. Entries in - the `enable_wol' array above will override any setting of this. + the ``enable_wol`` array above will override any setting of this. Media selection --------------- @@ -243,7 +254,7 @@ Media selection A number of the older NICs such as the 3c590 and 3c900 series have 10base2 and AUI interfaces. -Prior to January, 2001 this driver would autoeselect the 10base2 or AUI +Prior to January, 2001 this driver would autoselect the 10base2 or AUI port if it didn't detect activity on the 10baseT port. It would then get stuck on the 10base2 port and a driver reload was necessary to switch back to 10baseT. This behaviour could not be prevented with a @@ -325,12 +336,12 @@ Autonegotiation notes Cisco switches (Jeff Busch <jbusch@deja.com>) - My "standard config" for ports to which PC's/servers connect directly: + My "standard config" for ports to which PC's/servers connect directly:: - interface FastEthernet0/N - description machinename - load-interval 30 - spanning-tree portfast + interface FastEthernet0/N + description machinename + load-interval 30 + spanning-tree portfast If autonegotiation is a problem, you may need to specify "speed 100" and "duplex full" as well (or "speed 10" and "duplex half"). @@ -363,14 +374,14 @@ steps you should take: email address will be in the driver source or in the MAINTAINERS file. - The contents of your report will vary a lot depending upon the - problem. If it's a kernel crash then you should refer to the - admin-guide/reporting-bugs.rst file. + problem. If it's a kernel crash then you should refer to + 'Documentation/admin-guide/reporting-issues.rst'. But for most problems it is useful to provide the following: - o Kernel version, driver version + - Kernel version, driver version - o A copy of the banner message which the driver generates when + - A copy of the banner message which the driver generates when it is initialised. For example: eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:50:da:6a:88:f0, IRQ 19 @@ -378,68 +389,68 @@ steps you should take: MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. - NOTE: You must provide the `debug=2' modprobe option to generate - a full detection message. Please do this: + NOTE: You must provide the ``debug=2`` modprobe option to generate + a full detection message. Please do this:: modprobe 3c59x debug=2 - o If it is a PCI device, the relevant output from 'lspci -vx', eg: - - 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) - Subsystem: 3Com Corporation: Unknown device 9200 - Flags: bus master, medium devsel, latency 32, IRQ 19 - I/O ports at a400 [size=128] - Memory at db000000 (32-bit, non-prefetchable) [size=128] - Expansion ROM at <unassigned> [disabled] [size=128K] - Capabilities: [dc] Power Management version 2 - 00: b7 10 00 92 07 00 10 02 74 00 00 02 08 20 00 00 - 10: 01 a4 00 00 00 00 00 db 00 00 00 00 00 00 00 00 - 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10 - 30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0a 0a - - o A description of the environment: 10baseT? 100baseT? + - If it is a PCI device, the relevant output from 'lspci -vx', eg:: + + 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) + Subsystem: 3Com Corporation: Unknown device 9200 + Flags: bus master, medium devsel, latency 32, IRQ 19 + I/O ports at a400 [size=128] + Memory at db000000 (32-bit, non-prefetchable) [size=128] + Expansion ROM at <unassigned> [disabled] [size=128K] + Capabilities: [dc] Power Management version 2 + 00: b7 10 00 92 07 00 10 02 74 00 00 02 08 20 00 00 + 10: 01 a4 00 00 00 00 00 db 00 00 00 00 00 00 00 00 + 20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10 + 30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0a 0a + + - A description of the environment: 10baseT? 100baseT? full/half duplex? switched or hubbed? - o Any additional module parameters which you may be providing to the driver. + - Any additional module parameters which you may be providing to the driver. - o Any kernel logs which are produced. The more the merrier. + - Any kernel logs which are produced. The more the merrier. If this is a large file and you are sending your report to a mailing list, mention that you have the logfile, but don't send it. If you're reporting direct to the maintainer then just send it. To ensure that all kernel logs are available, add the - following line to /etc/syslog.conf: + following line to /etc/syslog.conf:: - kern.* /var/log/messages + kern.* /var/log/messages - Then restart syslogd with: + Then restart syslogd with:: - /etc/rc.d/init.d/syslog restart + /etc/rc.d/init.d/syslog restart (The above may vary, depending upon which Linux distribution you use). - o If your problem is reproducible then that's great. Try the + - If your problem is reproducible then that's great. Try the following: 1) Increase the debug level. Usually this is done via: - a) modprobe driver debug=7 - b) In /etc/modprobe.d/driver.conf: - options driver debug=7 + a) modprobe driver debug=7 + b) In /etc/modprobe.d/driver.conf: + options driver debug=7 2) Recreate the problem with the higher debug level, - send all logs to the maintainer. + send all logs to the maintainer. 3) Download you card's diagnostic tool from Donald - Becker's website <http://www.scyld.com/ethercard_diag.html>. - Download mii-diag.c as well. Build these. + Becker's website <http://www.scyld.com/ethercard_diag.html>. + Download mii-diag.c as well. Build these. - a) Run 'vortex-diag -aaee' and 'mii-diag -v' when the card is - working correctly. Save the output. + a) Run 'vortex-diag -aaee' and 'mii-diag -v' when the card is + working correctly. Save the output. - b) Run the above commands when the card is malfunctioning. Send - both sets of output. + b) Run the above commands when the card is malfunctioning. Send + both sets of output. Finally, please be patient and be prepared to do some work. You may end up working on this problem for a week or more as the maintainer diff --git a/Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst b/Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst new file mode 100644 index 000000000000..7a7040072e58 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/altera/altera_tse.rst @@ -0,0 +1,286 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: <isonum.txt> + +======================================= +Altera Triple-Speed Ethernet MAC driver +======================================= + +Copyright |copy| 2008-2014 Altera Corporation + +This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers +using the SGDMA and MSGDMA soft DMA IP components. The driver uses the +platform bus to obtain component resources. The designs used to test this +driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board, +and tested with ARM and NIOS processor hosts separately. The anticipated use +cases are simple communications between an embedded system and an external peer +for status and simple configuration of the embedded system. + +For more information visit www.altera.com and www.rocketboards.org. Support +forums for the driver may be found on www.rocketboards.org, and a design used +to test this driver may be found there as well. Support is also available from +the maintainer of this driver, found in MAINTAINERS. + +The Triple-Speed Ethernet, SGDMA, and MSGDMA components are all soft IP +components that can be assembled and built into an FPGA using the Altera +Quartus toolchain. Quartus 13.1 and 14.0 were used to build the design that +this driver was tested against. The sopc2dts tool is used to create the +device tree for the driver, and may be found at rocketboards.org. + +The driver probe function examines the device tree and determines if the +Triple-Speed Ethernet instance is using an SGDMA or MSGDMA component. The +probe function then installs the appropriate set of DMA routines to +initialize, setup transmits, receives, and interrupt handling primitives for +the respective configurations. + +The SGDMA component is to be deprecated in the near future (over the next 1-2 +years as of this writing in early 2014) in favor of the MSGDMA component. +SGDMA support is included for existing designs and reference in case a +developer wishes to support their own soft DMA logic and driver support. Any +new designs should not use the SGDMA. + +The SGDMA supports only a single transmit or receive operation at a time, and +therefore will not perform as well compared to the MSGDMA soft IP. Please +visit www.altera.com for known, documented SGDMA errata. + +Scatter-gather DMA is not supported by the SGDMA or MSGDMA at this time. +Scatter-gather DMA will be added to a future maintenance update to this +driver. + +Jumbo frames are not supported at this time. + +The driver limits PHY operations to 10/100Mbps, and has not yet been fully +tested for 1Gbps. This support will be added in a future maintenance update. + +1. Kernel Configuration +======================= + +The kernel configuration option is ALTERA_TSE: + + Device Drivers ---> Network device support ---> Ethernet driver support ---> + Altera Triple-Speed Ethernet MAC support (ALTERA_TSE) + +2. Driver parameters list +========================= + + - debug: message level (0: no output, 16: all); + - dma_rx_num: Number of descriptors in the RX list (default is 64); + - dma_tx_num: Number of descriptors in the TX list (default is 64). + +3. Command line options +======================= + +Driver parameters can be also passed in command line by using:: + + altera_tse=dma_rx_num:128,dma_tx_num:512 + +4. Driver information and notes +=============================== + +4.1. Transmit process +--------------------- +When the driver's transmit routine is called by the kernel, it sets up a +transmit descriptor by calling the underlying DMA transmit routine (SGDMA or +MSGDMA), and initiates a transmit operation. Once the transmit is complete, an +interrupt is driven by the transmit DMA logic. The driver handles the transmit +completion in the context of the interrupt handling chain by recycling +resource required to send and track the requested transmit operation. + +4.2. Receive process +-------------------- +The driver will post receive buffers to the receive DMA logic during driver +initialization. Receive buffers may or may not be queued depending upon the +underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able +to queue receive buffers to the SGDMA receive logic). When a packet is +received, the DMA logic generates an interrupt. The driver handles a receive +interrupt by obtaining the DMA receive logic status, reaping receive +completions until no more receive completions are available. + +4.3. Interrupt Mitigation +------------------------- +The driver is able to mitigate the number of its DMA interrupts +using NAPI for receive operations. Interrupt mitigation is not yet supported +for transmit operations, but will be added in a future maintenance release. + +4.4) Ethtool support +-------------------- +Ethtool is supported. Driver statistics and internal errors can be taken using: +ethtool -S ethX command. It is possible to dump registers etc. + +4.5) PHY Support +---------------- +The driver is compatible with PAL to work with PHY and GPHY devices. + +4.7) List of source files: +-------------------------- + - Kconfig + - Makefile + - altera_tse_main.c: main network device driver + - altera_tse_ethtool.c: ethtool support + - altera_tse.h: private driver structure and common definitions + - altera_msgdma.h: MSGDMA implementation function definitions + - altera_sgdma.h: SGDMA implementation function definitions + - altera_msgdma.c: MSGDMA implementation + - altera_sgdma.c: SGDMA implementation + - altera_sgdmahw.h: SGDMA register and descriptor definitions + - altera_msgdmahw.h: MSGDMA register and descriptor definitions + - altera_utils.c: Driver utility functions + - altera_utils.h: Driver utility function definitions + +5. Debug Information +==================== + +The driver exports debug information such as internal statistics, +debug information, MAC and DMA registers etc. + +A user may use the ethtool support to get statistics: +e.g. using: ethtool -S ethX (that shows the statistics counters) +or sees the MAC registers: e.g. using: ethtool -d ethX + +The developer can also use the "debug" module parameter to get +further debug information. + +6. Statistics Support +===================== + +The controller and driver support a mix of IEEE standard defined statistics, +RFC defined statistics, and driver or Altera defined statistics. The four +specifications containing the standard definitions for these statistics are +as follows: + + - IEEE 802.3-2012 - IEEE Standard for Ethernet. + - RFC 2863 found at http://www.rfc-editor.org/rfc/rfc2863.txt. + - RFC 2819 found at http://www.rfc-editor.org/rfc/rfc2819.txt. + - Altera Triple Speed Ethernet User Guide, found at http://www.altera.com + +The statistics supported by the TSE and the device driver are as follows: + +"tx_packets" is equivalent to aFramesTransmittedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.2. This statistics is the count of frames that are successfully +transmitted. + +"rx_packets" is equivalent to aFramesReceivedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.5. This statistic is the count of frames that are successfully +received. This count does not include any error packets such as CRC errors, +length errors, or alignment errors. + +"rx_crc_errors" is equivalent to aFrameCheckSequenceErrors defined in IEEE +802.3-2012, Section 5.2.2.1.6. This statistic is the count of frames that are +an integral number of bytes in length and do not pass the CRC test as the frame +is received. + +"rx_align_errors" is equivalent to aAlignmentErrors defined in IEEE 802.3-2012, +Section 5.2.2.1.7. This statistic is the count of frames that are not an +integral number of bytes in length and do not pass the CRC test as the frame is +received. + +"tx_bytes" is equivalent to aOctetsTransmittedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.8. This statistic is the count of data and pad bytes +successfully transmitted from the interface. + +"rx_bytes" is equivalent to aOctetsReceivedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.14. This statistic is the count of data and pad bytes +successfully received by the controller. + +"tx_pause" is equivalent to aPAUSEMACCtrlFramesTransmitted defined in IEEE +802.3-2012, Section 30.3.4.2. This statistic is a count of PAUSE frames +transmitted from the network controller. + +"rx_pause" is equivalent to aPAUSEMACCtrlFramesReceived defined in IEEE +802.3-2012, Section 30.3.4.3. This statistic is a count of PAUSE frames +received by the network controller. + +"rx_errors" is equivalent to ifInErrors defined in RFC 2863. This statistic is +a count of the number of packets received containing errors that prevented the +packet from being delivered to a higher level protocol. + +"tx_errors" is equivalent to ifOutErrors defined in RFC 2863. This statistic +is a count of the number of packets that could not be transmitted due to errors. + +"rx_unicast" is equivalent to ifInUcastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were not addressed +to the broadcast address or a multicast group. + +"rx_multicast" is equivalent to ifInMulticastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were addressed to +a multicast address group. + +"rx_broadcast" is equivalent to ifInBroadcastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were addressed to +the broadcast address. + +"tx_discards" is equivalent to ifOutDiscards defined in RFC 2863. This +statistic is the number of outbound packets not transmitted even though an +error was not detected. An example of a reason this might occur is to free up +internal buffer space. + +"tx_unicast" is equivalent to ifOutUcastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were not addressed to +a multicast group or broadcast address. + +"tx_multicast" is equivalent to ifOutMulticastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were addressed to a +multicast group. + +"tx_broadcast" is equivalent to ifOutBroadcastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were addressed to a +broadcast address. + +"ether_drops" is equivalent to etherStatsDropEvents defined in RFC 2819. +This statistic counts the number of packets dropped due to lack of internal +controller resources. + +"rx_total_bytes" is equivalent to etherStatsOctets defined in RFC 2819. +This statistic counts the total number of bytes received by the controller, +including error and discarded packets. + +"rx_total_packets" is equivalent to etherStatsPkts defined in RFC 2819. +This statistic counts the total number of packets received by the controller, +including error, discarded, unicast, multicast, and broadcast packets. + +"rx_undersize" is equivalent to etherStatsUndersizePkts defined in RFC 2819. +This statistic counts the number of correctly formed packets received less +than 64 bytes long. + +"rx_oversize" is equivalent to etherStatsOversizePkts defined in RFC 2819. +This statistic counts the number of correctly formed packets greater than 1518 +bytes long. + +"rx_64_bytes" is equivalent to etherStatsPkts64Octets defined in RFC 2819. +This statistic counts the total number of packets received that were 64 octets +in length. + +"rx_65_127_bytes" is equivalent to etherStatsPkts65to127Octets defined in RFC +2819. This statistic counts the total number of packets received that were +between 65 and 127 octets in length inclusive. + +"rx_128_255_bytes" is equivalent to etherStatsPkts128to255Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 128 and 255 octets in length inclusive. + +"rx_256_511_bytes" is equivalent to etherStatsPkts256to511Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 256 and 511 octets in length inclusive. + +"rx_512_1023_bytes" is equivalent to etherStatsPkts512to1023Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 512 and 1023 octets in length inclusive. + +"rx_1024_1518_bytes" is equivalent to etherStatsPkts1024to1518Octets define +in RFC 2819. This statistic is the total number of packets received that were +between 1024 and 1518 octets in length inclusive. + +"rx_gte_1519_bytes" is a statistic defined specific to the behavior of the +Altera TSE. This statistics counts the number of received good and errored +frames between the length of 1519 and the maximum frame length configured +in the frm_length register. See the Altera TSE User Guide for More details. + +"rx_jabbers" is equivalent to etherStatsJabbers defined in RFC 2819. This +statistic is the total number of packets received that were longer than 1518 +octets, and had either a bad CRC with an integral number of octets (CRC Error) +or a bad CRC with a non-integral number of octets (Alignment Error). + +"rx_runts" is equivalent to etherStatsFragments defined in RFC 2819. This +statistic is the total number of packets received that were less than 64 octets +in length and had either a bad CRC with an integral number of octets (CRC +error) or a bad CRC with a non-integral number of octets (Alignment Error). diff --git a/Documentation/networking/device_drivers/amazon/ena.txt b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index 1bb55c7b604c..a4c7d0c65fd7 100644 --- a/Documentation/networking/device_drivers/amazon/ena.txt +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst @@ -1,18 +1,22 @@ -Linux kernel driver for Elastic Network Adapter (ENA) family: -============================================================= +.. SPDX-License-Identifier: GPL-2.0 + +============================================================ +Linux kernel driver for Elastic Network Adapter (ENA) family +============================================================ + +Overview +======== -Overview: -========= ENA is a networking interface designed to make good use of modern CPU features and system architectures. The ENA device exposes a lightweight management interface with a -minimal set of memory mapped registers and extendable command set +minimal set of memory mapped registers and extendible command set through an Admin Queue. The driver supports a range of ENA devices, is link-speed independent -(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has -a negotiated and extendable feature set. +(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc), and has +a negotiated and extendible feature set. Some ENA devices support SR-IOV. This driver is used for both the SR-IOV Physical Function (PF) and Virtual Function (VF) devices. @@ -23,9 +27,9 @@ is advertised by the device via the Admin Queue), a dedicated MSI-X interrupt vector per Tx/Rx queue pair, adaptive interrupt moderation, and CPU cacheline optimized data placement. -The ENA driver supports industry standard TCP/IP offload features such -as checksum offload and TCP transmit segmentation offload (TSO). -Receive-side scaling (RSS) is supported for multi-core scaling. +The ENA driver supports industry standard TCP/IP offload features such as +checksum offload. Receive-side scaling (RSS) is supported for multi-core +scaling. The ENA driver and its corresponding devices implement health monitoring mechanisms such as watchdog, enabling the device and driver @@ -35,39 +39,37 @@ debug logs. Some of the ENA devices support a working mode called Low-latency Queue (LLQ), which saves several more microseconds. -Supported PCI vendor ID/device IDs: +ENA Source Code Directory Structure =================================== -1d0f:0ec2 - ENA PF -1d0f:1ec2 - ENA PF with LLQ support -1d0f:ec20 - ENA VF -1d0f:ec21 - ENA VF with LLQ support - -ENA Source Code Directory Structure: -==================================== -ena_com.[ch] - Management communication layer. This layer is + +================= ====================================================== +ena_com.[ch] Management communication layer. This layer is responsible for the handling all the management (admin) communication between the device and the driver. -ena_eth_com.[ch] - Tx/Rx data path. -ena_admin_defs.h - Definition of ENA management interface. -ena_eth_io_defs.h - Definition of ENA data path interface. -ena_common_defs.h - Common definitions for ena_com layer. -ena_regs_defs.h - Definition of ENA PCI memory-mapped (MMIO) registers. -ena_netdev.[ch] - Main Linux kernel driver. -ena_syfsfs.[ch] - Sysfs files. -ena_ethtool.c - ethtool callbacks. -ena_pci_id_tbl.h - Supported device IDs. +ena_eth_com.[ch] Tx/Rx data path. +ena_admin_defs.h Definition of ENA management interface. +ena_eth_io_defs.h Definition of ENA data path interface. +ena_common_defs.h Common definitions for ena_com layer. +ena_regs_defs.h Definition of ENA PCI memory-mapped (MMIO) registers. +ena_netdev.[ch] Main Linux kernel driver. +ena_ethtool.c ethtool callbacks. +ena_xdp.[ch] XDP files +ena_pci_id_tbl.h Supported device IDs. +================= ====================================================== Management Interface: ===================== + ENA management interface is exposed by means of: + - PCIe Configuration Space - Device Registers - Admin Queue (AQ) and Admin Completion Queue (ACQ) - Asynchronous Event Notification Queue (AENQ) ENA device MMIO Registers are accessed only during driver -initialization and are not involved in further normal device +initialization and are not used during further normal device operation. AQ is used for submitting management commands, and the @@ -78,6 +80,7 @@ vendor-specific extensions. Most of the management operations are framed in a generic Get/Set feature command. The following admin queue commands are supported: + - Create I/O submission queue - Create I/O completion queue - Destroy I/O submission queue @@ -96,25 +99,28 @@ be reported using ACQ. AENQ events are subdivided into groups. Each group may have multiple syndromes, as shown below The events are: - Group Syndrome - Link state change - X - - Fatal error - X - - Notification Suspend traffic - Notification Resume traffic - Keep-Alive - X - + +==================== =============== +Group Syndrome +==================== =============== +Link state change **X** +Fatal error **X** +Notification Suspend traffic +Notification Resume traffic +Keep-Alive **X** +==================== =============== ACQ and AENQ share the same MSI-X vector. -Keep-Alive is a special mechanism that allows monitoring of the -device's health. The driver maintains a watchdog (WD) handler which, -if fired, logs the current state and statistics then resets and -restarts the ENA device and driver. A Keep-Alive event is delivered by -the device every second. The driver re-arms the WD upon reception of a -Keep-Alive event. A missed Keep-Alive event causes the WD handler to -fire. +Keep-Alive is a special mechanism that allows monitoring the device's health. +A Keep-Alive event is delivered by the device every second. +The driver maintains a watchdog (WD) handler which logs the current state and +statistics. If the keep-alive events aren't delivered as expected the WD resets +the device and the driver. + +Data Path Interface +=================== -Data Path Interface: -==================== I/O operations are based on Tx and Rx Submission Queues (Tx SQ and Rx SQ correspondingly). Each SQ has a completion queue (CQ) associated with it. @@ -123,25 +129,28 @@ The SQs and CQs are implemented as descriptor rings in contiguous physical memory. The ENA driver supports two Queue Operation modes for Tx SQs: -- Regular mode - * In this mode the Tx SQs reside in the host's memory. The ENA - device fetches the ENA Tx descriptors and packet data from host - memory. -- Low Latency Queue (LLQ) mode or "push-mode". - * In this mode the driver pushes the transmit descriptors and the - first 128 bytes of the packet directly to the ENA device memory - space. The rest of the packet payload is fetched by the - device. For this operation mode, the driver uses a dedicated PCI - device memory BAR, which is mapped with write-combine capability. -The Rx SQs support only the regular mode. +- **Regular mode:** + In this mode the Tx SQs reside in the host's memory. The ENA + device fetches the ENA Tx descriptors and packet data from host + memory. + +- **Low Latency Queue (LLQ) mode or "push-mode":** + In this mode the driver pushes the transmit descriptors and the + first 96 bytes of the packet directly to the ENA device memory + space. The rest of the packet payload is fetched by the + device. For this operation mode, the driver uses a dedicated PCI + device memory BAR, which is mapped with write-combine capability. -Note: Not all ENA devices support LLQ, and this feature is negotiated - with the device upon initialization. If the ENA device does not - support LLQ mode, the driver falls back to the regular mode. + **Note that** not all ENA devices support LLQ, and this feature is negotiated + with the device upon initialization. If the ENA device does not + support LLQ mode, the driver falls back to the regular mode. + +The Rx SQs support only the regular mode. The driver supports multi-queue for both Tx and Rx. This has various benefits: + - Reduced CPU/thread/process contention on a given Ethernet interface. - Cache miss rate on completion is reduced, particularly for data cache lines that hold the sk_buff structures. @@ -151,8 +160,9 @@ benefits: packet is running. - In hardware interrupt re-direction. -Interrupt Modes: -================ +Interrupt Modes +=============== + The driver assigns a single MSI-X vector per queue pair (for both Tx and Rx directions). The driver assigns an additional dedicated MSI-X vector for management (for ACQ and AENQ). @@ -163,9 +173,12 @@ removed. I/O queue interrupt registration is performed when the Linux interface of the adapter is opened, and it is de-registered when the interface is closed. -The management interrupt is named: +The management interrupt is named:: + ena-mgmnt@pci:<PCI domain:bus:slot.function> -and for each queue pair, an interrupt is named: + +and for each queue pair, an interrupt is named:: + <interface name>-Tx-Rx-<queue index> The ENA device operates in auto-mask and auto-clear interrupt @@ -173,74 +186,69 @@ modes. That is, once MSI-X is delivered to the host, its Cause bit is automatically cleared and the interrupt is masked. The interrupt is unmasked by the driver after NAPI processing is complete. -Interrupt Moderation: -===================== +Interrupt Moderation +==================== + ENA driver and device can operate in conventional or adaptive interrupt moderation mode. -In conventional mode the driver instructs device to postpone interrupt +**In conventional mode** the driver instructs device to postpone interrupt posting according to static interrupt delay value. The interrupt delay -value can be configured through ethtool(8). The following ethtool -parameters are supported by the driver: tx-usecs, rx-usecs +value can be configured through `ethtool(8)`. The following `ethtool` +parameters are supported by the driver: ``tx-usecs``, ``rx-usecs`` -In adaptive interrupt moderation mode the interrupt delay value is +**In adaptive interrupt** moderation mode the interrupt delay value is updated by the driver dynamically and adjusted every NAPI cycle according to the traffic nature. -By default ENA driver applies adaptive coalescing on Rx traffic and -conventional coalescing on Tx traffic. +Adaptive coalescing can be switched on/off through `ethtool(8)`'s +:code:`adaptive_rx on|off` parameter. -Adaptive coalescing can be switched on/off through ethtool(8) -adaptive_rx on|off parameter. +More information about Adaptive Interrupt Moderation (DIM) can be found in +Documentation/networking/net_dim.rst -The driver chooses interrupt delay value according to the number of -bytes and packets received between interrupt unmasking and interrupt -posting. The driver uses interrupt delay table that subdivides the -range of received bytes/packets into 5 levels and assigns interrupt -delay value to each level. +.. _`RX copybreak`: -The user can enable/disable adaptive moderation, modify the interrupt -delay table and restore its default values through sysfs. +RX copybreak +============ -RX copybreak: -============= The rx_copybreak is initialized by default to ENA_DEFAULT_RX_COPYBREAK and can be configured by the ETHTOOL_STUNABLE command of the SIOCETHTOOL ioctl. -SKB: -==== -The driver-allocated SKB for frames received from Rx handling using -NAPI context. The allocation method depends on the size of the packet. -If the frame length is larger than rx_copybreak, napi_get_frags() -is used, otherwise netdev_alloc_skb_ip_align() is used, the buffer -content is copied (by CPU) to the SKB, and the buffer is recycled. - -Statistics: -=========== -The user can obtain ENA device and driver statistics using ethtool. +This option controls the maximum packet length for which the RX +descriptor it was received on would be recycled. When a packet smaller +than RX copybreak bytes is received, it is copied into a new memory +buffer and the RX descriptor is returned to HW. + +Statistics +========== + +The user can obtain ENA device and driver statistics using `ethtool`. The driver can collect regular or extended statistics (including per-queue stats) from the device. In addition the driver logs the stats to syslog upon device reset. -MTU: -==== +MTU +=== + The driver supports an arbitrarily large MTU with a maximum that is negotiated with the device. The driver configures MTU using the SetFeature command (ENA_ADMIN_MTU property). The user can change MTU -via ip(8) and similar legacy tools. +via `ip(8)` and similar legacy tools. + +Stateless Offloads +================== -Stateless Offloads: -=================== The ENA driver supports: -- TSO over IPv4/IPv6 -- TSO with ECN + - IPv4 header checksum offload - TCP/UDP over IPv4/IPv6 checksum offloads -RSS: -==== +RSS +=== + - The ENA device supports RSS that allows flexible Rx traffic steering. - Toeplitz and CRC32 hash functions are supported. @@ -248,61 +256,103 @@ RSS: inputs for hash functions. - The driver configures RSS settings using the AQ SetFeature command (ENA_ADMIN_RSS_HASH_FUNCTION, ENA_ADMIN_RSS_HASH_INPUT and - ENA_ADMIN_RSS_REDIRECTION_TABLE_CONFIG properties). + ENA_ADMIN_RSS_INDIRECTION_TABLE_CONFIG properties). - If the NETIF_F_RXHASH flag is set, the 32-bit result of the hash function delivered in the Rx CQ descriptor is set in the received SKB. - The user can provide a hash key, hash function, and configure the - indirection table through ethtool(8). + indirection table through `ethtool(8)`. -DATA PATH: -========== -Tx: ---- -end_start_xmit() is called by the stack. This function does the following: -- Maps data buffers (skb->data and frags). -- Populates ena_buf for the push buffer (if the driver and device are - in push mode.) +DATA PATH +========= + +Tx +-- + +:code:`ena_start_xmit()` is called by the stack. This function does the following: + +- Maps data buffers (``skb->data`` and frags). +- Populates ``ena_buf`` for the push buffer (if the driver and device are + in push mode). - Prepares ENA bufs for the remaining frags. -- Allocates a new request ID from the empty req_id ring. The request +- Allocates a new request ID from the empty ``req_id`` ring. The request ID is the index of the packet in the Tx info. This is used for - out-of-order TX completions. + out-of-order Tx completions. - Adds the packet to the proper place in the Tx ring. -- Calls ena_com_prepare_tx(), an ENA communication layer that converts - the ena_bufs to ENA descriptors (and adds meta ENA descriptors as - needed.) +- Calls :code:`ena_com_prepare_tx()`, an ENA communication layer that converts + the ``ena_bufs`` to ENA descriptors (and adds meta ENA descriptors as + needed). + * This function also copies the ENA descriptors and the push buffer - to the Device memory space (if in push mode.) -- Writes doorbell to the ENA device. + to the Device memory space (if in push mode). + +- Writes a doorbell to the ENA device. - When the ENA device finishes sending the packet, a completion interrupt is raised. - The interrupt handler schedules NAPI. -- The ena_clean_tx_irq() function is called. This function handles the +- The :code:`ena_clean_tx_irq()` function is called. This function handles the completion descriptors generated by the ENA, with a single completion descriptor per completed packet. - * req_id is retrieved from the completion descriptor. The tx_info of - the packet is retrieved via the req_id. The data buffers are - unmapped and req_id is returned to the empty req_id ring. + + * ``req_id`` is retrieved from the completion descriptor. The ``tx_info`` of + the packet is retrieved via the ``req_id``. The data buffers are + unmapped and ``req_id`` is returned to the empty ``req_id`` ring. * The function stops when the completion descriptors are completed or the budget is reached. -Rx: ---- +Rx +-- + - When a packet is received from the ENA device. - The interrupt handler schedules NAPI. -- The ena_clean_rx_irq() function is called. This function calls - ena_rx_pkt(), an ENA communication layer function, which returns the - number of descriptors used for a new unhandled packet, and zero if +- The :code:`ena_clean_rx_irq()` function is called. This function calls + :code:`ena_com_rx_pkt()`, an ENA communication layer function, which returns the + number of descriptors used for a new packet, and zero if no new packet is found. -- Then it calls the ena_clean_rx_irq() function. -- ena_eth_rx_skb() checks packet length: +- :code:`ena_rx_skb()` checks packet length: + * If the packet is small (len < rx_copybreak), the driver allocates a SKB for the new packet, and copies the packet payload into the SKB data buffer. + - In this way the original data buffer is not passed to the stack and is reused for future Rx packets. - * Otherwise the function unmaps the Rx buffer, then allocates the - new SKB structure and hooks the Rx buffer to the SKB frags. + + * Otherwise the function unmaps the Rx buffer, sets the first + descriptor as `skb`'s linear part and the other descriptors as the + `skb`'s frags. + - The new SKB is updated with the necessary information (protocol, - checksum hw verify result, etc.), and then passed to the network - stack, using the NAPI interface function napi_gro_receive(). + checksum hw verify result, etc), and then passed to the network + stack, using the NAPI interface function :code:`napi_gro_receive()`. + +Dynamic RX Buffers (DRB) +------------------------ + +Each RX descriptor in the RX ring is a single memory page (which is either 4KB +or 16KB long depending on system's configurations). +To reduce the memory allocations required when dealing with a high rate of small +packets, the driver tries to reuse the remaining RX descriptor's space if more +than 2KB of this page remain unused. + +A simple example of this mechanism is the following sequence of events: + +:: + + 1. Driver allocates page-sized RX buffer and passes it to hardware + +----------------------+ + |4KB RX Buffer | + +----------------------+ + + 2. A 300Bytes packet is received on this buffer + + 3. The driver increases the ref count on this page and returns it back to + HW as an RX buffer of size 4KB - 300Bytes = 3796 Bytes + +----+--------------------+ + |****|3796 Bytes RX Buffer| + +----+--------------------+ + +This mechanism isn't used when an XDP program is loaded, or when the +RX packet is less than rx_copybreak bytes (in which case the packet is +copied out of the RX buffer into the linear part of a new skb allocated +for it and the RX buffer remains the same size, see `RX copybreak`_). diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_core.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_core.rst new file mode 100644 index 000000000000..9e8a16c44102 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/amd/pds_core.rst @@ -0,0 +1,139 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +======================================================== +Linux Driver for the AMD/Pensando(R) DSC adapter family +======================================================== + +Copyright(c) 2023 Advanced Micro Devices, Inc + +Identifying the Adapter +======================= + +To find if one or more AMD/Pensando PCI Core devices are installed on the +host, check for the PCI devices:: + + # lspci -d 1dd8:100c + b5:00.0 Processing accelerators: Pensando Systems Device 100c + b6:00.0 Processing accelerators: Pensando Systems Device 100c + +If such devices are listed as above, then the pds_core.ko driver should find +and configure them for use. There should be log entries in the kernel +messages such as these:: + + $ dmesg | grep pds_core + pds_core 0000:b5:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link) + pds_core 0000:b5:00.0: FW: 1.60.0-73 + pds_core 0000:b6:00.0: 252.048 Gb/s available PCIe bandwidth (16.0 GT/s PCIe x16 link) + pds_core 0000:b6:00.0: FW: 1.60.0-73 + +Driver and firmware version information can be gathered with devlink:: + + $ devlink dev info pci/0000:b5:00.0 + pci/0000:b5:00.0: + driver pds_core + serial_number FLM18420073 + versions: + fixed: + asic.id 0x0 + asic.rev 0x0 + running: + fw 1.51.0-73 + stored: + fw.goldfw 1.15.9-C-22 + fw.mainfwa 1.60.0-73 + fw.mainfwb 1.60.0-57 + +Info versions +============= + +The ``pds_core`` driver reports the following versions + +.. list-table:: devlink info versions implemented + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``fw`` + - running + - Version of firmware running on the device + * - ``fw.goldfw`` + - stored + - Version of firmware stored in the goldfw slot + * - ``fw.mainfwa`` + - stored + - Version of firmware stored in the mainfwa slot + * - ``fw.mainfwb`` + - stored + - Version of firmware stored in the mainfwb slot + * - ``asic.id`` + - fixed + - The ASIC type for this device + * - ``asic.rev`` + - fixed + - The revision of the ASIC for this device + +Parameters +========== + +The ``pds_core`` driver implements the following generic +parameters for controlling the functionality to be made available +as auxiliary_bus devices. + +.. list-table:: Generic parameters implemented + :widths: 5 5 8 82 + + * - Name + - Mode + - Type + - Description + * - ``enable_vnet`` + - runtime + - Boolean + - Enables vDPA functionality through an auxiliary_bus device + +Firmware Management +=================== + +The ``flash`` command can update a the DSC firmware. The downloaded firmware +will be saved into either of firmware bank 1 or bank 2, whichever is not +currently in use, and that bank will used for the next boot:: + + # devlink dev flash pci/0000:b5:00.0 \ + file pensando/dsc_fw_1.63.0-22.tar + +Health Reporters +================ + +The driver supports a devlink health reporter for FW status:: + + # devlink health show pci/0000:2b:00.0 reporter fw + pci/0000:2b:00.0: + reporter fw + state healthy error 0 recover 0 + # devlink health diagnose pci/0000:2b:00.0 reporter fw + Status: healthy State: 1 Generation: 0 Recoveries: 0 + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command:: + + make oldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> Network device support (NETDEVICES [=y]) + -> Ethernet driver support + -> AMD devices + -> AMD/Pensando Ethernet PDS_CORE Support + +Support +======= + +For general Linux networking support, please use the netdev mailing +list, which is monitored by AMD/Pensando personnel:: + + netdev@vger.kernel.org diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst new file mode 100644 index 000000000000..587927d3de92 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/amd/pds_vdpa.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. note: can be edited and viewed with /usr/bin/formiko-vim + +========================================================== +PCI vDPA driver for the AMD/Pensando(R) DSC adapter family +========================================================== + +AMD/Pensando vDPA VF Device Driver + +Copyright(c) 2023 Advanced Micro Devices, Inc + +Overview +======== + +The ``pds_vdpa`` driver is an auxiliary bus driver that supplies +a vDPA device for use by the virtio network stack. It is used with +the Pensando Virtual Function devices that offer vDPA and virtio queue +services. It depends on the ``pds_core`` driver and hardware for the PF +and VF PCI handling as well as for device configuration services. + +Using the device +================ + +The ``pds_vdpa`` device is enabled via multiple configuration steps and +depends on the ``pds_core`` driver to create and enable SR-IOV Virtual +Function devices. After the VFs are enabled, we enable the vDPA service +in the ``pds_core`` device to create the auxiliary devices used by pds_vdpa. + +Example steps: + +.. code-block:: bash + + #!/bin/bash + + modprobe pds_core + modprobe vdpa + modprobe pds_vdpa + + PF_BDF=`ls /sys/module/pds_core/drivers/pci\:pds_core/*/sriov_numvfs | awk -F / '{print $7}'` + + # Enable vDPA VF auxiliary device(s) in the PF + devlink dev param set pci/$PF_BDF name enable_vnet cmode runtime value true + + # Create a VF for vDPA use + echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs + + # Find the vDPA services/devices available + PDS_VDPA_MGMT=`vdpa mgmtdev show | grep vDPA | head -1 | cut -d: -f1` + + # Create a vDPA device for use in virtio network configurations + vdpa dev add name vdpa1 mgmtdev $PDS_VDPA_MGMT mac 00:11:22:33:44:55 + + # Set up an ethernet interface on the vdpa device + modprobe virtio_vdpa + + + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command:: + + make oldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> Network device support (NETDEVICES [=y]) + -> Ethernet driver support + -> Pensando devices + -> Pensando Ethernet PDS_VDPA Support + +Support +======= + +For general Linux networking support, please use the netdev mailing +list, which is monitored by Pensando personnel:: + + netdev@vger.kernel.org + +For more specific support needs, please use the Pensando driver support +email:: + + drivers@pensando.io diff --git a/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst b/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst new file mode 100644 index 000000000000..7a6bc848a2b2 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/amd/pds_vfio_pci.rst @@ -0,0 +1,79 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. note: can be edited and viewed with /usr/bin/formiko-vim + +========================================================== +PCI VFIO driver for the AMD/Pensando(R) DSC adapter family +========================================================== + +AMD/Pensando Linux VFIO PCI Device Driver +Copyright(c) 2023 Advanced Micro Devices, Inc. + +Overview +======== + +The ``pds-vfio-pci`` module is a PCI driver that supports Live Migration +capable Virtual Function (VF) devices in the DSC hardware. + +Using the device +================ + +The pds-vfio-pci device is enabled via multiple configuration steps and +depends on the ``pds_core`` driver to create and enable SR-IOV Virtual +Function devices. + +Shown below are the steps to bind the driver to a VF and also to the +associated auxiliary device created by the ``pds_core`` driver. This +example assumes the pds_core and pds-vfio-pci modules are already +loaded. + +.. code-block:: bash + :name: example-setup-script + + #!/bin/bash + + PF_BUS="0000:60" + PF_BDF="0000:60:00.0" + VF_BDF="0000:60:00.1" + + # Prevent non-vfio VF driver from probing the VF device + echo 0 > /sys/class/pci_bus/$PF_BUS/device/$PF_BDF/sriov_drivers_autoprobe + + # Create single VF for Live Migration via pds_core + echo 1 > /sys/bus/pci/drivers/pds_core/$PF_BDF/sriov_numvfs + + # Allow the VF to be bound to the pds-vfio-pci driver + echo "pds-vfio-pci" > /sys/class/pci_bus/$PF_BUS/device/$VF_BDF/driver_override + + # Bind the VF to the pds-vfio-pci driver + echo "$VF_BDF" > /sys/bus/pci/drivers/pds-vfio-pci/bind + +After performing the steps above, a file in /dev/vfio/<iommu_group> +should have been created. + + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command:: + + make oldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> VFIO Non-Privileged userspace driver framework + -> VFIO support for PDS PCI devices + +Support +======= + +For general Linux networking support, please use the netdev mailing +list, which is monitored by Pensando personnel:: + + netdev@vger.kernel.org + +For more specific support needs, please use the Pensando driver support +email:: + + drivers@pensando.io diff --git a/Documentation/networking/device_drivers/aquantia/atlantic.txt b/Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst index 2013fcedc2da..099280a261be 100644 --- a/Documentation/networking/device_drivers/aquantia/atlantic.txt +++ b/Documentation/networking/device_drivers/ethernet/aquantia/atlantic.rst @@ -1,83 +1,96 @@ -Marvell(Aquantia) AQtion Driver for the aQuantia Multi-Gigabit PCI Express -Family of Ethernet Adapters -============================================================================= +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> -Contents -======== +=============================== +Marvell(Aquantia) AQtion Driver +=============================== -- Identifying Your Adapter -- Configuration -- Supported ethtool options -- Command Line Parameters -- Config file parameters -- Support -- License +For the aQuantia Multi-Gigabit PCI Express Family of Ethernet Adapters + +.. Contents + + - Identifying Your Adapter + - Configuration + - Supported ethtool options + - Command Line Parameters + - Config file parameters + - Support + - License Identifying Your Adapter ======================== -The driver in this release is compatible with AQC-100, AQC-107, AQC-108 based ethernet adapters. +The driver in this release is compatible with AQC-100, AQC-107, AQC-108 +based ethernet adapters. SFP+ Devices (for AQC-100 based adapters) ----------------------------------- +----------------------------------------- -This release tested with passive Direct Attach Cables (DAC) and SFP+/LC Optical Transceiver. +This release tested with passive Direct Attach Cables (DAC) and SFP+/LC +Optical Transceiver. Configuration -========================= - Viewing Link Messages - --------------------- +============= + +Viewing Link Messages +--------------------- Link messages will not be displayed to the console if the distribution is restricting system messages. In order to see network driver link messages on - your console, set dmesg to eight by entering the following: + your console, set dmesg to eight by entering the following:: dmesg -n 8 - NOTE: This setting is not saved across reboots. + .. note:: - Jumbo Frames - ------------ + This setting is not saved across reboots. + +Jumbo Frames +------------ The driver supports Jumbo Frames for all adapters. Jumbo Frames support is enabled by changing the MTU to a value larger than the default of 1500. The maximum value for the MTU is 16000. Use the `ip` command to - increase the MTU size. For example: + increase the MTU size. For example:: - ip link set mtu 16000 dev enp1s0 + ip link set mtu 16000 dev enp1s0 - ethtool - ------- +ethtool +------- The driver utilizes the ethtool interface for driver configuration and diagnostics, as well as displaying statistical information. The latest ethtool version is required for this functionality. - NAPI - ---- +NAPI +---- NAPI (Rx polling mode) is supported in the atlantic driver. Supported ethtool options -============================ - Viewing adapter settings - --------------------- - ethtool <ethX> +========================= + +Viewing adapter settings +------------------------ + + :: - Output example: + ethtool <ethX> + + Output example:: Settings for enp1s0: Supported ports: [ TP ] Supported link modes: 100baseT/Full - 1000baseT/Full - 10000baseT/Full - 2500baseT/Full - 5000baseT/Full + 1000baseT/Full + 10000baseT/Full + 2500baseT/Full + 5000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full - 1000baseT/Full - 10000baseT/Full - 2500baseT/Full - 5000baseT/Full + 1000baseT/Full + 10000baseT/Full + 2500baseT/Full + 5000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported @@ -92,16 +105,22 @@ Supported ethtool options Wake-on: d Link detected: yes - --- - Note: AQrate speeds (2.5/5 Gb/s) will be displayed only with linux kernels > 4.10. - But you can still use these speeds: + + .. note:: + + AQrate speeds (2.5/5 Gb/s) will be displayed only with linux kernels > 4.10. + But you can still use these speeds:: + ethtool -s eth0 autoneg off speed 2500 - Viewing adapter information - --------------------- - ethtool -i <ethX> +Viewing adapter information +--------------------------- - Output example: + :: + + ethtool -i <ethX> + + Output example:: driver: atlantic version: 5.2.0-050200rc5-generic-kern @@ -115,12 +134,16 @@ Supported ethtool options supports-priv-flags: no - Viewing Ethernet adapter statistics: - --------------------- - ethtool -S <ethX> +Viewing Ethernet adapter statistics +----------------------------------- + + :: - Output example: - NIC statistics: + ethtool -S <ethX> + + Output example:: + + NIC statistics: InPackets: 13238607 InUCast: 13293852 InMCast: 52 @@ -164,85 +187,95 @@ Supported ethtool options Queue[3] InLroPackets: 0 Queue[3] InErrors: 0 - Interrupt coalescing support - --------------------------------- - ITR mode, TX/RX coalescing timings could be viewed with: +Interrupt coalescing support +---------------------------- - ethtool -c <ethX> + ITR mode, TX/RX coalescing timings could be viewed with:: - and changed with: + ethtool -c <ethX> - ethtool -C <ethX> tx-usecs <usecs> rx-usecs <usecs> + and changed with:: - To disable coalescing: + ethtool -C <ethX> tx-usecs <usecs> rx-usecs <usecs> - ethtool -C <ethX> tx-usecs 0 rx-usecs 0 tx-max-frames 1 tx-max-frames 1 + To disable coalescing:: - Wake on LAN support - --------------------------------- + ethtool -C <ethX> tx-usecs 0 rx-usecs 0 tx-max-frames 1 tx-max-frames 1 - WOL support by magic packet: +Wake on LAN support +------------------- - ethtool -s <ethX> wol g + WOL support by magic packet:: - To disable WOL: + ethtool -s <ethX> wol g - ethtool -s <ethX> wol d + To disable WOL:: - Set and check the driver message level - --------------------------------- + ethtool -s <ethX> wol d + +Set and check the driver message level +-------------------------------------- Set message level - ethtool -s <ethX> msglvl <level> + :: + + ethtool -s <ethX> msglvl <level> Level values: - 0x0001 - general driver status. - 0x0002 - hardware probing. - 0x0004 - link state. - 0x0008 - periodic status check. - 0x0010 - interface being brought down. - 0x0020 - interface being brought up. - 0x0040 - receive error. - 0x0080 - transmit error. - 0x0200 - interrupt handling. - 0x0400 - transmit completion. - 0x0800 - receive completion. - 0x1000 - packet contents. - 0x2000 - hardware status. - 0x4000 - Wake-on-LAN status. + ====== ============================= + 0x0001 general driver status. + 0x0002 hardware probing. + 0x0004 link state. + 0x0008 periodic status check. + 0x0010 interface being brought down. + 0x0020 interface being brought up. + 0x0040 receive error. + 0x0080 transmit error. + 0x0200 interrupt handling. + 0x0400 transmit completion. + 0x0800 receive completion. + 0x1000 packet contents. + 0x2000 hardware status. + 0x4000 Wake-on-LAN status. + ====== ============================= By default, the level of debugging messages is set 0x0001(general driver status). Check message level - ethtool <ethX> | grep "Current message level" + :: - If you want to disable the output of messages + ethtool <ethX> | grep "Current message level" - ethtool -s <ethX> msglvl 0 + If you want to disable the output of messages:: + + ethtool -s <ethX> msglvl 0 + +RX flow rules (ntuple filters) +------------------------------ - RX flow rules (ntuple filters) - --------------------------------- There are separate rules supported, that applies in that order: + 1. 16 VLAN ID rules 2. 16 L2 EtherType rules 3. 8 L3/L4 5-Tuple rules The driver utilizes the ethtool interface for configuring ntuple filters, - via "ethtool -N <device> <filter>". + via ``ethtool -N <device> <filter>``. - To enable or disable the RX flow rules: + To enable or disable the RX flow rules:: - ethtool -K ethX ntuple <on|off> + ethtool -K ethX ntuple <on|off> - When disabling ntuple filters, all the user programed filters are + When disabling ntuple filters, all the user programmed filters are flushed from the driver cache and hardware. All needed filters must be re-added when ntuple is re-enabled. Because of the fixed order of the rules, the location of filters is also fixed: + - Locations 0 - 15 for VLAN ID filters - Locations 16 - 31 for L2 EtherType filters - Locations 32 - 39 for L3/L4 5-tuple filters (locations 32, 36 for IPv6) @@ -253,32 +286,34 @@ Supported ethtool options addresses can be supported. Source and destination ports are only compared for TCP/UDP/SCTP packets. - To add a filter that directs packet to queue 5, use <-N|-U|--config-nfc|--config-ntuple> switch: + To add a filter that directs packet to queue 5, use + ``<-N|-U|--config-nfc|--config-ntuple>`` switch:: - ethtool -N <ethX> flow-type udp4 src-ip 10.0.0.1 dst-ip 10.0.0.2 src-port 2000 dst-port 2001 action 5 <loc 32> + ethtool -N <ethX> flow-type udp4 src-ip 10.0.0.1 dst-ip 10.0.0.2 src-port 2000 dst-port 2001 action 5 <loc 32> - action is the queue number. - loc is the rule number. - For "flow-type ip4|udp4|tcp4|sctp4|ip6|udp6|tcp6|sctp6" you must set the loc + For ``flow-type ip4|udp4|tcp4|sctp4|ip6|udp6|tcp6|sctp6`` you must set the loc number within 32 - 39. - For "flow-type ip4|udp4|tcp4|sctp4|ip6|udp6|tcp6|sctp6" you can set 8 rules + For ``flow-type ip4|udp4|tcp4|sctp4|ip6|udp6|tcp6|sctp6`` you can set 8 rules for traffic IPv4 or you can set 2 rules for traffic IPv6. Loc number traffic IPv6 is 32 and 36. At the moment you can not use IPv4 and IPv6 filters at the same time. - Example filter for IPv6 filter traffic: + Example filter for IPv6 filter traffic:: - sudo ethtool -N <ethX> flow-type tcp6 src-ip 2001:db8:0:f101::1 dst-ip 2001:db8:0:f101::2 action 1 loc 32 - sudo ethtool -N <ethX> flow-type ip6 src-ip 2001:db8:0:f101::2 dst-ip 2001:db8:0:f101::5 action -1 loc 36 + sudo ethtool -N <ethX> flow-type tcp6 src-ip 2001:db8:0:f101::1 dst-ip 2001:db8:0:f101::2 action 1 loc 32 + sudo ethtool -N <ethX> flow-type ip6 src-ip 2001:db8:0:f101::2 dst-ip 2001:db8:0:f101::5 action -1 loc 36 - Example filter for IPv4 filter traffic: + Example filter for IPv4 filter traffic:: - sudo ethtool -N <ethX> flow-type udp4 src-ip 10.0.0.4 dst-ip 10.0.0.7 src-port 2000 dst-port 2001 loc 32 - sudo ethtool -N <ethX> flow-type tcp4 src-ip 10.0.0.3 dst-ip 10.0.0.9 src-port 2000 dst-port 2001 loc 33 - sudo ethtool -N <ethX> flow-type ip4 src-ip 10.0.0.6 dst-ip 10.0.0.4 loc 34 + sudo ethtool -N <ethX> flow-type udp4 src-ip 10.0.0.4 dst-ip 10.0.0.7 src-port 2000 dst-port 2001 loc 32 + sudo ethtool -N <ethX> flow-type tcp4 src-ip 10.0.0.3 dst-ip 10.0.0.9 src-port 2000 dst-port 2001 loc 33 + sudo ethtool -N <ethX> flow-type ip4 src-ip 10.0.0.6 dst-ip 10.0.0.4 loc 34 If you set action -1, then all traffic corresponding to the filter will be discarded. + The maximum value action is 31. @@ -287,8 +322,9 @@ Supported ethtool options from L2 Ethertype filter with UserPriority since both User Priority and VLAN ID are passed in the same 'vlan' parameter. - To add a filter that directs packets from VLAN 2001 to queue 5: - ethtool -N <ethX> flow-type ip4 vlan 2001 m 0xF000 action 1 loc 0 + To add a filter that directs packets from VLAN 2001 to queue 5:: + + ethtool -N <ethX> flow-type ip4 vlan 2001 m 0xF000 action 1 loc 0 L2 EtherType filters allows filter packet by EtherType field or both EtherType @@ -297,17 +333,17 @@ Supported ethtool options distinguish VLAN filter from L2 Ethertype filter with UserPriority since both User Priority and VLAN ID are passed in the same 'vlan' parameter. - To add a filter that directs IP4 packess of priority 3 to queue 3: - ethtool -N <ethX> flow-type ether proto 0x800 vlan 0x600 m 0x1FFF action 3 loc 16 + To add a filter that directs IP4 packess of priority 3 to queue 3:: + ethtool -N <ethX> flow-type ether proto 0x800 vlan 0x600 m 0x1FFF action 3 loc 16 - To see the list of filters currently present: + To see the list of filters currently present:: - ethtool <-u|-n|--show-nfc|--show-ntuple> <ethX> + ethtool <-u|-n|--show-nfc|--show-ntuple> <ethX> - Rules may be deleted from the table itself. This is done using: + Rules may be deleted from the table itself. This is done using:: - sudo ethtool <-N|-U|--config-nfc|--config-ntuple> <ethX> delete <loc> + sudo ethtool <-N|-U|--config-nfc|--config-ntuple> <ethX> delete <loc> - loc is the rule number to be deleted. @@ -316,34 +352,37 @@ Supported ethtool options case, any flow that matches the filter criteria will be directed to the appropriate queue. RX filters is supported on all kernels 2.6.30 and later. - RSS for UDP - --------------------------------- +RSS for UDP +----------- + Currently, NIC does not support RSS for fragmented IP packets, which leads to incorrect working of RSS for fragmented UDP traffic. To disable RSS for UDP the RX Flow L3/L4 rule may be used. - Example: - ethtool -N eth0 flow-type udp4 action 0 loc 32 + Example:: + + ethtool -N eth0 flow-type udp4 action 0 loc 32 + +UDP GSO hardware offload +------------------------ - UDP GSO hardware offload - --------------------------------- UDP GSO allows to boost UDP tx rates by offloading UDP headers allocation into hardware. A special userspace socket option is required for this, - could be validated with /kernel/tools/testing/selftests/net/ + could be validated with /kernel/tools/testing/selftests/net/:: udpgso_bench_tx -u -4 -D 10.0.1.1 -s 6300 -S 100 Will cause sending out of 100 byte sized UDP packets formed from single 6300 bytes user buffer. - UDP GSO is configured by: + UDP GSO is configured by:: ethtool -K eth0 tx-udp-segmentation on - Private flags (testing) - --------------------------------- +Private flags (testing) +----------------------- - Atlantic driver supports private flags for hardware custom features: + Atlantic driver supports private flags for hardware custom features:: $ ethtool --show-priv-flags ethX @@ -354,7 +393,7 @@ Supported ethtool options PHYInternalLoopback: off PHYExternalLoopback: off - Example: + Example:: $ ethtool --set-priv-flags ethX DMASystemLoopback on @@ -370,93 +409,130 @@ Command Line Parameters The following command line parameters are available on atlantic driver: aq_itr -Interrupt throttling mode ----------------------------------------- +--------------------------------- Accepted values: 0, 1, 0xFFFF + Default value: 0xFFFF -0 - Disable interrupt throttling. -1 - Enable interrupt throttling and use specified tx and rx rates. -0xFFFF - Auto throttling mode. Driver will choose the best RX and TX - interrupt throtting settings based on link speed. + +====== ============================================================== +0 Disable interrupt throttling. +1 Enable interrupt throttling and use specified tx and rx rates. +0xFFFF Auto throttling mode. Driver will choose the best RX and TX + interrupt throttling settings based on link speed. +====== ============================================================== aq_itr_tx - TX interrupt throttle rate ----------------------------------------- +-------------------------------------- + Accepted values: 0 - 0x1FF + Default value: 0 + TX side throttling in microseconds. Adapter will setup maximum interrupt delay to this value. Minimum interrupt delay will be a half of this value aq_itr_rx - RX interrupt throttle rate ----------------------------------------- +-------------------------------------- + Accepted values: 0 - 0x1FF + Default value: 0 + RX side throttling in microseconds. Adapter will setup maximum interrupt delay to this value. Minimum interrupt delay will be a half of this value -Note: ITR settings could be changed in runtime by ethtool -c means (see below) +.. note:: + + ITR settings could be changed in runtime by ethtool -c means (see below) Config file parameters -======================= +====================== + For some fine tuning and performance optimizations, some parameters can be changed in the {source_dir}/aq_cfg.h file. AQ_CFG_RX_PAGEORDER ----------------------------------------- +------------------- + Default value: 0 -RX page order override. Thats a power of 2 number of RX pages allocated for -each descriptor. Received descriptor size is still limited by AQ_CFG_RX_FRAME_MAX. + +RX page order override. That's a power of 2 number of RX pages allocated for +each descriptor. Received descriptor size is still limited by +AQ_CFG_RX_FRAME_MAX. + Increasing pageorder makes page reuse better (actual on iommu enabled systems). AQ_CFG_RX_REFILL_THRES ----------------------------------------- +---------------------- + Default value: 32 + RX refill threshold. RX path will not refill freed descriptors until the specified number of free descriptors is observed. Larger values may help better page reuse but may lead to packet drops as well. AQ_CFG_VECS_DEF ------------------------------------------------------------- +--------------- + Number of queues + Valid Range: 0 - 8 (up to AQ_CFG_VECS_MAX) + Default value: 8 + Notice this value will be capped by the number of cores available on the system. AQ_CFG_IS_RSS_DEF ------------------------------------------------------------- +----------------- + Enable/disable Receive Side Scaling This feature allows the adapter to distribute receive processing across multiple CPU-cores and to prevent from overloading a single CPU core. Valid values -0 - disabled -1 - enabled + +== ======== +0 disabled +1 enabled +== ======== Default value: 1 AQ_CFG_NUM_RSS_QUEUES_DEF ------------------------------------------------------------- +------------------------- + Number of queues for Receive Side Scaling + Valid Range: 0 - 8 (up to AQ_CFG_VECS_DEF) Default value: AQ_CFG_VECS_DEF AQ_CFG_IS_LRO_DEF ------------------------------------------------------------- +----------------- + Enable/disable Large Receive Offload This offload enables the adapter to coalesce multiple TCP segments and indicate them as a single coalesced unit to the OS networking subsystem. -The system consumes less energy but it also introduces more latency in packets processing. + +The system consumes less energy but it also introduces more latency in packets +processing. Valid values -0 - disabled -1 - enabled + +== ======== +0 disabled +1 enabled +== ======== Default value: 1 AQ_CFG_TX_CLEAN_BUDGET ----------------------------------------- +---------------------- + Maximum descriptors to cleanup on TX at once. + Default value: 256 After the aq_cfg.h file changed the driver must be rebuilt to take effect. @@ -472,7 +548,8 @@ License ======= aQuantia Corporation Network Driver -Copyright(c) 2014 - 2019 aQuantia Corporation. + +Copyright |copy| 2014 - 2019 aQuantia Corporation. This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, diff --git a/Documentation/networking/device_drivers/chelsio/cxgb.txt b/Documentation/networking/device_drivers/ethernet/chelsio/cxgb.rst index 20a887615c4a..435dce5fa2c7 100644 --- a/Documentation/networking/device_drivers/chelsio/cxgb.txt +++ b/Documentation/networking/device_drivers/ethernet/chelsio/cxgb.rst @@ -1,13 +1,18 @@ - Chelsio N210 10Gb Ethernet Network Controller +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> - Driver Release Notes for Linux +============================================= +Chelsio N210 10Gb Ethernet Network Controller +============================================= - Version 2.1.1 +Driver Release Notes for Linux - June 20, 2005 +Version 2.1.1 + +June 20, 2005 + +.. Contents -CONTENTS -======== INTRODUCTION FEATURES PERFORMANCE @@ -16,7 +21,7 @@ CONTENTS SUPPORT -INTRODUCTION +Introduction ============ This document describes the Linux driver for Chelsio 10Gb Ethernet Network @@ -24,11 +29,11 @@ INTRODUCTION compatible with the Chelsio N110 model 10Gb NICs. -FEATURES +Features ======== - Adaptive Interrupts (adaptive-rx) - --------------------------------- +Adaptive Interrupts (adaptive-rx) +--------------------------------- This feature provides an adaptive algorithm that adjusts the interrupt coalescing parameters, allowing the driver to dynamically adapt the latency @@ -39,24 +44,24 @@ FEATURES ethtool manpage for additional usage information. By default, adaptive-rx is disabled. - To enable adaptive-rx: + To enable adaptive-rx:: ethtool -C <interface> adaptive-rx on - To disable adaptive-rx, use ethtool: + To disable adaptive-rx, use ethtool:: ethtool -C <interface> adaptive-rx off After disabling adaptive-rx, the timer latency value will be set to 50us. - You may set the timer latency after disabling adaptive-rx: + You may set the timer latency after disabling adaptive-rx:: ethtool -C <interface> rx-usecs <microseconds> - An example to set the timer latency value to 100us on eth0: + An example to set the timer latency value to 100us on eth0:: ethtool -C eth0 rx-usecs 100 - You may also provide a timer latency value while disabling adaptive-rx: + You may also provide a timer latency value while disabling adaptive-rx:: ethtool -C <interface> adaptive-rx off rx-usecs <microseconds> @@ -64,13 +69,13 @@ FEATURES will be set to the specified value until changed by the user or until adaptive-rx is enabled. - To view the status of the adaptive-rx and timer latency values: + To view the status of the adaptive-rx and timer latency values:: ethtool -c <interface> - TCP Segmentation Offloading (TSO) Support - ----------------------------------------- +TCP Segmentation Offloading (TSO) Support +----------------------------------------- This feature, also known as "large send", enables a system's protocol stack to offload portions of outbound TCP processing to a network interface card @@ -80,20 +85,20 @@ FEATURES Please see the ethtool manpage for additional usage information. By default, TSO is enabled. - To disable TSO: + To disable TSO:: ethtool -K <interface> tso off - To enable TSO: + To enable TSO:: ethtool -K <interface> tso on - To view the status of TSO: + To view the status of TSO:: ethtool -k <interface> -PERFORMANCE +Performance =========== The following information is provided as an example of how to change system @@ -111,59 +116,81 @@ PERFORMANCE your system. You may want to write a script that runs at boot-up which includes the optimal settings for your system. - Setting PCI Latency Timer: - setpci -d 1425:* 0x0c.l=0x0000F800 + Setting PCI Latency Timer:: + + setpci -d 1425:: + +* 0x0c.l=0x0000F800 + + Disabling TCP timestamp:: - Disabling TCP timestamp: sysctl -w net.ipv4.tcp_timestamps=0 - Disabling SACK: + Disabling SACK:: + sysctl -w net.ipv4.tcp_sack=0 - Setting large number of incoming connection requests: + Setting large number of incoming connection requests:: + sysctl -w net.ipv4.tcp_max_syn_backlog=3000 - Setting maximum receive socket buffer size: + Setting maximum receive socket buffer size:: + sysctl -w net.core.rmem_max=1024000 - Setting maximum send socket buffer size: + Setting maximum send socket buffer size:: + sysctl -w net.core.wmem_max=1024000 - Set smp_affinity (on a multiprocessor system) to a single CPU: + Set smp_affinity (on a multiprocessor system) to a single CPU:: + echo 1 > /proc/irq/<interrupt_number>/smp_affinity - Setting default receive socket buffer size: + Setting default receive socket buffer size:: + sysctl -w net.core.rmem_default=524287 - Setting default send socket buffer size: + Setting default send socket buffer size:: + sysctl -w net.core.wmem_default=524287 - Setting maximum option memory buffers: + Setting maximum option memory buffers:: + sysctl -w net.core.optmem_max=524287 - Setting maximum backlog (# of unprocessed packets before kernel drops): + Setting maximum backlog (# of unprocessed packets before kernel drops):: + sysctl -w net.core.netdev_max_backlog=300000 - Setting TCP read buffers (min/default/max): + Setting TCP read buffers (min/default/max):: + sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000" - Setting TCP write buffers (min/pressure/max): + Setting TCP write buffers (min/pressure/max):: + sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000" - Setting TCP buffer space (min/pressure/max): + Setting TCP buffer space (min/pressure/max):: + sysctl -w net.ipv4.tcp_mem="10000000 10000000 10000000" TCP window size for single connections: + The receive buffer (RX_WINDOW) size must be at least as large as the Bandwidth-Delay Product of the communication link between the sender and receiver. Due to the variations of RTT, you may want to increase the buffer size up to 2 times the Bandwidth-Delay Product. Reference page 289 of "TCP/IP Illustrated, Volume 1, The Protocols" by W. Richard Stevens. - At 10Gb speeds, use the following formula: + + At 10Gb speeds, use the following formula:: + RX_WINDOW >= 1.25MBytes * RTT(in milliseconds) Example for RTT with 100us: RX_WINDOW = (1,250,000 * 0.1) = 125,000 + RX_WINDOW sizes of 256KB - 512KB should be sufficient. - Setting the min, max, and default receive buffer (RX_WINDOW) size: + + Setting the min, max, and default receive buffer (RX_WINDOW) size:: + sysctl -w net.ipv4.tcp_rmem="<min> <default> <max>" TCP window size for multiple connections: @@ -174,30 +201,35 @@ PERFORMANCE not supported on the machine. Experimentation may be necessary to attain the correct value. This method is provided as a starting point for the correct receive buffer size. + Setting the min, max, and default receive buffer (RX_WINDOW) size is performed in the same manner as single connection. -DRIVER MESSAGES +Driver Messages =============== The following messages are the most common messages logged by syslog. These may be found in /var/log/messages. - Driver up: + Driver up:: + Chelsio Network Driver - version 2.1.1 - NIC detected: + NIC detected:: + eth#: Chelsio N210 1x10GBaseX NIC (rev #), PCIX 133MHz/64-bit - Link up: + Link up:: + eth#: link is up at 10 Gbps, full duplex - Link down: + Link down:: + eth#: link is down -KNOWN ISSUES +Known Issues ============ These issues have been identified during testing. The following information @@ -214,27 +246,33 @@ KNOWN ISSUES To eliminate the TCP retransmits, set smp_affinity on the particular interrupt to a single CPU. You can locate the interrupt (IRQ) used on - the N110/N210 by using ifconfig: - ifconfig <dev_name> | grep Interrupt - Set the smp_affinity to a single CPU: - echo 1 > /proc/irq/<interrupt_number>/smp_affinity + the N110/N210 by using ifconfig:: + + ifconfig <dev_name> | grep Interrupt + + Set the smp_affinity to a single CPU:: + + echo 1 > /proc/irq/<interrupt_number>/smp_affinity It is highly suggested that you do not run the irqbalance daemon on your system, as this will change any smp_affinity setting you have applied. The irqbalance daemon runs on a 10 second interval and binds interrupts - to the least loaded CPU determined by the daemon. To disable this daemon: - chkconfig --level 2345 irqbalance off + to the least loaded CPU determined by the daemon. To disable this daemon:: + + chkconfig --level 2345 irqbalance off By default, some Linux distributions enable the kernel feature, irqbalance, which performs the same function as the daemon. To disable - this feature, add the following line to your bootloader: - noirqbalance + this feature, add the following line to your bootloader:: + + noirqbalance + + Example using the Grub bootloader:: - Example using the Grub bootloader: - title Red Hat Enterprise Linux AS (2.4.21-27.ELsmp) - root (hd0,0) - kernel /vmlinuz-2.4.21-27.ELsmp ro root=/dev/hda3 noirqbalance - initrd /initrd-2.4.21-27.ELsmp.img + title Red Hat Enterprise Linux AS (2.4.21-27.ELsmp) + root (hd0,0) + kernel /vmlinuz-2.4.21-27.ELsmp ro root=/dev/hda3 noirqbalance + initrd /initrd-2.4.21-27.ELsmp.img 2. After running insmod, the driver is loaded and the incorrect network interface is brought up without running ifup. @@ -277,12 +315,13 @@ KNOWN ISSUES AMD's provides three workarounds for this problem, however, Chelsio recommends the first option for best performance with this bug: - For 133Mhz secondary bus operation, limit the transaction length and - the number of outstanding transactions, via BIOS configuration - programming of the PCI-X card, to the following: + For 133Mhz secondary bus operation, limit the transaction length and + the number of outstanding transactions, via BIOS configuration + programming of the PCI-X card, to the following: - Data Length (bytes): 1k - Total allowed outstanding transactions: 2 + Data Length (bytes): 1k + + Total allowed outstanding transactions: 2 Please refer to AMD 8131-HT/PCI-X Errata 26310 Rev 3.08 August 2004, section 56, "133-MHz Mode Split Completion Data Corruption" for more @@ -293,8 +332,10 @@ KNOWN ISSUES have issues with these settings, please revert to the "safe" settings and duplicate the problem before submitting a bug or asking for support. - NOTE: The default setting on most systems is 8 outstanding transactions - and 2k bytes data length. + .. note:: + + The default setting on most systems is 8 outstanding transactions + and 2k bytes data length. 4. On multiprocessor systems, it has been noted that an application which is handling 10Gb networking can switch between CPUs causing degraded @@ -320,14 +361,16 @@ KNOWN ISSUES particular CPU: runon 0 ifup eth0 -SUPPORT +Support ======= If you have problems with the software or hardware, please contact our customer support team via email at support@chelsio.com or check our website at http://www.chelsio.com -=============================================================================== +------------------------------------------------------------------------------- + +:: Chelsio Communications 370 San Aleso Ave. @@ -343,10 +386,8 @@ You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. -THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED +THIS SOFTWARE IS PROVIDED ``AS IS`` AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. - Copyright (c) 2003-2005 Chelsio Communications. All rights reserved. - -=============================================================================== +Copyright |copy| 2003-2005 Chelsio Communications. All rights reserved. diff --git a/Documentation/networking/device_drivers/cirrus/cs89x0.txt b/Documentation/networking/device_drivers/ethernet/cirrus/cs89x0.rst index 0e190180eec8..e5c283940ac5 100644 --- a/Documentation/networking/device_drivers/cirrus/cs89x0.txt +++ b/Documentation/networking/device_drivers/ethernet/cirrus/cs89x0.rst @@ -1,79 +1,84 @@ +.. SPDX-License-Identifier: GPL-2.0 -NOTE ----- +================================================ +Cirrus Logic LAN CS8900/CS8920 Ethernet Adapters +================================================ -This document was contributed by Cirrus Logic for kernel 2.2.5. This version -has been updated for 2.3.48 by Andrew Morton. +.. 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. - -CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS 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.0 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 + + +.. 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 +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 @@ -85,22 +90,25 @@ or loaded at run-time as a device driver module. 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. + =================== ==================================================== + 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 +1.3. System Requirements +------------------------ The following hardware is required: - * Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter + * Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter * IBM or IBM-compatible PC with: * An 80386 or higher processor @@ -118,20 +126,21 @@ The following software is required: * 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) + * GNU Toolkit (gcc and make) v2.6 or above (if compiling into kernel + or a module) -1.4 LICENSING INFORMATION +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 +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 @@ -139,28 +148,29 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -2.0 ADAPTER INSTALLATION and CONFIGURATION -=============================================================================== +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. +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 +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 +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: +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 @@ -169,15 +179,16 @@ with the following "default" settings: Optimization: DOS Client Transmission Mode: Half-duplex BootProm: None - Media Type: Autodetect (3-media cards) or - 10BASE-T (10BASE-T only adapter) + 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. +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 +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 @@ -185,82 +196,83 @@ 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. +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. * - **************************************************************** + **************************************************************** + * 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.0 LOADING THE DRIVER AS A MODULE -=============================================================================== +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 +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: +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 +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 + 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) + debug=# - debug level (only available if the driver was compiled + for debugging) -NOTES: +**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. +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 + 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. + 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 + io + irq media type (no autodetect) f) The following additional parameters are CS89XX defaults (values @@ -282,13 +294,13 @@ h) Many Linux distributions use the 'modprobe' command to load module when it is loaded. All the configuration options which are described above may be placed within /etc/conf.modules. - For example: + For example:: - > cat /etc/conf.modules - ... - alias eth0 cs89x0 - options cs89x0 io=0x0200 dma=5 use_dma=1 - ... + > 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 @@ -305,9 +317,9 @@ j) The cs89x0 supports DMA for receiving only. DMA mode is 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 + with the command:: - cat /proc/isapnp + 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. @@ -321,11 +333,11 @@ 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: + 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: + or they may be placed in /etc/lilo.conf:: image=/boot/bzImage-2.3.48 append="cs89x0_dma=5" @@ -337,237 +349,246 @@ n) If the cs89x0 driver is compiled directly into the kernel, DMA (64k mode is not available). -4.0 COMPILING THE DRIVER -=============================================================================== +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 AS A LOADABLE MODULE - -To compile the driver into a loadable module, use the following command -(single command line, without quotes): - -"gcc -D__KERNEL__ -I/usr/src/linux/include -I/usr/src/linux/net/inet -Wall --Wstrict-prototypes -O2 -fomit-frame-pointer -DMODULE -DCONFIG_MODVERSIONS --c cs89x0.c" - -4.2 COMPILING THE DRIVER TO SUPPORT MEMORY MODE - -Support for memory mode was not carried over into the 2.3 series kernels. -4.3 COMPILING THE DRIVER TO SUPPORT Rx DMA +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.0 TESTING AND TROUBLESHOOTING -=============================================================================== +5. Testing and Troubleshooting +============================== -5.1 KNOWN DEFECTS and LIMITATIONS +5.1. Known Defects and Limitations +---------------------------------- -Refer to the RELEASE.TXT file distributed as part of this archive for a list of +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 +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 +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 +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. +.. 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. + 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 + 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. + 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 +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 +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 + + 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 + + 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 + + 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 +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 +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.) +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 +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 +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. + 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. + 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. - 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 +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. +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 +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 +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 +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 +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). + 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. + 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. + 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. + 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 +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 +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 +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 +:: + 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.0 TECHNICAL SUPPORT -=============================================================================== -6.1 CONTACTING CIRRUS LOGIC'S TECHNICAL SUPPORT +6. Technical Support +==================== -Cirrus Logic's CS89XX Technical Application Support can be reached at: +6.1. Contacting Cirrus Logic's Technical Support +------------------------------------------------ -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 +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. +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.) @@ -575,7 +596,7 @@ Much of the following information as possible. * 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). + * Configured for media auto-detect or specific media type (which type). 3.) PC System's Configuration @@ -590,35 +611,37 @@ Much of the following information as possible. * CS89XX driver and version * Your network operating system and version - * Your system's OS version + * Your system's OS version * Version of all protocol support files 5.) Any Error Message displayed. -6.3 OBTAINING THE LATEST DRIVER VERSION +6.3 Obtaining the Latest Driver Version +--------------------------------------- -You can obtain the latest CS89XX drivers and support software from Cirrus Logic's +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 +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 +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: +parameter ``cs89x0_media=`` has been implemented. Usage is:: cs89x0_media=rj45 or cs89x0_media=aui or cs89x0_media=bnc - diff --git a/Documentation/networking/device_drivers/davicom/dm9000.txt b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst index 5552e2e575c5..14eb0a4d4e4e 100644 --- a/Documentation/networking/device_drivers/davicom/dm9000.txt +++ b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst @@ -1,7 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== DM9000 Network driver ===================== Copyright 2008 Simtec Electronics, + Ben Dooks <ben@simtec.co.uk> <ben-linux@fluff.org> @@ -30,9 +34,9 @@ These resources should be specified in that order, as the ordering of the two address regions is important (the driver expects these to be address and then data). -An example from arch/arm/mach-s3c2410/mach-bast.c is: +An example from arch/arm/mach-s3c/mach-bast.c is:: -static struct resource bast_dm9k_resource[] = { + static struct resource bast_dm9k_resource[] = { [0] = { .start = S3C2410_CS5 + BAST_PA_DM9000, .end = S3C2410_CS5 + BAST_PA_DM9000 + 3, @@ -48,14 +52,14 @@ static struct resource bast_dm9k_resource[] = { .end = IRQ_DM9000, .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL, } -}; + }; -static struct platform_device bast_device_dm9k = { + static struct platform_device bast_device_dm9k = { .name = "dm9000", .id = 0, .num_resources = ARRAY_SIZE(bast_dm9k_resource), .resource = bast_dm9k_resource, -}; + }; Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags, as this will generate a warning if it is not present. The trigger from @@ -64,13 +68,13 @@ handler to ensure that the IRQ is setup correctly. This shows a typical platform device, without the optional configuration platform data supplied. The next example uses the same resources, but adds -the optional platform data to pass extra configuration data: +the optional platform data to pass extra configuration data:: -static struct dm9000_plat_data bast_dm9k_platdata = { + static struct dm9000_plat_data bast_dm9k_platdata = { .flags = DM9000_PLATF_16BITONLY, -}; + }; -static struct platform_device bast_device_dm9k = { + static struct platform_device bast_device_dm9k = { .name = "dm9000", .id = 0, .num_resources = ARRAY_SIZE(bast_dm9k_resource), @@ -78,7 +82,7 @@ static struct platform_device bast_device_dm9k = { .dev = { .platform_data = &bast_dm9k_platdata, } -}; + }; The platform data is defined in include/linux/dm9000.h and described below. diff --git a/Documentation/networking/device_drivers/dec/dmfe.txt b/Documentation/networking/device_drivers/ethernet/dec/dmfe.rst index 25320bf19c86..c4cf809cad84 100644 --- a/Documentation/networking/device_drivers/dec/dmfe.txt +++ b/Documentation/networking/device_drivers/ethernet/dec/dmfe.rst @@ -1,6 +1,11 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================== +Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux +============================================================== + Note: This driver doesn't have a maintainer. -Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License @@ -16,29 +21,29 @@ GNU General Public License for more details. This driver provides kernel support for Davicom DM9102(A)/DM9132/DM9801 ethernet cards ( CNET 10/100 ethernet cards uses Davicom chipset too, so this driver supports CNET cards too ).If you didn't compile this driver as a module, it will automatically load itself on boot and print a -line similar to : +line similar to:: dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17) -If you compiled this driver as a module, you have to load it on boot.You can load it with command : +If you compiled this driver as a module, you have to load it on boot.You can load it with command:: insmod dmfe This way it will autodetect the device mode.This is the suggested way to load the module.Or you can pass -a mode= setting to module while loading, like : +a mode= setting to module while loading, like:: insmod dmfe mode=0 # Force 10M Half Duplex insmod dmfe mode=1 # Force 100M Half Duplex insmod dmfe mode=4 # Force 10M Full Duplex insmod dmfe mode=5 # Force 100M Full Duplex -Next you should configure your network interface with a command similar to : +Next you should configure your network interface with a command similar to:: ifconfig eth0 172.22.3.18 - ^^^^^^^^^^^ + ^^^^^^^^^^^ Your IP Address -Then you may have to modify the default routing table with command : +Then you may have to modify the default routing table with command:: route add default eth0 @@ -48,10 +53,10 @@ Now your ethernet card should be up and running. TODO: -Implement pci_driver::suspend() and pci_driver::resume() power management methods. -Check on 64 bit boxes. -Check and fix on big endian boxes. -Test and make sure PCI latency is now correct for all cases. +- Implement pci_driver::suspend() and pci_driver::resume() power management methods. +- Check on 64 bit boxes. +- Check and fix on big endian boxes. +- Test and make sure PCI latency is now correct for all cases. Authors: @@ -60,7 +65,7 @@ Sten Wang <sten_wang@davicom.com.tw > : Original Author Contributors: -Marcelo Tosatti <marcelo@conectiva.com.br> -Alan Cox <alan@lxorguk.ukuu.org.uk> -Jeff Garzik <jgarzik@pobox.com> -Vojtech Pavlik <vojtech@suse.cz> +- Marcelo Tosatti <marcelo@conectiva.com.br> +- Alan Cox <alan@lxorguk.ukuu.org.uk> +- Jeff Garzik <jgarzik@pobox.com> +- Vojtech Pavlik <vojtech@suse.cz> diff --git a/Documentation/networking/device_drivers/dlink/dl2k.txt b/Documentation/networking/device_drivers/ethernet/dlink/dl2k.rst index cba74f7a3abc..ccdb5d0d7460 100644 --- a/Documentation/networking/device_drivers/dlink/dl2k.txt +++ b/Documentation/networking/device_drivers/ethernet/dlink/dl2k.rst @@ -1,10 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 - D-Link DL2000-based Gigabit Ethernet Adapter Installation - for Linux - May 23, 2002 +========================================================= +D-Link DL2000-based Gigabit Ethernet Adapter Installation +========================================================= + +May 23, 2002 + +.. Contents -Contents -======== - Compatibility List - Quick Install - Compiling the Driver @@ -15,12 +18,13 @@ Contents Compatibility List -================= +================== + Adapter Support: -D-Link DGE-550T Gigabit Ethernet Adapter. -D-Link DGE-550SX Gigabit Ethernet Adapter. -D-Link DL2000-based Gigabit Ethernet Adapter. +- D-Link DGE-550T Gigabit Ethernet Adapter. +- D-Link DGE-550SX Gigabit Ethernet Adapter. +- D-Link DL2000-based Gigabit Ethernet Adapter. The driver support Linux kernel 2.4.7 later. We had tested it @@ -34,28 +38,32 @@ on the environments below. Quick Install ============= -Install linux driver as following command: +Install linux driver as following command:: + + 1. make all + 2. insmod dl2k.ko + 3. ifconfig eth0 up 10.xxx.xxx.xxx netmask 255.0.0.0 + ^^^^^^^^^^^^^^^\ ^^^^^^^^\ + IP NETMASK -1. make all -2. insmod dl2k.ko -3. ifconfig eth0 up 10.xxx.xxx.xxx netmask 255.0.0.0 - ^^^^^^^^^^^^^^^\ ^^^^^^^^\ - IP NETMASK Now eth0 should active, you can test it by "ping" or get more information by "ifconfig". If tested ok, continue the next step. -4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net -5. Add the following line to /etc/modprobe.d/dl2k.conf: +4. ``cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net`` +5. Add the following line to /etc/modprobe.d/dl2k.conf:: + alias eth0 dl2k -6. Run depmod to updated module indexes. -7. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0 + +6. Run ``depmod`` to updated module indexes. +7. Run ``netconfig`` or ``netconf`` to create configuration script ifcfg-eth0 located at /etc/sysconfig/network-scripts or create it manually. + [see - Configuration Script Sample] 8. Driver will automatically load and configure at next boot time. Compiling the Driver ==================== - In Linux, NIC drivers are most commonly configured as loadable modules. +In Linux, NIC drivers are most commonly configured as loadable modules. The approach of building a monolithic kernel has become obsolete. The driver can be compiled as part of a monolithic kernel, but is strongly discouraged. The remainder of this section assumes the driver is built as a loadable module. @@ -73,93 +81,108 @@ to compile and link the driver: CD-ROM drive ------------ -[root@XXX /] mkdir cdrom -[root@XXX /] mount -r -t iso9660 -o conv=auto /dev/cdrom /cdrom -[root@XXX /] cd root -[root@XXX /root] mkdir dl2k -[root@XXX /root] cd dl2k -[root@XXX dl2k] cp /cdrom/linux/dl2k.tgz /root/dl2k -[root@XXX dl2k] tar xfvz dl2k.tgz -[root@XXX dl2k] make all +:: + + [root@XXX /] mkdir cdrom + [root@XXX /] mount -r -t iso9660 -o conv=auto /dev/cdrom /cdrom + [root@XXX /] cd root + [root@XXX /root] mkdir dl2k + [root@XXX /root] cd dl2k + [root@XXX dl2k] cp /cdrom/linux/dl2k.tgz /root/dl2k + [root@XXX dl2k] tar xfvz dl2k.tgz + [root@XXX dl2k] make all Floppy disc drive ----------------- -[root@XXX /] cd root -[root@XXX /root] mkdir dl2k -[root@XXX /root] cd dl2k -[root@XXX dl2k] mcopy a:/linux/dl2k.tgz /root/dl2k -[root@XXX dl2k] tar xfvz dl2k.tgz -[root@XXX dl2k] make all +:: + + [root@XXX /] cd root + [root@XXX /root] mkdir dl2k + [root@XXX /root] cd dl2k + [root@XXX dl2k] mcopy a:/linux/dl2k.tgz /root/dl2k + [root@XXX dl2k] tar xfvz dl2k.tgz + [root@XXX dl2k] make all Installing the Driver ===================== - Manual Installation - ------------------- +Manual Installation +------------------- + Once the driver has been compiled, it must be loaded, enabled, and bound to a protocol stack in order to establish network connectivity. To load a - module enter the command: + module enter the command:: + + insmod dl2k.o + + or:: + + insmod dl2k.o <optional parameter> ; add parameter - insmod dl2k.o +--------------------------------------------------------- - or + example:: - insmod dl2k.o <optional parameter> ; add parameter + insmod dl2k.o media=100mbps_hd - =============================================================== - example: insmod dl2k.o media=100mbps_hd - or insmod dl2k.o media=3 - or insmod dl2k.o media=3,2 ; for 2 cards - =============================================================== + or:: + + insmod dl2k.o media=3 + + or:: + + insmod dl2k.o media=3,2 ; for 2 cards + +--------------------------------------------------------- Please reference the list of the command line parameters supported by the Linux device driver below. The insmod command only loads the driver and gives it a name of the form eth0, eth1, etc. To bring the NIC into an operational state, - it is necessary to issue the following command: + it is necessary to issue the following command:: - ifconfig eth0 up + ifconfig eth0 up Finally, to bind the driver to the active protocol (e.g., TCP/IP with - Linux), enter the following command: + Linux), enter the following command:: - ifup eth0 + ifup eth0 Note that this is meaningful only if the system can find a configuration script that contains the necessary network information. A sample will be given in the next paragraph. - The commands to unload a driver are as follows: + The commands to unload a driver are as follows:: - ifdown eth0 - ifconfig eth0 down - rmmod dl2k.o + ifdown eth0 + ifconfig eth0 down + rmmod dl2k.o The following are the commands to list the currently loaded modules and - to see the current network configuration. + to see the current network configuration:: - lsmod - ifconfig + lsmod + ifconfig - Automated Installation - ---------------------- +Automated Installation +---------------------- This section describes how to install the driver such that it is automatically loaded and configured at boot time. The following description is based on a Red Hat 6.0/7.0 distribution, but it can easily be ported to other distributions as well. - Red Hat v6.x/v7.x - ----------------- +Red Hat v6.x/v7.x +----------------- 1. Copy dl2k.o to the network modules directory, typically /lib/modules/2.x.x-xx/net or /lib/modules/2.x.x/kernel/drivers/net. 2. Locate the boot module configuration file, most commonly in the - /etc/modprobe.d/ directory. Add the following lines: + /etc/modprobe.d/ directory. Add the following lines:: - alias ethx dl2k - options dl2k <optional parameters> + alias ethx dl2k + options dl2k <optional parameters> where ethx will be eth0 if the NIC is the only ethernet adapter, eth1 if one other ethernet adapter is installed, etc. Refer to the table in the @@ -180,11 +203,15 @@ parameter. Below is a list of the command line parameters supported by the Linux device driver. -mtu=packet_size - Specifies the maximum packet size. default + +=============================== ============================================== +mtu=packet_size Specifies the maximum packet size. default is 1500. -media=media_type - Specifies the media type the NIC operates at. +media=media_type Specifies the media type the NIC operates at. autosense Autosensing active media. + + =========== ========================= 10mbps_hd 10Mbps half duplex. 10mbps_fd 10Mbps full duplex. 100mbps_hd 100Mbps half duplex. @@ -198,85 +225,90 @@ media=media_type - Specifies the media type the NIC operates at. 4 100Mbps full duplex. 5 1000Mbps half duplex. 6 1000Mbps full duplex. + =========== ========================= By default, the NIC operates at autosense. 1000mbps_fd and 1000mbps_hd types are only available for fiber adapter. -vlan=n - Specifies the VLAN ID. If vlan=0, the +vlan=n Specifies the VLAN ID. If vlan=0, the Virtual Local Area Network (VLAN) function is disable. -jumbo=[0|1] - Specifies the jumbo frame support. If jumbo=1, +jumbo=[0|1] Specifies the jumbo frame support. If jumbo=1, the NIC accept jumbo frames. By default, this function is disabled. Jumbo frame usually improve the performance int gigabit. - This feature need jumbo frame compatible + This feature need jumbo frame compatible remote. - -rx_coalesce=m - Number of rx frame handled each interrupt. -rx_timeout=n - Rx DMA wait time for an interrupt. - If set rx_coalesce > 0, hardware only assert - an interrupt for m frames. Hardware won't + +rx_coalesce=m Number of rx frame handled each interrupt. +rx_timeout=n Rx DMA wait time for an interrupt. + If set rx_coalesce > 0, hardware only assert + an interrupt for m frames. Hardware won't assert rx interrupt until m frames received or - reach timeout of n * 640 nano seconds. - Set proper rx_coalesce and rx_timeout can + reach timeout of n * 640 nano seconds. + Set proper rx_coalesce and rx_timeout can reduce congestion collapse and overload which has been a bottleneck for high speed network. - + For example, rx_coalesce=10 rx_timeout=800. - that is, hardware assert only 1 interrupt - for 10 frames received or timeout of 512 us. + that is, hardware assert only 1 interrupt + for 10 frames received or timeout of 512 us. -tx_coalesce=n - Number of tx frame handled each interrupt. - Set n > 1 can reduce the interrupts +tx_coalesce=n Number of tx frame handled each interrupt. + Set n > 1 can reduce the interrupts congestion usually lower performance of high speed network card. Default is 16. - -tx_flow=[1|0] - Specifies the Tx flow control. If tx_flow=0, + +tx_flow=[1|0] Specifies the Tx flow control. If tx_flow=0, the Tx flow control disable else driver autodetect. -rx_flow=[1|0] - Specifies the Rx flow control. If rx_flow=0, +rx_flow=[1|0] Specifies the Rx flow control. If rx_flow=0, the Rx flow control enable else driver autodetect. +=============================== ============================================== Configuration Script Sample =========================== -Here is a sample of a simple configuration script: +Here is a sample of a simple configuration script:: -DEVICE=eth0 -USERCTL=no -ONBOOT=yes -POOTPROTO=none -BROADCAST=207.200.5.255 -NETWORK=207.200.5.0 -NETMASK=255.255.255.0 -IPADDR=207.200.5.2 + DEVICE=eth0 + USERCTL=no + ONBOOT=yes + POOTPROTO=none + BROADCAST=207.200.5.255 + NETWORK=207.200.5.0 + NETMASK=255.255.255.0 + IPADDR=207.200.5.2 Troubleshooting =============== Q1. Source files contain ^ M behind every line. - Make sure all files are Unix file format (no LF). Try the following - shell command to convert files. + + Make sure all files are Unix file format (no LF). Try the following + shell command to convert files:: cat dl2k.c | col -b > dl2k.tmp mv dl2k.tmp dl2k.c - OR + OR:: cat dl2k.c | tr -d "\r" > dl2k.tmp mv dl2k.tmp dl2k.c -Q2: Could not find header files (*.h) ? - To compile the driver, you need kernel header files. After +Q2: Could not find header files (``*.h``)? + + To compile the driver, you need kernel header files. After installing the kernel source, the header files are usually located in /usr/src/linux/include, which is the default include directory configured in Makefile. For some distributions, there is a copy of header files in /usr/src/include/linux and /usr/src/include/asm, that you can change the INCLUDEDIR in Makefile to /usr/include without installing kernel source. - Note that RH 7.0 didn't provide correct header files in /usr/include, + + Note that RH 7.0 didn't provide correct header files in /usr/include, including those files will make a wrong version driver. diff --git a/Documentation/networking/device_drivers/freescale/dpaa.txt b/Documentation/networking/device_drivers/ethernet/freescale/dpaa.rst index b06601ff9200..241c6c6f6e68 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa.txt +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa.rst @@ -1,12 +1,14 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== The QorIQ DPAA Ethernet Driver ============================== Authors: -Madalin Bucur <madalin.bucur@nxp.com> -Camelia Groza <camelia.groza@nxp.com> +- Madalin Bucur <madalin.bucur@nxp.com> +- Camelia Groza <camelia.groza@nxp.com> -Contents -======== +.. Contents - DPAA Ethernet Overview - DPAA Ethernet Supported SoCs @@ -34,7 +36,7 @@ following drivers in the Linux kernel: - Queue Manager (QMan), Buffer Manager (BMan) drivers/soc/fsl/qbman -A simplified view of the dpaa_eth interfaces mapped to FMan MACs: +A simplified view of the dpaa_eth interfaces mapped to FMan MACs:: dpaa_eth /eth0\ ... /ethN\ driver | | | | @@ -42,89 +44,93 @@ A simplified view of the dpaa_eth interfaces mapped to FMan MACs: -Ports / Tx Rx \ ... / Tx Rx \ FMan | | | | -MACs | MAC0 | | MACN | - / dtsec0 \ ... / dtsecN \ (or tgec) - / \ / \(or memac) + / dtsec0 \ ... / dtsecN \ (or tgec) + / \ / \(or memac) --------- -------------- --- -------------- --------- FMan, FMan Port, FMan SP, FMan MURAM drivers --------------------------------------------------------- FMan HW blocks: MURAM, MACs, Ports, SP --------------------------------------------------------- -The dpaa_eth relation to the QMan, BMan and FMan: - ________________________________ +The dpaa_eth relation to the QMan, BMan and FMan:: + + ________________________________ dpaa_eth / eth0 \ driver / \ --------- -^- -^- -^- --- --------- QMan driver / \ / \ / \ \ / | BMan | - |Rx | |Rx | |Tx | |Tx | | driver | + |Rx | |Rx | |Tx | |Tx | | driver | --------- |Dfl| |Err| |Cnf| |FQs| | | QMan HW |FQ | |FQ | |FQs| | | | | - / \ / \ / \ \ / | | + / \ / \ / \ \ / | | --------- --- --- --- -v- --------- - | FMan QMI | | - | FMan HW FMan BMI | BMan HW | - ----------------------- -------- + | FMan QMI | | + | FMan HW FMan BMI | BMan HW | + ----------------------- -------- where the acronyms used above (and in the code) are: -DPAA = Data Path Acceleration Architecture -FMan = DPAA Frame Manager -QMan = DPAA Queue Manager -BMan = DPAA Buffers Manager -QMI = QMan interface in FMan -BMI = BMan interface in FMan -FMan SP = FMan Storage Profiles -MURAM = Multi-user RAM in FMan -FQ = QMan Frame Queue -Rx Dfl FQ = default reception FQ -Rx Err FQ = Rx error frames FQ -Tx Cnf FQ = Tx confirmation FQs -Tx FQs = transmission frame queues -dtsec = datapath three speed Ethernet controller (10/100/1000 Mbps) -tgec = ten gigabit Ethernet controller (10 Gbps) -memac = multirate Ethernet MAC (10/100/1000/10000) + +=============== =========================================================== +DPAA Data Path Acceleration Architecture +FMan DPAA Frame Manager +QMan DPAA Queue Manager +BMan DPAA Buffers Manager +QMI QMan interface in FMan +BMI BMan interface in FMan +FMan SP FMan Storage Profiles +MURAM Multi-user RAM in FMan +FQ QMan Frame Queue +Rx Dfl FQ default reception FQ +Rx Err FQ Rx error frames FQ +Tx Cnf FQ Tx confirmation FQs +Tx FQs transmission frame queues +dtsec datapath three speed Ethernet controller (10/100/1000 Mbps) +tgec ten gigabit Ethernet controller (10 Gbps) +memac multirate Ethernet MAC (10/100/1000/10000) +=============== =========================================================== DPAA Ethernet Supported SoCs ============================ The DPAA drivers enable the Ethernet controllers present on the following SoCs: -# PPC -P1023 -P2041 -P3041 -P4080 -P5020 -P5040 -T1023 -T1024 -T1040 -T1042 -T2080 -T4240 -B4860 - -# ARM -LS1043A -LS1046A +PPC +- P1023 +- P2041 +- P3041 +- P4080 +- P5020 +- P5040 +- T1023 +- T1024 +- T1040 +- T1042 +- T2080 +- T4240 +- B4860 + +ARM +- LS1043A +- LS1046A Configuring DPAA Ethernet in your kernel ======================================== -To enable the DPAA Ethernet driver, the following Kconfig options are required: +To enable the DPAA Ethernet driver, the following Kconfig options are required:: -# common for arch/arm64 and arch/powerpc platforms -CONFIG_FSL_DPAA=y -CONFIG_FSL_FMAN=y -CONFIG_FSL_DPAA_ETH=y -CONFIG_FSL_XGMAC_MDIO=y + # common for arch/arm64 and arch/powerpc platforms + CONFIG_FSL_DPAA=y + CONFIG_FSL_FMAN=y + CONFIG_FSL_DPAA_ETH=y + CONFIG_FSL_XGMAC_MDIO=y -# for arch/powerpc only -CONFIG_FSL_PAMU=y + # for arch/powerpc only + CONFIG_FSL_PAMU=y -# common options needed for the PHYs used on the RDBs -CONFIG_VITESSE_PHY=y -CONFIG_REALTEK_PHY=y -CONFIG_AQUANTIA_PHY=y + # common options needed for the PHYs used on the RDBs + CONFIG_VITESSE_PHY=y + CONFIG_REALTEK_PHY=y + CONFIG_AQUANTIA_PHY=y DPAA Ethernet Frame Processing ============================== @@ -167,7 +173,9 @@ classes as follows: * priorities 8 to 11 - traffic class 2 (medium-high priority) * priorities 12 to 15 - traffic class 3 (high priority) -tc qdisc add dev <int> root handle 1: \ +:: + + tc qdisc add dev <int> root handle 1: \ mqprio num_tc 4 map 0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3 hw 1 DPAA IRQ Affinity and Receive Side Scaling @@ -201,11 +209,11 @@ of these frame queues will arrive at the same portal and will always be processed by the same CPU. This ensures intra-flow order preservation and workload distribution for multiple traffic flows. -RSS can be turned off for a certain interface using ethtool, i.e. +RSS can be turned off for a certain interface using ethtool, i.e.:: # ethtool -N fm1-mac9 rx-flow-hash tcp4 "" -To turn it back on, one needs to set rx-flow-hash for tcp4/6 or udp4/6: +To turn it back on, one needs to set rx-flow-hash for tcp4/6 or udp4/6:: # ethtool -N fm1-mac9 rx-flow-hash udp4 sfdn @@ -216,7 +224,7 @@ going to control the rx-flow-hashing for all protocols on that interface. Besides using the FMan Keygen computed hash for spreading traffic on the 128 Rx FQs, the DPAA Ethernet driver also sets the skb hash value when the NETIF_F_RXHASH feature is on (active by default). This can be turned -on or off through ethtool, i.e.: +on or off through ethtool, i.e.:: # ethtool -K fm1-mac9 rx-hashing off # ethtool -k fm1-mac9 | grep hash @@ -246,6 +254,7 @@ The following statistics are exported for each interface through ethtool: - Rx error count per CPU - Rx error count per type - congestion related statistics: + - congestion status - time spent in congestion - number of time the device entered congestion @@ -254,7 +263,7 @@ The following statistics are exported for each interface through ethtool: The driver also exports the following information in sysfs: - the FQ IDs for each FQ type - /sys/devices/platform/soc/<addr>.fman/<addr>.ethernet/dpaa-ethernet.<id>/net/fm<nr>-mac<nr>/fqids + /sys/devices/platform/soc/<addr>.fman/<addr>.ethernet/dpaa-ethernet.<id>/net/fm<nr>-mac<nr>/fqids - the ID of the buffer pool in use - /sys/devices/platform/soc/<addr>.fman/<addr>.ethernet/dpaa-ethernet.<id>/net/fm<nr>-mac<nr>/bpids + /sys/devices/platform/soc/<addr>.fman/<addr>.ethernet/dpaa-ethernet.<id>/net/fm<nr>-mac<nr>/bpids diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst index 17dbee1ac53e..e4ebfe62a183 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/dpio-driver.rst @@ -1,5 +1,6 @@ .. include:: <isonum.txt> +=================================== DPAA2 DPIO (Data Path I/O) Overview =================================== @@ -19,8 +20,10 @@ pool management for network interfaces. This document provides an overview the Linux DPIO driver, its subcomponents, and its APIs. -See Documentation/networking/device_drivers/freescale/dpaa2/overview.rst for -a general overview of DPAA2 and the general DPAA2 driver architecture in Linux. +See +Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst +for a general overview of DPAA2 and the general DPAA2 driver architecture +in Linux. Driver Overview --------------- diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/ethernet-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst index cb4c9a0c5a17..682f3986c15b 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/ethernet-driver.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/ethernet-driver.rst @@ -33,7 +33,8 @@ hardware resources, like queues, do not have a corresponding MC object and are treated as internal resources of other objects. For a more detailed description of the DPAA2 architecture and its object -abstractions see *Documentation/networking/device_drivers/freescale/dpaa2/overview.rst*. +abstractions see +*Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst*. Each Linux net device is built on top of a Datapath Network Interface (DPNI) object and uses Buffer Pools (DPBPs), I/O Portals (DPIOs) and Concentrators diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/index.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst index ee40fcc5ddff..62f4a4aff6ec 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/index.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/index.rst @@ -9,3 +9,4 @@ DPAA2 Documentation dpio-driver ethernet-driver mac-phy-support + switch-driver diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/mac-phy-support.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst index 51e6624fb774..e2a36d0d88ef 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/mac-phy-support.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/mac-phy-support.rst @@ -11,7 +11,7 @@ Overview -------- The DPAA2 MAC / PHY support consists of a set of APIs that help DPAA2 network -drivers (dpaa2-eth, dpaa2-ethsw) interract with the PHY library. +drivers (dpaa2-eth, dpaa2-ethsw) interact with the PHY library. DPAA2 Software Architecture --------------------------- @@ -181,10 +181,13 @@ when necessary using the below listed API:: - int dpaa2_mac_connect(struct dpaa2_mac *mac); - void dpaa2_mac_disconnect(struct dpaa2_mac *mac); -A phylink integration is necessary only when the partner DPMAC is not of TYPE_FIXED. -One can check for this condition using the below API:: +A phylink integration is necessary only when the partner DPMAC is not of +``TYPE_FIXED``. This means it is either of ``TYPE_PHY``, or of +``TYPE_BACKPLANE`` (the difference being the two that in the ``TYPE_BACKPLANE`` +mode, the MC firmware does not access the PCS registers). One can check for +this condition using the following helper:: - - bool dpaa2_mac_is_type_fixed(struct fsl_mc_device *dpmac_dev,struct fsl_mc_io *mc_io); + - static inline bool dpaa2_mac_is_type_phy(struct dpaa2_mac *mac); Before connection to a MAC, the caller must allocate and populate the dpaa2_mac structure with the associated net_device, a pointer to the MC portal diff --git a/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst index d638b5a8aadd..199647729251 100644 --- a/Documentation/networking/device_drivers/freescale/dpaa2/overview.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst @@ -183,6 +183,7 @@ PHY and allows physical transmission and reception of Ethernet frames. IRQ config, enable, reset DPNI (Datapath Network Interface) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contains TX/RX queues, network interface configuration, and RX buffer pool configuration mechanisms. The TX/RX queues are in memory and are identified by queue number. diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst new file mode 100644 index 000000000000..8bf411b857d4 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/switch-driver.rst @@ -0,0 +1,217 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +=================== +DPAA2 Switch driver +=================== + +:Copyright: |copy| 2021 NXP + +The DPAA2 Switch driver probes on the Datapath Switch (DPSW) object which can +be instantiated on the following DPAA2 SoCs and their variants: LS2088A and +LX2160A. + +The driver uses the switch device driver model and exposes each switch port as +a network interface, which can be included in a bridge or used as a standalone +interface. Traffic switched between ports is offloaded into the hardware. + +The DPSW can have ports connected to DPNIs or to DPMACs for external access. +:: + + [ethA] [ethB] [ethC] [ethD] [ethE] [ethF] + : : : : : : + : : : : : : + [dpaa2-eth] [dpaa2-eth] [ dpaa2-switch ] + : : : : : : kernel + ============================================================================= + : : : : : : hardware + [DPNI] [DPNI] [============= DPSW =================] + | | | | | | + | ---------- | [DPMAC] [DPMAC] + ------------------------------- | | + | | + [PHY] [PHY] + +Creating an Ethernet Switch +=========================== + +The dpaa2-switch driver probes on DPSW devices found on the fsl-mc bus. These +devices can be either created statically through the boot time configuration +file - DataPath Layout (DPL) - or at runtime using the DPAA2 object APIs +(incorporated already into the restool userspace tool). + +At the moment, the dpaa2-switch driver imposes the following restrictions on +the DPSW object that it will probe: + + * The minimum number of FDBs should be at least equal to the number of switch + interfaces. This is necessary so that separation of switch ports can be + done, ie when not under a bridge, each switch port will have its own FDB. + :: + + fsl_dpaa2_switch dpsw.0: The number of FDBs is lower than the number of ports, cannot probe + + * Both the broadcast and flooding configuration should be per FDB. This + enables the driver to restrict the broadcast and flooding domains of each + FDB depending on the switch ports that are sharing it (aka are under the + same bridge). + :: + + fsl_dpaa2_switch dpsw.0: Flooding domain is not per FDB, cannot probe + fsl_dpaa2_switch dpsw.0: Broadcast domain is not per FDB, cannot probe + + * The control interface of the switch should not be disabled + (DPSW_OPT_CTRL_IF_DIS not passed as a create time option). Without the + control interface, the driver is not capable to provide proper Rx/Tx traffic + support on the switch port netdevices. + :: + + fsl_dpaa2_switch dpsw.0: Control Interface is disabled, cannot probe + +Besides the configuration of the actual DPSW object, the dpaa2-switch driver +will need the following DPAA2 objects: + + * 1 DPMCP - A Management Command Portal object is needed for any interraction + with the MC firmware. + + * 1 DPBP - A Buffer Pool is used for seeding buffers intended for the Rx path + on the control interface. + + * Access to at least one DPIO object (Software Portal) is needed for any + enqueue/dequeue operation to be performed on the control interface queues. + The DPIO object will be shared, no need for a private one. + +Switching features +================== + +The driver supports the configuration of L2 forwarding rules in hardware for +port bridging as well as standalone usage of the independent switch interfaces. + +The hardware is not configurable with respect to VLAN awareness, thus any DPAA2 +switch port should be used only in usecases with a VLAN aware bridge:: + + $ ip link add dev br0 type bridge vlan_filtering 1 + + $ ip link add dev br1 type bridge + $ ip link set dev ethX master br1 + Error: fsl_dpaa2_switch: Cannot join a VLAN-unaware bridge + +Topology and loop detection through STP is supported when ``stp_state 1`` is +used at bridge create :: + + $ ip link add dev br0 type bridge vlan_filtering 1 stp_state 1 + +L2 FDB manipulation (add/delete/dump) is supported. + +HW FDB learning can be configured on each switch port independently through +bridge commands. When the HW learning is disabled, a fast age procedure will be +run and any previously learnt addresses will be removed. +:: + + $ bridge link set dev ethX learning off + $ bridge link set dev ethX learning on + +Restricting the unknown unicast and multicast flooding domain is supported, but +not independently of each other:: + + $ ip link set dev ethX type bridge_slave flood off mcast_flood off + $ ip link set dev ethX type bridge_slave flood off mcast_flood on + Error: fsl_dpaa2_switch: Cannot configure multicast flooding independently of unicast. + +Broadcast flooding on a switch port can be disabled/enabled through the brport sysfs:: + + $ echo 0 > /sys/bus/fsl-mc/devices/dpsw.Y/net/ethX/brport/broadcast_flood + +Offloads +======== + +Routing actions (redirect, trap, drop) +-------------------------------------- + +The DPAA2 switch is able to offload flow-based redirection of packets making +use of ACL tables. Shared filter blocks are supported by sharing a single ACL +table between multiple ports. + +The following flow keys are supported: + + * Ethernet: dst_mac/src_mac + * IPv4: dst_ip/src_ip/ip_proto/tos + * VLAN: vlan_id/vlan_prio/vlan_tpid/vlan_dei + * L4: dst_port/src_port + +Also, the matchall filter can be used to redirect the entire traffic received +on a port. + +As per flow actions, the following are supported: + + * drop + * mirred egress redirect + * trap + +Each ACL entry (filter) can be setup with only one of the listed +actions. + +Example 1: send frames received on eth4 with a SA of 00:01:02:03:04:05 to the +CPU:: + + $ tc qdisc add dev eth4 clsact + $ tc filter add dev eth4 ingress flower src_mac 00:01:02:03:04:05 skip_sw action trap + +Example 2: drop frames received on eth4 with VID 100 and PCP of 3:: + + $ tc filter add dev eth4 ingress protocol 802.1q flower skip_sw vlan_id 100 vlan_prio 3 action drop + +Example 3: redirect all frames received on eth4 to eth1:: + + $ tc filter add dev eth4 ingress matchall action mirred egress redirect dev eth1 + +Example 4: Use a single shared filter block on both eth5 and eth6:: + + $ tc qdisc add dev eth5 ingress_block 1 clsact + $ tc qdisc add dev eth6 ingress_block 1 clsact + $ tc filter add block 1 ingress flower dst_mac 00:01:02:03:04:04 skip_sw \ + action trap + $ tc filter add block 1 ingress protocol ipv4 flower src_ip 192.168.1.1 skip_sw \ + action mirred egress redirect dev eth3 + +Mirroring +~~~~~~~~~ + +The DPAA2 switch supports only per port mirroring and per VLAN mirroring. +Adding mirroring filters in shared blocks is also supported. + +When using the tc-flower classifier with the 802.1q protocol, only the +''vlan_id'' key will be accepted. Mirroring based on any other fields from the +802.1q protocol will be rejected:: + + $ tc qdisc add dev eth8 ingress_block 1 clsact + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_prio 3 action mirred egress mirror dev eth6 + Error: fsl_dpaa2_switch: Only matching on VLAN ID supported. + We have an error talking to the kernel + +If a mirroring VLAN filter is requested on a port, the VLAN must to be +installed on the switch port in question either using ''bridge'' or by creating +a VLAN upper device if the switch port is used as a standalone interface:: + + $ tc qdisc add dev eth8 ingress_block 1 clsact + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + Error: VLAN must be installed on the switch port. + We have an error talking to the kernel + + $ bridge vlan add vid 200 dev eth8 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + + $ ip link add link eth8 name eth8.200 type vlan id 200 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + +Also, it should be noted that the mirrored traffic will be subject to the same +egress restrictions as any other traffic. This means that when a mirrored +packet will reach the mirror port, if the VLAN found in the packet is not +installed on the port it will get dropped. + +The DPAA2 switch supports only a single mirroring destination, thus multiple +mirror rules can be installed but their ''to'' port has to be the same:: + + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 200 action mirred egress mirror dev eth6 + $ tc filter add block 1 ingress protocol 802.1q flower skip_sw vlan_id 100 action mirred egress mirror dev eth7 + Error: fsl_dpaa2_switch: Multiple mirror ports not supported. + We have an error talking to the kernel diff --git a/Documentation/networking/device_drivers/freescale/gianfar.txt b/Documentation/networking/device_drivers/ethernet/freescale/gianfar.rst index ba1daea7f2e4..9c4a91d3824b 100644 --- a/Documentation/networking/device_drivers/freescale/gianfar.txt +++ b/Documentation/networking/device_drivers/ethernet/freescale/gianfar.rst @@ -1,10 +1,15 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== The Gianfar Ethernet Driver +=========================== -Author: Andy Fleming <afleming@freescale.com> -Updated: 2005-07-28 +:Author: Andy Fleming <afleming@freescale.com> +:Updated: 2005-07-28 -CHECKSUM OFFLOADING +Checksum Offloading +=================== The eTSEC controller (first included in parts from late 2005 like the 8548) has the ability to perform TCP, UDP, and IP checksums @@ -15,13 +20,15 @@ packets. Use ethtool to enable or disable this feature for RX and TX. VLAN +==== In order to use VLAN, please consult Linux documentation on configuring VLANs. The gianfar driver supports hardware insertion and extraction of VLAN headers, but not filtering. Filtering will be done by the kernel. -MULTICASTING +Multicasting +============ The gianfar driver supports using the group hash table on the TSEC (and the extended hash table on the eTSEC) for multicast @@ -29,13 +36,15 @@ filtering. On the eTSEC, the exact-match MAC registers are used before the hash tables. See Linux documentation on how to join multicast groups. -PADDING +Padding +======= The gianfar driver supports padding received frames with 2 bytes to align the IP header to a 16-byte boundary, when supported by hardware. -ETHTOOL +Ethtool +======= The gianfar driver supports the use of ethtool for many configuration options. You must run ethtool only on currently diff --git a/Documentation/networking/device_drivers/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst index 793693cef6e3..31d621bca82e 100644 --- a/Documentation/networking/device_drivers/google/gve.rst +++ b/Documentation/networking/device_drivers/ethernet/google/gve.rst @@ -47,13 +47,33 @@ The driver interacts with the device in the following ways: - Transmit and Receive Queues - See description below +Descriptor Formats +------------------ +GVE supports two descriptor formats: GQI and DQO. These two formats have +entirely different descriptors, which will be described below. + +Addressing Mode +------------------ +GVE supports two addressing modes: QPL and RDA. +QPL ("queue-page-list") mode communicates data through a set of +pre-registered pages. + +For RDA ("raw DMA addressing") mode, the set of pages is dynamic. +Therefore, the packet buffers can be anywhere in guest memory. + Registers --------- -All registers are MMIO and big endian. +All registers are MMIO. The registers are used for initializing and configuring the device as well as querying device status in response to management interrupts. +Endianness +---------- +- Admin Queue messages and registers are all Big Endian. +- GQI descriptors and datapath registers are Big Endian. +- DQO descriptors and datapath registers are Little Endian. + Admin Queue (AQ) ---------------- The Admin Queue is a PAGE_SIZE memory block, treated as an array of AQ @@ -97,10 +117,10 @@ the queues associated with that interrupt. The handler for these irqs schedule the napi for that block to run and poll the queues. -Traffic Queues --------------- -gVNIC's queues are composed of a descriptor ring and a buffer and are -assigned to a notification block. +GQI Traffic Queues +------------------ +GQI queues are composed of a descriptor ring and a buffer and are assigned to a +notification block. The descriptor rings are power-of-two-sized ring buffers consisting of fixed-size descriptors. They advance their head pointer using a __be32 @@ -121,3 +141,35 @@ Receive The buffers for receive rings are put into a data ring that is the same length as the descriptor ring and the head and tail pointers advance over the rings together. + +DQO Traffic Queues +------------------ +- Every TX and RX queue is assigned a notification block. + +- TX and RX buffers queues, which send descriptors to the device, use MMIO + doorbells to notify the device of new descriptors. + +- RX and TX completion queues, which receive descriptors from the device, use a + "generation bit" to know when a descriptor was populated by the device. The + driver initializes all bits with the "current generation". The device will + populate received descriptors with the "next generation" which is inverted + from the current generation. When the ring wraps, the current/next generation + are swapped. + +- It's the driver's responsibility to ensure that the RX and TX completion + queues are not overrun. This can be accomplished by limiting the number of + descriptors posted to HW. + +- TX packets have a 16 bit completion_tag and RX buffers have a 16 bit + buffer_id. These will be returned on the TX completion and RX queues + respectively to let the driver know which packet/buffer was completed. + +Transmit +~~~~~~~~ +A packet's buffers are DMA mapped for the device to access before transmission. +After the packet was successfully transmitted, the buffers are unmapped. + +Receive +~~~~~~~ +The driver posts fixed sized buffers to HW on the RX buffer queue. The packet +received on the associated RX queue may span multiple descriptors. diff --git a/Documentation/networking/device_drivers/ethernet/huawei/hinic.rst b/Documentation/networking/device_drivers/ethernet/huawei/hinic.rst new file mode 100644 index 000000000000..867ac8f4e04a --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/huawei/hinic.rst @@ -0,0 +1,128 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================ +Linux Kernel Driver for Huawei Intelligent NIC(HiNIC) family +============================================================ + +Overview: +========= +HiNIC is a network interface card for the Data Center Area. + +The driver supports a range of link-speed devices (10GbE, 25GbE, 40GbE, etc.). +The driver supports also a negotiated and extendable feature set. + +Some HiNIC devices support SR-IOV. This driver is used for Physical Function +(PF). + +HiNIC devices support MSI-X interrupt vector for each Tx/Rx queue and +adaptive interrupt moderation. + +HiNIC devices support also various offload features such as checksum offload, +TCP Transmit Segmentation Offload(TSO), Receive-Side Scaling(RSS) and +LRO(Large Receive Offload). + + +Supported PCI vendor ID/device IDs: +=================================== + +19e5:1822 - HiNIC PF + + +Driver Architecture and Source Code: +==================================== + +hinic_dev - Implement a Logical Network device that is independent from +specific HW details about HW data structure formats. + +hinic_hwdev - Implement the HW details of the device and include the components +for accessing the PCI NIC. + +hinic_hwdev contains the following components: +=============================================== + +HW Interface: +============= + +The interface for accessing the pci device (DMA memory and PCI BARs). +(hinic_hw_if.c, hinic_hw_if.h) + +Configuration Status Registers Area that describes the HW Registers on the +configuration and status BAR0. (hinic_hw_csr.h) + +MGMT components: +================ + +Asynchronous Event Queues(AEQs) - The event queues for receiving messages from +the MGMT modules on the cards. (hinic_hw_eqs.c, hinic_hw_eqs.h) + +Application Programmable Interface commands(API CMD) - Interface for sending +MGMT commands to the card. (hinic_hw_api_cmd.c, hinic_hw_api_cmd.h) + +Management (MGMT) - the PF to MGMT channel that uses API CMD for sending MGMT +commands to the card and receives notifications from the MGMT modules on the +card by AEQs. Also set the addresses of the IO CMDQs in HW. +(hinic_hw_mgmt.c, hinic_hw_mgmt.h) + +IO components: +============== + +Completion Event Queues(CEQs) - The completion Event Queues that describe IO +tasks that are finished. (hinic_hw_eqs.c, hinic_hw_eqs.h) + +Work Queues(WQ) - Contain the memory and operations for use by CMD queues and +the Queue Pairs. The WQ is a Memory Block in a Page. The Block contains +pointers to Memory Areas that are the Memory for the Work Queue Elements(WQEs). +(hinic_hw_wq.c, hinic_hw_wq.h) + +Command Queues(CMDQ) - The queues for sending commands for IO management and is +used to set the QPs addresses in HW. The commands completion events are +accumulated on the CEQ that is configured to receive the CMDQ completion events. +(hinic_hw_cmdq.c, hinic_hw_cmdq.h) + +Queue Pairs(QPs) - The HW Receive and Send queues for Receiving and Transmitting +Data. (hinic_hw_qp.c, hinic_hw_qp.h, hinic_hw_qp_ctxt.h) + +IO - de/constructs all the IO components. (hinic_hw_io.c, hinic_hw_io.h) + +HW device: +========== + +HW device - de/constructs the HW Interface, the MGMT components on the +initialization of the driver and the IO components on the case of Interface +UP/DOWN Events. (hinic_hw_dev.c, hinic_hw_dev.h) + + +hinic_dev contains the following components: +=============================================== + +PCI ID table - Contains the supported PCI Vendor/Device IDs. +(hinic_pci_tbl.h) + +Port Commands - Send commands to the HW device for port management +(MAC, Vlan, MTU, ...). (hinic_port.c, hinic_port.h) + +Tx Queues - Logical Tx Queues that use the HW Send Queues for transmit. +The Logical Tx queue is not dependent on the format of the HW Send Queue. +(hinic_tx.c, hinic_tx.h) + +Rx Queues - Logical Rx Queues that use the HW Receive Queues for receive. +The Logical Rx queue is not dependent on the format of the HW Receive Queue. +(hinic_rx.c, hinic_rx.h) + +hinic_dev - de/constructs the Logical Tx and Rx Queues. +(hinic_main.c, hinic_dev.h) + + +Miscellaneous +============= + +Common functions that are used by HW and Logical Device. +(hinic_common.c, hinic_common.h) + + +Support +======= + +If an issue is identified with the released source code on the supported kernel +with a supported adapter, email the specific information related to the issue to +aviad.krawczyk@huawei.com. diff --git a/Documentation/networking/device_drivers/ethernet/index.rst b/Documentation/networking/device_drivers/ethernet/index.rst new file mode 100644 index 000000000000..6932d8c043c2 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/index.rst @@ -0,0 +1,66 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Ethernet Device Drivers +======================= + +Device drivers for Ethernet and Ethernet-based virtual function devices. + +Contents: + +.. toctree:: + :maxdepth: 2 + + 3com/3c509 + 3com/vortex + amazon/ena + altera/altera_tse + amd/pds_core + amd/pds_vdpa + amd/pds_vfio_pci + aquantia/atlantic + chelsio/cxgb + cirrus/cs89x0 + dlink/dl2k + davicom/dm9000 + dec/dmfe + freescale/dpaa + freescale/dpaa2/index + freescale/gianfar + google/gve + huawei/hinic + intel/e100 + intel/e1000 + intel/e1000e + intel/fm10k + intel/idpf + intel/igb + intel/igbvf + intel/ixgbe + intel/ixgbevf + intel/i40e + intel/iavf + intel/ice + marvell/octeontx2 + marvell/octeon_ep + marvell/octeon_ep_vf + mellanox/mlx5/index + microsoft/netvsc + neterion/s2io + netronome/nfp + pensando/ionic + smsc/smc9 + stmicro/stmmac + ti/cpsw + ti/cpsw_switchdev + ti/am65_nuss_cpsw_switchdev + ti/tlan + toshiba/spider_net + wangxun/txgbe + wangxun/ngbe + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/intel/e100.rst b/Documentation/networking/device_drivers/ethernet/intel/e100.rst index caf023cc88de..5dee1b53e977 100644 --- a/Documentation/networking/device_drivers/intel/e100.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e100.rst @@ -33,7 +33,7 @@ The following features are now available in supported kernels: - SNMP Channel Bonding documentation can be found in the Linux kernel source: -/Documentation/networking/bonding.txt +/Documentation/networking/bonding.rst Identifying Your Adapter @@ -41,7 +41,7 @@ Identifying Your Adapter For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Driver Configuration Parameters =============================== @@ -151,8 +151,7 @@ NAPI NAPI (Rx polling mode) is supported in the e100 driver. -See https://wiki.linuxfoundation.org/networking/napi for more -information on NAPI. +See :ref:`Documentation/networking/napi.rst <napi>` for more information. Multiple Interfaces on Same Ethernet Broadcast Network ------------------------------------------------------ @@ -179,10 +178,8 @@ filtering by Support ======= For general information, go to the Intel support website at: -http://www.intel.com/support/ +https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: -http://sourceforge.net/projects/e1000 If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/e1000.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000.rst index 4aaae0f7d6ba..52a7fb9ce8d9 100644 --- a/Documentation/networking/device_drivers/intel/e1000.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e1000.rst @@ -451,13 +451,8 @@ Support ======= For general information, go to the Intel support website at: - - http://support.intel.com - -or the Intel Wired Networking project hosted by Sourceforge at: - - http://sourceforge.net/projects/e1000 +http://support.intel.com If an issue is identified with the released source code on the supported kernel with a supported adapter, email the specific information related -to the issue to e1000-devel@lists.sf.net +to the issue to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/e1000e.rst b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst index f49cd370e7bf..d8f810afdd49 100644 --- a/Documentation/networking/device_drivers/intel/e1000e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/e1000e.rst @@ -371,13 +371,8 @@ NOTE: Wake on LAN is only supported on port A for the following devices: Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/fm10k.rst b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst index 4d279e64e221..396a2c8c3db1 100644 --- a/Documentation/networking/device_drivers/intel/fm10k.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/fm10k.rst @@ -22,7 +22,7 @@ Ethernet Multi-host Controller. For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Flow Control @@ -130,13 +130,8 @@ the Intel Ethernet Controller XL710. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/i40e.rst b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst index 8a9b18573688..4fbaa1a2d674 100644 --- a/Documentation/networking/device_drivers/intel/i40e.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/i40e.rst @@ -173,7 +173,7 @@ Director rule is added from ethtool (Sideband filter), ATR is turned off by the driver. To re-enable ATR, the sideband can be disabled with the ethtool -K option. For example:: - ethtool –K [adapter] ntuple [off|on] + ethtool -K [adapter] ntuple [off|on] If sideband is re-enabled after ATR is re-enabled, ATR remains enabled until a TCP-IP flow is added. When all TCP-IP sideband rules are deleted, ATR is @@ -399,8 +399,8 @@ operate only in full duplex and only at their native speed. NAPI ---- NAPI (Rx polling mode) is supported in the i40e driver. -For more information on NAPI, see -https://wiki.linuxfoundation.org/networking/napi + +See :ref:`Documentation/networking/napi.rst <napi>` for more information. Flow Control ------------ @@ -466,7 +466,7 @@ network. PTP support varies among Intel devices that support this driver. Use "ethtool -T <netdev name>" to get a definitive list of PTP capabilities supported by the device. -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as @@ -523,8 +523,8 @@ of a port's bandwidth (should it be available). The sum of all the values for Maximum Bandwidth is not restricted, because no more than 100% of a port's bandwidth can ever be used. -NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions -per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says +NOTE: X710/XXV710 devices fail to enable Max VFs (64) when Multiple Functions +per Port (MFP) and SR-IOV are enabled. An error from i40e is logged that says "add vsi failed for VF N, aq_err 16". To workaround the issue, enable less than 64 virtual functions (VFs). @@ -688,7 +688,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates. Totals must be equal or less than port speed. For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network -monitoring tools such as ifstat or sar –n DEV [interval] [number of samples] +monitoring tools such as `ifstat` or `sar -n DEV [interval] [number of samples]` 2. Enable HW TC offload on interface:: @@ -759,13 +759,8 @@ enabled when setting up DCB on your switch. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/iavf.rst b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst index 84ac7e75f363..eb926c3bd4cd 100644 --- a/Documentation/networking/device_drivers/intel/iavf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/iavf.rst @@ -43,7 +43,7 @@ device. For information on how to identify your adapter, and for the latest NVM/FW images and Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Additional Features and Configurations @@ -113,7 +113,7 @@ which the AVF is associated. The following are base mode features: - AVF device ID - HW mailbox is used for VF to PF communications (including on Windows) -IEEE 802.1ad (QinQ) Support +IEEE 802.1ad (QinQ) Support --------------------------- The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as @@ -179,7 +179,7 @@ shaper bw_rlimit: for each tc, sets minimum and maximum bandwidth rates. Totals must be equal or less than port speed. For example: min_rate 1Gbit 3Gbit: Verify bandwidth limit using network -monitoring tools such as ifstat or sar –n DEV [interval] [number of samples] +monitoring tools such as ``ifstat`` or ``sar -n DEV [interval] [number of samples]`` NOTE: Setting up channels via ethtool (ethtool -L) is not supported when the @@ -319,13 +319,8 @@ This is caused by the way the Linux kernel reports this stressed condition. Support ======= For general information, go to the Intel support website at: - https://support.intel.com -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on the supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/intel/ice.rst b/Documentation/networking/device_drivers/ethernet/intel/ice.rst new file mode 100644 index 000000000000..934752f675ba --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/intel/ice.rst @@ -0,0 +1,1175 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +================================================================= +Linux Base Driver for the Intel(R) Ethernet Controller 800 Series +================================================================= + +Intel ice Linux driver. +Copyright(c) 2018-2021 Intel Corporation. + +Contents +======== + +- Overview +- Identifying Your Adapter +- Important Notes +- Additional Features & Configurations +- Performance Optimization + + +The associated Virtual Function (VF) driver for this driver is iavf. + +Driver information can be obtained using ethtool and lspci. + +For questions related to hardware requirements, refer to the documentation +supplied with your Intel adapter. All hardware requirements listed apply to use +with Linux. + +This driver supports XDP (Express Data Path) and AF_XDP zero-copy. Note that +XDP is blocked for frame sizes larger than 3KB. + + +Identifying Your Adapter +======================== +For information on how to identify your adapter, and for the latest Intel +network drivers, refer to the Intel Support website: +https://www.intel.com/support + + +Important Notes +=============== + +Packet drops may occur under receive stress +------------------------------------------- +Devices based on the Intel(R) Ethernet Controller 800 Series are designed to +tolerate a limited amount of system latency during PCIe and DMA transactions. +If these transactions take longer than the tolerated latency, it can impact the +length of time the packets are buffered in the device and associated memory, +which may result in dropped packets. These packets drops typically do not have +a noticeable impact on throughput and performance under standard workloads. + +If these packet drops appear to affect your workload, the following may improve +the situation: + +1) Make sure that your system's physical memory is in a high-performance + configuration, as recommended by the platform vendor. A common + recommendation is for all channels to be populated with a single DIMM + module. +2) In your system's BIOS/UEFI settings, select the "Performance" profile. +3) Your distribution may provide tools like "tuned," which can help tweak + kernel settings to achieve better standard settings for different workloads. + + +Configuring SR-IOV for improved network security +------------------------------------------------ +In a virtualized environment, on Intel(R) Ethernet Network Adapters that +support SR-IOV, the virtual function (VF) may be subject to malicious behavior. +Software-generated layer two frames, like IEEE 802.3x (link flow control), IEEE +802.1Qbb (priority based flow-control), and others of this type, are not +expected and can throttle traffic between the host and the virtual switch, +reducing performance. To resolve this issue, and to ensure isolation from +unintended traffic streams, configure all SR-IOV enabled ports for VLAN tagging +from the administrative interface on the PF. This configuration allows +unexpected, and potentially malicious, frames to be dropped. + +See "Configuring VLAN Tagging on SR-IOV Enabled Adapter Ports" later in this +README for configuration instructions. + + +Do not unload port driver if VF with active VM is bound to it +------------------------------------------------------------- +Do not unload a port's driver if a Virtual Function (VF) with an active Virtual +Machine (VM) is bound to it. Doing so will cause the port to appear to hang. +Once the VM shuts down, or otherwise releases the VF, the command will +complete. + + +Additional Features and Configurations +====================================== + +ethtool +------- +The driver utilizes the ethtool interface for driver configuration and +diagnostics, as well as displaying statistical information. The latest ethtool +version is required for this functionality. Download it at: +https://kernel.org/pub/software/network/ethtool/ + +NOTE: The rx_bytes value of ethtool does not match the rx_bytes value of +Netdev, due to the 4-byte CRC being stripped by the device. The difference +between the two rx_bytes values will be 4 x the number of Rx packets. For +example, if Rx packets are 10 and Netdev (software statistics) displays +rx_bytes as "X", then ethtool (hardware statistics) will display rx_bytes as +"X+40" (4 bytes CRC x 10 packets). + + +Viewing Link Messages +--------------------- +Link messages will not be displayed to the console if the distribution is +restricting system messages. In order to see network driver link messages on +your console, set dmesg to eight by entering the following:: + + # dmesg -n 8 + +NOTE: This setting is not saved across reboots. + + +Dynamic Device Personalization +------------------------------ +Dynamic Device Personalization (DDP) allows you to change the packet processing +pipeline of a device by applying a profile package to the device at runtime. +Profiles can be used to, for example, add support for new protocols, change +existing protocols, or change default settings. DDP profiles can also be rolled +back without rebooting the system. + +The DDP package loads during device initialization. The driver looks for +``intel/ice/ddp/ice.pkg`` in your firmware root (typically ``/lib/firmware/`` +or ``/lib/firmware/updates/``) and checks that it contains a valid DDP package +file. + +NOTE: Your distribution should likely have provided the latest DDP file, but if +ice.pkg is missing, you can find it in the linux-firmware repository or from +intel.com. + +If the driver is unable to load the DDP package, the device will enter Safe +Mode. Safe Mode disables advanced and performance features and supports only +basic traffic and minimal functionality, such as updating the NVM or +downloading a new driver or DDP package. Safe Mode only applies to the affected +physical function and does not impact any other PFs. See the "Intel(R) Ethernet +Adapters and Devices User Guide" for more details on DDP and Safe Mode. + +NOTES: + +- If you encounter issues with the DDP package file, you may need to download + an updated driver or DDP package file. See the log messages for more + information. + +- The ice.pkg file is a symbolic link to the default DDP package file. + +- You cannot update the DDP package if any PF drivers are already loaded. To + overwrite a package, unload all PFs and then reload the driver with the new + package. + +- Only the first loaded PF per device can download a package for that device. + +You can install specific DDP package files for different physical devices in +the same system. To install a specific DDP package file: + +1. Download the DDP package file you want for your device. + +2. Rename the file ice-xxxxxxxxxxxxxxxx.pkg, where 'xxxxxxxxxxxxxxxx' is the + unique 64-bit PCI Express device serial number (in hex) of the device you + want the package downloaded on. The filename must include the complete + serial number (including leading zeros) and be all lowercase. For example, + if the 64-bit serial number is b887a3ffffca0568, then the file name would be + ice-b887a3ffffca0568.pkg. + + To find the serial number from the PCI bus address, you can use the + following command:: + + # lspci -vv -s af:00.0 | grep -i Serial + Capabilities: [150 v1] Device Serial Number b8-87-a3-ff-ff-ca-05-68 + + You can use the following command to format the serial number without the + dashes:: + + # lspci -vv -s af:00.0 | grep -i Serial | awk '{print $7}' | sed s/-//g + b887a3ffffca0568 + +3. Copy the renamed DDP package file to + ``/lib/firmware/updates/intel/ice/ddp/``. If the directory does not yet + exist, create it before copying the file. + +4. Unload all of the PFs on the device. + +5. Reload the driver with the new package. + +NOTE: The presence of a device-specific DDP package file overrides the loading +of the default DDP package file (ice.pkg). + + +Intel(R) Ethernet Flow Director +------------------------------- +The Intel Ethernet Flow Director performs the following tasks: + +- Directs receive packets according to their flows to different queues +- Enables tight control on routing a flow in the platform +- Matches flows and CPU cores for flow affinity + +NOTE: This driver supports the following flow types: + +- IPv4 +- TCPv4 +- UDPv4 +- SCTPv4 +- IPv6 +- TCPv6 +- UDPv6 +- SCTPv6 + +Each flow type supports valid combinations of IP addresses (source or +destination) and UDP/TCP/SCTP ports (source and destination). You can supply +only a source IP address, a source IP address and a destination port, or any +combination of one or more of these four parameters. + +NOTE: This driver allows you to filter traffic based on a user-defined flexible +two-byte pattern and offset by using the ethtool user-def and mask fields. Only +L3 and L4 flow types are supported for user-defined flexible filters. For a +given flow type, you must clear all Intel Ethernet Flow Director filters before +changing the input set (for that flow type). + + +Flow Director Filters +--------------------- +Flow Director filters are used to direct traffic that matches specified +characteristics. They are enabled through ethtool's ntuple interface. To enable +or disable the Intel Ethernet Flow Director and these filters:: + + # ethtool -K <ethX> ntuple <off|on> + +NOTE: When you disable ntuple filters, all the user programmed filters are +flushed from the driver cache and hardware. All needed filters must be re-added +when ntuple is re-enabled. + +To display all of the active filters:: + + # ethtool -u <ethX> + +To add a new filter:: + + # ethtool -U <ethX> flow-type <type> src-ip <ip> [m <ip_mask>] dst-ip <ip> + [m <ip_mask>] src-port <port> [m <port_mask>] dst-port <port> [m <port_mask>] + action <queue> + + Where: + <ethX> - the Ethernet device to program + <type> - can be ip4, tcp4, udp4, sctp4, ip6, tcp6, udp6, sctp6 + <ip> - the IP address to match on + <ip_mask> - the IPv4 address to mask on + NOTE: These filters use inverted masks. + <port> - the port number to match on + <port_mask> - the 16-bit integer for masking + NOTE: These filters use inverted masks. + <queue> - the queue to direct traffic toward (-1 discards the + matched traffic) + +To delete a filter:: + + # ethtool -U <ethX> delete <N> + + Where <N> is the filter ID displayed when printing all the active filters, + and may also have been specified using "loc <N>" when adding the filter. + +EXAMPLES: + +To add a filter that directs packet to queue 2:: + + # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \ + 192.168.10.2 src-port 2000 dst-port 2001 action 2 [loc 1] + +To set a filter using only the source and destination IP address:: + + # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \ + 192.168.10.2 action 2 [loc 1] + +To set a filter based on a user-defined pattern and offset:: + + # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.10.1 dst-ip \ + 192.168.10.2 user-def 0x4FFFF action 2 [loc 1] + + where the value of the user-def field contains the offset (4 bytes) and + the pattern (0xffff). + +To match TCP traffic sent from 192.168.0.1, port 5300, directed to 192.168.0.5, +port 80, and then send it to queue 7:: + + # ethtool -U enp130s0 flow-type tcp4 src-ip 192.168.0.1 dst-ip 192.168.0.5 + src-port 5300 dst-port 80 action 7 + +To add a TCPv4 filter with a partial mask for a source IP subnet:: + + # ethtool -U <ethX> flow-type tcp4 src-ip 192.168.0.0 m 0.255.255.255 dst-ip + 192.168.5.12 src-port 12600 dst-port 31 action 12 + +NOTES: + +For each flow-type, the programmed filters must all have the same matching +input set. For example, issuing the following two commands is acceptable:: + + # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7 + # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.5 src-port 55 action 10 + +Issuing the next two commands, however, is not acceptable, since the first +specifies src-ip and the second specifies dst-ip:: + + # ethtool -U enp130s0 flow-type ip4 src-ip 192.168.0.1 src-port 5300 action 7 + # ethtool -U enp130s0 flow-type ip4 dst-ip 192.168.0.5 src-port 55 action 10 + +The second command will fail with an error. You may program multiple filters +with the same fields, using different values, but, on one device, you may not +program two tcp4 filters with different matching fields. + +The ice driver does not support matching on a subportion of a field, thus +partial mask fields are not supported. + + +Flex Byte Flow Director Filters +------------------------------- +The driver also supports matching user-defined data within the packet payload. +This flexible data is specified using the "user-def" field of the ethtool +command in the following way: + +.. table:: + + ============================== ============================ + ``31 28 24 20 16`` ``15 12 8 4 0`` + ``offset into packet payload`` ``2 bytes of flexible data`` + ============================== ============================ + +For example, + +:: + + ... user-def 0x4FFFF ... + +tells the filter to look 4 bytes into the payload and match that value against +0xFFFF. The offset is based on the beginning of the payload, and not the +beginning of the packet. Thus + +:: + + flow-type tcp4 ... user-def 0x8BEAF ... + +would match TCP/IPv4 packets which have the value 0xBEAF 8 bytes into the +TCP/IPv4 payload. + +Note that ICMP headers are parsed as 4 bytes of header and 4 bytes of payload. +Thus to match the first byte of the payload, you must actually add 4 bytes to +the offset. Also note that ip4 filters match both ICMP frames as well as raw +(unknown) ip4 frames, where the payload will be the L3 payload of the IP4 +frame. + +The maximum offset is 64. The hardware will only read up to 64 bytes of data +from the payload. The offset must be even because the flexible data is 2 bytes +long and must be aligned to byte 0 of the packet payload. + +The user-defined flexible offset is also considered part of the input set and +cannot be programmed separately for multiple filters of the same type. However, +the flexible data is not part of the input set and multiple filters may use the +same offset but match against different data. + + +RSS Hash Flow +------------- +Allows you to set the hash bytes per flow type and any combination of one or +more options for Receive Side Scaling (RSS) hash byte configuration. + +:: + + # ethtool -N <ethX> rx-flow-hash <type> <option> + + Where <type> is: + tcp4 signifying TCP over IPv4 + udp4 signifying UDP over IPv4 + gtpc4 signifying GTP-C over IPv4 + gtpc4t signifying GTP-C (include TEID) over IPv4 + gtpu4 signifying GTP-U over IPV4 + gtpu4e signifying GTP-U and Extension Header over IPV4 + gtpu4u signifying GTP-U PSC Uplink over IPV4 + gtpu4d signifying GTP-U PSC Downlink over IPV4 + tcp6 signifying TCP over IPv6 + udp6 signifying UDP over IPv6 + gtpc6 signifying GTP-C over IPv6 + gtpc6t signifying GTP-C (include TEID) over IPv6 + gtpu6 signifying GTP-U over IPV6 + gtpu6e signifying GTP-U and Extension Header over IPV6 + gtpu6u signifying GTP-U PSC Uplink over IPV6 + gtpu6d signifying GTP-U PSC Downlink over IPV6 + And <option> is one or more of: + s Hash on the IP source address of the Rx packet. + d Hash on the IP destination address of the Rx packet. + f Hash on bytes 0 and 1 of the Layer 4 header of the Rx packet. + n Hash on bytes 2 and 3 of the Layer 4 header of the Rx packet. + e Hash on GTP Packet on TEID (4bytes) of the Rx packet. + + +Accelerated Receive Flow Steering (aRFS) +---------------------------------------- +Devices based on the Intel(R) Ethernet Controller 800 Series support +Accelerated Receive Flow Steering (aRFS) on the PF. aRFS is a load-balancing +mechanism that allows you to direct packets to the same CPU where an +application is running or consuming the packets in that flow. + +NOTES: + +- aRFS requires that ntuple filtering is enabled via ethtool. +- aRFS support is limited to the following packet types: + + - TCP over IPv4 and IPv6 + - UDP over IPv4 and IPv6 + - Nonfragmented packets + +- aRFS only supports Flow Director filters, which consist of the + source/destination IP addresses and source/destination ports. +- aRFS and ethtool's ntuple interface both use the device's Flow Director. aRFS + and ntuple features can coexist, but you may encounter unexpected results if + there's a conflict between aRFS and ntuple requests. See "Intel(R) Ethernet + Flow Director" for additional information. + +To set up aRFS: + +1. Enable the Intel Ethernet Flow Director and ntuple filters using ethtool. + +:: + + # ethtool -K <ethX> ntuple on + +2. Set up the number of entries in the global flow table. For example: + +:: + + # NUM_RPS_ENTRIES=16384 + # echo $NUM_RPS_ENTRIES > /proc/sys/net/core/rps_sock_flow_entries + +3. Set up the number of entries in the per-queue flow table. For example: + +:: + + # NUM_RX_QUEUES=64 + # for file in /sys/class/net/$IFACE/queues/rx-*/rps_flow_cnt; do + # echo $(($NUM_RPS_ENTRIES/$NUM_RX_QUEUES)) > $file; + # done + +4. Disable the IRQ balance daemon (this is only a temporary stop of the service + until the next reboot). + +:: + + # systemctl stop irqbalance + +5. Configure the interrupt affinity. + + See ``/Documentation/core-api/irq/irq-affinity.rst`` + + +To disable aRFS using ethtool:: + + # ethtool -K <ethX> ntuple off + +NOTE: This command will disable ntuple filters and clear any aRFS filters in +software and hardware. + +Example Use Case: + +1. Set the server application on the desired CPU (e.g., CPU 4). + +:: + + # taskset -c 4 netserver + +2. Use netperf to route traffic from the client to CPU 4 on the server with + aRFS configured. This example uses TCP over IPv4. + +:: + + # netperf -H <Host IPv4 Address> -t TCP_STREAM + + +Enabling Virtual Functions (VFs) +-------------------------------- +Use sysfs to enable virtual functions (VF). + +For example, you can create 4 VFs as follows:: + + # echo 4 > /sys/class/net/<ethX>/device/sriov_numvfs + +To disable VFs, write 0 to the same file:: + + # echo 0 > /sys/class/net/<ethX>/device/sriov_numvfs + +The maximum number of VFs for the ice driver is 256 total (all ports). To check +how many VFs each PF supports, use the following command:: + + # cat /sys/class/net/<ethX>/device/sriov_totalvfs + +Note: You cannot use SR-IOV when link aggregation (LAG)/bonding is active, and +vice versa. To enforce this, the driver checks for this mutual exclusion. + + +Displaying VF Statistics on the PF +---------------------------------- +Use the following command to display the statistics for the PF and its VFs:: + + # ip -s link show dev <ethX> + +NOTE: The output of this command can be very large due to the maximum number of +possible VFs. + +The PF driver will display a subset of the statistics for the PF and for all +VFs that are configured. The PF will always print a statistics block for each +of the possible VFs, and it will show zero for all unconfigured VFs. + + +Configuring VLAN Tagging on SR-IOV Enabled Adapter Ports +-------------------------------------------------------- +To configure VLAN tagging for the ports on an SR-IOV enabled adapter, use the +following command. The VLAN configuration should be done before the VF driver +is loaded or the VM is booted. The VF is not aware of the VLAN tag being +inserted on transmit and removed on received frames (sometimes called "port +VLAN" mode). + +:: + + # ip link set dev <ethX> vf <id> vlan <vlan id> + +For example, the following will configure PF eth0 and the first VF on VLAN 10:: + + # ip link set dev eth0 vf 0 vlan 10 + + +Enabling a VF link if the port is disconnected +---------------------------------------------- +If the physical function (PF) link is down, you can force link up (from the +host PF) on any virtual functions (VF) bound to the PF. + +For example, to force link up on VF 0 bound to PF eth0:: + + # ip link set eth0 vf 0 state enable + +Note: If the command does not work, it may not be supported by your system. + + +Setting the MAC Address for a VF +-------------------------------- +To change the MAC address for the specified VF:: + + # ip link set <ethX> vf 0 mac <address> + +For example:: + + # ip link set <ethX> vf 0 mac 00:01:02:03:04:05 + +This setting lasts until the PF is reloaded. + +NOTE: Assigning a MAC address for a VF from the host will disable any +subsequent requests to change the MAC address from within the VM. This is a +security feature. The VM is not aware of this restriction, so if this is +attempted in the VM, it will trigger MDD events. + + +Trusted VFs and VF Promiscuous Mode +----------------------------------- +This feature allows you to designate a particular VF as trusted and allows that +trusted VF to request selective promiscuous mode on the Physical Function (PF). + +To set a VF as trusted or untrusted, enter the following command in the +Hypervisor:: + + # ip link set dev <ethX> vf 1 trust [on|off] + +NOTE: It's important to set the VF to trusted before setting promiscuous mode. +If the VM is not trusted, the PF will ignore promiscuous mode requests from the +VF. If the VM becomes trusted after the VF driver is loaded, you must make a +new request to set the VF to promiscuous. + +Once the VF is designated as trusted, use the following commands in the VM to +set the VF to promiscuous mode. + +For promiscuous all:: + + # ip link set <ethX> promisc on + Where <ethX> is a VF interface in the VM + +For promiscuous Multicast:: + + # ip link set <ethX> allmulticast on + Where <ethX> is a VF interface in the VM + +NOTE: By default, the ethtool private flag vf-true-promisc-support is set to +"off," meaning that promiscuous mode for the VF will be limited. To set the +promiscuous mode for the VF to true promiscuous and allow the VF to see all +ingress traffic, use the following command:: + + # ethtool --set-priv-flags <ethX> vf-true-promisc-support on + +The vf-true-promisc-support private flag does not enable promiscuous mode; +rather, it designates which type of promiscuous mode (limited or true) you will +get when you enable promiscuous mode using the ip link commands above. Note +that this is a global setting that affects the entire device. However, the +vf-true-promisc-support private flag is only exposed to the first PF of the +device. The PF remains in limited promiscuous mode regardless of the +vf-true-promisc-support setting. + +Next, add a VLAN interface on the VF interface. For example:: + + # ip link add link eth2 name eth2.100 type vlan id 100 + +Note that the order in which you set the VF to promiscuous mode and add the +VLAN interface does not matter (you can do either first). The result in this +example is that the VF will get all traffic that is tagged with VLAN 100. + + +Malicious Driver Detection (MDD) for VFs +---------------------------------------- +Some Intel Ethernet devices use Malicious Driver Detection (MDD) to detect +malicious traffic from the VF and disable Tx/Rx queues or drop the offending +packet until a VF driver reset occurs. You can view MDD messages in the PF's +system log using the dmesg command. + +- If the PF driver logs MDD events from the VF, confirm that the correct VF + driver is installed. +- To restore functionality, you can manually reload the VF or VM or enable + automatic VF resets. +- When automatic VF resets are enabled, the PF driver will immediately reset + the VF and reenable queues when it detects MDD events on the receive path. +- If automatic VF resets are disabled, the PF will not automatically reset the + VF when it detects MDD events. + +To enable or disable automatic VF resets, use the following command:: + + # ethtool --set-priv-flags <ethX> mdd-auto-reset-vf on|off + + +MAC and VLAN Anti-Spoofing Feature for VFs +------------------------------------------ +When a malicious driver on a Virtual Function (VF) interface attempts to send a +spoofed packet, it is dropped by the hardware and not transmitted. + +NOTE: This feature can be disabled for a specific VF:: + + # ip link set <ethX> vf <vf id> spoofchk {off|on} + + +Jumbo Frames +------------ +Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU) +to a value larger than the default value of 1500. + +Use the ifconfig command to increase the MTU size. For example, enter the +following where <ethX> is the interface number:: + + # ifconfig <ethX> mtu 9000 up + +Alternatively, you can use the ip command as follows:: + + # ip link set mtu 9000 dev <ethX> + # ip link set up dev <ethX> + +This setting is not saved across reboots. + + +NOTE: The maximum MTU setting for jumbo frames is 9702. This corresponds to the +maximum jumbo frame size of 9728 bytes. + +NOTE: This driver will attempt to use multiple page sized buffers to receive +each jumbo packet. This should help to avoid buffer starvation issues when +allocating receive packets. + +NOTE: Packet loss may have a greater impact on throughput when you use jumbo +frames. If you observe a drop in performance after enabling jumbo frames, +enabling flow control may mitigate the issue. + + +Speed and Duplex Configuration +------------------------------ +In addressing speed and duplex configuration issues, you need to distinguish +between copper-based adapters and fiber-based adapters. + +In the default mode, an Intel(R) Ethernet Network Adapter using copper +connections will attempt to auto-negotiate with its link partner to determine +the best setting. If the adapter cannot establish link with the link partner +using auto-negotiation, you may need to manually configure the adapter and link +partner to identical settings to establish link and pass packets. This should +only be needed when attempting to link with an older switch that does not +support auto-negotiation or one that has been forced to a specific speed or +duplex mode. Your link partner must match the setting you choose. 1 Gbps speeds +and higher cannot be forced. Use the autonegotiation advertising setting to +manually set devices for 1 Gbps and higher. + +Speed, duplex, and autonegotiation advertising are configured through the +ethtool utility. For the latest version, download and install ethtool from the +following website: + + https://kernel.org/pub/software/network/ethtool/ + +To see the speed configurations your device supports, run the following:: + + # ethtool <ethX> + +Caution: Only experienced network administrators should force speed and duplex +or change autonegotiation advertising manually. The settings at the switch must +always match the adapter settings. Adapter performance may suffer or your +adapter may not operate if you configure the adapter differently from your +switch. + + +Data Center Bridging (DCB) +-------------------------- +NOTE: The kernel assumes that TC0 is available, and will disable Priority Flow +Control (PFC) on the device if TC0 is not available. To fix this, ensure TC0 is +enabled when setting up DCB on your switch. + +DCB is a configuration Quality of Service implementation in hardware. It uses +the VLAN priority tag (802.1p) to filter traffic. That means that there are 8 +different priorities that traffic can be filtered into. It also enables +priority flow control (802.1Qbb) which can limit or eliminate the number of +dropped packets during network stress. Bandwidth can be allocated to each of +these priorities, which is enforced at the hardware level (802.1Qaz). + +DCB is normally configured on the network using the DCBX protocol (802.1Qaz), a +specialization of LLDP (802.1AB). The ice driver supports the following +mutually exclusive variants of DCBX support: + +1) Firmware-based LLDP Agent +2) Software-based LLDP Agent + +In firmware-based mode, firmware intercepts all LLDP traffic and handles DCBX +negotiation transparently for the user. In this mode, the adapter operates in +"willing" DCBX mode, receiving DCB settings from the link partner (typically a +switch). The local user can only query the negotiated DCB configuration. For +information on configuring DCBX parameters on a switch, please consult the +switch manufacturer's documentation. + +In software-based mode, LLDP traffic is forwarded to the network stack and user +space, where a software agent can handle it. In this mode, the adapter can +operate in either "willing" or "nonwilling" DCBX mode and DCB configuration can +be both queried and set locally. This mode requires the FW-based LLDP Agent to +be disabled. + +NOTE: + +- You can enable and disable the firmware-based LLDP Agent using an ethtool + private flag. Refer to the "FW-LLDP (Firmware Link Layer Discovery Protocol)" + section in this README for more information. +- In software-based DCBX mode, you can configure DCB parameters using software + LLDP/DCBX agents that interface with the Linux kernel's DCB Netlink API. We + recommend using OpenLLDP as the DCBX agent when running in software mode. For + more information, see the OpenLLDP man pages and + https://github.com/intel/openlldp. +- The driver implements the DCB netlink interface layer to allow the user space + to communicate with the driver and query DCB configuration for the port. +- iSCSI with DCB is not supported. + + +FW-LLDP (Firmware Link Layer Discovery Protocol) +------------------------------------------------ +Use ethtool to change FW-LLDP settings. The FW-LLDP setting is per port and +persists across boots. + +To enable LLDP:: + + # ethtool --set-priv-flags <ethX> fw-lldp-agent on + +To disable LLDP:: + + # ethtool --set-priv-flags <ethX> fw-lldp-agent off + +To check the current LLDP setting:: + + # ethtool --show-priv-flags <ethX> + +NOTE: You must enable the UEFI HII "LLDP Agent" attribute for this setting to +take effect. If "LLDP AGENT" is set to disabled, you cannot enable it from the +OS. + + +Flow Control +------------ +Ethernet Flow Control (IEEE 802.3x) can be configured with ethtool to enable +receiving and transmitting pause frames for ice. When transmit is enabled, +pause frames are generated when the receive packet buffer crosses a predefined +threshold. When receive is enabled, the transmit unit will halt for the time +delay specified when a pause frame is received. + +NOTE: You must have a flow control capable link partner. + +Flow Control is disabled by default. + +Use ethtool to change the flow control settings. + +To enable or disable Rx or Tx Flow Control:: + + # ethtool -A <ethX> rx <on|off> tx <on|off> + +Note: This command only enables or disables Flow Control if auto-negotiation is +disabled. If auto-negotiation is enabled, this command changes the parameters +used for auto-negotiation with the link partner. + +Note: Flow Control auto-negotiation is part of link auto-negotiation. Depending +on your device, you may not be able to change the auto-negotiation setting. + +NOTE: + +- The ice driver requires flow control on both the port and link partner. If + flow control is disabled on one of the sides, the port may appear to hang on + heavy traffic. +- You may encounter issues with link-level flow control (LFC) after disabling + DCB. The LFC status may show as enabled but traffic is not paused. To resolve + this issue, disable and reenable LFC using ethtool:: + + # ethtool -A <ethX> rx off tx off + # ethtool -A <ethX> rx on tx on + + +NAPI +---- + +This driver supports NAPI (Rx polling mode). + +See :ref:`Documentation/networking/napi.rst <napi>` for more information. + +MACVLAN +------- +This driver supports MACVLAN. Kernel support for MACVLAN can be tested by +checking if the MACVLAN driver is loaded. You can run 'lsmod | grep macvlan' to +see if the MACVLAN driver is loaded or run 'modprobe macvlan' to try to load +the MACVLAN driver. + +NOTE: + +- In passthru mode, you can only set up one MACVLAN device. It will inherit the + MAC address of the underlying PF (Physical Function) device. + + +IEEE 802.1ad (QinQ) Support +--------------------------- +The IEEE 802.1ad standard, informally known as QinQ, allows for multiple VLAN +IDs within a single Ethernet frame. VLAN IDs are sometimes referred to as +"tags," and multiple VLAN IDs are thus referred to as a "tag stack." Tag stacks +allow L2 tunneling and the ability to segregate traffic within a particular +VLAN ID, among other uses. + +NOTES: + +- Receive checksum offloads and VLAN acceleration are not supported for 802.1ad + (QinQ) packets. + +- 0x88A8 traffic will not be received unless VLAN stripping is disabled with + the following command:: + + # ethtool -K <ethX> rxvlan off + +- 0x88A8/0x8100 double VLANs cannot be used with 0x8100 or 0x8100/0x8100 VLANS + configured on the same port. 0x88a8/0x8100 traffic will not be received if + 0x8100 VLANs are configured. + +- The VF can only transmit 0x88A8/0x8100 (i.e., 802.1ad/802.1Q) traffic if: + + 1) The VF is not assigned a port VLAN. + 2) spoofchk is disabled from the PF. If you enable spoofchk, the VF will + not transmit 0x88A8/0x8100 traffic. + +- The VF may not receive all network traffic based on the Inner VLAN header + when VF true promiscuous mode (vf-true-promisc-support) and double VLANs are + enabled in SR-IOV mode. + +The following are examples of how to configure 802.1ad (QinQ):: + + # ip link add link eth0 eth0.24 type vlan proto 802.1ad id 24 + # ip link add link eth0.24 eth0.24.371 type vlan proto 802.1Q id 371 + + Where "24" and "371" are example VLAN IDs. + + +Tunnel/Overlay Stateless Offloads +--------------------------------- +Supported tunnels and overlays include VXLAN, GENEVE, and others depending on +hardware and software configuration. Stateless offloads are enabled by default. + +To view the current state of all offloads:: + + # ethtool -k <ethX> + + +UDP Segmentation Offload +------------------------ +Allows the adapter to offload transmit segmentation of UDP packets with +payloads up to 64K into valid Ethernet frames. Because the adapter hardware is +able to complete data segmentation much faster than operating system software, +this feature may improve transmission performance. +In addition, the adapter may use fewer CPU resources. + +NOTE: + +- The application sending UDP packets must support UDP segmentation offload. + +To enable/disable UDP Segmentation Offload, issue the following command:: + + # ethtool -K <ethX> tx-udp-segmentation [off|on] + + +GNSS module +----------- +Requires kernel compiled with CONFIG_GNSS=y or CONFIG_GNSS=m. +Allows user to read messages from the GNSS hardware module and write supported +commands. If the module is physically present, a GNSS device is spawned: +``/dev/gnss<id>``. +The protocol of write command is dependent on the GNSS hardware module as the +driver writes raw bytes by the GNSS object to the receiver through i2c. Please +refer to the hardware GNSS module documentation for configuration details. + + +Firmware (FW) logging +--------------------- +The driver supports FW logging via the debugfs interface on PF 0 only. The FW +running on the NIC must support FW logging; if the FW doesn't support FW logging +the 'fwlog' file will not get created in the ice debugfs directory. + +Module configuration +~~~~~~~~~~~~~~~~~~~~ +Firmware logging is configured on a per module basis. Each module can be set to +a value independent of the other modules (unless the module 'all' is specified). +The modules will be instantiated under the 'fwlog/modules' directory. + +The user can set the log level for a module by writing to the module file like +this:: + + # echo <log_level> > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/<module> + +where + +* log_level is a name as described below. Each level includes the + messages from the previous/lower level + + * none + * error + * warning + * normal + * verbose + +* module is a name that represents the module to receive events for. The + module names are + + * general + * ctrl + * link + * link_topo + * dnl + * i2c + * sdp + * mdio + * adminq + * hdma + * lldp + * dcbx + * dcb + * xlr + * nvm + * auth + * vpd + * iosf + * parser + * sw + * scheduler + * txq + * rsvd + * post + * watchdog + * task_dispatch + * mng + * synce + * health + * tsdrv + * pfreg + * mdlver + * all + +The name 'all' is special and allows the user to set all of the modules to the +specified log_level or to read the log_level of all of the modules. + +Example usage to configure the modules +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +To set a single module to 'verbose':: + + # echo verbose > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/link + +To set multiple modules then issue the command multiple times:: + + # echo verbose > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/link + # echo warning > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/ctrl + # echo none > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/dcb + +To set all the modules to the same value:: + + # echo normal > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all + +To read the log_level of a specific module (e.g. module 'general'):: + + # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/general + +To read the log_level of all the modules:: + + # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/modules/all + +Enabling FW log +~~~~~~~~~~~~~~~ +Configuring the modules indicates to the FW that the configured modules should +generate events that the driver is interested in, but it **does not** send the +events to the driver until the enable message is sent to the FW. To do this +the user can write a 1 (enable) or 0 (disable) to 'fwlog/enable'. An example +is:: + + # echo 1 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/enable + +Retrieving FW log data +~~~~~~~~~~~~~~~~~~~~~~ +The FW log data can be retrieved by reading from 'fwlog/data'. The user can +write any value to 'fwlog/data' to clear the data. The data can only be cleared +when FW logging is disabled. The FW log data is a binary file that is sent to +Intel and used to help debug user issues. + +An example to read the data is:: + + # cat /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data > fwlog.bin + +An example to clear the data is:: + + # echo 0 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/data + +Changing how often the log events are sent to the driver +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver receives FW log data from the Admin Receive Queue (ARQ). The +frequency that the FW sends the ARQ events can be configured by writing to +'fwlog/nr_messages'. The range is 1-128 (1 means push every log message, 128 +means push only when the max AQ command buffer is full). The suggested value is +10. The user can see what the value is configured to by reading +'fwlog/nr_messages'. An example to set the value is:: + + # echo 50 > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/nr_messages + +Configuring the amount of memory used to store FW log data +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver stores FW log data within the driver. The default size of the memory +used to store the data is 1MB. Some use cases may require more or less data so +the user can change the amount of memory that is allocated for FW log data. +To change the amount of memory then write to 'fwlog/log_size'. The value must be +one of: 128K, 256K, 512K, 1M, or 2M. FW logging must be disabled to change the +value. An example of changing the value is:: + + # echo 128K > /sys/kernel/debug/ice/0000\:18\:00.0/fwlog/log_size + + +Performance Optimization +======================== +Driver defaults are meant to fit a wide variety of workloads, but if further +optimization is required, we recommend experimenting with the following +settings. + + +Rx Descriptor Ring Size +----------------------- +To reduce the number of Rx packet discards, increase the number of Rx +descriptors for each Rx ring using ethtool. + + Check if the interface is dropping Rx packets due to buffers being full + (rx_dropped.nic can mean that there is no PCIe bandwidth):: + + # ethtool -S <ethX> | grep "rx_dropped" + + If the previous command shows drops on queues, it may help to increase + the number of descriptors using 'ethtool -G':: + + # ethtool -G <ethX> rx <N> + Where <N> is the desired number of ring entries/descriptors + + This can provide temporary buffering for issues that create latency while + the CPUs process descriptors. + + +Interrupt Rate Limiting +----------------------- +This driver supports an adaptive interrupt throttle rate (ITR) mechanism that +is tuned for general workloads. The user can customize the interrupt rate +control for specific workloads, via ethtool, adjusting the number of +microseconds between interrupts. + +To set the interrupt rate manually, you must disable adaptive mode:: + + # ethtool -C <ethX> adaptive-rx off adaptive-tx off + +For lower CPU utilization: + + Disable adaptive ITR and lower Rx and Tx interrupts. The examples below + affect every queue of the specified interface. + + Setting rx-usecs and tx-usecs to 80 will limit interrupts to about + 12,500 interrupts per second per queue:: + + # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 80 tx-usecs 80 + +For reduced latency: + + Disable adaptive ITR and ITR by setting rx-usecs and tx-usecs to 0 + using ethtool:: + + # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 0 tx-usecs 0 + +Per-queue interrupt rate settings: + + The following examples are for queues 1 and 3, but you can adjust other + queues. + + To disable Rx adaptive ITR and set static Rx ITR to 10 microseconds or + about 100,000 interrupts/second, for queues 1 and 3:: + + # ethtool --per-queue <ethX> queue_mask 0xa --coalesce adaptive-rx off + rx-usecs 10 + + To show the current coalesce settings for queues 1 and 3:: + + # ethtool --per-queue <ethX> queue_mask 0xa --show-coalesce + +Bounding interrupt rates using rx-usecs-high: + + :Valid Range: 0-236 (0=no limit) + + The range of 0-236 microseconds provides an effective range of 4,237 to + 250,000 interrupts per second. The value of rx-usecs-high can be set + independently of rx-usecs and tx-usecs in the same ethtool command, and is + also independent of the adaptive interrupt moderation algorithm. The + underlying hardware supports granularity in 4-microsecond intervals, so + adjacent values may result in the same interrupt rate. + + The following command would disable adaptive interrupt moderation, and allow + a maximum of 5 microseconds before indicating a receive or transmit was + complete. However, instead of resulting in as many as 200,000 interrupts per + second, it limits total interrupts per second to 50,000 via the rx-usecs-high + parameter. + + :: + + # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs-high 20 + rx-usecs 5 tx-usecs 5 + + +Virtualized Environments +------------------------ +In addition to the other suggestions in this section, the following may be +helpful to optimize performance in VMs. + + Using the appropriate mechanism (vcpupin) in the VM, pin the CPUs to + individual LCPUs, making sure to use a set of CPUs included in the + device's local_cpulist: ``/sys/class/net/<ethX>/device/local_cpulist``. + + Configure as many Rx/Tx queues in the VM as available. (See the iavf driver + documentation for the number of queues supported.) For example:: + + # ethtool -L <virt_interface> rx <max> tx <max> + + +Support +======= +For general information, go to the Intel support website at: +https://www.intel.com/support/ + +If an issue is identified with the released source code on a supported kernel +with a supported adapter, email the specific information related to the issue +to intel-wired-lan@lists.osuosl.org. + + +Trademarks +========== +Intel is a trademark or registered trademark of Intel Corporation or its +subsidiaries in the United States and/or other countries. + +* Other names and brands may be claimed as the property of others. diff --git a/Documentation/networking/device_drivers/ethernet/intel/idpf.rst b/Documentation/networking/device_drivers/ethernet/intel/idpf.rst new file mode 100644 index 000000000000..adb16e2abd21 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/intel/idpf.rst @@ -0,0 +1,160 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +========================================================================== +idpf Linux* Base Driver for the Intel(R) Infrastructure Data Path Function +========================================================================== + +Intel idpf Linux driver. +Copyright(C) 2023 Intel Corporation. + +.. contents:: + +The idpf driver serves as both the Physical Function (PF) and Virtual Function +(VF) driver for the Intel(R) Infrastructure Data Path Function. + +Driver information can be obtained using ethtool, lspci, and ip. + +For questions related to hardware requirements, refer to the documentation +supplied with your Intel adapter. All hardware requirements listed apply to use +with Linux. + + +Identifying Your Adapter +======================== +For information on how to identify your adapter, and for the latest Intel +network drivers, refer to the Intel Support website: +http://www.intel.com/support + + +Additional Features and Configurations +====================================== + +ethtool +------- +The driver utilizes the ethtool interface for driver configuration and +diagnostics, as well as displaying statistical information. The latest ethtool +version is required for this functionality. If you don't have one yet, you can +obtain it at: +https://kernel.org/pub/software/network/ethtool/ + + +Viewing Link Messages +--------------------- +Link messages will not be displayed to the console if the distribution is +restricting system messages. In order to see network driver link messages on +your console, set dmesg to eight by entering the following:: + + # dmesg -n 8 + +.. note:: + This setting is not saved across reboots. + + +Jumbo Frames +------------ +Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU) +to a value larger than the default value of 1500. + +Use the ip command to increase the MTU size. For example, enter the following +where <ethX> is the interface number:: + + # ip link set mtu 9000 dev <ethX> + # ip link set up dev <ethX> + +.. note:: + The maximum MTU setting for jumbo frames is 9706. This corresponds to the + maximum jumbo frame size of 9728 bytes. + +.. note:: + This driver will attempt to use multiple page sized buffers to receive + each jumbo packet. This should help to avoid buffer starvation issues when + allocating receive packets. + +.. note:: + Packet loss may have a greater impact on throughput when you use jumbo + frames. If you observe a drop in performance after enabling jumbo frames, + enabling flow control may mitigate the issue. + + +Performance Optimization +======================== +Driver defaults are meant to fit a wide variety of workloads, but if further +optimization is required, we recommend experimenting with the following +settings. + + +Interrupt Rate Limiting +----------------------- +This driver supports an adaptive interrupt throttle rate (ITR) mechanism that +is tuned for general workloads. The user can customize the interrupt rate +control for specific workloads, via ethtool, adjusting the number of +microseconds between interrupts. + +To set the interrupt rate manually, you must disable adaptive mode:: + + # ethtool -C <ethX> adaptive-rx off adaptive-tx off + +For lower CPU utilization: + - Disable adaptive ITR and lower Rx and Tx interrupts. The examples below + affect every queue of the specified interface. + + - Setting rx-usecs and tx-usecs to 80 will limit interrupts to about + 12,500 interrupts per second per queue:: + + # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 80 + tx-usecs 80 + +For reduced latency: + - Disable adaptive ITR and ITR by setting rx-usecs and tx-usecs to 0 + using ethtool:: + + # ethtool -C <ethX> adaptive-rx off adaptive-tx off rx-usecs 0 + tx-usecs 0 + +Per-queue interrupt rate settings: + - The following examples are for queues 1 and 3, but you can adjust other + queues. + + - To disable Rx adaptive ITR and set static Rx ITR to 10 microseconds or + about 100,000 interrupts/second, for queues 1 and 3:: + + # ethtool --per-queue <ethX> queue_mask 0xa --coalesce adaptive-rx off + rx-usecs 10 + + - To show the current coalesce settings for queues 1 and 3:: + + # ethtool --per-queue <ethX> queue_mask 0xa --show-coalesce + + + +Virtualized Environments +------------------------ +In addition to the other suggestions in this section, the following may be +helpful to optimize performance in VMs. + + - Using the appropriate mechanism (vcpupin) in the VM, pin the CPUs to + individual LCPUs, making sure to use a set of CPUs included in the + device's local_cpulist: /sys/class/net/<ethX>/device/local_cpulist. + + - Configure as many Rx/Tx queues in the VM as available. (See the idpf driver + documentation for the number of queues supported.) For example:: + + # ethtool -L <virt_interface> rx <max> tx <max> + + +Support +======= +For general information, go to the Intel support website at: +http://www.intel.com/support/ + +If an issue is identified with the released source code on a supported kernel +with a supported adapter, email the specific information related to the issue +to intel-wired-lan@lists.osuosl.org. + + +Trademarks +========== +Intel is a trademark or registered trademark of Intel Corporation or its +subsidiaries in the United States and/or other countries. + +* Other names and brands may be claimed as the property of others. diff --git a/Documentation/networking/device_drivers/intel/igb.rst b/Documentation/networking/device_drivers/ethernet/intel/igb.rst index 87e560fe5eaa..fbd590b6a0d6 100644 --- a/Documentation/networking/device_drivers/intel/igb.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igb.rst @@ -20,7 +20,7 @@ Identifying Your Adapter ======================== For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Command Line Parameters @@ -201,13 +201,8 @@ NOTE: This feature is exclusive to i210 models. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/igbvf.rst b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst index 557fc020ef31..11a9017f3069 100644 --- a/Documentation/networking/device_drivers/intel/igbvf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/igbvf.rst @@ -35,7 +35,7 @@ Identifying Your Adapter ======================== For information on how to identify your adapter, and for the latest Intel network drivers, refer to the Intel Support website: -http://www.intel.com/support +https://www.intel.com/support Additional Features and Configurations @@ -53,13 +53,8 @@ https://www.kernel.org/pub/software/network/ethtool/ Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/ixgbe.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst index f1d5233e5e51..1e5f16993f69 100644 --- a/Documentation/networking/device_drivers/intel/ixgbe.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst @@ -440,6 +440,22 @@ NOTE: For 82599-based network connections, if you are enabling jumbo frames in a virtual function (VF), jumbo frames must first be enabled in the physical function (PF). The VF MTU setting cannot be larger than the PF MTU. +NBASE-T Support +--------------- +The ixgbe driver supports NBASE-T on some devices. However, the advertisement +of NBASE-T speeds is suppressed by default, to accommodate broken network +switches which cannot cope with advertised NBASE-T speeds. Use the ethtool +command to enable advertising NBASE-T speeds on devices which support it:: + + ethtool -s eth? advertise 0x1800000001028 + +On Linux systems with INTERFACES(5), this can be specified as a pre-up command +in /etc/network/interfaces so that the interface is always brought up with +NBASE-T support, e.g.:: + + iface eth? inet dhcp + pre-up ethtool -s eth? advertise 0x1800000001028 || true + Generic Receive Offload, aka GRO -------------------------------- The driver supports the in-kernel software implementation of GRO. GRO has @@ -529,13 +545,8 @@ on the Intel Ethernet Controller XL710. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/intel/ixgbevf.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst index 76bbde736f21..08dc0d368a48 100644 --- a/Documentation/networking/device_drivers/intel/ixgbevf.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbevf.rst @@ -55,13 +55,8 @@ VLANs: There is a limit of a total of 64 shared VLANs to 1 or more VFs. Support ======= For general information, go to the Intel support website at: - https://www.intel.com/support/ -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. +to intel-wired-lan@lists.osuosl.org. diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst new file mode 100644 index 000000000000..c96d262b30be --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep.rst @@ -0,0 +1,41 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +==================================================================== +Linux kernel networking driver for Marvell's Octeon PCI Endpoint NIC +==================================================================== + +Network driver for Marvell's Octeon PCI EndPoint NIC. +Copyright (c) 2020 Marvell International Ltd. + +Contents +======== + +- `Overview`_ +- `Supported Devices`_ +- `Interface Control`_ + +Overview +======== +This driver implements networking functionality of Marvell's Octeon PCI +EndPoint NIC. + +Supported Devices +================= +Currently, this driver support following devices: + * Network controller: Cavium, Inc. Device b100 + * Network controller: Cavium, Inc. Device b200 + * Network controller: Cavium, Inc. Device b400 + * Network controller: Cavium, Inc. Device b900 + * Network controller: Cavium, Inc. Device ba00 + * Network controller: Cavium, Inc. Device bc00 + * Network controller: Cavium, Inc. Device bd00 + +Interface Control +================= +Network Interface control like changing mtu, link speed, link down/up are +done by writing command to mailbox command queue, a mailbox interface +implemented through a reserved region in BAR4. +This driver writes the commands into the mailbox and the firmware on the +Octeon device processes them. The firmware also sends unsolicited notifications +to driver for events suchs as link change, through notification queue +implemented as part of mailbox interface. diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep_vf.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep_vf.rst new file mode 100644 index 000000000000..603133d0b92f --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeon_ep_vf.rst @@ -0,0 +1,24 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +======================================================================= +Linux kernel networking driver for Marvell's Octeon PCI Endpoint NIC VF +======================================================================= + +Network driver for Marvell's Octeon PCI EndPoint NIC VF. +Copyright (c) 2020 Marvell International Ltd. + +Overview +======== +This driver implements networking functionality of Marvell's Octeon PCI +EndPoint NIC VF. + +Supported Devices +================= +Currently, this driver support following devices: + * Network controller: Cavium, Inc. Device b203 + * Network controller: Cavium, Inc. Device b403 + * Network controller: Cavium, Inc. Device b103 + * Network controller: Cavium, Inc. Device b903 + * Network controller: Cavium, Inc. Device ba03 + * Network controller: Cavium, Inc. Device bc03 + * Network controller: Cavium, Inc. Device bd03 diff --git a/Documentation/networking/device_drivers/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index 88f508338c5f..1e196cb9ce25 100644 --- a/Documentation/networking/device_drivers/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst @@ -12,6 +12,8 @@ Contents - `Overview`_ - `Drivers`_ - `Basic packet flow`_ +- `Devlink health reporters`_ +- `Quality of service`_ Overview ======== @@ -126,7 +128,7 @@ Type1: Type2: - RVU PF0 ie admin function creates these VFs and maps them to loopback block's channels. - A set of two VFs (VF0 & VF1, VF2 & VF3 .. so on) works as a pair ie pkts sent out of - VF0 will be received by VF1 and viceversa. + VF0 will be received by VF1 and vice versa. - These VFs can be used by applications or virtual machines to communicate between them without sending traffic outside. There is no switch present in HW, hence the support for loopback VFs. @@ -157,3 +159,184 @@ 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 example:: + + ~# 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 + + +NIX Reporters +------------- +The NIX reporters are responsible for reporting and recovering the following group of errors: + +1. GENERAL events + + - Receive mirror/multicast packet drop due to insufficient buffer. + - SMQ Flush operation. + +2. ERROR events + + - Memory Fault due to WQE read/write from multicast/mirror buffer. + - Receive multicast/mirror replication list error. + - Receive packet on an unmapped PF. + - Fault due to NIX_AQ_INST_S read or NIX_AQ_RES_S write. + - AQ Doorbell Error. + +3. RAS events + + - RAS Error Reporting for NIX Receive Multicast/Mirror Entry Structure. + - RAS Error Reporting for WQE/Packet Data read from Multicast/Mirror Buffer.. + - RAS Error Reporting for NIX_AQ_INST_S/NIX_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 0 recover 0 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_gen + state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_err + state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_ras + state healthy error 0 recover 0 grace_period 0 auto_recover true auto_dump true + reporter hw_nix_intr + state healthy error 1121 recover 1121 last_dump_date 2021-01-19 last_dump_time 05:42:26 grace_period 0 auto_recover true auto_dump true + reporter hw_nix_gen + state healthy error 949 recover 949 last_dump_date 2021-01-19 last_dump_time 05:42:43 grace_period 0 auto_recover true auto_dump true + reporter hw_nix_err + state healthy error 1147 recover 1147 last_dump_date 2021-01-19 last_dump_time 05:42:59 grace_period 0 auto_recover true auto_dump true + reporter hw_nix_ras + state healthy error 409 recover 409 last_dump_date 2021-01-19 last_dump_time 05:43:16 grace_period 0 auto_recover true auto_dump true + +Each reporter dumps the + + - Error Type + - Error Register value + - Reason in words + +For example:: + + ~# devlink health dump show pci/0002:01:00.0 reporter hw_nix_intr + NIX_AF_RVU: + NIX RVU Interrupt Reg : 1 + Unmap Slot Error + ~# devlink health dump show pci/0002:01:00.0 reporter hw_nix_gen + NIX_AF_GENERAL: + NIX General Interrupt Reg : 1 + Rx multicast pkt drop + ~# devlink health dump show pci/0002:01:00.0 reporter hw_nix_err + NIX_AF_ERR: + NIX Error Interrupt Reg : 64 + Rx on unmapped PF_FUNC + + +Quality of service +================== + + +Hardware algorithms used in scheduling +-------------------------------------- + +octeontx2 silicon and CN10K transmit interface consists of five transmit levels +starting from SMQ/MDQ, TL4 to TL1. Each packet will traverse MDQ, TL4 to TL1 +levels. Each level contains an array of queues to support scheduling and shaping. +The hardware uses the below algorithms depending on the priority of scheduler queues. +once the usercreates tc classes with different priorities, the driver configures +schedulers allocated to the class with specified priority along with rate-limiting +configuration. + +1. Strict Priority + + - Once packets are submitted to MDQ, hardware picks all active MDQs having different priority + using strict priority. + +2. Round Robin + + - Active MDQs having the same priority level are chosen using round robin. + + +Setup HTB offload +----------------- + +1. Enable HW TC offload on the interface:: + + # ethtool -K <interface> hw-tc-offload on + +2. Crate htb root:: + + # tc qdisc add dev <interface> clsact + # tc qdisc replace dev <interface> root handle 1: htb offload + +3. Create tc classes with different priorities:: + + # tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 1 + + # tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 7 + +4. Create tc classes with same priorities and different quantum:: + + # tc class add dev <interface> parent 1: classid 1:1 htb rate 10Gbit prio 2 quantum 409600 + + # tc class add dev <interface> parent 1: classid 1:2 htb rate 10Gbit prio 2 quantum 188416 + + # tc class add dev <interface> parent 1: classid 1:3 htb rate 10Gbit prio 2 quantum 32768 diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst new file mode 100644 index 000000000000..f69ee1ebee01 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/counters.rst @@ -0,0 +1,1305 @@ +.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB +.. include:: <isonum.txt> + +================ +Ethtool counters +================ + +:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. + +Contents +======== + +- `Overview`_ +- `Groups`_ +- `Types`_ +- `Descriptions`_ + +Overview +======== + +There are several counter groups based on where the counter is being counted. In +addition, each group of counters may have different counter types. + +These counter groups are based on which component in a networking setup, +illustrated below, that they describe:: + + ---------------------------------------- + | | + ---------------------------------------- ---------------------------------------- | + | Hypervisor | | VM | | + | | | | | + | ------------------- --------------- | | ------------------- --------------- | | + | | Ethernet driver | | RDMA driver | | | | Ethernet driver | | RDMA driver | | | + | ------------------- --------------- | | ------------------- --------------- | | + | | | | | | | | | + | ------------------- | | ------------------- | | + | | | | | |-- + ---------------------------------------- ---------------------------------------- + | | + ------------- ----------------------------- + | | + ------ ------ ------ ------ ------ ------ ------ + -----| PF |----------------------| VF |-| VF |-| VF |----- --| PF |--- --| PF |--- --| PF |--- + | ------ ------ ------ ------ | | ------ | | ------ | | ------ | + | | | | | | | | + | | | | | | | | + | | | | | | | | + | eSwitch | | eSwitch | | eSwitch | | eSwitch | + ---------------------------------------------------------- ----------- ----------- ----------- + ------------------------------------------------------------------------------- + | | + | | + | Uplink (no counters) | + ------------------------------------------------------------------------------- + --------------------------------------------------------------- + | | + | | + | MPFS (no counters) | + --------------------------------------------------------------- + | + | + | Port + +Groups +====== + +Ring + Software counters populated by the driver stack. + +Netdev + An aggregation of software ring counters. + +vPort counters + Traffic counters and drops due to steering or no buffers. May indicate issues + with NIC. These counters include Ethernet traffic counters (including Raw + Ethernet) and RDMA/RoCE traffic counters. + +Physical port counters + Counters that collect statistics about the PFs and VFs. May indicate issues + with NIC, link, or network. This measuring point holds information on + standardized counters like IEEE 802.3, RFC2863, RFC 2819, RFC 3635 and + additional counters like flow control, FEC and more. Physical port counters + are not exposed to virtual machines. + +Priority Port Counters + A set of the physical port counters, per priority per port. + +Types +===== + +Counters are divided into three types. + +Traffic Informative Counters + Counters which count traffic. These counters can be used for load estimation + or for general debug. + +Traffic Acceleration Counters + Counters which count traffic that was accelerated by Mellanox driver or by + hardware. The counters are an additional layer to the informative counter set, + and the same traffic is counted in both informative and acceleration counters. + +.. [#accel] Traffic acceleration counter. + +Error Counters + Increment of these counters might indicate a problem. Each of these counters + has an explanation and correction action. + +Statistic can be fetched via the `ip link` or `ethtool` commands. `ethtool` +provides more detailed information.:: + + ip –s link show <if-name> + ethtool -S <if-name> + +Descriptions +============ + +XSK, PTP, and QoS counters that are similar to counters defined previously will +not be separately listed. For example, `ptp_tx[i]_packets` will not be +explicitly documented since `tx[i]_packets` describes the behavior of both +counters, except `ptp_tx[i]_packets` is only counted when precision time +protocol is used. + +Ring / Netdev Counter +---------------------------- +The following counters are available per ring or software port. + +These counters provide information on the amount of traffic that was accelerated +by the NIC. The counters are counting the accelerated traffic in addition to the +standard counters which counts it (i.e. accelerated traffic is counted twice). + +The counter names in the table below refers to both ring and port counters. The +notation for ring counters includes the [i] index without the braces. The +notation for port counters doesn't include the [i]. A counter name +`rx[i]_packets` will be printed as `rx0_packets` for ring 0 and `rx_packets` for +the software port. + +.. flat-table:: Ring / Software Port Counter Table + :widths: 2 3 1 + + * - Counter + - Description + - Type + + * - `rx[i]_packets` + - The number of packets received on ring i. + - Informative + + * - `rx[i]_bytes` + - The number of bytes received on ring i. + - Informative + + * - `tx[i]_packets` + - The number of packets transmitted on ring i. + - Informative + + * - `tx[i]_bytes` + - The number of bytes transmitted on ring i. + - Informative + + * - `tx[i]_recover` + - The number of times the SQ was recovered. + - Error + + * - `tx[i]_cqes` + - Number of CQEs events on SQ issued on ring i. + - Informative + + * - `tx[i]_cqe_err` + - The number of error CQEs encountered on the SQ for ring i. + - Error + + * - `tx[i]_tso_packets` + - The number of TSO packets transmitted on ring i [#accel]_. + - Acceleration + + * - `tx[i]_tso_bytes` + - The number of TSO bytes transmitted on ring i [#accel]_. + - Acceleration + + * - `tx[i]_tso_inner_packets` + - The number of TSO packets which are indicated to be carry internal + encapsulation transmitted on ring i [#accel]_. + - Acceleration + + * - `tx[i]_tso_inner_bytes` + - The number of TSO bytes which are indicated to be carry internal + encapsulation transmitted on ring i [#accel]_. + - Acceleration + + * - `rx[i]_gro_packets` + - Number of received packets processed using hardware-accelerated GRO. The + number of hardware GRO offloaded packets received on ring i. + - Acceleration + + * - `rx[i]_gro_bytes` + - Number of received bytes processed using hardware-accelerated GRO. The + number of hardware GRO offloaded bytes received on ring i. + - Acceleration + + * - `rx[i]_gro_skbs` + - The number of receive SKBs constructed while performing + hardware-accelerated GRO. + - Informative + + * - `rx[i]_gro_match_packets` + - Number of received packets processed using hardware-accelerated GRO that + met the flow table match criteria. + - Informative + + * - `rx[i]_gro_large_hds` + - Number of receive packets using hardware-accelerated GRO that have large + headers that require additional memory to be allocated. + - Informative + + * - `rx[i]_lro_packets` + - The number of LRO packets received on ring i [#accel]_. + - Acceleration + + * - `rx[i]_lro_bytes` + - The number of LRO bytes received on ring i [#accel]_. + - Acceleration + + * - `rx[i]_ecn_mark` + - The number of received packets where the ECN mark was turned on. + - Informative + + * - `rx_oversize_pkts_buffer` + - The number of dropped received packets due to length which arrived to RQ + and exceed software buffer size allocated by the device for incoming + traffic. It might imply that the device MTU is larger than the software + buffers size. + - Error + + * - `rx_oversize_pkts_sw_drop` + - Number of received packets dropped in software because the CQE data is + larger than the MTU size. + - Error + + * - `rx[i]_csum_unnecessary` + - Packets received with a `CHECKSUM_UNNECESSARY` on ring i [#accel]_. + - Acceleration + + * - `rx[i]_csum_unnecessary_inner` + - Packets received with inner encapsulation with a `CHECKSUM_UNNECESSARY` + on ring i [#accel]_. + - Acceleration + + * - `rx[i]_csum_none` + - Packets received with a `CHECKSUM_NONE` on ring i [#accel]_. + - Acceleration + + * - `rx[i]_csum_complete` + - Packets received with a `CHECKSUM_COMPLETE` on ring i [#accel]_. + - Acceleration + + * - `rx[i]_csum_complete_tail` + - Number of received packets that had checksum calculation computed, + potentially needed padding, and were able to do so with + `CHECKSUM_PARTIAL`. + - Informative + + * - `rx[i]_csum_complete_tail_slow` + - Number of received packets that need padding larger than eight bytes for + the checksum. + - Informative + + * - `tx[i]_csum_partial` + - Packets transmitted with a `CHECKSUM_PARTIAL` on ring i [#accel]_. + - Acceleration + + * - `tx[i]_csum_partial_inner` + - Packets transmitted with inner encapsulation with a `CHECKSUM_PARTIAL` on + ring i [#accel]_. + - Acceleration + + * - `tx[i]_csum_none` + - Packets transmitted with no hardware checksum acceleration on ring i. + - Informative + + * - `tx[i]_stopped` / `tx_queue_stopped` [#ring_global]_ + - Events where SQ was full on ring i. If this counter is increased, check + the amount of buffers allocated for transmission. + - Informative + + * - `tx[i]_wake` / `tx_queue_wake` [#ring_global]_ + - Events where SQ was full and has become not full on ring i. + - Informative + + * - `tx[i]_dropped` / `tx_queue_dropped` [#ring_global]_ + - Packets transmitted that were dropped due to DMA mapping failure on + ring i. If this counter is increased, check the amount of buffers + allocated for transmission. + - Error + + * - `tx[i]_nop` + - The number of nop WQEs (empty WQEs) inserted to the SQ (related to + ring i) due to the reach of the end of the cyclic buffer. When reaching + near to the end of cyclic buffer the driver may add those empty WQEs to + avoid handling a state the a WQE start in the end of the queue and ends + in the beginning of the queue. This is a normal condition. + - Informative + + * - `tx[i]_added_vlan_packets` + - The number of packets sent where vlan tag insertion was offloaded to the + hardware. + - Acceleration + + * - `rx[i]_removed_vlan_packets` + - The number of packets received where vlan tag stripping was offloaded to + the hardware. + - Acceleration + + * - `rx[i]_wqe_err` + - The number of wrong opcodes received on ring i. + - Error + + * - `rx[i]_mpwqe_frag` + - The number of WQEs that failed to allocate compound page and hence + fragmented MPWQE’s (Multi Packet WQEs) were used on ring i. If this + counter raise, it may suggest that there is no enough memory for large + pages, the driver allocated fragmented pages. This is not abnormal + condition. + - Informative + + * - `rx[i]_mpwqe_filler_cqes` + - The number of filler CQEs events that were issued on ring i. + - Informative + + * - `rx[i]_mpwqe_filler_strides` + - The number of strides consumed by filler CQEs on ring i. + - Informative + + * - `tx[i]_mpwqe_blks` + - The number of send blocks processed from Multi-Packet WQEs (mpwqe). + - Informative + + * - `tx[i]_mpwqe_pkts` + - The number of send packets processed from Multi-Packet WQEs (mpwqe). + - Informative + + * - `rx[i]_cqe_compress_blks` + - The number of receive blocks with CQE compression on ring i [#accel]_. + - Acceleration + + * - `rx[i]_cqe_compress_pkts` + - The number of receive packets with CQE compression on ring i [#accel]_. + - Acceleration + + * - `rx[i]_arfs_add` + - The number of aRFS flow rules added to the device for direct RQ steering + on ring i [#accel]_. + - Acceleration + + * - `rx[i]_arfs_request_in` + - Number of flow rules that have been requested to move into ring i for + direct RQ steering [#accel]_. + - Acceleration + + * - `rx[i]_arfs_request_out` + - Number of flow rules that have been requested to move out of ring i [#accel]_. + - Acceleration + + * - `rx[i]_arfs_expired` + - Number of flow rules that have been expired and removed [#accel]_. + - Acceleration + + * - `rx[i]_arfs_err` + - Number of flow rules that failed to be added to the flow table. + - Error + + * - `rx[i]_recover` + - The number of times the RQ was recovered. + - Error + + * - `tx[i]_xmit_more` + - The number of packets sent with `xmit_more` indication set on the skbuff + (no doorbell). + - Acceleration + + * - `ch[i]_poll` + - The number of invocations of NAPI poll of channel i. + - Informative + + * - `ch[i]_arm` + - The number of times the NAPI poll function completed and armed the + completion queues on channel i. + - Informative + + * - `ch[i]_aff_change` + - The number of times the NAPI poll function explicitly stopped execution + on a CPU due to a change in affinity, on channel i. + - Informative + + * - `ch[i]_events` + - The number of hard interrupt events on the completion queues of channel i. + - Informative + + * - `ch[i]_eq_rearm` + - The number of times the EQ was recovered. + - Error + + * - `ch[i]_force_irq` + - Number of times NAPI is triggered by XSK wakeups by posting a NOP to + ICOSQ. + - Acceleration + + * - `rx[i]_congst_umr` + - The number of times an outstanding UMR request is delayed due to + congestion, on ring i. + - Informative + + * - `rx_pp_alloc_fast` + - Number of successful fast path allocations. + - Informative + + * - `rx_pp_alloc_slow` + - Number of slow path order-0 allocations. + - Informative + + * - `rx_pp_alloc_slow_high_order` + - Number of slow path high order allocations. + - Informative + + * - `rx_pp_alloc_empty` + - Counter is incremented when ptr ring is empty, so a slow path allocation + was forced. + - Informative + + * - `rx_pp_alloc_refill` + - Counter is incremented when an allocation which triggered a refill of the + cache. + - Informative + + * - `rx_pp_alloc_waive` + - Counter is incremented when pages obtained from the ptr ring that cannot + be added to the cache due to a NUMA mismatch. + - Informative + + * - `rx_pp_recycle_cached` + - Counter is incremented when recycling placed page in the page pool cache. + - Informative + + * - `rx_pp_recycle_cache_full` + - Counter is incremented when page pool cache was full. + - Informative + + * - `rx_pp_recycle_ring` + - Counter is incremented when page placed into the ptr ring. + - Informative + + * - `rx_pp_recycle_ring_full` + - Counter is incremented when page released from page pool because the ptr + ring was full. + - Informative + + * - `rx_pp_recycle_released_ref` + - Counter is incremented when page released (and not recycled) because + refcnt > 1. + - Informative + + * - `rx[i]_xsk_buff_alloc_err` + - The number of times allocating an skb or XSK buffer failed in the XSK RQ + context. + - Error + + * - `rx[i]_xdp_tx_xmit` + - The number of packets forwarded back to the port due to XDP program + `XDP_TX` action (bouncing). these packets are not counted by other + software counters. These packets are counted by physical port and vPort + counters. + - Informative + + * - `rx[i]_xdp_tx_mpwqe` + - Number of multi-packet WQEs transmitted by the netdev and `XDP_TX`-ed by + the netdev during the RQ context. + - Acceleration + + * - `rx[i]_xdp_tx_inlnw` + - Number of WQE data segments transmitted where the data could be inlined + in the WQE and then `XDP_TX`-ed during the RQ context. + - Acceleration + + * - `rx[i]_xdp_tx_nops` + - Number of NOP WQEBBs (WQE building blocks) received posted to the XDP SQ. + - Acceleration + + * - `rx[i]_xdp_tx_full` + - The number of packets that should have been forwarded back to the port + due to `XDP_TX` action but were dropped due to full tx queue. These packets + are not counted by other software counters. These packets are counted by + physical port and vPort counters. You may open more rx queues and spread + traffic rx over all queues and/or increase rx ring size. + - Error + + * - `rx[i]_xdp_tx_err` + - The number of times an `XDP_TX` error such as frame too long and frame + too short occurred on `XDP_TX` ring of RX ring. + - Error + + * - `rx[i]_xdp_tx_cqes` / `rx_xdp_tx_cqe` [#ring_global]_ + - The number of completions received on the CQ of the `XDP_TX` ring. + - Informative + + * - `rx[i]_xdp_drop` + - The number of packets dropped due to XDP program `XDP_DROP` action. these + packets are not counted by other software counters. These packets are + counted by physical port and vPort counters. + - Informative + + * - `rx[i]_xdp_redirect` + - The number of times an XDP redirect action was triggered on ring i. + - Acceleration + + * - `tx[i]_xdp_xmit` + - The number of packets redirected to the interface(due to XDP redirect). + These packets are not counted by other software counters. These packets + are counted by physical port and vPort counters. + - Informative + + * - `tx[i]_xdp_full` + - The number of packets redirected to the interface(due to XDP redirect), + but were dropped due to full tx queue. these packets are not counted by + other software counters. you may enlarge tx queues. + - Informative + + * - `tx[i]_xdp_mpwqe` + - Number of multi-packet WQEs offloaded onto the NIC that were + `XDP_REDIRECT`-ed from other netdevs. + - Acceleration + + * - `tx[i]_xdp_inlnw` + - Number of WQE data segments where the data could be inlined in the WQE + where the data segments were `XDP_REDIRECT`-ed from other netdevs. + - Acceleration + + * - `tx[i]_xdp_nops` + - Number of NOP WQEBBs (WQE building blocks) posted to the SQ that were + `XDP_REDIRECT`-ed from other netdevs. + - Acceleration + + * - `tx[i]_xdp_err` + - The number of packets redirected to the interface(due to XDP redirect) + but were dropped due to error such as frame too long and frame too short. + - Error + + * - `tx[i]_xdp_cqes` + - The number of completions received for packets redirected to the + interface(due to XDP redirect) on the CQ. + - Informative + + * - `tx[i]_xsk_xmit` + - The number of packets transmitted using XSK zerocopy functionality. + - Acceleration + + * - `tx[i]_xsk_mpwqe` + - Number of multi-packet WQEs offloaded onto the NIC that were + `XDP_REDIRECT`-ed from other netdevs. + - Acceleration + + * - `tx[i]_xsk_inlnw` + - Number of WQE data segments where the data could be inlined in the WQE + that are transmitted using XSK zerocopy. + - Acceleration + + * - `tx[i]_xsk_full` + - Number of times doorbell is rung in XSK zerocopy mode when SQ is full. + - Error + + * - `tx[i]_xsk_err` + - Number of errors that occurred in XSK zerocopy mode such as if the data + size is larger than the MTU size. + - Error + + * - `tx[i]_xsk_cqes` + - Number of CQEs processed in XSK zerocopy mode. + - Acceleration + + * - `tx_tls_ctx` + - Number of TLS TX HW offload contexts added to device for encryption. + - Acceleration + + * - `tx_tls_del` + - Number of TLS TX HW offload contexts removed from device (connection + closed). + - Acceleration + + * - `tx_tls_pool_alloc` + - Number of times a unit of work is successfully allocated in the TLS HW + offload pool. + - Acceleration + + * - `tx_tls_pool_free` + - Number of times a unit of work is freed in the TLS HW offload pool. + - Acceleration + + * - `rx_tls_ctx` + - Number of TLS RX HW offload contexts added to device for decryption. + - Acceleration + + * - `rx_tls_del` + - Number of TLS RX HW offload contexts deleted from device (connection has + finished). + - Acceleration + + * - `rx[i]_tls_decrypted_packets` + - Number of successfully decrypted RX packets which were part of a TLS + stream. + - Acceleration + + * - `rx[i]_tls_decrypted_bytes` + - Number of TLS payload bytes in RX packets which were successfully + decrypted. + - Acceleration + + * - `rx[i]_tls_resync_req_pkt` + - Number of received TLS packets with a resync request. + - Acceleration + + * - `rx[i]_tls_resync_req_start` + - Number of times the TLS async resync request was started. + - Acceleration + + * - `rx[i]_tls_resync_req_end` + - Number of times the TLS async resync request properly ended with + providing the HW tracked tcp-seq. + - Acceleration + + * - `rx[i]_tls_resync_req_skip` + - Number of times the TLS async resync request procedure was started but + not properly ended. + - Error + + * - `rx[i]_tls_resync_res_ok` + - Number of times the TLS resync response call to the driver was + successfully handled. + - Acceleration + + * - `rx[i]_tls_resync_res_retry` + - Number of times the TLS resync response call to the driver was + reattempted when ICOSQ is full. + - Error + + * - `rx[i]_tls_resync_res_skip` + - Number of times the TLS resync response call to the driver was terminated + unsuccessfully. + - Error + + * - `rx[i]_tls_err` + - Number of times when CQE TLS offload was problematic. + - Error + + * - `tx[i]_tls_encrypted_packets` + - The number of send packets that are TLS encrypted by the kernel. + - Acceleration + + * - `tx[i]_tls_encrypted_bytes` + - The number of send bytes that are TLS encrypted by the kernel. + - Acceleration + + * - `tx[i]_tls_ooo` + - Number of times out of order TLS SQE fragments were handled on ring i. + - Acceleration + + * - `tx[i]_tls_dump_packets` + - Number of TLS decrypted packets copied over from NIC over DMA. + - Acceleration + + * - `tx[i]_tls_dump_bytes` + - Number of TLS decrypted bytes copied over from NIC over DMA. + - Acceleration + + * - `tx[i]_tls_resync_bytes` + - Number of TLS bytes requested to be resynchronized in order to be + decrypted. + - Acceleration + + * - `tx[i]_tls_skip_no_sync_data` + - Number of TLS send data that can safely be skipped / do not need to be + decrypted. + - Acceleration + + * - `tx[i]_tls_drop_no_sync_data` + - Number of TLS send data that were dropped due to retransmission of TLS + data. + - Acceleration + + * - `ptp_cq[i]_abort` + - Number of times a CQE has to be skipped in precision time protocol due to + a skew between the port timestamp and CQE timestamp being greater than + 128 seconds. + - Error + + * - `ptp_cq[i]_abort_abs_diff_ns` + - Accumulation of time differences between the port timestamp and CQE + timestamp when the difference is greater than 128 seconds in precision + time protocol. + - Error + + * - `ptp_cq[i]_late_cqe` + - Number of times a CQE has been delivered on the PTP timestamping CQ when + the CQE was not expected since a certain amount of time had elapsed where + the device typically ensures not posting the CQE. + - Error + +.. [#ring_global] The corresponding ring and global counters do not share the + same name (i.e. do not follow the common naming scheme). + +vPort Counters +-------------- +Counters on the NIC port that is connected to a eSwitch. + +.. flat-table:: vPort Counter Table + :widths: 2 3 1 + + * - Counter + - Description + - Type + + * - `rx_vport_unicast_packets` + - Unicast packets received, steered to a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `rx_vport_unicast_bytes` + - Unicast bytes received, steered to a port including Raw Ethernet QP/DPDK + traffic, excluding RDMA traffic. + - Informative + + * - `tx_vport_unicast_packets` + - Unicast packets transmitted, steered from a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `tx_vport_unicast_bytes` + - Unicast bytes transmitted, steered from a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `rx_vport_multicast_packets` + - Multicast packets received, steered to a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `rx_vport_multicast_bytes` + - Multicast bytes received, steered to a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `tx_vport_multicast_packets` + - Multicast packets transmitted, steered from a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `tx_vport_multicast_bytes` + - Multicast bytes transmitted, steered from a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `rx_vport_broadcast_packets` + - Broadcast packets received, steered to a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `rx_vport_broadcast_bytes` + - Broadcast bytes received, steered to a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `tx_vport_broadcast_packets` + - Broadcast packets transmitted, steered from a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `tx_vport_broadcast_bytes` + - Broadcast bytes transmitted, steered from a port including Raw Ethernet + QP/DPDK traffic, excluding RDMA traffic. + - Informative + + * - `rx_vport_rdma_unicast_packets` + - RDMA unicast packets received, steered to a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `rx_vport_rdma_unicast_bytes` + - RDMA unicast bytes received, steered to a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `tx_vport_rdma_unicast_packets` + - RDMA unicast packets transmitted, steered from a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `tx_vport_rdma_unicast_bytes` + - RDMA unicast bytes transmitted, steered from a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `rx_vport_rdma_multicast_packets` + - RDMA multicast packets received, steered to a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `rx_vport_rdma_multicast_bytes` + - RDMA multicast bytes received, steered to a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `tx_vport_rdma_multicast_packets` + - RDMA multicast packets transmitted, steered from a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `tx_vport_rdma_multicast_bytes` + - RDMA multicast bytes transmitted, steered from a port (counters counts + RoCE/UD/RC traffic) [#accel]_. + - Acceleration + + * - `vport_loopback_packets` + - Unicast, multicast and broadcast packets that were loop-back (received + and transmitted), IB/Eth [#accel]_. + - Acceleration + + * - `vport_loopback_bytes` + - Unicast, multicast and broadcast bytes that were loop-back (received + and transmitted), IB/Eth [#accel]_. + - Acceleration + + * - `rx_steer_missed_packets` + - Number of packets that was received by the NIC, however was discarded + because it did not match any flow in the NIC flow table. + - Error + + * - `rx_packets` + - Representor only: packets received, that were handled by the hypervisor. + - Informative + + * - `rx_bytes` + - Representor only: bytes received, that were handled by the hypervisor. + - Informative + + * - `tx_packets` + - Representor only: packets transmitted, that were handled by the + hypervisor. + - Informative + + * - `tx_bytes` + - Representor only: bytes transmitted, that were handled by the hypervisor. + - Informative + + * - `dev_internal_queue_oob` + - The number of dropped packets due to lack of receive WQEs for an internal + device RQ. + - Error + +Physical Port Counters +---------------------- +The physical port counters are the counters on the external port connecting the +adapter to the network. This measuring point holds information on standardized +counters like IEEE 802.3, RFC2863, RFC 2819, RFC 3635 and additional counters +like flow control, FEC and more. + +.. flat-table:: Physical Port Counter Table + :widths: 2 3 1 + + * - Counter + - Description + - Type + + * - `rx_packets_phy` + - The number of packets received on the physical port. This counter doesn’t + include packets that were discarded due to FCS, frame size and similar + errors. + - Informative + + * - `tx_packets_phy` + - The number of packets transmitted on the physical port. + - Informative + + * - `rx_bytes_phy` + - The number of bytes received on the physical port, including Ethernet + header and FCS. + - Informative + + * - `tx_bytes_phy` + - The number of bytes transmitted on the physical port. + - Informative + + * - `rx_multicast_phy` + - The number of multicast packets received on the physical port. + - Informative + + * - `tx_multicast_phy` + - The number of multicast packets transmitted on the physical port. + - Informative + + * - `rx_broadcast_phy` + - The number of broadcast packets received on the physical port. + - Informative + + * - `tx_broadcast_phy` + - The number of broadcast packets transmitted on the physical port. + - Informative + + * - `rx_crc_errors_phy` + - The number of dropped received packets due to FCS (Frame Check Sequence) + error on the physical port. If this counter is increased in high rate, + check the link quality using `rx_symbol_error_phy` and + `rx_corrected_bits_phy` counters below. + - Error + + * - `rx_in_range_len_errors_phy` + - The number of received packets dropped due to length/type errors on a + physical port. + - Error + + * - `rx_out_of_range_len_phy` + - The number of received packets dropped due to length greater than allowed + on a physical port. If this counter is increasing, it implies that the + peer connected to the adapter has a larger MTU configured. Using same MTU + configuration shall resolve this issue. + - Error + + * - `rx_oversize_pkts_phy` + - The number of dropped received packets due to length which exceed MTU + size on a physical port. If this counter is increasing, it implies that + the peer connected to the adapter has a larger MTU configured. Using same + MTU configuration shall resolve this issue. + - Error + + * - `rx_symbol_err_phy` + - The number of received packets dropped due to physical coding errors + (symbol errors) on a physical port. + - Error + + * - `rx_mac_control_phy` + - The number of MAC control packets received on the physical port. + - Informative + + * - `tx_mac_control_phy` + - The number of MAC control packets transmitted on the physical port. + - Informative + + * - `rx_pause_ctrl_phy` + - The number of link layer pause packets received on a physical port. If + this counter is increasing, it implies that the network is congested and + cannot absorb the traffic coming from to the adapter. + - Informative + + * - `tx_pause_ctrl_phy` + - The number of link layer pause packets transmitted on a physical port. If + this counter is increasing, it implies that the NIC is congested and + cannot absorb the traffic coming from the network. + - Informative + + * - `rx_unsupported_op_phy` + - The number of MAC control packets received with unsupported opcode on a + physical port. + - Error + + * - `rx_discards_phy` + - The number of received packets dropped due to lack of buffers on a + physical port. If this counter is increasing, it implies that the adapter + is congested and cannot absorb the traffic coming from the network. + - Error + + * - `tx_discards_phy` + - The number of packets which were discarded on transmission, even no + errors were detected. the drop might occur due to link in down state, + head of line drop, pause from the network, etc. + - Error + + * - `tx_errors_phy` + - The number of transmitted packets dropped due to a length which exceed + MTU size on a physical port. + - Error + + * - `rx_undersize_pkts_phy` + - The number of received packets dropped due to length which is shorter + than 64 bytes on a physical port. If this counter is increasing, it + implies that the peer connected to the adapter has a non-standard MTU + configured or malformed packet had arrived. + - Error + + * - `rx_fragments_phy` + - The number of received packets dropped due to a length which is shorter + than 64 bytes and has FCS error on a physical port. If this counter is + increasing, it implies that the peer connected to the adapter has a + non-standard MTU configured. + - Error + + * - `rx_jabbers_phy` + - The number of received packets d due to a length which is longer than 64 + bytes and had FCS error on a physical port. + - Error + + * - `rx_64_bytes_phy` + - The number of packets received on the physical port with size of 64 bytes. + - Informative + + * - `rx_65_to_127_bytes_phy` + - The number of packets received on the physical port with size of 65 to + 127 bytes. + - Informative + + * - `rx_128_to_255_bytes_phy` + - The number of packets received on the physical port with size of 128 to + 255 bytes. + - Informative + + * - `rx_256_to_511_bytes_phy` + - The number of packets received on the physical port with size of 256 to + 512 bytes. + - Informative + + * - `rx_512_to_1023_bytes_phy` + - The number of packets received on the physical port with size of 512 to + 1023 bytes. + - Informative + + * - `rx_1024_to_1518_bytes_phy` + - The number of packets received on the physical port with size of 1024 to + 1518 bytes. + - Informative + + * - `rx_1519_to_2047_bytes_phy` + - The number of packets received on the physical port with size of 1519 to + 2047 bytes. + - Informative + + * - `rx_2048_to_4095_bytes_phy` + - The number of packets received on the physical port with size of 2048 to + 4095 bytes. + - Informative + + * - `rx_4096_to_8191_bytes_phy` + - The number of packets received on the physical port with size of 4096 to + 8191 bytes. + - Informative + + * - `rx_8192_to_10239_bytes_phy` + - The number of packets received on the physical port with size of 8192 to + 10239 bytes. + - Informative + + * - `link_down_events_phy` + - The number of times where the link operative state changed to down. In + case this counter is increasing it may imply on port flapping. You may + need to replace the cable/transceiver. + - Error + + * - `rx_out_of_buffer` + - Number of times receive queue had no software buffers allocated for the + adapter's incoming traffic. + - Error + + * - `module_bus_stuck` + - The number of times that module's I\ :sup:`2`\C bus (data or clock) + short-wire was detected. You may need to replace the cable/transceiver. + - Error + + * - `module_high_temp` + - The number of times that the module temperature was too high. If this + issue persist, you may need to check the ambient temperature or replace + the cable/transceiver module. + - Error + + * - `module_bad_shorted` + - The number of times that the module cables were shorted. You may need to + replace the cable/transceiver module. + - Error + + * - `module_unplug` + - The number of times that module was ejected. + - Informative + + * - `rx_buffer_passed_thres_phy` + - The number of events where the port receive buffer was over 85% full. + - Informative + + * - `tx_pause_storm_warning_events` + - The number of times the device was sending pauses for a long period of + time. + - Informative + + * - `tx_pause_storm_error_events` + - The number of times the device was sending pauses for a long period of + time, reaching time out and disabling transmission of pause frames. on + the period where pause frames were disabled, drop could have been + occurred. + - Error + + * - `rx[i]_buff_alloc_err` + - Failed to allocate a buffer to received packet (or SKB) on ring i. + - Error + + * - `rx_bits_phy` + - This counter provides information on the total amount of traffic that + could have been received and can be used as a guideline to measure the + ratio of errored traffic in `rx_pcs_symbol_err_phy` and + `rx_corrected_bits_phy`. + - Informative + + * - `rx_pcs_symbol_err_phy` + - This counter counts the number of symbol errors that wasn’t corrected by + FEC correction algorithm or that FEC algorithm was not active on this + interface. If this counter is increasing, it implies that the link + between the NIC and the network is suffering from high BER, and that + traffic is lost. You may need to replace the cable/transceiver. The error + rate is the number of `rx_pcs_symbol_err_phy` divided by the number of + `rx_bits_phy` on a specific time frame. + - Error + + * - `rx_corrected_bits_phy` + - The number of corrected bits on this port according to active FEC + (RS/FC). If this counter is increasing, it implies that the link between + the NIC and the network is suffering from high BER. The corrected bit + rate is the number of `rx_corrected_bits_phy` divided by the number of + `rx_bits_phy` on a specific time frame. + - Error + + * - `rx_err_lane_[l]_phy` + - This counter counts the number of physical raw errors per lane l index. + The counter counts errors before FEC corrections. If this counter is + increasing, it implies that the link between the NIC and the network is + suffering from high BER, and that traffic might be lost. You may need to + replace the cable/transceiver. Please check in accordance with + `rx_corrected_bits_phy`. + - Error + + * - `rx_global_pause` + - The number of pause packets received on the physical port. If this + counter is increasing, it implies that the network is congested and + cannot absorb the traffic coming from the adapter. Note: This counter is + only enabled when global pause mode is enabled. + - Informative + + * - `rx_global_pause_duration` + - The duration of pause received (in microSec) on the physical port. The + counter represents the time the port did not send any traffic. If this + counter is increasing, it implies that the network is congested and + cannot absorb the traffic coming from the adapter. Note: This counter is + only enabled when global pause mode is enabled. + - Informative + + * - `tx_global_pause` + - The number of pause packets transmitted on a physical port. If this + counter is increasing, it implies that the adapter is congested and + cannot absorb the traffic coming from the network. Note: This counter is + only enabled when global pause mode is enabled. + - Informative + + * - `tx_global_pause_duration` + - The duration of pause transmitter (in microSec) on the physical port. + Note: This counter is only enabled when global pause mode is enabled. + - Informative + + * - `rx_global_pause_transition` + - The number of times a transition from Xoff to Xon on the physical port + has occurred. Note: This counter is only enabled when global pause mode + is enabled. + - Informative + + * - `rx_if_down_packets` + - The number of received packets that were dropped due to interface down. + - Informative + +Priority Port Counters +---------------------- +The following counters are physical port counters that are counted per L2 +priority (0-7). + +**Note:** `p` in the counter name represents the priority. + +.. flat-table:: Priority Port Counter Table + :widths: 2 3 1 + + * - Counter + - Description + - Type + + * - `rx_prio[p]_bytes` + - The number of bytes received with priority p on the physical port. + - Informative + + * - `rx_prio[p]_packets` + - The number of packets received with priority p on the physical port. + - Informative + + * - `tx_prio[p]_bytes` + - The number of bytes transmitted on priority p on the physical port. + - Informative + + * - `tx_prio[p]_packets` + - The number of packets transmitted on priority p on the physical port. + - Informative + + * - `rx_prio[p]_pause` + - The number of pause packets received with priority p on a physical port. + If this counter is increasing, it implies that the network is congested + and cannot absorb the traffic coming from the adapter. Note: This counter + is available only if PFC was enabled on priority p. + - Informative + + * - `rx_prio[p]_pause_duration` + - The duration of pause received (in microSec) on priority p on the + physical port. The counter represents the time the port did not send any + traffic on this priority. If this counter is increasing, it implies that + the network is congested and cannot absorb the traffic coming from the + adapter. Note: This counter is available only if PFC was enabled on + priority p. + - Informative + + * - `rx_prio[p]_pause_transition` + - The number of times a transition from Xoff to Xon on priority p on the + physical port has occurred. Note: This counter is available only if PFC + was enabled on priority p. + - Informative + + * - `tx_prio[p]_pause` + - The number of pause packets transmitted on priority p on a physical port. + If this counter is increasing, it implies that the adapter is congested + and cannot absorb the traffic coming from the network. Note: This counter + is available only if PFC was enabled on priority p. + - Informative + + * - `tx_prio[p]_pause_duration` + - The duration of pause transmitter (in microSec) on priority p on the + physical port. Note: This counter is available only if PFC was enabled on + priority p. + - Informative + + * - `rx_prio[p]_buf_discard` + - The number of packets discarded by device due to lack of per host receive + buffers. + - Informative + + * - `rx_prio[p]_cong_discard` + - The number of packets discarded by device due to per host congestion. + - Informative + + * - `rx_prio[p]_marked` + - The number of packets ecn marked by device due to per host congestion. + - Informative + + * - `rx_prio[p]_discards` + - The number of packets discarded by device due to lack of receive buffers. + - Informative + +Device Counters +--------------- +.. flat-table:: Device Counter Table + :widths: 2 3 1 + + * - Counter + - Description + - Type + + * - `rx_pci_signal_integrity` + - Counts physical layer PCIe signal integrity errors, the number of + transitions to recovery due to Framing errors and CRC (dlp and tlp). If + this counter is raising, try moving the adapter card to a different slot + to rule out a bad PCI slot. Validate that you are running with the latest + firmware available and latest server BIOS version. + - Error + + * - `tx_pci_signal_integrity` + - Counts physical layer PCIe signal integrity errors, the number of + transition to recovery initiated by the other side (moving to recovery + due to getting TS/EIEOS). If this counter is raising, try moving the + adapter card to a different slot to rule out a bad PCI slot. Validate + that you are running with the latest firmware available and latest server + BIOS version. + - Error + + * - `outbound_pci_buffer_overflow` + - The number of packets dropped due to pci buffer overflow. If this counter + is raising in high rate, it might indicate that the receive traffic rate + for a host is larger than the PCIe bus and therefore a congestion occurs. + - Informative + + * - `outbound_pci_stalled_rd` + - The percentage (in the range 0...100) of time within the last second that + the NIC had outbound non-posted reads requests but could not perform the + operation due to insufficient posted credits. + - Informative + + * - `outbound_pci_stalled_wr` + - The percentage (in the range 0...100) of time within the last second that + the NIC had outbound posted writes requests but could not perform the + operation due to insufficient posted credits. + - Informative + + * - `outbound_pci_stalled_rd_events` + - The number of seconds where `outbound_pci_stalled_rd` was above 30%. + - Informative + + * - `outbound_pci_stalled_wr_events` + - The number of seconds where `outbound_pci_stalled_wr` was above 30%. + - Informative + + * - `dev_out_of_buffer` + - The number of times the device owned queue had not enough buffers + allocated. + - Error diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst new file mode 100644 index 000000000000..581a91caa579 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/index.rst @@ -0,0 +1,25 @@ +.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB +.. include:: <isonum.txt> + +Mellanox ConnectX(R) mlx5 core VPI Network Driver +================================================= + +:Copyright: |copy| 2019, Mellanox Technologies LTD. +:Copyright: |copy| 2020-2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. + +Contents: + +.. toctree:: + :maxdepth: 2 + + kconfig + switchdev + tracepoints + counters + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst new file mode 100644 index 000000000000..20d3b7e87049 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/kconfig.rst @@ -0,0 +1,168 @@ +.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB +.. include:: <isonum.txt> + +======================================= +Enabling the driver and kconfig options +======================================= + +:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. + +| mlx5 core is modular and most of the major mlx5 core driver features can be selected (compiled in/out) +| at build time via kernel Kconfig flags. +| Basic features, ethernet net device rx/tx offloads and XDP, are available with the most basic flags +| CONFIG_MLX5_CORE=y/m and CONFIG_MLX5_CORE_EN=y. +| For the list of advanced features, please see below. + +**CONFIG_MLX5_BRIDGE=(y/n)** + +| Enable :ref:`Ethernet Bridging (BRIDGE) offloading support <mlx5_bridge_offload>`. +| This will provide the ability to add representors of mlx5 uplink and VF +| ports to Bridge and offloading rules for traffic between such ports. +| Supports VLANs (trunk and access modes). + + +**CONFIG_MLX5_CORE=(y/m/n)** (module mlx5_core.ko) + +| The driver can be enabled by choosing CONFIG_MLX5_CORE=y/m in kernel config. +| This will provide mlx5 core driver for mlx5 ulps to interface with (mlx5e, mlx5_ib). + + +**CONFIG_MLX5_CORE_EN=(y/n)** + +| Choosing this option will allow basic ethernet netdevice support with all of the standard rx/tx offloads. +| mlx5e is the mlx5 ulp driver which provides netdevice kernel interface, when chosen, mlx5e will be +| built-in into mlx5_core.ko. + + +**CONFIG_MLX5_CORE_EN_DCB=(y/n)**: + +| Enables `Data Center Bridging (DCB) Support <https://enterprise-support.nvidia.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx>`_. + + +**CONFIG_MLX5_CORE_IPOIB=(y/n)** + +| IPoIB offloads & acceleration support. +| Requires CONFIG_MLX5_CORE_EN to provide an accelerated interface for the rdma +| IPoIB ulp netdevice. + + +**CONFIG_MLX5_CLS_ACT=(y/n)** + +| Enables offload support for TC classifier action (NET_CLS_ACT). +| Works in both native NIC mode and Switchdev SRIOV mode. +| Flow-based classifiers, such as those registered through +| `tc-flower(8)`, are processed by the device, rather than the +| host. Actions that would then overwrite matching classification +| results would then be instant due to the offload. + + +**CONFIG_MLX5_EN_ARFS=(y/n)** + +| Enables Hardware-accelerated receive flow steering (arfs) support, and ntuple filtering. +| https://enterprise-support.nvidia.com/s/article/howto-configure-arfs-on-connectx-4 + + +**CONFIG_MLX5_EN_IPSEC=(y/n)** + +| Enables :ref:`IPSec XFRM cryptography-offload acceleration <xfrm_device>`. + + +**CONFIG_MLX5_MACSEC=(y/n)** + +| Build support for MACsec cryptography-offload acceleration in the NIC. + + +**CONFIG_MLX5_EN_RXNFC=(y/n)** + +| Enables ethtool receive network flow classification, which allows user defined +| flow rules to direct traffic into arbitrary rx queue via ethtool set/get_rxnfc API. + + +**CONFIG_MLX5_EN_TLS=(y/n)** + +| TLS cryptography-offload acceleration. + + +**CONFIG_MLX5_ESWITCH=(y/n)** + +| Ethernet SRIOV E-Switch support in ConnectX NIC. E-Switch provides internal SRIOV packet steering +| and switching for the enabled VFs and PF in two available modes: +| 1) `Legacy SRIOV mode (L2 mac vlan steering based) <https://enterprise-support.nvidia.com/s/article/HowTo-Configure-SR-IOV-for-ConnectX-4-ConnectX-5-ConnectX-6-with-KVM-Ethernet>`_. +| 2) :ref:`Switchdev mode (eswitch offloads) <switchdev>`. + + +**CONFIG_MLX5_FPGA=(y/n)** + +| Build support for the Innova family of network cards by Mellanox Technologies. +| Innova network cards are comprised of a ConnectX chip and an FPGA chip on one board. +| If you select this option, the mlx5_core driver will include the Innova FPGA core and allow +| building sandbox-specific client drivers. + + +**CONFIG_MLX5_INFINIBAND=(y/n/m)** (module mlx5_ib.ko) + +| Provides low-level InfiniBand/RDMA and `RoCE <https://enterprise-support.nvidia.com/s/article/recommended-network-configuration-examples-for-roce-deployment>`_ support. + + +**CONFIG_MLX5_MPFS=(y/n)** + +| Ethernet Multi-Physical Function Switch (MPFS) support in ConnectX NIC. +| MPFs is required for when `Multi-Host <https://www.nvidia.com/en-us/networking/multi-host/>`_ configuration is enabled to allow passing +| user configured unicast MAC addresses to the requesting PF. + + +**CONFIG_MLX5_SF=(y/n)** + +| Build support for subfunction. +| Subfunctons are more light weight than PCI SRIOV VFs. Choosing this option +| will enable support for creating subfunction devices. + + +**CONFIG_MLX5_SF_MANAGER=(y/n)** + +| Build support for subfuction port in the NIC. A Mellanox subfunction +| port is managed through devlink. A subfunction supports RDMA, netdevice +| and vdpa device. It is similar to a SRIOV VF but it doesn't require +| SRIOV support. + + +**CONFIG_MLX5_SW_STEERING=(y/n)** + +| Build support for software-managed steering in the NIC. + + +**CONFIG_MLX5_TC_CT=(y/n)** + +| Support offloading connection tracking rules via tc ct action. + + +**CONFIG_MLX5_TC_SAMPLE=(y/n)** + +| Support offloading sample rules via tc sample action. + + +**CONFIG_MLX5_VDPA=(y/n)** + +| Support library for Mellanox VDPA drivers. Provides code that is +| common for all types of VDPA drivers. The following drivers are planned: +| net, block. + + +**CONFIG_MLX5_VDPA_NET=(y/n)** + +| VDPA network driver for ConnectX6 and newer. Provides offloading +| of virtio net datapath such that descriptors put on the ring will +| be executed by the hardware. It also supports a variety of stateless +| offloads depending on the actual device used and firmware version. + + +**CONFIG_MLX5_VFIO_PCI=(y/n)** + +| This provides migration support for MLX5 devices using the VFIO framework. + + +**External options** ( Choose if the corresponding mlx5 feature is required ) + +- CONFIG_MLXFW: When chosen, mlx5 firmware flashing support will be enabled (via devlink and ethtool). +- CONFIG_PTP_1588_CLOCK: When chosen, mlx5 ptp support will be enabled +- CONFIG_VXLAN: When chosen, mlx5 vxlan support will be enabled. diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst new file mode 100644 index 000000000000..b617e93d7c2c --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/switchdev.rst @@ -0,0 +1,281 @@ +.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB +.. include:: <isonum.txt> + +========= +Switchdev +========= + +:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. + +.. _mlx5_bridge_offload: + +Bridge offload +============== + +The mlx5 driver implements support for offloading bridge rules when in switchdev +mode. Linux bridge FDBs are automatically offloaded when mlx5 switchdev +representor is attached to bridge. + +- Change device to switchdev mode:: + + $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev + +- Attach mlx5 switchdev representor 'enp8s0f0' to bridge netdev 'bridge1':: + + $ ip link set enp8s0f0 master bridge1 + +VLANs +----- + +Following bridge VLAN functions are supported by mlx5: + +- VLAN filtering (including multiple VLANs per port):: + + $ ip link set bridge1 type bridge vlan_filtering 1 + $ bridge vlan add dev enp8s0f0 vid 2-3 + +- VLAN push on bridge ingress:: + + $ bridge vlan add dev enp8s0f0 vid 3 pvid + +- VLAN pop on bridge egress:: + + $ bridge vlan add dev enp8s0f0 vid 3 untagged + +Subfunction +=========== + +Subfunction which are spawned over the E-switch are created only with devlink +device, and by default all the SF auxiliary devices are disabled. +This will allow user to configure the SF before the SF have been fully probed, +which will save time. + +Usage example: + +- Create SF:: + + $ devlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 11 + $ devlink port function set pci/0000:08:00.0/32768 hw_addr 00:00:00:00:00:11 state active + +- Enable ETH auxiliary device:: + + $ devlink dev param set auxiliary/mlx5_core.sf.1 name enable_eth value true cmode driverinit + +- Now, in order to fully probe the SF, use devlink reload:: + + $ devlink dev reload auxiliary/mlx5_core.sf.1 + +mlx5 supports ETH,rdma and vdpa (vnet) auxiliary devices devlink params (see :ref:`Documentation/networking/devlink/devlink-params.rst <devlink_params_generic>`). + +mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface. + +A subfunction has its own function capabilities and its own resources. This +means a subfunction has its own dedicated queues (txq, rxq, cq, eq). These +queues are neither shared nor stolen from the parent PCI function. + +When a subfunction is RDMA capable, it has its own QP1, GID table, and RDMA +resources neither shared nor stolen from the parent PCI function. + +A subfunction has a dedicated window in PCI BAR space that is not shared +with the other subfunctions or the parent PCI function. This ensures that all +devices (netdev, rdma, vdpa, etc.) of the subfunction accesses only assigned +PCI BAR space. + +A subfunction supports eswitch representation through which it supports tc +offloads. The user configures eswitch to send/receive packets from/to +the subfunction port. + +Subfunctions share PCI level resources such as PCI MSI-X IRQs with +other subfunctions and/or with its parent PCI function. + +Example mlx5 software, system, and device view:: + + _______ + | admin | + | user |---------- + |_______| | + | | + ____|____ __|______ _________________ + | | | | | | + | devlink | | tc tool | | user | + | tool | |_________| | applications | + |_________| | |_________________| + | | | | + | | | | Userspace + +---------|-------------|-------------------|----------|--------------------+ + | | +----------+ +----------+ Kernel + | | | netdev | | rdma dev | + | | +----------+ +----------+ + (devlink port add/del | ^ ^ + port function set) | | | + | | +---------------| + _____|___ | | _______|_______ + | | | | | mlx5 class | + | devlink | +------------+ | | drivers | + | kernel | | rep netdev | | |(mlx5_core,ib) | + |_________| +------------+ | |_______________| + | | | ^ + (devlink ops) | | (probe/remove) + _________|________ | | ____|________ + | subfunction | | +---------------+ | subfunction | + | management driver|----- | subfunction |---| driver | + | (mlx5_core) | | auxiliary dev | | (mlx5_core) | + |__________________| +---------------+ |_____________| + | ^ + (sf add/del, vhca events) | + | (device add/del) + _____|____ ____|________ + | | | subfunction | + | PCI NIC |--- activate/deactivate events--->| host driver | + |__________| | (mlx5_core) | + |_____________| + +Subfunction is created using devlink port interface. + +- Change device to switchdev mode:: + + $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev + +- Add a devlink port of subfunction flavour:: + + $ devlink port add pci/0000:06:00.0 flavour pcisf pfnum 0 sfnum 88 + pci/0000:06:00.0/32768: type eth netdev eth6 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false + function: + hw_addr 00:00:00:00:00:00 state inactive opstate detached + +- Show a devlink port of the subfunction:: + + $ devlink port show pci/0000:06:00.0/32768 + pci/0000:06:00.0/32768: type eth netdev enp6s0pf0sf88 flavour pcisf pfnum 0 sfnum 88 + function: + hw_addr 00:00:00:00:00:00 state inactive opstate detached + +- Delete a devlink port of subfunction after use:: + + $ devlink port del pci/0000:06:00.0/32768 + +Function attributes +=================== + +The mlx5 driver provides a mechanism to setup PCI VF/SF function attributes in +a unified way for SmartNIC and non-SmartNIC. + +This is supported only when the eswitch mode is set to switchdev. Port function +configuration of the PCI VF/SF is supported through devlink eswitch port. + +Port function attributes should be set before PCI VF/SF is enumerated by the +driver. + +MAC address setup +----------------- + +mlx5 driver support devlink port function attr mechanism to setup MAC +address. (refer to Documentation/networking/devlink/devlink-port.rst) + +RoCE capability setup +~~~~~~~~~~~~~~~~~~~~~ +Not all mlx5 PCI devices/SFs require RoCE capability. + +When RoCE capability is disabled, it saves 1 Mbytes worth of system memory per +PCI devices/SF. + +mlx5 driver support devlink port function attr mechanism to setup RoCE +capability. (refer to Documentation/networking/devlink/devlink-port.rst) + +migratable capability setup +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +User who wants mlx5 PCI VFs to be able to perform live migration need to +explicitly enable the VF migratable capability. + +mlx5 driver support devlink port function attr mechanism to setup migratable +capability. (refer to Documentation/networking/devlink/devlink-port.rst) + +IPsec crypto capability setup +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +User who wants mlx5 PCI VFs to be able to perform IPsec crypto offloading need +to explicitly enable the VF ipsec_crypto capability. Enabling IPsec capability +for VFs is supported starting with ConnectX6dx devices and above. When a VF has +IPsec capability enabled, any IPsec offloading is blocked on the PF. + +mlx5 driver support devlink port function attr mechanism to setup ipsec_crypto +capability. (refer to Documentation/networking/devlink/devlink-port.rst) + +IPsec packet capability setup +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +User who wants mlx5 PCI VFs to be able to perform IPsec packet offloading need +to explicitly enable the VF ipsec_packet capability. Enabling IPsec capability +for VFs is supported starting with ConnectX6dx devices and above. When a VF has +IPsec capability enabled, any IPsec offloading is blocked on the PF. + +mlx5 driver support devlink port function attr mechanism to setup ipsec_packet +capability. (refer to Documentation/networking/devlink/devlink-port.rst) + +SF state setup +-------------- + +To use the SF, the user must activate the SF using the SF function state +attribute. + +- Get the state of the SF identified by its unique devlink port index:: + + $ devlink port show ens2f0npf0sf88 + pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false + function: + hw_addr 00:00:00:00:88:88 state inactive opstate detached + +- Activate the function and verify its state is active:: + + $ devlink port function set ens2f0npf0sf88 state active + + $ devlink port show ens2f0npf0sf88 + pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false + function: + hw_addr 00:00:00:00:88:88 state active opstate detached + +Upon function activation, the PF driver instance gets the event from the device +that a particular SF was activated. It's the cue to put the device on bus, probe +it and instantiate the devlink instance and class specific auxiliary devices +for it. + +- Show the auxiliary device and port of the subfunction:: + + $ devlink dev show + devlink dev show auxiliary/mlx5_core.sf.4 + + $ devlink port show auxiliary/mlx5_core.sf.4/1 + auxiliary/mlx5_core.sf.4/1: type eth netdev p0sf88 flavour virtual port 0 splittable false + + $ rdma link show mlx5_0/1 + link mlx5_0/1 state ACTIVE physical_state LINK_UP netdev p0sf88 + + $ rdma dev show + 8: rocep6s0f1: node_type ca fw 16.29.0550 node_guid 248a:0703:00b3:d113 sys_image_guid 248a:0703:00b3:d112 + 13: mlx5_0: node_type ca fw 16.29.0550 node_guid 0000:00ff:fe00:8888 sys_image_guid 248a:0703:00b3:d112 + +- Subfunction auxiliary device and class device hierarchy:: + + mlx5_core.sf.4 + (subfunction auxiliary device) + /\ + / \ + / \ + / \ + / \ + mlx5_core.eth.4 mlx5_core.rdma.4 + (sf eth aux dev) (sf rdma aux dev) + | | + | | + p0sf88 mlx5_0 + (sf netdev) (sf rdma device) + +Additionally, the SF port also gets the event when the driver attaches to the +auxiliary device of the subfunction. This results in changing the operational +state of the function. This provides visibility to the user to decide when is it +safe to delete the SF port for graceful termination of the subfunction. + +- Show the SF port operational state:: + + $ devlink port show ens2f0npf0sf88 + pci/0000:06:00.0/32768: type eth netdev ens2f0npf0sf88 flavour pcisf controller 0 pfnum 0 sfnum 88 external false splittable false + function: + hw_addr 00:00:00:00:88:88 state active opstate attached diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/tracepoints.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/tracepoints.rst new file mode 100644 index 000000000000..da8e53cebb6c --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5/tracepoints.rst @@ -0,0 +1,229 @@ +.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB +.. include:: <isonum.txt> + +=========== +Tracepoints +=========== + +:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved. + +mlx5 driver provides internal tracepoints for tracking and debugging using +kernel tracepoints interfaces (refer to Documentation/trace/ftrace.rst). + +For the list of support mlx5 events, check /sys/kernel/tracing/events/mlx5/. + +tc and eswitch offloads tracepoints: + +- mlx5e_configure_flower: trace flower filter actions and cookies offloaded to mlx5:: + + $ echo mlx5:mlx5e_configure_flower >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + tc-6535 [019] ...1 2672.404466: mlx5e_configure_flower: cookie=0000000067874a55 actions= REDIRECT + +- mlx5e_delete_flower: trace flower filter actions and cookies deleted from mlx5:: + + $ echo mlx5:mlx5e_delete_flower >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + tc-6569 [010] .N.1 2686.379075: mlx5e_delete_flower: cookie=0000000067874a55 actions= NULL + +- mlx5e_stats_flower: trace flower stats request:: + + $ echo mlx5:mlx5e_stats_flower >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + tc-6546 [010] ...1 2679.704889: mlx5e_stats_flower: cookie=0000000060eb3d6a bytes=0 packets=0 lastused=4295560217 + +- mlx5e_tc_update_neigh_used_value: trace tunnel rule neigh update value offloaded to mlx5:: + + $ echo mlx5:mlx5e_tc_update_neigh_used_value >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u48:4-8806 [009] ...1 55117.882428: mlx5e_tc_update_neigh_used_value: netdev: ens1f0 IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_used=1 + +- mlx5e_rep_neigh_update: trace neigh update tasks scheduled due to neigh state change events:: + + $ echo mlx5:mlx5e_rep_neigh_update >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1 + +Bridge offloads tracepoints: + +- mlx5_esw_bridge_fdb_entry_init: trace bridge FDB entry offloaded to mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u20:9-2217 [003] ...1 318.582243: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=0 flags=0 used=0 + +- mlx5_esw_bridge_fdb_entry_cleanup: trace bridge FDB entry deleted from mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_cleanup >> set_event + $ cat /sys/kernel/tracing/trace + ... + ip-2581 [005] ...1 318.629871: mlx5_esw_bridge_fdb_entry_cleanup: net_device=enp8s0f0_1 addr=e4:fd:05:08:00:03 vid=0 flags=0 used=16 + +- mlx5_esw_bridge_fdb_entry_refresh: trace bridge FDB entry offload refreshed in + mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_refresh >> set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u20:8-3849 [003] ...1 466716: mlx5_esw_bridge_fdb_entry_refresh: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 used=0 + +- mlx5_esw_bridge_vlan_create: trace bridge VLAN object add on mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_create >> set_event + $ cat /sys/kernel/tracing/trace + ... + ip-2560 [007] ...1 318.460258: mlx5_esw_bridge_vlan_create: vid=1 flags=6 + +- mlx5_esw_bridge_vlan_cleanup: trace bridge VLAN object delete from mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_cleanup >> set_event + $ cat /sys/kernel/tracing/trace + ... + bridge-2582 [007] ...1 318.653496: mlx5_esw_bridge_vlan_cleanup: vid=2 flags=8 + +- mlx5_esw_bridge_vport_init: trace mlx5 vport assigned with bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_init >> set_event + $ cat /sys/kernel/tracing/trace + ... + ip-2560 [007] ...1 318.458915: mlx5_esw_bridge_vport_init: vport_num=1 + +- mlx5_esw_bridge_vport_cleanup: trace mlx5 vport removed from bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_cleanup >> set_event + $ cat /sys/kernel/tracing/trace + ... + ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1 + +Eswitch QoS tracepoints: + +- mlx5_esw_vport_qos_create: trace creation of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_create >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + <...>-23496 [018] .... 73136.838831: mlx5_esw_vport_qos_create: (0000:82:00.0) vport=2 tsar_ix=4 bw_share=0, max_rate=0 group=000000007b576bb3 + +- mlx5_esw_vport_qos_config: trace configuration of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_config >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + <...>-26548 [023] .... 75754.223823: mlx5_esw_vport_qos_config: (0000:82:00.0) vport=1 tsar_ix=3 bw_share=34, max_rate=10000 group=000000007b576bb3 + +- mlx5_esw_vport_qos_destroy: trace deletion of transmit scheduler arbiter for vport:: + + $ echo mlx5:mlx5_esw_vport_qos_destroy >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + <...>-27418 [004] .... 76546.680901: mlx5_esw_vport_qos_destroy: (0000:82:00.0) vport=1 tsar_ix=3 + +- mlx5_esw_group_qos_create: trace creation of transmit scheduler arbiter for rate group:: + + $ echo mlx5:mlx5_esw_group_qos_create >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + <...>-26578 [008] .... 75776.022112: mlx5_esw_group_qos_create: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 + +- mlx5_esw_group_qos_config: trace configuration of transmit scheduler arbiter for rate group:: + + $ echo mlx5:mlx5_esw_group_qos_config >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + <...>-27303 [020] .... 76461.455356: mlx5_esw_group_qos_config: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 bw_share=100 max_rate=20000 + +- mlx5_esw_group_qos_destroy: trace deletion of transmit scheduler arbiter for group:: + + $ echo mlx5:mlx5_esw_group_qos_destroy >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + <...>-27418 [006] .... 76547.187258: mlx5_esw_group_qos_destroy: (0000:82:00.0) group=000000007b576bb3 tsar_ix=1 + +SF tracepoints: + +- mlx5_sf_add: trace addition of the SF port:: + + $ echo mlx5:mlx5_sf_add >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + devlink-9363 [031] ..... 24610.188722: mlx5_sf_add: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000 sfnum=88 + +- mlx5_sf_free: trace freeing of the SF port:: + + $ echo mlx5:mlx5_sf_free >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + devlink-9830 [038] ..... 26300.404749: mlx5_sf_free: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000 + +- mlx5_sf_activate: trace activation of the SF port:: + + $ echo mlx5:mlx5_sf_activate >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + devlink-29841 [008] ..... 3669.635095: mlx5_sf_activate: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000 + +- mlx5_sf_deactivate: trace deactivation of the SF port:: + + $ echo mlx5:mlx5_sf_deactivate >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + devlink-29994 [008] ..... 4015.969467: mlx5_sf_deactivate: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000 + +- mlx5_sf_hwc_alloc: trace allocating of the hardware SF context:: + + $ echo mlx5:mlx5_sf_hwc_alloc >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + devlink-9775 [031] ..... 26296.385259: mlx5_sf_hwc_alloc: (0000:06:00.0) controller=0 hw_id=0x8000 sfnum=88 + +- mlx5_sf_hwc_free: trace freeing of the hardware SF context:: + + $ echo mlx5:mlx5_sf_hwc_free >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u128:3-9093 [046] ..... 24625.365771: mlx5_sf_hwc_free: (0000:06:00.0) hw_id=0x8000 + +- mlx5_sf_hwc_deferred_free: trace deferred freeing of the hardware SF context:: + + $ echo mlx5:mlx5_sf_hwc_deferred_free >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + devlink-9519 [046] ..... 24624.400271: mlx5_sf_hwc_deferred_free: (0000:06:00.0) hw_id=0x8000 + +- mlx5_sf_update_state: trace state updates for SF contexts:: + + $ echo mlx5:mlx5_sf_update_state >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u20:3-29490 [009] ..... 4141.453530: mlx5_sf_update_state: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000 state=2 + +- mlx5_sf_vhca_event: trace SF vhca event and state:: + + $ echo mlx5:mlx5_sf_vhca_event >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u128:3-9093 [046] ..... 24625.365525: mlx5_sf_vhca_event: (0000:06:00.0) hw_id=0x8000 sfnum=88 vhca_state=1 + +- mlx5_sf_dev_add: trace SF device add event:: + + $ echo mlx5:mlx5_sf_dev_add>> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u128:3-9093 [000] ..... 24616.524495: mlx5_sf_dev_add: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88 + +- mlx5_sf_dev_del: trace SF device delete event:: + + $ echo mlx5:mlx5_sf_dev_del >> /sys/kernel/tracing/set_event + $ cat /sys/kernel/tracing/trace + ... + kworker/u128:3-9093 [044] ..... 24624.400749: mlx5_sf_dev_del: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88 diff --git a/Documentation/networking/device_drivers/microsoft/netvsc.txt b/Documentation/networking/device_drivers/ethernet/microsoft/netvsc.rst index cd63556b27a0..fc5acd427a5d 100644 --- a/Documentation/networking/device_drivers/microsoft/netvsc.txt +++ b/Documentation/networking/device_drivers/ethernet/microsoft/netvsc.rst @@ -1,3 +1,6 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================== Hyper-V network driver ====================== @@ -10,15 +13,15 @@ Windows 10. Features ======== - Checksum offload - ---------------- +Checksum offload +---------------- The netvsc driver supports checksum offload as long as the Hyper-V host version does. Windows Server 2016 and Azure support checksum offload for TCP and UDP for both IPv4 and IPv6. Windows Server 2012 only supports checksum offload for TCP. - Receive Side Scaling - -------------------- +Receive Side Scaling +-------------------- Hyper-V supports receive side scaling. For TCP & UDP, packets can be distributed among available queues based on IP address and port number. @@ -32,30 +35,37 @@ Features hashing. Using L3 hashing is recommended in this case. For example, for UDP over IPv4 on eth0: - To include UDP port numbers in hashing: - ethtool -N eth0 rx-flow-hash udp4 sdfn - To exclude UDP port numbers in hashing: - ethtool -N eth0 rx-flow-hash udp4 sd - To show UDP hash level: - ethtool -n eth0 rx-flow-hash udp4 - - Generic Receive Offload, aka GRO - -------------------------------- + + To include UDP port numbers in hashing:: + + ethtool -N eth0 rx-flow-hash udp4 sdfn + + To exclude UDP port numbers in hashing:: + + ethtool -N eth0 rx-flow-hash udp4 sd + + To show UDP hash level:: + + ethtool -n eth0 rx-flow-hash udp4 + +Generic Receive Offload, aka GRO +-------------------------------- The driver supports GRO and it is enabled by default. GRO coalesces like packets and significantly reduces CPU usage under heavy Rx load. - Large Receive Offload (LRO), or Receive Side Coalescing (RSC) - ------------------------------------------------------------- +Large Receive Offload (LRO), or Receive Side Coalescing (RSC) +------------------------------------------------------------- The driver supports LRO/RSC in the vSwitch feature. It reduces the per packet processing overhead by coalescing multiple TCP segments when possible. The feature is enabled by default on VMs running on Windows Server 2019 and - later. It may be changed by ethtool command: + later. It may be changed by ethtool command:: + ethtool -K eth0 lro on ethtool -K eth0 lro off - SR-IOV support - -------------- +SR-IOV support +-------------- Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV is enabled in both the vSwitch and the guest configuration, then the Virtual Function (VF) device is passed to the guest as a PCI @@ -70,21 +80,25 @@ Features flow direction is desired, these should be applied directly to the VF slave device. - Receive Buffer - -------------- +Receive Buffer +-------------- Packets are received into a receive area which is created when device is probed. The receive area is broken into MTU sized chunks and each may contain one or more packets. The number of receive sections may be changed via ethtool Rx ring parameters. - There is a similar send buffer which is used to aggregate packets for sending. - The send area is broken into chunks of 6144 bytes, each of section may - contain one or more packets. The send buffer is an optimization, the driver - will use slower method to handle very large packets or if the send buffer - area is exhausted. - - XDP support - ----------- + There is a similar send buffer which is used to aggregate packets + for sending. The send area is broken into chunks, typically of 6144 + bytes, each of section may contain one or more packets. Small + packets are usually transmitted via copy to the send buffer. However, + if the buffer is temporarily exhausted, or the packet to be transmitted is + an LSO packet, the driver will provide the host with pointers to the data + from the SKB. This attempts to achieve a balance between the overhead of + data copy and the impact of remapping VM memory to be accessible by the + host. + +XDP support +----------- XDP (eXpress Data Path) is a feature that runs eBPF bytecode at the early stage when packets arrive at a NIC card. The goal is to increase performance for packet processing, reducing the overhead of SKB allocation and other @@ -99,7 +113,8 @@ Features overwritten by setting of synthetic NIC. XDP program cannot run with LRO (RSC) enabled, so you need to disable LRO - before running XDP: + before running XDP:: + ethtool -K eth0 lro off XDP_REDIRECT action is not yet supported. diff --git a/Documentation/networking/device_drivers/ethernet/neterion/s2io.rst b/Documentation/networking/device_drivers/ethernet/neterion/s2io.rst new file mode 100644 index 000000000000..d731b5a98561 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/neterion/s2io.rst @@ -0,0 +1,196 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================================= +Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver +========================================================= + +Release notes for Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver. + +.. Contents + - 1. Introduction + - 2. Identifying the adapter/interface + - 3. Features supported + - 4. Command line parameters + - 5. Performance suggestions + - 6. Available Downloads + + +1. Introduction +=============== +This Linux driver supports Neterion's Xframe I PCI-X 1.0 and +Xframe II PCI-X 2.0 adapters. It supports several features +such as jumbo frames, MSI/MSI-X, checksum offloads, TSO, UFO and so on. +See below for complete list of features. + +All features are supported for both IPv4 and IPv6. + +2. Identifying the adapter/interface +==================================== + +a. Insert the adapter(s) in your system. +b. Build and load driver:: + + # insmod s2io.ko + +c. View log messages:: + + # dmesg | tail -40 + +You will see messages similar to:: + + eth3: Neterion Xframe I 10GbE adapter (rev 3), Version 2.0.9.1, Intr type INTA + eth4: Neterion Xframe II 10GbE adapter (rev 2), Version 2.0.9.1, Intr type INTA + eth4: Device is on 64 bit 133MHz PCIX(M1) bus + +The above messages identify the adapter type(Xframe I/II), adapter revision, +driver version, interface name(eth3, eth4), Interrupt type(INTA, MSI, MSI-X). +In case of Xframe II, the PCI/PCI-X bus width and frequency are displayed +as well. + +To associate an interface with a physical adapter use "ethtool -p <ethX>". +The corresponding adapter's LED will blink multiple times. + +3. Features supported +===================== +a. Jumbo frames. Xframe I/II supports MTU up to 9600 bytes, + modifiable using ip command. + +b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit + and receive, TSO. + +c. Multi-buffer receive mode. Scattering of packet across multiple + buffers. Currently driver supports 2-buffer mode which yields + significant performance improvement on certain platforms(SGI Altix, + IBM xSeries). + +d. MSI/MSI-X. Can be enabled on platforms which support this feature + resulting in noticeable performance improvement (up to 7% on certain + platforms). + +e. Statistics. Comprehensive MAC-level and software statistics displayed + using "ethtool -S" option. + +f. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, + with multiple steering options. + +4. Command line parameters +========================== + +a. tx_fifo_num + Number of transmit queues + +Valid range: 1-8 + +Default: 1 + +b. rx_ring_num + Number of receive rings + +Valid range: 1-8 + +Default: 1 + +c. tx_fifo_len + Size of each transmit queue + +Valid range: Total length of all queues should not exceed 8192 + +Default: 4096 + +d. rx_ring_sz + Size of each receive ring(in 4K blocks) + +Valid range: Limited by memory on system + +Default: 30 + +e. intr_type + Specifies interrupt type. Possible values 0(INTA), 2(MSI-X) + +Valid values: 0, 2 + +Default: 2 + +5. Performance suggestions +========================== + +General: + +a. Set MTU to maximum(9000 for switch setup, 9600 in back-to-back configuration) +b. Set TCP windows size to optimal value. + +For instance, for MTU=1500 a value of 210K has been observed to result in +good performance:: + + # sysctl -w net.ipv4.tcp_rmem="210000 210000 210000" + # sysctl -w net.ipv4.tcp_wmem="210000 210000 210000" + +For MTU=9000, TCP window size of 10 MB is recommended:: + + # sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000" + # sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000" + +Transmit performance: + +a. By default, the driver respects BIOS settings for PCI bus parameters. + However, you may want to experiment with PCI bus parameters + max-split-transactions(MOST) and MMRBC (use setpci command). + + A MOST value of 2 has been found optimal for Opterons and 3 for Itanium. + + It could be different for your hardware. + + Set MMRBC to 4K**. + + For example you can set + + For opteron:: + + #setpci -d 17d5:* 62=1d + + For Itanium:: + + #setpci -d 17d5:* 62=3d + + For detailed description of the PCI registers, please see Xframe User Guide. + +b. Ensure Transmit Checksum offload is enabled. Use ethtool to set/verify this + parameter. + +c. Turn on TSO(using "ethtool -K"):: + + # ethtool -K <ethX> tso on + +Receive performance: + +a. By default, the driver respects BIOS settings for PCI bus parameters. + However, you may want to set PCI latency timer to 248:: + + #setpci -d 17d5:* LATENCY_TIMER=f8 + + For detailed description of the PCI registers, please see Xframe User Guide. + +b. Use 2-buffer mode. This results in large performance boost on + certain platforms(eg. SGI Altix, IBM xSeries). + +c. Ensure Receive Checksum offload is enabled. Use "ethtool -K ethX" command to + set/verify this option. + +d. Enable NAPI feature(in kernel configuration Device Drivers ---> Network + device support ---> Ethernet (10000 Mbit) ---> S2IO 10Gbe Xframe NIC) to + bring down CPU utilization. + +.. note:: + + For AMD opteron platforms with 8131 chipset, MMRBC=1 and MOST=1 are + recommended as safe parameters. + +For more information, please review the AMD8131 errata at +http://vip.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/ +26310_AMD-8131_HyperTransport_PCI-X_Tunnel_Revision_Guide_rev_3_18.pdf + +6. Support +========== + +For further support please contact either your 10GbE Xframe NIC vendor (IBM, +HP, SGI etc.) diff --git a/Documentation/networking/device_drivers/netronome/nfp.rst b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst index ada611fb427c..650b57742d51 100644 --- a/Documentation/networking/device_drivers/netronome/nfp.rst +++ b/Documentation/networking/device_drivers/ethernet/netronome/nfp.rst @@ -1,50 +1,57 @@ .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +.. include:: <isonum.txt> -============================================= -Netronome Flow Processor (NFP) Kernel Drivers -============================================= +=========================================== +Network Flow Processor (NFP) Kernel Drivers +=========================================== -Copyright (c) 2019, Netronome Systems, Inc. +:Copyright: |copy| 2019, Netronome Systems, Inc. +:Copyright: |copy| 2022, Corigine, Inc. Contents ======== - `Overview`_ - `Acquiring Firmware`_ +- `Devlink Info`_ +- `Configure Device`_ +- `Statistics`_ Overview ======== -This driver supports Netronome's line of Flow Processor devices, -including the NFP4000, NFP5000, and NFP6000 models, which are also -incorporated in the company's family of Agilio SmartNICs. The SR-IOV -physical and virtual functions for these devices are supported by -the driver. +This driver supports Netronome and Corigine's line of Network Flow Processor +devices, including the NFP3800, NFP4000, NFP5000, and NFP6000 models, which +are also incorporated in the companies' family of Agilio SmartNICs. The SR-IOV +physical and virtual functions for these devices are supported by the driver. Acquiring Firmware ================== -The NFP4000 and NFP6000 devices require application specific firmware -to function. Application firmware can be located either on the host file system +The NFP3800, NFP4000 and NFP6000 devices require application specific firmware +to function. Application firmware can be located either on the host file system or in the device flash (if supported by management firmware). Firmware files on the host filesystem contain card type (`AMDA-*` string), media -config etc. They should be placed in `/lib/firmware/netronome` directory to +config etc. They should be placed in `/lib/firmware/netronome` directory to load firmware from the host file system. Firmware for basic NIC operation is available in the upstream `linux-firmware.git` repository. +A more comprehensive list of firmware can be downloaded from the +`Corigine Support site <https://www.corigine.com/DPUDownload.html>`_. + Firmware in NVRAM ----------------- Recent versions of management firmware supports loading application -firmware from flash when the host driver gets probed. The firmware loading +firmware from flash when the host driver gets probed. The firmware loading policy configuration may be used to configure this feature appropriately. Devlink or ethtool can be used to update the application firmware on the device flash by providing the appropriate `nic_AMDA*.nffw` file to the respective -command. Users need to take care to write the correct firmware image for the +command. Users need to take care to write the correct firmware image for the card and media configuration to flash. Available storage space in flash depends on the card being used. @@ -79,9 +86,9 @@ You may need to use hard instead of symbolic links on distributions which use old `mkinitrd` command instead of `dracut` (e.g. Ubuntu). After changing firmware files you may need to regenerate the initramfs -image. Initramfs contains drivers and firmware files your system may -need to boot. Refer to the documentation of your distribution to find -out how to update initramfs. Good indication of stale initramfs +image. Initramfs contains drivers and firmware files your system may +need to boot. Refer to the documentation of your distribution to find +out how to update initramfs. Good indication of stale initramfs is system loading wrong driver or firmware on boot, but when driver is later reloaded manually everything works correctly. @@ -89,9 +96,9 @@ Selecting firmware per device ----------------------------- Most commonly all cards on the system use the same type of firmware. -If you want to load specific firmware image for a specific card, you -can use either the PCI bus address or serial number. Driver will print -which files it's looking for when it recognizes a NFP device:: +If you want to load a specific firmware image for a specific card, you +can use either the PCI bus address or serial number. The driver will +print which files it's looking for when it recognizes a NFP device:: nfp: Looking for firmware file in order of priority: nfp: netronome/serial-00-12-34-aa-bb-cc-10-ff.nffw: not found @@ -106,6 +113,15 @@ Note that `serial-*` and `pci-*` files are **not** automatically included in initramfs, you will have to refer to documentation of appropriate tools to find out how to include them. +Running firmware version +------------------------ + +The version of the loaded firmware for a particular <netdev> interface, +(e.g. enp4s0), or an interface's port <netdev port> (e.g. enp4s0np0) can +be displayed with the ethtool command:: + + $ ethtool -i <netdev> + Firmware loading policy ----------------------- @@ -132,6 +148,115 @@ abi_drv_load_ifc Defines a list of PF devices allowed to load FW on the device. This variable is not currently user configurable. +Devlink Info +============ + +The devlink info command displays the running and stored firmware versions +on the device, serial number and board information. + +Devlink info command example (replace PCI address):: + + $ devlink dev info pci/0000:03:00.0 + pci/0000:03:00.0: + driver nfp + serial_number CSAAMDA2001-1003000111 + versions: + fixed: + board.id AMDA2001-1003 + board.rev 01 + board.manufacture CSA + board.model mozart + running: + fw.mgmt 22.10.0-rc3 + fw.cpld 0x1000003 + fw.app nic-22.09.0 + chip.init AMDA-2001-1003 1003000111 + stored: + fw.bundle_id bspbundle_1003000111 + fw.mgmt 22.10.0-rc3 + fw.cpld 0x0 + chip.init AMDA-2001-1003 1003000111 + +Configure Device +================ + +This section explains how to use Agilio SmartNICs running basic NIC firmware. + +Configure interface link-speed +------------------------------ +The following steps explains how to change between 10G mode and 25G mode on +Agilio CX 2x25GbE cards. The changing of port speed must be done in order, +port 0 (p0) must be set to 10G before port 1 (p1) may be set to 10G. + +Down the respective interface(s):: + + $ ip link set dev <netdev port 0> down + $ ip link set dev <netdev port 1> down + +Set interface link-speed to 10G:: + + $ ethtool -s <netdev port 0> speed 10000 + $ ethtool -s <netdev port 1> speed 10000 + +Set interface link-speed to 25G:: + + $ ethtool -s <netdev port 0> speed 25000 + $ ethtool -s <netdev port 1> speed 25000 + +Reload driver for changes to take effect:: + + $ rmmod nfp; modprobe nfp + +Configure interface Maximum Transmission Unit (MTU) +--------------------------------------------------- + +The MTU of interfaces can temporarily be set using the iproute2, ip link or +ifconfig tools. Note that this change will not persist. Setting this via +Network Manager, or another appropriate OS configuration tool, is +recommended as changes to the MTU using Network Manager can be made to +persist. + +Set interface MTU to 9000 bytes:: + + $ ip link set dev <netdev port> mtu 9000 + +It is the responsibility of the user or the orchestration layer to set +appropriate MTU values when handling jumbo frames or utilizing tunnels. For +example, if packets sent from a VM are to be encapsulated on the card and +egress a physical port, then the MTU of the VF should be set to lower than +that of the physical port to account for the extra bytes added by the +additional header. If a setup is expected to see fallback traffic between +the SmartNIC and the kernel then the user should also ensure that the PF MTU +is appropriately set to avoid unexpected drops on this path. + +Configure Forward Error Correction (FEC) modes +---------------------------------------------- + +Agilio SmartNICs support FEC mode configuration, e.g. Auto, Firecode Base-R, +ReedSolomon and Off modes. Each physical port's FEC mode can be set +independently using ethtool. The supported FEC modes for an interface can +be viewed using:: + + $ ethtool <netdev> + +The currently configured FEC mode can be viewed using:: + + $ ethtool --show-fec <netdev> + +To force the FEC mode for a particular port, auto-negotiation must be disabled +(see the `Auto-negotiation`_ section). An example of how to set the FEC mode +to Reed-Solomon is:: + + $ ethtool --set-fec <netdev> encoding rs + +Auto-negotiation +---------------- + +To change auto-negotiation settings, the link must first be put down. After the +link is down, auto-negotiation can be enabled or disabled using:: + + ethtool -s <netdev> autoneg <on|off> + Statistics ========== diff --git a/Documentation/networking/device_drivers/ethernet/pensando/ionic.rst b/Documentation/networking/device_drivers/ethernet/pensando/ionic.rst new file mode 100644 index 000000000000..05fe2b11bb18 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/pensando/ionic.rst @@ -0,0 +1,296 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +======================================================== +Linux Driver for the Pensando(R) Ethernet adapter family +======================================================== + +Pensando Linux Ethernet driver. +Copyright(c) 2019 Pensando Systems, Inc + +Contents +======== + +- Identifying the Adapter +- Enabling the driver +- Configuring the driver +- Statistics +- Support + +Identifying the Adapter +======================= + +To find if one or more Pensando PCI Ethernet devices are installed on the +host, check for the PCI devices:: + + $ lspci -d 1dd8: + b5:00.0 Ethernet controller: Device 1dd8:1002 + b6:00.0 Ethernet controller: Device 1dd8:1002 + +If such devices are listed as above, then the ionic.ko driver should find +and configure them for use. There should be log entries in the kernel +messages such as these:: + + $ dmesg | grep ionic + ionic 0000:b5:00.0: 126.016 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x16 link) + ionic 0000:b5:00.0 enp181s0: renamed from eth0 + ionic 0000:b5:00.0 enp181s0: Link up - 100 Gbps + ionic 0000:b6:00.0: 126.016 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x16 link) + ionic 0000:b6:00.0 enp182s0: renamed from eth0 + ionic 0000:b6:00.0 enp182s0: Link up - 100 Gbps + +Driver and firmware version information can be gathered with either of +ethtool or devlink tools:: + + $ ethtool -i enp181s0 + driver: ionic + version: 5.7.0 + firmware-version: 1.8.0-28 + ... + + $ devlink dev info pci/0000:b5:00.0 + pci/0000:b5:00.0: + driver ionic + serial_number FLM18420073 + versions: + fixed: + asic.id 0x0 + asic.rev 0x0 + running: + fw 1.8.0-28 + +See Documentation/networking/devlink/ionic.rst for more information +on the devlink dev info data. + +Enabling the driver +=================== + +The driver is enabled via the standard kernel configuration system, +using the make command:: + + make oldconfig/menuconfig/etc. + +The driver is located in the menu structure at: + + -> Device Drivers + -> Network device support (NETDEVICES [=y]) + -> Ethernet driver support + -> Pensando devices + -> Pensando Ethernet IONIC Support + +Configuring the Driver +====================== + +MTU +--- + +Jumbo frame support is available with a maximum size of 9194 bytes. + +Interrupt coalescing +-------------------- + +Interrupt coalescing can be configured by changing the rx-usecs value with +the "ethtool -C" command. The rx-usecs range is 0-190. The tx-usecs value +reflects the rx-usecs value as they are tied together on the same interrupt. + +SR-IOV +------ + +Minimal SR-IOV support is currently offered and can be enabled by setting +the sysfs 'sriov_numvfs' value, if supported by your particular firmware +configuration. + +XDP +--- + +Support for XDP includes the basics, plus Jumbo frames, Redirect and +ndo_xmit. There is no current support for zero-copy sockets or HW offload. + +Statistics +========== + +Basic hardware stats +-------------------- + +The commands ``netstat -i``, ``ip -s link show``, and ``ifconfig`` show +a limited set of statistics taken directly from firmware. For example:: + + $ ip -s link show enp181s0 + 7: enp181s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 + link/ether 00:ae:cd:00:07:68 brd ff:ff:ff:ff:ff:ff + RX: bytes packets errors dropped overrun mcast + 414 5 0 0 0 0 + TX: bytes packets errors dropped carrier collsns + 1384 18 0 0 0 0 + +ethtool -S +---------- + +The statistics shown from the ``ethtool -S`` command includes a combination of +driver counters and firmware counters, including port and queue specific values. +The driver values are counters computed by the driver, and the firmware values +are gathered by the firmware from the port hardware and passed through the +driver with no further interpretation. + +Driver port specific:: + + tx_packets: 12 + tx_bytes: 964 + rx_packets: 5 + rx_bytes: 414 + tx_tso: 0 + tx_tso_bytes: 0 + tx_csum_none: 12 + tx_csum: 0 + rx_csum_none: 0 + rx_csum_complete: 3 + rx_csum_error: 0 + xdp_drop: 0 + xdp_aborted: 0 + xdp_pass: 0 + xdp_tx: 0 + xdp_redirect: 0 + xdp_frames: 0 + +Driver queue specific:: + + tx_0_pkts: 3 + tx_0_bytes: 294 + tx_0_clean: 3 + tx_0_dma_map_err: 0 + tx_0_linearize: 0 + tx_0_frags: 0 + tx_0_tso: 0 + tx_0_tso_bytes: 0 + tx_0_hwstamp_valid: 0 + tx_0_hwstamp_invalid: 0 + tx_0_csum_none: 3 + tx_0_csum: 0 + tx_0_vlan_inserted: 0 + tx_0_xdp_frames: 0 + rx_0_pkts: 2 + rx_0_bytes: 120 + rx_0_dma_map_err: 0 + rx_0_alloc_err: 0 + rx_0_csum_none: 0 + rx_0_csum_complete: 0 + rx_0_csum_error: 0 + rx_0_hwstamp_valid: 0 + rx_0_hwstamp_invalid: 0 + rx_0_dropped: 0 + rx_0_vlan_stripped: 0 + rx_0_xdp_drop: 0 + rx_0_xdp_aborted: 0 + rx_0_xdp_pass: 0 + rx_0_xdp_tx: 0 + rx_0_xdp_redirect: 0 + +Firmware port specific:: + + hw_tx_dropped: 0 + hw_rx_dropped: 0 + hw_rx_over_errors: 0 + hw_rx_missed_errors: 0 + hw_tx_aborted_errors: 0 + frames_rx_ok: 15 + frames_rx_all: 15 + frames_rx_bad_fcs: 0 + frames_rx_bad_all: 0 + octets_rx_ok: 1290 + octets_rx_all: 1290 + frames_rx_unicast: 10 + frames_rx_multicast: 5 + frames_rx_broadcast: 0 + frames_rx_pause: 0 + frames_rx_bad_length: 0 + frames_rx_undersized: 0 + frames_rx_oversized: 0 + frames_rx_fragments: 0 + frames_rx_jabber: 0 + frames_rx_pripause: 0 + frames_rx_stomped_crc: 0 + frames_rx_too_long: 0 + frames_rx_vlan_good: 3 + frames_rx_dropped: 0 + frames_rx_less_than_64b: 0 + frames_rx_64b: 4 + frames_rx_65b_127b: 11 + frames_rx_128b_255b: 0 + frames_rx_256b_511b: 0 + frames_rx_512b_1023b: 0 + frames_rx_1024b_1518b: 0 + frames_rx_1519b_2047b: 0 + frames_rx_2048b_4095b: 0 + frames_rx_4096b_8191b: 0 + frames_rx_8192b_9215b: 0 + frames_rx_other: 0 + frames_tx_ok: 31 + frames_tx_all: 31 + frames_tx_bad: 0 + octets_tx_ok: 2614 + octets_tx_total: 2614 + frames_tx_unicast: 8 + frames_tx_multicast: 21 + frames_tx_broadcast: 2 + frames_tx_pause: 0 + frames_tx_pripause: 0 + frames_tx_vlan: 0 + frames_tx_less_than_64b: 0 + frames_tx_64b: 4 + frames_tx_65b_127b: 27 + frames_tx_128b_255b: 0 + frames_tx_256b_511b: 0 + frames_tx_512b_1023b: 0 + frames_tx_1024b_1518b: 0 + frames_tx_1519b_2047b: 0 + frames_tx_2048b_4095b: 0 + frames_tx_4096b_8191b: 0 + frames_tx_8192b_9215b: 0 + frames_tx_other: 0 + frames_tx_pri_0: 0 + frames_tx_pri_1: 0 + frames_tx_pri_2: 0 + frames_tx_pri_3: 0 + frames_tx_pri_4: 0 + frames_tx_pri_5: 0 + frames_tx_pri_6: 0 + frames_tx_pri_7: 0 + frames_rx_pri_0: 0 + frames_rx_pri_1: 0 + frames_rx_pri_2: 0 + frames_rx_pri_3: 0 + frames_rx_pri_4: 0 + frames_rx_pri_5: 0 + frames_rx_pri_6: 0 + frames_rx_pri_7: 0 + tx_pripause_0_1us_count: 0 + tx_pripause_1_1us_count: 0 + tx_pripause_2_1us_count: 0 + tx_pripause_3_1us_count: 0 + tx_pripause_4_1us_count: 0 + tx_pripause_5_1us_count: 0 + tx_pripause_6_1us_count: 0 + tx_pripause_7_1us_count: 0 + rx_pripause_0_1us_count: 0 + rx_pripause_1_1us_count: 0 + rx_pripause_2_1us_count: 0 + rx_pripause_3_1us_count: 0 + rx_pripause_4_1us_count: 0 + rx_pripause_5_1us_count: 0 + rx_pripause_6_1us_count: 0 + rx_pripause_7_1us_count: 0 + rx_pause_1us_count: 0 + frames_tx_truncated: 0 + + +Support +======= + +For general Linux networking support, please use the netdev mailing +list, which is monitored by Pensando personnel:: + + netdev@vger.kernel.org + +For more specific support needs, please use the Pensando driver support +email:: + + drivers@pensando.io diff --git a/Documentation/networking/device_drivers/ethernet/smsc/smc9.rst b/Documentation/networking/device_drivers/ethernet/smsc/smc9.rst new file mode 100644 index 000000000000..e5eac896a631 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/smsc/smc9.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================ +SMC 9xxxx Driver +================ + +Revision 0.12 + +3/5/96 + +Copyright 1996 Erik Stahlman + +Released under terms of the GNU General Public License. + +This file contains the instructions and caveats for my SMC9xxx driver. You +should not be using the driver without reading this file. + +Things to note about installation: + + 1. The driver should work on all kernels from 1.2.13 until 1.3.71. + (A kernel patch is supplied for 1.3.71 ) + + 2. If you include this into the kernel, you might need to change some + options, such as for forcing IRQ. + + + 3. To compile as a module, run 'make'. + Make will give you the appropriate options for various kernel support. + + 4. Loading the driver as a module:: + + use: insmod smc9194.o + optional parameters: + io=xxxx : your base address + irq=xx : your irq + ifport=x : 0 for whatever is default + 1 for twisted pair + 2 for AUI ( or BNC on some cards ) + +How to obtain the latest version? + +FTP: + ftp://fenris.campus.vt.edu/smc9/smc9-12.tar.gz + ftp://sfbox.vt.edu/filebox/F/fenris/smc9/smc9-12.tar.gz + + +Contacting me: + erik@mail.vt.edu diff --git a/Documentation/networking/device_drivers/stmicro/stmmac.rst b/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst index c34bab3d2df0..5d46e5036129 100644 --- a/Documentation/networking/device_drivers/stmicro/stmmac.rst +++ b/Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst @@ -32,7 +32,8 @@ is also supported. DesignWare(R) Cores Ethernet MAC 10/100/1000 Universal version 3.70a (and older) and DesignWare(R) Cores Ethernet Quality-of-Service version 4.0 (and upper) have been used for developing this driver as well as -DesignWare(R) Cores XGMAC - 10G Ethernet MAC. +DesignWare(R) Cores XGMAC - 10G Ethernet MAC and DesignWare(R) Cores +Enterprise MAC - 100G Ethernet MAC. This driver supports both the platform bus and PCI. @@ -48,6 +49,8 @@ Cores Ethernet Controllers and corresponding minimum and maximum versions: +-------------------------------+--------------+--------------+--------------+ | XGMAC - 10G Ethernet MAC | 2.10a | N/A | XGMAC2+ | +-------------------------------+--------------+--------------+--------------+ +| XLGMAC - 100G Ethernet MAC | 2.00a | N/A | XLGMAC2+ | ++-------------------------------+--------------+--------------+--------------+ For questions related to hardware requirements, refer to the documentation supplied with your Ethernet adapter. All hardware requirements listed apply @@ -57,7 +60,7 @@ Feature List ============ The following features are available in this driver: - - GMII/MII/RGMII/SGMII/RMII/XGMII Interface + - GMII/MII/RGMII/SGMII/RMII/XGMII/XLGMII Interface - Half-Duplex / Full-Duplex Operation - Energy Efficient Ethernet (EEE) - IEEE 802.3x PAUSE Packets (Flow Control) diff --git a/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst new file mode 100644 index 000000000000..25fd9aa284e2 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst @@ -0,0 +1,143 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================================================== +Texas Instruments K3 AM65 CPSW NUSS switchdev based ethernet driver +=================================================================== + +:Version: 1.0 + +Port renaming +============= + +In order to rename via udev:: + + ip -d link show dev sw0p1 | grep switchid + + SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==<switchid>, \ + ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}" + + +Multi mac mode +============== + +- The driver is operating in multi-mac mode by default, thus + working as N individual network interfaces. + +Devlink configuration parameters +================================ + +See Documentation/networking/devlink/am65-nuss-cpsw-switch.rst + +Enabling "switch" +================= + +The Switch mode can be enabled by configuring devlink driver parameter +"switch_mode" to 1/true:: + + devlink dev param set platform/c000000.ethernet \ + name switch_mode value true cmode runtime + +This can be done regardless of the state of Port's netdev devices - UP/DOWN, but +Port's netdev devices have to be in UP before joining to the bridge to avoid +overwriting of bridge configuration as CPSW switch driver completely reloads its +configuration when first port changes its state to UP. + +When the both interfaces joined the bridge - CPSW switch driver will enable +marking packets with offload_fwd_mark flag. + +All configuration is implemented via switchdev API. + +Bridge setup +============ + +:: + + devlink dev param set platform/c000000.ethernet \ + name switch_mode value true cmode runtime + + ip link add name br0 type bridge + ip link set dev br0 type bridge ageing_time 1000 + ip link set dev sw0p1 up + ip link set dev sw0p2 up + ip link set dev sw0p1 master br0 + ip link set dev sw0p2 master br0 + + [*] bridge vlan add dev br0 vid 1 pvid untagged self + + [*] if vlan_filtering=1. where default_pvid=1 + + Note. Steps [*] are mandatory. + + +On/off STP +========== + +:: + + ip link set dev BRDEV type bridge stp_state 1/0 + +VLAN configuration +================== + +:: + + bridge vlan add dev br0 vid 1 pvid untagged self <---- add cpu port to VLAN 1 + +Note. This step is mandatory for bridge/default_pvid. + +Add extra VLANs +=============== + + 1. untagged:: + + bridge vlan add dev sw0p1 vid 100 pvid untagged master + bridge vlan add dev sw0p2 vid 100 pvid untagged master + bridge vlan add dev br0 vid 100 pvid untagged self <---- Add cpu port to VLAN100 + + 2. tagged:: + + bridge vlan add dev sw0p1 vid 100 master + bridge vlan add dev sw0p2 vid 100 master + bridge vlan add dev br0 vid 100 pvid tagged self <---- Add cpu port to VLAN100 + +FDBs +---- + +FDBs are automatically added on the appropriate switch port upon detection + +Manually adding FDBs:: + + bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100 + bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master <---- Add on all VLANs + +MDBs +---- + +MDBs are automatically added on the appropriate switch port upon detection + +Manually adding MDBs:: + + bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100 + bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent <---- Add on all VLANs + +Multicast flooding +================== +CPU port mcast_flooding is always on + +Turning flooding on/off on switch ports: +bridge link set dev sw0p1 mcast_flood on/off + +Access and Trunk port +===================== + +:: + + bridge vlan add dev sw0p1 vid 100 pvid untagged master + bridge vlan add dev sw0p2 vid 100 master + + + bridge vlan add dev br0 vid 100 self + ip link add link br0 name br0.100 type vlan id 100 + +Note. Setting PVID on Bridge device itself works only for +default VLAN (default_pvid). diff --git a/Documentation/networking/device_drivers/ethernet/ti/cpsw.rst b/Documentation/networking/device_drivers/ethernet/ti/cpsw.rst new file mode 100644 index 000000000000..a88946bd188b --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/ti/cpsw.rst @@ -0,0 +1,587 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +Texas Instruments CPSW ethernet driver +====================================== + +Multiqueue & CBS & MQPRIO +========================= + + +The cpsw has 3 CBS shapers for each external ports. This document +describes MQPRIO and CBS Qdisc offload configuration for cpsw driver +based on examples. It potentially can be used in audio video bridging +(AVB) and time sensitive networking (TSN). + +The following examples were tested on AM572x EVM and BBB boards. + +Test setup +========== + +Under consideration two examples with AM572x EVM running cpsw driver +in dual_emac mode. + +Several prerequisites: + +- TX queues must be rated starting from txq0 that has highest priority +- Traffic classes are used starting from 0, that has highest priority +- CBS shapers should be used with rated queues +- The bandwidth for CBS shapers has to be set a little bit more then + potential incoming rate, thus, rate of all incoming tx queues has + to be a little less +- Real rates can differ, due to discreetness +- Map skb-priority to txq is not enough, also skb-priority to l2 prio + map has to be created with ip or vconfig tool +- Any l2/socket prio (0 - 7) for classes can be used, but for + simplicity default values are used: 3 and 2 +- only 2 classes tested: A and B, but checked and can work with more, + maximum allowed 4, but only for 3 rate can be set. + +Test setup for examples +======================= + +:: + + +-------------------------------+ + |--+ | + | | Workstation0 | + |E | MAC 18:03:73:66:87:42 | + +-----------------------------+ +--|t | | + | | 1 | E | | |h |./tsn_listener -d \ | + | Target board: | 0 | t |--+ |0 | 18:03:73:66:87:42 -i eth0 \| + | AM572x EVM | 0 | h | | | -s 1500 | + | | 0 | 0 | |--+ | + | Only 2 classes: |Mb +---| +-------------------------------+ + | class A, class B | | + | | +---| +-------------------------------+ + | | 1 | E | |--+ | + | | 0 | t | | | Workstation1 | + | | 0 | h |--+ |E | MAC 20:cf:30:85:7d:fd | + | |Mb | 1 | +--|t | | + +-----------------------------+ |h |./tsn_listener -d \ | + |0 | 20:cf:30:85:7d:fd -i eth0 \| + | | -s 1500 | + |--+ | + +-------------------------------+ + + +Example 1: One port tx AVB configuration scheme for target board +---------------------------------------------------------------- + +(prints and scheme for AM572x evm, applicable for single port boards) + +- tc - traffic class +- txq - transmit queue +- p - priority +- f - fifo (cpsw fifo) +- S - shaper configured + +:: + + +------------------------------------------------------------------+ u + | +---------------+ +---------------+ +------+ +------+ | s + | | | | | | | | | | e + | | App 1 | | App 2 | | Apps | | Apps | | r + | | Class A | | Class B | | Rest | | Rest | | + | | Eth0 | | Eth0 | | Eth0 | | Eth1 | | s + | | VLAN100 | | VLAN100 | | | | | | | | p + | | 40 Mb/s | | 20 Mb/s | | | | | | | | a + | | SO_PRIORITY=3 | | SO_PRIORITY=2 | | | | | | | | c + | | | | | | | | | | | | | | e + | +---|-----------+ +---|-----------+ +---|--+ +---|--+ | + +-----|------------------|------------------|--------|-------------+ + +-+ +------------+ | | + | | +-----------------+ +--+ + | | | | + +---|-------|-------------|-----------------------|----------------+ + | +----+ +----+ +----+ +----+ +----+ | + | | p3 | | p2 | | p1 | | p0 | | p0 | | k + | \ / \ / \ / \ / \ / | e + | \ / \ / \ / \ / \ / | r + | \/ \/ \/ \/ \/ | n + | | | | | | e + | | | +-----+ | | l + | | | | | | + | +----+ +----+ +----+ +----+ | s + | |tc0 | |tc1 | |tc2 | |tc0 | | p + | \ / \ / \ / \ / | a + | \ / \ / \ / \ / | c + | \/ \/ \/ \/ | e + | | | +-----+ | | + | | | | | | | + | | | | | | | + | | | | | | | + | +----+ +----+ +----+ +----+ +----+ | + | |txq0| |txq1| |txq2| |txq3| |txq4| | + | \ / \ / \ / \ / \ / | + | \ / \ / \ / \ / \ / | + | \/ \/ \/ \/ \/ | + | +-|------|------|------|--+ +--|--------------+ | + | | | | | | | Eth0.100 | | Eth1 | | + +---|------|------|------|------------------------|----------------+ + | | | | | + p p p p | + 3 2 0-1, 4-7 <- L2 priority | + | | | | | + | | | | | + +---|------|------|------|------------------------|----------------+ + | | | | | |----------+ | + | +----+ +----+ +----+ +----+ +----+ | + | |dma7| |dma6| |dma5| |dma4| |dma3| | + | \ / \ / \ / \ / \ / | c + | \S / \S / \ / \ / \ / | p + | \/ \/ \/ \/ \/ | s + | | | | +----- | | w + | | | | | | | + | | | | | | | d + | +----+ +----+ +----+p p+----+ | r + | | | | | | |o o| | | i + | | f3 | | f2 | | f0 |r r| f0 | | v + | |tc0 | |tc1 | |tc2 |t t|tc0 | | e + | \CBS / \CBS / \CBS /1 2\CBS / | r + | \S / \S / \ / \ / | + | \/ \/ \/ \/ | + +------------------------------------------------------------------+ + + +1) :: + + + // Add 4 tx queues, for interface Eth0, and 1 tx queue for Eth1 + $ ethtool -L eth0 rx 1 tx 5 + rx unmodified, ignoring + +2) :: + + // Check if num of queues is set correctly: + $ ethtool -l eth0 + Channel parameters for eth0: + Pre-set maximums: + RX: 8 + TX: 8 + Other: 0 + Combined: 0 + Current hardware settings: + RX: 1 + TX: 5 + Other: 0 + Combined: 0 + +3) :: + + // TX queues must be rated starting from 0, so set bws for tx0 and tx1 + // Set rates 40 and 20 Mb/s appropriately. + // Pay attention, real speed can differ a bit due to discreetness. + // Leave last 2 tx queues not rated. + $ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate + $ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate + +4) :: + + // Check maximum rate of tx (cpdma) queues: + $ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate + 40 + 20 + 0 + 0 + 0 + +5) :: + + // Map skb->priority to traffic class: + // 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2 + // Map traffic class to transmit queue: + // tc0 -> txq0, tc1 -> txq1, tc2 -> (txq2, txq3) + $ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \ + map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 1 + +5a) :: + + // As two interface sharing same set of tx queues, assign all traffic + // coming to interface Eth1 to separate queue in order to not mix it + // with traffic from interface Eth0, so use separate txq to send + // packets to Eth1, so all prio -> tc0 and tc0 -> txq4 + // Here hw 0, so here still default configuration for eth1 in hw + $ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 1 \ + map 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@4 hw 0 + +6) :: + + // Check classes settings + $ tc -g class show dev eth0 + +---(100:ffe2) mqprio + | +---(100:3) mqprio + | +---(100:4) mqprio + | + +---(100:ffe1) mqprio + | +---(100:2) mqprio + | + +---(100:ffe0) mqprio + +---(100:1) mqprio + + $ tc -g class show dev eth1 + +---(100:ffe0) mqprio + +---(100:5) mqprio + +7) :: + + // Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc + // Set it +1 Mb for reserve (important!) + // here only idle slope is important, others arg are ignored + // Pay attention, real speed can differ a bit due to discreetness + $ tc qdisc add dev eth0 parent 100:1 cbs locredit -1438 \ + hicredit 62 sendslope -959000 idleslope 41000 offload 1 + net eth0: set FIFO3 bw = 50 + +8) :: + + // Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc: + // Set it +1 Mb for reserve (important!) + $ tc qdisc add dev eth0 parent 100:2 cbs locredit -1468 \ + hicredit 65 sendslope -979000 idleslope 21000 offload 1 + net eth0: set FIFO2 bw = 30 + +9) :: + + // Create vlan 100 to map sk->priority to vlan qos + $ ip link add link eth0 name eth0.100 type vlan id 100 + 8021q: 802.1Q VLAN Support v1.8 + 8021q: adding VLAN 0 to HW filter on device eth0 + 8021q: adding VLAN 0 to HW filter on device eth1 + net eth0: Adding vlanid 100 to vlan filter + +10) :: + + // Map skb->priority to L2 prio, 1 to 1 + $ ip link set eth0.100 type vlan \ + egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 + +11) :: + + // Check egress map for vlan 100 + $ cat /proc/net/vlan/eth0.100 + [...] + INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 + EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 + +12) :: + + // Run your appropriate tools with socket option "SO_PRIORITY" + // to 3 for class A and/or to 2 for class B + // (I took at https://www.spinics.net/lists/netdev/msg460869.html) + ./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500& + ./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500& + +13) :: + + // run your listener on workstation (should be in same vlan) + // (I took at https://www.spinics.net/lists/netdev/msg460869.html) + ./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500 + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39000 kbps + +14) :: + + // Restore default configuration if needed + $ ip link del eth0.100 + $ tc qdisc del dev eth1 root + $ tc qdisc del dev eth0 root + net eth0: Prev FIFO2 is shaped + net eth0: set FIFO3 bw = 0 + net eth0: set FIFO2 bw = 0 + $ ethtool -L eth0 rx 1 tx 1 + +Example 2: Two port tx AVB configuration scheme for target board +---------------------------------------------------------------- + +(prints and scheme for AM572x evm, for dual emac boards only) + +:: + + +------------------------------------------------------------------+ u + | +----------+ +----------+ +------+ +----------+ +----------+ | s + | | | | | | | | | | | | e + | | App 1 | | App 2 | | Apps | | App 3 | | App 4 | | r + | | Class A | | Class B | | Rest | | Class B | | Class A | | + | | Eth0 | | Eth0 | | | | | Eth1 | | Eth1 | | s + | | VLAN100 | | VLAN100 | | | | | VLAN100 | | VLAN100 | | p + | | 40 Mb/s | | 20 Mb/s | | | | | 10 Mb/s | | 30 Mb/s | | a + | | SO_PRI=3 | | SO_PRI=2 | | | | | SO_PRI=3 | | SO_PRI=2 | | c + | | | | | | | | | | | | | | | | | e + | +---|------+ +---|------+ +---|--+ +---|------+ +---|------+ | + +-----|-------------|-------------|---------|-------------|--------+ + +-+ +-------+ | +----------+ +----+ + | | +-------+------+ | | + | | | | | | + +---|-------|-------------|--------------|-------------|-------|---+ + | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | + | | p3 | | p2 | | p1 | | p0 | | p0 | | p1 | | p2 | | p3 | | k + | \ / \ / \ / \ / \ / \ / \ / \ / | e + | \ / \ / \ / \ / \ / \ / \ / \ / | r + | \/ \/ \/ \/ \/ \/ \/ \/ | n + | | | | | | | | e + | | | +----+ +----+ | | | l + | | | | | | | | + | +----+ +----+ +----+ +----+ +----+ +----+ | s + | |tc0 | |tc1 | |tc2 | |tc2 | |tc1 | |tc0 | | p + | \ / \ / \ / \ / \ / \ / | a + | \ / \ / \ / \ / \ / \ / | c + | \/ \/ \/ \/ \/ \/ | e + | | | +-----+ +-----+ | | | + | | | | | | | | | | + | | | | | | | | | | + | | | | | E E | | | | | + | +----+ +----+ +----+ +----+ t t +----+ +----+ +----+ +----+ | + | |txq0| |txq1| |txq4| |txq5| h h |txq6| |txq7| |txq3| |txq2| | + | \ / \ / \ / \ / 0 1 \ / \ / \ / \ / | + | \ / \ / \ / \ / . . \ / \ / \ / \ / | + | \/ \/ \/ \/ 1 1 \/ \/ \/ \/ | + | +-|------|------|------|--+ 0 0 +-|------|------|------|--+ | + | | | | | | | 0 0 | | | | | | | + +---|------|------|------|---------------|------|------|------|----+ + | | | | | | | | + p p p p p p p p + 3 2 0-1, 4-7 <-L2 pri-> 0-1, 4-7 2 3 + | | | | | | | | + | | | | | | | | + +---|------|------|------|---------------|------|------|------|----+ + | | | | | | | | | | + | +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | + | |dma7| |dma6| |dma3| |dma2| |dma1| |dma0| |dma4| |dma5| | + | \ / \ / \ / \ / \ / \ / \ / \ / | c + | \S / \S / \ / \ / \ / \ / \S / \S / | p + | \/ \/ \/ \/ \/ \/ \/ \/ | s + | | | | +----- | | | | | w + | | | | | +----+ | | | | + | | | | | | | | | | d + | +----+ +----+ +----+p p+----+ +----+ +----+ | r + | | | | | | |o o| | | | | | | i + | | f3 | | f2 | | f0 |r CPSW r| f3 | | f2 | | f0 | | v + | |tc0 | |tc1 | |tc2 |t t|tc0 | |tc1 | |tc2 | | e + | \CBS / \CBS / \CBS /1 2\CBS / \CBS / \CBS / | r + | \S / \S / \ / \S / \S / \ / | + | \/ \/ \/ \/ \/ \/ | + +------------------------------------------------------------------+ + ========================================Eth==========================> + +1) :: + + // Add 8 tx queues, for interface Eth0, but they are common, so are accessed + // by two interfaces Eth0 and Eth1. + $ ethtool -L eth1 rx 1 tx 8 + rx unmodified, ignoring + +2) :: + + // Check if num of queues is set correctly: + $ ethtool -l eth0 + Channel parameters for eth0: + Pre-set maximums: + RX: 8 + TX: 8 + Other: 0 + Combined: 0 + Current hardware settings: + RX: 1 + TX: 8 + Other: 0 + Combined: 0 + +3) :: + + // TX queues must be rated starting from 0, so set bws for tx0 and tx1 for Eth0 + // and for tx2 and tx3 for Eth1. That is, rates 40 and 20 Mb/s appropriately + // for Eth0 and 30 and 10 Mb/s for Eth1. + // Real speed can differ a bit due to discreetness + // Leave last 4 tx queues as not rated + $ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate + $ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate + $ echo 30 > /sys/class/net/eth1/queues/tx-2/tx_maxrate + $ echo 10 > /sys/class/net/eth1/queues/tx-3/tx_maxrate + +4) :: + + // Check maximum rate of tx (cpdma) queues: + $ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate + 40 + 20 + 30 + 10 + 0 + 0 + 0 + 0 + +5) :: + + // Map skb->priority to traffic class for Eth0: + // 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2 + // Map traffic class to transmit queue: + // tc0 -> txq0, tc1 -> txq1, tc2 -> (txq4, txq5) + $ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \ + map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@4 hw 1 + +6) :: + + // Check classes settings + $ tc -g class show dev eth0 + +---(100:ffe2) mqprio + | +---(100:5) mqprio + | +---(100:6) mqprio + | + +---(100:ffe1) mqprio + | +---(100:2) mqprio + | + +---(100:ffe0) mqprio + +---(100:1) mqprio + +7) :: + + // Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc for Eth0 + // here only idle slope is important, others ignored + // Real speed can differ a bit due to discreetness + $ tc qdisc add dev eth0 parent 100:1 cbs locredit -1470 \ + hicredit 62 sendslope -959000 idleslope 41000 offload 1 + net eth0: set FIFO3 bw = 50 + +8) :: + + // Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc for Eth0 + $ tc qdisc add dev eth0 parent 100:2 cbs locredit -1470 \ + hicredit 65 sendslope -979000 idleslope 21000 offload 1 + net eth0: set FIFO2 bw = 30 + +9) :: + + // Create vlan 100 to map sk->priority to vlan qos for Eth0 + $ ip link add link eth0 name eth0.100 type vlan id 100 + net eth0: Adding vlanid 100 to vlan filter + +10) :: + + // Map skb->priority to L2 prio for Eth0.100, one to one + $ ip link set eth0.100 type vlan \ + egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 + +11) :: + + // Check egress map for vlan 100 + $ cat /proc/net/vlan/eth0.100 + [...] + INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 + EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 + +12) :: + + // Map skb->priority to traffic class for Eth1: + // 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2 + // Map traffic class to transmit queue: + // tc0 -> txq2, tc1 -> txq3, tc2 -> (txq6, txq7) + $ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 3 \ + map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@2 1@3 2@6 hw 1 + +13) :: + + // Check classes settings + $ tc -g class show dev eth1 + +---(100:ffe2) mqprio + | +---(100:7) mqprio + | +---(100:8) mqprio + | + +---(100:ffe1) mqprio + | +---(100:4) mqprio + | + +---(100:ffe0) mqprio + +---(100:3) mqprio + +14) :: + + // Set rate for class A - 31 Mbit (tc0, txq2) using CBS Qdisc for Eth1 + // here only idle slope is important, others ignored, but calculated + // for interface speed - 100Mb for eth1 port. + // Set it +1 Mb for reserve (important!) + $ tc qdisc add dev eth1 parent 100:3 cbs locredit -1035 \ + hicredit 465 sendslope -69000 idleslope 31000 offload 1 + net eth1: set FIFO3 bw = 31 + +15) :: + + // Set rate for class B - 11 Mbit (tc1, txq3) using CBS Qdisc for Eth1 + // Set it +1 Mb for reserve (important!) + $ tc qdisc add dev eth1 parent 100:4 cbs locredit -1335 \ + hicredit 405 sendslope -89000 idleslope 11000 offload 1 + net eth1: set FIFO2 bw = 11 + +16) :: + + // Create vlan 100 to map sk->priority to vlan qos for Eth1 + $ ip link add link eth1 name eth1.100 type vlan id 100 + net eth1: Adding vlanid 100 to vlan filter + +17) :: + + // Map skb->priority to L2 prio for Eth1.100, one to one + $ ip link set eth1.100 type vlan \ + egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 + +18) :: + + // Check egress map for vlan 100 + $ cat /proc/net/vlan/eth1.100 + [...] + INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 + EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 + +19) :: + + // Run appropriate tools with socket option "SO_PRIORITY" to 3 + // for class A and to 2 for class B. For both interfaces + ./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500& + ./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500& + ./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p2 -s 1500& + ./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p3 -s 1500& + +20) :: + + // run your listener on workstation (should be in same vlan) + // (I took at https://www.spinics.net/lists/netdev/msg460869.html) + ./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500 + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39012 kbps + Receiving data rate: 39000 kbps + +21) :: + + // Restore default configuration if needed + $ ip link del eth1.100 + $ ip link del eth0.100 + $ tc qdisc del dev eth1 root + net eth1: Prev FIFO2 is shaped + net eth1: set FIFO3 bw = 0 + net eth1: set FIFO2 bw = 0 + $ tc qdisc del dev eth0 root + net eth0: Prev FIFO2 is shaped + net eth0: set FIFO3 bw = 0 + net eth0: set FIFO2 bw = 0 + $ ethtool -L eth0 rx 1 tx 1 diff --git a/Documentation/networking/device_drivers/ti/cpsw_switchdev.txt b/Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst index 12855ab268b8..464dce938ed1 100644 --- a/Documentation/networking/device_drivers/ti/cpsw_switchdev.txt +++ b/Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst @@ -1,30 +1,44 @@ -* Texas Instruments CPSW switchdev based ethernet driver 2.0 +.. SPDX-License-Identifier: GPL-2.0 + +====================================================== +Texas Instruments CPSW switchdev based ethernet driver +====================================================== + +:Version: 2.0 + +Port renaming +============= -- Port renaming On older udev versions renaming of ethX to swXpY will not be automatically supported -In order to rename via udev: -ip -d link show dev sw0p1 | grep switchid -SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==<switchid>, \ - ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}" +In order to rename via udev:: + + ip -d link show dev sw0p1 | grep switchid + + SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==<switchid>, \ + ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}" + +Dual mac mode +============= -==================== -# Dual mac mode -==================== - The new (cpsw_new.c) driver is operating in dual-emac mode by default, thus -working as 2 individual network interfaces. Main differences from legacy CPSW -driver are: + working as 2 individual network interfaces. Main differences from legacy CPSW + driver are: + - optimized promiscuous mode: The P0_UNI_FLOOD (both ports) is enabled in -addition to ALLMULTI (current port) instead of ALE_BYPASS. -So, Ports in promiscuous mode will keep possibility of mcast and vlan filtering, -which is provides significant benefits when ports are joined to the same bridge, -but without enabling "switch" mode, or to different bridges. + addition to ALLMULTI (current port) instead of ALE_BYPASS. + So, Ports in promiscuous mode will keep possibility of mcast and vlan + filtering, which is provides significant benefits when ports are joined + to the same bridge, but without enabling "switch" mode, or to different + bridges. - learning disabled on ports as it make not too much sense for segregated ports - no forwarding in HW. - enabled basic support for devlink. + :: + devlink dev show platform/48484000.switch @@ -38,22 +52,25 @@ but without enabling "switch" mode, or to different bridges. cmode runtime value false Devlink configuration parameters -==================== +================================ + See Documentation/networking/devlink/ti-cpsw-switch.rst -==================== -# Bridging in dual mac mode -==================== +Bridging in dual mac mode +========================= + The dual_mac mode requires two vids to be reserved for internal purposes, which, by default, equal CPSW Port numbers. As result, bridge has to be -configured in vlan unaware mode or default_pvid has to be adjusted. +configured in vlan unaware mode or default_pvid has to be adjusted:: ip link add name br0 type bridge ip link set dev br0 type bridge vlan_filtering 0 echo 0 > /sys/class/net/br0/bridge/default_pvid ip link set dev sw0p1 master br0 ip link set dev sw0p2 master br0 - - or - + +or:: + ip link add name br0 type bridge ip link set dev br0 type bridge vlan_filtering 0 echo 100 > /sys/class/net/br0/bridge/default_pvid @@ -61,11 +78,12 @@ configured in vlan unaware mode or default_pvid has to be adjusted. ip link set dev sw0p1 master br0 ip link set dev sw0p2 master br0 -==================== -# Enabling "switch" -==================== +Enabling "switch" +================= + The Switch mode can be enabled by configuring devlink driver parameter -"switch_mode" to 1/true: +"switch_mode" to 1/true:: + devlink dev param set platform/48484000.switch \ name switch_mode value 1 cmode runtime @@ -79,9 +97,11 @@ marking packets with offload_fwd_mark flag unless "ale_bypass=0" All configuration is implemented via switchdev API. -==================== -# Bridge setup -==================== +Bridge setup +============ + +:: + devlink dev param set platform/48484000.switch \ name switch_mode value 1 cmode runtime @@ -91,66 +111,77 @@ All configuration is implemented via switchdev API. ip link set dev sw0p2 up ip link set dev sw0p1 master br0 ip link set dev sw0p2 master br0 + [*] bridge vlan add dev br0 vid 1 pvid untagged self -[*] if vlan_filtering=1. where default_pvid=1 + [*] if vlan_filtering=1. where default_pvid=1 -================= -# On/off STP -================= -ip link set dev BRDEV type bridge stp_state 1/0 + Note. Steps [*] are mandatory. + + +On/off STP +========== -Note. Steps [*] are mandatory. +:: -==================== -# VLAN configuration -==================== -bridge vlan add dev br0 vid 1 pvid untagged self <---- add cpu port to VLAN 1 + ip link set dev BRDEV type bridge stp_state 1/0 + +VLAN configuration +================== + +:: + + bridge vlan add dev br0 vid 1 pvid untagged self <---- add cpu port to VLAN 1 Note. This step is mandatory for bridge/default_pvid. -================= -# Add extra VLANs -================= - 1. untagged: - bridge vlan add dev sw0p1 vid 100 pvid untagged master - bridge vlan add dev sw0p2 vid 100 pvid untagged master - bridge vlan add dev br0 vid 100 pvid untagged self <---- Add cpu port to VLAN100 +Add extra VLANs +=============== - 2. tagged: - bridge vlan add dev sw0p1 vid 100 master - bridge vlan add dev sw0p2 vid 100 master - bridge vlan add dev br0 vid 100 pvid tagged self <---- Add cpu port to VLAN100 + 1. untagged:: + + bridge vlan add dev sw0p1 vid 100 pvid untagged master + bridge vlan add dev sw0p2 vid 100 pvid untagged master + bridge vlan add dev br0 vid 100 pvid untagged self <---- Add cpu port to VLAN100 + + 2. tagged:: + + bridge vlan add dev sw0p1 vid 100 master + bridge vlan add dev sw0p2 vid 100 master + bridge vlan add dev br0 vid 100 pvid tagged self <---- Add cpu port to VLAN100 -==== FDBs -==== +---- + FDBs are automatically added on the appropriate switch port upon detection -Manually adding FDBs: -bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100 -bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master <---- Add on all VLANs +Manually adding FDBs:: + + bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100 + bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master <---- Add on all VLANs -==== MDBs -==== +---- + MDBs are automatically added on the appropriate switch port upon detection -Manually adding MDBs: -bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100 -bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent <---- Add on all VLANs +Manually adding MDBs:: + + bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100 + bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent <---- Add on all VLANs -================== Multicast flooding ================== CPU port mcast_flooding is always on -Turning flooding on/off on swithch ports: +Turning flooding on/off on switch ports: bridge link set dev sw0p1 mcast_flood on/off -================== Access and Trunk port -================== +===================== + +:: + bridge vlan add dev sw0p1 vid 100 pvid untagged master bridge vlan add dev sw0p2 vid 100 master @@ -158,52 +189,54 @@ Access and Trunk port bridge vlan add dev br0 vid 100 self ip link add link br0 name br0.100 type vlan id 100 - Note. Setting PVID on Bridge device itself working only for - default VLAN (default_pvid). +Note. Setting PVID on Bridge device itself working only for +default VLAN (default_pvid). + +NFS +=== -===================== - NFS -===================== The only way for NFS to work is by chrooting to a minimal environment when switch configuration that will affect connectivity is needed. Assuming you are booting NFS with eth1 interface(the script is hacky and it's just there to prove NFS is doable). -setup.sh: -#!/bin/sh -mkdir proc -mount -t proc none /proc -ifconfig br0 > /dev/null -if [ $? -ne 0 ]; then - echo "Setting up bridge" - ip link add name br0 type bridge - ip link set dev br0 type bridge ageing_time 1000 - ip link set dev br0 type bridge vlan_filtering 1 - - ip link set eth1 down - ip link set eth1 name sw0p1 - ip link set dev sw0p1 up - ip link set dev sw0p2 up - ip link set dev sw0p2 master br0 - ip link set dev sw0p1 master br0 - bridge vlan add dev br0 vid 1 pvid untagged self - ifconfig sw0p1 0.0.0.0 - udhchc -i br0 -fi -umount /proc - -run_nfs.sh: -#!/bin/sh -mkdir /tmp/root/bin -p -mkdir /tmp/root/lib -p - -cp -r /lib/ /tmp/root/ -cp -r /bin/ /tmp/root/ -cp /sbin/ip /tmp/root/bin -cp /sbin/bridge /tmp/root/bin -cp /sbin/ifconfig /tmp/root/bin -cp /sbin/udhcpc /tmp/root/bin -cp /path/to/setup.sh /tmp/root/bin -chroot /tmp/root/ busybox sh /bin/setup.sh - -run ./run_nfs.sh +setup.sh:: + + #!/bin/sh + mkdir proc + mount -t proc none /proc + ifconfig br0 > /dev/null + if [ $? -ne 0 ]; then + echo "Setting up bridge" + ip link add name br0 type bridge + ip link set dev br0 type bridge ageing_time 1000 + ip link set dev br0 type bridge vlan_filtering 1 + + ip link set eth1 down + ip link set eth1 name sw0p1 + ip link set dev sw0p1 up + ip link set dev sw0p2 up + ip link set dev sw0p2 master br0 + ip link set dev sw0p1 master br0 + bridge vlan add dev br0 vid 1 pvid untagged self + ifconfig sw0p1 0.0.0.0 + udhchc -i br0 + fi + umount /proc + +run_nfs.sh::: + + #!/bin/sh + mkdir /tmp/root/bin -p + mkdir /tmp/root/lib -p + + cp -r /lib/ /tmp/root/ + cp -r /bin/ /tmp/root/ + cp /sbin/ip /tmp/root/bin + cp /sbin/bridge /tmp/root/bin + cp /sbin/ifconfig /tmp/root/bin + cp /sbin/udhcpc /tmp/root/bin + cp /path/to/setup.sh /tmp/root/bin + chroot /tmp/root/ busybox sh /bin/setup.sh + + run ./run_nfs.sh diff --git a/Documentation/networking/device_drivers/ti/tlan.txt b/Documentation/networking/device_drivers/ethernet/ti/tlan.rst index 34550dfcef74..4fdc0907f4fc 100644 --- a/Documentation/networking/device_drivers/ti/tlan.txt +++ b/Documentation/networking/device_drivers/ethernet/ti/tlan.rst @@ -1,20 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +TLAN driver for Linux +===================== + +:Version: 1.14a + (C) 1997-1998 Caldera, Inc. + (C) 1998 James Banks + (C) 1999-2001 Torben Mathiasen <tmm@image.dk, torben.mathiasen@compaq.com> For driver information/updates visit http://www.compaq.com -TLAN driver for Linux, version 1.14a -README -I. Supported Devices. + +I. Supported Devices +==================== Only PCI devices will work with this driver. Supported: + + ========= ========= =========================================== Vendor ID Device ID Name + ========= ========= =========================================== 0e11 ae32 Compaq Netelligent 10/100 TX PCI UTP 0e11 ae34 Compaq Netelligent 10 T PCI UTP 0e11 ae35 Compaq Integrated NetFlex 3/P @@ -25,13 +38,14 @@ I. Supported Devices. 0e11 b030 Compaq Netelligent 10/100 TX UTP 0e11 f130 Compaq NetFlex 3/P 0e11 f150 Compaq NetFlex 3/P - 108d 0012 Olicom OC-2325 + 108d 0012 Olicom OC-2325 108d 0013 Olicom OC-2183 - 108d 0014 Olicom OC-2326 + 108d 0014 Olicom OC-2326 + ========= ========= =========================================== Caveats: - + I am not sure if 100BaseTX daughterboards (for those cards which support such things) will work. I haven't had any solid evidence either way. @@ -41,21 +55,25 @@ I. Supported Devices. The "Netelligent 10 T/2 PCI UTP/Coax" (b012) device is untested, but I do not expect any problems. - -II. Driver Options + +II. Driver Options +================== + 1. You can append debug=x to the end of the insmod line to get - debug messages, where x is a bit field where the bits mean + debug messages, where x is a bit field where the bits mean the following: - + + ==== ===================================== 0x01 Turn on general debugging messages. 0x02 Turn on receive debugging messages. 0x04 Turn on transmit debugging messages. 0x08 Turn on list debugging messages. + ==== ===================================== 2. You can append aui=1 to the end of the insmod line to cause - the adapter to use the AUI interface instead of the 10 Base T - interface. This is also what to do if you want to use the BNC + the adapter to use the AUI interface instead of the 10 Base T + interface. This is also what to do if you want to use the BNC connector on a TLAN based device. (Setting this option on a device that does not have an AUI/BNC connector will probably cause it to not function correctly.) @@ -70,41 +88,45 @@ II. Driver Options 5. You have to use speed=X duplex=Y together now. If you just do "insmod tlan.o speed=100" the driver will do Auto-Neg. - To force a 10Mbps Half-Duplex link do "insmod tlan.o speed=10 + To force a 10Mbps Half-Duplex link do "insmod tlan.o speed=10 duplex=1". 6. If the driver is built into the kernel, you can use the 3rd and 4th parameters to set aui and debug respectively. For - example: + example:: - ether=0,0,0x1,0x7,eth0 + ether=0,0,0x1,0x7,eth0 This sets aui to 0x1 and debug to 0x7, assuming eth0 is a supported TLAN device. The bits in the third byte are assigned as follows: - 0x01 = aui - 0x02 = use half duplex - 0x04 = use full duplex - 0x08 = use 10BaseT - 0x10 = use 100BaseTx + ==== =============== + 0x01 aui + 0x02 use half duplex + 0x04 use full duplex + 0x08 use 10BaseT + 0x10 use 100BaseTx + ==== =============== You also need to set both speed and duplex settings when forcing - speeds with kernel-parameters. + speeds with kernel-parameters. ether=0,0,0x12,0,eth0 will force link to 100Mbps Half-Duplex. 7. If you have more than one tlan adapter in your system, you can use the above options on a per adapter basis. To force a 100Mbit/HD - link with your eth1 adapter use: - - insmod tlan speed=0,100 duplex=0,1 + link with your eth1 adapter use:: + + insmod tlan speed=0,100 duplex=0,1 Now eth0 will use auto-neg and eth1 will be forced to 100Mbit/HD. Note that the tlan driver supports a maximum of 8 adapters. -III. Things to try if you have problems. +III. Things to try if you have problems +======================================= + 1. Make sure your card's PCI id is among those listed in section I, above. 2. Make sure routing is correct. @@ -113,5 +135,6 @@ III. Things to try if you have problems. There is also a tlan mailing list which you can join by sending "subscribe tlan" in the body of an email to majordomo@vuser.vu.union.edu. + There is also a tlan website at http://www.compaq.com diff --git a/Documentation/networking/device_drivers/toshiba/spider_net.txt b/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst index b0b75f8463b3..fe5b32be15cd 100644 --- a/Documentation/networking/device_drivers/toshiba/spider_net.txt +++ b/Documentation/networking/device_drivers/ethernet/toshiba/spider_net.rst @@ -1,6 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 - The Spidernet Device Driver - =========================== +=========================== +The Spidernet Device Driver +=========================== Written by Linas Vepstas <linas@austin.ibm.com> @@ -78,15 +80,15 @@ GDACTDPA, tail and head pointers. It will also summarize the contents of the ring, starting at the tail pointer, and listing the status of the descrs that follow. -A typical example of the output, for a nearly idle system, might be +A typical example of the output, for a nearly idle system, might be:: -net eth1: Total number of descrs=256 -net eth1: Chain tail located at descr=20 -net eth1: Chain head is at 20 -net eth1: HW curr desc (GDACTDPA) is at 21 -net eth1: Have 1 descrs with stat=x40800101 -net eth1: HW next desc (GDACNEXTDA) is at 22 -net eth1: Last 255 descrs with stat=xa0800000 + net eth1: Total number of descrs=256 + net eth1: Chain tail located at descr=20 + net eth1: Chain head is at 20 + net eth1: HW curr desc (GDACTDPA) is at 21 + net eth1: Have 1 descrs with stat=x40800101 + net eth1: HW next desc (GDACNEXTDA) is at 22 + net eth1: Last 255 descrs with stat=xa0800000 In the above, the hardware has filled in one descr, number 20. Both head and tail are pointing at 20, because it has not yet been emptied. @@ -101,11 +103,11 @@ The status x4... corresponds to "full" and status xa... corresponds to "empty". The actual value printed is RXCOMST_A. In the device driver source code, a different set of names are -used for these same concepts, so that +used for these same concepts, so that:: -"empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa -"full" == SPIDER_NET_DESCR_FRAME_END == 0x4 -"not in use" == SPIDER_NET_DESCR_NOT_IN_USE == 0xf + "empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa + "full" == SPIDER_NET_DESCR_FRAME_END == 0x4 + "not in use" == SPIDER_NET_DESCR_NOT_IN_USE == 0xf The RX RAM full bug/feature @@ -137,19 +139,19 @@ while the hardware is waiting for a different set of descrs to become empty. A call to show_rx_chain() at this point indicates the nature of the -problem. A typical print when the network is hung shows the following: - -net eth1: Spider RX RAM full, incoming packets might be discarded! -net eth1: Total number of descrs=256 -net eth1: Chain tail located at descr=255 -net eth1: Chain head is at 255 -net eth1: HW curr desc (GDACTDPA) is at 0 -net eth1: Have 1 descrs with stat=xa0800000 -net eth1: HW next desc (GDACNEXTDA) is at 1 -net eth1: Have 127 descrs with stat=x40800101 -net eth1: Have 1 descrs with stat=x40800001 -net eth1: Have 126 descrs with stat=x40800101 -net eth1: Last 1 descrs with stat=xa0800000 +problem. A typical print when the network is hung shows the following:: + + net eth1: Spider RX RAM full, incoming packets might be discarded! + net eth1: Total number of descrs=256 + net eth1: Chain tail located at descr=255 + net eth1: Chain head is at 255 + net eth1: HW curr desc (GDACTDPA) is at 0 + net eth1: Have 1 descrs with stat=xa0800000 + net eth1: HW next desc (GDACNEXTDA) is at 1 + net eth1: Have 127 descrs with stat=x40800101 + net eth1: Have 1 descrs with stat=x40800001 + net eth1: Have 126 descrs with stat=x40800101 + net eth1: Last 1 descrs with stat=xa0800000 Both the tail and head pointers are pointing at descr 255, which is marked xa... which is "empty". Thus, from the OS point of view, there @@ -198,7 +200,3 @@ For large packets, this mechanism generates a relatively small number of interrupts, about 1K/sec. For smaller packets, this will drop to zero interrupts, as the hardware can empty the queue faster than the kernel can fill it. - - - ======= END OF DOCUMENT ======== - diff --git a/Documentation/networking/device_drivers/ethernet/wangxun/ngbe.rst b/Documentation/networking/device_drivers/ethernet/wangxun/ngbe.rst new file mode 100644 index 000000000000..43a02f9943e1 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/wangxun/ngbe.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================= +Linux Base Driver for WangXun(R) Gigabit PCI Express Adapters +============================================================= + +WangXun Gigabit Linux driver. +Copyright (c) 2019 - 2022 Beijing WangXun Technology Co., Ltd. + +Support +======= + If you have problems with the software or hardware, please contact our + customer support team via email at nic-support@net-swift.com or check our website + at https://www.net-swift.com diff --git a/Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst b/Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst new file mode 100644 index 000000000000..d052ef40fe36 --- /dev/null +++ b/Documentation/networking/device_drivers/ethernet/wangxun/txgbe.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================================ +Linux Base Driver for WangXun(R) 10 Gigabit PCI Express Adapters +================================================================ + +WangXun 10 Gigabit Linux driver. +Copyright (c) 2015 - 2022 Beijing WangXun Technology Co., Ltd. + + +Contents +======== + +- Support + + +Support +======= +If you got any problem, contact Wangxun support team via nic-support@net-swift.com +and Cc: netdev. diff --git a/Documentation/networking/device_drivers/fddi/defza.rst b/Documentation/networking/device_drivers/fddi/defza.rst new file mode 100644 index 000000000000..7393f33ea705 --- /dev/null +++ b/Documentation/networking/device_drivers/fddi/defza.rst @@ -0,0 +1,63 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================================== +Notes on the DEC FDDIcontroller 700 (DEFZA-xx) driver +===================================================== + +:Version: v.1.1.4 + + +DEC FDDIcontroller 700 is DEC's first-generation TURBOchannel FDDI +network card, designed in 1990 specifically for the DECstation 5000 +model 200 workstation. The board is a single attachment station and +it was manufactured in two variations, both of which are supported. + +First is the SAS MMF DEFZA-AA option, the original design implementing +the standard MMF-PMD, however with a pair of ST connectors rather than +the usual MIC connector. The other one is the SAS ThinWire/STP DEFZA-CA +option, denoted 700-C, with the network medium selectable by a switch +between the DEC proprietary ThinWire-PMD using a BNC connector and the +standard STP-PMD using a DE-9F connector. This option can interface to +a DECconcentrator 500 device and, in the case of the STP-PMD, also other +FDDI equipment and was designed to make it easier to transition from +existing IEEE 802.3 10BASE2 Ethernet and IEEE 802.5 Token Ring networks +by providing means to reuse existing cabling. + +This driver handles any number of cards installed in a single system. +They get fddi0, fddi1, etc. interface names assigned in the order of +increasing TURBOchannel slot numbers. + +The board only supports DMA on the receive side. Transmission involves +the use of PIO. As a result under a heavy transmission load there will +be a significant impact on system performance. + +The board supports a 64-entry CAM for matching destination addresses. +Two entries are preoccupied by the Directed Beacon and Ring Purger +multicast addresses and the rest is used as a multicast filter. An +all-multi mode is also supported for LLC frames and it is used if +requested explicitly or if the CAM overflows. The promiscuous mode +supports separate enables for LLC and SMT frames, but this driver +doesn't support changing them individually. + + +Known problems: + +None. + + +To do: + +5. MAC address change. The card does not support changing the Media + Access Controller's address registers but a similar effect can be + achieved by adding an alias to the CAM. There is no way to disable + matching against the original address though. + +7. Queueing incoming/outgoing SMT frames in the driver if the SMT + receive/RMC transmit ring is full. (?) + +8. Retrieving/reporting FDDI/SNMP stats. + + +Both success and failure reports are welcome. + +Maciej W. Rozycki <macro@orcam.me.uk> diff --git a/Documentation/networking/device_drivers/fddi/index.rst b/Documentation/networking/device_drivers/fddi/index.rst new file mode 100644 index 000000000000..0b75294e6c8b --- /dev/null +++ b/Documentation/networking/device_drivers/fddi/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Fiber Distributed Data Interface (FDDI) Device Drivers +====================================================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + defza + skfp + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/fddi/skfp.rst b/Documentation/networking/device_drivers/fddi/skfp.rst new file mode 100644 index 000000000000..58f548105c1d --- /dev/null +++ b/Documentation/networking/device_drivers/fddi/skfp.rst @@ -0,0 +1,253 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: <isonum.txt> + +======================== +SysKonnect driver - SKFP +======================== + +|copy| Copyright 1998-2000 SysKonnect, + +skfp.txt created 11-May-2000 + +Readme File for skfp.o v2.06 + + +.. This file contains + + (1) OVERVIEW + (2) SUPPORTED ADAPTERS + (3) GENERAL INFORMATION + (4) INSTALLATION + (5) INCLUSION OF THE ADAPTER IN SYSTEM START + (6) TROUBLESHOOTING + (7) FUNCTION OF THE ADAPTER LEDS + (8) HISTORY + + +1. Overview +=========== + +This README explains how to use the driver 'skfp' for Linux with your +network adapter. + +Chapter 2: Contains a list of all network adapters that are supported by +this driver. + +Chapter 3: + Gives some general information. + +Chapter 4: Describes common problems and solutions. + +Chapter 5: Shows the changed functionality of the adapter LEDs. + +Chapter 6: History of development. + + +2. Supported adapters +===================== + +The network driver 'skfp' supports the following network adapters: +SysKonnect adapters: + + - SK-5521 (SK-NET FDDI-UP) + - SK-5522 (SK-NET FDDI-UP DAS) + - SK-5541 (SK-NET FDDI-FP) + - SK-5543 (SK-NET FDDI-LP) + - SK-5544 (SK-NET FDDI-LP DAS) + - SK-5821 (SK-NET FDDI-UP64) + - SK-5822 (SK-NET FDDI-UP64 DAS) + - SK-5841 (SK-NET FDDI-FP64) + - SK-5843 (SK-NET FDDI-LP64) + - SK-5844 (SK-NET FDDI-LP64 DAS) + +Compaq adapters (not tested): + + - Netelligent 100 FDDI DAS Fibre SC + - Netelligent 100 FDDI SAS Fibre SC + - Netelligent 100 FDDI DAS UTP + - Netelligent 100 FDDI SAS UTP + - Netelligent 100 FDDI SAS Fibre MIC + + +3. General Information +====================== + +From v2.01 on, the driver is integrated in the linux kernel sources. +Therefore, the installation is the same as for any other adapter +supported by the kernel. + +Refer to the manual of your distribution about the installation +of network adapters. + +Makes my life much easier :-) + +4. Troubleshooting +================== + +If you run into problems during installation, check those items: + +Problem: + The FDDI adapter cannot be found by the driver. + +Reason: + Look in /proc/pci for the following entry: + + 'FDDI network controller: SysKonnect SK-FDDI-PCI ...' + + If this entry exists, then the FDDI adapter has been + found by the system and should be able to be used. + + If this entry does not exist or if the file '/proc/pci' + is not there, then you may have a hardware problem or PCI + support may not be enabled in your kernel. + + The adapter can be checked using the diagnostic program + which is available from the SysKonnect web site: + + www.syskonnect.de + + Some COMPAQ machines have a problem with PCI under + Linux. This is described in the 'PCI howto' document + (included in some distributions or available from the + www, e.g. at 'www.linux.org') and no workaround is available. + +Problem: + You want to use your computer as a router between + multiple IP subnetworks (using multiple adapters), but + you cannot reach computers in other subnetworks. + +Reason: + Either the router's kernel is not configured for IP + forwarding or there is a problem with the routing table + and gateway configuration in at least one of the + computers. + +If your problem is not listed here, please contact our +technical support for help. + +You can send email to: linux@syskonnect.de + +When contacting our technical support, +please ensure that the following information is available: + +- System Manufacturer and Model +- Boards in your system +- Distribution +- Kernel version + + +5. Function of the Adapter LEDs +=============================== + + The functionality of the LED's on the FDDI network adapters was + changed in SMT version v2.82. With this new SMT version, the yellow + LED works as a ring operational indicator. An active yellow LED + indicates that the ring is down. The green LED on the adapter now + works as a link indicator where an active GREEN LED indicates that + the respective port has a physical connection. + + With versions of SMT prior to v2.82 a ring up was indicated if the + yellow LED was off while the green LED(s) showed the connection + status of the adapter. During a ring down the green LED was off and + the yellow LED was on. + + All implementations indicate that a driver is not loaded if + all LEDs are off. + + +6. History +========== + +v2.06 (20000511) (In-Kernel version) + New features: + + - 64 bit support + - new pci dma interface + - in kernel 2.3.99 + +v2.05 (20000217) (In-Kernel version) + New features: + + - Changes for 2.3.45 kernel + +v2.04 (20000207) (Standalone version) + New features: + + - Added rx/tx byte counter + +v2.03 (20000111) (Standalone version) + Problems fixed: + + - Fixed printk statements from v2.02 + +v2.02 (991215) (Standalone version) + Problems fixed: + + - Removed unnecessary output + - Fixed path for "printver.sh" in makefile + +v2.01 (991122) (In-Kernel version) + New features: + + - Integration in Linux kernel sources + - Support for memory mapped I/O. + +v2.00 (991112) + New features: + + - Full source released under GPL + +v1.05 (991023) + Problems fixed: + + - Compilation with kernel version 2.2.13 failed + +v1.04 (990427) + Changes: + + - New SMT module included, changing LED functionality + + Problems fixed: + + - Synchronization on SMP machines was buggy + +v1.03 (990325) + Problems fixed: + + - Interrupt routing on SMP machines could be incorrect + +v1.02 (990310) + New features: + + - Support for kernel versions 2.2.x added + - Kernel patch instead of private duplicate of kernel functions + +v1.01 (980812) + Problems fixed: + + Connection hangup with telnet + Slow telnet connection + +v1.00 beta 01 (980507) + New features: + + None. + + Problems fixed: + + None. + + Known limitations: + + - tar archive instead of standard package format (rpm). + - FDDI statistic is empty. + - not tested with 2.1.xx kernels + - integration in kernel not tested + - not tested simultaneously with FDDI adapters from other vendors. + - only X86 processors supported. + - SBA (Synchronous Bandwidth Allocator) parameters can + not be configured. + - does not work on some COMPAQ machines. See the PCI howto + document for details about this problem. + - data corruption with kernel versions below 2.0.33. diff --git a/Documentation/networking/device_drivers/hamradio/baycom.rst b/Documentation/networking/device_drivers/hamradio/baycom.rst new file mode 100644 index 000000000000..fe2d010f0e86 --- /dev/null +++ b/Documentation/networking/device_drivers/hamradio/baycom.rst @@ -0,0 +1,174 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================== +Linux Drivers for Baycom Modems +=============================== + +Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch> + +The drivers for the baycom modems have been split into +separate drivers as they did not share any code, and the driver +and device names have changed. + +This document describes the Linux Kernel Drivers for simple Baycom style +amateur radio modems. + +The following drivers are available: +==================================== + +baycom_ser_fdx: + This driver supports the SER12 modems either full or half duplex. + Its baud rate may be changed via the ``baud`` module parameter, + therefore it supports just about every bit bang modem on a + serial port. Its devices are called bcsf0 through bcsf3. + This is the recommended driver for SER12 type modems, + however if you have a broken UART clone that does not have working + delta status bits, you may try baycom_ser_hdx. + +baycom_ser_hdx: + This is an alternative driver for SER12 type modems. + It only supports half duplex, and only 1200 baud. Its devices + are called bcsh0 through bcsh3. Use this driver only if baycom_ser_fdx + does not work with your UART. + +baycom_par: + This driver supports the par96 and picpar modems. + Its devices are called bcp0 through bcp3. + +baycom_epp: + This driver supports the EPP modem. + Its devices are called bce0 through bce3. + This driver is work-in-progress. + +The following modems are supported: + +======= ======================================================================== +ser12 This is a very simple 1200 baud AFSK modem. The modem consists only + of a modulator/demodulator chip, usually a TI TCM3105. The computer + is responsible for regenerating the receiver bit clock, as well as + for handling the HDLC protocol. The modem connects to a serial port, + hence the name. Since the serial port is not used as an async serial + port, the kernel driver for serial ports cannot be used, and this + driver only supports standard serial hardware (8250, 16450, 16550) + +par96 This is a modem for 9600 baud FSK compatible to the G3RUH standard. + The modem does all the filtering and regenerates the receiver clock. + Data is transferred from and to the PC via a shift register. + The shift register is filled with 16 bits and an interrupt is signalled. + The PC then empties the shift register in a burst. This modem connects + to the parallel port, hence the name. The modem leaves the + implementation of the HDLC protocol and the scrambler polynomial to + the PC. + +picpar This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem + is protocol compatible to par96, but uses only three low power ICs + and can therefore be fed from the parallel port and does not require + an additional power supply. Furthermore, it incorporates a carrier + detect circuitry. + +EPP This is a high-speed modem adaptor that connects to an enhanced parallel + port. + + Its target audience is users working over a high speed hub (76.8kbit/s). + +eppfpga This is a redesign of the EPP adaptor. +======= ======================================================================== + +All of the above modems only support half duplex communications. However, +the driver supports the KISS (see below) fullduplex command. It then simply +starts to send as soon as there's a packet to transmit and does not care +about DCD, i.e. it starts to send even if there's someone else on the channel. +This command is required by some implementations of the DAMA channel +access protocol. + + +The Interface of the drivers +============================ + +Unlike previous drivers, these drivers are no longer character devices, +but they are now true kernel network interfaces. Installation is therefore +simple. Once installed, four interfaces named bc{sf,sh,p,e}[0-3] are available. +sethdlc from the ax25 utilities may be used to set driver states etc. +Users of userland AX.25 stacks may use the net2kiss utility (also available +in the ax25 utilities package) to convert packets of a network interface +to a KISS stream on a pseudo tty. There's also a patch available from +me for WAMPES which allows attaching a kernel network interface directly. + + +Configuring the driver +====================== + +Every time a driver is inserted into the kernel, it has to know which +modems it should access at which ports. This can be done with the setbaycom +utility. If you are only using one modem, you can also configure the +driver from the insmod command line (or by means of an option line in +``/etc/modprobe.d/*.conf``). + +Examples:: + + modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4 + sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4 + +Both lines configure the first port to drive a ser12 modem at the first +serial port (COM1 under DOS). The * in the mode parameter instructs the driver +to use the software DCD algorithm (see below):: + + insmod baycom_par mode="picpar" iobase=0x378 + sethdlc -i bcp0 -p mode "picpar" io 0x378 + +Both lines configure the first port to drive a picpar modem at the +first parallel port (LPT1 under DOS). (Note: picpar implies +hardware DCD, par96 implies software DCD). + +The channel access parameters can be set with sethdlc -a or kissparms. +Note that both utilities interpret the values slightly differently. + + +Hardware DCD versus Software DCD +================================ + +To avoid collisions on the air, the driver must know when the channel is +busy. This is the task of the DCD circuitry/software. The driver may either +utilise a software DCD algorithm (options=1) or use a DCD signal from +the hardware (options=0). + +======= ================================================================= +ser12 if software DCD is utilised, the radio's squelch should always be + open. It is highly recommended to use the software DCD algorithm, + as it is much faster than most hardware squelch circuitry. The + disadvantage is a slightly higher load on the system. + +par96 the software DCD algorithm for this type of modem is rather poor. + The modem simply does not provide enough information to implement + a reasonable DCD algorithm in software. Therefore, if your radio + feeds the DCD input of the PAR96 modem, the use of the hardware + DCD circuitry is recommended. + +picpar the picpar modem features a builtin DCD hardware, which is highly + recommended. +======= ================================================================= + + + +Compatibility with the rest of the Linux kernel +=============================================== + +The serial driver and the baycom serial drivers compete +for the same hardware resources. Of course only one driver can access a given +interface at a time. The serial driver grabs all interfaces it can find at +startup time. Therefore the baycom drivers subsequently won't be able to +access a serial port. You might therefore find it necessary to release +a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where +# is the number of the interface. The baycom drivers do not reserve any +ports at startup, unless one is specified on the 'insmod' command line. Another +method to solve the problem is to compile all drivers as modules and +leave it to kmod to load the correct driver depending on the application. + +The parallel port drivers (baycom_par, baycom_epp) now use the parport subsystem +to arbitrate the ports between different client drivers. + +vy 73s de + +Tom Sailer, sailer@ife.ee.ethz.ch + +hb9jnx @ hb9w.ampr.org diff --git a/Documentation/networking/device_drivers/hamradio/index.rst b/Documentation/networking/device_drivers/hamradio/index.rst new file mode 100644 index 000000000000..7e731732057b --- /dev/null +++ b/Documentation/networking/device_drivers/hamradio/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Amateur Radio Device Drivers +============================ + +Contents: + +.. toctree:: + :maxdepth: 2 + + baycom + z8530drv + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/hamradio/z8530drv.rst b/Documentation/networking/device_drivers/hamradio/z8530drv.rst new file mode 100644 index 000000000000..d2942760f167 --- /dev/null +++ b/Documentation/networking/device_drivers/hamradio/z8530drv.rst @@ -0,0 +1,686 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +========================================================= +SCC.C - Linux driver for Z8530 based HDLC cards for AX.25 +========================================================= + + +This is a subset of the documentation. To use this driver you MUST have the +full package from: + +Internet: + + 1. ftp://ftp.ccac.rwth-aachen.de/pub/jr/z8530drv-utils_3.0-3.tar.gz + + 2. ftp://ftp.pspt.fi/pub/ham/linux/ax25/z8530drv-utils_3.0-3.tar.gz + +Please note that the information in this document may be hopelessly outdated. +A new version of the documentation, along with links to other important +Linux Kernel AX.25 documentation and programs, is available on +http://yaina.de/jreuter + +Copyright |copy| 1993,2000 by Joerg Reuter DL1BKE <jreuter@yaina.de> + +portions Copyright |copy| 1993 Guido ten Dolle PE1NNZ + +for the complete copyright notice see >> Copying.Z8530DRV << + +1. Initialization of the driver +=============================== + +To use the driver, 3 steps must be performed: + + 1. if compiled as module: loading the module + 2. Setup of hardware, MODEM and KISS parameters with sccinit + 3. Attach each channel to the Linux kernel AX.25 with "ifconfig" + +Unlike the versions below 2.4 this driver is a real network device +driver. If you want to run xNOS instead of our fine kernel AX.25 +use a 2.x version (available from above sites) or read the +AX.25-HOWTO on how to emulate a KISS TNC on network device drivers. + + +1.1 Loading the module +====================== + +(If you're going to compile the driver as a part of the kernel image, + skip this chapter and continue with 1.2) + +Before you can use a module, you'll have to load it with:: + + insmod scc.o + +please read 'man insmod' that comes with module-init-tools. + +You should include the insmod in one of the /etc/rc.d/rc.* files, +and don't forget to insert a call of sccinit after that. It +will read your /etc/z8530drv.conf. + +1.2. /etc/z8530drv.conf +======================= + +To setup all parameters you must run /sbin/sccinit from one +of your rc.*-files. This has to be done BEFORE you can +"ifconfig" an interface. Sccinit reads the file /etc/z8530drv.conf +and sets the hardware, MODEM and KISS parameters. A sample file is +delivered with this package. Change it to your needs. + +The file itself consists of two main sections. + +1.2.1 configuration of hardware parameters +========================================== + +The hardware setup section defines the following parameters for each +Z8530:: + + chip 1 + data_a 0x300 # data port A + ctrl_a 0x304 # control port A + data_b 0x301 # data port B + ctrl_b 0x305 # control port B + irq 5 # IRQ No. 5 + pclock 4915200 # clock + board BAYCOM # hardware type + escc no # enhanced SCC chip? (8580/85180/85280) + vector 0 # latch for interrupt vector + special no # address of special function register + option 0 # option to set via sfr + + +chip + - this is just a delimiter to make sccinit a bit simpler to + program. A parameter has no effect. + +data_a + - the address of the data port A of this Z8530 (needed) +ctrl_a + - the address of the control port A (needed) +data_b + - the address of the data port B (needed) +ctrl_b + - the address of the control port B (needed) + +irq + - the used IRQ for this chip. Different chips can use different + IRQs or the same. If they share an interrupt, it needs to be + specified within one chip-definition only. + +pclock - the clock at the PCLK pin of the Z8530 (option, 4915200 is + default), measured in Hertz + +board + - the "type" of the board: + + ======================= ======== + SCC type value + ======================= ======== + PA0HZP SCC card PA0HZP + EAGLE card EAGLE + PC100 card PC100 + PRIMUS-PC (DG9BL) card PRIMUS + BayCom (U)SCC card BAYCOM + ======================= ======== + +escc + - if you want support for ESCC chips (8580, 85180, 85280), set + this to "yes" (option, defaults to "no") + +vector + - address of the vector latch (aka "intack port") for PA0HZP + cards. There can be only one vector latch for all chips! + (option, defaults to 0) + +special + - address of the special function register on several cards. + (option, defaults to 0) + +option - The value you write into that register (option, default is 0) + +You can specify up to four chips (8 channels). If this is not enough, +just change:: + + #define MAXSCC 4 + +to a higher value. + +Example for the BAYCOM USCC: +---------------------------- + +:: + + chip 1 + data_a 0x300 # data port A + ctrl_a 0x304 # control port A + data_b 0x301 # data port B + ctrl_b 0x305 # control port B + irq 5 # IRQ No. 5 (#) + board BAYCOM # hardware type (*) + # + # SCC chip 2 + # + chip 2 + data_a 0x302 + ctrl_a 0x306 + data_b 0x303 + ctrl_b 0x307 + board BAYCOM + +An example for a PA0HZP card: +----------------------------- + +:: + + chip 1 + data_a 0x153 + data_b 0x151 + ctrl_a 0x152 + ctrl_b 0x150 + irq 9 + pclock 4915200 + board PA0HZP + vector 0x168 + escc no + # + # + # + chip 2 + data_a 0x157 + data_b 0x155 + ctrl_a 0x156 + ctrl_b 0x154 + irq 9 + pclock 4915200 + board PA0HZP + vector 0x168 + escc no + +A DRSI would should probably work with this: +-------------------------------------------- +(actually: two DRSI cards...) + +:: + + chip 1 + data_a 0x303 + data_b 0x301 + ctrl_a 0x302 + ctrl_b 0x300 + irq 7 + pclock 4915200 + board DRSI + escc no + # + # + # + chip 2 + data_a 0x313 + data_b 0x311 + ctrl_a 0x312 + ctrl_b 0x310 + irq 7 + pclock 4915200 + board DRSI + escc no + +Note that you cannot use the on-board baudrate generator off DRSI +cards. Use "mode dpll" for clock source (see below). + +This is based on information provided by Mike Bilow (and verified +by Paul Helay) + +The utility "gencfg" +-------------------- + +If you only know the parameters for the PE1CHL driver for DOS, +run gencfg. It will generate the correct port addresses (I hope). +Its parameters are exactly the same as the ones you use with +the "attach scc" command in net, except that the string "init" must +not appear. Example:: + + gencfg 2 0x150 4 2 0 1 0x168 9 4915200 + +will print a skeleton z8530drv.conf for the OptoSCC to stdout. + +:: + + gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10 + +does the same for the BAYCOM USCC card. In my opinion it is much easier +to edit scc_config.h... + + +1.2.2 channel configuration +=========================== + +The channel definition is divided into three sub sections for each +channel: + +An example for scc0:: + + # DEVICE + + device scc0 # the device for the following params + + # MODEM / BUFFERS + + speed 1200 # the default baudrate + clock dpll # clock source: + # dpll = normal half duplex operation + # external = MODEM provides own Rx/Tx clock + # divider = use full duplex divider if + # installed (1) + mode nrzi # HDLC encoding mode + # nrzi = 1k2 MODEM, G3RUH 9k6 MODEM + # nrz = DF9IC 9k6 MODEM + # + bufsize 384 # size of buffers. Note that this must include + # the AX.25 header, not only the data field! + # (optional, defaults to 384) + + # KISS (Layer 1) + + txdelay 36 # (see chapter 1.4) + persist 64 + slot 8 + tail 8 + fulldup 0 + wait 12 + min 3 + maxkey 7 + idle 3 + maxdef 120 + group 0 + txoff off + softdcd on + slip off + +The order WITHIN these sections is unimportant. The order OF these +sections IS important. The MODEM parameters are set with the first +recognized KISS parameter... + +Please note that you can initialize the board only once after boot +(or insmod). You can change all parameters but "mode" and "clock" +later with the Sccparam program or through KISS. Just to avoid +security holes... + +(1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not + present at all (BayCom). It feeds back the output of the DPLL + (digital pll) as transmit clock. Using this mode without a divider + installed will normally result in keying the transceiver until + maxkey expires --- of course without sending anything (useful). + +2. Attachment of a channel by your AX.25 software +================================================= + +2.1 Kernel AX.25 +================ + +To set up an AX.25 device you can simply type:: + + ifconfig scc0 44.128.1.1 hw ax25 dl0tha-7 + +This will create a network interface with the IP number 44.128.20.107 +and the callsign "dl0tha". If you do not have any IP number (yet) you +can use any of the 44.128.0.0 network. Note that you do not need +axattach. The purpose of axattach (like slattach) is to create a KISS +network device linked to a TTY. Please read the documentation of the +ax25-utils and the AX.25-HOWTO to learn how to set the parameters of +the kernel AX.25. + +2.2 NOS, NET and TFKISS +======================= + +Since the TTY driver (aka KISS TNC emulation) is gone you need +to emulate the old behaviour. The cost of using these programs is +that you probably need to compile the kernel AX.25, regardless of whether +you actually use it or not. First setup your /etc/ax25/axports, +for example:: + + 9k6 dl0tha-9 9600 255 4 9600 baud port (scc3) + axlink dl0tha-15 38400 255 4 Link to NOS + +Now "ifconfig" the scc device:: + + ifconfig scc3 44.128.1.1 hw ax25 dl0tha-9 + +You can now axattach a pseudo-TTY:: + + axattach /dev/ptys0 axlink + +and start your NOS and attach /dev/ptys0 there. The problem is that +NOS is reachable only via digipeating through the kernel AX.25 +(disastrous on a DAMA controlled channel). To solve this problem, +configure "rxecho" to echo the incoming frames from "9k6" to "axlink" +and outgoing frames from "axlink" to "9k6" and start:: + + rxecho + +Or simply use "kissbridge" coming with z8530drv-utils:: + + ifconfig scc3 hw ax25 dl0tha-9 + kissbridge scc3 /dev/ptys0 + + +3. Adjustment and Display of parameters +======================================= + +3.1 Displaying SCC Parameters: +============================== + +Once a SCC channel has been attached, the parameter settings and +some statistic information can be shown using the param program:: + + dl1bke-u:~$ sccstat scc0 + + Parameters: + + speed : 1200 baud + txdelay : 36 + persist : 255 + slottime : 0 + txtail : 8 + fulldup : 1 + waittime : 12 + mintime : 3 sec + maxkeyup : 7 sec + idletime : 3 sec + maxdefer : 120 sec + group : 0x00 + txoff : off + softdcd : on + SLIP : off + + Status: + + HDLC Z8530 Interrupts Buffers + ----------------------------------------------------------------------- + Sent : 273 RxOver : 0 RxInts : 125074 Size : 384 + Received : 1095 TxUnder: 0 TxInts : 4684 NoSpace : 0 + RxErrors : 1591 ExInts : 11776 + TxErrors : 0 SpInts : 1503 + Tx State : idle + + +The status info shown is: + +============== ============================================================== +Sent number of frames transmitted +Received number of frames received +RxErrors number of receive errors (CRC, ABORT) +TxErrors number of discarded Tx frames (due to various reasons) +Tx State status of the Tx interrupt handler: idle/busy/active/tail (2) +RxOver number of receiver overruns +TxUnder number of transmitter underruns +RxInts number of receiver interrupts +TxInts number of transmitter interrupts +EpInts number of receiver special condition interrupts +SpInts number of external/status interrupts +Size maximum size of an AX.25 frame (*with* AX.25 headers!) +NoSpace number of times a buffer could not get allocated +============== ============================================================== + +An overrun is abnormal. If lots of these occur, the product of +baudrate and number of interfaces is too high for the processing +power of your computer. NoSpace errors are unlikely to be caused by the +driver or the kernel AX.25. + + +3.2 Setting Parameters +====================== + + +The setting of parameters of the emulated KISS TNC is done in the +same way in the SCC driver. You can change parameters by using +the kissparms program from the ax25-utils package or use the program +"sccparam":: + + sccparam <device> <paramname> <decimal-|hexadecimal value> + +You can change the following parameters: + +=========== ===== +param value +=========== ===== +speed 1200 +txdelay 36 +persist 255 +slottime 0 +txtail 8 +fulldup 1 +waittime 12 +mintime 3 +maxkeyup 7 +idletime 3 +maxdefer 120 +group 0x00 +txoff off +softdcd on +SLIP off +=========== ===== + + +The parameters have the following meaning: + +speed: + The baudrate on this channel in bits/sec + + Example: sccparam /dev/scc3 speed 9600 + +txdelay: + The delay (in units of 10 ms) after keying of the + transmitter, until the first byte is sent. This is usually + called "TXDELAY" in a TNC. When 0 is specified, the driver + will just wait until the CTS signal is asserted. This + assumes the presence of a timer or other circuitry in the + MODEM and/or transmitter, that asserts CTS when the + transmitter is ready for data. + A normal value of this parameter is 30-36. + + Example: sccparam /dev/scc0 txd 20 + +persist: + This is the probability that the transmitter will be keyed + when the channel is found to be free. It is a value from 0 + to 255, and the probability is (value+1)/256. The value + should be somewhere near 50-60, and should be lowered when + the channel is used more heavily. + + Example: sccparam /dev/scc2 persist 20 + +slottime: + This is the time between samples of the channel. It is + expressed in units of 10 ms. About 200-300 ms (value 20-30) + seems to be a good value. + + Example: sccparam /dev/scc0 slot 20 + +tail: + The time the transmitter will remain keyed after the last + byte of a packet has been transferred to the SCC. This is + necessary because the CRC and a flag still have to leave the + SCC before the transmitter is keyed down. The value depends + on the baudrate selected. A few character times should be + sufficient, e.g. 40ms at 1200 baud. (value 4) + The value of this parameter is in 10 ms units. + + Example: sccparam /dev/scc2 4 + +full: + The full-duplex mode switch. This can be one of the following + values: + + 0: The interface will operate in CSMA mode (the normal + half-duplex packet radio operation) + 1: Fullduplex mode, i.e. the transmitter will be keyed at + any time, without checking the received carrier. It + will be unkeyed when there are no packets to be sent. + 2: Like 1, but the transmitter will remain keyed, also + when there are no packets to be sent. Flags will be + sent in that case, until a timeout (parameter 10) + occurs. + + Example: sccparam /dev/scc0 fulldup off + +wait: + The initial waittime before any transmit attempt, after the + frame has been queue for transmit. This is the length of + the first slot in CSMA mode. In full duplex modes it is + set to 0 for maximum performance. + The value of this parameter is in 10 ms units. + + Example: sccparam /dev/scc1 wait 4 + +maxkey: + The maximal time the transmitter will be keyed to send + packets, in seconds. This can be useful on busy CSMA + channels, to avoid "getting a bad reputation" when you are + generating a lot of traffic. After the specified time has + elapsed, no new frame will be started. Instead, the trans- + mitter will be switched off for a specified time (parameter + min), and then the selected algorithm for keyup will be + started again. + The value 0 as well as "off" will disable this feature, + and allow infinite transmission time. + + Example: sccparam /dev/scc0 maxk 20 + +min: + This is the time the transmitter will be switched off when + the maximum transmission time is exceeded. + + Example: sccparam /dev/scc3 min 10 + +idle: + This parameter specifies the maximum idle time in full duplex + 2 mode, in seconds. When no frames have been sent for this + time, the transmitter will be keyed down. A value of 0 is + has same result as the fullduplex mode 1. This parameter + can be disabled. + + Example: sccparam /dev/scc2 idle off # transmit forever + +maxdefer + This is the maximum time (in seconds) to wait for a free channel + to send. When this timer expires the transmitter will be keyed + IMMEDIATELY. If you love to get trouble with other users you + should set this to a very low value ;-) + + Example: sccparam /dev/scc0 maxdefer 240 # 2 minutes + + +txoff: + When this parameter has the value 0, the transmission of packets + is enable. Otherwise it is disabled. + + Example: sccparam /dev/scc2 txoff on + +group: + It is possible to build special radio equipment to use more than + one frequency on the same band, e.g. using several receivers and + only one transmitter that can be switched between frequencies. + Also, you can connect several radios that are active on the same + band. In these cases, it is not possible, or not a good idea, to + transmit on more than one frequency. The SCC driver provides a + method to lock transmitters on different interfaces, using the + "param <interface> group <x>" command. This will only work when + you are using CSMA mode (parameter full = 0). + + The number <x> must be 0 if you want no group restrictions, and + can be computed as follows to create restricted groups: + <x> is the sum of some OCTAL numbers: + + + === ======================================================= + 200 This transmitter will only be keyed when all other + transmitters in the group are off. + 100 This transmitter will only be keyed when the carrier + detect of all other interfaces in the group is off. + 0xx A byte that can be used to define different groups. + Interfaces are in the same group, when the logical AND + between their xx values is nonzero. + === ======================================================= + + Examples: + + When 2 interfaces use group 201, their transmitters will never be + keyed at the same time. + + When 2 interfaces use group 101, the transmitters will only key + when both channels are clear at the same time. When group 301, + the transmitters will not be keyed at the same time. + + Don't forget to convert the octal numbers into decimal before + you set the parameter. + + Example: (to be written) + +softdcd: + use a software dcd instead of the real one... Useful for a very + slow squelch. + + Example: sccparam /dev/scc0 soft on + + +4. Problems +=========== + +If you have tx-problems with your BayCom USCC card please check +the manufacturer of the 8530. SGS chips have a slightly +different timing. Try Zilog... A solution is to write to register 8 +instead to the data port, but this won't work with the ESCC chips. +*SIGH!* + +A very common problem is that the PTT locks until the maxkeyup timer +expires, although interrupts and clock source are correct. In most +cases compiling the driver with CONFIG_SCC_DELAY (set with +make config) solves the problems. For more hints read the (pseudo) FAQ +and the documentation coming with z8530drv-utils. + +I got reports that the driver has problems on some 386-based systems. +(i.e. Amstrad) Those systems have a bogus AT bus timing which will +lead to delayed answers on interrupts. You can recognize these +problems by looking at the output of Sccstat for the suspected +port. If it shows under- and overruns you own such a system. + +Delayed processing of received data: This depends on + +- the kernel version + +- kernel profiling compiled or not + +- a high interrupt load + +- a high load of the machine --- running X, Xmorph, XV and Povray, + while compiling the kernel... hmm ... even with 32 MB RAM ... ;-) + Or running a named for the whole .ampr.org domain on an 8 MB + box... + +- using information from rxecho or kissbridge. + +Kernel panics: please read /linux/README and find out if it +really occurred within the scc driver. + +If you cannot solve a problem, send me + +- a description of the problem, +- information on your hardware (computer system, scc board, modem) +- your kernel version +- the output of cat /proc/net/z8530 + +4. Thor RLC100 +============== + +Mysteriously this board seems not to work with the driver. Anyone +got it up-and-running? + + +Many thanks to Linus Torvalds and Alan Cox for including the driver +in the Linux standard distribution and their support. + +:: + + Joerg Reuter ampr-net: dl1bke@db0pra.ampr.org + AX-25 : DL1BKE @ DB0ABH.#BAY.DEU.EU + Internet: jreuter@yaina.de + WWW : http://yaina.de/jreuter diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index a191faaf97de..0dd30a84ce25 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -1,32 +1,22 @@ .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -Vendor Device Drivers -===================== +Hardware Device Drivers +======================= Contents: .. toctree:: :maxdepth: 2 - freescale/dpaa2/index - intel/e100 - intel/e1000 - intel/e1000e - intel/fm10k - intel/igb - intel/igbvf - intel/ixgb - intel/ixgbe - intel/ixgbevf - intel/i40e - intel/iavf - intel/ice - google/gve - marvell/octeontx2 - mellanox/mlx5 - netronome/nfp - pensando/ionic - stmicro/stmmac + atm/index + cable/index + can/index + cellular/index + ethernet/index + fddi/index + hamradio/index + wifi/index + wwan/index .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/intel/ice.rst b/Documentation/networking/device_drivers/intel/ice.rst deleted file mode 100644 index ee43ea57d443..000000000000 --- a/Documentation/networking/device_drivers/intel/ice.rst +++ /dev/null @@ -1,46 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0+ - -================================================================== -Linux Base Driver for the Intel(R) Ethernet Connection E800 Series -================================================================== - -Intel ice Linux driver. -Copyright(c) 2018 Intel Corporation. - -Contents -======== - -- Enabling the driver -- Support - -The driver in this release supports Intel's E800 Series of products. For -more information, visit Intel's support page at https://support.intel.com. - -Enabling the driver -=================== -The driver is enabled via the standard kernel configuration system, -using the make command:: - - make oldconfig/menuconfig/etc. - -The driver is located in the menu structure at: - - -> Device Drivers - -> Network device support (NETDEVICES [=y]) - -> Ethernet driver support - -> Intel devices - -> Intel(R) Ethernet Connection E800 Series Support - -Support -======= -For general information, go to the Intel support website at: - -https://www.intel.com/support/ - -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - -If an issue is identified with the released source code on a supported kernel -with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net. diff --git a/Documentation/networking/device_drivers/intel/ixgb.rst b/Documentation/networking/device_drivers/intel/ixgb.rst deleted file mode 100644 index 945018207a92..000000000000 --- a/Documentation/networking/device_drivers/intel/ixgb.rst +++ /dev/null @@ -1,468 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0+ - -===================================================================== -Linux Base Driver for 10 Gigabit Intel(R) Ethernet Network Connection -===================================================================== - -October 1, 2018 - - -Contents -======== - -- In This Release -- Identifying Your Adapter -- Command Line Parameters -- Improving Performance -- Additional Configurations -- Known Issues/Troubleshooting -- Support - - - -In This Release -=============== - -This file describes the ixgb Linux Base Driver for the 10 Gigabit Intel(R) -Network Connection. This driver includes support for Itanium(R)2-based -systems. - -For questions related to hardware requirements, refer to the documentation -supplied with your 10 Gigabit adapter. All hardware requirements listed apply -to use with Linux. - -The following features are available in this kernel: - - Native VLANs - - Channel Bonding (teaming) - - SNMP - -Channel Bonding documentation can be found in the Linux kernel source: -/Documentation/networking/bonding.txt - -The driver information previously displayed in the /proc filesystem is not -supported in this release. Alternatively, you can use ethtool (version 1.6 -or later), lspci, and iproute2 to obtain the same information. - -Instructions on updating ethtool can be found in the section "Additional -Configurations" later in this document. - - -Identifying Your Adapter -======================== - -The following Intel network adapters are compatible with the drivers in this -release: - -+------------+------------------------------+----------------------------------+ -| Controller | Adapter Name | Physical Layer | -+============+==============================+==================================+ -| 82597EX | Intel(R) PRO/10GbE LR/SR/CX4 | - 10G Base-LR (fiber) | -| | Server Adapters | - 10G Base-SR (fiber) | -| | | - 10G Base-CX4 (copper) | -+------------+------------------------------+----------------------------------+ - -For more information on how to identify your adapter, go to the Adapter & -Driver ID Guide at: - - https://support.intel.com - - -Command Line Parameters -======================= - -If the driver is built as a module, the following optional parameters are -used by entering them on the command line with the modprobe command using -this syntax:: - - modprobe ixgb [<option>=<VAL1>,<VAL2>,...] - -For example, with two 10GbE PCI adapters, entering:: - - modprobe ixgb TxDescriptors=80,128 - -loads the ixgb driver with 80 TX resources for the first adapter and 128 TX -resources for the second adapter. - -The default value for each parameter is generally the recommended setting, -unless otherwise noted. - -Copybreak ---------- -:Valid Range: 0-XXXX -:Default Value: 256 - - This is the maximum size of packet that is copied to a new buffer on - receive. - -Debug ------ -:Valid Range: 0-16 (0=none,...,16=all) -:Default Value: 0 - - This parameter adjusts the level of debug messages displayed in the - system logs. - -FlowControl ------------ -:Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) -:Default Value: 1 if no EEPROM, otherwise read from EEPROM - - This parameter controls the automatic generation(Tx) and response(Rx) to - Ethernet PAUSE frames. There are hardware bugs associated with enabling - Tx flow control so beware. - -RxDescriptors -------------- -:Valid Range: 64-4096 -:Default Value: 1024 - - This value is the number of receive descriptors allocated by the driver. - Increasing this value allows the driver to buffer more incoming packets. - Each descriptor is 16 bytes. A receive buffer is also allocated for - each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, - depending on the MTU setting. When the MTU size is 1500 or less, the - receive buffer size is 2048 bytes. When the MTU is greater than 1500 the - receive buffer size will be either 4056, 8192, or 16384 bytes. The - maximum MTU size is 16114. - -TxDescriptors -------------- -:Valid Range: 64-4096 -:Default Value: 256 - - This value is the number of transmit descriptors allocated by the driver. - Increasing this value allows the driver to queue more transmits. Each - descriptor is 16 bytes. - -RxIntDelay ----------- -:Valid Range: 0-65535 (0=off) -:Default Value: 72 - - This value delays the generation of receive interrupts in units of - 0.8192 microseconds. Receive interrupt reduction can improve CPU - efficiency if properly tuned for specific network traffic. Increasing - this value adds extra latency to frame reception and can end up - decreasing the throughput of TCP traffic. If the system is reporting - dropped receives, this value may be set too high, causing the driver to - run out of available receive descriptors. - -TxIntDelay ----------- -:Valid Range: 0-65535 (0=off) -:Default Value: 32 - - This value delays the generation of transmit interrupts in units of - 0.8192 microseconds. Transmit interrupt reduction can improve CPU - efficiency if properly tuned for specific network traffic. Increasing - this value adds extra latency to frame transmission and can end up - decreasing the throughput of TCP traffic. If this value is set too high, - it will cause the driver to run out of available transmit descriptors. - -XsumRX ------- -:Valid Range: 0-1 -:Default Value: 1 - - A value of '1' indicates that the driver should enable IP checksum - offload for received packets (both UDP and TCP) to the adapter hardware. - -RxFCHighThresh --------------- -:Valid Range: 1,536-262,136 (0x600 - 0x3FFF8, 8 byte granularity) -:Default Value: 196,608 (0x30000) - - Receive Flow control high threshold (when we send a pause frame) - -RxFCLowThresh -------------- -:Valid Range: 64-262,136 (0x40 - 0x3FFF8, 8 byte granularity) -:Default Value: 163,840 (0x28000) - - Receive Flow control low threshold (when we send a resume frame) - -FCReqTimeout ------------- -:Valid Range: 1-65535 -:Default Value: 65535 - - Flow control request timeout (how long to pause the link partner's tx) - -IntDelayEnable --------------- -:Value Range: 0,1 -:Default Value: 1 - - Interrupt Delay, 0 disables transmit interrupt delay and 1 enables it. - - -Improving Performance -===================== - -With the 10 Gigabit server adapters, the default Linux configuration will -very likely limit the total available throughput artificially. There is a set -of configuration changes that, when applied together, will increase the ability -of Linux to transmit and receive data. The following enhancements were -originally acquired from settings published at http://www.spec.org/web99/ for -various submitted results using Linux. - -NOTE: - These changes are only suggestions, and serve as a starting point for - tuning your network performance. - -The changes are made in three major ways, listed in order of greatest effect: - -- Use ip link to modify the mtu (maximum transmission unit) and the txqueuelen - parameter. -- Use sysctl to modify /proc parameters (essentially kernel tuning) -- Use setpci to modify the MMRBC field in PCI-X configuration space to increase - transmit burst lengths on the bus. - -NOTE: - setpci modifies the adapter's configuration registers to allow it to read - up to 4k bytes at a time (for transmits). However, for some systems the - behavior after modifying this register may be undefined (possibly errors of - some kind). A power-cycle, hard reset or explicitly setting the e6 register - back to 22 (setpci -d 8086:1a48 e6.b=22) may be required to get back to a - stable configuration. - -- COPY these lines and paste them into ixgb_perf.sh: - -:: - - #!/bin/bash - echo "configuring network performance , edit this file to change the interface - or device ID of 10GbE card" - # set mmrbc to 4k reads, modify only Intel 10GbE device IDs - # replace 1a48 with appropriate 10GbE device's ID installed on the system, - # if needed. - setpci -d 8086:1a48 e6.b=2e - # set the MTU (max transmission unit) - it requires your switch and clients - # to change as well. - # set the txqueuelen - # your ixgb adapter should be loaded as eth1 for this to work, change if needed - ip li set dev eth1 mtu 9000 txqueuelen 1000 up - # call the sysctl utility to modify /proc/sys entries - sysctl -p ./sysctl_ixgb.conf - -- COPY these lines and paste them into sysctl_ixgb.conf: - -:: - - # some of the defaults may be different for your kernel - # call this file with sysctl -p <this file> - # these are just suggested values that worked well to increase throughput in - # several network benchmark tests, your mileage may vary - - ### IPV4 specific settings - # turn TCP timestamp support off, default 1, reduces CPU use - net.ipv4.tcp_timestamps = 0 - # turn SACK support off, default on - # on systems with a VERY fast bus -> memory interface this is the big gainer - net.ipv4.tcp_sack = 0 - # set min/default/max TCP read buffer, default 4096 87380 174760 - net.ipv4.tcp_rmem = 10000000 10000000 10000000 - # set min/pressure/max TCP write buffer, default 4096 16384 131072 - net.ipv4.tcp_wmem = 10000000 10000000 10000000 - # set min/pressure/max TCP buffer space, default 31744 32256 32768 - net.ipv4.tcp_mem = 10000000 10000000 10000000 - - ### CORE settings (mostly for socket and UDP effect) - # set maximum receive socket buffer size, default 131071 - net.core.rmem_max = 524287 - # set maximum send socket buffer size, default 131071 - net.core.wmem_max = 524287 - # set default receive socket buffer size, default 65535 - net.core.rmem_default = 524287 - # set default send socket buffer size, default 65535 - net.core.wmem_default = 524287 - # set maximum amount of option memory buffers, default 10240 - net.core.optmem_max = 524287 - # set number of unprocessed input packets before kernel starts dropping them; default 300 - net.core.netdev_max_backlog = 300000 - -Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface -your ixgb driver is using and/or replace '1a48' with appropriate 10GbE device's -ID installed on the system. - -NOTE: - Unless these scripts are added to the boot process, these changes will - only last only until the next system reboot. - - -Resolving Slow UDP Traffic --------------------------- -If your server does not seem to be able to receive UDP traffic as fast as it -can receive TCP traffic, it could be because Linux, by default, does not set -the network stack buffers as large as they need to be to support high UDP -transfer rates. One way to alleviate this problem is to allow more memory to -be used by the IP stack to store incoming data. - -For instance, use the commands:: - - sysctl -w net.core.rmem_max=262143 - -and:: - - sysctl -w net.core.rmem_default=262143 - -to increase the read buffer memory max and default to 262143 (256k - 1) from -defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables -will increase the amount of memory used by the network stack for receives, and -can be increased significantly more if necessary for your application. - - -Additional Configurations -========================= - -Configuring the Driver on Different Distributions -------------------------------------------------- -Configuring a network driver to load properly when the system is started is -distribution dependent. Typically, the configuration process involves adding -an alias line to /etc/modprobe.conf as well as editing other system startup -scripts and/or configuration files. Many popular Linux distributions ship -with tools to make these changes for you. To learn the proper way to -configure a network device for your system, refer to your distribution -documentation. If during this process you are asked for the driver or module -name, the name for the Linux Base Driver for the Intel 10GbE Family of -Adapters is ixgb. - -Viewing Link Messages ---------------------- -Link messages will not be displayed to the console if the distribution is -restricting system messages. In order to see network driver link messages on -your console, set dmesg to eight by entering the following:: - - dmesg -n 8 - -NOTE: This setting is not saved across reboots. - -Jumbo Frames ------------- -The driver supports Jumbo Frames for all adapters. Jumbo Frames support is -enabled by changing the MTU to a value larger than the default of 1500. -The maximum value for the MTU is 16114. Use the ip command to -increase the MTU size. For example:: - - ip li set dev ethx mtu 9000 - -The maximum MTU setting for Jumbo Frames is 16114. This value coincides -with the maximum Jumbo Frames size of 16128. - -Ethtool -------- -The driver utilizes the ethtool interface for driver configuration and -diagnostics, as well as displaying statistical information. The ethtool -version 1.6 or later is required for this functionality. - -The latest release of ethtool can be found from -https://www.kernel.org/pub/software/network/ethtool/ - -NOTE: - The ethtool version 1.6 only supports a limited set of ethtool options. - Support for a more complete ethtool feature set can be enabled by - upgrading to the latest version. - -NAPI ----- -NAPI (Rx polling mode) is supported in the ixgb driver. - -See https://wiki.linuxfoundation.org/networking/napi for more information on -NAPI. - - -Known Issues/Troubleshooting -============================ - -NOTE: - After installing the driver, if your Intel Network Connection is not - working, verify in the "In This Release" section of the readme that you have - installed the correct driver. - -Cable Interoperability Issue with Fujitsu XENPAK Module in SmartBits Chassis ----------------------------------------------------------------------------- -Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 -Server adapter is connected to a Fujitsu XENPAK CX4 module in a SmartBits -chassis using 15 m/24AWG cable assemblies manufactured by Fujitsu or Leoni. -The CRC errors may be received either by the Intel(R) PRO/10GbE CX4 -Server adapter or the SmartBits. If this situation occurs using a different -cable assembly may resolve the issue. - -Cable Interoperability Issues with HP Procurve 3400cl Switch Port ------------------------------------------------------------------ -Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 Server -adapter is connected to an HP Procurve 3400cl switch port using short cables -(1 m or shorter). If this situation occurs, using a longer cable may resolve -the issue. - -Excessive CRC errors may be observed using Fujitsu 24AWG cable assemblies that -Are 10 m or longer or where using a Leoni 15 m/24AWG cable assembly. The CRC -errors may be received either by the CX4 Server adapter or at the switch. If -this situation occurs, using a different cable assembly may resolve the issue. - -Jumbo Frames System Requirement -------------------------------- -Memory allocation failures have been observed on Linux systems with 64 MB -of RAM or less that are running Jumbo Frames. If you are using Jumbo -Frames, your system may require more than the advertised minimum -requirement of 64 MB of system memory. - -Performance Degradation with Jumbo Frames ------------------------------------------ -Degradation in throughput performance may be observed in some Jumbo frames -environments. If this is observed, increasing the application's socket buffer -size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help. -See the specific application manual and /usr/src/linux*/Documentation/ -networking/ip-sysctl.txt for more details. - -Allocating Rx Buffers when Using Jumbo Frames ---------------------------------------------- -Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if -the available memory is heavily fragmented. This issue may be seen with PCI-X -adapters or with packet split disabled. This can be reduced or eliminated -by changing the amount of available memory for receive buffer allocation, by -increasing /proc/sys/vm/min_free_kbytes. - -Multiple Interfaces on Same Ethernet Broadcast Network ------------------------------------------------------- -Due to the default ARP behavior on Linux, it is not possible to have -one system on two IP networks in the same Ethernet broadcast domain -(non-partitioned switch) behave as expected. All Ethernet interfaces -will respond to IP traffic for any IP address assigned to the system. -This results in unbalanced receive traffic. - -If you have multiple interfaces in a server, do either of the following: - - - Turn on ARP filtering by entering:: - - echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter - - - Install the interfaces in separate broadcast domains - either in - different switches or in a switch partitioned to VLANs. - -UDP Stress Test Dropped Packet Issue --------------------------------------- -Under small packets UDP stress test with 10GbE driver, the Linux system -may drop UDP packets due to the fullness of socket buffers. You may want -to change the driver's Flow Control variables to the minimum value for -controlling packet reception. - -Tx Hangs Possible Under Stress ------------------------------- -Under stress conditions, if TX hangs occur, turning off TSO -"ethtool -K eth0 tso off" may resolve the problem. - - -Support -======= -For general information, go to the Intel support website at: - -https://www.intel.com/support/ - -or the Intel Wired Networking project hosted by Sourceforge at: - -https://sourceforge.net/projects/e1000 - -If an issue is identified with the released source code on a supported kernel -with a supported adapter, email the specific information related to the issue -to e1000-devel@lists.sf.net diff --git a/Documentation/networking/device_drivers/mellanox/mlx5.rst b/Documentation/networking/device_drivers/mellanox/mlx5.rst deleted file mode 100644 index f575a49790e8..000000000000 --- a/Documentation/networking/device_drivers/mellanox/mlx5.rst +++ /dev/null @@ -1,321 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB - -================================================= -Mellanox ConnectX(R) mlx5 core VPI Network Driver -================================================= - -Copyright (c) 2019, Mellanox Technologies LTD. - -Contents -======== - -- `Enabling the driver and kconfig options`_ -- `Devlink info`_ -- `Devlink parameters`_ -- `Devlink health reporters`_ -- `mlx5 tracepoints`_ - -Enabling the driver and kconfig options -================================================ - -| mlx5 core is modular and most of the major mlx5 core driver features can be selected (compiled in/out) -| at build time via kernel Kconfig flags. -| Basic features, ethernet net device rx/tx offloads and XDP, are available with the most basic flags -| CONFIG_MLX5_CORE=y/m and CONFIG_MLX5_CORE_EN=y. -| For the list of advanced features please see below. - -**CONFIG_MLX5_CORE=(y/m/n)** (module mlx5_core.ko) - -| The driver can be enabled by choosing CONFIG_MLX5_CORE=y/m in kernel config. -| This will provide mlx5 core driver for mlx5 ulps to interface with (mlx5e, mlx5_ib). - - -**CONFIG_MLX5_CORE_EN=(y/n)** - -| Choosing this option will allow basic ethernet netdevice support with all of the standard rx/tx offloads. -| mlx5e is the mlx5 ulp driver which provides netdevice kernel interface, when chosen, mlx5e will be -| built-in into mlx5_core.ko. - - -**CONFIG_MLX5_EN_ARFS=(y/n)** - -| Enables Hardware-accelerated receive flow steering (arfs) support, and ntuple filtering. -| https://community.mellanox.com/s/article/howto-configure-arfs-on-connectx-4 - - -**CONFIG_MLX5_EN_RXNFC=(y/n)** - -| Enables ethtool receive network flow classification, which allows user defined -| flow rules to direct traffic into arbitrary rx queue via ethtool set/get_rxnfc API. - - -**CONFIG_MLX5_CORE_EN_DCB=(y/n)**: - -| Enables `Data Center Bridging (DCB) Support <https://community.mellanox.com/s/article/howto-auto-config-pfc-and-ets-on-connectx-4-via-lldp-dcbx>`_. - - -**CONFIG_MLX5_MPFS=(y/n)** - -| Ethernet Multi-Physical Function Switch (MPFS) support in ConnectX NIC. -| MPFs is required for when `Multi-Host <http://www.mellanox.com/page/multihost>`_ configuration is enabled to allow passing -| user configured unicast MAC addresses to the requesting PF. - - -**CONFIG_MLX5_ESWITCH=(y/n)** - -| Ethernet SRIOV E-Switch support in ConnectX NIC. E-Switch provides internal SRIOV packet steering -| and switching for the enabled VFs and PF in two available modes: -| 1) `Legacy SRIOV mode (L2 mac vlan steering based) <https://community.mellanox.com/s/article/howto-configure-sr-iov-for-connectx-4-connectx-5-with-kvm--ethernet-x>`_. -| 2) `Switchdev mode (eswitch offloads) <https://www.mellanox.com/related-docs/prod_software/ASAP2_Hardware_Offloading_for_vSwitches_User_Manual_v4.4.pdf>`_. - - -**CONFIG_MLX5_CORE_IPOIB=(y/n)** - -| IPoIB offloads & acceleration support. -| Requires CONFIG_MLX5_CORE_EN to provide an accelerated interface for the rdma -| IPoIB ulp netdevice. - - -**CONFIG_MLX5_FPGA=(y/n)** - -| Build support for the Innova family of network cards by Mellanox Technologies. -| Innova network cards are comprised of a ConnectX chip and an FPGA chip on one board. -| If you select this option, the mlx5_core driver will include the Innova FPGA core and allow -| building sandbox-specific client drivers. - - -**CONFIG_MLX5_EN_IPSEC=(y/n)** - -| Enables `IPSec XFRM cryptography-offload accelaration <http://www.mellanox.com/related-docs/prod_software/Mellanox_Innova_IPsec_Ethernet_Adapter_Card_User_Manual.pdf>`_. - -**CONFIG_MLX5_EN_TLS=(y/n)** - -| TLS cryptography-offload accelaration. - - -**CONFIG_MLX5_INFINIBAND=(y/n/m)** (module mlx5_ib.ko) - -| Provides low-level InfiniBand/RDMA and `RoCE <https://community.mellanox.com/s/article/recommended-network-configuration-examples-for-roce-deployment>`_ support. - - -**External options** ( Choose if the corresponding mlx5 feature is required ) - -- CONFIG_PTP_1588_CLOCK: When chosen, mlx5 ptp support will be enabled -- CONFIG_VXLAN: When chosen, mlx5 vxaln support will be enabled. -- CONFIG_MLXFW: When chosen, mlx5 firmware flashing support will be enabled (via devlink and ethtool). - -Devlink info -============ - -The devlink info reports the running and stored firmware versions on device. -It also prints the device PSID which represents the HCA board type ID. - -User command example:: - - $ devlink dev info pci/0000:00:06.0 - pci/0000:00:06.0: - driver mlx5_core - versions: - fixed: - fw.psid MT_0000000009 - running: - fw.version 16.26.0100 - stored: - fw.version 16.26.0100 - -Devlink parameters -================== - -flow_steering_mode: Device flow steering mode ---------------------------------------------- -The flow steering mode parameter controls the flow steering mode of the driver. -Two modes are supported: -1. 'dmfs' - Device managed flow steering. -2. 'smfs - Software/Driver managed flow steering. - -In DMFS mode, the HW steering entities are created and managed through the -Firmware. -In SMFS mode, the HW steering entities are created and managed though by -the driver directly into Hardware without firmware intervention. - -SMFS mode is faster and provides better rule inserstion rate compared to default DMFS mode. - -User command examples: - -- Set SMFS flow steering mode:: - - $ devlink dev param set pci/0000:06:00.0 name flow_steering_mode value "smfs" cmode runtime - -- Read device flow steering mode:: - - $ devlink dev param show pci/0000:06:00.0 name flow_steering_mode - pci/0000:06:00.0: - name flow_steering_mode type driver-specific - values: - cmode runtime value smfs - -enable_roce: RoCE enablement state ----------------------------------- -RoCE enablement state controls driver support for RoCE traffic. -When RoCE is disabled, there is no gid table, only raw ethernet QPs are supported and traffic on the well known UDP RoCE port is handled as raw ethernet traffic. - -To change RoCE enablement state a user must change the driverinit cmode value and run devlink reload. - -User command examples: - -- Disable RoCE:: - - $ devlink dev param set pci/0000:06:00.0 name enable_roce value false cmode driverinit - $ devlink dev reload pci/0000:06:00.0 - -- Read RoCE enablement state:: - - $ devlink dev param show pci/0000:06:00.0 name enable_roce - pci/0000:06:00.0: - name enable_roce type generic - values: - cmode driverinit value true - -Devlink health reporters -======================== - -tx reporter ------------ -The tx reporter is responsible for reporting and recovering of the following two error scenarios: - -- TX timeout - Report on kernel tx timeout detection. - Recover by searching lost interrupts. -- TX error completion - Report on error tx completion. - Recover by flushing the TX queue and reset it. - -TX reporter also support on demand diagnose callback, on which it provides -real time information of its send queues status. - -User commands examples: - -- Diagnose send queues status:: - - $ devlink health diagnose pci/0000:82:00.0 reporter tx - -NOTE: This command has valid output only when interface is up, otherwise the command has empty output. - -- Show number of tx errors indicated, number of recover flows ended successfully, - is autorecover enabled and graceful period from last recover:: - - $ devlink health show pci/0000:82:00.0 reporter tx - -rx reporter ------------ -The rx reporter is responsible for reporting and recovering of the following two error scenarios: - -- RX queues initialization (population) timeout - RX queues descriptors population on ring initialization is done in - napi context via triggering an irq, in case of a failure to get - the minimum amount of descriptors, a timeout would occur and it - could be recoverable by polling the EQ (Event Queue). -- RX completions with errors (reported by HW on interrupt context) - Report on rx completion error. - Recover (if needed) by flushing the related queue and reset it. - -RX reporter also supports on demand diagnose callback, on which it -provides real time information of its receive queues status. - -- Diagnose rx queues status, and corresponding completion queue:: - - $ devlink health diagnose pci/0000:82:00.0 reporter rx - -NOTE: This command has valid output only when interface is up, otherwise the command has empty output. - -- Show number of rx errors indicated, number of recover flows ended successfully, - is autorecover enabled and graceful period from last recover:: - - $ devlink health show pci/0000:82:00.0 reporter rx - -fw reporter ------------ -The fw reporter implements diagnose and dump callbacks. -It follows symptoms of fw error such as fw syndrome by triggering -fw core dump and storing it into the dump buffer. -The fw reporter diagnose command can be triggered any time by the user to check -current fw status. - -User commands examples: - -- Check fw heath status:: - - $ devlink health diagnose pci/0000:82:00.0 reporter fw - -- Read FW core dump if already stored or trigger new one:: - - $ devlink health dump show pci/0000:82:00.0 reporter fw - -NOTE: This command can run only on the PF which has fw tracer ownership, -running it on other PF or any VF will return "Operation not permitted". - -fw fatal reporter ------------------ -The fw fatal reporter implements dump and recover callbacks. -It follows fatal errors indications by CR-space dump and recover flow. -The CR-space dump uses vsc interface which is valid even if the FW command -interface is not functional, which is the case in most FW fatal errors. -The recover function runs recover flow which reloads the driver and triggers fw -reset if needed. - -User commands examples: - -- Run fw recover flow manually:: - - $ devlink health recover pci/0000:82:00.0 reporter fw_fatal - -- Read FW CR-space dump if already strored or trigger new one:: - - $ devlink health dump show pci/0000:82:00.1 reporter fw_fatal - -NOTE: This command can run only on PF. - -mlx5 tracepoints -================ - -mlx5 driver provides internal trace points for tracking and debugging using -kernel tracepoints interfaces (refer to Documentation/trace/ftrace.rst). - -For the list of support mlx5 events check /sys/kernel/debug/tracing/events/mlx5/ - -tc and eswitch offloads tracepoints: - -- mlx5e_configure_flower: trace flower filter actions and cookies offloaded to mlx5:: - - $ echo mlx5:mlx5e_configure_flower >> /sys/kernel/debug/tracing/set_event - $ cat /sys/kernel/debug/tracing/trace - ... - tc-6535 [019] ...1 2672.404466: mlx5e_configure_flower: cookie=0000000067874a55 actions= REDIRECT - -- mlx5e_delete_flower: trace flower filter actions and cookies deleted from mlx5:: - - $ echo mlx5:mlx5e_delete_flower >> /sys/kernel/debug/tracing/set_event - $ cat /sys/kernel/debug/tracing/trace - ... - tc-6569 [010] .N.1 2686.379075: mlx5e_delete_flower: cookie=0000000067874a55 actions= NULL - -- mlx5e_stats_flower: trace flower stats request:: - - $ echo mlx5:mlx5e_stats_flower >> /sys/kernel/debug/tracing/set_event - $ cat /sys/kernel/debug/tracing/trace - ... - tc-6546 [010] ...1 2679.704889: mlx5e_stats_flower: cookie=0000000060eb3d6a bytes=0 packets=0 lastused=4295560217 - -- mlx5e_tc_update_neigh_used_value: trace tunnel rule neigh update value offloaded to mlx5:: - - $ echo mlx5:mlx5e_tc_update_neigh_used_value >> /sys/kernel/debug/tracing/set_event - $ cat /sys/kernel/debug/tracing/trace - ... - kworker/u48:4-8806 [009] ...1 55117.882428: mlx5e_tc_update_neigh_used_value: netdev: ens1f0 IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_used=1 - -- mlx5e_rep_neigh_update: trace neigh update tasks scheduled due to neigh state change events:: - - $ echo mlx5:mlx5e_rep_neigh_update >> /sys/kernel/debug/tracing/set_event - $ cat /sys/kernel/debug/tracing/trace - ... - kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1 diff --git a/Documentation/networking/device_drivers/neterion/s2io.txt b/Documentation/networking/device_drivers/neterion/s2io.txt deleted file mode 100644 index 0362a42f7cf4..000000000000 --- a/Documentation/networking/device_drivers/neterion/s2io.txt +++ /dev/null @@ -1,141 +0,0 @@ -Release notes for Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver. - -Contents -======= -- 1. Introduction -- 2. Identifying the adapter/interface -- 3. Features supported -- 4. Command line parameters -- 5. Performance suggestions -- 6. Available Downloads - - -1. Introduction: -This Linux driver supports Neterion's Xframe I PCI-X 1.0 and -Xframe II PCI-X 2.0 adapters. It supports several features -such as jumbo frames, MSI/MSI-X, checksum offloads, TSO, UFO and so on. -See below for complete list of features. -All features are supported for both IPv4 and IPv6. - -2. Identifying the adapter/interface: -a. Insert the adapter(s) in your system. -b. Build and load driver -# insmod s2io.ko -c. View log messages -# dmesg | tail -40 -You will see messages similar to: -eth3: Neterion Xframe I 10GbE adapter (rev 3), Version 2.0.9.1, Intr type INTA -eth4: Neterion Xframe II 10GbE adapter (rev 2), Version 2.0.9.1, Intr type INTA -eth4: Device is on 64 bit 133MHz PCIX(M1) bus - -The above messages identify the adapter type(Xframe I/II), adapter revision, -driver version, interface name(eth3, eth4), Interrupt type(INTA, MSI, MSI-X). -In case of Xframe II, the PCI/PCI-X bus width and frequency are displayed -as well. - -To associate an interface with a physical adapter use "ethtool -p <ethX>". -The corresponding adapter's LED will blink multiple times. - -3. Features supported: -a. Jumbo frames. Xframe I/II supports MTU up to 9600 bytes, -modifiable using ip command. - -b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit -and receive, TSO. - -c. Multi-buffer receive mode. Scattering of packet across multiple -buffers. Currently driver supports 2-buffer mode which yields -significant performance improvement on certain platforms(SGI Altix, -IBM xSeries). - -d. MSI/MSI-X. Can be enabled on platforms which support this feature -(IA64, Xeon) resulting in noticeable performance improvement(up to 7% -on certain platforms). - -e. Statistics. Comprehensive MAC-level and software statistics displayed -using "ethtool -S" option. - -f. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, -with multiple steering options. - -4. Command line parameters -a. tx_fifo_num -Number of transmit queues -Valid range: 1-8 -Default: 1 - -b. rx_ring_num -Number of receive rings -Valid range: 1-8 -Default: 1 - -c. tx_fifo_len -Size of each transmit queue -Valid range: Total length of all queues should not exceed 8192 -Default: 4096 - -d. rx_ring_sz -Size of each receive ring(in 4K blocks) -Valid range: Limited by memory on system -Default: 30 - -e. intr_type -Specifies interrupt type. Possible values 0(INTA), 2(MSI-X) -Valid values: 0, 2 -Default: 2 - -5. Performance suggestions -General: -a. Set MTU to maximum(9000 for switch setup, 9600 in back-to-back configuration) -b. Set TCP windows size to optimal value. -For instance, for MTU=1500 a value of 210K has been observed to result in -good performance. -# sysctl -w net.ipv4.tcp_rmem="210000 210000 210000" -# sysctl -w net.ipv4.tcp_wmem="210000 210000 210000" -For MTU=9000, TCP window size of 10 MB is recommended. -# sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000" -# sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000" - -Transmit performance: -a. By default, the driver respects BIOS settings for PCI bus parameters. -However, you may want to experiment with PCI bus parameters -max-split-transactions(MOST) and MMRBC (use setpci command). -A MOST value of 2 has been found optimal for Opterons and 3 for Itanium. -It could be different for your hardware. -Set MMRBC to 4K**. - -For example you can set -For opteron -#setpci -d 17d5:* 62=1d -For Itanium -#setpci -d 17d5:* 62=3d - -For detailed description of the PCI registers, please see Xframe User Guide. - -b. Ensure Transmit Checksum offload is enabled. Use ethtool to set/verify this -parameter. -c. Turn on TSO(using "ethtool -K") -# ethtool -K <ethX> tso on - -Receive performance: -a. By default, the driver respects BIOS settings for PCI bus parameters. -However, you may want to set PCI latency timer to 248. -#setpci -d 17d5:* LATENCY_TIMER=f8 -For detailed description of the PCI registers, please see Xframe User Guide. -b. Use 2-buffer mode. This results in large performance boost on -certain platforms(eg. SGI Altix, IBM xSeries). -c. Ensure Receive Checksum offload is enabled. Use "ethtool -K ethX" command to -set/verify this option. -d. Enable NAPI feature(in kernel configuration Device Drivers ---> Network -device support ---> Ethernet (10000 Mbit) ---> S2IO 10Gbe Xframe NIC) to -bring down CPU utilization. - -** For AMD opteron platforms with 8131 chipset, MMRBC=1 and MOST=1 are -recommended as safe parameters. -For more information, please review the AMD8131 errata at -http://vip.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/ -26310_AMD-8131_HyperTransport_PCI-X_Tunnel_Revision_Guide_rev_3_18.pdf - -6. Support -For further support please contact either your 10GbE Xframe NIC vendor (IBM, -HP, SGI etc.) diff --git a/Documentation/networking/device_drivers/neterion/vxge.txt b/Documentation/networking/device_drivers/neterion/vxge.txt deleted file mode 100644 index abfec245f97c..000000000000 --- a/Documentation/networking/device_drivers/neterion/vxge.txt +++ /dev/null @@ -1,93 +0,0 @@ -Neterion's (Formerly S2io) X3100 Series 10GbE PCIe Server Adapter Linux driver -============================================================================== - -Contents --------- - -1) Introduction -2) Features supported -3) Configurable driver parameters -4) Troubleshooting - -1) Introduction: ----------------- -This Linux driver supports all Neterion's X3100 series 10 GbE PCIe I/O -Virtualized Server adapters. -The X3100 series supports four modes of operation, configurable via -firmware - - Single function mode - Multi function mode - SRIOV mode - MRIOV mode -The functions share a 10GbE link and the pci-e bus, but hardly anything else -inside the ASIC. Features like independent hw reset, statistics, bandwidth/ -priority allocation and guarantees, GRO, TSO, interrupt moderation etc are -supported independently on each function. - -(See below for a complete list of features supported for both IPv4 and IPv6) - -2) Features supported: ----------------------- - -i) Single function mode (up to 17 queues) - -ii) Multi function mode (up to 17 functions) - -iii) PCI-SIG's I/O Virtualization - - Single Root mode: v1.0 (up to 17 functions) - - Multi-Root mode: v1.0 (up to 17 functions) - -iv) Jumbo frames - X3100 Series supports MTU up to 9600 bytes, modifiable using - ip command. - -v) Offloads supported: (Enabled by default) - Checksum offload (TCP/UDP/IP) on transmit and receive paths - TCP Segmentation Offload (TSO) on transmit path - Generic Receive Offload (GRO) on receive path - -vi) MSI-X: (Enabled by default) - Resulting in noticeable performance improvement (up to 7% on certain - platforms). - -vii) NAPI: (Enabled by default) - For better Rx interrupt moderation. - -viii)RTH (Receive Traffic Hash): (Enabled by default) - Receive side steering for better scaling. - -ix) Statistics - Comprehensive MAC-level and software statistics displayed using - "ethtool -S" option. - -x) Multiple hardware queues: (Enabled by default) - Up to 17 hardware based transmit and receive data channels, with - multiple steering options (transmit multiqueue enabled by default). - -3) Configurable driver parameters: ----------------------------------- - -i) max_config_dev - Specifies maximum device functions to be enabled. - Valid range: 1-8 - -ii) max_config_port - Specifies number of ports to be enabled. - Valid range: 1,2 - Default: 1 - -iii)max_config_vpath - Specifies maximum VPATH(s) configured for each device function. - Valid range: 1-17 - -iv) vlan_tag_strip - Enables/disables vlan tag stripping from all received tagged frames that - are not replicated at the internal L2 switch. - Valid range: 0,1 (disabled, enabled respectively) - Default: 1 - -v) addr_learn_en - Enable learning the mac address of the guest OS interface in - virtualization environment. - Valid range: 0,1 (disabled, enabled respectively) - Default: 0 diff --git a/Documentation/networking/device_drivers/pensando/ionic.rst b/Documentation/networking/device_drivers/pensando/ionic.rst deleted file mode 100644 index c17d680cf334..000000000000 --- a/Documentation/networking/device_drivers/pensando/ionic.rst +++ /dev/null @@ -1,45 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0+ - -======================================================== -Linux Driver for the Pensando(R) Ethernet adapter family -======================================================== - -Pensando Linux Ethernet driver. -Copyright(c) 2019 Pensando Systems, Inc - -Contents -======== - -- Identifying the Adapter -- Support - -Identifying the Adapter -======================= - -To find if one or more Pensando PCI Ethernet devices are installed on the -host, check for the PCI devices:: - - $ lspci -d 1dd8: - b5:00.0 Ethernet controller: Device 1dd8:1002 - b6:00.0 Ethernet controller: Device 1dd8:1002 - -If such devices are listed as above, then the ionic.ko driver should find -and configure them for use. There should be log entries in the kernel -messages such as these:: - - $ dmesg | grep ionic - ionic Pensando Ethernet NIC Driver, ver 0.15.0-k - ionic 0000:b5:00.0 enp181s0: renamed from eth0 - ionic 0000:b6:00.0 enp182s0: renamed from eth0 - -Support -======= -For general Linux networking support, please use the netdev mailing -list, which is monitored by Pensando personnel:: - - netdev@vger.kernel.org - -For more specific support needs, please use the Pensando driver support -email:: - - drivers@pensando.io diff --git a/Documentation/networking/device_drivers/qlogic/LICENSE.qla3xxx b/Documentation/networking/device_drivers/qlogic/LICENSE.qla3xxx deleted file mode 100644 index 2f2077e34d81..000000000000 --- a/Documentation/networking/device_drivers/qlogic/LICENSE.qla3xxx +++ /dev/null @@ -1,46 +0,0 @@ -Copyright (c) 2003-2006 QLogic Corporation -QLogic Linux Networking HBA Driver - -This program includes a device driver for Linux 2.6 that may be -distributed with QLogic hardware specific firmware binary file. -You may modify and redistribute the device driver code under the -GNU General Public License as published by the Free Software -Foundation (version 2 or a later version). - -You may redistribute the hardware specific firmware binary file -under the following terms: - - 1. Redistribution of source code (only if applicable), - must retain the above copyright notice, this list of - conditions and the following disclaimer. - - 2. Redistribution in binary form must reproduce the above - copyright notice, this list of conditions and the - following disclaimer in the documentation and/or other - materials provided with the distribution. - - 3. The name of QLogic Corporation may not be used to - endorse or promote products derived from this software - without specific prior written permission - -REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE, -THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY -EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A -PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR -BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, -EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED -TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON -ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, -OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE -POSSIBILITY OF SUCH DAMAGE. - -USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT -CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR -OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, -TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN -ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN -COMBINATION WITH THIS PROGRAM. - diff --git a/Documentation/networking/device_drivers/qlogic/LICENSE.qlcnic b/Documentation/networking/device_drivers/qlogic/LICENSE.qlcnic deleted file mode 100644 index 2ae3b64983ab..000000000000 --- a/Documentation/networking/device_drivers/qlogic/LICENSE.qlcnic +++ /dev/null @@ -1,288 +0,0 @@ -Copyright (c) 2009-2013 QLogic Corporation -QLogic Linux qlcnic NIC Driver - -You may modify and redistribute the device driver code under the -GNU General Public License (a copy of which is attached hereto as -Exhibit A) published by the Free Software Foundation (version 2). - - -EXHIBIT A - - GNU GENERAL PUBLIC LICENSE - Version 2, June 1991 - - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - Preamble - - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software--to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Lesser General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - - GNU GENERAL PUBLIC LICENSE - TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION - - 0. This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this General Public License. The "Program", below, -refers to any such program or work, and a "work based on the Program" -means either the Program or any derivative work under copyright law: -that is to say, a work containing the Program or a portion of it, -either verbatim or with modifications and/or translated into another -language. (Hereinafter, translation is included without limitation in -the term "modification".) Each licensee is addressed as "you". - -Activities other than copying, distribution and modification are not -covered by this License; they are outside its scope. The act of -running the Program is not restricted, and the output from the Program -is covered only if its contents constitute a work based on the -Program (independent of having been made by running the Program). -Whether that is true depends on what the Program does. - - 1. You may copy and distribute verbatim copies of the Program's -source code as you receive it, in any medium, provided that you -conspicuously and appropriately publish on each copy an appropriate -copyright notice and disclaimer of warranty; keep intact all the -notices that refer to this License and to the absence of any warranty; -and give any other recipients of the Program a copy of this License -along with the Program. - -You may charge a fee for the physical act of transferring a copy, and -you may at your option offer warranty protection in exchange for a fee. - - 2. You may modify your copy or copies of the Program or any portion -of it, thus forming a work based on the Program, and copy and -distribute such modifications or work under the terms of Section 1 -above, provided that you also meet all of these conditions: - - a) You must cause the modified files to carry prominent notices - stating that you changed the files and the date of any change. - - b) You must cause any work that you distribute or publish, that in - whole or in part contains or is derived from the Program or any - part thereof, to be licensed as a whole at no charge to all third - parties under the terms of this License. - - c) If the modified program normally reads commands interactively - when run, you must cause it, when started running for such - interactive use in the most ordinary way, to print or display an - announcement including an appropriate copyright notice and a - notice that there is no warranty (or else, saying that you provide - a warranty) and that users may redistribute the program under - these conditions, and telling the user how to view a copy of this - License. (Exception: if the Program itself is interactive but - does not normally print such an announcement, your work based on - the Program is not required to print an announcement.) - -These requirements apply to the modified work as a whole. If -identifiable sections of that work are not derived from the Program, -and can be reasonably considered independent and separate works in -themselves, then this License, and its terms, do not apply to those -sections when you distribute them as separate works. But when you -distribute the same sections as part of a whole which is a work based -on the Program, the distribution of the whole must be on the terms of -this License, whose permissions for other licensees extend to the -entire whole, and thus to each and every part regardless of who wrote it. - -Thus, it is not the intent of this section to claim rights or contest -your rights to work written entirely by you; rather, the intent is to -exercise the right to control the distribution of derivative or -collective works based on the Program. - -In addition, mere aggregation of another work not based on the Program -with the Program (or with a work based on the Program) on a volume of -a storage or distribution medium does not bring the other work under -the scope of this License. - - 3. You may copy and distribute the Program (or a work based on it, -under Section 2) in object code or executable form under the terms of -Sections 1 and 2 above provided that you also do one of the following: - - a) Accompany it with the complete corresponding machine-readable - source code, which must be distributed under the terms of Sections - 1 and 2 above on a medium customarily used for software interchange; or, - - b) Accompany it with a written offer, valid for at least three - years, to give any third party, for a charge no more than your - cost of physically performing source distribution, a complete - machine-readable copy of the corresponding source code, to be - distributed under the terms of Sections 1 and 2 above on a medium - customarily used for software interchange; or, - - c) Accompany it with the information you received as to the offer - to distribute corresponding source code. (This alternative is - allowed only for noncommercial distribution and only if you - received the program in object code or executable form with such - an offer, in accord with Subsection b above.) - -The source code for a work means the preferred form of the work for -making modifications to it. For an executable work, complete source -code means all the source code for all modules it contains, plus any -associated interface definition files, plus the scripts used to -control compilation and installation of the executable. However, as a -special exception, the source code distributed need not include -anything that is normally distributed (in either source or binary -form) with the major components (compiler, kernel, and so on) of the -operating system on which the executable runs, unless that component -itself accompanies the executable. - -If distribution of executable or object code is made by offering -access to copy from a designated place, then offering equivalent -access to copy the source code from the same place counts as -distribution of the source code, even though third parties are not -compelled to copy the source along with the object code. - - 4. You may not copy, modify, sublicense, or distribute the Program -except as expressly provided under this License. Any attempt -otherwise to copy, modify, sublicense or distribute the Program is -void, and will automatically terminate your rights under this License. -However, parties who have received copies, or rights, from you under -this License will not have their licenses terminated so long as such -parties remain in full compliance. - - 5. You are not required to accept this License, since you have not -signed it. However, nothing else grants you permission to modify or -distribute the Program or its derivative works. These actions are -prohibited by law if you do not accept this License. Therefore, by -modifying or distributing the Program (or any work based on the -Program), you indicate your acceptance of this License to do so, and -all its terms and conditions for copying, distributing or modifying -the Program or works based on it. - - 6. Each time you redistribute the Program (or any work based on the -Program), the recipient automatically receives a license from the -original licensor to copy, distribute or modify the Program subject to -these terms and conditions. You may not impose any further -restrictions on the recipients' exercise of the rights granted herein. -You are not responsible for enforcing compliance by third parties to -this License. - - 7. If, as a consequence of a court judgment or allegation of patent -infringement or for any other reason (not limited to patent issues), -conditions are imposed on you (whether by court order, agreement or -otherwise) that contradict the conditions of this License, they do not -excuse you from the conditions of this License. If you cannot -distribute so as to satisfy simultaneously your obligations under this -License and any other pertinent obligations, then as a consequence you -may not distribute the Program at all. For example, if a patent -license would not permit royalty-free redistribution of the Program by -all those who receive copies directly or indirectly through you, then -the only way you could satisfy both it and this License would be to -refrain entirely from distribution of the Program. - -If any portion of this section is held invalid or unenforceable under -any particular circumstance, the balance of the section is intended to -apply and the section as a whole is intended to apply in other -circumstances. - -It is not the purpose of this section to induce you to infringe any -patents or other property right claims or to contest validity of any -such claims; this section has the sole purpose of protecting the -integrity of the free software distribution system, which is -implemented by public license practices. Many people have made -generous contributions to the wide range of software distributed -through that system in reliance on consistent application of that -system; it is up to the author/donor to decide if he or she is willing -to distribute software through any other system and a licensee cannot -impose that choice. - -This section is intended to make thoroughly clear what is believed to -be a consequence of the rest of this License. - - 8. If the distribution and/or use of the Program is restricted in -certain countries either by patents or by copyrighted interfaces, the -original copyright holder who places the Program under this License -may add an explicit geographical distribution limitation excluding -those countries, so that distribution is permitted only in or among -countries not thus excluded. In such case, this License incorporates -the limitation as if written in the body of this License. - - 9. The Free Software Foundation may publish revised and/or new versions -of the General Public License from time to time. Such new versions will -be similar in spirit to the present version, but may differ in detail to -address new problems or concerns. - -Each version is given a distinguishing version number. If the Program -specifies a version number of this License which applies to it and "any -later version", you have the option of following the terms and conditions -either of that version or of any later version published by the Free -Software Foundation. If the Program does not specify a version number of -this License, you may choose any version ever published by the Free Software -Foundation. - - 10. If you wish to incorporate parts of the Program into other free -programs whose distribution conditions are different, write to the author -to ask for permission. For software which is copyrighted by the Free -Software Foundation, write to the Free Software Foundation; we sometimes -make exceptions for this. Our decision will be guided by the two goals -of preserving the free status of all derivatives of our free software and -of promoting the sharing and reuse of software generally. - - NO WARRANTY - - 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY -FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN -OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES -PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED -OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS -TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE -PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, -REPAIR OR CORRECTION. - - 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING -WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR -REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, -INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING -OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED -TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY -YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER -PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE -POSSIBILITY OF SUCH DAMAGES. diff --git a/Documentation/networking/device_drivers/qlogic/LICENSE.qlge b/Documentation/networking/device_drivers/qlogic/LICENSE.qlge deleted file mode 100644 index ce64e4d15b21..000000000000 --- a/Documentation/networking/device_drivers/qlogic/LICENSE.qlge +++ /dev/null @@ -1,288 +0,0 @@ -Copyright (c) 2003-2011 QLogic Corporation -QLogic Linux qlge NIC Driver - -You may modify and redistribute the device driver code under the -GNU General Public License (a copy of which is attached hereto as -Exhibit A) published by the Free Software Foundation (version 2). - - -EXHIBIT A - - GNU GENERAL PUBLIC LICENSE - Version 2, June 1991 - - Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA - Everyone is permitted to copy and distribute verbatim copies - of this license document, but changing it is not allowed. - - Preamble - - The licenses for most software are designed to take away your -freedom to share and change it. By contrast, the GNU General Public -License is intended to guarantee your freedom to share and change free -software--to make sure the software is free for all its users. This -General Public License applies to most of the Free Software -Foundation's software and to any other program whose authors commit to -using it. (Some other Free Software Foundation software is covered by -the GNU Lesser General Public License instead.) You can apply it to -your programs, too. - - When we speak of free software, we are referring to freedom, not -price. Our General Public Licenses are designed to make sure that you -have the freedom to distribute copies of free software (and charge for -this service if you wish), that you receive source code or can get it -if you want it, that you can change the software or use pieces of it -in new free programs; and that you know you can do these things. - - To protect your rights, we need to make restrictions that forbid -anyone to deny you these rights or to ask you to surrender the rights. -These restrictions translate to certain responsibilities for you if you -distribute copies of the software, or if you modify it. - - For example, if you distribute copies of such a program, whether -gratis or for a fee, you must give the recipients all the rights that -you have. You must make sure that they, too, receive or can get the -source code. And you must show them these terms so they know their -rights. - - We protect your rights with two steps: (1) copyright the software, and -(2) offer you this license which gives you legal permission to copy, -distribute and/or modify the software. - - Also, for each author's protection and ours, we want to make certain -that everyone understands that there is no warranty for this free -software. If the software is modified by someone else and passed on, we -want its recipients to know that what they have is not the original, so -that any problems introduced by others will not reflect on the original -authors' reputations. - - Finally, any free program is threatened constantly by software -patents. We wish to avoid the danger that redistributors of a free -program will individually obtain patent licenses, in effect making the -program proprietary. To prevent this, we have made it clear that any -patent must be licensed for everyone's free use or not licensed at all. - - The precise terms and conditions for copying, distribution and -modification follow. - - GNU GENERAL PUBLIC LICENSE - TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION - - 0. This License applies to any program or other work which contains -a notice placed by the copyright holder saying it may be distributed -under the terms of this General Public License. The "Program", below, -refers to any such program or work, and a "work based on the Program" -means either the Program or any derivative work under copyright law: -that is to say, a work containing the Program or a portion of it, -either verbatim or with modifications and/or translated into another -language. (Hereinafter, translation is included without limitation in -the term "modification".) Each licensee is addressed as "you". - -Activities other than copying, distribution and modification are not -covered by this License; they are outside its scope. The act of -running the Program is not restricted, and the output from the Program -is covered only if its contents constitute a work based on the -Program (independent of having been made by running the Program). -Whether that is true depends on what the Program does. - - 1. You may copy and distribute verbatim copies of the Program's -source code as you receive it, in any medium, provided that you -conspicuously and appropriately publish on each copy an appropriate -copyright notice and disclaimer of warranty; keep intact all the -notices that refer to this License and to the absence of any warranty; -and give any other recipients of the Program a copy of this License -along with the Program. - -You may charge a fee for the physical act of transferring a copy, and -you may at your option offer warranty protection in exchange for a fee. - - 2. You may modify your copy or copies of the Program or any portion -of it, thus forming a work based on the Program, and copy and -distribute such modifications or work under the terms of Section 1 -above, provided that you also meet all of these conditions: - - a) You must cause the modified files to carry prominent notices - stating that you changed the files and the date of any change. - - b) You must cause any work that you distribute or publish, that in - whole or in part contains or is derived from the Program or any - part thereof, to be licensed as a whole at no charge to all third - parties under the terms of this License. - - c) If the modified program normally reads commands interactively - when run, you must cause it, when started running for such - interactive use in the most ordinary way, to print or display an - announcement including an appropriate copyright notice and a - notice that there is no warranty (or else, saying that you provide - a warranty) and that users may redistribute the program under - these conditions, and telling the user how to view a copy of this - License. (Exception: if the Program itself is interactive but - does not normally print such an announcement, your work based on - the Program is not required to print an announcement.) - -These requirements apply to the modified work as a whole. If -identifiable sections of that work are not derived from the Program, -and can be reasonably considered independent and separate works in -themselves, then this License, and its terms, do not apply to those -sections when you distribute them as separate works. But when you -distribute the same sections as part of a whole which is a work based -on the Program, the distribution of the whole must be on the terms of -this License, whose permissions for other licensees extend to the -entire whole, and thus to each and every part regardless of who wrote it. - -Thus, it is not the intent of this section to claim rights or contest -your rights to work written entirely by you; rather, the intent is to -exercise the right to control the distribution of derivative or -collective works based on the Program. - -In addition, mere aggregation of another work not based on the Program -with the Program (or with a work based on the Program) on a volume of -a storage or distribution medium does not bring the other work under -the scope of this License. - - 3. You may copy and distribute the Program (or a work based on it, -under Section 2) in object code or executable form under the terms of -Sections 1 and 2 above provided that you also do one of the following: - - a) Accompany it with the complete corresponding machine-readable - source code, which must be distributed under the terms of Sections - 1 and 2 above on a medium customarily used for software interchange; or, - - b) Accompany it with a written offer, valid for at least three - years, to give any third party, for a charge no more than your - cost of physically performing source distribution, a complete - machine-readable copy of the corresponding source code, to be - distributed under the terms of Sections 1 and 2 above on a medium - customarily used for software interchange; or, - - c) Accompany it with the information you received as to the offer - to distribute corresponding source code. (This alternative is - allowed only for noncommercial distribution and only if you - received the program in object code or executable form with such - an offer, in accord with Subsection b above.) - -The source code for a work means the preferred form of the work for -making modifications to it. For an executable work, complete source -code means all the source code for all modules it contains, plus any -associated interface definition files, plus the scripts used to -control compilation and installation of the executable. However, as a -special exception, the source code distributed need not include -anything that is normally distributed (in either source or binary -form) with the major components (compiler, kernel, and so on) of the -operating system on which the executable runs, unless that component -itself accompanies the executable. - -If distribution of executable or object code is made by offering -access to copy from a designated place, then offering equivalent -access to copy the source code from the same place counts as -distribution of the source code, even though third parties are not -compelled to copy the source along with the object code. - - 4. You may not copy, modify, sublicense, or distribute the Program -except as expressly provided under this License. Any attempt -otherwise to copy, modify, sublicense or distribute the Program is -void, and will automatically terminate your rights under this License. -However, parties who have received copies, or rights, from you under -this License will not have their licenses terminated so long as such -parties remain in full compliance. - - 5. You are not required to accept this License, since you have not -signed it. However, nothing else grants you permission to modify or -distribute the Program or its derivative works. These actions are -prohibited by law if you do not accept this License. Therefore, by -modifying or distributing the Program (or any work based on the -Program), you indicate your acceptance of this License to do so, and -all its terms and conditions for copying, distributing or modifying -the Program or works based on it. - - 6. Each time you redistribute the Program (or any work based on the -Program), the recipient automatically receives a license from the -original licensor to copy, distribute or modify the Program subject to -these terms and conditions. You may not impose any further -restrictions on the recipients' exercise of the rights granted herein. -You are not responsible for enforcing compliance by third parties to -this License. - - 7. If, as a consequence of a court judgment or allegation of patent -infringement or for any other reason (not limited to patent issues), -conditions are imposed on you (whether by court order, agreement or -otherwise) that contradict the conditions of this License, they do not -excuse you from the conditions of this License. If you cannot -distribute so as to satisfy simultaneously your obligations under this -License and any other pertinent obligations, then as a consequence you -may not distribute the Program at all. For example, if a patent -license would not permit royalty-free redistribution of the Program by -all those who receive copies directly or indirectly through you, then -the only way you could satisfy both it and this License would be to -refrain entirely from distribution of the Program. - -If any portion of this section is held invalid or unenforceable under -any particular circumstance, the balance of the section is intended to -apply and the section as a whole is intended to apply in other -circumstances. - -It is not the purpose of this section to induce you to infringe any -patents or other property right claims or to contest validity of any -such claims; this section has the sole purpose of protecting the -integrity of the free software distribution system, which is -implemented by public license practices. Many people have made -generous contributions to the wide range of software distributed -through that system in reliance on consistent application of that -system; it is up to the author/donor to decide if he or she is willing -to distribute software through any other system and a licensee cannot -impose that choice. - -This section is intended to make thoroughly clear what is believed to -be a consequence of the rest of this License. - - 8. If the distribution and/or use of the Program is restricted in -certain countries either by patents or by copyrighted interfaces, the -original copyright holder who places the Program under this License -may add an explicit geographical distribution limitation excluding -those countries, so that distribution is permitted only in or among -countries not thus excluded. In such case, this License incorporates -the limitation as if written in the body of this License. - - 9. The Free Software Foundation may publish revised and/or new versions -of the General Public License from time to time. Such new versions will -be similar in spirit to the present version, but may differ in detail to -address new problems or concerns. - -Each version is given a distinguishing version number. If the Program -specifies a version number of this License which applies to it and "any -later version", you have the option of following the terms and conditions -either of that version or of any later version published by the Free -Software Foundation. If the Program does not specify a version number of -this License, you may choose any version ever published by the Free Software -Foundation. - - 10. If you wish to incorporate parts of the Program into other free -programs whose distribution conditions are different, write to the author -to ask for permission. For software which is copyrighted by the Free -Software Foundation, write to the Free Software Foundation; we sometimes -make exceptions for this. Our decision will be guided by the two goals -of preserving the free status of all derivatives of our free software and -of promoting the sharing and reuse of software generally. - - NO WARRANTY - - 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY -FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN -OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES -PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED -OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF -MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS -TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE -PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, -REPAIR OR CORRECTION. - - 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING -WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR -REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, -INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING -OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED -TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY -YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER -PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE -POSSIBILITY OF SUCH DAMAGES. diff --git a/Documentation/networking/device_drivers/qualcomm/rmnet.txt b/Documentation/networking/device_drivers/qualcomm/rmnet.txt deleted file mode 100644 index 6b341eaf2062..000000000000 --- a/Documentation/networking/device_drivers/qualcomm/rmnet.txt +++ /dev/null @@ -1,82 +0,0 @@ -1. Introduction - -rmnet driver is used for supporting the Multiplexing and aggregation -Protocol (MAP). This protocol is used by all recent chipsets using Qualcomm -Technologies, Inc. modems. - -This driver can be used to register onto any physical network device in -IP mode. Physical transports include USB, HSIC, PCIe and IP accelerator. - -Multiplexing allows for creation of logical netdevices (rmnet devices) to -handle multiple private data networks (PDN) like a default internet, tethering, -multimedia messaging service (MMS) or IP media subsystem (IMS). Hardware sends -packets with MAP headers to rmnet. Based on the multiplexer id, rmnet -routes to the appropriate PDN after removing the MAP header. - -Aggregation is required to achieve high data rates. This involves hardware -sending aggregated bunch of MAP frames. rmnet driver will de-aggregate -these MAP frames and send them to appropriate PDN's. - -2. Packet format - -a. MAP packet (data / control) - -MAP header has the same endianness of the IP packet. - -Packet format - - -Bit 0 1 2-7 8 - 15 16 - 31 -Function Command / Data Reserved Pad Multiplexer ID Payload length -Bit 32 - x -Function Raw Bytes - -Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command -or data packet. Control packet is used for transport level flow control. Data -packets are standard IP packets. - -Reserved bits are usually zeroed out and to be ignored by receiver. - -Padding is number of bytes to be added for 4 byte alignment if required by -hardware. - -Multiplexer ID is to indicate the PDN on which data has to be sent. - -Payload length includes the padding length but does not include MAP header -length. - -b. MAP packet (command specific) - -Bit 0 1 2-7 8 - 15 16 - 31 -Function Command Reserved Pad Multiplexer ID Payload length -Bit 32 - 39 40 - 45 46 - 47 48 - 63 -Function Command name Reserved Command Type Reserved -Bit 64 - 95 -Function Transaction ID -Bit 96 - 127 -Function Command data - -Command 1 indicates disabling flow while 2 is enabling flow - -Command types - -0 for MAP command request -1 is to acknowledge the receipt of a command -2 is for unsupported commands -3 is for error during processing of commands - -c. Aggregation - -Aggregation is multiple MAP packets (can be data or command) delivered to -rmnet in a single linear skb. rmnet will process the individual -packets and either ACK the MAP command or deliver the IP packet to the -network stack as needed - -MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding.... -MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad... - -3. Userspace configuration - -rmnet userspace configuration is done through netlink library librmnetctl -and command line utility rmnetcli. Utility is hosted in codeaurora forum git. -The driver uses rtnl_link_ops for communication. - -https://source.codeaurora.org/quic/la/platform/vendor/qcom-opensource/dataservices/tree/rmnetctl diff --git a/Documentation/networking/device_drivers/sb1000.txt b/Documentation/networking/device_drivers/sb1000.txt deleted file mode 100644 index f92c2aac56a9..000000000000 --- a/Documentation/networking/device_drivers/sb1000.txt +++ /dev/null @@ -1,207 +0,0 @@ -sb1000 is a module network device driver for the General Instrument (also known -as NextLevel) SURFboard1000 internal cable modem board. This is an ISA card -which is used by a number of cable TV companies to provide cable modem access. -It's a one-way downstream-only cable modem, meaning that your upstream net link -is provided by your regular phone modem. - -This driver was written by Franco Venturi <fventuri@mediaone.net>. He deserves -a great deal of thanks for this wonderful piece of code! - ------------------------------------------------------------------------------ - -Support for this device is now a part of the standard Linux kernel. The -driver source code file is drivers/net/sb1000.c. In addition to this -you will need: - -1.) The "cmconfig" program. This is a utility which supplements "ifconfig" -to configure the cable modem and network interface (usually called "cm0"); -and - -2.) Several PPP scripts which live in /etc/ppp to make connecting via your -cable modem easy. - - These utilities can be obtained from: - - http://www.jacksonville.net/~fventuri/ - - in Franco's original source code distribution .tar.gz file. Support for - the sb1000 driver can be found at: - - http://web.archive.org/web/*/http://home.adelphia.net/~siglercm/sb1000.html - http://web.archive.org/web/*/http://linuxpower.cx/~cable/ - - along with these utilities. - -3.) The standard isapnp tools. These are necessary to configure your SB1000 -card at boot time (or afterwards by hand) since it's a PnP card. - - If you don't have these installed as a standard part of your Linux - distribution, you can find them at: - - http://www.roestock.demon.co.uk/isapnptools/ - - or check your Linux distribution binary CD or their web site. For help with - isapnp, pnpdump, or /etc/isapnp.conf, go to: - - http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html - ------------------------------------------------------------------------------ - -To make the SB1000 card work, follow these steps: - -1.) Run `make config', or `make menuconfig', or `make xconfig', whichever -you prefer, in the top kernel tree directory to set up your kernel -configuration. Make sure to say "Y" to "Prompt for development drivers" -and to say "M" to the sb1000 driver. Also say "Y" or "M" to all the standard -networking questions to get TCP/IP and PPP networking support. - -2.) *BEFORE* you build the kernel, edit drivers/net/sb1000.c. Make sure -to redefine the value of READ_DATA_PORT to match the I/O address used -by isapnp to access your PnP cards. This is the value of READPORT in -/etc/isapnp.conf or given by the output of pnpdump. - -3.) Build and install the kernel and modules as usual. - -4.) Boot your new kernel following the usual procedures. - -5.) Set up to configure the new SB1000 PnP card by capturing the output -of "pnpdump" to a file and editing this file to set the correct I/O ports, -IRQ, and DMA settings for all your PnP cards. Make sure none of the settings -conflict with one another. Then test this configuration by running the -"isapnp" command with your new config file as the input. Check for -errors and fix as necessary. (As an aside, I use I/O ports 0x110 and -0x310 and IRQ 11 for my SB1000 card and these work well for me. YMMV.) -Then save the finished config file as /etc/isapnp.conf for proper configuration -on subsequent reboots. - -6.) Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of -the others referenced above. As root, unpack it into a temporary directory and -do a `make cmconfig' and then `install -c cmconfig /usr/local/sbin'. Don't do -`make install' because it expects to find all the utilities built and ready for -installation, not just cmconfig. - -7.) As root, copy all the files under the ppp/ subdirectory in Franco's -tar file into /etc/ppp, being careful not to overwrite any files that are -already in there. Then modify ppp@gi-on to set the correct login name, -phone number, and frequency for the cable modem. Also edit pap-secrets -to specify your login name and password and any site-specific information -you need. - -8.) Be sure to modify /etc/ppp/firewall to use ipchains instead of -the older ipfwadm commands from the 2.0.x kernels. There's a neat utility to -convert ipfwadm commands to ipchains commands: - - http://users.dhp.com/~whisper/ipfwadm2ipchains/ - -You may also wish to modify the firewall script to implement a different -firewalling scheme. - -9.) Start the PPP connection via the script /etc/ppp/ppp@gi-on. You must be -root to do this. It's better to use a utility like sudo to execute -frequently used commands like this with root permissions if possible. If you -connect successfully the cable modem interface will come up and you'll see a -driver message like this at the console: - - cm0: sb1000 at (0x110,0x310), csn 1, S/N 0x2a0d16d8, IRQ 11. - sb1000.c:v1.1.2 6/01/98 (fventuri@mediaone.net) - -The "ifconfig" command should show two new interfaces, ppp0 and cm0. -The command "cmconfig cm0" will give you information about the cable modem -interface. - -10.) Try pinging a site via `ping -c 5 www.yahoo.com', for example. You should -see packets received. - -11.) If you can't get site names (like www.yahoo.com) to resolve into -IP addresses (like 204.71.200.67), be sure your /etc/resolv.conf file -has no syntax errors and has the right nameserver IP addresses in it. -If this doesn't help, try something like `ping -c 5 204.71.200.67' to -see if the networking is running but the DNS resolution is where the -problem lies. - -12.) If you still have problems, go to the support web sites mentioned above -and read the information and documentation there. - ------------------------------------------------------------------------------ - -Common problems: - -1.) Packets go out on the ppp0 interface but don't come back on the cm0 -interface. It looks like I'm connected but I can't even ping any -numerical IP addresses. (This happens predominantly on Debian systems due -to a default boot-time configuration script.) - -Solution -- As root `echo 0 > /proc/sys/net/ipv4/conf/cm0/rp_filter' so it -can share the same IP address as the ppp0 interface. Note that this -command should probably be added to the /etc/ppp/cablemodem script -*right*between* the "/sbin/ifconfig" and "/sbin/cmconfig" commands. -You may need to do this to /proc/sys/net/ipv4/conf/ppp0/rp_filter as well. -If you do this to /proc/sys/net/ipv4/conf/default/rp_filter on each reboot -(in rc.local or some such) then any interfaces can share the same IP -addresses. - -2.) I get "unresolved symbol" error messages on executing `insmod sb1000.o'. - -Solution -- You probably have a non-matching kernel source tree and -/usr/include/linux and /usr/include/asm header files. Make sure you -install the correct versions of the header files in these two directories. -Then rebuild and reinstall the kernel. - -3.) When isapnp runs it reports an error, and my SB1000 card isn't working. - -Solution -- There's a problem with later versions of isapnp using the "(CHECK)" -option in the lines that allocate the two I/O addresses for the SB1000 card. -This first popped up on RH 6.0. Delete "(CHECK)" for the SB1000 I/O addresses. -Make sure they don't conflict with any other pieces of hardware first! Then -rerun isapnp and go from there. - -4.) I can't execute the /etc/ppp/ppp@gi-on file. - -Solution -- As root do `chmod ug+x /etc/ppp/ppp@gi-on'. - -5.) The firewall script isn't working (with 2.2.x and higher kernels). - -Solution -- Use the ipfwadm2ipchains script referenced above to convert the -/etc/ppp/firewall script from the deprecated ipfwadm commands to ipchains. - -6.) I'm getting *tons* of firewall deny messages in the /var/kern.log, -/var/messages, and/or /var/syslog files, and they're filling up my /var -partition!!! - -Solution -- First, tell your ISP that you're receiving DoS (Denial of Service) -and/or portscanning (UDP connection attempts) attacks! Look over the deny -messages to figure out what the attack is and where it's coming from. Next, -edit /etc/ppp/cablemodem and make sure the ",nobroadcast" option is turned on -to the "cmconfig" command (uncomment that line). If you're not receiving these -denied packets on your broadcast interface (IP address xxx.yyy.zzz.255 -typically), then someone is attacking your machine in particular. Be careful -out there.... - -7.) Everything seems to work fine but my computer locks up after a while -(and typically during a lengthy download through the cable modem)! - -Solution -- You may need to add a short delay in the driver to 'slow down' the -SURFboard because your PC might not be able to keep up with the transfer rate -of the SB1000. To do this, it's probably best to download Franco's -sb1000-1.1.2.tar.gz archive and build and install sb1000.o manually. You'll -want to edit the 'Makefile' and look for the 'SB1000_DELAY' -define. Uncomment those 'CFLAGS' lines (and comment out the default ones) -and try setting the delay to something like 60 microseconds with: -'-DSB1000_DELAY=60'. Then do `make' and as root `make install' and try -it out. If it still doesn't work or you like playing with the driver, you may -try other numbers. Remember though that the higher the delay, the slower the -driver (which slows down the rest of the PC too when it is actively -used). Thanks to Ed Daiga for this tip! - ------------------------------------------------------------------------------ - -Credits: This README came from Franco Venturi's original README file which is -still supplied with his driver .tar.gz archive. I and all other sb1000 users -owe Franco a tremendous "Thank you!" Additional thanks goes to Carl Patten -and Ralph Bonnell who are now managing the Linux SB1000 web site, and to -the SB1000 users who reported and helped debug the common problems listed -above. - - - Clemmitt Sigler - csigler@vt.edu diff --git a/Documentation/networking/device_drivers/smsc/smc9.txt b/Documentation/networking/device_drivers/smsc/smc9.txt deleted file mode 100644 index d1e15074e43d..000000000000 --- a/Documentation/networking/device_drivers/smsc/smc9.txt +++ /dev/null @@ -1,42 +0,0 @@ - -SMC 9xxxx Driver -Revision 0.12 -3/5/96 -Copyright 1996 Erik Stahlman -Released under terms of the GNU General Public License. - -This file contains the instructions and caveats for my SMC9xxx driver. You -should not be using the driver without reading this file. - -Things to note about installation: - - 1. The driver should work on all kernels from 1.2.13 until 1.3.71. - (A kernel patch is supplied for 1.3.71 ) - - 2. If you include this into the kernel, you might need to change some - options, such as for forcing IRQ. - - - 3. To compile as a module, run 'make' . - Make will give you the appropriate options for various kernel support. - - 4. Loading the driver as a module : - - use: insmod smc9194.o - optional parameters: - io=xxxx : your base address - irq=xx : your irq - ifport=x : 0 for whatever is default - 1 for twisted pair - 2 for AUI ( or BNC on some cards ) - -How to obtain the latest version? - -FTP: - ftp://fenris.campus.vt.edu/smc9/smc9-12.tar.gz - ftp://sfbox.vt.edu/filebox/F/fenris/smc9/smc9-12.tar.gz - - -Contacting me: - erik@mail.vt.edu - diff --git a/Documentation/networking/device_drivers/ti/cpsw.txt b/Documentation/networking/device_drivers/ti/cpsw.txt deleted file mode 100644 index d4d4c0751a09..000000000000 --- a/Documentation/networking/device_drivers/ti/cpsw.txt +++ /dev/null @@ -1,541 +0,0 @@ -* Texas Instruments CPSW ethernet driver - -Multiqueue & CBS & MQPRIO -===================================================================== -===================================================================== - -The cpsw has 3 CBS shapers for each external ports. This document -describes MQPRIO and CBS Qdisc offload configuration for cpsw driver -based on examples. It potentially can be used in audio video bridging -(AVB) and time sensitive networking (TSN). - -The following examples were tested on AM572x EVM and BBB boards. - -Test setup -========== - -Under consideration two examples with AM572x EVM running cpsw driver -in dual_emac mode. - -Several prerequisites: -- TX queues must be rated starting from txq0 that has highest priority -- Traffic classes are used starting from 0, that has highest priority -- CBS shapers should be used with rated queues -- The bandwidth for CBS shapers has to be set a little bit more then - potential incoming rate, thus, rate of all incoming tx queues has - to be a little less -- Real rates can differ, due to discreetness -- Map skb-priority to txq is not enough, also skb-priority to l2 prio - map has to be created with ip or vconfig tool -- Any l2/socket prio (0 - 7) for classes can be used, but for - simplicity default values are used: 3 and 2 -- only 2 classes tested: A and B, but checked and can work with more, - maximum allowed 4, but only for 3 rate can be set. - -Test setup for examples -======================= - +-------------------------------+ - |--+ | - | | Workstation0 | - |E | MAC 18:03:73:66:87:42 | -+-----------------------------+ +--|t | | -| | 1 | E | | |h |./tsn_listener -d \ | -| Target board: | 0 | t |--+ |0 | 18:03:73:66:87:42 -i eth0 \| -| AM572x EVM | 0 | h | | | -s 1500 | -| | 0 | 0 | |--+ | -| Only 2 classes: |Mb +---| +-------------------------------+ -| class A, class B | | -| | +---| +-------------------------------+ -| | 1 | E | |--+ | -| | 0 | t | | | Workstation1 | -| | 0 | h |--+ |E | MAC 20:cf:30:85:7d:fd | -| |Mb | 1 | +--|t | | -+-----------------------------+ |h |./tsn_listener -d \ | - |0 | 20:cf:30:85:7d:fd -i eth0 \| - | | -s 1500 | - |--+ | - +-------------------------------+ - -********************************************************************* -********************************************************************* -********************************************************************* -Example 1: One port tx AVB configuration scheme for target board ----------------------------------------------------------------------- -(prints and scheme for AM572x evm, applicable for single port boards) - -tc - traffic class -txq - transmit queue -p - priority -f - fifo (cpsw fifo) -S - shaper configured - -+------------------------------------------------------------------+ u -| +---------------+ +---------------+ +------+ +------+ | s -| | | | | | | | | | e -| | App 1 | | App 2 | | Apps | | Apps | | r -| | Class A | | Class B | | Rest | | Rest | | -| | Eth0 | | Eth0 | | Eth0 | | Eth1 | | s -| | VLAN100 | | VLAN100 | | | | | | | | p -| | 40 Mb/s | | 20 Mb/s | | | | | | | | a -| | SO_PRIORITY=3 | | SO_PRIORITY=2 | | | | | | | | c -| | | | | | | | | | | | | | e -| +---|-----------+ +---|-----------+ +---|--+ +---|--+ | -+-----|------------------|------------------|--------|-------------+ - +-+ +------------+ | | - | | +-----------------+ +--+ - | | | | -+---|-------|-------------|-----------------------|----------------+ -| +----+ +----+ +----+ +----+ +----+ | -| | p3 | | p2 | | p1 | | p0 | | p0 | | k -| \ / \ / \ / \ / \ / | e -| \ / \ / \ / \ / \ / | r -| \/ \/ \/ \/ \/ | n -| | | | | | e -| | | +-----+ | | l -| | | | | | -| +----+ +----+ +----+ +----+ | s -| |tc0 | |tc1 | |tc2 | |tc0 | | p -| \ / \ / \ / \ / | a -| \ / \ / \ / \ / | c -| \/ \/ \/ \/ | e -| | | +-----+ | | -| | | | | | | -| | | | | | | -| | | | | | | -| +----+ +----+ +----+ +----+ +----+ | -| |txq0| |txq1| |txq2| |txq3| |txq4| | -| \ / \ / \ / \ / \ / | -| \ / \ / \ / \ / \ / | -| \/ \/ \/ \/ \/ | -| +-|------|------|------|--+ +--|--------------+ | -| | | | | | | Eth0.100 | | Eth1 | | -+---|------|------|------|------------------------|----------------+ - | | | | | - p p p p | - 3 2 0-1, 4-7 <- L2 priority | - | | | | | - | | | | | -+---|------|------|------|------------------------|----------------+ -| | | | | |----------+ | -| +----+ +----+ +----+ +----+ +----+ | -| |dma7| |dma6| |dma5| |dma4| |dma3| | -| \ / \ / \ / \ / \ / | c -| \S / \S / \ / \ / \ / | p -| \/ \/ \/ \/ \/ | s -| | | | +----- | | w -| | | | | | | -| | | | | | | d -| +----+ +----+ +----+p p+----+ | r -| | | | | | |o o| | | i -| | f3 | | f2 | | f0 |r r| f0 | | v -| |tc0 | |tc1 | |tc2 |t t|tc0 | | e -| \CBS / \CBS / \CBS /1 2\CBS / | r -| \S / \S / \ / \ / | -| \/ \/ \/ \/ | -+------------------------------------------------------------------+ -========================================Eth==========================> - -1) -// Add 4 tx queues, for interface Eth0, and 1 tx queue for Eth1 -$ ethtool -L eth0 rx 1 tx 5 -rx unmodified, ignoring - -2) -// Check if num of queues is set correctly: -$ ethtool -l eth0 -Channel parameters for eth0: -Pre-set maximums: -RX: 8 -TX: 8 -Other: 0 -Combined: 0 -Current hardware settings: -RX: 1 -TX: 5 -Other: 0 -Combined: 0 - -3) -// TX queues must be rated starting from 0, so set bws for tx0 and tx1 -// Set rates 40 and 20 Mb/s appropriately. -// Pay attention, real speed can differ a bit due to discreetness. -// Leave last 2 tx queues not rated. -$ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate -$ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate - -4) -// Check maximum rate of tx (cpdma) queues: -$ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate -40 -20 -0 -0 -0 - -5) -// Map skb->priority to traffic class: -// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2 -// Map traffic class to transmit queue: -// tc0 -> txq0, tc1 -> txq1, tc2 -> (txq2, txq3) -$ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \ -map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 1 - -5a) -// As two interface sharing same set of tx queues, assign all traffic -// coming to interface Eth1 to separate queue in order to not mix it -// with traffic from interface Eth0, so use separate txq to send -// packets to Eth1, so all prio -> tc0 and tc0 -> txq4 -// Here hw 0, so here still default configuration for eth1 in hw -$ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 1 \ -map 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@4 hw 0 - -6) -// Check classes settings -$ tc -g class show dev eth0 -+---(100:ffe2) mqprio -| +---(100:3) mqprio -| +---(100:4) mqprio -| -+---(100:ffe1) mqprio -| +---(100:2) mqprio -| -+---(100:ffe0) mqprio - +---(100:1) mqprio - -$ tc -g class show dev eth1 -+---(100:ffe0) mqprio - +---(100:5) mqprio - -7) -// Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc -// Set it +1 Mb for reserve (important!) -// here only idle slope is important, others arg are ignored -// Pay attention, real speed can differ a bit due to discreetness -$ tc qdisc add dev eth0 parent 100:1 cbs locredit -1438 \ -hicredit 62 sendslope -959000 idleslope 41000 offload 1 -net eth0: set FIFO3 bw = 50 - -8) -// Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc: -// Set it +1 Mb for reserve (important!) -$ tc qdisc add dev eth0 parent 100:2 cbs locredit -1468 \ -hicredit 65 sendslope -979000 idleslope 21000 offload 1 -net eth0: set FIFO2 bw = 30 - -9) -// Create vlan 100 to map sk->priority to vlan qos -$ ip link add link eth0 name eth0.100 type vlan id 100 -8021q: 802.1Q VLAN Support v1.8 -8021q: adding VLAN 0 to HW filter on device eth0 -8021q: adding VLAN 0 to HW filter on device eth1 -net eth0: Adding vlanid 100 to vlan filter - -10) -// Map skb->priority to L2 prio, 1 to 1 -$ ip link set eth0.100 type vlan \ -egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 - -11) -// Check egress map for vlan 100 -$ cat /proc/net/vlan/eth0.100 -[...] -INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 -EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 - -12) -// Run your appropriate tools with socket option "SO_PRIORITY" -// to 3 for class A and/or to 2 for class B -// (I took at https://www.spinics.net/lists/netdev/msg460869.html) -./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500& -./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500& - -13) -// run your listener on workstation (should be in same vlan) -// (I took at https://www.spinics.net/lists/netdev/msg460869.html) -./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500 -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39000 kbps - -14) -// Restore default configuration if needed -$ ip link del eth0.100 -$ tc qdisc del dev eth1 root -$ tc qdisc del dev eth0 root -net eth0: Prev FIFO2 is shaped -net eth0: set FIFO3 bw = 0 -net eth0: set FIFO2 bw = 0 -$ ethtool -L eth0 rx 1 tx 1 - -********************************************************************* -********************************************************************* -********************************************************************* -Example 2: Two port tx AVB configuration scheme for target board ----------------------------------------------------------------------- -(prints and scheme for AM572x evm, for dual emac boards only) - -+------------------------------------------------------------------+ u -| +----------+ +----------+ +------+ +----------+ +----------+ | s -| | | | | | | | | | | | e -| | App 1 | | App 2 | | Apps | | App 3 | | App 4 | | r -| | Class A | | Class B | | Rest | | Class B | | Class A | | -| | Eth0 | | Eth0 | | | | | Eth1 | | Eth1 | | s -| | VLAN100 | | VLAN100 | | | | | VLAN100 | | VLAN100 | | p -| | 40 Mb/s | | 20 Mb/s | | | | | 10 Mb/s | | 30 Mb/s | | a -| | SO_PRI=3 | | SO_PRI=2 | | | | | SO_PRI=3 | | SO_PRI=2 | | c -| | | | | | | | | | | | | | | | | e -| +---|------+ +---|------+ +---|--+ +---|------+ +---|------+ | -+-----|-------------|-------------|---------|-------------|--------+ - +-+ +-------+ | +----------+ +----+ - | | +-------+------+ | | - | | | | | | -+---|-------|-------------|--------------|-------------|-------|---+ -| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | -| | p3 | | p2 | | p1 | | p0 | | p0 | | p1 | | p2 | | p3 | | k -| \ / \ / \ / \ / \ / \ / \ / \ / | e -| \ / \ / \ / \ / \ / \ / \ / \ / | r -| \/ \/ \/ \/ \/ \/ \/ \/ | n -| | | | | | | | e -| | | +----+ +----+ | | | l -| | | | | | | | -| +----+ +----+ +----+ +----+ +----+ +----+ | s -| |tc0 | |tc1 | |tc2 | |tc2 | |tc1 | |tc0 | | p -| \ / \ / \ / \ / \ / \ / | a -| \ / \ / \ / \ / \ / \ / | c -| \/ \/ \/ \/ \/ \/ | e -| | | +-----+ +-----+ | | | -| | | | | | | | | | -| | | | | | | | | | -| | | | | E E | | | | | -| +----+ +----+ +----+ +----+ t t +----+ +----+ +----+ +----+ | -| |txq0| |txq1| |txq4| |txq5| h h |txq6| |txq7| |txq3| |txq2| | -| \ / \ / \ / \ / 0 1 \ / \ / \ / \ / | -| \ / \ / \ / \ / . . \ / \ / \ / \ / | -| \/ \/ \/ \/ 1 1 \/ \/ \/ \/ | -| +-|------|------|------|--+ 0 0 +-|------|------|------|--+ | -| | | | | | | 0 0 | | | | | | | -+---|------|------|------|---------------|------|------|------|----+ - | | | | | | | | - p p p p p p p p - 3 2 0-1, 4-7 <-L2 pri-> 0-1, 4-7 2 3 - | | | | | | | | - | | | | | | | | -+---|------|------|------|---------------|------|------|------|----+ -| | | | | | | | | | -| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ | -| |dma7| |dma6| |dma3| |dma2| |dma1| |dma0| |dma4| |dma5| | -| \ / \ / \ / \ / \ / \ / \ / \ / | c -| \S / \S / \ / \ / \ / \ / \S / \S / | p -| \/ \/ \/ \/ \/ \/ \/ \/ | s -| | | | +----- | | | | | w -| | | | | +----+ | | | | -| | | | | | | | | | d -| +----+ +----+ +----+p p+----+ +----+ +----+ | r -| | | | | | |o o| | | | | | | i -| | f3 | | f2 | | f0 |r CPSW r| f3 | | f2 | | f0 | | v -| |tc0 | |tc1 | |tc2 |t t|tc0 | |tc1 | |tc2 | | e -| \CBS / \CBS / \CBS /1 2\CBS / \CBS / \CBS / | r -| \S / \S / \ / \S / \S / \ / | -| \/ \/ \/ \/ \/ \/ | -+------------------------------------------------------------------+ -========================================Eth==========================> - -1) -// Add 8 tx queues, for interface Eth0, but they are common, so are accessed -// by two interfaces Eth0 and Eth1. -$ ethtool -L eth1 rx 1 tx 8 -rx unmodified, ignoring - -2) -// Check if num of queues is set correctly: -$ ethtool -l eth0 -Channel parameters for eth0: -Pre-set maximums: -RX: 8 -TX: 8 -Other: 0 -Combined: 0 -Current hardware settings: -RX: 1 -TX: 8 -Other: 0 -Combined: 0 - -3) -// TX queues must be rated starting from 0, so set bws for tx0 and tx1 for Eth0 -// and for tx2 and tx3 for Eth1. That is, rates 40 and 20 Mb/s appropriately -// for Eth0 and 30 and 10 Mb/s for Eth1. -// Real speed can differ a bit due to discreetness -// Leave last 4 tx queues as not rated -$ echo 40 > /sys/class/net/eth0/queues/tx-0/tx_maxrate -$ echo 20 > /sys/class/net/eth0/queues/tx-1/tx_maxrate -$ echo 30 > /sys/class/net/eth1/queues/tx-2/tx_maxrate -$ echo 10 > /sys/class/net/eth1/queues/tx-3/tx_maxrate - -4) -// Check maximum rate of tx (cpdma) queues: -$ cat /sys/class/net/eth0/queues/tx-*/tx_maxrate -40 -20 -30 -10 -0 -0 -0 -0 - -5) -// Map skb->priority to traffic class for Eth0: -// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2 -// Map traffic class to transmit queue: -// tc0 -> txq0, tc1 -> txq1, tc2 -> (txq4, txq5) -$ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \ -map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@4 hw 1 - -6) -// Check classes settings -$ tc -g class show dev eth0 -+---(100:ffe2) mqprio -| +---(100:5) mqprio -| +---(100:6) mqprio -| -+---(100:ffe1) mqprio -| +---(100:2) mqprio -| -+---(100:ffe0) mqprio - +---(100:1) mqprio - -7) -// Set rate for class A - 41 Mbit (tc0, txq0) using CBS Qdisc for Eth0 -// here only idle slope is important, others ignored -// Real speed can differ a bit due to discreetness -$ tc qdisc add dev eth0 parent 100:1 cbs locredit -1470 \ -hicredit 62 sendslope -959000 idleslope 41000 offload 1 -net eth0: set FIFO3 bw = 50 - -8) -// Set rate for class B - 21 Mbit (tc1, txq1) using CBS Qdisc for Eth0 -$ tc qdisc add dev eth0 parent 100:2 cbs locredit -1470 \ -hicredit 65 sendslope -979000 idleslope 21000 offload 1 -net eth0: set FIFO2 bw = 30 - -9) -// Create vlan 100 to map sk->priority to vlan qos for Eth0 -$ ip link add link eth0 name eth0.100 type vlan id 100 -net eth0: Adding vlanid 100 to vlan filter - -10) -// Map skb->priority to L2 prio for Eth0.100, one to one -$ ip link set eth0.100 type vlan \ -egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 - -11) -// Check egress map for vlan 100 -$ cat /proc/net/vlan/eth0.100 -[...] -INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 -EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 - -12) -// Map skb->priority to traffic class for Eth1: -// 3pri -> tc0, 2pri -> tc1, (0,1,4-7)pri -> tc2 -// Map traffic class to transmit queue: -// tc0 -> txq2, tc1 -> txq3, tc2 -> (txq6, txq7) -$ tc qdisc replace dev eth1 handle 100: parent root mqprio num_tc 3 \ -map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@2 1@3 2@6 hw 1 - -13) -// Check classes settings -$ tc -g class show dev eth1 -+---(100:ffe2) mqprio -| +---(100:7) mqprio -| +---(100:8) mqprio -| -+---(100:ffe1) mqprio -| +---(100:4) mqprio -| -+---(100:ffe0) mqprio - +---(100:3) mqprio - -14) -// Set rate for class A - 31 Mbit (tc0, txq2) using CBS Qdisc for Eth1 -// here only idle slope is important, others ignored, but calculated -// for interface speed - 100Mb for eth1 port. -// Set it +1 Mb for reserve (important!) -$ tc qdisc add dev eth1 parent 100:3 cbs locredit -1035 \ -hicredit 465 sendslope -69000 idleslope 31000 offload 1 -net eth1: set FIFO3 bw = 31 - -15) -// Set rate for class B - 11 Mbit (tc1, txq3) using CBS Qdisc for Eth1 -// Set it +1 Mb for reserve (important!) -$ tc qdisc add dev eth1 parent 100:4 cbs locredit -1335 \ -hicredit 405 sendslope -89000 idleslope 11000 offload 1 -net eth1: set FIFO2 bw = 11 - -16) -// Create vlan 100 to map sk->priority to vlan qos for Eth1 -$ ip link add link eth1 name eth1.100 type vlan id 100 -net eth1: Adding vlanid 100 to vlan filter - -17) -// Map skb->priority to L2 prio for Eth1.100, one to one -$ ip link set eth1.100 type vlan \ -egress 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 - -18) -// Check egress map for vlan 100 -$ cat /proc/net/vlan/eth1.100 -[...] -INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0 -EGRESS priority mappings: 0:0 1:1 2:2 3:3 4:4 5:5 6:6 7:7 - -19) -// Run appropriate tools with socket option "SO_PRIORITY" to 3 -// for class A and to 2 for class B. For both interfaces -./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p2 -s 1500& -./tsn_talker -d 18:03:73:66:87:42 -i eth0.100 -p3 -s 1500& -./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p2 -s 1500& -./tsn_talker -d 20:cf:30:85:7d:fd -i eth1.100 -p3 -s 1500& - -20) -// run your listener on workstation (should be in same vlan) -// (I took at https://www.spinics.net/lists/netdev/msg460869.html) -./tsn_listener -d 18:03:73:66:87:42 -i enp5s0 -s 1500 -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39012 kbps -Receiving data rate: 39000 kbps - -21) -// Restore default configuration if needed -$ ip link del eth1.100 -$ ip link del eth0.100 -$ tc qdisc del dev eth1 root -net eth1: Prev FIFO2 is shaped -net eth1: set FIFO3 bw = 0 -net eth1: set FIFO2 bw = 0 -$ tc qdisc del dev eth0 root -net eth0: Prev FIFO2 is shaped -net eth0: set FIFO3 bw = 0 -net eth0: set FIFO2 bw = 0 -$ ethtool -L eth0 rx 1 tx 1 diff --git a/Documentation/networking/device_drivers/wifi/index.rst b/Documentation/networking/device_drivers/wifi/index.rst new file mode 100644 index 000000000000..fb394f5de4a9 --- /dev/null +++ b/Documentation/networking/device_drivers/wifi/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Wi-Fi Device Drivers +==================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + intel/ipw2100 + intel/ipw2200 + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/intel/ipw2100.txt b/Documentation/networking/device_drivers/wifi/intel/ipw2100.rst index 6f85e1d06031..883e96355799 100644 --- a/Documentation/networking/device_drivers/intel/ipw2100.txt +++ b/Documentation/networking/device_drivers/wifi/intel/ipw2100.rst @@ -1,31 +1,37 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> -Intel(R) PRO/Wireless 2100 Driver for Linux in support of: +=========================================== +Intel(R) PRO/Wireless 2100 Driver for Linux +=========================================== -Intel(R) PRO/Wireless 2100 Network Connection +Support for: -Copyright (C) 2003-2006, Intel Corporation +- Intel(R) PRO/Wireless 2100 Network Connection + +Copyright |copy| 2003-2006, Intel Corporation README.ipw2100 -Version: git-1.1.5 -Date : January 25, 2006 +:Version: git-1.1.5 +:Date: January 25, 2006 -Index ------------------------------------------------ -0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER -1. Introduction -2. Release git-1.1.5 Current Features -3. Command Line Parameters -4. Sysfs Helper Files -5. Radio Kill Switch -6. Dynamic Firmware -7. Power Management -8. Support -9. License +.. Index + + 0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER + 1. Introduction + 2. Release git-1.1.5 Current Features + 3. Command Line Parameters + 4. Sysfs Helper Files + 5. Radio Kill Switch + 6. Dynamic Firmware + 7. Power Management + 8. Support + 9. License -0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER ------------------------------------------------ +0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER +================================================= Important Notice FOR ALL USERS OR DISTRIBUTORS!!!! @@ -72,13 +78,13 @@ such, if you are interested in deploying or shipping a driver as part of solution intended to be used for purposes other than development, please obtain a tested driver from Intel Customer Support at: -http://www.intel.com/support/wireless/sb/CS-006408.htm +https://www.intel.com/support/wireless/sb/CS-006408.htm 1. Introduction ------------------------------------------------ +=============== -This document provides a brief overview of the features supported by the -IPW2100 driver project. The main project website, where the latest +This document provides a brief overview of the features supported by the +IPW2100 driver project. The main project website, where the latest development version of the driver can be found, is: http://ipw2100.sourceforge.net @@ -89,10 +95,11 @@ for the driver project. 2. Release git-1.1.5 Current Supported Features ------------------------------------------------ +=============================================== + - Managed (BSS) and Ad-Hoc (IBSS) - WEP (shared key and open) -- Wireless Tools support +- Wireless Tools support - 802.1x (tested with XSupplicant 1.0.1) Enabled (but not supported) features: @@ -105,11 +112,11 @@ performed on a given feature. 3. Command Line Parameters ------------------------------------------------ +========================== If the driver is built as a module, the following optional parameters are used by entering them on the command line with the modprobe command using this -syntax: +syntax:: modprobe ipw2100 [<option>=<VAL1><,VAL2>...] @@ -119,61 +126,76 @@ For example, to disable the radio on driver loading, enter: The ipw2100 driver supports the following module parameters: -Name Value Example: -debug 0x0-0xffffffff debug=1024 -mode 0,1,2 mode=1 /* AdHoc */ -channel int channel=3 /* Only valid in AdHoc or Monitor */ -associate boolean associate=0 /* Do NOT auto associate */ -disable boolean disable=1 /* Do not power the HW */ +========= ============== ============ ============================== +Name Value Example Meaning +========= ============== ============ ============================== +debug 0x0-0xffffffff debug=1024 Debug level set to 1024 +mode 0,1,2 mode=1 AdHoc +channel int channel=3 Only valid in AdHoc or Monitor +associate boolean associate=0 Do NOT auto associate +disable boolean disable=1 Do not power the HW +========= ============== ============ ============================== 4. Sysfs Helper Files ---------------------------- ------------------------------------------------ +===================== -There are several ways to control the behavior of the driver. Many of the +There are several ways to control the behavior of the driver. Many of the general capabilities are exposed through the Wireless Tools (iwconfig). There are a few capabilities that are exposed through entries in the Linux Sysfs. ------ Driver Level ------ +**Driver Level** + For the driver level files, look in /sys/bus/pci/drivers/ipw2100/ - debug_level - - This controls the same global as the 'debug' module parameter. For - information on the various debugging levels available, run the 'dvals' + debug_level + This controls the same global as the 'debug' module parameter. For + information on the various debugging levels available, run the 'dvals' script found in the driver source directory. - NOTE: 'debug_level' is only enabled if CONFIG_IPW2100_DEBUG is turn - on. + .. note:: + + 'debug_level' is only enabled if CONFIG_IPW2100_DEBUG is turn on. + +**Device Level** + +For the device level files look in:: ------ Device Level ------ -For the device level files look in - /sys/bus/pci/drivers/ipw2100/{PCI-ID}/ -For example: +For example:: + /sys/bus/pci/drivers/ipw2100/0000:02:01.0 For the device level files, see /sys/bus/pci/drivers/ipw2100: rf_kill - read - - 0 = RF kill not enabled (radio on) - 1 = SW based RF kill active (radio off) - 2 = HW based RF kill active (radio off) - 3 = Both HW and SW RF kill active (radio off) - write - - 0 = If SW based RF kill active, turn the radio back on - 1 = If radio is on, activate SW based RF kill + read + + == ========================================= + 0 RF kill not enabled (radio on) + 1 SW based RF kill active (radio off) + 2 HW based RF kill active (radio off) + 3 Both HW and SW RF kill active (radio off) + == ========================================= + + write + + == ================================================== + 0 If SW based RF kill active, turn the radio back on + 1 If radio is on, activate SW based RF kill + == ================================================== - NOTE: If you enable the SW based RF kill and then toggle the HW - based RF kill from ON -> OFF -> ON, the radio will NOT come back on + .. note:: + + If you enable the SW based RF kill and then toggle the HW + based RF kill from ON -> OFF -> ON, the radio will NOT come back on 5. Radio Kill Switch ------------------------------------------------ +==================== + Most laptops provide the ability for the user to physically disable the radio. Some vendors have implemented this as a physical switch that requires no software to turn the radio off and on. On other laptops, however, the switch @@ -186,9 +208,10 @@ on your system. 6. Dynamic Firmware ------------------------------------------------ -As the firmware is licensed under a restricted use license, it can not be -included within the kernel sources. To enable the IPW2100 you will need a +=================== + +As the firmware is licensed under a restricted use license, it can not be +included within the kernel sources. To enable the IPW2100 you will need a firmware image to load into the wireless NIC's processors. You can obtain these images from <http://ipw2100.sf.net/firmware.php>. @@ -197,52 +220,57 @@ See INSTALL for instructions on installing the firmware. 7. Power Management ------------------------------------------------ -The IPW2100 supports the configuration of the Power Save Protocol -through a private wireless extension interface. The IPW2100 supports +=================== + +The IPW2100 supports the configuration of the Power Save Protocol +through a private wireless extension interface. The IPW2100 supports the following different modes: + === =========================================================== off No power management. Radio is always on. on Automatic power management - 1-5 Different levels of power management. The higher the - number the greater the power savings, but with an impact to - packet latencies. - -Power management works by powering down the radio after a certain -interval of time has passed where no packets are passed through the -radio. Once powered down, the radio remains in that state for a given -period of time. For higher power savings, the interval between last + 1-5 Different levels of power management. The higher the + number the greater the power savings, but with an impact to + packet latencies. + === =========================================================== + +Power management works by powering down the radio after a certain +interval of time has passed where no packets are passed through the +radio. Once powered down, the radio remains in that state for a given +period of time. For higher power savings, the interval between last packet processed to sleep is shorter and the sleep period is longer. -When the radio is asleep, the access point sending data to the station -must buffer packets at the AP until the station wakes up and requests -any buffered packets. If you have an AP that does not correctly support -the PSP protocol you may experience packet loss or very poor performance -while power management is enabled. If this is the case, you will need -to try and find a firmware update for your AP, or disable power -management (via `iwconfig eth1 power off`) +When the radio is asleep, the access point sending data to the station +must buffer packets at the AP until the station wakes up and requests +any buffered packets. If you have an AP that does not correctly support +the PSP protocol you may experience packet loss or very poor performance +while power management is enabled. If this is the case, you will need +to try and find a firmware update for your AP, or disable power +management (via ``iwconfig eth1 power off``) -To configure the power level on the IPW2100 you use a combination of -iwconfig and iwpriv. iwconfig is used to turn power management on, off, +To configure the power level on the IPW2100 you use a combination of +iwconfig and iwpriv. iwconfig is used to turn power management on, off, and set it to auto. + ========================= ==================================== iwconfig eth1 power off Disables radio power down - iwconfig eth1 power on Enables radio power management to + iwconfig eth1 power on Enables radio power management to last set level (defaults to AUTO) - iwpriv eth1 set_power 0 Sets power level to AUTO and enables - power management if not previously + iwpriv eth1 set_power 0 Sets power level to AUTO and enables + power management if not previously enabled. - iwpriv eth1 set_power 1-5 Set the power level as specified, - enabling power management if not + iwpriv eth1 set_power 1-5 Set the power level as specified, + enabling power management if not previously enabled. + ========================= ==================================== + +You can view the current power level setting via:: -You can view the current power level setting via: - iwpriv eth1 get_power It will return the current period or timeout that is configured as a string in the form of xxxx/yyyy (z) where xxxx is the timeout interval (amount of -time after packet processing), yyyy is the period to sleep (amount of time to +time after packet processing), yyyy is the period to sleep (amount of time to wait before powering the radio and querying the access point for buffered packets), and z is the 'power level'. If power management is turned off the xxxx/yyyy will be replaced with 'off' -- the level reported will be the active @@ -250,44 +278,46 @@ level if `iwconfig eth1 power on` is invoked. 8. Support ------------------------------------------------ +========== For general development information and support, go to: - + http://ipw2100.sf.net/ -The ipw2100 1.1.0 driver and firmware can be downloaded from: +The ipw2100 1.1.0 driver and firmware can be downloaded from: http://support.intel.com -For installation support on the ipw2100 1.1.0 driver on Linux kernels -2.6.8 or greater, email support is available from: +For installation support on the ipw2100 1.1.0 driver on Linux kernels +2.6.8 or greater, email support is available from: http://supportmail.intel.com 9. License ------------------------------------------------ +========== - Copyright(c) 2003 - 2006 Intel Corporation. All rights reserved. + Copyright |copy| 2003 - 2006 Intel Corporation. All rights reserved. - This program is free software; you can redistribute it and/or modify it - under the terms of the GNU General Public License (version 2) as + This program is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License (version 2) as published by the Free Software Foundation. - - 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 + + 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. - + You should have received a copy of the GNU General Public License along with - this program; if not, write to the Free Software Foundation, Inc., 59 + this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - + The full GNU General Public License is included in this distribution in the file called LICENSE. - + License Contact Information: + James P. Ketrenos <ipw2100-admin@linux.intel.com> + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 diff --git a/Documentation/networking/device_drivers/intel/ipw2200.txt b/Documentation/networking/device_drivers/wifi/intel/ipw2200.rst index b7658bed4906..0cb42d2fd7e5 100644 --- a/Documentation/networking/device_drivers/intel/ipw2200.txt +++ b/Documentation/networking/device_drivers/wifi/intel/ipw2200.rst @@ -1,8 +1,15 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> -Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of: +============================================== +Intel(R) PRO/Wireless 2915ABG Driver for Linux +============================================== -Intel(R) PRO/Wireless 2200BG Network Connection -Intel(R) PRO/Wireless 2915ABG Network Connection + +Support for: + +- Intel(R) PRO/Wireless 2200BG Network Connection +- Intel(R) PRO/Wireless 2915ABG Network Connection Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R) PRO/Wireless 2200BG Driver for Linux is a unified driver that works on @@ -10,37 +17,37 @@ both hardware adapters listed above. In this document the Intel(R) PRO/Wireless 2915ABG Driver for Linux will be used to reference the unified driver. -Copyright (C) 2004-2006, Intel Corporation +Copyright |copy| 2004-2006, Intel Corporation README.ipw2200 -Version: 1.1.2 -Date : March 30, 2006 +:Version: 1.1.2 +:Date: March 30, 2006 -Index ------------------------------------------------ -0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER -1. Introduction -1.1. Overview of features -1.2. Module parameters -1.3. Wireless Extension Private Methods -1.4. Sysfs Helper Files -1.5. Supported channels -2. Ad-Hoc Networking -3. Interacting with Wireless Tools -3.1. iwconfig mode -3.2. iwconfig sens -4. About the Version Numbers -5. Firmware installation -6. Support -7. License +.. Index + 0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER + 1. Introduction + 1.1. Overview of features + 1.2. Module parameters + 1.3. Wireless Extension Private Methods + 1.4. Sysfs Helper Files + 1.5. Supported channels + 2. Ad-Hoc Networking + 3. Interacting with Wireless Tools + 3.1. iwconfig mode + 3.2. iwconfig sens + 4. About the Version Numbers + 5. Firmware installation + 6. Support + 7. License -0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER ------------------------------------------------ -Important Notice FOR ALL USERS OR DISTRIBUTORS!!!! +0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER +================================================= + +Important Notice FOR ALL USERS OR DISTRIBUTORS!!!! Intel wireless LAN adapters are engineered, manufactured, tested, and quality checked to ensure that they meet all necessary local and @@ -56,7 +63,7 @@ product is granted. Intel's wireless LAN's EEPROM, firmware, and software driver are designed to carefully control parameters that affect radio operation and to ensure electromagnetic compliance (EMC). These parameters include, without limitation, RF power, spectrum usage, -channel scanning, and human exposure. +channel scanning, and human exposure. For these reasons Intel cannot permit any manipulation by third parties of the software provided in binary format with the wireless WLAN @@ -70,7 +77,7 @@ no liability, under any theory of liability for any issues associated with the modified products, including without limitation, claims under the warranty and/or issues arising from regulatory non-compliance, and (iii) Intel will not provide or be required to assist in providing -support to any third parties for such modified products. +support to any third parties for such modified products. Note: Many regulatory agencies consider Wireless LAN adapters to be modules, and accordingly, condition system-level regulatory approval @@ -78,23 +85,24 @@ upon receipt and review of test data documenting that the antennas and system configuration do not cause the EMC and radio operation to be non-compliant. -The drivers available for download from SourceForge are provided as a -part of a development project. Conformance to local regulatory -requirements is the responsibility of the individual developer. As -such, if you are interested in deploying or shipping a driver as part of -solution intended to be used for purposes other than development, please +The drivers available for download from SourceForge are provided as a +part of a development project. Conformance to local regulatory +requirements is the responsibility of the individual developer. As +such, if you are interested in deploying or shipping a driver as part of +solution intended to be used for purposes other than development, please obtain a tested driver from Intel Customer Support at: http://support.intel.com -1. Introduction ------------------------------------------------ -The following sections attempt to provide a brief introduction to using +1. Introduction +=============== + +The following sections attempt to provide a brief introduction to using the Intel(R) PRO/Wireless 2915ABG Driver for Linux. -This document is not meant to be a comprehensive manual on -understanding or using wireless technologies, but should be sufficient +This document is not meant to be a comprehensive manual on +understanding or using wireless technologies, but should be sufficient to get you moving without wires on Linux. For information on building and installing the driver, see the INSTALL @@ -102,14 +110,14 @@ file. 1.1. Overview of Features ------------------------------------------------ +------------------------- The current release (1.1.2) supports the following features: + BSS mode (Infrastructure, Managed) + IBSS mode (Ad-Hoc) + WEP (OPEN and SHARED KEY mode) + 802.1x EAP via wpa_supplicant and xsupplicant -+ Wireless Extension support ++ Wireless Extension support + Full B and G rate support (2200 and 2915) + Full A rate support (2915 only) + Transmit power control @@ -122,102 +130,107 @@ supported: + long/short preamble support + Monitor mode (aka RFMon) -The distinction between officially supported and enabled is a reflection +The distinction between officially supported and enabled is a reflection on the amount of validation and interoperability testing that has been -performed on a given feature. +performed on a given feature. 1.2. Command Line Parameters ------------------------------------------------ +---------------------------- Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless -2915ABG Driver for Linux allows configuration options to be provided -as module parameters. The most common way to specify a module parameter -is via the command line. +2915ABG Driver for Linux allows configuration options to be provided +as module parameters. The most common way to specify a module parameter +is via the command line. -The general form is: +The general form is:: -% modprobe ipw2200 parameter=value + % modprobe ipw2200 parameter=value Where the supported parameter are: associate Set to 0 to disable the auto scan-and-associate functionality of the - driver. If disabled, the driver will not attempt to scan - for and associate to a network until it has been configured with - one or more properties for the target network, for example configuring + driver. If disabled, the driver will not attempt to scan + for and associate to a network until it has been configured with + one or more properties for the target network, for example configuring the network SSID. Default is 0 (do not auto-associate) - + Example: % modprobe ipw2200 associate=0 auto_create - Set to 0 to disable the auto creation of an Ad-Hoc network - matching the channel and network name parameters provided. + Set to 0 to disable the auto creation of an Ad-Hoc network + matching the channel and network name parameters provided. Default is 1. channel channel number for association. The normal method for setting - the channel would be to use the standard wireless tools - (i.e. `iwconfig eth1 channel 10`), but it is useful sometimes + the channel would be to use the standard wireless tools + (i.e. `iwconfig eth1 channel 10`), but it is useful sometimes to set this while debugging. Channel 0 means 'ANY' debug If using a debug build, this is used to control the amount of debug info is logged. See the 'dvals' and 'load' script for more info on - how to use this (the dvals and load scripts are provided as part - of the ipw2200 development snapshot releases available from the + how to use this (the dvals and load scripts are provided as part + of the ipw2200 development snapshot releases available from the SourceForge project at http://ipw2200.sf.net) - + led Can be used to turn on experimental LED code. 0 = Off, 1 = On. Default is 1. mode - Can be used to set the default mode of the adapter. + Can be used to set the default mode of the adapter. 0 = Managed, 1 = Ad-Hoc, 2 = Monitor 1.3. Wireless Extension Private Methods ------------------------------------------------ +--------------------------------------- -As an interface designed to handle generic hardware, there are certain -capabilities not exposed through the normal Wireless Tool interface. As -such, a provision is provided for a driver to declare custom, or -private, methods. The Intel(R) PRO/Wireless 2915ABG Driver for Linux +As an interface designed to handle generic hardware, there are certain +capabilities not exposed through the normal Wireless Tool interface. As +such, a provision is provided for a driver to declare custom, or +private, methods. The Intel(R) PRO/Wireless 2915ABG Driver for Linux defines several of these to configure various settings. -The general form of using the private wireless methods is: +The general form of using the private wireless methods is:: % iwpriv $IFNAME method parameters -Where $IFNAME is the interface name the device is registered with +Where $IFNAME is the interface name the device is registered with (typically eth1, customized via one of the various network interface name managers, such as ifrename) The supported private methods are: get_mode - Can be used to report out which IEEE mode the driver is + Can be used to report out which IEEE mode the driver is configured to support. Example: - + % iwpriv eth1 get_mode eth1 get_mode:802.11bg (6) set_mode - Can be used to configure which IEEE mode the driver will - support. + Can be used to configure which IEEE mode the driver will + support. + + Usage:: + + % iwpriv eth1 set_mode {mode} - Usage: - % iwpriv eth1 set_mode {mode} Where {mode} is a number in the range 1-7: + + == ===================== 1 802.11a (2915 only) 2 802.11b 3 802.11ab (2915 only) - 4 802.11g + 4 802.11g 5 802.11ag (2915 only) 6 802.11bg 7 802.11abg (2915 only) + == ===================== get_preamble Can be used to report configuration of preamble length. @@ -225,99 +238,123 @@ The supported private methods are: set_preamble Can be used to set the configuration of preamble length: - Usage: - % iwpriv eth1 set_preamble {mode} + Usage:: + + % iwpriv eth1 set_preamble {mode} + Where {mode} is one of: + + == ======================================== 1 Long preamble only 0 Auto (long or short based on connection) - + == ======================================== + -1.4. Sysfs Helper Files: ------------------------------------------------ +1.4. Sysfs Helper Files +----------------------- -The Linux kernel provides a pseudo file system that can be used to +The Linux kernel provides a pseudo file system that can be used to access various components of the operating system. The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes several configuration parameters through this mechanism. -An entry in the sysfs can support reading and/or writing. You can -typically query the contents of a sysfs entry through the use of cat, -and can set the contents via echo. For example: +An entry in the sysfs can support reading and/or writing. You can +typically query the contents of a sysfs entry through the use of cat, +and can set the contents via echo. For example:: -% cat /sys/bus/pci/drivers/ipw2200/debug_level + % cat /sys/bus/pci/drivers/ipw2200/debug_level -Will report the current debug level of the driver's logging subsystem +Will report the current debug level of the driver's logging subsystem (only available if CONFIG_IPW2200_DEBUG was configured when the driver was built). -You can set the debug level via: +You can set the debug level via:: -% echo $VALUE > /sys/bus/pci/drivers/ipw2200/debug_level + % echo $VALUE > /sys/bus/pci/drivers/ipw2200/debug_level -Where $VALUE would be a number in the case of this sysfs entry. The -input to sysfs files does not have to be a number. For example, the -firmware loader used by hotplug utilizes sysfs entries for transferring +Where $VALUE would be a number in the case of this sysfs entry. The +input to sysfs files does not have to be a number. For example, the +firmware loader used by hotplug utilizes sysfs entries for transferring the firmware image from user space into the driver. -The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries -at two levels -- driver level, which apply to all instances of the driver -(in the event that there are more than one device installed) and device +The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries +at two levels -- driver level, which apply to all instances of the driver +(in the event that there are more than one device installed) and device level, which applies only to the single specific instance. 1.4.1 Driver Level Sysfs Helper Files ------------------------------------------------ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ For the driver level files, look in /sys/bus/pci/drivers/ipw2200/ - debug_level - + debug_level This controls the same global as the 'debug' module parameter 1.4.2 Device Level Sysfs Helper Files ------------------------------------------------ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +For the device level files, look in:: -For the device level files, look in - /sys/bus/pci/drivers/ipw2200/{PCI-ID}/ -For example: +For example::: + /sys/bus/pci/drivers/ipw2200/0000:02:01.0 For the device level files, see /sys/bus/pci/drivers/ipw2200: rf_kill - read - - 0 = RF kill not enabled (radio on) - 1 = SW based RF kill active (radio off) - 2 = HW based RF kill active (radio off) - 3 = Both HW and SW RF kill active (radio off) + read - + + == ========================================= + 0 RF kill not enabled (radio on) + 1 SW based RF kill active (radio off) + 2 HW based RF kill active (radio off) + 3 Both HW and SW RF kill active (radio off) + == ========================================= + write - - 0 = If SW based RF kill active, turn the radio back on - 1 = If radio is on, activate SW based RF kill - NOTE: If you enable the SW based RF kill and then toggle the HW - based RF kill from ON -> OFF -> ON, the radio will NOT come back on - - ucode + == ================================================== + 0 If SW based RF kill active, turn the radio back on + 1 If radio is on, activate SW based RF kill + == ================================================== + + .. note:: + + If you enable the SW based RF kill and then toggle the HW + based RF kill from ON -> OFF -> ON, the radio will NOT come back on + + ucode read-only access to the ucode version number led read - - 0 = LED code disabled - 1 = LED code enabled + + == ================= + 0 LED code disabled + 1 LED code enabled + == ================= + write - - 0 = Disable LED code - 1 = Enable LED code - NOTE: The LED code has been reported to hang some systems when - running ifconfig and is therefore disabled by default. + == ================ + 0 Disable LED code + 1 Enable LED code + == ================ + + + .. note:: + + The LED code has been reported to hang some systems when + running ifconfig and is therefore disabled by default. 1.5. Supported channels ------------------------------------------------ +----------------------- Upon loading the Intel(R) PRO/Wireless 2915ABG Driver for Linux, a message stating the detected geography code and the number of 802.11 @@ -326,44 +363,59 @@ channels supported by the card will be displayed in the log. The geography code corresponds to a regulatory domain as shown in the table below. - Supported channels -Code Geography 802.11bg 802.11a - ---- Restricted 11 0 -ZZF Custom US/Canada 11 8 -ZZD Rest of World 13 0 -ZZA Custom USA & Europe & High 11 13 -ZZB Custom NA & Europe 11 13 -ZZC Custom Japan 11 4 -ZZM Custom 11 0 -ZZE Europe 13 19 -ZZJ Custom Japan 14 4 -ZZR Rest of World 14 0 -ZZH High Band 13 4 -ZZG Custom Europe 13 4 -ZZK Europe 13 24 -ZZL Europe 11 13 - - -2. Ad-Hoc Networking ------------------------------------------------ - -When using a device in an Ad-Hoc network, it is useful to understand the -sequence and requirements for the driver to be able to create, join, or + +------+----------------------------+--------------------+ + | | | Supported channels | + | Code | Geography +----------+---------+ + | | | 802.11bg | 802.11a | + +======+============================+==========+=========+ + | --- | Restricted | 11 | 0 | + +------+----------------------------+----------+---------+ + | ZZF | Custom US/Canada | 11 | 8 | + +------+----------------------------+----------+---------+ + | ZZD | Rest of World | 13 | 0 | + +------+----------------------------+----------+---------+ + | ZZA | Custom USA & Europe & High | 11 | 13 | + +------+----------------------------+----------+---------+ + | ZZB | Custom NA & Europe | 11 | 13 | + +------+----------------------------+----------+---------+ + | ZZC | Custom Japan | 11 | 4 | + +------+----------------------------+----------+---------+ + | ZZM | Custom | 11 | 0 | + +------+----------------------------+----------+---------+ + | ZZE | Europe | 13 | 19 | + +------+----------------------------+----------+---------+ + | ZZJ | Custom Japan | 14 | 4 | + +------+----------------------------+----------+---------+ + | ZZR | Rest of World | 14 | 0 | + +------+----------------------------+----------+---------+ + | ZZH | High Band | 13 | 4 | + +------+----------------------------+----------+---------+ + | ZZG | Custom Europe | 13 | 4 | + +------+----------------------------+----------+---------+ + | ZZK | Europe | 13 | 24 | + +------+----------------------------+----------+---------+ + | ZZL | Europe | 11 | 13 | + +------+----------------------------+----------+---------+ + +2. Ad-Hoc Networking +===================== + +When using a device in an Ad-Hoc network, it is useful to understand the +sequence and requirements for the driver to be able to create, join, or merge networks. -The following attempts to provide enough information so that you can -have a consistent experience while using the driver as a member of an +The following attempts to provide enough information so that you can +have a consistent experience while using the driver as a member of an Ad-Hoc network. 2.1. Joining an Ad-Hoc Network ------------------------------------------------ +------------------------------ -The easiest way to get onto an Ad-Hoc network is to join one that +The easiest way to get onto an Ad-Hoc network is to join one that already exists. 2.2. Creating an Ad-Hoc Network ------------------------------------------------ +------------------------------- An Ad-Hoc networks is created using the syntax of the Wireless tool. @@ -371,21 +423,21 @@ For Example: iwconfig eth1 mode ad-hoc essid testing channel 2 2.3. Merging Ad-Hoc Networks ------------------------------------------------ +---------------------------- -3. Interaction with Wireless Tools ------------------------------------------------ +3. Interaction with Wireless Tools +================================== 3.1 iwconfig mode ------------------------------------------------ +----------------- When configuring the mode of the adapter, all run-time configured parameters are reset to the value used when the module was loaded. This includes channels, rates, ESSID, etc. 3.2 iwconfig sens ------------------------------------------------ +----------------- The 'iwconfig ethX sens XX' command will not set the signal sensitivity threshold, as described in iwconfig documentation, but rather the number @@ -394,35 +446,35 @@ to another access point. At the same time, it will set the disassociation threshold to 3 times the given value. -4. About the Version Numbers ------------------------------------------------ +4. About the Version Numbers +============================= -Due to the nature of open source development projects, there are -frequently changes being incorporated that have not gone through -a complete validation process. These changes are incorporated into +Due to the nature of open source development projects, there are +frequently changes being incorporated that have not gone through +a complete validation process. These changes are incorporated into development snapshot releases. -Releases are numbered with a three level scheme: +Releases are numbered with a three level scheme: major.minor.development Any version where the 'development' portion is 0 (for example -1.0.0, 1.1.0, etc.) indicates a stable version that will be made +1.0.0, 1.1.0, etc.) indicates a stable version that will be made available for kernel inclusion. Any version where the 'development' portion is not a 0 (for example 1.0.1, 1.1.5, etc.) indicates a development version that is -being made available for testing and cutting edge users. The stability +being made available for testing and cutting edge users. The stability and functionality of the development releases are not know. We make efforts to try and keep all snapshots reasonably stable, but due to the -frequency of their release, and the desire to get those releases +frequency of their release, and the desire to get those releases available as quickly as possible, unknown anomalies should be expected. The major version number will be incremented when significant changes are made to the driver. Currently, there are no major changes planned. -5. Firmware installation ----------------------------------------------- +5. Firmware installation +======================== The driver requires a firmware image, download it and extract the files under /lib/firmware (or wherever your hotplug's firmware.agent @@ -433,40 +485,42 @@ The firmware can be downloaded from the following URL: http://ipw2200.sf.net/ -6. Support ------------------------------------------------ +6. Support +========== -For direct support of the 1.0.0 version, you can contact +For direct support of the 1.0.0 version, you can contact http://supportmail.intel.com, or you can use the open source project support. For general information and support, go to: - + http://ipw2200.sf.net/ -7. License ------------------------------------------------ +7. License +========== - Copyright(c) 2003 - 2006 Intel Corporation. All rights reserved. + Copyright |copy| 2003 - 2006 Intel Corporation. All rights reserved. - This program is free software; you can redistribute it and/or modify it - under the terms of the GNU General Public License version 2 as + This program is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. - - 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 + + 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. - + You should have received a copy of the GNU General Public License along with - this program; if not, write to the Free Software Foundation, Inc., 59 + this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - + The full GNU General Public License is included in this distribution in the file called LICENSE. - + Contact Information: + James P. Ketrenos <ipw2100-admin@linux.intel.com> + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 diff --git a/Documentation/networking/device_drivers/wwan/index.rst b/Documentation/networking/device_drivers/wwan/index.rst new file mode 100644 index 000000000000..370d8264d5dc --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +WWAN Device Drivers +=================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + iosm + t7xx + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/wwan/iosm.rst b/Documentation/networking/device_drivers/wwan/iosm.rst new file mode 100644 index 000000000000..6f9e955af984 --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/iosm.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +.. Copyright (C) 2020-21 Intel Corporation + +.. _iosm_driver_doc: + +=========================================== +IOSM Driver for Intel M.2 PCIe based Modems +=========================================== +The IOSM (IPC over Shared Memory) driver is a WWAN PCIe host driver developed +for linux or chrome platform for data exchange over PCIe interface between +Host platform & Intel M.2 Modem. The driver exposes interface conforming to the +MBIM protocol [1]. Any front end application ( eg: Modem Manager) could easily +manage the MBIM interface to enable data communication towards WWAN. + +Basic usage +=========== +MBIM functions are inactive when unmanaged. The IOSM driver only provides a +userspace interface MBIM "WWAN PORT" representing MBIM control channel and does +not play any role in managing the functionality. It is the job of a userspace +application to detect port enumeration and enable MBIM functionality. + +Examples of few such userspace application are: +- mbimcli (included with the libmbim [2] library), and +- Modem Manager [3] + +Management Applications to carry out below required actions for establishing +MBIM IP session: +- open the MBIM control channel +- configure network connection settings +- connect to network +- configure IP network interface + +Management application development +================================== +The driver and userspace interfaces are described below. The MBIM protocol is +described in [1] Mobile Broadband Interface Model v1.0 Errata-1. + +MBIM control channel userspace ABI +---------------------------------- + +/dev/wwan0mbim0 character device +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver exposes an MBIM interface to the MBIM function by implementing +MBIM WWAN Port. The userspace end of the control channel pipe is a +/dev/wwan0mbim0 character device. Application shall use this interface for +MBIM protocol communication. + +Fragmentation +~~~~~~~~~~~~~ +The userspace application is responsible for all control message fragmentation +and defragmentation as per MBIM specification. + +/dev/wwan0mbim0 write() +~~~~~~~~~~~~~~~~~~~~~~~ +The MBIM control messages from the management application must not exceed the +negotiated control message size. + +/dev/wwan0mbim0 read() +~~~~~~~~~~~~~~~~~~~~~~ +The management application must accept control messages of up the negotiated +control message size. + +MBIM data channel userspace ABI +------------------------------- + +wwan0-X network device +~~~~~~~~~~~~~~~~~~~~~~ +The IOSM driver exposes IP link interface "wwan0-X" of type "wwan" for IP +traffic. Iproute network utility is used for creating "wwan0-X" network +interface and for associating it with MBIM IP session. The Driver supports +up to 8 IP sessions for simultaneous IP communication. + +The userspace management application is responsible for creating new IP link +prior to establishing MBIM IP session where the SessionId is greater than 0. + +For example, creating new IP link for a MBIM IP session with SessionId 1: + + ip link add dev wwan0-1 parentdev-name wwan0 type wwan linkid 1 + +The driver will automatically map the "wwan0-1" network device to MBIM IP +session 1. + +References +========== +[1] "MBIM (Mobile Broadband Interface Model) Errata-1" + - https://www.usb.org/document-library/ + +[2] libmbim - "a glib-based library for talking to WWAN modems and + devices which speak the Mobile Interface Broadband Model (MBIM) + protocol" + - http://www.freedesktop.org/wiki/Software/libmbim/ + +[3] Modem Manager - "a DBus-activated daemon which controls mobile + broadband (2G/3G/4G) devices and connections" + - http://www.freedesktop.org/wiki/Software/ModemManager/ diff --git a/Documentation/networking/device_drivers/wwan/t7xx.rst b/Documentation/networking/device_drivers/wwan/t7xx.rst new file mode 100644 index 000000000000..f346f5f85f15 --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/t7xx.rst @@ -0,0 +1,166 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +.. Copyright (C) 2020-21 Intel Corporation + +.. _t7xx_driver_doc: + +============================================ +t7xx driver for MTK PCIe based T700 5G modem +============================================ +The t7xx driver is a WWAN PCIe host driver developed for linux or Chrome OS platforms +for data exchange over PCIe interface between Host platform & MediaTek's T700 5G modem. +The driver exposes an interface conforming to the MBIM protocol [1]. Any front end +application (e.g. Modem Manager) could easily manage the MBIM interface to enable +data communication towards WWAN. The driver also provides an interface to interact +with the MediaTek's modem via AT commands. + +Basic usage +=========== +MBIM & AT functions are inactive when unmanaged. The t7xx driver provides +WWAN port userspace interfaces representing MBIM & AT control channels and does +not play any role in managing their functionality. It is the job of a userspace +application to detect port enumeration and enable MBIM & AT functionalities. + +Examples of few such userspace applications are: + +- mbimcli (included with the libmbim [2] library), and +- Modem Manager [3] + +Management Applications to carry out below required actions for establishing +MBIM IP session: + +- open the MBIM control channel +- configure network connection settings +- connect to network +- configure IP network interface + +Management Applications to carry out below required actions for send an AT +command and receive response: + +- open the AT control channel using a UART tool or a special user tool + +Sysfs +===== +The driver provides sysfs interfaces to userspace. + +t7xx_mode +--------- +The sysfs interface provides userspace with access to the device mode, this interface +supports read and write operations. + +Device mode: + +- ``unknown`` represents that device in unknown status +- ``ready`` represents that device in ready status +- ``reset`` represents that device in reset status +- ``fastboot_switching`` represents that device in fastboot switching status +- ``fastboot_download`` represents that device in fastboot download status +- ``fastboot_dump`` represents that device in fastboot dump status + +Read from userspace to get the current device mode. + +:: + $ cat /sys/bus/pci/devices/${bdf}/t7xx_mode + +Write from userspace to set the device mode. + +:: + $ echo fastboot_switching > /sys/bus/pci/devices/${bdf}/t7xx_mode + +Management application development +================================== +The driver and userspace interfaces are described below. The MBIM protocol is +described in [1] Mobile Broadband Interface Model v1.0 Errata-1. + +MBIM control channel userspace ABI +---------------------------------- + +/dev/wwan0mbim0 character device +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver exposes an MBIM interface to the MBIM function by implementing +MBIM WWAN Port. The userspace end of the control channel pipe is a +/dev/wwan0mbim0 character device. Application shall use this interface for +MBIM protocol communication. + +Fragmentation +~~~~~~~~~~~~~ +The userspace application is responsible for all control message fragmentation +and defragmentation as per MBIM specification. + +/dev/wwan0mbim0 write() +~~~~~~~~~~~~~~~~~~~~~~~ +The MBIM control messages from the management application must not exceed the +negotiated control message size. + +/dev/wwan0mbim0 read() +~~~~~~~~~~~~~~~~~~~~~~ +The management application must accept control messages of up the negotiated +control message size. + +MBIM data channel userspace ABI +------------------------------- + +wwan0-X network device +~~~~~~~~~~~~~~~~~~~~~~ +The t7xx driver exposes IP link interface "wwan0-X" of type "wwan" for IP +traffic. Iproute network utility is used for creating "wwan0-X" network +interface and for associating it with MBIM IP session. + +The userspace management application is responsible for creating new IP link +prior to establishing MBIM IP session where the SessionId is greater than 0. + +For example, creating new IP link for a MBIM IP session with SessionId 1: + + ip link add dev wwan0-1 parentdev wwan0 type wwan linkid 1 + +The driver will automatically map the "wwan0-1" network device to MBIM IP +session 1. + +AT port userspace ABI +---------------------------------- + +/dev/wwan0at0 character device +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver exposes an AT port by implementing AT WWAN Port. +The userspace end of the control port is a /dev/wwan0at0 character +device. Application shall use this interface to issue AT commands. + +fastboot port userspace ABI +--------------------------- + +/dev/wwan0fastboot0 character device +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver exposes a fastboot protocol interface by implementing +fastboot WWAN Port. The userspace end of the fastboot channel pipe is a +/dev/wwan0fastboot0 character device. Application shall use this interface for +fastboot protocol communication. + +Please note that driver needs to be reloaded to export /dev/wwan0fastboot0 +port, because device needs a cold reset after enter ``fastboot_switching`` +mode. + +The MediaTek's T700 modem supports the 3GPP TS 27.007 [4] specification. + +References +========== +[1] *MBIM (Mobile Broadband Interface Model) Errata-1* + +- https://www.usb.org/document-library/ + +[2] *libmbim "a glib-based library for talking to WWAN modems and devices which +speak the Mobile Interface Broadband Model (MBIM) protocol"* + +- http://www.freedesktop.org/wiki/Software/libmbim/ + +[3] *Modem Manager "a DBus-activated daemon which controls mobile broadband +(2G/3G/4G/5G) devices and connections"* + +- http://www.freedesktop.org/wiki/Software/ModemManager/ + +[4] *Specification # 27.007 - 3GPP* + +- https://www.3gpp.org/DynaReport/27007.htm + +[5] *fastboot "a mechanism for communicating with bootloaders"* + +- https://android.googlesource.com/platform/system/core/+/refs/heads/main/fastboot/README.md |
