lkml.org 
[lkml]   [2022]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] usb: dwc3: Do not get extcon device when usb-role-switch is used
On Mon, Nov 7, 2022, at 12:25, Andy Shevchenko wrote:
> On Sun, Nov 06, 2022 at 10:48:04PM +0100, Janne Grunau wrote:
>> The change breaks device tree based platforms with PHY device and use
>> usb-role-switch instead of an extcon switch. extcon_find_edev_by_node()
>> will return EPROBE_DEFER if it can not find a device so probing without
>> an extcon device will be deferred indefinitely. Fix this by
>> explicitly checking for usb-role-switch.
>> At least the out-of-tree USB3 support on Apple silicon based platforms
>> using dwc3 with tipd USB Type-C and PD controller is affected by this
>> issue.
>
> We don't care about out-of-tree modules, do we?
>
> OTOH, the problem you are trying to workaround is probably in a (mis)use of
> deferred probe somewhere.
>
> Btw, does it prevent the system boot or you just see the extcon in the list of
> deferred devices after booting?

Which extcon? The commit description already mentions that the issue is that there
is no extcon and that the dwc3 probe gets stuck with EPROBE_DEFER forever.

This happens because the code after Janne's new check looks for the PHY and then
just assumes that if the PHY has a "port" that the other end always is an extcon.
It then tries extcon_find_edev_by_node which will always fail with EPROBE_DEFER
if that node never registers an extcon.

If "usb-role-switch" is used and configured in the DT there is no extcon.
There actually cannot ever be a working extcon with "usb-role-switch" because
the very first thing dwc3_drd_init does is to look for a role switch partner
and then skip the entire extcon setup:

int dwc3_drd_init(struct dwc3 *dwc)
{
int ret, irq;

if (ROLE_SWITCH &&
device_property_read_bool(dwc->dev, "usb-role-switch"))
return dwc3_setup_role_switch(dwc);
[....]


This entire issue was actually first fixed in ab7aa2866d29, then broken
again in 0f0101719138 due to a merge resolution, then fixed again with
7a84e7353e23 (where we actually had a brief discussion about this already
on the ML) and then broken again in d182c2e1bc92.

Janne's fix is much less subtle and should hopefully survive this time.

For the patch:

Reviewed-by: Sven Peter <sven@svenpeter.dev>


Best,

Sven

\
 
 \ /
  Last update: 2022-11-07 17:02    [W:0.985 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site