Re: [REGRESSION] Re: [PATCH 0/3] USB: core: Don't overwrite device descriptor during reinitialization

From: Alan Stern <stern@rowland.harvard.edu>
To: "Alexander Dahl" <ada@thorsis.com>,
	"Jan Čermák" <sairon@sairon.cz>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"Khazhy Kumykov" <khazhy@google.com>,
	"USB mailing list" <linux-usb@vger.kernel.org>,
	regressions@lists.linux.dev
Subject: Re: [REGRESSION] Re: [PATCH 0/3] USB: core: Don't overwrite device descriptor during reinitialization
Date: Thu, 28 Mar 2024 12:16:06 -0400	[thread overview]
Message-ID: <b8aeb235-1f07-4acc-bcf8-0e7344cab291@rowland.harvard.edu> (raw)
In-Reply-To: <20240328-fragment-envoy-f2c5bfa5c4ff@thorsis.com>

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