linux-stable.git/drivers/net/ethernet/broadcom, branch linux-5.14.y

bnxt_en: Check devlink allocation and registration status

2021-11-17T10:03:59+00:00

[ Upstream commit e624c70e1131e145bd0510b8a700b5e2d112e377 ]

devlink is a software interface that doesn't depend on any hardware
capabilities. The failure in SW means memory issues, wrong parameters,
programmer error e.t.c.

Like any other such interface in the kernel, the returned status of
devlink APIs should be checked and propagated further and not ignored.

Fixes: 4ab0c6a8ffd7 ("bnxt_en: add support to enable VF-representors")
Signed-off-by: Leon Romanovsky 
Reviewed-by: Edwin Peer 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: bgmac-platform: handle mac-address deferral

2021-10-17T08:44:50+00:00

[ Upstream commit 763716a55cb1f480ffe1a9702e6b5d9ea1a80a24 ]

This patch is a replication of Christian Lamparter's "net: bgmac-bcma:
handle deferred probe error due to mac-address" patch for the
bgmac-platform driver [1].

As is the case with the bgmac-bcma driver, this change is to cover the
scenario where the MAC address cannot yet be discovered due to reliance
on an nvmem provider which is yet to be instantiated, resulting in a
random address being assigned that has to be manually overridden.

[1] https://lore.kernel.org/netdev/20210919115725.29064-1-chunkeey@gmail.com

Signed-off-by: Matthew Hagan 
Reviewed-by: Andrew Lunn 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bnxt_en: Fix TX timeout when TX ring size is set to the smallest

2021-09-30T08:12:58+00:00

[ Upstream commit 5bed8b0704c9ecccc8f4a2c377d7c8e21090a82e ]

The smallest TX ring size we support must fit a TX SKB with MAX_SKB_FRAGS
+ 1.  Because the first TX BD for a packet is always a long TX BD, we
need an extra TX BD to fit this packet.  Define BNXT_MIN_TX_DESC_CNT with
this value to make this more clear.  The current code uses a minimum
that is off by 1.  Fix it using this constant.

The tx_wake_thresh to determine when to wake up the TX queue is half the
ring size but we must have at least BNXT_MIN_TX_DESC_CNT for the next
packet which may have maximum fragments.  So the comparison of the
available TX BDs with tx_wake_thresh should be >= instead of > in the
current code.  Otherwise, at the smallest ring size, we will never wake
up the TX queue and will cause TX timeout.

Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
Reviewed-by: Pavan Chebbi 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: bgmac-bcma: handle deferred probe error due to mac-address

2021-09-30T08:12:58+00:00

[ Upstream commit 029497e66bdc762e001880e4c85a91f35a54b1e2 ]

Due to the inclusion of nvmem handling into the mac-address getter
function of_get_mac_address() by
commit d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
it is now possible to get a -EPROBE_DEFER return code. Which did cause
bgmac to assign a random ethernet address.

This exact issue happened on my Meraki MR32. The nvmem provider is
an EEPROM (at24c64) which gets instantiated once the module
driver is loaded... This happens once the filesystem becomes available.

With this patch, bgmac_probe() will propagate the -EPROBE_DEFER error.
Then the driver subsystem will reschedule the probe at a later time.

Cc: Petr Štetiar 
Cc: Michael Walle 
Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
Signed-off-by: Christian Lamparter 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bnxt_en: Fix error recovery regression

2021-09-22T10:39:33+00:00

commit eca4cf12acda306f851f6d2a05b1c9ef62cf0e81 upstream.

The recent patch has introduced a regression by not reading the reset
count in the ERROR_RECOVERY async event handler.  We may have just
gone through a reset and the reset count has just incremented.  If
we don't update the reset count in the ERROR_RECOVERY event handler,
the health check timer will see that the reset count has changed and
will initiate an unintended reset.

Restore the unconditional update of the reset count in
bnxt_async_event_process() if error recovery watchdog is enabled.
Also, update the reset count at the end of the reset sequence to
make it even more robust.

Fixes: 1b2b91831983 ("bnxt_en: Fix possible unintended driver initiated error recovery")
Reviewed-by: Edwin Peer 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bnxt_en: Fix possible unintended driver initiated error recovery

2021-09-22T10:39:32+00:00

[ Upstream commit 1b2b91831983aeac3adcbb469aa8b0dc71453f89 ]

If error recovery is already enabled, bnxt_timer() will periodically
check the heartbeat register and the reset counter.  If we get an
error recovery async. notification from the firmware (e.g. change in
primary/secondary role), we will immediately read and update the
heartbeat register and the reset counter.  If the timer for the next
health check expires soon after this, we may read the heartbeat register
again in quick succession and find that it hasn't changed.  This will
trigger error recovery unintentionally.

The likelihood is small because we also reset fw_health->tmr_counter
which will reset the interval for the next health check.  But the
update is not protected and bnxt_timer() can miss the update and
perform the health check without waiting for the full interval.

Fix it by only reading the heartbeat register and reset counter in
bnxt_async_event_process() if error recovery is trasitioning to the
enabled state.  Also add proper memory barriers so that when enabling
for the first time, bnxt_timer() will see the tmr_counter interval and
perform the health check after the full interval has elapsed.

Fixes: 7e914027f757 ("bnxt_en: Enable health monitoring.")
Reviewed-by: Edwin Peer 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bnxt_en: Fix asic.rev in devlink dev info command

2021-09-22T10:39:32+00:00

[ Upstream commit 6fdab8a3ade2adc123bbf5c4fdec3394560b1fb1 ]

The current asic.rev is incomplete and does not include the metal
revision.  Add the metal revision and decode the complete asic
revision into the more common and readable form (A0, B0, etc).

Fixes: 7154917a12b2 ("bnxt_en: Refactor bnxt_dl_info_get().")
Reviewed-by: Edwin Peer 
Reviewed-by: Somnath Kotur 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bnxt_en: fix stored FW_PSID version masks

2021-09-22T10:39:32+00:00

[ Upstream commit 1656db67233e4259281d2ac35b25f712edbbc20b ]

The FW_PSID version components are 8 bits wide, not 4.

Fixes: db28b6c77f40 ("bnxt_en: Fix devlink info's stored fw.psid version format.")
Signed-off-by: Edwin Peer 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bnxt_en: make bnxt_free_skbs() safe to call after bnxt_free_mem()

2021-09-22T10:39:22+00:00

commit 1affc01fdc6035189a5ab2a24948c9419ee0ecf2 upstream.

The call to bnxt_free_mem(..., false) in the bnxt_half_open_nic() error
path will deallocate ring descriptor memory via bnxt_free_?x_rings(),
but because irq_re_init is false, the ring info itself is not freed.

To simplify error paths, deallocation functions have generally been
written to be safe when called on unallocated memory. It should always
be safe to call dev_close(), which calls bnxt_free_skbs() a second time,
even in this semi- allocated ring state.

Calling bnxt_free_skbs() a second time with the rings already freed will
cause NULL pointer dereference.  Fix it by checking the rings are valid
before proceeding in bnxt_free_tx_skbs() and
bnxt_free_one_rx_ring_skbs().

Fixes: 975bc99a4a39 ("bnxt_en: Refactor bnxt_free_rx_skbs().")
Signed-off-by: Edwin Peer 
Signed-off-by: Michael Chan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/{mlx5|nfp|bnxt}: Remove unnecessary RTNL lock assert

2021-09-22T10:39:19+00:00

commit 7c3a0a018e672a9723a79b128227272562300055 upstream.

Remove the assert from the callback priv lookup function since it does
not require RTNL lock and is already protected by flow_indr_block_lock.

This will avoid warnings from being emitted to dmesg if the driver
registers its callback after an ingress qdisc was created for a
netdevice.

The warnings started after the following patch was merged:
commit 74fc4f828769 ("net: Fix offloading indirect devices dependency on qdisc order creation")

Signed-off-by: Eli Cohen 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman