From: Ferry Toth <fntoth@gmail.com>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
Ferry Toth <ftoth@exalondelft.nl>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sean Anderson <sean.anderson@seco.com>,
Liu Shixin <liushixin2@huawei.com>,
Andrey Smirnov <andrew.smirnov@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH v3 2/2] usb: dwc3: core: defer probe on ulpi_read_id timeout
Date: Fri, 18 Nov 2022 13:29:03 +0100 [thread overview]
Message-ID: <53dde473-2e88-7f51-7417-fce3a73fb8c8@gmail.com> (raw)
In-Reply-To: <20221118021107.3uhixtck6sawluoy@synopsys.com>
On 18-11-2022 03:11, Thinh Nguyen wrote:
> On Thu, Nov 17, 2022, Ferry Toth wrote:
>> Since commit 0f010171
> I don't your update as noted in the v3 change (ie. Greg's suggestions).
Indeed. I seem to have sent in the wrong sha. Sorry about this.
>> Dual Role support on Intel Merrifield platform broke due to rearranging
>> the call to dwc3_get_extcon().
>>
>> It appears to be caused by ulpi_read_id() masking the timeout on the first
>> test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset()
>> followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER.
>> On deferred probe ulpi_read_id() finally succeeded.
>>
>> As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we
>> need to handle the error by calling dwc3_core_soft_reset() and request
>> -EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds.
>>
>> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
>> ---
>> drivers/usb/dwc3/core.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 648f1c570021..2779f17bffaf 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1106,8 +1106,13 @@ static int dwc3_core_init(struct dwc3 *dwc)
>>
>> if (!dwc->ulpi_ready) {
>> ret = dwc3_core_ulpi_init(dwc);
>> - if (ret)
>> + if (ret) {
>> + if (ret == -ETIMEDOUT) {
>> + dwc3_core_soft_reset(dwc);
> I'm not sure if you saw my previous response. I wanted to check to see
> if we need to do soft-reset once before ulpi init as part of its
> initialization.
I missed it but found it now. I will try your suggestion and answer.
> I'm just curious why Andrey Smirnov test doesn't require this change. If
> it's a quirk for this specific configuration, then the change here is
> fine. If it's required for all ULPI setup, then we can unconditionally
> do that for all ULPI setup during initialization.
Yes me too. I can reproduce that when I build kernel and rootfs with
buildroot there is no issue. But as soon as I add ftrace / bootconfig
the issue appears and then I can't analyze the flow. It's seems some
kind of timing / race.
However, I have tried deferring without dwc3_core_soft_reset() (to
verify if it is just a matter of time) and that doesn't work. dwc3 is
deferred about 10x and then gives up without phy. So, it's not just the
time and not just a matter of retrying the test write.
>> + ret = -EPROBE_DEFER;
>> + }
>> goto err0;
>> + }
>> dwc->ulpi_ready = true;
>> }
>>
>> --
>> 2.37.2
>>
> Thanks,
> Thinh
next prev parent reply other threads:[~2022-11-18 12:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 20:54 [PATCH v3 0/2] usb: dwc3: core: defer probe on ulpi_read_id timeout Ferry Toth
2022-11-17 20:54 ` [PATCH v3 1/2] usb: ulpi: defer ulpi_register " Ferry Toth
2022-11-18 10:31 ` Andy Shevchenko
2022-11-17 20:54 ` [PATCH v3 2/2] usb: dwc3: core: defer probe " Ferry Toth
2022-11-17 20:54 ` kernel test robot
2022-11-18 2:11 ` Thinh Nguyen
2022-11-18 12:29 ` Ferry Toth [this message]
2022-11-18 19:49 ` Thinh Nguyen
2022-11-18 10:32 ` [PATCH v3 0/2] " Andy Shevchenko
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=53dde473-2e88-7f51-7417-fce3a73fb8c8@gmail.com \
--to=fntoth@gmail.com \
--cc=Thinh.Nguyen@synopsys.com \
--cc=andrew.smirnov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ftoth@exalondelft.nl \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=liushixin2@huawei.com \
--cc=sean.anderson@seco.com \
--cc=stable@vger.kernel.org \
/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