Hi,

2015-01-06 1:09 GMT+08:00 Felipe Balbi [off-list ref]:

Hi,

On Sun, Jan 04, 2015 at 08:55:01PM +0800, Sneeker Yeh wrote:

quoted

quoted

quoted

So far Fujitsu Semiconductor got Synopsys internal case id , that is

"

quoted

quoted

quoted

Case: 8000679552".
However the contents belongs this id cannot be referred except

Fujitsu

quoted

quoted

quoted

Semiconductor and Synopsys.
Synopsis decide the official errata (STAR information) will be

disclosed

quoted

quoted

quoted

next February.

Would you suggest if this quirk can be accepted with this case ID,

or can

quoted

quoted

quoted

only be accepted with STARS ticket number?

The thing is that without the STARS number I can't really verify which
versions of the IP would be affected. Clearly, it's not only your setup
and I think it's pretty unfair to have "is_compatible("fujitsu")" to

just found some way of quirk injection i miss,
does it looks more reasonable if i have to decide to use it via Kconfig?

:

quoted

20f6fdd01c2c0de9cc1109083222edded24c5350
b2f463e1300016785d63475c56f5807e2be00934

We will only use Kconfig for those which can't be detected in runtime.
LPM is one such case as there's no way for SW to detect that core was
configured with LPM Errata, IIRC.

Super thanks, I see.

quoted

quoted

enable the quirk only for you. Isn't there a better way of enabling the
quirk based off of revision detection couple with a look on GHWPARAMS*
registers ?

What's tricking me is this claim that only config-free PHYs would be
affected, why ?

i'm still struggling now to try to get more information about this.
some security policy inside Fujitsu make me unable to access full
information of this errata today.

Someday after i get enough information,
i shall take your suggestion here that seems better to incur quirk
dynamically via GHWPARAMS,
and then send it here again.

ok, hopefully you'll find a way ;-)

I got some update information here finally~

in case i express unclearly i also put a pdf:
https://drive.google.com/file/d/0B18MmcvvKjNNbDF6eEdHSzZCazA/view

This issue is defined by a two-way race at disconnect, between
1) class driver interrupt endpoint resheduling attempts if the ISR gave an
ep error event due to device detach (it would try 3 times)
2) Disconnect interrupt on PORTSC_CSC, which is cleared by hub thread
asynchronously
3) The hardware IP was configured in silicon with
       - DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 (this is an IP configuration
port whose state cannot be checked from software)
       - Synopsys IP version is < 3.00a
       The IP will auto-suspend itself on device detach with some
phy-specific interval after CSC is cleared by 2)

If 2) and 3) complete before 1), the interrupts it expects will not be
generated by the autosuspended IP, leading to a deadlock. Even later
disconnection procedure would detect that corresponding urb is still
in-progress and issue a ep stop command, auto-suspended IP still won't
respond to that command.

this defect would result in this when device detached:
-------------------
[   99.603544] usb 4-1: USB disconnect, device number 2
[  104.615254] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop
endpoint command.
[  104.623362] xhci-hcd xhci-hcd.0.auto: Assuming host is dying, halting
host.
[  104.653261] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000
microseconds.
[  104.660584] xhci-hcd xhci-hcd.0.auto: Non-responsive xHCI host is not
halting.
[  104.667817] xhci-hcd xhci-hcd.0.auto: Completing active URBs anyway.
[  104.674198] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up
--------------------
As a result, when device detached, we desired to postpone "PORTCSC clear"
behind "disable slot". it's found that all executed ep command related to
disconnetion, are executed before "disable slot".

BR,
Sneeker

--
balbi