linux-kernel - Re: [RFC][PATCH] HACK: usb: dwc2: Workaround case where GOTGCTL state is wrong

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALAqxLWnPDhwH+6kYBv47nNFVK_bR7tsz18No015m8zedMQSyQ@mail.gmail.com>
Date:   Thu, 8 Dec 2016 23:32:23 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Chen Yu <chenyu56@...wei.com>
Cc:     John Youn <John.Youn@...opsys.com>,
        Biggo Wang <wangbinghui@...ilicon.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Wei Xu <xuwei5@...ilicon.com>,
        Guodong Xu <guodong.xu@...aro.org>,
        Amit Pundir <amit.pundir@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Douglas Anderson <dianders@...omium.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [RFC][PATCH] HACK: usb: dwc2: Workaround case where GOTGCTL state
 is wrong

On Thu, Dec 8, 2016 at 11:09 PM, Chen Yu <chenyu56@...wei.com> wrote:
> On 2016/12/9 7:29, John Youn wrote:
>> On 12/8/2016 2:43 PM, John Stultz wrote:
>>> On Tue, Dec 6, 2016 at 7:52 PM, John Youn <John.Youn@...opsys.com> wrote:
>>>> On 12/6/2016 5:48 PM, John Stultz wrote:
>>>>> This patch works around the issue by re-reading the GOTGCTL
>>>>> state to check if the GOTGCTL_CONID_B is still set and if not
>>>>> restarting the change status logic.
>>>>
>>>> This also seems weird. The connector id status shouldn't go back to A,
>>>> assuming you've left the cable unplugged.
>>>
>>> So I suspect this has something to do with the way the USB-A host
>>> ports on the board are wired up. As removing the usb-b plug seems to
>>> switch the device back into A mode.
>>>
>>> One quirk with this board is that the USB-A ports on the board do not
>>> function if anything is in the OTG/B plug (which is frustrating to use
>>> at times).
>>>
>>
>> Do you mean there are multiple A-ports on the board hooked up to the
>> same controller?
>>
>> If so, that would go a long way towards explaining things. Because the
>> hsotg is a single-port OTG controller. If there are multiple A-ports,
>> that means a hub has to be hard-wired internally to the port. But if
>> that's the case the OTG function won't work because OTG doesn't work
>> through a hub. It must go directly to the otg port. So there must be
>> some external logic kicking-in to switch routing to the OTG port or to
>> the HUB.
>>
>> This would explain this behavior with the ID pin status. Since hooking
>> up the HUB would make the controller an A-device whereas normally it
>> would be a B-device.
>>
>>> Guodong or Chen Yu understand the hardware details a bit better, and
>>> might be able to explain more if you need more information.
>>>
>>
>> Yeah it would be good to get some insight into this from a hardware
>> point of view.
>>
>
> Actually, I'm not very clear about the hardware details.
>
>                 In simple terms, there are two Type A USB 2.0 host ports and one microUSB OTG port on the front edge of the board.
>                 The two Type A USB 2.0 host ports connect to a high-speed hub and the hub connect to a USB Switch to which the microUSB OTG port
>         also connect.
>                 If the Vbus of the microUSB OTG port was high or the ID of the microUSB OTG port was low, the Switch will switch the DP and DM of the SOC
>         to microUSB OTG port. If no cable was inserted to microUSB OTG port, the Switch will switch the DP and DM of the SOC to the high-speed hub.
>                 There is another import point, the ID pin of soc will be pulled high in both cases:
>                 1.no cable is inserted to microUSB OTG port
>                 2.cable is inserted to microUSB OTG port and ID of microUSB OTG port is low.
>
>         If my explanation confuse you,  maybe these documents can be helpful.
>
>         1、https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/HardwareDocs/HardwareNotes.md
>
>         USB Ports
>
>         There are multiple USB ports on the HiKey board:
>
>         One microUSB OTG port on the front edge of the board
>         Two Type A USB 2.0 host ports on the front edge of the board
>         One USB 2.0 host port on the high-speed expansion bus
>
>         2、https://github.com/96boards/documentation/tree/master/ConsumerEdition/HiKey/AdditionalDocs
>         Hardware User Guide

Yea, Page 12 in this pdf seems to explain it:
https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/AdditionalDocs/HiKey_Hardware_User_Manual_Rev0.2.pdf

There is a usb switch which enables the micro-usb-b port if a cable is
present, or switches to using the hub(which has its own limitations
wrt multi-speed support) for the usb-a ports.

thanks
-john