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

[Ramesh Errabolu <ramesh@linux.ibm.com>]

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


>
>>