Re: [PATCH v22 1/4] PCI: Allow per function PCI slots to fix slot reset on s390

[Farhan Ali]

On 7/30/2026 5:22 PM, Bjorn Helgaas wrote:
> [+cc Keith, just fyi since this is slightly related to 102c8b26b54e
> ("PCI: Allow all bus devices to use the same slot")]
>
> On Mon, Jul 20, 2026 at 12:25:02PM -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.
> I guess we must be talking about rpaphp?

No, this is the s390_pci_hpc driver.


> > Currently, the pci_create_slot() assigns the same pci_slot object to
> > multifunction devices.
> Can we say something about exactly where and why this reuse happens?
> Is this because most callers have stripped off the function number by
> using PCI_SLOT() before they pass it to pci_create_slot() as @slot_nr?
>
> If so, it seems like more a property of the *callers*, not of
> pci_create_slot() itself.

AFAIU in pci_create_slot() we will iterate through all the devices in 
the bus, and assign the same pci_slot object to devices that falls in 
the same slot as per PCI_SLOT(). So even if a caller provides different 
slot_nr, devices that fall in the same slot will be assigned the same 
object. In s390 hotplug driver case, it provides the devfn as the 
slot_nr. So for example devices with bdf 00:00.0 and bdf 00:00.2 will 
get assigned the same slot, when we create a slot for device 00:00.0. 
When we attempt to create a slot for device 00:00.2, we do indeed create 
a separate slot object, but don't update the device's pci_slot as 
PCI_SLOT(00:00.2) != 2.

I am open to suggestion on how we should re-word this. But i think it's 
pci_create_slot() that strips the devfn to a slot number.

> > This approach worked fine on s390 systems that only
> > exposed virtual functions as individual PCI domains to the operating
> > system.  Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions")
> > s390 supports exposing the topology of multifunction PCI devices by
> > grouping them in a shared PCI domain. This creates a problem when resetting
> > a function through the hotplug driver's slot_reset() interface.
> >
> > When attempting to reset a function through the hotplug driver, the shared
> > slot assignment causes the wrong function to be reset instead of the
> > intended one. It also leaks memory as we do create a pci_slot object for
> > the function, but don't correctly free it in pci_slot_release().
> >
> > Add a flag for struct pci_slot to allow per function PCI slots for
> > functions managed through a hypervisor, which exposes individual PCI
> > functions while retaining the topology. Since we can use all 8 bits for
> > slot 'number' (for ARI devices), change slot 'number' u16 to account for
> > special values -1 and PCI_SLOT_ALL_DEVICES.
> Sorry for the delay in reviewing this.  I always struggle to find
> my way through the PCI slot code, which has grown into a bit of a
> maze.  I keep hoping we can simplify it somehow.  I don't think that
> time is now, but the complexity does make changes messy.

Thank you for reviewing this! I appreciate you taking the time to help 
with the review.


