linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ferry Toth <fntoth@gmail.com>
To: Andrey Smirnov <andrew.smirnov@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Felipe Balbi <balbi@kernel.org>,
	Thinh Nguyen <thinhn@synopsys.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Sven Peter <sven@svenpeter.dev>
Subject: Re: [PATCH v4] usb: dwc3: Don't switch OTG -> peripheral if extcon is present
Date: Sun, 25 Sep 2022 21:21:03 +0200	[thread overview]
Message-ID: <331b5644-e204-8915-cd08-bd4fabbfcb49@gmail.com> (raw)
In-Reply-To: <966ef528-455c-5180-fc63-ea77cb933af1@gmail.com>

Hi,

Promising results below.

Op 24-09-2022 om 23:29 schreef Ferry Toth:
> Hi,
>
> One more test
>
> Op 23-09-2022 om 20:23 schreef Andrey Smirnov:
>> On Fri, Sep 23, 2022 at 9:42 AM Andy Shevchenko
>> <andriy.shevchenko@intel.com> wrote:
>>> On Thu, Sep 22, 2022 at 04:32:55PM -0700, Andrey Smirnov wrote:
>>>> On Thu, Sep 22, 2022 at 3:23 AM Ferry Toth <fntoth@gmail.com> wrote:
>>>>> On 22-09-2022 12:08, Andy Shevchenko wrote:
>>>>> On Sun, Apr 03, 2022 at 09:49:07AM -0700, Andrey Smirnov wrote:
>>> FYI: For now I sent a revert, but if we got a solution quicker we 
>>> always
>>> can choose the course of actions.
>>>
>> I think we have another problem. This patch happened in parallel to mine
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0-rc6&id=ab7aa2866d295438dc60522f85c5421c6b4f1507 
>>
>>
>> so my changes didn't have that fix in mind and I think your revert
>> will not preserve that fix. Can you update your revert to take care of
>> that too, please?
>>
>> I'm really confused how the above commit could be followed up by:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/dwc3/drd.c?h=v6.0-rc6&id=0f01017191384e3962fa31520a9fd9846c3d352f 
>>
>>
>> the diffs in dwc3_drd_init seem contradictory
>>
>>>>> If the extcon device exists, get the mode from the extcon device. If
>>>>> the controller is DRD and the driver is unable to determine the mode,
>>>>> only then default the dr_mode to USB_DR_MODE_PERIPHERAL.
>>>>>
>>>>> According to Ferry (Cc'ed) this broke Intel Merrifield platform. 
>>>>> Ferry, can you
>>>>> share bisect log?
>>>>>
>>>>> I can but not right now. But what I did was bisect between 5.18.0 
>>>>> (good) and 5.19.0 (bad) then when I got near the culprit (~20 
>>>>> remaining) based on the commit message I tried 
>>>>> 0f01017191384e3962fa31520a9fd9846c3d352f "usb: dwc3: Don't switch 
>>>>> OTG -> peripheral if extcon is present" (bad) and commit before 
>>>>> that (good).
>>>>>
>>>>> The effect of the patch is that on Merrifield (I tested with Intel 
>>>>> Edison Arduino board which has a HW switch to select between host 
>>>>> and device mode) device mode works but in host mode USB is 
>>>>> completely not working.
>>>>>
>>>>> Currently on host mode - when working - superfluous error messages 
>>>>> from tusb1210 appear. When host mode is not working there are no 
>>>>> tusb1210 messages in the logs / on the console at all. Seemingly 
>>>>> tusb1210 is not probed, which points in the direction of a 
>>>>> relation to extcon.
>>>>>
>>>>> Taking into account the late cycle, I would like to revert the 
>>>>> change. And
>>>>> Ferry and I would help to test any other (non-regressive) approach).
>>>>>
>>>>> I have not yet tested if a simple revert fixes the problem but 
>>>>> will tonight.
>>>>>
>>>>>
>>>>> I would be happy to test other approaches too.
>>>>
>>>> It's a bit hard for me to suggest an alternative approach without
>>>> knowing how things are breaking in this case. I'd love to order one of
>>>> those boards to repro and fix this on my end, but it looks like this
>>>> HW is EOLed and out of stock in most places. If you guys know how to
>>>> get my hands on those boards I'm all ears.
>>> There are still some second hand Intel Edison boards flying around
>>> (but maybe cost a bit more than expected) and there are also
>>> Dell Venue 7 3740 tablets based on the same platform/SoC. The latter
>>> option though requires more actions in order something to be boot
>>> there.
>>>
>> OK, I'll check e-bay just in case.
>>
>>> In any case, it's probably quicker to ask Ferry or me for testing.
>>> (Although currently I have no access to the board to test OTG, it's
>>>   remote device which I can only power on and off and it has always
>>>   be in host mode.)
>>>
>>>> Barring that, Ferry can you dig more into this failure? E.g. is it 
>>>> this hunk
>>>>
>>>> @@ -85,7 +86,7 @@ static int dwc3_get_dr_mode(struct dwc3 *dwc)
>>>>                   * mode. If the controller supports DRD but the 
>>>> dr_mode is not
>>>>                   * specified or set to OTG, then set the mode to 
>>>> peripheral.
>>>>                   */
>>>> -               if (mode == USB_DR_MODE_OTG &&
>>>> +               if (mode == USB_DR_MODE_OTG && !dwc->edev &&
>>>>                      (!IS_ENABLED(CONFIG_USB_ROLE_SWITCH) ||
>>>> !device_property_read_bool(dwc->dev, "usb-role-switch")) &&
>>>>                      !DWC3_VER_IS_PRIOR(DWC3, 330A))
>>>> @@ -1632,6 +1633,51 @@ static void dwc3_check_params(struct dwc3 *dwc)
>>>>          }
>>>>   }
>>>>
>>>> that's problematic or moving
>>> I think you wanted to revert only this line and test?
>> Yes.
>>
>>>>   static int dwc3_probe(struct platform_device *pdev)
>>>>   {
>>>>          struct device           *dev = &pdev->dev;
>>>> @@ -1744,6 +1790,13 @@ static int dwc3_probe(struct platform_device 
>>>> *pdev)
>>>>                  goto err2;
>>>>          }
>>>>
>>>> +       dwc->edev = dwc3_get_extcon(dwc);
>>>> +       if (IS_ERR(dwc->edev)) {
>>>> +               ret = PTR_ERR(dwc->edev);
>>>> +               dev_err_probe(dwc->dev, ret, "failed to get 
>>>> extcon\n");
>>>> +               goto err3;
>>>> +       }
>>>> +
>>>>          ret = dwc3_get_dr_mode(dwc);
>>>>          if (ret)
>>>>                  goto err3;
>>>>
>>>> to happen earlier?
>
> I tried moving dwc3_get_extcon after dwc3_get_dr_mode like so::
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 8c8e32651473..3bf370def546 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1843,6 +1843,10 @@ static int dwc3_probe(struct platform_device 
> *pdev)
>          goto err2;
>      }
>
> +    ret = dwc3_get_dr_mode(dwc);
> +    if (ret)
> +        goto err3;
> +
>      dwc->edev = dwc3_get_extcon(dwc);
>      if (IS_ERR(dwc->edev)) {
>          ret = PTR_ERR(dwc->edev);
> @@ -1850,10 +1854,6 @@ static int dwc3_probe(struct platform_device 
> *pdev)
>          goto err3;
>      }
>
> -    ret = dwc3_get_dr_mode(dwc);
> -    if (ret)
> -        goto err3;
> -
>      ret = dwc3_alloc_scratch_buffers(dwc);
>      if (ret)
>          goto err3;

