Re: [PATCH v1] PCI: Add write-only 'uevent' sysfs attribute for PCI slots

[Niklas Schnelle <schnelle@linux.ibm.com>]

On Mon, 2026-03-02 at 21:48 +0200, Leon Romanovsky wrote:
> On Fri, Feb 27, 2026 at 12:23:03PM +0100, Peter Oberparleiter wrote:
> > On 2/26/2026 7:39 PM, Leon Romanovsky wrote:
> > > On Thu, Feb 26, 2026 at 11:53:32AM -0600, Ramesh Errabolu wrote:
> > > > On 2/26/2026 2:34 AM, Leon Romanovsky wrote:
> > > > > On Wed, Feb 25, 2026 at 09:08:15AM -0600, Ramesh Errabolu wrote:
> > > > > > Add a new write-only 'uevent' attribute to PCI slot sysfs
> > > > > > entries. This provides a mechanism for userspace to explicitly
> > > > > > synthesize PCI slot uevents when needed.
> > > > > > 
> > > > > > For cold-plugged PCI devices, slots may be created before
> > > > > > udev is ready to receive events, causing the initial 'add'
> > > > > > uevents to be missed. As a result, slot specific udev
> > > > > > rules that define naming, permissions, and related policies,
> > > > > > are not applied at boot. Allowing userspace to resynthesize
> > > > > > the 'add' uevent ensures these rules are processed correctly.
> > > > > This patch sounds like a hack to me. AFAIK, "udevadm trigger"
> > > > > performs exactly that.
> > > > > 
> > > > > Thanks
> > > > 
> > > > AFAIK, PCI slots do not yet raise a uevent. 
> > 
> > That is only partially true. PCI slots are represented in sysfs by a
> > kobject (pci_slot.kobj) and pci_hotplug_core generates uevents for these
> > kobjects during pci_hp_add() [1].
> > 
> > Here is an example for these uevents:
> > 
> > KERNEL[62021.190266] add      /bus/pci/slots/000018d0 (slots)
> > ACTION=add
> > DEVPATH=/bus/pci/slots/000018d0
> > SUBSYSTEM=slots
> > SEQNUM=1638
> > 
> > KERNEL[62032.304390] remove   /bus/pci/slots/000018d0 (slots)
> > ACTION=remove
> > DEVPATH=/bus/pci/slots/000018d0
> > SUBSYSTEM=slots
> > SEQNUM=1682
> > 
> > On s390 there is a use case for reacting to these events via udev rules,
> > namely to persistently apply a user-specified, per-slot power state.
> 
> But the component that issues the uevent should create this file.
> In your example, it is the hotplug code that must provide a writable
> file, isn't it?
> 
> Thanks

Sorry for the late reply, I was out last week and then missed your
follow up as it seems I was erroneously neither on Cc nor To for the
series.

Good point, after all a non-hotplug slot would also not have no reason
to create such events. Moreover the hotplug code does have attributes
already in particular the 'power' attribute. We will look into this.

Thanks,
Niklas