Subject: Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc
 quirk
To: Dmitry Malkin <DMalkin@ptsecurity.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>
References: <1447425637180.84662@ptsecurity.com>
 <1447428842332.88038@ptsecurity.com>
From: Lu Baolu <baolu.lu@linux.intel.com>
Message-ID: <56493D02.8020204@linux.intel.com>
Date: Mon, 16 Nov 2015 10:18:42 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <1447428842332.88038@ptsecurity.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3276
Lines: 88

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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/