After trying to understand the code a bit, I successfully tested the 
following move:

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 8c8e32651473..4a38cff8cb16 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1843,13 +1843,6 @@ static int dwc3_probe(struct platform_device *pdev)
          goto err2;
      }

-    dwc->edev = dwc3_get_extcon(dwc);
-    if (IS_ERR(dwc->edev)) {
-        ret = PTR_ERR(dwc->edev);
-        dev_err_probe(dwc->dev, ret, "failed to get extcon\n");
-        goto err3;
-    }
-
      ret = dwc3_get_dr_mode(dwc);
      if (ret)
          goto err3;
@@ -1867,6 +1860,13 @@ static int dwc3_probe(struct platform_device *pdev)
      dwc3_check_params(dwc);
      dwc3_debugfs_init(dwc);

+    dwc->edev = dwc3_get_extcon(dwc);
+    if (IS_ERR(dwc->edev)) {
+        ret = PTR_ERR(dwc->edev);
+        dev_err_probe(dwc->dev, ret, "failed to get extcon\n");
+        goto err5;
+    }
+
      ret = dwc3_core_init_mode(dwc);
      if (ret)
          goto err5;

This moves dwc3_get_extcon() until after dwc3_core_init() but just 
before dwc3_core_init_mode(). AFAIU initially dwc3_get_extcon() was 
called from within dwc3_core_init_mode() but only for case 
USB_DR_MODE_OTG. So with this change order of events is more or less 
unchanged.

Due to move I modified goto to err5, not sure if that is correct.

Thoughts? Can we get something like this in quick or should we revert first?


  reply	other threads:[~2022-09-25 19:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-03 16:49 [PATCH v4] usb: dwc3: Don't switch OTG -> peripheral if extcon is present Andrey Smirnov
2022-09-22 10:08 ` Andy Shevchenko
     [not found]   ` <691c3073-5105-9a2b-e6f2-ea0a4b8aaea8@gmail.com>
2022-09-22 13:29     ` Andy Shevchenko
2022-09-22 20:35       ` Ferry Toth
2022-09-22 23:32     ` Andrey Smirnov
2022-09-23 16:42       ` Andy Shevchenko
2022-09-23 18:23         ` Andrey Smirnov
2022-09-23 18:35           ` Sven Peter
2022-09-23 18:58             ` Andy Shevchenko
2022-09-24  1:07               ` Andrey Smirnov
2022-09-23 18:54           ` Andy Shevchenko
2022-09-24  1:27             ` Andrey Smirnov
2022-09-24 11:55               ` Ferry Toth
2022-09-23 20:10           ` Ferry Toth
2022-09-24 21:29           ` Ferry Toth
2022-09-25 19:21             ` Ferry Toth [this message]
2022-09-26  5:43               ` Andrey Smirnov
2022-09-26 10:19                 ` Andy Shevchenko
2022-09-26 18:31                   ` Andrey Smirnov
2022-09-27 12:21                     ` Andy Shevchenko
2022-09-26 10:45               ` Sven Peter
2022-09-23 21:12         ` Ferry Toth
2022-09-24  1:34           ` Andrey Smirnov
2022-09-24 16:06             ` Ferry Toth
2022-09-26 10:21               ` Andy Shevchenko
2022-09-22 14:30   ` Ferry Toth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=331b5644-e204-8915-cd08-bd4fabbfcb49@gmail.com \
    --to=fntoth@gmail.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=sven@svenpeter.dev \
    --cc=thinhn@synopsys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).