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] [day] [month] [year] [list]

Message-ID: <eb1e045b-1ea4-caaa-79fe-6e4e01514490@huawei.com>
Date:   Fri, 9 Dec 2016 18:07:04 +0800
From:   Chen Yu <chenyu56@...wei.com>
To:     John Stultz <john.stultz@...aro.org>
CC:     <wangbinghui@...ilicon.com>, John Youn <John.Youn@...opsys.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 2016/12/9 15:32, John Stultz wrote:
> 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:

Sorry, I made a mistake here, the ID pin of soc will be pulled low 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
>