I have been trying to identify the chips that I have in some way, but as I do not have a big sampling or more information, it is difficult. And I have verified again the datasheets for CSR (Qualcomm) and they do not comment anything related to the problem. All the devices contain this information: manufacturer 10 hci_rev 22bb lmp_subver 22bb hci_ver 6 (BLUETOOTH_VER_4_0) And two of them contain bcdDevice=88.91 (Trust and unknown) and the other 75.58 (EDR) Following the code and comments to detect fakes in btusb.c, the devices are correct although it comments that 0x7558, 0x8891 are known fake bcdDevices. In fact, the unconfigure issue is the only problem that I have found. So, I think the only solution, at least to be able to work, would be to add the user quirk with the patch. Of course, if you consider. Thanks again Best regards José Ignacio On Fri, May 13, 2022 at 4:58 PM Jose Ignacio Tornos Martinez <jtornosm@xxxxxxxxxx> wrote: > > >> 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 > >
