Hei hei, following this discussion with some kind of curiosity, because I own such a device and depent on it, but my firmware version does not seem to be affected. Remarks below. Am Wed, Mar 27, 2024 at 10:21:19AM -0400 schrieb Alan Stern: > On Wed, Mar 27, 2024 at 02:24:34PM +0100, Jan Čermák wrote: > > Hi Alan, > > > > On 19. 03. 24 17:03, Alan Stern wrote: > > > Change the HUB_DEBOUNCE_TIMEOUT value to 4500, the HUB_DEBOUNCE_STEP > > > value to 250 and the HUB_DEBOUNCE_STABLE value to 2000. That just > > > might give the device enough time to settle down and start working > > > before the computer tries using it. > > > > sorry for the delay, I only managed to test it today. You are right, with > > the timeouts adjusted, it enumerates fine after a while, without any > > descriptor read errors or anything like that: > > > > [ 210.957371] usb 1-1.2: new full-speed USB device number 5 using ehci-pci > > [ 211.037728] usb 1-1.2: New USB device found, idVendor=0658, > > idProduct=0200, bcdDevice= 0.00 > > [ 211.037747] usb 1-1.2: New USB device strings: Mfr=0, Product=0, > > SerialNumber=0 > > [ 211.039764] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device > > Great! > > > If it's worth anything, usbmon trace is attached below. Anyway, do you have > > any ideas what could be done to make it work without doing any detrimental > > changes? I was thinking I'll try to reach out to the vendor at this point - > > they should be aware their device might stop working with recent kernels, > > and they could explain the quirky behavior, or implement any changes on the > > firmware side (if it's even possible). > > The ideal solution would be if the vendor updates the firmware to > prevent the device from turning on its pull-up (thereby telling the > host computer that it is connected to the bus) until it is ready to > operate. There's no good reason to have that > 1-second period during > which the device claims to be connected but does not work. As pointed out in the GitHub ticket already: Firmware update from a users point of view is difficult to impossible. There's no easy "take the latest firmware" and update and you're done. It is not clear which tools are necessary, and even worse there are only certain combinations of upgrade paths. For example upgrading to x.z is only possible from x.x but not from x.y, if I understood it correctly. And you don't know if you will brick the device or not. And I'm speaking as an embedded developer. The ordinary home user is probably not even going to try it. > Another possible solution, a lot less attractive, would be to change > the initialization code in the hub driver so that if it sees the > device disconnect itself from the bus, it restarts the entire > procedure from the beginning. You'd end up getting a bunch of error > messages during the initial non-working period, just as you do now, > but afterwards the device should be detected and initialized okay. Is it possible to hook in with some kind of quirk if this device ID is seen on the bus (and wait longer just for this device), or can you only access that after successful init? Greets Alex
