linux-stable.git/drivers/net, branch v5.16.4

bnx2x: Invalidate fastpath HSI version for VFs

2022-01-29T09:59:24+00:00

commit 802d4d207e75d7208ff75adb712b556c1e91cf1c upstream

Commit 0a6890b9b4df ("bnx2x: Utilize FW 7.13.15.0.")
added validation for fastpath HSI versions for different
client init which was not meant for SR-IOV VF clients, which
resulted in firmware asserts when running VF clients with
different fastpath HSI version.

This patch along with the new firmware support in patch #1
fixes this behavior in order to not validate fastpath HSI
version for the VFs.

Fixes: 0a6890b9b4df ("bnx2x: Utilize FW 7.13.15.0.")
Signed-off-by: Manish Chopra 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Alok Prasad 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bnx2x: Utilize firmware 7.13.21.0

2022-01-29T09:59:24+00:00

commit b7a49f73059fe6147b6b78e8f674ce0d21237432 upstream

This new firmware addresses few important issues and enhancements
as mentioned below -

- Support direct invalidation of FP HSI Ver per function ID, required for
  invalidating FP HSI Ver prior to each VF start, as there is no VF start
- BRB hardware block parity error detection support for the driver
- Fix the FCOE underrun flow
- Fix PSOD during FCoE BFS over the NIC ports after preboot driver
- Maintains backward compatibility

This patch incorporates this new firmware 7.13.21.0 in bnx2x driver.

Signed-off-by: Manish Chopra 
Signed-off-by: Prabhakar Kushwaha 
Signed-off-by: Alok Prasad 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: Fix extraction of ports from the packet headers

2022-01-27T11:03:03+00:00

commit 429e3d123d9a50cc9882402e40e0ac912d88cfcf upstream.

Wrong hash sends single stream to multiple output interfaces.

The offset calculation was relative to skb->head, fix it to be relative
to skb->data.

