linux-kernel - Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

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]

Date:   Mon, 8 May 2017 10:19:25 -0600
From:   Shuah Khan <shuahkhan@...il.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>,
        Felipe Balbi <balbi@...nel.org>
Cc:     Richard Genoud <richard.genoud@...il.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Anand Moon <linux.amoon@...il.com>,
        Bartłomiej Żołnierkiewicz 
        <b.zolnierkie@...sung.com>, Huang Rui <ray.huang@....com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Kukjin Kim <kgene@...nel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux USB Mailing List <linux-usb@...r.kernel.org>,
        "linux-samsung-soc@...r.kernel.org" 
        <linux-samsung-soc@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        shuahkh@....samsung.com
Subject: Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports

Hi Krzysztof,

On Fri, Feb 10, 2017 at 6:34 AM, Krzysztof Kozlowski <krzk@...nel.org> wrote:
> On Thu, Feb 09, 2017 at 11:26:48AM +0100, Richard Genoud wrote:
>> I did some tests with XU3 and XU4, playing with USB2 and USB3 quirks
>> (snps,dis_u{2,3}_susphy_quirk)
>>
>> kernel for the tests: next-20170206
>> DTBs: exynos5422-odroidxu3-lite.dtb exynos5422-odroidxu4.dtb
>>
>> USB devices used for the tests: kingston USB3 key, Akasa sata/USB3
>> +SSD standard USB2 key
>> once recognized, a dd if=/dev/sda bs=1M count=100 of=/dev/null is done.
>>
>>
>> The results are:
>> - On XU4:
>>   - adding snps,dis_u2_susphy_quirk doesn't change anything:
>>     inserting an USB2 or USB3 device gives the error message:
>>     xhci-hcd xhci-hcd.2.auto: Port resume took longer than 20000 msec,
>> port status = 0xc400fe3
>>   - with snps,dis_u3_susphy_quirk, USB2 and USB3 devices are recognized
>>
>> - On XU3:
>>   - Without changing XU3 dts, USB2 devices are recognized.
>>   - With or without the snps,dis_u3_susphy_quirk, USB3 devices are not
>> recognized/not working properly
>>   (never seen or disconnected, unable to enumerate, etc.)
>>   However, adding an external powered USB3 hub in between works. (with
>> or without the snps,dis_u3_susphy_quirk)
>>   Anyway, this problem doesn't seems to be related to the other since
>>   addind the quirks doesn't change anything.
>
> From this description I am missing where are you inserting the USB
> devices.
>
> Both boards have totally different USB port configuration. On XU3 the
> hub is on USB 2.0 port. On XU4 the opposite - the hub is on USB 3.0
> port.
>

I am running into this on XU4 USB 3.0 ports. Cold booting with device
present in USB 3.0 port, device is recognized.

Bus 004 Device 003: ID 8564:4000 Transcend Information, Inc. RDF8
    MaxPower              224mA

However, if I were to insert it after boot, it fails to resume the port.

[ 2936.560129] usb 4-1.2: USB disconnect, device number 3
[ 2959.249815] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
20000 msec, port status = 0xc400fe3

and lsusb -v|egrep "^Bus|MaxPower" shows:

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    MaxPower                0mA

Preventing suspend with this. Looking at this more, could this be
related to GCTL.RAMCLKSEL?

The commnet block below in dwc3_gadget_conndone_interrupt() seems to
indicate a potential problem on platforms when RAMClkSel is reset to 0
after USB reset. Is that the case on Odroid-xu4 that updating
GCTL.RAMCLKSEL is necessary to USB device hotplug to work without the
the quirk?

     /*
         * RAMClkSel is reset to 0 after USB reset, so it must be reprogrammed
         * each time on Connect Done.
         *
         * Currently we always use the reset value. If any platform
         * wants to set this to a different value, we need to add a
         * setting and update GCTL.RAMCLKSEL here.
         */

I can debug this more dumping GCTL.RAMCLKSEL registers in cold boot
vs. hotplig cases to get more information.

thanks,
-- Shuah