- 02 Feb, 2023 40 commits
-
-
Lukas Magel authored
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>
-
Lukas Magel authored
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 authored
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:
-
Stephane Grosjean authored
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 authored
This patch changes the call to unregister_netdev() in peak_usb_disconnect() with unregister_candev(). Signed-off-by:
-
Stephane Grosjean authored
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 authored
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 authored
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:
-
Marc Kleine-Budde authored
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.comSigned-off-by:
-
Gerhard Uttenthaler authored
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.comSigned-off-by:
-
Gerhard Uttenthaler authored
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 authored
Add IRQ enable Signed-off-by:
-
Gerhard Uttenthaler authored
Add CAN controller base registers Signed-off-by:
-
Gerhard Uttenthaler authored
Add functions to read and write SJA1000 registers and also the post irq routine Signed-off-by:
-
Gerhard Uttenthaler authored
Fix the base register defines and their usage for all three card versions Signed-off-by:
-
Gerhard Uttenthaler authored
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 authored
Fix code style complained by checkpatch.pl, add Copyright and fix email address Signed-off-by:
-
Marc Kleine-Budde authored
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: -
Geert Uytterhoeven authored
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.beSigned-off-by:
-
Geert Uytterhoeven authored
This may avoid conflicts when adding or removing files in the future. Signed-off-by:
-
Geert Uytterhoeven authored
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 authored
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 authored
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 authored
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 authored
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: 45721c40 ("can: rcar_canfd: Add support for r8a779a0 SoC") Signed-off-by:
-
Geert Uytterhoeven authored
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: 45721c40 ("can: rcar_canfd: Add support for r8a779a0 SoC") Signed-off-by:
-
Geert Uytterhoeven authored
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:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/all/1bd328b5c9c6cfa633b42af87550f4c7358a05c1.1674499048.git.geert+renesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
Document support for the CAN-FD Interface on the Renesas R-Car V4H (R8A779G0) SoC. Signed-off-by:
-
Geert Uytterhoeven authored
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:
-
Thomas Kopp authored
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.deSigned-off-by:
Thomas Kopp <thomas.kopp@microchip.com> Signed-off-by:
-
Oliver Hartkopp authored
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.netSigned-off-by:
-
Oliver Hartkopp authored
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:
-
Sunil Goutham authored
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.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Heng Qi authored
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: ef75cb51 ("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.comSigned-off-by:
-
Leon Romanovsky authored
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@unrealReviewed-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
-
Brian Haley authored
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.comSigned-off-by:
-
Jakub Kicinski authored
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.comSigned-off-by:
-
Xin Long authored
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:
-
Xin Long authored
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 authored
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:
-
