Re: [PATCH v23 2/5] PCI: Allow per function PCI slots to fix slot reset on s390

On Fri, Aug 14, 2026 at 10:46:28AM +0200, Niklas Schnelle wrote:
> On Thu, 2026-08-13 at 18:25 -0500, Bjorn Helgaas wrote:
> > On Wed, Aug 05, 2026 at 09:55:15AM -0700, Farhan Ali wrote:
> > > On s390 systems, which use a machine level hypervisor, PCI devices are
> > > always accessed through a form of PCI pass-through which fundamentally
> > > operates on a per PCI function granularity. This is also reflected in the
> > > s390 PCI hotplug driver which creates hotplug slots for individual PCI
> > > functions. Its reset_slot() function, which is a wrapper for
> > > zpci_hot_reset_device(), thus also resets individual functions.
> > 
> > Sorry to come back to this yet again.  I understand the issue with
> > the wrong pci_slot being assigned for these s390 functions.
> > 
> > What I don't understand is why we would use slot_reset() in the first
> > place.  I would expect FLR instead.
> > 
> > The hotplug slot_reset() path is used by pci_reset_bus_function().
> > But given the order in pci_reset_fn_methods[], we would typically try
> > pcie_reset_flr() first, and we would only get to
> > pci_reset_bus_function() if FLR and the other resets are not
> > available.
> > 
> > Since these are actually multi-function devices, I'm surprised that
> > they wouldn't advertise FLR support.
> 
> Good question. The problem isn't that FLR isn't advertised or
> unsupported. Rather we end up needing to use the slot reset when the
> platform has put the PCI function in the architected error state which
> blocks both MMIO and DMA similar to DPC and which we can only get out
> of with the platform specific CLP Set PCI Function Disable/Enable
> hypercalls. FLR still works if you have a function that wasn't put in
> the error state but for most real world errors as well as some service
> scenarios we do end up in the error state where a FLR won't work.

I assume these are standard PCIe devices, but this architected error
state doesn't sound like something from the PCIe spec.

DPC works by disabling the link, but of course that blocks traffic to
all the functions of an MFD, so maybe this is some s390-specific thing
outside the endpoint, e.g., something in a Downstream Port that can
selectively block traffic to/from a specific function?

To get to pci_reset_bus_function() where we can use the slot reset, I
think all the previous methods, including pcie_reset_flr(), must have
failed with -ENOTTY.  But I don't see a place that would do that.
Maybe you remove the other methods from dev->reset_methods[]?

In addition to whatever the CLP Set PCI Function Disable/Enable
hypercall does to unblock traffic to/from the endpoint, I suppose it
does an FLR internally?  It must use some standard PCIe mechanism
because the endpoint doesn't know anything about s390 or the
hypervisor.

I wonder if we should make some kind of direct platform-specific reset
method, or maybe a pcibios_*()-style hook in the pcie_reset_flr() path
instead of this somewhat convoluted pci_slot stuff.  But
s390_pci_hpc.c is pretty simple and maybe it's used for things other
than reset.

Bjorn