Re:

On 2/2/2026 2:53 AM, Anshumali Gaur wrote:

On 2026-01-29 at 23:02:43, Jacob Keller (jacob.e.keller@intel.com) wrote:

quoted

On 1/29/2026 1:19 AM, Anshumali Gaur wrote:

quoted

When both AF and PF drivers are built as modules, the PF driver in the
kexec kernel may probe before the AF driver is ready. This leads to
a crash due to uninitialized hardware state.

This patch ensures the PF driver properly detects and waits for AF
driver readiness before proceeding with initialization.

To me, the patch description is not sufficient to describe the what and why
of this change.

Could you please provide a better explanation of how the addition of the
provided shutdown handler fixes initialization?

Hi Jacob,
The issue being addressed here is specific to kexec and persistent AF
hardware state across kernel transitions. When both AF and PF drivers
are built as modules and a kexec kernel is performed, the PF driver in
the new kernel may probe before the AF driver has completed probing and
reinitializing the RVU hardware. In this scenario, the hardware state
left behind by the AF driver in the old kernel is still visible to the
PF driver in the new kernel resulting in crash due to stale state.

quoted

quoted

Fixes: 54494aa5d1e6 ("octeontx2-af: Add Marvell OcteonTX2 RVU AF driver")
Signed-off-by: Anshumali Gaur <redacted>
---
   drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 11 +++++++++++
   1 file changed, 11 insertions(+)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
index 747fbdf2a908..8530df8b3fda 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c

@@ -3632,11 +3632,22 @@ static void rvu_remove(struct pci_dev *pdev)
   	devm_kfree(&pdev->dev, rvu);
   }
+static void rvu_shutdown(struct pci_dev *pdev)
+{
+	struct rvu *rvu = pci_get_drvdata(pdev);
+
+	if (!rvu)
+		return;
+
+	rvu_clear_rvum_blk_revid(rvu);

Here, I guess you are clearing some data about the device status. Does that
mean that when you initialize later you will wait for the AF driver to
finish probing and configure this? It would be nice to explain how this
change fixes initialization.

The RVUM block revision field acts as an implicit indication that the AF
driver has completed its initialization. If this value is left uncleared
during kexec kernel booting, the PF driver may observe a non-zero/valid
RVUM block revision and incorrectly assume that the AF is already
initialized and ready, even though the AF driver in the kexec kernel has
not yet probed. This leads to PF initialization proceeding against
partially initialized hardware, resulting in a crash.

Makes sense. When shutting down you need to explicitly clear the stale 
data so that booting up (without a powercycle as in the kexec case) does 
not lead to stale data.

I'd appreciate a little more of this detail in the commit message 
personally. However, functionally it makes sense, so:

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>