On Thu, Mar 28, 2024 at 04:44:26PM +0100, Alexander Dahl wrote: > 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. > > 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. Oh, okay. Too bad. Although in many cases, manufacturers tend not to be eager to change their devices' firmwares just to suit Linux users... > > 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? The latter, unfortunately. Before initialization there's no way to communicate with the device. Alan Stern
