public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: 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>,
	Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
	Sean Anderson <sean.anderson@seco.com>,
	Liu Shixin <liushixin2@huawei.com>, Ferry Toth <fntoth@gmail.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 v4 1/2] usb: ulpi: defer ulpi_register on ulpi_read_id timeout
Date: Tue, 22 Nov 2022 01:47:51 +0000	[thread overview]
Message-ID: <20221122014746.ejxwie5g7yjrtlbm@synopsys.com> (raw)
In-Reply-To: <20221120153704.9090-2-ftoth@exalondelft.nl>

On Sun, Nov 20, 2022, Ferry Toth wrote:
> Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present")
> 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() on the first test write failing
> with -ETIMEDOUT. Currently ulpi_read_id() expects to discover the phy via
> DT when the test write fails and returns 0 in that case, even if DT does not
> provide the phy. As a result usb probe completes without phy.
> 
> On Intel Merrifield the issue is reproducible but difficult to find the
> root cause. Using an ordinary kernel and rootfs with buildroot ulpi_read_id()

ordinary = mainline?

> succeeds. As soon as adding ftrace / bootconfig to find out why,
> ulpi_read_id() fails and we can't analyze the flow. Using another rootfs
> ulpi_read_id() fails even without adding ftrace. Appearantly the issue is

This info fits more for the dwc3 patch, and can we use another word for
"apparently" when we still don't know the real cause? Maybe "we
suspect?"

Thanks,
Thinh

> some kind of timing / race, but merely retrying ulpi_read_id() does not
> resolve the issue.
> 
> This patch makes ulpi_read_id() return -ETIMEDOUT to its user if the first
> test write fails. The user should then handle it appropriately. A follow up
> patch will make dwc3_core_init() set -EPROBE_DEFER in this case and bail out.
> 
> Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT")
> Cc: stable@vger.kernel.org
> 
> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
> ---
>  drivers/usb/common/ulpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
> index d7c8461976ce..60e8174686a1 100644
> --- a/drivers/usb/common/ulpi.c
> +++ b/drivers/usb/common/ulpi.c
> @@ -207,7 +207,7 @@ static int ulpi_read_id(struct ulpi *ulpi)
>  	/* Test the interface */
>  	ret = ulpi_write(ulpi, ULPI_SCRATCH, 0xaa);
>  	if (ret < 0)
> -		goto err;
> +		return ret;
>  
>  	ret = ulpi_read(ulpi, ULPI_SCRATCH);
>  	if (ret < 0)
> -- 
> 2.37.2
> 

  parent reply	other threads:[~2022-11-22  1:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-20 15:37 [PATCH v4 0/2] usb: dwc3: core: defer probe on ulpi_read_id timeout Ferry Toth
2022-11-20 15:37 ` [PATCH v4 1/2] usb: ulpi: defer ulpi_register " Ferry Toth
2022-11-21  8:35   ` Andy Shevchenko
2022-11-22  1:47   ` Thinh Nguyen [this message]
2022-11-20 15:37 ` [PATCH v4 2/2] usb: dwc3: core: defer probe " Ferry Toth
2022-11-21  8:37   ` 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=20221122014746.ejxwie5g7yjrtlbm@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=fntoth@gmail.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