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

[Greg KH <gregkh@linuxfoundation.org>]

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