From: Leon Romanovsky <leon@kernel.org>
To: Peter Oberparleiter <oberpar@linux.ibm.com>
Cc: Ramesh Errabolu <ramesh@linux.ibm.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
Matthew Rosato <mjrosato@linux.ibm.com>,
Gerd Bayer <gbayer@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>
Subject: Re: [PATCH v1] PCI: Add write-only 'uevent' sysfs attribute for PCI slots
Date: Mon, 2 Mar 2026 21:48:44 +0200 [thread overview]
Message-ID: <20260302194844.GU12611@unreal> (raw)
In-Reply-To: <5d30ad0a-9c16-4802-adfe-e795c38f5990@linux.ibm.com>
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
next prev parent reply other threads:[~2026-03-02 19:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 15:08 [PATCH v1] PCI: Add write-only 'uevent' sysfs attribute for PCI slots Ramesh Errabolu
2026-02-26 8:34 ` Leon Romanovsky
2026-02-26 17:53 ` Ramesh Errabolu
2026-02-26 18:39 ` Leon Romanovsky
2026-02-26 19:31 ` Ramesh Errabolu
2026-02-26 19:51 ` Leon Romanovsky
2026-02-26 20:33 ` Ramesh Errabolu
2026-02-27 11:23 ` Peter Oberparleiter
2026-03-02 19:48 ` Leon Romanovsky [this message]
2026-03-06 15:15 ` Niklas Schnelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260302194844.GU12611@unreal \
--to=leon@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=bhelgaas@google.com \
--cc=gbayer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mjrosato@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=ramesh@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.