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

[Ramesh Errabolu]

On 2/26/2026 1:51 PM, Leon Romanovsky wrote:
> 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

Thanks for taking time to review. Will  use your example to elaborate. 
Will reference slot 3

Requirement:
  - Be able to define a udev rule to match a PCI slot uevent
   - Enable or Disable a PCI device

Before:
  - PCI slot 3 raises a uevent during boot
  - This uevent is lost i.e. occurs before udevd begins to run
  - Need to resurface uevents arises
  - PCI slot 3 could not raise a uevent on demand
  - udevd could not match any udev rule as there are no uevents

With The Patch:
  - The raising of uevent during boot and it loss continues
  - PCI slot 3 CAN RAISE a uevent on demand
  - This is made possible by uevent attribute
  - udevd could match a udev rule and apply defined configuration


> > 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

Before you could not match a udev rule that could be applied. The patch 
if approved will allow this capability


> >