>> 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?) > Yes, it is in the usbutils package. I don't think many distros package > the prebuilt binary, but the .c file can be found here: > https://github.com/gregkh/usbutils/blob/master/usbreset.c Of course, I can also try that way and I will comment on the result. I would like to identify in some way, I have some ideas related to the initial configuration but I have to research more. If not possible, if there is a user workaround like this, it would be great. Thank you very much José Ignacio On Fri, May 13, 2022 at 4:46 PM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, May 13, 2022 at 10:26:02AM -0400, Alan Stern wrote: > > 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@xxxxxxxxxxxxxxxxxxx> 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?) > > Yes, it is in the usbutils package. I don't think many distros package > the prebuilt binary, but the .c file can be found here: > https://github.com/gregkh/usbutils/blob/master/usbreset.c >
