summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
AgeCommit message (Collapse)Author
2020-11-07net: macb: fix NULL dereference due to no pcs_config methodParshuram Thombare
This patch fixes NULL pointer dereference due to NULL pcs_config in pcs_ops. Fixes: e4e143e26ce8 ("net: macb: add support for high speed interface") Reported-by: Nicolas Ferre <Nicolas.Ferre@microchip.com> Link: https://lore.kernel.org/netdev/2db854c7-9ffb-328a-f346-f68982723d29@microchip.com/ Signed-off-by: Parshuram Thombare <pthombar@cadence.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/1604599113-2488-1-git-send-email-pthombar@cadence.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-07cxgb4: Fix the -Wmisleading-indentation warningKaixu Xia
Fix the gcc warning: drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c:2673:9: warning: this 'for' clause does not guard... [-Wmisleading-indentation] 2673 | for (i = 0; i < n; ++i) \ Reported-by: Tosk Robot <tencent_os_robot@tencent.com> Signed-off-by: Kaixu Xia <kaixuxia@tencent.com> Link: https://lore.kernel.org/r/1604467444-23043-1-git-send-email-kaixuxia@tencent.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-07net: xilinx: axiethernet: Enable dynamic MDIO MDCClayton Rayment
MDIO spec does not require an MDC at all times, only when MDIO transactions are occurring. This patch allows the xilinx_axienet driver to disable the MDC when not in use, and re-enable it when needed. It also simplifies the driver by removing MDC disable and enable in device reset sequence. Signed-off-by: Clayton Rayment <clayton.rayment@xilinx.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-07net: xilinx: axiethernet: Introduce helper functions for MDC enable/disableRadhey Shyam Pandey
Introduce helper functions to enable/disable MDIO interface clock. This change serves a preparatory patch for the coming feature to dynamically control the management bus clock. Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-06Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-06Revert ibmvnic merge do_change_param_reset into do_resetDany Madden
This reverts commit 16b5f5ce351f8709a6b518cc3cbf240c378305bf where it restructures do_reset. There are patches being tested that would require major rework if this is committed first. We will resend this after the other patches have been applied. Signed-off-by: Dany Madden <drt@linux.ibm.com> Link: https://lore.kernel.org/r/20201106191745.1679846-1-drt@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-06Merge tag 'net-5.10-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Networking fixes for 5.10-rc3, including fixes from wireless, can, and netfilter subtrees. Current merge window - bugs in new features: - can: isotp: isotp_rcv_cf(): enable RX timeout handling in listen-only mode Previous releases - regressions: - mac80211: - don't require VHT elements for HE on 2.4 GHz - fix regression where EAPOL frames were sent in plaintext - netfilter: - ipset: Update byte and packet counters regardless of whether they match - ip_tunnel: fix over-mtu packet send by allowing fragmenting even if inner packet has IP_DF (don't fragment) set in its header (when TUNNEL_DONT_FRAGMENT flag is not set on the tunnel dev) - net: fec: fix MDIO probing for some FEC hardware blocks - ip6_tunnel: set inner ipproto before ip6_tnl_encap to un-break gso support - sctp: Fix COMM_LOST/CANT_STR_ASSOC err reporting on big-endian platforms, sparse-related fix used the wrong integer size Previous releases - always broken: - netfilter: use actual socket sk rather than skb sk when routing harder - r8169: work around short packet hw bug on RTL8125 by padding frames - net: ethernet: ti: cpsw: disable PTPv1 hw timestamping advertisement, the hardware does not support it - chelsio/chtls: fix always leaking ctrl_skb and another leak caused by a race condition - fix drivers incorrectly writing into skbs on TX: - cadence: force nonlinear buffers to be cloned - gianfar: Account for Tx PTP timestamp in the skb headroom - gianfar: Replace skb_realloc_headroom with skb_cow_head for PTP - can: flexcan: - remove FLEXCAN_QUIRK_DISABLE_MECR quirk for LS1021A - add ECC initialization for VF610 and LX2160A - flexcan_remove(): disable wakeup completely - can: fix packet echo functionality: - peak_canfd: fix echo management when loopback is on - make sure skbs are not freed in IRQ context in case they need to be dropped - always clone the skbs to make sure they have a reference on the socket, and prevent it from disappearing - fix real payload length return value for RTR frames - can: j1939: return failure on bind if netdev is down, rather than waiting indefinitely Misc: - IPv6: reply ICMP error if the first fragment don't include all headers to improve compliance with RFC 8200" * tag 'net-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (66 commits) ionic: check port ptr before use r8169: work around short packet hw bug on RTL8125 net: openvswitch: silence suspicious RCU usage warning chelsio/chtls: fix always leaking ctrl_skb chelsio/chtls: fix memory leaks caused by a race can: flexcan: flexcan_remove(): disable wakeup completely can: flexcan: add ECC initialization for VF610 can: flexcan: add ECC initialization for LX2160A can: flexcan: remove FLEXCAN_QUIRK_DISABLE_MECR quirk for LS1021A can: mcp251xfd: remove unneeded break can: mcp251xfd: mcp251xfd_regmap_nocrc_read(): fix semicolon.cocci warnings can: mcp251xfd: mcp251xfd_regmap_crc_read(): increase severity of CRC read error messages can: peak_canfd: pucan_handle_can_rx(): fix echo management when loopback is on can: peak_usb: peak_usb_get_ts_time(): fix timestamp wrapping can: peak_usb: add range checking in decode operations can: xilinx_can: handle failure cases of pm_runtime_get_sync can: ti_hecc: ti_hecc_probe(): add missed clk_disable_unprepare() in error path can: isotp: padlen(): make const array static, makes object smaller can: isotp: isotp_rcv_cf(): enable RX timeout handling in listen-only mode can: isotp: Explain PDU in CAN_ISOTP help text ...
2020-11-05Merge tag 'mlx5-updates-2020-11-03' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5-updates-2020-11-03 This series includes updates to mlx5 software steering component. 1) Few improvements in the DR area, such as removing unneeded checks, renaming to better general names, refactor in some places, etc. 2) Software steering (DR) Memory management improvements This patch series contains SW Steering memory management improvements: using buddy allocator instead of an existing bucket allocator, and several other optimizations. The buddy system is a memory allocation and management algorithm that manages memory in power of two increments. The algorithm is well-known and well-described, such as here: https://en.wikipedia.org/wiki/Buddy_memory_allocation Linux uses this algorithm for managing and allocating physical pages, as described here: https://www.kernel.org/doc/gorman/html/understand/understand009.html In our case, although the algorithm in principal is similar to the Linux physical page allocator, the "building blocks" and the circumstances are different: in SW steering, buddy allocator doesn't really allocates a memory, but rather manages ICM (Interconnect Context Memory) that was previously allocated and registered. The ICM memory that is used in SW steering is always power of 2 (order), so buddy system is a good fit for this. Patches in this series: [PATH 4] net/mlx5: DR, Add buddy allocator utilities This patch adds a modified implementation of a well-known buddy allocator, adjusted for SW steering needs: the algorithm in principal is similar to the Linux physical page allocator, but in our case buddy allocator doesn't really allocate a memory, but rather manages ICM memory that was previously allocated and registered. [PATH 5] net/mlx5: DR, Handle ICM memory via buddy allocation instead of bucket management This patch changes ICM management of SW steering to use buddy-system mechanism Instead of the previous bucket management. [PATH 6] net/mlx5: DR, Sync chunks only during free This patch makes syncing happen only when freeing memory chunks. [PATH 7] net/mlx5: DR, ICM memory pools sync optimization This patch adds tracking of pool's "hot" memory and makes the check whether steering sync is required much shorter and faster. [PATH 8] net/mlx5: DR, Free buddy ICM memory if it is unused This patch adds tracking buddy's used ICM memory, and frees the buddy if all its memory becomes unused. 3) Misc code cleanups * tag 'mlx5-updates-2020-11-03' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net: mlx5: Replace in_irq() usage net/mlx5: Cleanup kernel-doc warnings net/mlx4: Cleanup kernel-doc warnings net/mlx5e: Validate stop_room size upon user input net/mlx5: DR, Free unused buddy ICM memory net/mlx5: DR, ICM memory pools sync optimization net/mlx5: DR, Sync chunks only during free net/mlx5: DR, Handle ICM memory via buddy allocation instead of buckets net/mlx5: DR, Add buddy allocator utilities net/mlx5: DR, Rename matcher functions to be more HW agnostic net/mlx5: DR, Rename builders HW specific names net/mlx5: DR, Remove unused member of action struct ==================== Link: https://lore.kernel.org/r/20201105201242.21716-1-saeedm@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-05net: mlx5: Replace in_irq() usageSebastian Andrzej Siewior
mlx5_eq_async_int() uses in_irq() to decide whether eq::lock needs to be acquired and released with spin_[un]lock() or the irq saving/restoring variants. The usage of in_*() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be seperated or the context be conveyed in an argument passed by the caller, which usually knows the context. mlx5_eq_async_int() knows the context via the action argument already so using it for the lock variant decision is a straight forward replacement for in_irq(). Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: Cleanup kernel-doc warningsSaeed Mahameed
$ git ls-files *.[ch] | egrep drivers/net/ethernet/mellanox/ | \ xargs scripts/kernel-doc -none drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.h:57: warning: Enum value 'MLX5_FPGA_ACCESS_TYPE_I2C' not described ... drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.h:57: warning: Enum value 'MLX5_FPGA_ACCESS_TYPE_DONTCARE' not described ... drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.h:118: warning: Function parameter or member 'cb_arg' not described ... drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.h:160: warning: Function parameter or member 'conn' not described ... drivers/net/ethernet/mellanox/mlx5/core/fpga/sdk.h:160: warning: Excess function parameter 'fdev' description ... Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reported-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
2020-11-05net/mlx4: Cleanup kernel-doc warningsSaeed Mahameed
$ git ls-files *.[ch] | egrep drivers/net/ethernet/mellanox/ | \ xargs scripts/kernel-doc -none drivers/net/ethernet/mellanox/mlx4/fw_qos.h:144: warning: Function parameter or member 'in_param' not described ... drivers/net/ethernet/mellanox/mlx4/fw_qos.h:144: warning: Excess function parameter 'out_param' description ... Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Reported-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
2020-11-05net/mlx5e: Validate stop_room size upon user inputVladyslav Tarasiuk
Stop room is a space that may be taken by WQEs in the SQ during a packet transmit. It is used to check if next packet has enough room in the SQ. Stop room guarantees this packet can be served and if not, the queue is stopped, so no more packets are passed to the driver until it's ready. Currently, stop_room size is calculated and validated upon tx queues allocation. This makes it impossible to know if user provided valid input for certain parameters when interface is down. Instead, store stop_room in mlx5e_sq_param and create mlx5e_validate_params(), to validate its fields upon user input even when the interface is down. Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, Free unused buddy ICM memoryYevgeny Kliteynik
Track buddy's used ICM memory, and free it if all of the buddy's memory bacame unused. Do this only for STEs. MODIFY_ACTION buddies are much smaller, so in case there is a large amount of modify_header actions, which result in large amount of MODIFY_ACTION buddies, doing this cleanup during sync will result in performance hit while not freeing significant amount of memory. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, ICM memory pools sync optimizationYevgeny Kliteynik
Track the pool's hot ICM memory when freeing/allocating chunk, so that when checking if the sync is required, just check if the pool hot memory has reached the sync threshold. Signed-off-by: Hamdan Igbaria <hamdani@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, Sync chunks only during freeYevgeny Kliteynik
When freeing chunks, we want to sync the steering so that all the "hot" memory will be written to ICM and all the chunks that are in the hot_list will be actually destroyed. When allocating from the pool, we don't have a need to sync the steering, as we're not freeing anything, and sync might just hurt the performance in terms of flow-per-second offloaded. Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, Handle ICM memory via buddy allocation instead of bucketsYevgeny Kliteynik
Till now in order to manage the ICM memory we used bucket mechanism, which kept a bucket per specified size (sizes were between 1 block to 2^21 blocks). Now changing that with buddy-system mechanism, which gives us much more flexible way to manage the ICM memory. Its biggest advantage over the bucket is by using the same ICM memory area for all the sizes of blocks, which reduces the memory consumption. Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, Add buddy allocator utilitiesYevgeny Kliteynik
Add implementation of SW Steering variation of buddy allocator. The buddy system for ICM memory uses 2 main data structures: - Bitmap per order, that keeps the current state of allocated blocks for this order - Indicator for the number of available blocks per each order Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, Rename matcher functions to be more HW agnosticYevgeny Kliteynik
Remove flex parser from the matcher function names since the matcher should not be aware of such HW specific details. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, Rename builders HW specific namesYevgeny Kliteynik
We will support multiple STE versions. The existing naming is not suitable for newer versions. Removed the HW specific details and renamed with a more general names. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05net/mlx5: DR, Remove unused member of action structYevgeny Kliteynik
Struct mlx5dr_action doesn't use this member Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-05ionic: check port ptr before useShannon Nelson
Check for corner case of port_init failure before using the port_info pointer. Fixes: 4d03e00a2140 ("ionic: Add initial ethtool support") Signed-off-by: Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20201104195606.61184-1-snelson@pensando.io Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-04r8169: work around short packet hw bug on RTL8125Heiner Kallweit
Network problems with RTL8125B have been reported [0] and with help from Realtek it turned out that this chip version has a hw problem with short packets (similar to RTL8168evl). Having said that activate the same workaround as for RTL8168evl. Realtek suggested to activate the workaround for RTL8125A too, even though they're not 100% sure yet which RTL8125 versions are affected. [0] https://bugzilla.kernel.org/show_bug.cgi?id=209839 Fixes: 0439297be951 ("r8169: add support for RTL8125B") Reported-by: Maxim Plotnikov <wgh@torlan.ru> Tested-by: Maxim Plotnikov <wgh@torlan.ru> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8002c31a-60b9-58f1-f0dd-8fd07239917f@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-04enetc: Remove Tx checksumming offload codeClaudiu Manoil
Tx checksumming has been defeatured and completely removed from the h/w reference manual. Made a little cleanup for the TSE case as this is complementary code. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Link: https://lore.kernel.org/r/20201103140213.3294-1-claudiu.manoil@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-04dpaa_eth: use false and true for bool variablesZou Wei
Fix coccicheck warnings: ./dpaa_eth.c:2549:2-22: WARNING: Assignment of 0/1 to bool variable ./dpaa_eth.c:2562:2-22: WARNING: Assignment of 0/1 to bool variable Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Acked-by: Madalin Bucur <madalin.bucur@oss.nxp.com> Link: https://lore.kernel.org/r/1604405100-33255-1-git-send-email-zou_wei@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03chelsio/chtls: Utilizing multiple rxq/txq to process requestsVinay Kumar Yadav
patch adds a logic to utilize multiple queues to process requests. The queue selection logic uses a round-robin distribution technique using a counter. Signed-off-by: Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Link: https://lore.kernel.org/r/20201102162832.22344-1-vinay.yadav@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03octeontx2-pf: Fix sizeof() mismatchColin Ian King
An incorrect sizeof() is being used, sizeof(u64 *) is not correct, it should be sizeof(*sq->sqb_ptrs). Addresses-Coverity: ("Sizeof not portable (SIZEOF_MISMATCH)") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201102134601.698436-1-colin.king@canonical.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03forcedeth: fix excluded_middle.cocci warningskernel test robot
Condition !A || A && B is equivalent to !A || B. Generated by: scripts/coccinelle/misc/excluded_middle.cocci Fixes: b76f0ea01312 ("coccinelle: misc: add excluded_middle.cocci script") CC: Denis Efremov <efremov@linux.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Julia Lawall <julia.lawall@inria.fr> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2011020936100.3077@hadrien Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03net: dpaa: Replace in_irq() usage.Sebastian Andrzej Siewior
The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI scheduling is required or packet processing. The usage of in_*() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Use the `sched_napi' argument passed by the callback. It is set true if called from the interrupt handler and NAPI should be scheduled. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Li Yang <leoyang.li@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com> Tested-by: Camelia Groza <camelia.groza@nxp.com>
2020-11-03soc/fsl/qbman: Add an argument to signal if NAPI processing is required.Sebastian Andrzej Siewior
dpaa_eth_napi_schedule() and caam_qi_napi_schedule() schedule NAPI if invoked from: - Hard interrupt context - Any context which is not serving soft interrupts Any context which is not serving soft interrupts includes hard interrupts so the in_irq() check is redundant. caam_qi_napi_schedule() has a comment about this: /* * In case of threaded ISR, for RT kernels in_irq() does not return * appropriate value, so use in_serving_softirq to distinguish between * softirq and irq contexts. */ if (in_irq() || !in_serving_softirq()) This has nothing to do with RT. Even on a non RT kernel force threaded interrupts run obviously in thread context and therefore in_irq() returns false when invoked from the handler. The extension of the in_irq() check with !in_serving_softirq() was there when the drivers were added, but in the out of tree FSL BSP the original condition was in_irq() which got extended due to failures on RT. The usage of in_xxx() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Right he is, the above construct is clearly showing why. The following callchains have been analyzed to end up in dpaa_eth_napi_schedule(): qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() portal_isr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() Both need to schedule NAPI. The crypto part has another code path leading up to this: kill_fq() empty_retired_fq() qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() kill_fq() is called from task context and ends up scheduling NAPI, but that's pointless and an unintended side effect of the !in_serving_softirq() check. The code path: caam_qi_poll() -> qman_p_poll_dqrr() is invoked from NAPI and I *assume* from crypto's NAPI device and not from qbman's NAPI device. I *guess* it is okay to skip scheduling NAPI (because this is what happens now) but could be changed if it is wrong due to `budget' handling. Add an argument to __poll_portal_fast() which is true if NAPI needs to be scheduled. This requires propagating the value to the caller including `qman_cb_dqrr' typedef which is used by the dpaa and the crypto driver. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Herbert XS <herbert@gondor.apana.org.au> Cc: Li Yang <leoyang.li@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Madalin Bucur <madalin.bucur@oss.nxp.com> Tested-by: Camelia Groza <camelia.groza@nxp.com>
2020-11-03lan743x: fix for potential NULL pointer dereference with bare cardSergej Bauer
This is the 3rd revision of the patch fix for potential null pointer dereference with lan743x card. The simpliest way to reproduce: boot with bare lan743x and issue "ethtool ethN" commant where ethN is the interface with lan743x card. Example: $ sudo ethtool eth7 dmesg: [ 103.510336] BUG: kernel NULL pointer dereference, address: 0000000000000340 ... [ 103.510836] RIP: 0010:phy_ethtool_get_wol+0x5/0x30 [libphy] ... [ 103.511629] Call Trace: [ 103.511666] lan743x_ethtool_get_wol+0x21/0x40 [lan743x] [ 103.511724] dev_ethtool+0x1507/0x29d0 [ 103.511769] ? avc_has_extended_perms+0x17f/0x440 [ 103.511820] ? tomoyo_init_request_info+0x84/0x90 [ 103.511870] ? tomoyo_path_number_perm+0x68/0x1e0 [ 103.511919] ? tty_insert_flip_string_fixed_flag+0x82/0xe0 [ 103.511973] ? inet_ioctl+0x187/0x1d0 [ 103.512016] dev_ioctl+0xb5/0x560 [ 103.512055] sock_do_ioctl+0xa0/0x140 [ 103.512098] sock_ioctl+0x2cb/0x3c0 [ 103.512139] __x64_sys_ioctl+0x84/0xc0 [ 103.512183] do_syscall_64+0x33/0x80 [ 103.512224] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 103.512274] RIP: 0033:0x7f54a9cba427 ... Previous versions can be found at: v1: initial version https://lkml.org/lkml/2020/10/28/921 v2: do not return from lan743x_ethtool_set_wol if netdev->phydev == NULL, just skip the call of phy_ethtool_set_wol() instead. https://lkml.org/lkml/2020/10/31/380 v3: in function lan743x_ethtool_set_wol: use ternary operator instead of if-else sentence (review by Markus Elfring) return -ENETDOWN insted of -EIO (review by Andrew Lunn) Signed-off-by: Sergej Bauer <sbauer@blackbox.su> Link: https://lore.kernel.org/r/20201101223556.16116-1-sbauer@blackbox.su Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03r8169: set IRQF_NO_THREAD if MSI(X) is enabledHeiner Kallweit
We had to remove flag IRQF_NO_THREAD because it conflicts with shared interrupts in case legacy interrupts are used. Following up on the linked discussion set IRQF_NO_THREAD if MSI or MSI-X is used, because both guarantee that interrupt won't be shared. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://www.spinics.net/lists/netdev/msg695341.html Link: https://lore.kernel.org/r/446cf5b8-dddd-197f-cb96-66783141ade4@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03r8169: align number of tx descriptors with vendor driverHeiner Kallweit
Lowest number of tx descriptors used in the vendor drivers is 256 in r8169. r8101/r8168/r8125 use 1024 what seems to be the hw limit. Stay on the safe side and go with 256, same as number of rx descriptors. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/a52a6de4-f792-5038-ae2f-240d3b7860eb@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03mlxsw: spectrum_router: Introduce low-level ops and implement them for RALXX ↵Jiri Pirko
regs In preparation for support of XM router implementation which uses different registers to work with trees and FIB entries, introduce a structure to hold low-level ops and implement tree manipulation register ops. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03mlxsw: reg: Add XRALXX RegistersJiri Pirko
Add a couple of registers used to manipulate LPM trees on XM: The XRALTA is used to allocate the XLT LPM trees. The XRALST is used to set and query the structure of an XLT LPM tree. The XRALTB register is used to bind virtual router and protocol to an allocated LPM tree. Since the XM registers are identical to the legacy router registers with a fixed offset, re-use their pack functions. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03ibmvnic: merge do_change_param_reset into do_resetLijun Pan
Commit b27507bb59ed ("net/ibmvnic: unlock rtnl_lock in reset so linkwatch_event can run") introduced do_change_param_reset function to solve the rtnl lock issue. Majority of the code in do_change_param_reset duplicates do_reset. Also, we can handle the rtnl lock issue in do_reset itself. Hence merge do_change_param_reset back into do_reset to clean up the code. Signed-off-by: Lijun Pan <ljp@linux.ibm.com> Link: https://lore.kernel.org/r/20201031094645.17255-1-ljp@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03chelsio/chtls: fix always leaking ctrl_skbVinay Kumar Yadav
Correct skb refcount in alloc_ctrl_skb(), causing skb memleak when chtls_send_abort() called with NULL skb. it was always leaking the skb, correct it by incrementing skb refs by one. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Link: https://lore.kernel.org/r/20201102173909.24826-1-vinay.yadav@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-03chelsio/chtls: fix memory leaks caused by a raceVinay Kumar Yadav
race between user context and softirq causing memleak, consider the call sequence scenario chtls_setkey() //user context chtls_peer_close() chtls_abort_req_rss() chtls_setkey() //user context work request skb queued in chtls_setkey() won't be freed because resources are already cleaned for this connection, fix it by not queuing work request while socket is closing. v1->v2: - fix W=1 warning. v2->v3: - separate it out from another memleak fix. Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Link: https://lore.kernel.org/r/20201102173650.24754-1-vinay.yadav@chelsio.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net/mlx4_core : remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20201101140528.2279424-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: stmmac: dwmac-meson8b: remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201101140720.2280013-1-trix@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: hns3: Remove duplicated includeYueHaibing
Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20201031024940.29716-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02liquidio: cn68xx: Remove duplicated includeYueHaibing
Remove duplicated include. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20201031024744.39020-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: mscc: ocelot: deny changing the native VLAN from the prepare phaseVladimir Oltean
Put the preparation phase of switchdev VLAN objects to some good use, and move the check we already had, for preventing the existence of more than one egress-untagged VLAN per port, to the preparation phase of the addition. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: mscc: ocelot: move the logic to drop 802.1p traffic to the pvid deletionVladimir Oltean
Currently, the ocelot_port_set_native_vlan() function starts dropping untagged and prio-tagged traffic when the native VLAN is removed? What is the native VLAN? It is the only egress-untagged VLAN that ocelot supports on a port. If the port is a trunk with 100 VLANs, one of those VLANs can be transmitted as egress-untagged, and that's the native VLAN. Is it wrong to drop untagged and prio-tagged traffic if there's no native VLAN? Yes and no. In this case, which is more typical, it's ok to apply that drop configuration: $ bridge vlan add dev swp0 vid 1 pvid untagged <- this is the native VLAN $ bridge vlan add dev swp0 vid 100 $ bridge vlan add dev swp0 vid 101 $ bridge vlan del dev swp0 vid 1 <- delete the native VLAN But only because the pvid and the native VLAN have the same ID. In this case, it isn't: $ bridge vlan add dev swp0 vid 1 pvid $ bridge vlan add dev swp0 vid 100 untagged <- this is the native VLAN $ bridge vlan del dev swp0 vid 101 $ bridge vlan del dev swp0 vid 100 <- delete the native VLAN It's wrong, because the switch will drop untagged and prio-tagged traffic now, despite having a valid pvid of 1. The confusion seems to stem from the fact that the native VLAN is an egress setting, while the PVID is an ingress setting. It would be correct to drop untagged and prio-tagged traffic only if there was no pvid on the port. So let's do just that. Background: https://lore.kernel.org/netdev/CA+h21hrRMrLH-RjBGhEJSTZd6_QPRSd3RkVRQF-wNKkrgKcRSA@mail.gmail.com/#t Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: mscc: ocelot: add a "valid" boolean to struct ocelot_vlanVladimir Oltean
Currently we are checking in some places whether the port has a native VLAN on egress or not, by comparing the ocelot_port->vid value with zero. That works, because VID 0 can never be a native VLAN configured by the bridge, but now we want to make similar checks for the pvid. That won't work, because there are cases when we do have the pvid set to 0 (not by the bridge, by ourselves, but still.. it's confusing). And we can't encode a negative value into an u16, so add a bool to the structure. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: mscc: ocelot: transform the pvid and native vlan values into a structureVladimir Oltean
This is a mechanical patch only. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: mscc: ocelot: don't reset the pvid to 0 when deleting itVladimir Oltean
I have no idea why this code is here, but I have 2 hypotheses: 1. A desperate attempt to keep untagged traffic working when the bridge deletes the pvid on a port. There was a fairly okay discussion here: https://lore.kernel.org/netdev/CA+h21hrRMrLH-RjBGhEJSTZd6_QPRSd3RkVRQF-wNKkrgKcRSA@mail.gmail.com/#t which established that in vlan_filtering=1 mode, the absence of a pvid should denote that the ingress port should drop untagged and priority tagged traffic. While in vlan_filtering=0 mode, nothing should change. So in vlan_filtering=1 mode, we should simply let things happen, and not attempt to save the day. And in vlan_filtering=0 mode, the pvid is 0 anyway, no need to do anything. 2. The driver encodes the native VLAN (ocelot_port->vid) value of 0 as special, meaning "not valid". There are checks based on that. But there are no such checks for the ocelot_port->pvid value of 0. In fact, that's a perfectly valid value, which is used in standalone mode. Maybe there was some confusion and the author thought that 0 means "invalid" here as well. In conclusion, delete the code*. *in fact we'll add it back later, in a slightly different form, but for an entirely different reason than the one for which this exists now. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: mscc: ocelot: use the pvid of zero when bridged with vlan_filtering=0Vladimir Oltean
Currently, mscc_ocelot ports configure pvid=0 in standalone mode, and inherit the pvid from the bridge when one is present. When the bridge has vlan_filtering=0, the software semantics are that packets should be received regardless of whether there's a pvid configured on the ingress port or not. However, ocelot does not observe those semantics today. Moreover, changing the PVID is also a problem with vlan_filtering=0. We are privately remapping the VID of FDB, MDB entries to the port's PVID when those are VLAN-unaware (i.e. when the VID of these entries comes to us as 0). But we have no logic of adjusting that remapping when the user changes the pvid and vlan_filtering is 0. So stale entries would be left behind, and untagged traffic will stop matching on them. And even if we were to solve that, there's an even bigger problem. If swp0 has pvid 1, and swp1 has pvid 2, and both are under a vlan_filtering=0 bridge, they should be able to forward traffic between one another. However, with ocelot they wouldn't do that. The simplest way of fixing this is to never configure the pvid based on what the bridge is asking for, when vlan_filtering is 0. Only if there was a VLAN that the bridge couldn't mangle, that we could use as pvid.... So, turns out, there's 0 just for that. And for a reason: IEEE 802.1Q-2018, page 247, Table 9-2-Reserved VID values says: The null VID. Indicates that the tag header contains only priority information; no VID is present in the frame. This VID value shall not be configured as a PVID or a member ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ of a VID Set, or configured in any FDB entry, or used in any Management operation. So, aren't we doing exactly what 802.1Q says not to? Well, in a way, but what we're doing here is just driver-level bookkeeping, all for the better. The fact that we're using a pvid of 0 is not observable behavior from the outside world: the network stack does not see the classified VLAN that the switch uses, in vlan_filtering=0 mode. And we're also more consistent with the standalone mode now. And now that we use the pvid of 0 in this mode, there's another advantage: we don't need to perform any VID remapping for FDB and MDB entries either, we can just use the VID of 0 that the bridge is passing to us. The only gotcha is that every time we change the vlan_filtering setting, we need to reapply the pvid (either to 0, or to the value from the bridge). A small side-effect visible in the patch is that ocelot_port_set_pvid needs to be moved above ocelot_port_vlan_filtering, so that it can be called from there without forward-declarations. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02powerpc/vnic: Extend "failover pending" windowSukadev Bhattiprolu
Commit 5a18e1e0c193b introduced the 'failover_pending' state to track the "failover pending window" - where we wait for the partner to become ready (after a transport event) before actually attempting to failover. i.e window is between following two events: a. we get a transport event due to a FAILOVER b. later, we get CRQ_INITIALIZED indicating the partner is ready at which point we schedule a FAILOVER reset. and ->failover_pending is true during this window. If during this window, we attempt to open (or close) a device, we pretend that the operation succeded and let the FAILOVER reset path complete the operation. This is fine, except if the transport event ("a" above) occurs during the open and after open has already checked whether a failover is pending. If that happens, we fail the open, which can cause the boot scripts to leave the interface down requiring administrator to manually bring up the device. This fix "extends" the failover pending window till we are _actually_ ready to perform the failover reset (i.e until after we get the RTNL lock). Since open() holds the RTNL lock, we can be sure that we either finish the open or if the open() fails due to the failover pending window, we can again pretend that open is done and let the failover complete it. We could try and block the open until failover is completed but a) that could still timeout the application and b) Existing code "pretends" that failover occurred "just after" open succeeded, so marks the open successful and lets the failover complete the open. So, mark the open successful even if the transport event occurs before we actually start the open. Fixes: 5a18e1e0c193 ("ibmvnic: Fix failover case for non-redundant configuration") Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Acked-by: Dany Madden <drt@linux.ibm.com> Link: https://lore.kernel.org/r/20201030170711.1562994-1-sukadev@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: ethernet: ti: am65-cpsw: handle deferred probe with dev_err_probe()Grygorii Strashko
Use new dev_err_probe() API to handle deferred probe properly and simplify the code. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-02net: ethernet: ti: am65-cpsw: add multi port support in mac-only modeGrygorii Strashko
This patch adds final multi-port support to TI AM65x CPSW driver path in preparation for adding support for multi-port devices, like Main CPSW0 on K3 J721E SoC or future CPSW3g on K3 AM64x SoC. - the separate netdev is created for every enabled external Port; - DMA channels are common/shared for all external Ports and the RX/TX NAPI and DMA processing assigned to first available netdev; - external Ports are configured in mac-only mode, which is similar to TI "dual-mac" mode for legacy TI CPSW - packets are sent to the Host port only in ingress and directly to the Port on egress. No packet switching between external ports happens. - every port supports the same features as current AM65x CPSW on external device. Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>