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

[Jakub Kicinski]

On Tue, 9 Jun 2026 07:13:40 +0530 Ratheesh Kannoth wrote:
> On 2026-06-09 at 04:10:14, Jakub Kicinski (kuba@xxxxxxxxxx) wrote:
> > On Fri, 5 Jun 2026 12:02:37 +0530 Ratheesh Kannoth wrote:  
> > > There is only one admin-function PCI device per system.
> > > Reject any additional AF probe with -EBUSY so the driver model matches
> > > hardware and automated reviewers can rely on a single bound instance.  
> >
> > Could you point me to a PCI networking driver written in the last two
> > decades which would have this sort of limitation?
> >
> > At the very least you need to explain in the commit message **why**
> > correctly handling multiple devices in a system is beyond your
> > abilities.  
> 
> 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?