Re: [PATCH v2 2/2] PCI: Don't treat ~0 as ready in pci_dev_wait() with RRS SV

[Lukas Wunner]

On Sun, Oct 11, 2026 at 06:49:55PM +0200, Alexander Gruhlke wrote:
> On Sun, Oct 11, 2026 at 04:41:42PM +0000, sashiko-bot@xxxxxxxxxx wrote:
> > Does this cause pci_dev_wait() to exit prematurely for Virtual Functions
> > (VFs) that return ~0 under Configuration RRS Software Visibility?
> 
> Yes, but that's the current behavior for all devices; the patch only
> changes it for non-VFs.
> 
> VFs could be covered by reading the Command register when the Vendor ID
> reads ~0 and waiting while that is ~0, too.  Devices that are ready would
> still need only one read.
> 
> Lukas, Bjorn: should I do that in v3, or keep the current form?

For a patch which is going to be backported to stable (due to the
Fixes tag), changing behavior is not a good idea, so I guess you
were right to read the Command Register on VFs if the return value
is 0xffff.  I apologize for my earlier misleading comments.

You could probably constrain the Command Register read operation
to VFs as those are the only ones that would need it, right?

I've started to wonder if VFs can actually be inaccessible and
thus cause a 0xffff response.  So I looked up where the spec
language in PCIe r7.1 sec 7.5.1.1.1 originates from:

It was introduced in PCIe r5.0 sec 9.3.4.1.2 and then r6.0 moved
spec language to sec 7.5.1.1.1.  As rationale, PCIe r5.0 only says:

   "This field in all VFs returns FFFFh when read. VI software should
    return the VF Device ID (see Section 9.3.3.11) value from the
    associated PF as the Device ID for the VF.
    
    IMPLEMENTATION NOTE: Legacy PCI Probing Software
    Returning FFFFh for Device ID and Vendor ID values allows some
    legacy software to ignore VFs. See Section 7.5.1.1.1."

So it's a little unclear to me whether inaccessibility of VFs can
actually occur, but again, for a patch with a Fixes tag, it's better
to play it safe.

Thanks,

Lukas