Re: [PATCH v19 net-next 1/9] octeontx2-af: Enforce single RVU AF probe

On Tue, 9 Jun 2026 07:56:46 +0530 Ratheesh Kannoth wrote:

quoted

quoted

The comparison to a generic PCI networking driver isn't quite applicable
here. The RVU AF (Administrative Function) is not a standard NIC PF —
it is a system-level resource manager that owns a single, shared set of
AF registers across the entire RVU subsystem. The hardware spec is
explicit on this: "RVU has a single, common set of AF registers.

This is fundamentally different from a multi-port NIC where each PF is
an independent, symmetric instance. In the RVU model, there is exactly
one AF device per SoC, and all other PFs  communicate with it
via mailboxes rather than accessing AF registers directly. Allowing a
second AF probe would mean two driver instances racing to manage the
same global hardware state — provisioning LFs, configuring
NPC/NIX/NPA — with no hardware arbitration between them.  

I asked you before - is this a driver for a PCIe devices?
You said "yes". If so what prevents the user from plugging two such
devices into one system?  

The RVU AF (PCI device ID 0xA065) is not a pluggable add-in card. It
is an integrated function inside the Marvell OcteonTX2/CN10K/CN20K SoC.
On-chip firmware programs the PCI configuration space for all RVU
functions at boot time — setting device ID, class code, and BAR layout
via RVU_PRIV_PF()_ID_CFG — and the Linux PCI subsystem then discovers
what firmware has configured. There is no slot, no connector, and no
mechanism by which a second instance of this device could appear on the
same system. The hardware exposes exactly one AF PCI device per SoC,
and that is the only device this driver (rvu af driver) binds to.

SMH, I asked you if it is a PCIe **card** or a SoC device.
You answered "This is PCIe." Now you're saying it's a function within
the SoC. I can see the driver is operating on struct pci_device...

Just say this is an integrated device within the SoC then in the commit
message.