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.

The patch was validated by manually triggering PCI slot 'add'
uevents through the slot’s 'uevent' sysfs file and confirming
that udev received and processed those events. The following
command raises an 'add' uevent for a specific PCI slot:

    $ echo "add $(uuidgen)" | sudo tee   \
                /sys/bus/pci/slots/<slot-id>/uevent

Signed-off-by: Ramesh Errabolu <ramesh@linux.ibm.com>
---
 drivers/pci/slot.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
index 787311614e5b..cbc7cf6ab7ad 100644
--- a/drivers/pci/slot.c
+++ b/drivers/pci/slot.c
@@ -63,6 +63,15 @@ static ssize_t cur_speed_read_file(struct pci_slot *slot, char *buf)
 	return bus_speed_read(slot->bus->cur_bus_speed, buf);
 }
 
+static ssize_t uevent_write_file(struct pci_slot *slot,
+				 const char *buf, size_t len)
+{
+	int rc;
+
+	rc = kobject_synth_uevent(&slot->kobj, buf, len);
+	return rc ? rc : len;
+}
+
 static void pci_slot_release(struct kobject *kobj)
 {
 	struct pci_dev *dev;
@@ -89,11 +98,14 @@ static struct pci_slot_attribute pci_slot_attr_max_speed =
 	__ATTR(max_bus_speed, S_IRUGO, max_speed_read_file, NULL);
 static struct pci_slot_attribute pci_slot_attr_cur_speed =
 	__ATTR(cur_bus_speed, S_IRUGO, cur_speed_read_file, NULL);
+static struct pci_slot_attribute pci_slot_attr_uevent =
+	__ATTR(uevent, S_IWUSR, NULL, uevent_write_file);
 
 static struct attribute *pci_slot_default_attrs[] = {
 	&pci_slot_attr_address.attr,
 	&pci_slot_attr_max_speed.attr,
 	&pci_slot_attr_cur_speed.attr,
+	&pci_slot_attr_uevent.attr,
 	NULL,
 };
 ATTRIBUTE_GROUPS(pci_slot_default);
-- 
2.43.0

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

> 
> The patch was validated by manually triggering PCI slot 'add'
> uevents through the slot’s 'uevent' sysfs file and confirming
> that udev received and processed those events. The following
> command raises an 'add' uevent for a specific PCI slot:
> 
>     $ echo "add $(uuidgen)" | sudo tee   \
>                 /sys/bus/pci/slots/<slot-id>/uevent
> 
> Signed-off-by: Ramesh Errabolu <ramesh@linux.ibm.com>
> ---
>  drivers/pci/slot.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
> index 787311614e5b..cbc7cf6ab7ad 100644
> --- a/drivers/pci/slot.c
> +++ b/drivers/pci/slot.c
> @@ -63,6 +63,15 @@ static ssize_t cur_speed_read_file(struct pci_slot *slot, char *buf)
>  	return bus_speed_read(slot->bus->cur_bus_speed, buf);
>  }
>  
> +static ssize_t uevent_write_file(struct pci_slot *slot,
> +				 const char *buf, size_t len)
> +{
> +	int rc;
> +
> +	rc = kobject_synth_uevent(&slot->kobj, buf, len);
> +	return rc ? rc : len;
> +}
> +
>  static void pci_slot_release(struct kobject *kobj)
>  {
>  	struct pci_dev *dev;
> @@ -89,11 +98,14 @@ static struct pci_slot_attribute pci_slot_attr_max_speed =
>  	__ATTR(max_bus_speed, S_IRUGO, max_speed_read_file, NULL);
>  static struct pci_slot_attribute pci_slot_attr_cur_speed =
>  	__ATTR(cur_bus_speed, S_IRUGO, cur_speed_read_file, NULL);
> +static struct pci_slot_attribute pci_slot_attr_uevent =
> +	__ATTR(uevent, S_IWUSR, NULL, uevent_write_file);
>  
>  static struct attribute *pci_slot_default_attrs[] = {
>  	&pci_slot_attr_address.attr,
>  	&pci_slot_attr_max_speed.attr,
>  	&pci_slot_attr_cur_speed.attr,
> +	&pci_slot_attr_uevent.attr,
>  	NULL,
>  };
>  ATTRIBUTE_GROUPS(pci_slot_default);
> -- 
> 2.43.0
> 
> 

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. Secondly there is no uevent 
attribute in slot-id directory to submit requests to raise a uevent. 
This  patch fills that gap

>
>> The patch was validated by manually triggering PCI slot 'add'
>> uevents through the slot’s 'uevent' sysfs file and confirming
>> that udev received and processed those events. The following
>> command raises an 'add' uevent for a specific PCI slot:
>>
>>      $ echo "add $(uuidgen)" | sudo tee   \
>>                  /sys/bus/pci/slots/<slot-id>/uevent
>>
>> Signed-off-by: Ramesh Errabolu <ramesh@linux.ibm.com>
>> ---
>>   drivers/pci/slot.c | 12 ++++++++++++
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/pci/slot.c b/drivers/pci/slot.c
>> index 787311614e5b..cbc7cf6ab7ad 100644
>> --- a/drivers/pci/slot.c
>> +++ b/drivers/pci/slot.c
>> @@ -63,6 +63,15 @@ static ssize_t cur_speed_read_file(struct pci_slot *slot, char *buf)
>>   	return bus_speed_read(slot->bus->cur_bus_speed, buf);
>>   }
>>   
>> +static ssize_t uevent_write_file(struct pci_slot *slot,
>> +				 const char *buf, size_t len)
>> +{
>> +	int rc;
>> +
>> +	rc = kobject_synth_uevent(&slot->kobj, buf, len);
>> +	return rc ? rc : len;
>> +}
>> +
>>   static void pci_slot_release(struct kobject *kobj)
>>   {
>>   	struct pci_dev *dev;
>> @@ -89,11 +98,14 @@ static struct pci_slot_attribute pci_slot_attr_max_speed =
>>   	__ATTR(max_bus_speed, S_IRUGO, max_speed_read_file, NULL);
>>   static struct pci_slot_attribute pci_slot_attr_cur_speed =
>>   	__ATTR(cur_bus_speed, S_IRUGO, cur_speed_read_file, NULL);
>> +static struct pci_slot_attribute pci_slot_attr_uevent =
>> +	__ATTR(uevent, S_IWUSR, NULL, uevent_write_file);
>>   
>>   static struct attribute *pci_slot_default_attrs[] = {
>>   	&pci_slot_attr_address.attr,
>>   	&pci_slot_attr_max_speed.attr,
>>   	&pci_slot_attr_cur_speed.attr,
>> +	&pci_slot_attr_uevent.attr,
>>   	NULL,
>>   };
>>   ATTRIBUTE_GROUPS(pci_slot_default);
>> -- 
>> 2.43.0
>>
>>

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

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

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

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

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.

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

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

> 
> 

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


>
>>