linux-kernel - Re: [PATCH v2 2/2] Revert "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"

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: <a7724993-6c04-92c5-3a26-3aef6d29c9e3@gmail.com>
Date:   Tue, 4 Oct 2022 21:14:21 +0200
From:   Ferry Toth <fntoth@...il.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrey Smirnov <andrew.smirnov@...il.com>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Felipe Balbi <balbi@...nel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] Revert "usb: dwc3: Don't switch OTG -> peripheral
 if extcon is present"

Hi

Op 04-10-2022 om 10:28 schreef Andy Shevchenko:
> On Mon, Oct 03, 2022 at 09:57:35PM +0000, Thinh Nguyen wrote:
>> On Tue, Sep 27, 2022, Andy Shevchenko wrote:
>>> This reverts commit 0f01017191384e3962fa31520a9fd9846c3d352f.
>>>
>>> As pointed out by Ferry this breaks Dual Role support on
>>> Intel Merrifield platforms.
>> Can you provide more info than this (any debug info/description)? It
>> will be difficult to come back to fix with just this to go on. The
>> reverted patch was needed to fix a different issue.

On Merrifield we have a switch with extcon driver to switch between host 
and device mode. Now with commit 0f01017, device mode works. In host 
mode the root hub appears, but no devices appear. In the logs there are 
no messages from tusb1210, but there should be because lately there 
normally are (harmless) error messages. Nothing in the logs point in the 
direction of tusb1210 not being probed.

The discussion is here: https://lkml.org/lkml/2022/9/24/237

I tried moving some code as suggested without result: 
https://lkml.org/lkml/2022/9/24/434

And with success: https://lkml.org/lkml/2022/9/25/285

So, as Andrey Smirnov writes "I think we'd want to figure out why the 
ordering is important if we want to justify the above fix."

> It's already applied, but Ferry probably can provide more info if you describe
> step-by-step instructions. (I'm still unable to test this particular type of
> features since remove access is always in host mode.)
>
I'd be happy to test.