Re: [PATCH v4] usb: core: hub: Add quirks for reducing device address timeout

Greg KH
2023-10-21T10:16:17Z

On Tue, Oct 17, 2023 at 02:59:54PM -0400, Alan Stern wrote:
> On Tue, Oct 17, 2023 at 06:53:44PM +0200, Greg KH wrote:
> > On Tue, Oct 17, 2023 at 06:10:21PM +0200, Hardik Gajjar wrote:
> > > More logs and detailed in patch V1:
> > > https://lore.kernel.org/linux-usb/20230818092353.124658-1-hgajjar@de.adit-jv.com/T/#m452ec9dad94e8181fdb050cd29483dd89437f7c1
> > > >
> > > > > Achieving this is impossible in scenarios where the set_address is
> > > > > not successful and waits for a timeout.
> > > >
> > > > Agreed, broken hardware is a pain, but if your device is allowed to take
> > > > longer, it can, and will, so you have to support that.
> > > >
> > > The problem is not caused by the device taking an extended amount of time to
> > > process the 'set_address' request. Instead, the issue lies in the absence of
> > > any activity on the upstream bus until a timeout occurs.
> >
> > So, a broken device. Why are you then adding the hub to the quirk list
> > and not the broken device? We are used to adding broken devices to
> > qurik lists all the time, this shouldn't be new.
>
> Adding a quirk for the device isn't feasible, because the problem occurs
> before the device has been initialized and enumerated. The kernel
> doesn't know anything about the device at this point; only that it has
> just connected.

Ah, ick, you are right, but we do know the "broken hub" id, so that
makes a bit more sense. Should this be a hub-only type quirk?

> > > This situation arises when the host has already transmitted the 'set_address' command to the hub,
> > > assuming that the device operates at full speed. However, the device connected
> > > to the hub undergoes a state change from full speed to high-speed during this process.
> >
> > During which process? While the set-address happens? That feels like a
> > hub bug then.
> >
> > > > > The shortened address device timeout quirks provide the flexibility
> > > > > to align with a 3-second time limit in the event of errors.
> > > > > By swiftly triggering a failure response and swiftly initiating
> > > > > retry procedures, these quirks ensure efficient and rapid recovery,
> > > > > particularly in automotive contexts where rapid smartphone enumeration
> > > > > and screen projection are vital.
> > > >
> > > > Screen projection is a requirement that you should not be relying on USB
> > > > for as USB has a different set of required timeouts, right? This sounds
> > > > like a bad hardware design, if not an impossible one.
> > > >
> > >
> > > Screen projection for us means displaying the connected phone on the screen and
> > > launching Carplay and Android Auto for the user. This works perfectly in nearly all
> > > cases, except in scenarios like this one where a combination of a special hub and
> > > a specific phone model is causing the issue
> >
> > So which is broken, the hub or phone?
>
> It sounds like both of them are broken to some extent, although we can't
> tell for sure without seeing what's actually happening on the USB bus
> (i.e., bus analyzer output):
>
> The phone seems to take too long to activate its high-speed
> terminations and deactivate the full-speed terminations.
>
> The hub doesn't seem to realize that the phone has disconnected
> its full-speed connection and switched to high-speed.
>
> But without real data, these are just best guesses.

Agreed, Hardik, can you look at some bus traces to figure out where the
root problem here is?

thanks,

greg k-h