Message-ID: <2025100805-resisting-target-419a@gregkh>
Date: Wed, 8 Oct 2025 13:08:31 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Akshay Gujar <Akshay.Gujar@...man.com>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	naveen.v@...man.com, sankarkumar.krishnasamy@...man.com,
	oneukum@...e.com
Subject: Re: [PATCH] usb: core: notify unrecognized usb device

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

Powered by blists - more mailing lists