aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet
AgeCommit message (Collapse)AuthorFilesLines
2020-11-05net/mlx5: Cleanup kernel-doc warningsSaeed Mahameed1-3/+5
$ 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 Mahameed1-1/+1
$ 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 Tarasiuk8-36/+57
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 Kliteynik2-4/+11
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 Kliteynik2-18/+6
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 Kliteynik1-6/+8
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 Kliteynik2-307/+204
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 Kliteynik3-1/+204
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 Kliteynik3-37/+33
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 Kliteynik3-71/+76
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 Kliteynik1-1/+0
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 Nelson1-0/+5
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 Kallweit1-3/+11
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 Manoil5-91/+32
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 Wei1-2/+2
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 Yadav2-1/+3
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 King1-1/+1
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 robot1-2/+1
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 Siewior1-6/+6
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 Siewior1-4/+8
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 Bauer1-4/+5
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 Kallweit1-1/+3
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 Kallweit1-1/+1
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 regsJiri Pirko2-41/+90
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 Pirko1-0/+83
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 Pan1-104/+43
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 Yadav1-1/+1
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 Yadav1-0/+3
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 Rix1-1/+1
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 Rix1-1/+1
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 includeYueHaibing1-1/+0
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 includeYueHaibing1-1/+0
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 Oltean2-20/+43
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 Oltean1-13/+22
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 Oltean1-13/+14
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 Oltean2-29/+42
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 Oltean1-4/+0
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 Oltean1-36/+17
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 Bhattiprolu1-4/+32
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 Strashko1-18/+10
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 Strashko2-48/+82
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>
2020-11-02net: ethernet: ti: am65-cpsw: prepare xmit/rx path for multi-port devices in mac-only modeGrygorii Strashko2-34/+108
This patch adds multi-port support to TI AM65x CPSW driver xmit/rx path in preparation for adding support for multi-port devices, like Main CPSW0 on K3 J721E SoC or future CPSW3g on K3 AM64x SoC. Hence DMA channels are common/shared for all ext Ports and the RX/TX NAPI and DMA processing going to be assigned to first available netdev this patch: - ensures all RX descriptors fields are initialized; - adds synchronization for TX DMA push/pop operation (locking) as Networking core locks are not enough any more; - updates TX bql processing for every packet in am65_cpsw_nuss_tx_compl_packets() as every completed TX skb can have different ndev assigned (come from different netdevs). To avoid performance issues for existing one-port CPSW2g devices the above changes are done only for multi-port devices by splitting xmit path for one-port and multi-port devices. 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>
2020-11-02net: ethernet: ti: am65-cpsw: fix tx csum offload for multi mac modeGrygorii Strashko1-29/+1
The current implementation uses .ndo_set_features() callback to track NETIF_F_HW_CSUM feature changes and update generic CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option accordingly. It's not going to work in case of multi-port devices as TX csum offload can be changed per netdev. On K3 CPSWxG devices TX csum offload enabled in the following way: - the CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option enables TX csum offload in generic and affects all TX DMA channels and packets; - corresponding fields in TX DMA descriptor have to be filed properly when upper layer wants to offload TX csum (skb->ip_summed == CHECKSUM_PARTIAL) and it's per-packet option. The Linux Network core is expected to never request TX csum offload if netdev NETIF_F_HW_CSUM feature is disabled, and, as result, TX DMA descriptors should not be modified, and per-packet TX csum offload will be disabled (or enabled) on per-netdev basis. Which, in turn, makes it safe to enable the CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option unconditionally. Hence, fix TX csum offload for multi-port devices by: - enabling the CPSW_P0_CONTROL_REG.RX_CHECKSUM_EN option in am65_cpsw_nuss_common_open() unconditionally - and removing .ndo_set_features() callback implementation, which was used only NETIF_F_HW_CSUM feature update purposes 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>
2020-11-02net: ethernet: ti: am65-cpsw: keep active if cpts enabledGrygorii Strashko1-0/+7
Some K3 CPSW NUSS instances can lose context after PM runtime ON->OFF->ON transition depending on integration (including all submodules: CPTS, MDIO, etc), like J721E Main CPSW (CPSW9G). In case CPTS is enabled it's initialized during probe and does not expect to be reset. Hence, keep K3 CPSW active by forbidding PM runtime if CPTS is enabled. 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>
2020-11-02net: ethernet: ti: am65-cpsw: fix vlan offload for multi mac modeGrygorii Strashko2-7/+20
The VLAN offload for AM65x CPSW2G is implemented using existing ALE APIs, which are also used by legacy CPSW drivers. So, now it always adds current Ext. Port and Host as VLAN members when VLAN is added by 8021Q core (.ndo_vlan_rx_add_vid) and forcibly removes VLAN from ALE table in .ndo_vlan_rx_kill_vid(). This works as for AM65x CPSW2G (which has only one Ext. Port) as for legacy CPSW devices (which can't support same VLAN on more then one Port in multi mac (dual-mac) mode). But it doesn't work for the new J721E and AM64x multi port CPSWxG versions doesn't have such restrictions and allow to offload the same VLAN on any number of ports. Now the attempt to add same VLAN on two (or more) K3 CPSWxG Ports will cause: - VLAN members mask overwrite when VLAN is added - VLAN removal from ALE table when any Port removes VLAN This patch fixes an issue by: - switching to use cpsw_ale_vlan_add_modify() instead of cpsw_ale_add_vlan() when VLAN is added to ALE table, so VLAN members mask will not be overwritten; - Updates cpsw_ale_del_vlan() as: if more than one ext. Port is in VLAN member mask then remove only current port from VLAN member mask else remove VLAN ALE entry Example: add: P1 | P0 (Host) -> members mask: P1 | P0 add: P2 | P0 -> members mask: P2 | P1 | P0 rem: P1 | P0 -> members mask: P2 | P0 rem: P2 | P0 -> members mask: - The VLAN is forcibly removed if port_mask=0 passed to cpsw_ale_del_vlan() to preserve existing legacy CPSW drivers functionality. 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>
2020-11-02net: ethernet: ti: cpsw_ale: add cpsw_ale_vlan_del_modify()Grygorii Strashko3-4/+23
Add/export cpsw_ale_vlan_del_modify() and use it in cpsw_switchdev instead of generic cpsw_ale_del_vlan() to avoid mixing 8021Q and switchdev VLAN offload. This is preparation patch equired by follow up changes. 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>
2020-11-02net: ethernet: ti: am65-cpsw: use cppi5_desc_is_tdcm()Grygorii Strashko1-2/+2
Use cppi5_desc_is_tdcm() helper for teardown indicator detection instead of hard-coded value. 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>
2020-11-02net: ethernet: ti: am65-cpsw: move free desc queue mode selection in pdataGrygorii Strashko2-1/+5
In preparation of adding more multi-port K3 CPSW versions move free descriptor queue mode selection in am65_cpsw_pdata, so it can be selected basing on DT compatibility property. 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>
2020-11-02net: ethernet: ti: am65-cpsw: move ale selection in pdataGrygorii Strashko2-1/+4
In preparation of adding more multi-port K3 CPSW versions move ALE selection in am65_cpsw_pdata, so it can be selected basing on DT compatibility property. 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>
2020-11-02drivers: net: davicom Add COMPILE_TEST supportAndrew Lunn1-1/+1
Improve the build testing of this davicom driver by enabling it when COMPILE_TEST is selected. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.