Re: [PATCH v9 3/9] PCI: Avoid saving config space state in reset path

[Farhan Ali <alifm@linux.ibm.com>]

On 2/18/2026 11:35 AM, Bjorn Helgaas wrote:
> On Wed, Feb 18, 2026 at 12:02:01PM -0700, Keith Busch wrote:
>> On Tue, Feb 17, 2026 at 11:55:43AM -0800, Farhan Ali wrote:
>>> Yes I think you are right, with this change the PCI Command
>>> register gets restored to state at enumeration. So we will lose
>>> the updated state after pci_clear_master() and
>>> pci_enable_device(). I think we can update the vfio driver to call
>>> pci_save_state() after pci_enable_device()?
>> Either that, or move the pci_enable_device() call to after the
>> function reset.
> I kind of like the latter idea because it seems a little simpler for
> the rule of thumb to be that a reset done by the PCI core returns the
> device to the same state as when the driver first probed the device.
> Drivers would generally not use pci_save_state() at all, and they
> could share some initialization logic between probe and post-reset
> recovery.

I think the vfio-pci driver was intentionally doing the 
pci_enable_device() before doing the reset. As per commit 9a92c5091a42 
("vfio-pci: Enable device before attempting reset") it was done to 
handle devices using PM reset, that were getting incorrectly identified 
not supporting PM reset due to current state of the device not being D0. 
It looks like pci_pm_reset() still returns -EINVAL if current power 
state is not D0. So I think we can't move pci_enable_device() after 
reset. Unless we want to update pci_pm_reset() to not use cached value 
of current_state and read it directly from register?

Thanks

Farhan


>
> But I would really like to have Lukas's take on this.  Clearly some
> drivers would have to be adapted if we stop saving config space in the
> PCI core reset path.  We can take care of that for upstream drivers,
> but it seems risky for out-of-tree drivers.
>
> Bjorn