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

[Leon Romanovsky <leon@kernel.org>]

On Thu, Feb 26, 2026 at 01:31:07PM -0600, Ramesh Errabolu wrote:
> 
> On 2/26/2026 12: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.
> > Right
> > 
> > > Secondly there is no uevent attribute in slot-id directory to submit requests to raise a uevent. This
> > > patch fills that gap
> > Please start from the beginning and explain what you mean by 'the gap'.
> > Which scenario failed before and began working after this patch? From your
> > description, it sounds like the behavior should already be covered by the
> > 'udevadm trigger' command.
> > 
> > I want to note that drivers/pci/slot.c has remained largely unchanged since 2008.
> > 
> > Thanks
> PCI slots are surfaced early in the boot process before udev daemon is able
> to run and process these uevents. As a consequence any uevents raised by PCI
> slots are lost. To apply the relevant udev rules, we need to raise PCI slot
> uevents a second time. This cannot happen if uevent attribute is not surface
> by PCI slots.

I don't understand what you are saying. In previous email, we both
agreed that PCI slots doesn't have uevents and here you are again
repeating that these uevents are lost.

On my system:
➜  ~ ls /sys/bus/pci/slots/
0  12  14  8
➜  ~ ls /sys/bus/pci/slots/0
adapter  address  cur_bus_speed  max_bus_speed  power

> 
> To me the sequence is as follows:
> 
> - udevadm submits a request to raise a PCI Slot uevent
> - PCI slot uevent handler constructs and publishes a uevent to userspace
> - udev daemon receives the uevent and processes it i.e. apply configuration
> encoded by matching udev rules

I asked slightly different question. "Which scenario failed before and
began working after this patch?"

Thanks

> 
>