Hi Balbi,

thanks for your review,

2014-12-30 0:06 GMT+08:00 Felipe Balbi [off-list ref]:

Hi,

On Mon, Dec 29, 2014 at 04:07:50PM +0800, Sneeker Yeh wrote:

quoted

Hi,

2014-12-29 14:41 GMT+08:00 Sneeker Yeh [off-list ref]:

quoted

Hi,

2014-12-22 23:37 GMT+08:00 Felipe Balbi [off-list ref]:

quoted

On Tue, Dec 16, 2014 at 10:10:28AM +0800, Sneeker Yeh wrote:

quoted

Synopsis DesignWare USB3 IP Core integrated with a config-free
phy needs special handling during device disconnection to avoid
the host controller dying.

This quirk makes sure PORT_CSC is cleared after the disable slot
command when usb device is disconnected from internal root hub,
otherwise, Synopsis core would fall into a state that cannot use
any endpoint command. Consequently, device disconnection procedure
might not be finished because sometimes endpoint need to be stop
by endpoint stop command issuing.

Symptom usually happens when disconnected device is keyboard,
mouse, and hub.

you need to point us to the synopsys STARS ticket number. That's the
only way to reference this specific quirk. Add it to a comment
somewhere.

Thanks, we're still waiting for Synopsis STARS ticket number.
I'll add it to comment later.

Sorry I didn't express myself clearly.

So far Fujitsu Semiconductor got Synopsys internal case id , that is "
Case: 8000679552".
However the contents belongs this id cannot be referred except Fujitsu
Semiconductor and Synopsys.
Synopsis decide the official errata (STAR information) will be disclosed
next February.

Would you suggest if this quirk can be accepted with this case ID, or can
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? :
20f6fdd01c2c0de9cc1109083222edded24c5350
b2f463e1300016785d63475c56f5807e2be00934

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.

Much appreciate,
Sneeker

I still have many questions about this patch which are not answered by
commit log nor can I poke around on Synopsys solvnet for answers :-s

--
balbi