- 30 Mar, 2021 21 commits
-
-
Wan Jiabing authored
linux/regmap.h has been included at line 13, so remove the duplicate one at line 14. Fixes: 67def4ef ("can: tcan4x5x: move regmap code into seperate file") Link: https://lore.kernel.org/r/20210323021026.140460-1-wanjiabing@vivo.comSigned-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Torin Cooper-Bennun authored
For peripheral devices, m_can sent skbs directly from a threaded irq instead of from a softirq context, breaking the tcan4x5x peripheral driver completely. This patch transitions the driver to use the rx-offload helper for peripherals, ensuring the skbs are sent from the correct context, with h/w timestamping to ensure correct ordering. Link: https://lore.kernel.org/r/20210308102427.63916-4-torin@maxiluxsystems.comSigned-off-by:
Torin Cooper-Bennun <torin@maxiluxsystems.com> [mkl: m_can_class_register(): update error handling] Signed-off-by:
-
Torin Cooper-Bennun authored
This is a prerequisite for transitioning the m_can driver to rx-offload, which works best with TX and RX timestamps. The timestamps provided by M_CAN are 16-bit, timed according to the nominal bit timing, and may be prescaled by a multiplier up to 16. We choose the highest prescalar so that the timestamp wraps every 2^20 bit times, or 209 ms at a bus speed of 5 Mbit/s. Timestamps will have a precision of 16 bit times. Link: https://lore.kernel.org/r/20210308102427.63916-3-torin@maxiluxsystems.comSigned-off-by:
-
Torin Cooper-Bennun authored
Add infrastucture to allow internal timestamps from the M_CAN to be configured and retrieved. Link: https://lore.kernel.org/r/20210308102427.63916-2-torin@maxiluxsystems.comSigned-off-by:
-
Xulin Sun authored
If the CAN net device has been successfully allocated, its private data structure is impossible to be empty, remove this redundant error return judgment. Link: https://lore.kernel.org/r/20210205072559.13241-2-xulin.sun@windriver.comSigned-off-by:
Xulin Sun <xulin.sun@windriver.com> Signed-off-by:
-
Stephane Grosjean authored
This patch adds "ONE-SHOT" mode support to the following CAN-USB PEAK-System GmbH interfaces: - PCAN-USB X6 - PCAN-USB FD - PCAN-USB Pro FD - PCAN-Chip USB - PCAN-USB Pro Signed-off-by:
Stephane Grosjean <s.grosjean@peak-system.com> [mkl: split into two patches] Signed-off-by:
-
Stephane Grosjean authored
This patch makes it possible to specifically flash the LED of a CAN port of the CAN-USB interfaces of PEAK-System. Link: https://lore.kernel.org/r/20210309122141.3276927-1-mkl@pengutronix.deSigned-off-by:
-
Stephane Grosjean authored
This patch replaces the plain integers used for flags in pcan_usb_pro_encode_msg() by macros which are already defined. Link: https://lore.kernel.org/r/20210309082128.23125-4-s.grosjean@peak-system.comSigned-off-by:
-
Arnd Bergmann authored
struct ucan_message_in contains member with 4-byte alignment but is itself marked as unaligned, which triggers a warning: drivers/net/can/usb/ucan.c:249:1: warning: alignment 1 of 'struct ucan_message_in' is less than 4 [-Wpacked-not-aligned] Mark the outer structure to have the same alignment as the inner one. Link: https://lore.kernel.org/r/20210204162625.3099392-1-arnd@kernel.orgSigned-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Michal Simek authored
Use already prepared dev_err_probe() introduced by commit a787e540 ("driver core: add device probe log helper"). It simplifies EPROBE_DEFER handling. Also unify message format for similar error cases. Link: https://lore.kernel.org/r/91af0945ed7397b08f1af0c829450620bd92b804.1612442564.git.michal.simek@xilinx.comSigned-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Marc Kleine-Budde authored
On ARCHs without IOMEM support the grcan driver fails to link due to missing iomem functionality. This patch adds the missing Kconfig dependency to HAS_IOMEM. Link: https://lore.kernel.org/r/20210309140424.3331010-1-mkl@pengutronix.deReported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Vincent Mailhol authored
Add three macro to simplify the readability of big bit timing numbers: - CAN_KBPS: kilobits per second (one thousand) - CAN_MBPS: megabits per second (one million) - CAN_MHZ: megahertz per second (one million) Example: u32 bitrate_max = 8 * CAN_MBPS; struct can_clock clock = {.freq = 80 * CAN_MHZ}; instead of: u32 bitrate_max = 8000000; struct can_clock clock = {.freq = 80000000}; Apply the new macro to driver/net/can/dev/bittiming.c. Link: https://lore.kernel.org/r/20210306054040.76483-1-mailhol.vincent@wanadoo.frSigned-off-by:Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by:
-
Vincent Mailhol authored
The logic for the tdco calculation is to just reuse the normal sample point: tdco = sp. Because the sample point is expressed in tenth of percent and the tdco is expressed in time quanta, a conversion is needed. At the end, ssp = tdcv + tdco = tdcv + sp. Another popular method is to set tdco to the middle of the bit: tdc->tdco = can_bit_time(dbt) / 2 During benchmark tests, we could not find a clear advantages for one of the two methods. The tdco calculation is triggered each time the data_bittiming is changed so that users relying on automated calculation can use the netlink interface the exact same way without need of new parameters. For example, a command such as: ip link set canX type can bitrate 500000 dbitrate 4000000 fd on would trigger the calculation. The user using CONFIG_CAN_CALC_BITTIMING who does not want automated calculation needs to manually set tdco to zero. For example with: ip link set canX type can tdco 0 bitrate 500000 dbitrate 4000000 fd on (if the tdco parameter is provided in a previous command, it will be overwritten). If tdcv is set to zero (default), it is automatically calculated by the transiver for each frame. As such, there is no code in the kernel to calculate it. tdcf has no automated calculation functions because we could not figure out a formula for this parameter. Link: https://lore.kernel.org/r/20210224002008.4158-6-mailhol.vincent@wanadoo.frSigned-off-by: -
Vincent Mailhol authored
Fix the warning triggered by having an '=' at the beginning of the line by moving it back to the previous line. Also replace all indentations with a single space so that future entries can be more easily added. Extract of ./scripts/checkpatch.pl -f drivers/net/can/dev/netlink.c: CHECK: Assignment operator '=' should be on the previous line + [IFLA_CAN_BITTIMING_CONST] + = { .len = sizeof(struct can_bittiming_const) }, CHECK: Assignment operator '=' should be on the previous line + [IFLA_CAN_DATA_BITTIMING] + = { .len = sizeof(struct can_bittiming) }, CHECK: Assignment operator '=' should be on the previous line + [IFLA_CAN_DATA_BITTIMING_CONST] + = { .len = sizeof(struct can_bittiming_const) }, Link: https://lore.kernel.org/r/20210224002008.4158-4-mailhol.vincent@wanadoo.frSigned-off-by: -
Vincent Mailhol authored
Save eight bytes of holes on x86-64 architectures by reordering struct can_priv members. Before: $ pahole -C can_priv drivers/net/can/dev/dev.o struct can_priv { struct net_device * dev; /* 0 8 */ struct can_device_stats can_stats; /* 8 24 */ struct can_bittiming bittiming; /* 32 32 */ /* --- cacheline 1 boundary (64 bytes) --- */ struct can_bittiming data_bittiming; /* 64 32 */ const struct can_bittiming_const * bittiming_const; /* 96 8 */ const struct can_bittiming_const * data_bittiming_const; /* 104 8 */ struct can_tdc tdc; /* 112 12 */ /* XXX 4 bytes hole, try to pack */ /* --- cacheline 2 boundary (128 bytes) --- */ const struct can_tdc_const * tdc_const; /* 128 8 */ const u16 * termination_const; /* 136 8 */ unsigned int termination_const_cnt; /* 144 4 */ u16 termination; /* 148 2 */ /* XXX 2 bytes hole, try to pack */ const u32 * bitrate_const; /* 152 8 */ unsigned int bitrate_const_cnt; /* 160 4 */ /* XXX 4 bytes hole, try to pack */ const u32 * data_bitrate_const; /* 168 8 */ unsigned int data_bitrate_const_cnt; /* 176 4 */ u32 bitrate_max; /* 180 4 */ struct can_clock clock; /* 184 4 */ enum can_state state; /* 188 4 */ /* --- cacheline 3 boundary (192 bytes) --- */ u32 ctrlmode; /* 192 4 */ u32 ctrlmode_supported; /* 196 4 */ u32 ctrlmode_static; /* 200 4 */ int restart_ms; /* 204 4 */ struct delayed_work restart_work; /* 208 168 */ /* XXX last struct has 4 bytes of padding */ /* --- cacheline 5 boundary (320 bytes) was 56 bytes ago --- */ int (*do_set_bittiming)(struct net_device *); /* 376 8 */ /* --- cacheline 6 boundary (384 bytes) --- */ int (*do_set_data_bittiming)(struct net_device *); /* 384 8 */ int (*do_set_mode)(struct net_device *, enum can_mode); /* 392 8 */ int (*do_set_termination)(struct net_device *, u16); /* 400 8 */ int (*do_get_state)(const struct net_device *, enum can_state *); /* 408 8 */ int (*do_get_berr_counter)(const struct net_device *, struct can_berr_counter *); /* 416 8 */ unsigned int echo_skb_max; /* 424 4 */ /* XXX 4 bytes hole, try to pack */ struct sk_buff * * echo_skb; /* 432 8 */ /* size: 440, cachelines: 7, members: 31 */ /* sum members: 426, holes: 4, sum holes: 14 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 56 bytes */ }; After: $ pahole -C can_priv drivers/net/can/dev/dev.o struct can_priv { struct net_device * dev; /* 0 8 */ struct can_device_stats can_stats; /* 8 24 */ const struct can_bittiming_const * bittiming_const; /* 32 8 */ const struct can_bittiming_const * data_bittiming_const; /* 40 8 */ struct can_bittiming bittiming; /* 48 32 */ /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ struct can_bittiming data_bittiming; /* 80 32 */ const struct can_tdc_const * tdc_const; /* 112 8 */ struct can_tdc tdc; /* 120 12 */ /* --- cacheline 2 boundary (128 bytes) was 4 bytes ago --- */ unsigned int bitrate_const_cnt; /* 132 4 */ const u32 * bitrate_const; /* 136 8 */ const u32 * data_bitrate_const; /* 144 8 */ unsigned int data_bitrate_const_cnt; /* 152 4 */ u32 bitrate_max; /* 156 4 */ struct can_clock clock; /* 160 4 */ unsigned int termination_const_cnt; /* 164 4 */ const u16 * termination_const; /* 168 8 */ u16 termination; /* 176 2 */ /* XXX 2 bytes hole, try to pack */ enum can_state state; /* 180 4 */ u32 ctrlmode; /* 184 4 */ u32 ctrlmode_supported; /* 188 4 */ /* --- cacheline 3 boundary (192 bytes) --- */ u32 ctrlmode_static; /* 192 4 */ int restart_ms; /* 196 4 */ struct delayed_work restart_work; /* 200 168 */ /* XXX last struct has 4 bytes of padding */ /* --- cacheline 5 boundary (320 bytes) was 48 bytes ago --- */ int (*do_set_bittiming)(struct net_device *); /* 368 8 */ int (*do_set_data_bittiming)(struct net_device *); /* 376 8 */ /* --- cacheline 6 boundary (384 bytes) --- */ int (*do_set_mode)(struct net_device *, enum can_mode); /* 384 8 */ int (*do_set_termination)(struct net_device *, u16); /* 392 8 */ int (*do_get_state)(const struct net_device *, enum can_state *); /* 400 8 */ int (*do_get_berr_counter)(const struct net_device *, struct can_berr_counter *); /* 408 8 */ unsigned int echo_skb_max; /* 416 4 */ /* XXX 4 bytes hole, try to pack */ struct sk_buff * * echo_skb; /* 424 8 */ /* size: 432, cachelines: 7, members: 31 */ /* sum members: 426, holes: 2, sum holes: 6 */ /* paddings: 1, sum paddings: 4 */ /* last cacheline: 48 bytes */ }; Link: https://lore.kernel.org/r/20210224002008.4158-3-mailhol.vincent@wanadoo.frSigned-off-by: -
Vincent Mailhol authored
At high bit rates, the propagation delay from the TX pin to the RX pin of the transceiver causes measurement errors: the sample point on the RX pin might occur on the previous bit. This issue is addressed in ISO 11898-1 section 11.3.3 "Transmitter delay compensation" (TDC). This patch adds two new structures: can_tdc and can_tdc_const in order to implement this TDC. The structures are then added to can_priv. A controller supports TDC if an only if can_priv::tdc_const is not NULL. TDC is active if and only if: - fd flag is on - can_priv::tdc.tdco is not zero. It is the driver responsibility to check those two conditions are met. No new controller modes are introduced (i.e. no CAN_CTRL_MODE_TDC) in order not to be redundant with above logic. The names of the parameters are chosen to match existing CAN controllers specification. References: - Bosch C_CAN FD8: https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/c_can_fd8/users_manual_c_can_fd8_r210_1.pdf - Microchip CAN FD Controller Module: http://ww1.microchip.com/downloads/en/DeviceDoc/MCP251XXFD-CAN-FD-Controller-Module-Family-Reference-Manual-20005678B.pdf - SAM E701/S70/V70/V71 Family: https://www.mouser.com/datasheet/2/268/60001527A-1284321.pdf Link: https://lore.kernel.org/r/20210224002008.4158-2-mailhol.vincent@wanadoo.frSigned-off-by:
-
Marc Kleine-Budde authored
In order to implement byte queue limits (bql) in CAN drivers, the length of the CAN frame needs to be passed into the networking stack even if the transmission failed for some reason. To avoid to calculate this length twice, extend can_free_echo_skb() to return that value. Convert all users of this function, too. This patch is the natural extension of commit: | 9420e1d4 ("can: dev: can_get_echo_skb(): extend to return can | frame length") Link: https://lore.kernel.org/r/20210319142700.305648-3-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
can: dev: can_free_echo_skb(): don't crash the kernel if can_priv::echo_skb is accessed out of bounds A out of bounds access to "struct can_priv::echo_skb" leads to a kernel crash. Better print a sensible warning message instead and try to recover. This patch is similar to: | e7a6994d ("can: dev: __can_get_echo_skb(): Don't crash the kernel | if can_priv::echo_skb is accessed out of bounds") Link: https://lore.kernel.org/r/20210319142700.305648-2-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
So far the creation of the TX echo skb was optional and can be controlled by the local sender of a CAN frame. It turns out that the TX echo CAN skb can be piggybacked to carry information in the driver from the TX- to the TX-complete handler. Several drivers already use the return value of can_get_echo_skb() (which is the length of the data field in the CAN frame) for their number of transferred bytes statistics. The statistics are not working if CAN echo skbs are disabled. Another use case is to calculate and set the CAN frame length on the wire, which is needed for BQL support in both the TX and TX-completion handler. For now in can_put_echo_skb(), which is called from the TX handler, the skb carrying the CAN frame is discarded if no TX echo is requested, leading to the above illustrated problems. This patch changes the can_put_echo_skb() function, so that the echo skb is always generated. If the sender requests no echo, the echo skb is consumed in __can_get_echo_skb() without being passed into the RX handler of the networking stack, but the CAN data length and CAN frame length information is properly returned. Link: https://lore.kernel.org/r/20210309211904.3348700-1-mkl@pengutronix.deSigned-off-by:
-
Pankaj Sharma authored
Update Chandrasekar Ramakrishnan as maintainer for mcan mmio device driver as I will be moving to a different role. Signed-off-by:
Pankaj Sharma <pankj.sharma@samsung.com> Signed-off-by:
-
Marc Kleine-Budde authored
Dan Murphy's email address at ti.com doesn't work anymore, mails bounce with: | 550 Invalid recipient <dmurphy@ti.com> (#5.1.1) For now remove all CAN related entries of Dan from the Maintainers file. Link: https://lore.kernel.org/r/20210228094218.40015-1-mkl@pengutronix.deSigned-off-by:
-
- 29 Mar, 2021 19 commits
-
-
Haiyang Zhang authored
Add error handling in case of failure to send switching data path message to the host. Reported-by:
Shachar Raindel <shacharr@microsoft.com> Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
tcp_min_tso_segs is now stored in u8, so max value is 255. 255 limit is enforced by proc_dou8vec_minmax(). We can therefore remove the gso_max_segs variable. Fixes: 47996b489bdc ("tcp: convert elligible sysctls to u8") Signed-off-by:Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding prior dev_hold(). - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. Fixes: 919067cc ("net: add CONFIG_PCPU_DEV_REFCNT") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Eric Dumazet authored
After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding prior dev_hold(). - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. Therefore, we need to move dev_hold() call from vti6_tnl_create2() to vti6_dev_init_gen() [1] WARNING: CPU: 0 PID: 15951 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Modules linked in: CPU: 0 PID: 15951 Comm: syz-executor.3 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58 RSP: 0018:ffffc90001eaef28 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520003d5dd7 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff88801bb1c568 R13: ffff88801f69e800 R14: 00000000ffffffff R15: ffff888050889d40 FS: 00007fc79314e700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1c1ff47108 CR3: 0000000020fd5000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] dev_put include/linux/netdevice.h:4135 [inline] vti6_dev_uninit+0x31a/0x360 net/ipv6/ip6_vti.c:297 register_netdevice+0xadf/0x1500 net/core/dev.c:10308 vti6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_vti.c:190 vti6_newlink+0x9d/0xd0 net/ipv6/ip6_vti.c:1020 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x331/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmmsg+0x195/0x470 net/socket.c:2490 __do_sys_sendmmsg net/socket.c:2519 [inline] __se_sys_sendmmsg net/socket.c:2516 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2516 Signed-off-by:
-
Eric Dumazet authored
After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1] Issue here is that: - all dev_put() should be paired with a corresponding dev_hold(), and vice versa. - A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0. Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon. ip6_gre for example (among others problematic drivers) has to use dev_hold() in ip6gre_tunnel_init_common() instead of from ip6gre_newlink_common(), covering both ip6gre_tunnel_init() and ip6gre_tap_init()/ Note that ip6gre_tunnel_init_common() is not called from ip6erspan_tap_init() thus we also need to add a dev_hold() there, as ip6erspan_tunnel_uninit() does call dev_put() [1] refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 0 PID: 8422 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Modules linked in: CPU: 1 PID: 8422 Comm: syz-executor854 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31 Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58 RSP: 0018:ffffc900018befd0 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88801ef19c40 RSI: ffffffff815c51f5 RDI: fffff52000317dec RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff888018cf4568 R13: ffff888018cf4c00 R14: ffff8880228f2000 R15: ffffffff8d659b80 FS: 00000000014eb300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d7bf2b3138 CR3: 0000000014933000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_dec include/linux/refcount.h:344 [inline] refcount_dec include/linux/refcount.h:359 [inline] dev_put include/linux/netdevice.h:4135 [inline] ip6gre_tunnel_uninit+0x3d7/0x440 net/ipv6/ip6_gre.c:420 register_netdevice+0xadf/0x1500 net/core/dev.c:10308 ip6gre_newlink_common.constprop.0+0x158/0x410 net/ipv6/ip6_gre.c:1984 ip6gre_newlink+0x275/0x7a0 net/ipv6/ip6_gre.c:2017 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 Fixes: 919067cc ("net: add CONFIG_PCPU_DEV_REFCNT") Signed-off-by:
-
Jon Maloy authored
We fix a warning from the htmldoc tool and an indentation error reported by smatch. There are no functional changes in this commit. Signed-off-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2021-03-29 This series contains updates to igc driver only. Andre Guedes says: Add XDP support for the igc driver. The approach implemented by this series follows the same approach implemented in other Intel drivers as much as possible for the sake of consistency. The series is organized in two parts. In the first part, i.e. patches from 1 to 4, igc_main.c and igc_ptp.c code is refactored in preparation for landing the XDP support, which is introduced in the second part (patches from 5 to 8). As far as code organization is concerned, XDP-related helpers are defined in a new file, igc_xdp.c, and are called by igc_main.c. The features added by this series have been tested with the samples provided in samples/bpf/: xdp1, xdp2, xdp_redirect_cpu, and xdp_redirect_map. Upcoming series will add support of UMEM and zero-copy features from AF_XDP. ==================== Signed-off-by: -
Loic Poulain authored
MBIM protocol makes the mhi network interface asymmetric, ingress data received from MHI is MBIM protocol, possibly containing multiple aggregated IP packets, while egress data received from network stack is IP protocol. This changes allows a 'protocol' to specify its own MRU, that when specified is used to allocate MHI RX buffers (skb). For MBIM, Set the default MTU to 1500, which is the usual network MTU for WWAN IP packets, and MRU to 3.5K (for allocation efficiency), allowing skb to fit in an usual 4K page (including padding, skb_shared_info, ...). Signed-off-by:
Loic Poulain <loic.poulain@linaro.org> Signed-off-by:
-
Loic Poulain authored
Currently, if skb is non-linear, due to MHI skb chaining, it is linearized in MBIM RX handler prior MBIM decoding, causing extra allocation and copy that can be as large as the maximum MBIM frame size (32K). This change introduces MBIM decoding for non-linear skb, allowing to process 'large' non-linear MBIM packets without skb linearization. The IP packets are simply extracted from the MBIM frame using the skb_copy_bits helper. Signed-off-by:
-
Colin Ian King authored
The variable res is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Petr Machata authored
Add a document describing the principles behind resilient next-hop groups, and some notes about how to configure and offload them. Suggested-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Yang Yingliang authored
Fix the following make W=1 kernel build warning: drivers/net/mdio.c:95: warning: expecting prototype for mdio_link_ok(). Prototype was for mdio45_links_ok() instead Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Yang Yingliang authored
Fix the following make W=1 kernel build warning: drivers/net/bonding/bond_main.c:982: warning: expecting prototype for change_active_interface(). Prototype was for bond_change_active_slave() instead Reported-by:
-
Yang Yingliang authored
Fix the following make W=1 kernel build warning: drivers/net/phy/mdio-boardinfo.c:63: warning: expecting prototype for mdio_register_board_info(). Prototype was for mdiobus_register_board_info() instead Reported-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Two sampling fixes This patchset fixes two bugs in recent sampling submissions. The first fix, in patch #3, prevents matchall rules with sample action to be added in front of flower rules on egress. Patches #1-#2 are preparations meant at avoiding similar bugs in the future. Patch #4 is a selftest. The second fix, in patch #5, prevents sampling from being enabled on a port if already enabled. Patch #6 is a selftest. ==================== Signed-off-by: -
Ido Schimmel authored
Test that two sampling rules cannot be configured on the same port with the same trigger. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
-
Ido Schimmel authored
The per-port sampling triggers (i.e., ingress / egress) cannot be enabled twice. Meaning, the below configuration will not result in packets being sampled twice: # tc filter add dev swp1 ingress matchall skip_sw action sample rate 100 group 1 # tc filter add dev swp1 ingress matchall skip_sw action sample rate 100 group 1 Therefore, reject such configurations. Fixes: 90f53c53 ("mlxsw: spectrum: Start using sampling triggers hash table") Signed-off-by:
-
Ido Schimmel authored
The driver can only offload matchall rules that do not match on a protocol. Test that matchall rules that match on a protocol are vetoed. Signed-off-by:
-
Ido Schimmel authored
Perform the priority check earlier in the function instead of repeating it for every action. This fixes a bug that allowed matchall rules with sample action to be added in front of flower rules on egress. Fixes: 54d0e963 ("mlxsw: spectrum_matchall: Add support for egress sampling") Signed-off-by:
-
