summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-02-06can: bittiming: can_fixup_bittiming(): use CAN_SYNC_SEG instead of 1Marc Kleine-Budde1-1/+1
Commit 1c47fa6b31c2 ("can: dev: add a helper function to calculate the duration of one bit") made the constant CAN_SYNC_SEG available in a header file. The magic number 1 in can_fixup_bittiming() represents the width of the sync segment, replace it by CAN_SYNC_SEG to make the code more readable. Link: https://lore.kernel.org/all/20230202110854.2318594-3-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-06can: bittiming(): replace open coded variants of can_bit_time()Marc Kleine-Budde2-5/+4
Commit 1c47fa6b31c2 ("can: dev: add a helper function to calculate the duration of one bit") added the helper function can_bit_time(). Replace open coded variants of can_bit_time() by the helper function. Link: https://lore.kernel.org/all/20230202110854.2318594-2-mkl@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02Merge patch series "can: peak_usb: Introduce configurable CAN channel ID"Marc Kleine-Budde7-31/+265
Lukas Magel <lukas.magel@posteo.net> says: This series of patches introduces the CAN channel ID for the PEAK USB CAN interfaces. The id can be read/written via ethtool and is exposed as a read-only attribute via sysfs. This allows users to set the id via ethtool and write udev rules to match against the sysfs attribute. Part of the patches were originally introduced by Stéphane Grosjean and were modified slightly. See the following threads for the original patches: * https://lore.kernel.org/linux-can/20220128150157.1222850-1-s.grosjean@peak-system.com * https://lore.kernel.org/linux-can/20211117150132.37056-1-s.grosjean@peak-system.com changes since v2: https://lore.kernel.org/all/20221030105939.87658-1-lukas.magel@posteo.net * Fix the issues raised on netdev * Rename user device ID to CAN channel ID to make the 1-to-N mapping between USB device and exposed CAN channels more obvious changes since v1: https://lore.kernel.org/all/20221022213535.8495-1-lukas.magel@posteo.net * Fix type of devid_le in ethtool peak_usb_(get|set)_eeprom * Fix signed-off tags Link: https://lore.kernel.org/all/20221213080309.9013-1-lukas.magel@posteo.net [mkl: added links] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: Reorder include directives alphabeticallyLukas Magel4-11/+12
The include directives in all source files are reordered alphabetically according to the names of the header files. Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-9-lukas.magel@posteo.net [mkl: move header changes from Patch 3 here] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: align CAN channel ID format in log with sysfs attributeLukas Magel1-2/+2
Previously, the CAN channel ID was printed to the kernel log in decimal upon connecting a new PEAK device. This behavior is inconsistent with the hexadecimal format of the CAN channel ID sysfs attribute. This patch updates the log message to output the id in hexadecimal. Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-8-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: export PCAN CAN channel ID as sysfs device attributeLukas Magel2-0/+44
This patch exports the CAN channel ID as a sysfs attribute. The CAN channel ID is a user-configurable u8/u32 identifier that can be set individually for each CAN interface of a PEAK USB device. Exporting the channel ID as a sysfs attribute allows users to easily read the ID and to write udev rules that can match against the ID. This is especially useful for PEAK USB devices that do not export a serial number at SUB level. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-7-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: add ethtool interface to user-configurable CAN channel identifierStephane Grosjean5-0/+101
This patch introduces 3 new functions implementing support for ethtool access to the CAN channel ID of all USB CAN network interfaces managed by the driver. With this patch, it is possible to read/write the CAN channel ID from/to the EEPROM via the ethtool interface. The CAN channel ID is a user-configurable device identifier that can be set individually for each CAN interface of a PEAK USB device. Depending on the device, the identifier has a length of 8 or 32 bit. The identifier is stored in the non-volatile memory of the device. The identifier of a CAN interface can be read/written as an 8 or 32 bit byte string in native (little-endian) byte order, where the length depends on the device type. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-6-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: replace unregister_netdev() with unregister_candev()Stephane Grosjean1-1/+1
This patch changes the call to unregister_netdev() in peak_usb_disconnect() with unregister_candev(). Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-5-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: allow flashing of the CAN channel IDStephane Grosjean5-0/+63
This patch adds callbacks that allow the user to set a new self-defined CAN channel ID to all USB - CAN/CANFD interfaces of PEAK-System managed by this driver, namely: - PCAN-USB - PCAN-USB FD - PCAN-USB Pro FD - PCAN-USB X6 - PCAN-Chip USB - PCAN-USB Pro The callback functions write the CAN channel ID to the non-volatile memory of the devices. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-4-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: add callback to read CAN channel ID of PEAK CAN-FD devicesStephane Grosjean2-6/+30
This patch adds a new function that allows to read the CAN channel ID from the non volatile memory of the USB CAN-FD PEAK devices. The CAN channel ID is a user-configurable u8/u32 identifier value that can be set individually for each PEAK CAN interface. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-3-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: peak_usb: rename device_id to CAN channel IDStephane Grosjean5-16/+17
The so-called "device id" is a user-defined identifier value that can be set individually for each CAN interface of a PEAK USB device. Contrary to a static serial number, the value can be changed by the user. With this ID, each CAN interface can be uniquely identified even if the USB device does not export a proper serial number or the USB device exports multiple CAN interfaces. In order to not confuse it with the device ID used by the USB core and emphasize the link to the CAN interface, the functions and variables for reading this user-defined value are renamed to CAN channel ID. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Lukas Magel <lukas.magel@posteo.net> Link: https://lore.kernel.org/all/20230116200932.157769-2-lukas.magel@posteo.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02Merge patch series "can: ems_pci: Add support for CPC-PCIe v3"Marc Kleine-Budde1-39/+115
Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> says: The CPC-PCIe v3 uses an Asix AX99100 instead of the discontinued PLX PCI9030 bridge chip. This patch series adds support for this card version and cleans some code styling issues. v1: https://lore.kernel.org/all/20230119154528.28425-1-uttenthaler@ems-wuensche.com Link: https://lore.kernel.org/all/20230120112616.6071-1-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Add myself as module authorGerhard Uttenthaler1-0/+1
Added myself as module author Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-9-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Deassert hardware resetGerhard Uttenthaler1-0/+8
The reset line from the Asix chip to the SJA1000 is asserted after boot up until it is deasserted by a register write Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-8-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Add IRQ enableGerhard Uttenthaler1-2/+9
Add IRQ enable Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-7-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Initialize CAN controller base addressesGerhard Uttenthaler1-2/+7
Add CAN controller base registers Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-6-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Add read/write register and post irq functionsGerhard Uttenthaler1-1/+23
Add functions to read and write SJA1000 registers and also the post irq routine Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-5-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Initialize BAR registersGerhard Uttenthaler1-9/+28
Fix the base register defines and their usage for all three card versions Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-4-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Add Asix AX99100 definitionsGerhard Uttenthaler1-0/+19
Add Asix AX99100 PCI IDs and add the v3 to the ems_pci_tbl. Add define for maximum CAN channel count Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-3-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: ems_pci: Fix code style, copyright and email addressGerhard Uttenthaler1-25/+20
Fix code style complained by checkpatch.pl, add Copyright and fix email address Signed-off-by: Gerhard Uttenthaler <uttenthaler@ems-wuensche.com> Link: https://lore.kernel.org/all/20230120112616.6071-2-uttenthaler@ems-wuensche.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02Merge patch series "can: rcar_canfd: Add support for R-Car V4H systems"Marc Kleine-Budde2-118/+123
Geert Uytterhoeven <geert+renesas@glider.be> says: This patch series adds support for the CAN-FD interface on the Renesas R-Car V4H (R8A779G0) SoC and support for CAN transceivers described as PHYs to the R-Car CAN-FD driver. It includes several fixes for issues (some minor) detected while adding the support and during testing. More details can be found in the individual patches. This has been tested on the Renesas White-Hawk development board using cansend, candump, and canfdtest: - Channel 0 uses an NXP TJR1443AT CAN transceiver, and works fine, - Channels 1-7 use Microchip MCP2558FD-H/SN CAN transceivers (not mounted for channels 4-7), which do not need explicit description. While channel 1 works fine, channels 2-3 do not seem to work. Hence despite the new fixes, the test results are similar to what Ulrich Hecht reported for R-Car V3U on the Falcon development board before, i.e. only channels 0 and 1 work (FTR, [2] does not help). Whether this is a CAN-FD driver issue, a pin control issue, an IP core issue, or an SoC integration issue is still to be seen... [1] https://lore.kernel.org/all/f53a1bcca637ceeafb04ce3540a605532d3bc34a.1674036164.git.geert+renesas@glider.be [2] commit e3e5bccc92446048 ("can: rcar_canfd: rcar_canfd_configure_afl_rules(): Fix Rx FIFO entry setting") in renesas-bsp/v5.10.147/rcar-5.2.0.rc3. Link: https://lore.kernel.org/all/cover.1674499048.git.geert+renesas@glider.be [mkl: applying patches 1...11 only] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Add helper variable devGeert Uytterhoeven1-44/+42
rcar_canfd_channel_probe() and rcar_canfd_probe() have many users of "pdev->dev". Introduce shorthands to simplify the code. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/2965edc7992ab54dc6c862910775f3466fca6b29.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Sort included header filesGeert Uytterhoeven1-11/+11
This may avoid conflicts when adding or removing files in the future. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/f7fa8090487c6e05b2c7f89542e0a1bd045356f1.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Fix R-Car Gen4 CFCC.CFTML field widthGeert Uytterhoeven1-1/+2
On R-Car Gen4 CAN_FD variants, the Common FIFO TX Message Buffer Link (CFTML) field in the Common FIFO Configuration / Control Register (CCFC) register is one bit wider than on older variants. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/9c37aaa799a2391be272dbaa474379cf9a7af147.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Fix R-Car Gen4 DCFG.DSJW field widthGeert Uytterhoeven1-2/+2
On R-Car Gen4 CAN_FD variants, the Data Bit Rate Resynchronization Jump Width Control (DSJW) field in the Channel n Data Bitrate Configuration Register (DCFG) register is one bit wider than on older variants. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/c4e8bc220bf87e6c7e375f7a2ce51e2aa89ea8a7.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Add support for R-Car Gen4Geert Uytterhoeven1-49/+50
Despite the name, R-Car V3U (R8A779A0) was the first member of the R-Car Gen4 family. Generalize the support for R-Car V3U to other SoCs in the R-Car Gen4 family by adding a family-specific compatible value, and by replacing all references to "V3U" by "Gen4". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/61f6f34eb7bcc62ff604add98f1bcd2d2584187d.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Abstract out DCFG address differencesGeert Uytterhoeven1-6/+2
Abstract the different addresses for the Channel n Data Bitrate Configuration Register (DCFG) in the definition of the register macro, like is already done for other register definitions, to simplify code accessing this register. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/13e02d710dac3ddef73aa4be2b995766db9b6b4d.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Fix R-Car V3U GAFLCFG field accessesGeert Uytterhoeven1-2/+2
Each Global Acceptance Filter List Configuration Register (GAFLCFG) contains two fields, and stores the number of channel rules for one channel pair. As R-Car V3U and later can have more than 2 channels, the field selection should be based on the LSB (even or odd) of the channel number, instead of on the full channel number. Fixes: 45721c406dcf50d4 ("can: rcar_canfd: Add support for r8a779a0 SoC") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/36bcf0ffb96d6aaed970751f9546b901af638bcf.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: rcar_canfd: Fix R-Car V3U CAN mode selectionGeert Uytterhoeven1-9/+10
When adding support for R-Car V3U, the Global FD Configuration register (CFDGFDCFG) and the Channel-specific CAN-FD Configuration Registers (CFDCmFDCFG) were mixed up. Use the correct register, and apply the selected CAN mode to all available channels. Annotate the corresponding register bits, to make it clear they do not exist on older variants. Fixes: 45721c406dcf50d4 ("can: rcar_canfd: Add support for r8a779a0 SoC") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/388ddf312917eb9f6cc460a481f68402a876f9b5.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02dt-bindings: can: renesas,rcar-canfd: Add transceiver supportGeert Uytterhoeven1-0/+4
Add support for describing CAN transceivers as PHYs. While simple CAN transceivers can do without, this is needed for CAN transceivers like NXP TJR1443 that need a configuration step (like pulling standby or enable lines), and/or impose a bitrate limit. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/1bd328b5c9c6cfa633b42af87550f4c7358a05c1.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02dt-bindings: can: renesas,rcar-canfd: Document R-Car V4H supportGeert Uytterhoeven1-0/+1
Document support for the CAN-FD Interface on the Renesas R-Car V4H (R8A779G0) SoC. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/d8158c78cc786c432df5a5e5bbad848b717aca71.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02dt-bindings: can: renesas,rcar-canfd: R-Car V3U is R-Car Gen4Geert Uytterhoeven1-4/+7
Despite the name, R-Car V3U is the first member of the R-Car Gen4 family. Hence generalize this by introducing a family-specific compatible value for R-Car Gen4. While at it, replace "both channels" by "all channels", as the numbers of channels may differ from two. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/4dea4b7dd76d4f859ada85f97094b7adeef5169f.1674499048.git.geert+renesas@glider.be Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: mcp251xfd: regmap: optimizing transfer size for CRC transfers size 1Thomas Kopp2-8/+36
For CRC transfers with size 1 it is more efficient to use the write_safe command instead of the write_crc command. This saves the length byte on the SPI transfer. changes since v1: https://lore.kernel.org/all/20230127124258.2764-1-thomas.kopp@microchip.com - change logic to remove 1 level of indention Link: https://lore.kernel.org/all/20230202141811.2581795-1-mkl@pengutronix.de Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: isotp: check CAN address family in isotp_bind()Oliver Hartkopp1-0/+3
Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field: bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the userspace should be notified about the wrong address family field content. Link: https://syzkaller.appspot.com/text?tag=CrashLog&x=11ff9d8c480000 Reported-by: syzbot+5aed6c3aaba661f5b917@syzkaller.appspotmail.com Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230104201844.13168-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02can: gw: give feedback on missing CGW_FLAGS_CAN_IIF_TX_OK flagOliver Hartkopp1-0/+7
To send CAN traffic back to the incoming interface a special flag has to be set. When creating a routing job for identical interfaces without this flag the rule is created but has no effect. This patch adds an error return value in the case that the CAN interfaces are identical but the CGW_FLAGS_CAN_IIF_TX_OK flag was not set. Reported-by: Jannik Hartung <jannik.hartung@tu-bs.de> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://lore.kernel.org/all/20230125055407.2053-1-socketcan@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-02-02octeontx2-af: Removed unnecessary debug messages.Sunil Goutham1-14/+4
NPC exact match feature is supported only on one silicon variant, removed debug messages which print that this feature is not available on all other silicon variants. Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20230201040301.1034843-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02virtio-net: fix possible unsigned integer overflowHeng Qi1-6/+9
When the single-buffer xdp is loaded and after xdp_linearize_page() is called, *num_buf becomes 0 and (*num_buf - 1) may overflow into a large integer in virtnet_build_xdp_buff_mrg(), resulting in unexpected packet dropping. Fixes: ef75cb51f139 ("virtio-net: build xdp_buff with multi buffers") Signed-off-by: Heng Qi <hengqi@linux.alibaba.com> Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20230131085004.98687-1-hengqi@linux.alibaba.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02netlink: provide an ability to set default extack messageLeon Romanovsky5-13/+20
In netdev common pattern, extack pointer is forwarded to the drivers to be filled with error message. However, the caller can easily overwrite the filled message. Instead of adding multiple "if (!extack->_msg)" checks before any NL_SET_ERR_MSG() call, which appears after call to the driver, let's add new macro to common code. [1] https://lore.kernel.org/all/Y9Irgrgf3uxOjwUm@unreal Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/6993fac557a40a1973dfa0095107c3d03d40bec1.1675171790.git.leon@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02neighbor: fix proxy_delay usage when it is zeroBrian Haley2-2/+20
When set to zero, the neighbor sysctl proxy_delay value does not cause an immediate reply for ARP/ND requests as expected, it instead causes a random delay between [0, U32_MAX). Looking at this comment from __get_random_u32_below() explains the reason: /* * This function is technically undefined for ceil == 0, and in fact * for the non-underscored constant version in the header, we build bug * on that. But for the non-constant case, it's convenient to have that * evaluate to being a straight call to get_random_u32(), so that * get_random_u32_inclusive() can work over its whole range without * undefined behavior. */ Added helper function that does not call get_random_u32_below() if proxy_delay is zero and just uses the current value of jiffies instead, causing pneigh_enqueue() to respond immediately. Also added definition of proxy_delay to ip-sysctl.txt since it was missing. Signed-off-by: Brian Haley <haleyb.dev@gmail.com> Link: https://lore.kernel.org/r/20230130171428.367111-1-haleyb.dev@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02Merge branch 'net-support-ipv4-big-tcp'Jakub Kicinski25-38/+130
Xin Long says: ==================== net: support ipv4 big tcp This is similar to the BIG TCP patchset added by Eric for IPv6: https://lwn.net/Articles/895398/ Different from IPv6, IPv4 tot_len is 16-bit long only, and IPv4 header doesn't have exthdrs(options) for the BIG TCP packets' length. To make it simple, as David and Paolo suggested, we set IPv4 tot_len to 0 to indicate this might be a BIG TCP packet and use skb->len as the real IPv4 total length. This will work safely, as all BIG TCP packets are GSO/GRO packets and processed on the same host as they were created; There is no padding in GSO/GRO packets, and skb->len - network_offset is exactly the IPv4 packet total length; Also, before implementing the feature, all those places that may get iph tot_len from BIG TCP packets are taken care with some new APIs: Patch 1 adds some APIs for iph tot_len setting and getting, which are used in all these places where IPv4 BIG TCP packets may reach in Patch 2-7, Patch 8 adds a GSO_TCP tp_status for af_packet users, and Patch 9 add new netlink attributes to make IPv4 BIG TCP independent from IPv6 BIG TCP on configuration, and Patch 10 implements this feature. Note that the similar change as in Patch 2-6 are also needed for IPv6 BIG TCP packets, and will be addressed in another patchset. The similar performance test is done for IPv4 BIG TCP with 25Gbit NIC and 1.5K MTU: No BIG TCP: for i in {1..10}; do netperf -t TCP_RR -H 192.168.100.1 -- -r80000,80000 -O MIN_LATENCY,P90_LATENCY,P99_LATENCY,THROUGHPUT|tail -1; done 168 322 337 3776.49 143 236 277 4654.67 128 258 288 4772.83 171 229 278 4645.77 175 228 243 4678.93 149 239 279 4599.86 164 234 268 4606.94 155 276 289 4235.82 180 255 268 4418.95 168 241 249 4417.82 Enable BIG TCP: ip link set dev ens1f0np0 gro_ipv4_max_size 128000 gso_ipv4_max_size 128000 for i in {1..10}; do netperf -t TCP_RR -H 192.168.100.1 -- -r80000,80000 -O MIN_LATENCY,P90_LATENCY,P99_LATENCY,THROUGHPUT|tail -1; done 161 241 252 4821.73 174 205 217 5098.28 167 208 220 5001.43 164 228 249 4883.98 150 233 249 4914.90 180 233 244 4819.66 154 208 219 5004.92 157 209 247 4999.78 160 218 246 4842.31 174 206 217 5080.99 Thanks for the feedback from Eric and David Ahern. ==================== Link: https://lore.kernel.org/r/cover.1674921359.git.lucien.xin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02net: add support for ipv4 big tcpXin Long5-22/+27
Similar to Eric's IPv6 BIG TCP, this patch is to enable IPv4 BIG TCP. Firstly, allow sk->sk_gso_max_size to be set to a value greater than GSO_LEGACY_MAX_SIZE by not trimming gso_max_size in sk_trim_gso_size() for IPv4 TCP sockets. Then on TX path, set IP header tot_len to 0 when skb->len > IP_MAX_MTU in __ip_local_out() to allow to send BIG TCP packets, and this implies that skb->len is the length of a IPv4 packet; On RX path, use skb->len as the length of the IPv4 packet when the IP header tot_len is 0 and skb->len > IP_MAX_MTU in ip_rcv_core(). As the API iph_set_totlen() and skb_ip_totlen() are used in __ip_local_out() and ip_rcv_core(), we only need to update these APIs. Also in GRO receive, add the check for ETH_P_IP/IPPROTO_TCP, and allows the merged packet size >= GRO_LEGACY_MAX_SIZE in skb_gro_receive(). In GRO complete, set IP header tot_len to 0 when the merged packet size greater than IP_MAX_MTU in iph_set_totlen() so that it can be processed on RX path. Note that by checking skb_is_gso_tcp() in API iph_totlen(), it makes this implementation safe to use iph->len == 0 indicates IPv4 BIG TCP packets. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02net: add gso_ipv4_max_size and gro_ipv4_max_size per deviceXin Long5-0/+64
This patch introduces gso_ipv4_max_size and gro_ipv4_max_size per device and adds netlink attributes for them, so that IPV4 BIG TCP can be guarded by a separate tunable in the next patch. To not break the old application using "gso/gro_max_size" for IPv4 GSO packets, this patch updates "gso/gro_ipv4_max_size" in netif_set_gso/gro_max_size() if the new size isn't greater than GSO_LEGACY_MAX_SIZE, so that nothing will change even if userspace doesn't realize the new netlink attributes. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02packet: add TP_STATUS_GSO_TCP for tp_statusXin Long2-0/+5
Introduce TP_STATUS_GSO_TCP tp_status flag to tell the af_packet user that this is a TCP GSO packet. When parsing IPv4 BIG TCP packets in tcpdump/libpcap, it can use tp_len as the IPv4 packet len when this flag is set, as iph tot_len is set to 0 for IPv4 BIG TCP packets. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02ipvlan: use skb_ip_totlen in ipvlan_get_L3_hdrXin Long1-1/+1
ipvlan devices calls netif_inherit_tso_max() to get the tso_max_size/segs from the lower device, so when lower device supports BIG TCP, the ipvlan devices support it too. We also should consider its iph tot_len accessing. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02cipso_ipv4: use iph_set_totlen in skbuff_setattrXin Long1-1/+1
It may process IPv4 TCP GSO packets in cipso_v4_skbuff_setattr(), so the iph->tot_len update should use iph_set_totlen(). Note that for these non GSO packets, the new iph tot_len with extra iph option len added may become greater than 65535, the old process will cast it and set iph->tot_len to it, which is a bug. In theory, iph options shouldn't be added for these big packets in here, a fix may be needed here in the future. For now this patch is only to set iph->tot_len to 0 when it happens. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02netfilter: use skb_ip_totlen and iph_totlenXin Long4-5/+5
There are also quite some places in netfilter that may process IPv4 TCP GSO packets, we need to replace them too. In length_mt(), we have to use u_int32_t/int to accept skb_ip_totlen() return value, otherwise it may overflow and mismatch. This change will also help us add selftest for IPv4 BIG TCP in the following patch. Note that we don't need to replace the one in tcpmss_tg4(), as it will return if there is data after tcphdr in tcpmss_mangle_packet(). The same in mangle_contents() in nf_nat_helper.c, it returns false when skb->len + extra > 65535 in enlarge_skb(). Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02net: sched: use skb_ip_totlen and iph_totlenXin Long2-2/+2
There are 1 action and 1 qdisc that may process IPv4 TCP GSO packets and access iph->tot_len, replace them with skb_ip_totlen() and iph_totlen() accordingly. Note that we don't need to replace the one in tcf_csum_ipv4(), as it will return for TCP GSO packets in tcf_csum_ipv4_tcp(). Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02openvswitch: use skb_ip_totlen in conntrackXin Long1-1/+1
IPv4 GSO packets may get processed in ovs_skb_network_trim(), and we need to use skb_ip_totlen() to get iph totlen. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Aaron Conole <aconole@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02bridge: use skb_ip_totlen in br netfilterXin Long2-3/+3
These 3 places in bridge netfilter are called on RX path after GRO and IPv4 TCP GSO packets may come through, so replace iph tot_len accessing with skb_ip_totlen() in there. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-02-02net: add a couple of helpers for iph tot_lenXin Long2-3/+21
This patch adds three APIs to replace the iph->tot_len setting and getting in all places where IPv4 BIG TCP packets may reach, they will be used in the following patches. Note that iph_totlen() will be used when iph is not in linear data of the skb. Signed-off-by: Xin Long <lucien.xin@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 02:16:53 +0300