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
prev parent reply other threads:[~2024-03-28 16:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6eadec91-990a-4fbd-8883-8366c4a4d8e4@rowland.harvard.edu>
2024-03-05 8:20 ` [REGRESSION] Re: [PATCH 0/3] USB: core: Don't overwrite device descriptor during reinitialization Jan Čermák
2024-03-06 21:08 ` Alan Stern
2024-03-07 16:17 ` Jan Čermák
2024-03-07 19:34 ` Alan Stern
2024-03-11 9:58 ` Jan Čermák
2024-03-11 14:43 ` Alan Stern
2024-03-12 8:57 ` Jan Čermák
2024-03-12 20:47 ` Alan Stern
2024-03-16 20:35 ` Alan Stern
2024-03-19 11:54 ` Jan Čermák
2024-03-19 16:03 ` Alan Stern
2024-03-27 13:24 ` Jan Čermák
2024-03-27 14:21 ` Alan Stern
2024-03-28 15:44 ` Alexander Dahl
2024-03-28 16:16 ` Alan Stern [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8aeb235-1f07-4acc-bcf8-0e7344cab291@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=ada@thorsis.com \
--cc=gregkh@linuxfoundation.org \
--cc=khazhy@google.com \
--cc=linux-usb@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=sairon@sairon.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).