From: Akshay Gujar <Akshay.Gujar@harman.com>
To: <gregkh@linuxfoundation.org>
Cc: <Akshay.Gujar@harman.com>, <linux-kernel@vger.kernel.org>,
<linux-usb@vger.kernel.org>, <naveen.v@harman.com>,
<oneukum@suse.com>, <stern@rowland.harvard.edu>
Subject: Re: [PATCH v5 2/3] Documentation: ABI: document DEVICE_ENUMERATION_FAILURE uevent
Date: Fri, 24 Jul 2026 22:25:06 +0000 [thread overview]
Message-ID: <20260724222506.471475-1-Akshay.Gujar@harman.com> (raw)
In-Reply-To: <2026071745-ambulance-reload-4e29@gregkh>
On Fri, Jul 17, 2026 at 12:37:32PM +0200, Greg KH wrote:
> > Document the DEVICE_ENUMERATION_FAILURE environment variable emitted
> > in KOBJ_CHANGE uevents when device enumeration fails.
> >
> > Signed-off-by: Akshay Gujar <Akshay.Gujar@harman.com>
> > ---
> > Documentation/ABI/testing/sysfs-uevent | 25 +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-uevent b/Documentation/ABI/testing/sysfs-uevent
> > index 0b6227706b35e..e362c34aa2ef6 100644
> > --- a/Documentation/ABI/testing/sysfs-uevent
> > +++ b/Documentation/ABI/testing/sysfs-uevent
> > @@ -49,3 +49,28 @@ Description:
> >
> > Users:
> > udev, userspace tools generating synthetic uevents
> > +
> > +What: DEVICE_ENUMERATION_FAILURE
> > +Date: July 2026
> > +KernelVersion: 7.3
> > +Description:
> > + Some devices may be detected but fail to enumerate
> > + due to protocol-level errors or invalid responses.
> > +
> > + A KOBJ_CHANGE uevent includes the following environment
> > + variable when this occurs:
> > +
> > + DEVICE_ENUMERATION_FAILURE=<dev_name>
> > +
> > + The value is the kernel device name of the device for
> > + which enumeration failed, as returned by dev_name().
> > +
> > + Example (USB):
> > +
> > + ACTION=change
> > + SUBSYSTEM=usb
> > + DEVTYPE=usb_interface
>
> This will be the port device, not the usb interface, right?
No, DEVTYPE=usb_interface is correct, the example was captured on
real hardware. The uevent is not emitted from the port device itself.
usb_port devices have no bus or class, so dev_uevent_filter()
drops any event from them.It is emitted from the port's parent,
the hub's usb_interface device, while the failing port is identified in the payload instead.
Per your feedback on patch 1/3, In v6, this becomes explicit in the API.
The caller passes the emitting device and the failed identifier as
separate arguments. I will also reword the Description to make clear
that the value is a bus-specific identifier of the port or slot that
failed to enumerate, not the name of the emitting device, so the
example cannot be misread.
> > + DEVICE_ENUMERATION_FAILURE=usb1-port1
>
> That looks right.
>
> > +
> > +Users:
> > + udev, userspace tools monitoring device enumeration failures
> > \ No newline at end of file
>
> Didn't checkpatch complain about this?
checkpatch did not flag it. Will fix the missing newline at EOF in v6.
> And is there actually udev code to handle this being proposed anywhere?
We currently consume this uevent via a netlink listener to show
system popups/notifications when device enumeration fails. Once the kernel
ABI stabilizes, a default udev rule example will be submitted separately.
Thanks,
Akshay
next prev parent reply other threads:[~2026-07-24 22:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 11:40 [PATCH v5 0/3] driver core: add enumeration failure uevent helper Akshay Gujar
2026-07-15 11:40 ` [PATCH v5 1/3] driver core: add device_enumeration_failure_notify() helper Akshay Gujar
2026-07-17 10:40 ` Greg KH
2026-07-24 22:22 ` Akshay Gujar
2026-07-15 11:40 ` [PATCH v5 2/3] Documentation: ABI: document DEVICE_ENUMERATION_FAILURE uevent Akshay Gujar
2026-07-17 10:37 ` Greg KH
2026-07-24 22:25 ` Akshay Gujar [this message]
2026-07-25 5:21 ` Greg KH
2026-07-27 13:32 ` Akshay Gujar
2026-07-27 19:31 ` Greg KH
2026-07-15 11:40 ` [PATCH v5 3/3] usb: hub: send enumeration failure uevent Akshay Gujar
2026-07-17 10:35 ` [PATCH v5 0/3] driver core: add enumeration failure uevent helper Greg KH
2026-07-24 22:26 ` Akshay Gujar
2026-07-26 23:14 ` Michal Pecio
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=20260724222506.471475-1-Akshay.Gujar@harman.com \
--to=akshay.gujar@harman.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=naveen.v@harman.com \
--cc=oneukum@suse.com \
--cc=stern@rowland.harvard.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®