- 27 Sep, 2021 22 commits
-
-
Leon Romanovsky authored
Move devlink_registration routine to be the last command, when the device is fully initialized. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Move devlink registration to be the last command in device activation, so it opens the driver to accept such devlink commands from the user when it is fully initialized. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Move devlink_register to be the last command in the initialization sequence. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
The liquidio driver is broken by design. It initialize PCI devices in separate delayed works. It causes to the situation where device lock is dropped during initialize and remove sequences. That lock is part of driver/core and needed to protect from races during init, destroy and bus invocations. In addition to lack of locking protection, it has incorrect order of destroy flows and very questionable synchronization scheme based on atomic_t. This change doesn't fix that driver but makes sure that rest of the netdev subsystem doesn't suffer from such basic protection by adding device_lock over devlink_*() APIs and by moving devlink_register() to be last command in setup_nic_devices(). Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
Move devlink_register() to be last command in devlink configuration sequence, so no user space access will be possible till devlink instance is fully operable. As part of this change, the devlink_params_publish call is removed as not needed. This change fixes forgotten devlink_params_unpublish() too. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Leon Romanovsky authored
The devlink core code notified users about add/remove objects without relation if this object can be accessible or not. In this patch we unify such user visible notifications in one place. Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
clang-14 does not like the custom offsetof() macro in vsc7326: drivers/net/ethernet/chelsio/cxgb/vsc7326.c:597:3: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] HW_STAT(RxUnicast, RxUnicastFramesOK), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/chelsio/cxgb/vsc7326.c:594:56: note: expanded from macro 'HW_STAT' { reg, (&((struct cmac_statistics *)NULL)->stat_name) - (u64 *)NULL } Rewrite this to use the version provided by the kernel. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
gcc-10 and later warn about a theoretical array overrun when accessing priv->int_name_rx_irq[i] with an out of bounds value of 'i': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_request_irq_multi_msi': drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3528:17: error: 'snprintf' argument 4 may overlap destination object 'dev' [-Werror=restrict] 3528 | snprintf(int_name, int_name_len, "%s:%s-%d", dev->name, "tx", i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3404:60: note: destination object referenced by 'restrict'-qualified argument 1 was declared here 3404 | static int stmmac_request_irq_multi_msi(struct net_device *dev) | ~~~~~~~~~~~~~~~~~~~^~~ The warning is a bit strange since it's not actually about the array bounds but rather about possible string operations with overlapping arguments, but it's not technically wrong. Avoid the warning by adding an extra bounds check. Fixes: 8532f613 ("net: stmmac: introduce MSI Interrupt routines for mac, safety, RX & TX") Link: https://lore.kernel.org/all/20210421134743.3260921-1-arnd@kernel.org/Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Christian Lamparter authored
of_get_mac_address() reads the same "local-mac-address" property. ... But goes above and beyond by checking the MAC value properly. printk+message seems outdated too, so let's put dev_err in the queue. Signed-off-by: Christian Lamparter <chunkeey@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Yang Li authored
Use resource_size function on resource object instead of explicit computation. Clean up coccicheck warning: ./drivers/net/ethernet/microchip/sparx5/sparx5_main.c:237:19-22: ERROR: Missing resource_size with iores [ idx ] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Replacing kmalloc/kfree/dma_map_single/dma_unmap_single() with dma_alloc_coherent/dma_free_coherent() helps to reduce code size, and simplify the code, and coherent DMA will not clear the cache every time. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mianhan Liu authored
tcp_nv.c hasn't use any macro or function declared in mm.h. Thus, these files can be removed from tcp_nv.c safely without affecting the compilation of the net module. Signed-off-by: Mianhan Liu <liumh1@shanghaitech.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Use dma_xxx_xxx() instead of pci_xxx_xxx(), because the pci function wrappers are not called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Use dma_alloc_coherent() instead of pci_alloc_consistent(), because only dma_alloc_coherent() is called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Use dma_map_single() instead of pci_map_single(), because the pci function wrappers are not called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Use dma_map_single() instead of pci_map_single(), because only dma_map_single() is called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cai Huoqing authored
Use dma_xxx_xxx() instead of pci_xxx_xxx(), because the pci function wrappers are not called here. Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Commit 3765996e ("napi: fix race inside napi_enable") fixed an ordering bug in napi_enable() and made the napi_enable() diverge from napi_disable(). The state transitions done on disable are not symmetric to enable. There is no known bug in napi_disable() this is just refactoring. Eric suggests we can also replace msleep(1) with a more opportunistic usleep_range(). Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Min Li authored
rsmu (Renesas Synchronization Management Unit ) driver is located in drivers/mfd and responsible for creating multiple devices including clockmatrix phc, which will then use the exposed regmap and mutex handle to access i2c/spi bus. Signed-off-by: Min Li <min.li.xe@renesas.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
The purpose of this test is to verify that after a short activity passes, the reported time is reasonable: not zero (which could be reported by mistake), and not something outrageous (which would be indicative of an issue in used units). However, the idle time is reported in units of clock_t, or hundredths of second. If the initial sequence of commands is very quick, it is possible that the idle time is reported as just flat-out zero. When this test was recently enabled in our nightly regression, we started seeing spurious failures for exactly this reason. Therefore buffer the delay leading up to the test with a sleep, to make sure there is no legitimate way of reporting 0. Signed-off-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 26 Sep, 2021 3 commits
-
-
David S. Miller authored
Kiran Kumar K says: ==================== adding KPU profile changes for GTPU and custom Adding changes to limit the KPU processing for GTPU headers to parse packet up to L4 and added changes to variable length headers to parse LA as part of PKIND action. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kiran Kumar K authored
Optimized KPU1 entry processing for variable-length custom L2 headers of size 24B, 90B by - Moving LA LTYPE parsing for 24B and 90B headers to PKIND. - Removing LA flags assignment for 24B and 90B headers. - Reserving a PKIND 55 to parse variable length headers. Also, new mailbox(NPC_SET_PKIND) added to configure PKIND with corresponding variable-length offset, mask, and shift count (NPC_AF_KPUX_ENTRYX_ACTION0). Signed-off-by: Kiran Kumar K <kirankumark@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kiran Kumar K authored
With current KPU profile, while parsing GTPU packets, GTPU payload is also being parsed and GTPU PDU payload is being treated as IPV4 data, which is not correct. In case of GTPU packets, parsing should be stopped after identifying the GTPU. Adding changes to limit KPU profile parsing for GTPU payload. Signed-off-by: Kiran Kumar K <kirankumark@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 25 Sep, 2021 7 commits
-
-
David S. Miller authored
Mat Martineau says: ==================== mptcp: Miscellaneous fixes Here are five changes we've collected and tested in the mptcp-tree: Patch 1 changes handling of the MPTCP-level snd_next value during the recovery phase after a subflow link failure. Patches 2 and 3 are some small refactoring changes to replace some open-coded bits. Patch 4 removes an unused field in struct mptcp_sock. Patch 5 restarts the MPTCP retransmit timer when there is not-yet-transmitted data to send and all previously sent data has been acknowledged. This prevents some sending stalls. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
The retransmit head will be NULL in case there is no in-flight data (meaning all data injected into network has been acked). In that case the retransmit timer is stopped. This is only correct if there is no more pending, not-yet-sent data. If there is, the retransmit timer needs to set the PENDING bit again so that mptcp tries to send the remaining (new) data once a subflow can accept more data. Also, mptcp_subflow_get_retrans() has to be called unconditionally. This function checks for subflows that have become unresponsive and marks them as stale, so in the case where the rtx queue is empty, subflows will never be marked stale which prevents available backup subflows from becoming eligible for transmit. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/226Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
The update on recovery is not correct. msk->tx_pending_data += msk->snd_nxt - rtx_head->data_seq; will update tx_pending_data multiple times when a subflow is declared stale while earlier recovery is still in progress. This means that tx_pending_data will still be positive even after all data as has been transmitted. Rather than fix it, remove this field: there are no consumers. The outstanding data byte count can be computed either via "msk->write_seq - rtx_head->data_seq" or "msk->write_seq - msk->snd_una". The latter is more recent/accurate estimate as rtx_head adjustment is deferred until mptcp lock can be acquired. Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Paolo Abeni authored
We have a few more places where the mptcp code duplicates lockdep_assert_held_once(). Let's use the existing macro and avoid a bunch of compiler's conditional. Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Geliang Tang authored
Since OPTIONS_MPTCP_MPC has been defined, use it instead of open-coding. Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Geliang Tang <geliangtang@xiaomi.com> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Westphal authored
When recovering after a link failure, snd_nxt should not be set to a lower value. Else, update of snd_nxt is broken because: msk->snd_nxt += ret; (where ret is number of bytes sent) assumes that snd_nxt always moves forward. After reduction, its possible that snd_nxt update gets out of sync: dfrag we just sent might have had a data sequence number even past recovery_snd_nxt. This change factors the common msk state update to a helper and updates snd_nxt based on the current dfrag data sequence number. The conditional is required for the recovery phase where we may re-transmit old dfrags that are before current snd_nxt. After this change, snd_nxt only moves forward and covers all in-sequence data that was transmitted. recovery_snd_nxt is retained to detect when recovery has completed. Fixes: 1e1d9d6f ("mptcp: handle pending data on closed subflow") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2021-09-24 mlx5 misc updates and fixes to net-next branch: 1) Roi Dayan provided some cleanups in mlx5e TC module, and some code improvements to fwd/drop actions handling. 2) Tariq, Add TX max rate support for MQPRIO channel mode 3) Dima adds the support for TC egress/ingress offload of macvlan interfaces 4) misc cleanup ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 24 Sep, 2021 8 commits
-
-
Dima Chumak authored
Support offloading of TC rules that filter ingress traffic from a MACVLAN device, which is attached to uplink representor. Signed-off-by: Dima Chumak <dchumak@nvidia.com> Reviewed-by: Vlad Buslov <vladbu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Dima Chumak authored
Support offloading of TC rules that mirror/redirect egress traffic to a MACVLAN device, which is attached to mlx5 representor net device. Signed-off-by: Dima Chumak <dchumak@nvidia.com> Reviewed-by: Vlad Buslov <vladbu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Roi Dayan authored
In switchdev mode we insert steering rules to eswitch that make sure packets can't be looped back. Modify the self tests infra and have flags per test. Add a flag for tests that needs to be skipped in switchdev mode. Before this commit: $ ethtool --test enp8s0f0 The test result is FAIL The test extra info: Link Test 0 Speed Test 0 Health Test 0 Loopback Test 1 After this commit: $ ethtool --test enp8s0f0 The test result is PASS The test extra info: Link Test 0 Speed Test 0 Health Test 0 Example output in dmesg: enp8s0f0: Self test begin.. enp8s0f0: [0] Link Test start.. enp8s0f0: [0] Link Test end: result(0) enp8s0f0: [1] Speed Test start.. enp8s0f0: [1] Speed Test end: result(0) enp8s0f0: [2] Health Test start.. enp8s0f0: [2] Health Test end: result(0) enp8s0f0: Self test out: status flags(0x1) Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Roi Dayan authored
This to be consistent and adds the module name to the error message. Signed-off-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Roi Dayan authored
Instead of having sparse ifdefs in source files use a single ifdef in the tc sample header file and use stubs. Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Roi Dayan authored
The priv argument is not being used. remove it. Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Roi Dayan authored
The driver should add offloaded rules with either a fwd or drop action. The check existed in parsing fdb flows but not when parsing nic flows. Move the test into actions_match_supported() which is called for checking nic flows and fdb flows. Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-
Roi Dayan authored
Do it when parsing like in other actions instead of when checking if goto is supported in current scenario. Signed-off-by: Roi Dayan <roid@nvidia.com> Reviewed-by: Maor Dickman <maord@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
-