From: Greg KH <gregkh@linuxfoundation.org>
To: Akshay Gujar <Akshay.Gujar@harman.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
naveen.v@harman.com, sankarkumar.krishnasamy@harman.com,
oneukum@suse.com
Subject: Re: [PATCH] usb: core: notify unrecognized usb device
Date: Wed, 8 Oct 2025 13:08:31 +0200 [thread overview]
Message-ID: <2025100805-resisting-target-419a@gregkh> (raw)
In-Reply-To: <20250918172355.5118-1-Akshay.Gujar@harman.com>
On Thu, Sep 18, 2025 at 05:23:55PM +0000, Akshay Gujar wrote:
> >On Sat, Sep 6, 2025 14:28:37AM +0200, Greg KH wrote:
>
> > >>> As per the usb compliance, USB-IF enforces a "no silent failure" rule.
> > >>> This means that an implementation of USB must not appear broken to the
> > >>> consumer. In configurations where the consumer's expectations are not
> > >>> met, either the peripheral or host must provide appropriate and useful
> > >>> feedback to the consumer regarding the problem.
> > >>>
> > >>> Link: https://compliance.usb.org/index.asp?UpdateFile=Embedded%20Host&Format=Standard#10
> > >
> > >Odd, many Linux devices have passed usb-if testing since 2005 when this
> > >was made a "rule", how did that happen? What recently changed to
> > >suddenly require this be a kernel issue?
> > >
> > > Previously, OEMs handled this with private kernel patches or custom modifications.
> > > However, with Android's Generic Kernel Image (GKI) initiative, vendors can no longer make arbitrary kernel modifications.
> > > GKI requires using a common upstream kernel, so functionality like this needs to be up streamed rather than handled with vendor-specific patches.
> > > This patch provides a standard upstream solution for what was previously handled with custom kernel modifications.
>
> > That's good, but that does not mean that what you are attempting to do
> > really is the correct thing to do. Here you were trying to say that
> > this is a requirement of USB-IF, but it really is not. This is just
> > wanting to add a new feature to the USB core that previously was only
> > out-of-tree for your devices. Please be more specific in your
> > description of the problem and issues involved.
>
> To clarify, this patch targets two needs:
> it helps with USB-IF compliance testing (where enumeration failures must be visible to userspace),
Why must it be visible to userspace? How have we passed testing before
now?
> and it provides a generic mechanism for userspace to be notified of USB enumeration failures,
> which is currently missing in the USB core. This solution standardizes the notification,
> especially important for Android GKI and similar environments.
But there is no user for this new user/kernel api anywhere. Android
does not do this today, what is the chance it really will use it? Do
you have working patches somewhere that will land if this is added?
And where is any of this being documented? :)
> >> that is probably not true. For once you can try another cable in many cases.
> >> Currently we'd log this information. That is a worse way to handle this kind
> >> of failure.
> >> If there is an unrecoverable IO error, user space ought to be notified.
> >> Syslog is not the best way to do so. There ought to be a standardized way
> >> of doing this. However, this makes me say that this issue is not really
> >> confined to USB. Other hotpluggable busses have the same issue.
>
> >Yes, all busses have this type of issue for when devices can not be
> >enumerated or fail. We shouldn't make something that only works for
> >USB. I think PCI reports this type of thing somehow, so maybe
> >generalize that api?
>
> Agreed, this is a broader issue across hotpluggable busses. Generalizing the API to cover enumeration failures for USB, PCI, and others would be ideal.
> For now, this patch addresses USB specifically due to immediate needs.
Great, but again, why not make it generic so that all can use it?
Otherwise we end up with a USB-specific solution that no one else can
ever use in the future.
thanks,
greg k-h
prev parent reply other threads:[~2025-10-08 11:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250221102949.1135849-1-Akshay.Gujar@harman.com>
2025-02-21 10:53 ` [PATCH] usb: core: notify unrecognized usb device Greg KH
[not found] ` <20250826165244.22283-1-Akshay.Gujar@harman.com>
2025-09-06 12:28 ` Greg KH
2025-09-08 8:58 ` Oliver Neukum
2025-09-08 9:04 ` Greg KH
[not found] ` <20250918172355.5118-1-Akshay.Gujar@harman.com>
2025-10-08 11:08 ` Greg KH [this message]
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=2025100805-resisting-target-419a@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Akshay.Gujar@harman.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=naveen.v@harman.com \
--cc=oneukum@suse.com \
--cc=sankarkumar.krishnasamy@harman.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).