Re: [PATCHv3 2/4] pci: allow all bus devices to use the same slot

[<dan.j.williams@intel.com>]

Keith Busch wrote:
> On Tue, Feb 10, 2026 at 12:00:56PM -0800, dan.j.williams@intel.com wrote:
> > Keith Busch wrote:
> > 
> > > this new feature is 0xfe. This will not clash with any actual slot
> > > number since they are limited to 5 bits.
> > 
> > Can you say a bit more about why other hotplug controller drivers can
> > continue to get away with a single device number as a hotplug slot
> > target?  For example, would you expect that the ACPI hotplug driver is
> > broken if an ARI device is added?
> 
> Right, I don't think acpiphp would work correctly for such a device. I
> didn't change that out an abundance of caution to not introduce
> regressions to platforms I can't readily test.
> 
> I've limited this patch to pciehp since that's the only hotplug driver
> that hard-codes the "devnr" value to 0, and ensures there's only one
> pciehp "hotplug_slot" per bridge. pciehp is uniquely clear that this
> patch is safe.
>
> The remaining hotplug_slot users derive devnr and can make additional
> hotplug_slots for each device on the bus, so I can't tell if it is safe
> to make the others subscribe to this proposed behavior.

Ok, I figured as much, maybe just put these notes in the changelog.

> > It looks like the goal of this sentinel is to turn all
> > pci_try_reset_slot() into pci_try_reset_bus() only for the native PCIe
> > hotplug controller, or did I miss a detail?
> 
> Yes, pretty much that. Since every device on the subordinate bus belongs
> to the same pciehp slot now, we'll get the same locking, notification,
> and state restore as what pci_try_reset_bus() does.
>  
> > > @@ -41,6 +41,10 @@ static ssize_t address_read_file(struct pci_slot *slot, char *buf)
> > >  		return sysfs_emit(buf, "%04x:%02x\n",
> > >  				  pci_domain_nr(slot->bus),
> > >  				  slot->bus->number);
> > > +	if (slot->number == PCI_SLOT_ALL_DEVICES)
> > > +		return sysfs_emit(buf, "%04x:%02x:00\n",
> > > +				  pci_domain_nr(slot->bus),
> > > +				  slot->bus->number);
> > 
> > Why not treat the PCI_SLOT_ALL_DEVICES case the same as the 0xff case?
> 
> Just preserving backward compatibility with what this file would show
> for pciehp slots prior to this patch.

Makes sense, perhaps a comment:

/*
 * Preserve legacy ABI expectations that hotplug drivers that manage
 * multiple devices per slot emit 0 for the device number.
 */

...just to remember that this is due to caution.

With that you can add:

Reviewed-by: Dan Williams <dan.j.williams@intel.com>