Re: [PATCH v1] Bluetooth: btintel_pcie: Support function level reset

[Bjorn Helgaas <helgaas@kernel.org>]

On Mon, Oct 27, 2025 at 11:08:22AM +0100, Johannes Berg wrote:
> Hi,
> 
> So I've been asked to chime in here, mostly on behalf of iwlwifi, and
> I'll actually respond to two of your messages a bit.
> 
> (from your previous email first:)
> 
> > Sort of weird that the commit log mentions FLR, but it's not mentioned
> > in the patch itself except for BTINTEL_PCIE_FLR_RESET_MAX_RETRY.
> > Apparently the assumption is that DSM_SET_RESET_METHOD_PCIE performs
> > an FLR.
> 
> It's not just weird, it's simply wrong. This is not about FLR at all.

Thanks for clearing that up.

> > If you reset the device, you know the state of the device afterward,
> > and the driver should be able to initialize its own data structures
> > accordingly.  This should not require any PCI device removal or
> > rescan.
> 
> Obviously, we know the state of the device, but ... it _does_ require
> PCI removal *and* rescan, because the device completely falls off the
> bus and needs to be rediscovered. The drivers also fundamentally have to
> be unbound from it, since all state of the device (including BAR setup)
> is lost. I'm fairly certain that if you were to query even the device
> IDs after the reset, you'd see 0xFFFFFFFF, but in truth I don't fully
> understand how this works at the PCIe bus level.

It might be different for other buses, but the PCI core really doesn't
do anything to the device during removal or rescan.  It does turn off
power management interrupts from the device and the like, but I'm
pretty sure it doesn't reset the device or do anything to make it
start responding to PCI transactions again.

Obviously remove and rescan reinitializes the *driver* because the PCI
core calls the driver .remove() method, reads the Vendor and Device
IDs, reads and if necessary programs the BARs, and calls the driver
.probe() method.

I think it's really the PLDR that's making the difference here, not
the remove and rescan.  I guess you could experimentally read some
config registers after the PLDR and before the remove/rescan.

Since you know the other device is dead already, I don't have a
problem with resetting the shared parts of the device, so you do need
some way to poke the other driver to reinit.  But I think using the
PCI core remove/rescan to do that makes it more complicated than
necessary and distracts from what's really happening.

Bjorn