Message ID | 20221120153704.9090-2-ftoth@exalondelft.nl |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1165204wrr; Sun, 20 Nov 2022 07:39:05 -0800 (PST) X-Google-Smtp-Source: AA0mqf4Nd3gnhKjUe2JPV+E1IhWfx3LJVay47yCo98FH9JOwvRpMQOTc44IUmsfJKDjVmiyoxVra X-Received: by 2002:a63:da45:0:b0:434:aa27:6bee with SMTP id l5-20020a63da45000000b00434aa276beemr13806669pgj.388.1668958745245; Sun, 20 Nov 2022 07:39:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668958745; cv=none; d=google.com; s=arc-20160816; b=V3K1ewltek/A2YGnkt3XI3Pefw3lPyoBJSLoI4xCFR0jGc1ThS7qxFjErOHDGyWpvE sFBXQSUBfknr/vQ21STW0mTVzfNx1h+P1RPunhqqrIuyeD4og+iEeOLBWFbnSkEnTxxz an4jrAiGTXsnOZ67Ldi3USQ64PqdrXgRy7u7QWQw3vI6fuq8kLukr4SQ4bi77C5QeZ+0 7ix8+QP0j2Q9r/4x8GXjlAuPCS0+mwaAvJ04V5p0RkN8gJtrTpQ2P525hJGgQAofIl6B MHiH/XWsEyoQOtB2bXWkwEVG7OeTs1F5lFLRRgdrZOOlioAeqXt5Dafub5bKPrYlGvi6 YQUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=pL3v1LXTDSwlVQKeW2cdKoypwqG73N7k6gDtgGMdYn0=; b=C9wVnbCdZqWffKHI+SVTgG6/sm2DwP28z8yY4F273TdNoe2ku9hb0KMNFxsIQ0IeMJ F2jdkZesisdtIKs56TtI19JWoy9jaUtLzjy+WkgMJjAzETXHvvtcOtsAM82xIKt/K+ud 5CuERNEIEUj/QyHWASe+E6C8INsAz6AkrdgxkEwLXJOaJWzXCYmb51ND+2CNtZjZ72m6 EUM0KF1dI/7rfl0ymdw+/SqpAO/4zBMP2SqXgu0PcBn7MDCbc5/gxlpApqwG1w39VyTR hwi2P+6tA53t8ZQzoTZ2dTqepS9AFx22rDxXBNVlF4axGtNTjoqSsfXZn/5zyHue39l/ 3aaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@exalondelft.nl header.s=whs1 header.b=fykCvFRd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=exalondelft.nl Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e1-20020a170902744100b0017a8a84a3b6si8307676plt.106.2022.11.20.07.38.51; Sun, 20 Nov 2022 07:39:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@exalondelft.nl header.s=whs1 header.b=fykCvFRd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=exalondelft.nl Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229770AbiKTPhg (ORCPT <rfc822;yuanzuo1009@gmail.com> + 99 others); Sun, 20 Nov 2022 10:37:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49088 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229736AbiKTPhd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 20 Nov 2022 10:37:33 -0500 Received: from mailfilter05-out40.webhostingserver.nl (mailfilter05-out40.webhostingserver.nl [195.211.74.36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE55921A9 for <linux-kernel@vger.kernel.org>; Sun, 20 Nov 2022 07:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exalondelft.nl; s=whs1; h=content-transfer-encoding:mime-version:references:in-reply-to:message-id:date: subject:cc:to:from:from; bh=pL3v1LXTDSwlVQKeW2cdKoypwqG73N7k6gDtgGMdYn0=; b=fykCvFRdSymPbE7P4/0KI1oXYDb0vKv3BSSHwC5nCsm4tkAj1iNWhsuZjswgBU2b2BXR8+Fyox9Vv Zxll944e+9uco78mCsfQjRFyi7rJ7e/D3Du6bSYJuvk3hSiThSIdV0FLWYjOU7agxCYh7UraQARJ9n oFKWov1IvO/U98EIrFo7w4VXmRx6PR1E5QLdielzxlBzn90JZs7lVppmttEVCaanu6b+Z+//IyLGzV iszTq5dL4jJD7s8rDMfDqrMZ5lwtRLDb36m3oWCL3JkZxNruxbNy1kj3Dex0J9yzNgvtVawtz49fS8 2v435afgopxECdTXJA3KtpUGFjgiS6w== X-Halon-ID: 3bab168f-68e9-11ed-9686-001a4a4cb933 Received: from s198.webhostingserver.nl (s198.webhostingserver.nl [141.138.168.154]) by mailfilter05.webhostingserver.nl (Halon) with ESMTPSA id 3bab168f-68e9-11ed-9686-001a4a4cb933; Sun, 20 Nov 2022 16:37:25 +0100 (CET) Received: from 2a02-a466-68ed-1-a813-1b80-f6b2-b786.fixed6.kpn.net ([2a02:a466:68ed:1:a813:1b80:f6b2:b786] helo=delfion.fritz.box) by s198.webhostingserver.nl with esmtpa (Exim 4.96) (envelope-from <ftoth@exalondelft.nl>) id 1owmNp-004Y9S-1U; Sun, 20 Nov 2022 16:37:25 +0100 From: Ferry Toth <ftoth@exalondelft.nl> To: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Cc: 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>, Ferry Toth <ftoth@exalondelft.nl>, stable@vger.kernel.org Subject: [PATCH v4 1/2] usb: ulpi: defer ulpi_register on ulpi_read_id timeout Date: Sun, 20 Nov 2022 16:37:03 +0100 Message-Id: <20221120153704.9090-2-ftoth@exalondelft.nl> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20221120153704.9090-1-ftoth@exalondelft.nl> References: <20221120153704.9090-1-ftoth@exalondelft.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750030085112711844?= X-GMAIL-MSGID: =?utf-8?q?1750030085112711844?= |
Series |
usb: dwc3: core: defer probe on ulpi_read_id timeout
|
|
Commit Message
Ferry Toth
Nov. 20, 2022, 3:37 p.m. UTC
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()
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
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(-)
Comments
Sorry, Ferry, but a few style issues in the commit message. On Sun, Nov 20, 2022 at 04:37:03PM +0100, Ferry Toth wrote: > Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") It's fine to wrap this long line when it's in the commit message main body. > 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() > 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 > 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 s/This patch makes/Make/ (as per Submitting Patches: use imperative form) > 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 > This line breaks the tag block, meaning that Fixes won't be recognized as a tag by some scripts. > 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 >
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 >
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)