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

[Peter Oberparleiter]

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.

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

The problem is that PCI slots registered during early boot generate
uevents before udevd is running, therefore no udev rule is triggered for
them. While systemd re-triggers early uevents after udevd was started
via a call to `udevadm trigger`, udevadm relies on the existence of
writable "uevent" sysfs attributes [2] to generate these replay events.

Driver model code automatically creates "uevent" attributes for struct
devices (such as pci_dev.dev) and struct drivers, but there is no such
automatism for kobjects like pci_slot.kobj. As a result, early uevents
are missed by `udevadm trigger` and the per-slot udev rules are ineffective.

This patch tries to resolve the issue by adding the "uevent" sysfs
attribute for PCI slots. Another patch is required in systemd/udevadm to
also consider these newly added "uevent" attributes during sysfs
enumeration.

> I want to note that drivers/pci/slot.c has remained largely unchanged since 2008.

The requirement to be able to consume PCI slot uevents existed for some
time on s390. This was previously addressed via crude workarounds using
boot scripts [3] but with PCI usage increasing on recent s390 hardware,
the lack of a proper solution is turning into a real limitation.


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/hotplug/pci_hotplug_core.c#n424
[2]
https://github.com/systemd/systemd/blob/main/src/libsystemd/sd-device/sd-device.c#L2796
[3]
https://github.com/ibm-s390-linux/s390-tools/blob/master/zdev/dracut/95zdev/parse-zdev.sh#L48

-- 
Peter Oberparleiter
Linux on IBM Z Development - IBM Germany R&D