Re: [PATCH v5] USB: core: skip unconfiguration if device doesn't support it

[Alan Stern <stern@rowland.harvard.edu>]

On Fri, May 13, 2022 at 04:13:07PM +0200, Greg KH wrote:
> On Fri, May 13, 2022 at 10:09:26AM -0400, Alan Stern wrote:
> > On Fri, May 13, 2022 at 11:50:26AM +0200, Jose Ignacio Tornos Martinez wrote:
> > > Ok, I will try to identify the "bad" devices in some way.
> > > 
> > > Thanks
> > > 
> > > José Ignacio
> > > 
> > > 
> > > On Thu, May 12, 2022 at 1:48 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > I'll drop this for now as there are no in-kernel users for this quirk
> > > > yet.  When there is a need for one, please resubmit it.
> > 
> > Hold on; Greg's comment doesn't seem fair.  There are no in-kernel 
> > users for this quirk because it is meant to be a user API.  (Just as 
> > there are no in-kernel users for read(2) -- it is there so that 
> > userspace can call it).
> 
> True, but the kernel calls read(2) itself as well in places, it just
> looks a bit different, kernel_read_file()  :)

Okay, but you get the point.  :-)

> > Jose does have users for the new quirk: Anybody with one of the bad 
> > Bluetooth CSR knockoff chips.  Now I agree; it would be great if there 
> > was some way to identify them automatically.  But if that's not 
> > possible, the only alternative is to allow userspace to set the quirk 
> > flag whenever it knows the quirk is needed.
> 
> Is that the case here that we know how to identify this?  I thought
> Marcel said something else was happening here.
> 
> If the bluetooth developers/maintainers say this is needed for some
> devices to work properly and they will be handled in userspace somehow
> through a udev rule or the like, I will gladly add this.  But I thought
> this thread died out as it was determined that this wasn't needed at
> this point in time which is why I dropped it.

It's kind of an odd situation.  In ordinary usage the device works okay.  
But it stops working after it has been exported over usbip; that is what 
Jose wants to fix.

Come to think of it, maybe there is a simple workaround.  If userspace 
resets the device after it is unconfigured, there's a good chance that 
will get it to start working again.  Jose, can you try this?  There is a 
usbreset program you can use, floating around on the web.  (Greg, did 
that program or something like it ever get added to the usbutils 
package?)

I don't know how much attention the bluetooth people have given to this 
issue so far.  Marcel should be able to provide more information.

Alan Stern