Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

[Lu Baolu]

Hi,

On 11/13/2015 11:34 PM, Dmitry Malkin wrote:
> On Mon, 9 Nov 2015 15:38:33 +0800, Lu Baolu wrote:
> > On Intel platform, if the debug target is connected with debug
> > host, enabling DCE bit in command register leads to a hung bus
> > state. In the hung state, the host system will not see a port
> > connected status bit set. Hence debug target fails to be probed.
> >
> > The state could be resolved by performing a port reset to the
> > debug port from the host xHCI. This patch introduces this work
> > around.
> Is it correct to call this a "hung bus state"?  Wouldn't calling it
> "hung port state" more appropriate?

Yes, "hung port state" is more appropriate.

> I have observed this DCE-enable-related hung port state,
> but the reason seemed to be different in my case:
>
> Citing a note (sic!) from The Holy XHCI Spec, section 7.6.4.1:
> > If a Debug Host attempts to attach to a Debug Target before the DCE flag is set,
> > both ends of the link shall transition to the Inactive state.
> > So a Debug Host should periodically issue a Warm Reset
> > to ports that are Inactive to enable a connection to the DbC of the Debug Target.

Exactly. A formal workaround is to periodically issue Warm Resets to ports
from debug host.

> Indeed, the inactive state is what I have observed (PLS field of port register PORTSC)
> when the DCE bit is set to 1 with the cable already plugged in.
>
> Now, according to my interpretation of The Hole USB 3.1 spec, section 7.5.2,
> which says:
> > eSS.Inactive is a state where a link has failed Enhanced SuperSpeed operation.
> > A downstream port can only exit from this state when directed, or upon detection of
> > an absence of a far-end receiver termination (R RX-DC ) specified in Table 6-21,
> > or upon a Warm Reset.
> It follows, that since hosts without DBC cannot listen to upstream requests,
> the debug target-originated port reset requests (both hot and warm) will be ignored
> by the debug host.

As above, a formal workaround is to issue Warm Reset periodically from debug
host, but that could cause much complexity. My quirk is to issue port 
reset just
*before* setting DCE bit. This quirk seems to work on several platforms.
(My debug host doesn't have DBC.)

> This is the essence of the "hung port state" that I was able to observe.
>
> Note, that this roadblock doesn't appear if you attach the cable /after/ enabling the DCE bit,

Yes.

> or, alternatively, if the host has DBC.

Really? I haven't tried it yet.

> And indeed, your quirk will work in the latter case, since the debug host hub
> will be able to see the upstream reset request.

This quirk works as well if debug host doesn't have DBC. I didn't try a 
DBC-capable
debug host yet.

> --
> with best regards,
> Dmitry Malkin

Thank you.
-Baolu

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/