> > Fixes: 44510d6fa0c0 ("s390/pci: Handling multifunctions")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Suggested-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
> > Reviewed-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx>
> > Signed-off-by: Farhan Ali <alifm@xxxxxxxxxxxxx>
> > ---
> >   drivers/pci/hotplug/rpaphp_slot.c |  2 +-
> >   drivers/pci/pci.c                 |  5 +++--
> >   drivers/pci/slot.c                | 33 +++++++++++++++++++++++--------
> >   include/linux/pci.h               |  8 ++++++--
> >   4 files changed, 35 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/pci/hotplug/rpaphp_slot.c b/drivers/pci/hotplug/rpaphp_slot.c
> > index 67362e5b9971..92eabf5f61b9 100644
> > --- a/drivers/pci/hotplug/rpaphp_slot.c
> > +++ b/drivers/pci/hotplug/rpaphp_slot.c
> > @@ -84,7 +84,7 @@ int rpaphp_register_slot(struct slot *slot)
> >   	struct hotplug_slot *php_slot = &slot->hotplug_slot;
> >   	u32 my_index;
> >   	int retval;
> > -	int slotno = -1;
> > +	int slotno = PCI_SLOT_PLACEHOLDER;
> >   
> >   	dbg("%s registering slot:path[%pOF] index[%x], name[%s] pdomain[%x] type[%d]\n",
> >   		__func__, slot->dn, slot->index, slot->name,
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 77b17b13ee61..350bae907ebf 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -4897,8 +4897,9 @@ static int pci_reset_hotplug_slot(struct hotplug_slot *hotplug, bool probe)
> >   
> >   static int pci_dev_reset_slot_function(struct pci_dev *dev, bool probe)
> >   {
> > -	if (dev->multifunction || dev->subordinate || !dev->slot ||
> > -	    dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET)
> > +	if (dev->subordinate || !dev->slot ||
> > +	    dev->dev_flags & PCI_DEV_FLAGS_NO_BUS_RESET ||
> > +	    (dev->multifunction && !dev->slot->per_func_slot))
> >   		return -ENOTTY;
> >   
> >   	return pci_reset_hotplug_slot(dev->slot->hotplug, probe);
> > diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
> > index 6d5cd37bfb1e..894d6213ed30 100644
> > --- a/drivers/pci/slot.c
> > +++ b/drivers/pci/slot.c
> > @@ -37,7 +37,7 @@ static const struct sysfs_ops pci_slot_sysfs_ops = {
> >   
> >   static ssize_t address_read_file(struct pci_slot *slot, char *buf)
> >   {
> > -	if (slot->number == 0xff)
> > +	if (slot->number == (u16)PCI_SLOT_PLACEHOLDER)
> I think it might be worth splitting the PCI_SLOT_PLACEHOLDER addition
> and the relevant kernel-doc updates, which are mostly unrelated to
> this patch, to a separate no-functional-changes patch to simplify this
> patch.

I will take a look at splitting the PCI_SLOT_PLACEHOLDER out of this patch.


> >   		return sysfs_emit(buf, "%04x:%02x\n",
> >   				  pci_domain_nr(slot->bus),
> >   				  slot->bus->number);
> > @@ -72,6 +72,23 @@ static ssize_t cur_speed_read_file(struct pci_slot *slot, char *buf)
> >   	return bus_speed_read(slot->bus->cur_bus_speed, buf);
> >   }
> >   
> > +static bool pci_dev_matches_slot(struct pci_dev *dev, struct pci_slot *slot)
> > +{
> > +	if (slot->per_func_slot)
> > +		return dev->devfn == slot->number;
> > +
> > +	return slot->number == PCI_SLOT_ALL_DEVICES ||
> > +		PCI_SLOT(dev->devfn) == slot->number;
> > +}
> > +
> > +static bool pci_slot_enabled_per_func(void)
> > +{
> > +	if (IS_ENABLED(CONFIG_S390))
> > +		return true;
> > +
> > +	return false;
> > +}
> > +
> >   static void pci_slot_release(struct kobject *kobj)
> >   {
> >   	struct pci_dev *dev;
> > @@ -82,8 +99,7 @@ static void pci_slot_release(struct kobject *kobj)
> >   
> >   	down_read(&pci_bus_sem);
> >   	list_for_each_entry(dev, &slot->bus->devices, bus_list)
> > -		if (slot->number == PCI_SLOT_ALL_DEVICES ||
> > -		    PCI_SLOT(dev->devfn) == slot->number)
> > +		if (pci_dev_matches_slot(dev, slot))
> >   			dev->slot = NULL;
> >   	up_read(&pci_bus_sem);
> >   
> > @@ -187,8 +203,7 @@ void pci_dev_assign_slot(struct pci_dev *dev)
> >   
> >   	mutex_lock(&pci_slot_mutex);
> >   	list_for_each_entry(slot, &dev->bus->slots, list)
> > -		if (slot->number == PCI_SLOT_ALL_DEVICES ||
> > -		    PCI_SLOT(dev->devfn) == slot->number)
> > +		if (pci_dev_matches_slot(dev, slot))
> >   			dev->slot = slot;
> >   	mutex_unlock(&pci_slot_mutex);
> >   }
> Update pci_create_slot() kernel-doc to mention PCI_SLOT_PLACEHOLDER
> instead of "-1" (several instances).
>
> In addition to PCI_SLOT_PLACEHOLDER or PCI_SLOT_ALL_DEVICES, and a
> 0-31 PCI_SLOT(devfn) value, I think @slot_nr can already be a 0-255
> value (e.g., from cpci module parameters or s390
> zpci_bus_add_device()).
>
> It seems like this patch also needs pci_slot.number to end up with a
> complete devfn in it so pci_dev_matches_slot() can use it, but I'm
> confused about how that happens, since it looks like
> rpaphp_register_slot() will pass either PCI_SLOT_PLACEHOLDER or a
> PCI_SLOT(...) value to pci_hp_register().

On s390 it happens via zpci_init_slot() in the 
drivers/pci/hotplug/s390_pci_hpc.c, which assigns a devfn as a slot_nr.


> > @@ -267,7 +282,7 @@ struct pci_slot *pci_create_slot(struct pci_bus *parent, int slot_nr,
> >   
> >   	mutex_lock(&pci_slot_mutex);
> >   
> > -	if (slot_nr == -1)
> > +	if (slot_nr == PCI_SLOT_PLACEHOLDER)
> No action for you here, but one thing that complicates this is the
> overloading of slot_nr for different purposes:
>
>    - Sentinel flags:
>
>      * PCI_SLOT_ALL_DEVICES (0xfe or 0xfeff) used by pciehp init_slot()
>
>      * PCI_SLOT_PLACEHOLDER (-1), used by rpaphp_register_slot()
>
>      * -1 may also be used by pnv_php_alloc_slot(); I don't know
>        exactly what it means
>
>    - Traditional (mostly) PCI device numbers:
>
>      * 0-31 derived by PCI_SLOT() in hv_pci_assign_slots(),
>        octep_hp_register_slot(), pnv_php_alloc_slot(),
>        rpaphp_register_slot()
>
>      * 0-255 from cpci (module parameters)
>
>      * 0-15 from cpq ((u8 from readb(SLOT_MASK) >> 4))
>
>      * 0 from ibmphp_ebda
>
>      * 0-255 from s390 zpci_bus_add_device()
>        (zdev->rid & ZPCI_RID_MASK_DEVFN), where ZPCI_RID_MASK_DEVFN is
>        0xff
>
>      * 0-255 for s390 per-function slots (this series)
>
>    - Arbitrary values:
>
>      * Sparc pcie_bus_slot_names() path uses unvalidated
>        'physical-slot#' DT property as slot_nr
>
>      * acpiphp uses the value of _ADR as slot_nr (per spec it should be
>        device number in bits 16-31, but not validated)
>
> >   		goto placeholder;
> >   
> >   	/*
> > @@ -298,6 +313,9 @@ struct pci_slot *pci_create_slot(struct pci_bus *parent, int slot_nr,
> >   	slot->bus = pci_bus_get(parent);
> >   	slot->number = slot_nr;
> >   
> > +	if (pci_slot_enabled_per_func())
> > +		slot->per_func_slot = 1;
> > +
> >   	slot->kobj.kset = pci_slots_kset;
> >   
> >   	slot_name = make_slot_name(name);
> > @@ -318,8 +336,7 @@ struct pci_slot *pci_create_slot(struct pci_bus *parent, int slot_nr,
> >   
> >   	down_read(&pci_bus_sem);
> >   	list_for_each_entry(dev, &parent->devices, bus_list)
> > -		if (slot_nr == PCI_SLOT_ALL_DEVICES ||
> > -		    PCI_SLOT(dev->devfn) == slot_nr)
> > +		if (pci_dev_matches_slot(dev, slot))
> >   			dev->slot = slot;
> >   	up_read(&pci_bus_sem);
> >   
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 64b308b6e61c..6141787f7417 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -79,14 +79,18 @@
> >    * and, if ARI Forwarding is enabled, functions may appear to be on multiple
> >    * devices.
> >    */
> > -#define PCI_SLOT_ALL_DEVICES	0xfe
> > +#define PCI_SLOT_ALL_DEVICES	0xfeff
> > +
> > +/* Used to identify a slot as a placeholder */
> > +#define PCI_SLOT_PLACEHOLDER	-1
> Since this is eventually assigned to a u16, and you use "0xfeff" for
> PCI_SLOT_ALL_DEVICES, it seems like "0xffff" would be appropriate.
>
> I suppose you used -1 because the arguments to pci_hp_register() all
> the way down to pci_create_slot() are "int" and it's only inside
> pci_create_slot() where it gets chopped to u16 when it's stored in
> pci_slot.number.  But the mix of int/u16 and 0xfeff (a valid u16) and
> -1 (which needs to be int) seems like unnecessary complexity.

I kept it as -1 because it's an int up until pci_create_slot(). I can 
change it to 0xffff.

Thanks

Farhan

> AFAICT the only values we need to *store* in pci_slot are 0-255 and
> the "ALL_DEVICES" indication.
>
> >   /* pci_slot represents a physical slot */
> >   struct pci_slot {
> >   	struct pci_bus		*bus;		/* Bus this slot is on */
> >   	struct list_head	list;		/* Node in list of slots */
> >   	struct hotplug_slot	*hotplug;	/* Hotplug info (move here) */
> > -	unsigned char		number;		/* Device nr, or PCI_SLOT_ALL_DEVICES */
> > +	u16			number;		/* Device nr, or PCI_SLOT_ALL_DEVICES */
> > +	unsigned int		per_func_slot:1; /* Allow per function slot */
> >   	struct kobject		kobj;
> >   };
> >   
> > --
> > 2.43.0