Fixes: a815bde56b15 ("net, bonding: Refactor bond_xmit_hash for use with
xdp_buff")
Reviewed-by: Jussi Maki 
Reviewed-by: Saeed Mahameed 
Reviewed-by: Gal Pressman 
Signed-off-by: Moshe Tal 
Acked-by: Jay Vosburgh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

lib82596: Fix IRQ check in sni_82596_probe

2022-01-27T11:03:03+00:00

commit 99218cbf81bf21355a3de61cd46a706d36e900e6 upstream.

platform_get_irq() returns negative error number instead 0 on failure.
And the doc of platform_get_irq() provides a usage example:

    int irq = platform_get_irq(pdev, 0);
    if (irq < 0)
        return irq;

Fix the check of return value to catch errors correctly.

Fixes: 115978859272 ("i825xx: Move the Intel 82586/82593/82596 based drivers")
Signed-off-by: Miaoqian Lin 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mscc: ocelot: fix using match before it is set

2022-01-27T11:03:02+00:00

commit baa59504c1cd0cca7d41954a45ee0b3dc78e41a0 upstream.

Clang static analysis reports this issue
ocelot_flower.c:563:8: warning: 1st function call argument
  is an uninitialized value
    !is_zero_ether_addr(match.mask->dst)) {
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The variable match is used before it is set.  So move the
block.

Fixes: 75944fda1dfe ("net: mscc: ocelot: offload ingress skbedit and vlan actions to VCAP IS1")
Signed-off-by: Tom Rix 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: phy: micrel: use kszphy_suspend()/kszphy_resume for irq aware devices

2022-01-27T11:03:02+00:00

commit f1131b9c23fb4a3540a774828ff49f421619f902 upstream.

On a setup with KSZ9131 and MACB drivers it happens on suspend path, from
time to time, that the PHY interrupt arrives after PHY and MACB were
suspended (PHY via genphy_suspend(), MACB via macb_suspend()). In this
case the phy_read() at the beginning of kszphy_handle_interrupt() will
fail (as MACB driver is suspended at this time) leading to phy_error()
being called and a stack trace being displayed on console. To solve this
.suspend/.resume functions for all KSZ devices implementing
.handle_interrupt were replaced with kszphy_suspend()/kszphy_resume()
which disable/enable interrupt before/after calling
genphy_suspend()/genphy_resume().

The fix has been adapted for all KSZ devices which implements
.handle_interrupt but it has been tested only on KSZ9131.

Fixes: 59ca4e58b917 ("net: phy: micrel: implement generic .handle_interrupt() callback")
Signed-off-by: Claudiu Beznea 
Reviewed-by: Andrew Lunn 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: cpsw: avoid alignment faults by taking NET_IP_ALIGN into account

2022-01-27T11:03:02+00:00

commit 1771afd47430f5e95c9c3a2e3a8a63e67402d3fe upstream.

Both versions of the CPSW driver declare a CPSW_HEADROOM_NA macro that
takes NET_IP_ALIGN into account, but fail to use it appropriately when
storing incoming packets in memory. This results in the IPv4 source and
destination addresses to appear misaligned in memory, which causes
aligment faults that need to be fixed up in software.

So let's switch from CPSW_HEADROOM to CPSW_HEADROOM_NA where needed.
This gets rid of any alignment faults on the RX path on a Beaglebone
White.

Fixes: 9ed4050c0d75 ("net: ethernet: ti: cpsw: add XDP support")
Cc: Grygorii Strashko 
Cc: Ilias Apalodimas 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: sfp: fix high power modules without diagnostic monitoring

2022-01-27T11:03:02+00:00

commit 5765cee119bf5a36c94d20eceb37c445508934be upstream.

Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change
modules") unintetionally changed the semantics for high power modules
without the digital diagnostics monitoring. We repeatedly attempt to
read the power status from the non-existing 0xa2 address in a futile
hope this failure is temporary:

[    8.856051] sfp sfp-eth3: module NTT              0000000000000000 rev 0000  sn 0000000000000000 dc 160408
[    8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode
[    8.873469] sfp sfp-eth3: Failed to read EEPROM: -5
[    8.983251] sfp sfp-eth3: Failed to read EEPROM: -5
[    9.103250] sfp sfp-eth3: Failed to read EEPROM: -5

We previosuly assumed such modules were powered up in the correct mode,
continuing without further configuration as long as the required power
class was supported by the host.

Restore this behaviour, while preserving the intent of subsequent
patches to avoid the "Address Change Sequence not supported" warning
if we are not going to be accessing the DDM address.

Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules")
Reported-by: 照山周一郎 
Tested-by: 照山周一郎 
Signed-off-by: Russell King (Oracle) 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ocelot: Fix the call to switchdev_bridge_port_offload

2022-01-27T11:03:02+00:00

commit c0b7f7d7e0ad44f35745c01964b3fa2833e298cb upstream.

In the blamed commit, the call to the function
switchdev_bridge_port_offload was passing the wrong argument for
atomic_nb. It was ocelot_netdevice_nb instead of ocelot_swtchdev_nb.
This patch fixes this issue.

Fixes: 4e51bf44a03af6 ("net: bridge: move the switchdev object replay helpers to "push" mode")
Signed-off-by: Horatiu Vultur 
Reviewed-by: Vladimir Oltean 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ethernet: mtk_eth_soc: fix error checking in mtk_mac_config()

2022-01-27T11:03:02+00:00

commit 214b3369ab9b0a6f28d6c970220c209417edbc65 upstream.

Clang static analysis reports this problem
mtk_eth_soc.c:394:7: warning: Branch condition evaluates
  to a garbage value
                if (err)
                    ^~~

err is not initialized and only conditionally set.
So intitialize err.

Fixes: 7e538372694b ("net: ethernet: mediatek: Re-add support SGMII")
Signed-off-by: Tom Rix 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman