From: Mohsin Bashir mohsin.bashr@gmail.com
[ Upstream commit b1161b1863c5f3d592adba5accd6e5c79741720f ]
Upon experiencing a PCI error, fbnic reset the device to recover from the failure. Reset the hardware stats as part of the device reset to ensure accurate stats reporting.
Note that the reset is not really resetting the aggregate value to 0, which may result in a spike for a system collecting deltas in stats. Rather, the reset re-latches the current value as previous, in case HW got reset.
Signed-off-by: Mohsin Bashir mohsin.bashr@gmail.com Reviewed-by: Jacob Keller jacob.e.keller@intel.com Link: https://patch.msgid.link/20250825200206.2357713-3-kuba@kernel.org Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What changed and where - Adds a single call to re-latch hardware stats on reattach: `fbnic_reset_hw_stats(fbd)` in `__fbnic_pm_attach()` so stats are consistent after device reset, including PCI AER recovery and PM resume flows (drivers/net/ethernet/meta/fbnic/fbnic_pci.c:524). - `__fbnic_pm_attach()` is invoked on both PM resume and PCI error recovery: - From PM resume wrapper: drivers/net/ethernet/meta/fbnic/fbnic_pci.c:544 - From PCI AER resume handler: drivers/net/ethernet/meta/fbnic/fbnic_pci.c:593 - The reset routine itself locks and re-latches all stats fields: drivers/net/ethernet/meta/fbnic/fbnic_hw_stats.c:544. It uses `hw_stats.lock` for most stats and relies on RTNL for MAC stats, as documented in the function’s comment (drivers/net/ethernet/meta/fbnic/fbnic_hw_stats.c:558). In this tree, `__fbnic_pm_attach()` wraps the reset with RTNL (`rtnl_lock(); fbnic_reset_hw_stats(fbd); rtnl_unlock();`) to satisfy `ASSERT_RTNL()` when `netdev` is present (drivers/net/ethernet/meta/fbnic/fbnic_pci.c:521–526).
- Why it’s a bug fix affecting users - After PCI errors and recovery (and likewise after suspend/resume), the device is reset and hardware counters may be cleared. Without re-latching the driver’s baseline, reported stats can become inaccurate or exhibit wrap-like artifacts. The added reset ensures accurate stats reporting post-recovery, matching the commit message intent. - The commit acknowledges a possible one-time spike for systems collecting deltas, which is a normal and acceptable behavior when re-basing stats after a reset.
- Scope and risk - Change is minimal and self-contained: a single function call in the driver’s reattach path. - No user-visible API changes, no architectural changes, and no impact to the fast path. - Concurrency is handled: `fbnic_reset_hw_stats()` uses a spinlock for most stats and relies on RTNL for MAC stats; the caller holds RTNL around the call (drivers/net/ethernet/meta/fbnic/fbnic_pci.c:521–526), consistent with the function’s comment (drivers/net/ethernet/meta/fbnic/fbnic_hw_stats.c:558). - Only touches the `fbnic` driver, not core networking or PCI subsystems.
- Stable backport criteria - Fixes a real user-visible issue (incorrect stats after PCI/PM reset). - Small, focused change with low regression risk. - No new features or architectural churn. - Clear, intentional behavior with locking correctness.
Given the above, this is a strong candidate for stable backporting. If targeting older stable trees, ensure prerequisites exist: the presence of `fbnic_reset_hw_stats()` (drivers/net/ethernet/meta/fbnic/fbnic_hw_stats.c:544) and that the call site holds RTNL when `netdev` is present (as done here).
drivers/net/ethernet/meta/fbnic/fbnic_pci.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c index 28e23e3ffca88..c4d51490140eb 100644 --- a/drivers/net/ethernet/meta/fbnic/fbnic_pci.c +++ b/drivers/net/ethernet/meta/fbnic/fbnic_pci.c @@ -489,6 +489,8 @@ static void __fbnic_pm_attach(struct device *dev) struct net_device *netdev = fbd->netdev; struct fbnic_net *fbn;
+ fbnic_reset_hw_stats(fbd); + if (fbnic_init_failure(fbd)) return;