Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1271054 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc  quirk Dmitry Malkin <DMalkin@ptsecurity.com> - 2015-11-17 11:30 +0100
    Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc  quirk Lu Baolu <baolu.lu@linux.intel.com> - 2015-11-18 12:20 +0100

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

On Mon, 16 Nov 2015 10:18:42 +0800, Lu Baolu wrote:
> This quirk works as well if debug host doesn't have DBC. I didn't try a
> DBC-capable debug host yet.

Hi,

I went through it again, with your v3 patch series on top of vanilla v4.3.0.

Two targets, one host, all with Intel chipset (XHCI device 0:14.0 with VID:8086).
Targets DIDs are 9c31 (8-series chipset) and 9d2f (100-series chipset).
Host DID is 8c31 (8-series).

I can only further confirm my previous observations.  The host cannot
see the target (there is no debug device) at all, until I manually
re-plug a debug cable.  Cable plugged in, prior to starting the target.

I think that trying a Hot Reset for all disconnected USB 3.0 ports on
the debug target *just before* setting DCE bit is inherently racy.

What if the number of disconnected ports changes or if someone will insert
a print statement or refactors your code?

Also sending TS2 to the debug host port will either:
 - get dropped by its hub as unsupported upstream request, or
 - get ignored due to SS.Inactive port state

Could you explain what exactly you workaround does at the low level?

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

[toc] | [next] | [standalone]

#1272094

Hi,

On 11/17/2015 06:28 PM, Dmitry Malkin wrote:
> On Mon, 16 Nov 2015 10:18:42 +0800, Lu Baolu wrote:
>> This quirk works as well if debug host doesn't have DBC. I didn't try a
>> DBC-capable debug host yet.
> Hi,
>
> I went through it again, with your v3 patch series on top of vanilla v4.3.0.
>
> Two targets, one host, all with Intel chipset (XHCI device 0:14.0 with VID:8086).
> Targets DIDs are 9c31 (8-series chipset) and 9d2f (100-series chipset).
> Host DID is 8c31 (8-series).
>
> I can only further confirm my previous observations.  The host cannot
> see the target (there is no debug device) at all, until I manually
> re-plug a debug cable.  Cable plugged in, prior to starting the target.

Thank you for your time.

Are you using a "USB3 debugging cable"? The internal wiring of
the debug cable is crossed over.

> I think that trying a Hot Reset for all disconnected USB 3.0 ports on
> the debug target *just before* setting DCE bit is inherently racy.
>
> What if the number of disconnected ports changes or if someone will insert
> a print statement or refactors your code?

That might be problematic. I will put a comment there.

>
> Also sending TS2 to the debug host port will either:
>   - get dropped by its hub as unsupported upstream request, or
>   - get ignored due to SS.Inactive port state
>
> Could you explain what exactly you workaround does at the low level?

What I though was that reset USB 3.0 ports on debug target before setting
DCE bit will cause debug host to warm reset the port for enumeration
purpose and then setting the DCE bit will take effect.

This just works on my development machine, not only connecting debug
target to root port of host, but also under external hubs. I realized that
this quirk isn't a universal solution and it might not work with some
silicons. But I thought it shouldn't do any harmless. In bad case, users
could plug out and plug in the debug cable, or reset the port through
the sysfs node for workaround. If this is acceptable, I will add this in
the user guide and increase the timeout value in code.

Thanks,
-Baolu

>
> --
> with best regards,
> Dmitry Malkin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web