Message ID | 20221110211132.297512-2-ftoth@exalondelft.nl |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp383183wru; Thu, 10 Nov 2022 13:25:27 -0800 (PST) X-Google-Smtp-Source: AMsMyM4TQJSFUpnw8Yi023aCRGMULVuES8IDZHwALT8lidrK6Fxuubp0gfY8AHRNpE1Cpw14/G9a X-Received: by 2002:a05:6402:206b:b0:461:c3d9:c6a3 with SMTP id bd11-20020a056402206b00b00461c3d9c6a3mr3512024edb.154.1668115526884; Thu, 10 Nov 2022 13:25:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668115526; cv=none; d=google.com; s=arc-20160816; b=JthLGFElWTQ9W2eOmreyg2abL611I6thosgxbQnh/cUzMF8cdqR9Ql0WccDGkJHQBH UdYj9vWYxGQeCikgB/r4Zhdpq2WR+RRbgmMlrG/yzNAV04P3Fut6tnre5+DNsU8gAtOG QOExTdJFJHXa24/SshKhXyXgrquIEqrxPTYfKpTy+7TrPVN586LBUH2aToEQWZ4I1Asd w1uF0ODhNiff+3pKWWumBV5q57/SMZwveXSJpOjb5ehWZDnsEhsWrhNQZjuRl+iXA+rW Ey6lWF4Lp1NI+QKrfbfXqVdvIBvEw9gXosO0Y58DUg3LevJr0xz2WDdkvngD5sYVna9f Pleg== 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=cdesS2DQFWedzwuFw/fxWGknLLF3dzMaZQT1dpDtHwc=; b=NqR5FCNzuj9P+V8v8jyhgQifS+Lv8CRB07jc0Y7rhuc9KNAdBqzU2rlKa2W4JIODrN i60qNF9PQaV6a7hd+ETWHPEakhUcoLZ4+cb1/UPRXxHFaGsLwO7XoRWwM3R8rZWszC6X OAF+sQf1ewVRvSLv7UHBPUmADaqtXozCNaltVPr9wwkRkpk6dZV38fPZB0o8FX8anA7a zy0CSKUCq7qaiM+mlLxAhjD5kG/K8FyndolYvlT43CpPsyuy9XlyxjhjpWagph7JRbTA vMdeDoJ8HeagM5ccvY3dQJiCmv8aNoyLwS+Z4zSX/g62aiNCmqS8El7kidgFde3+5cRo dLig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@exalondelft.nl header.s=whs1 header.b=caJy+WdU; 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 js12-20020a17090797cc00b007ae5ce3c730si389253ejc.82.2022.11.10.13.25.02; Thu, 10 Nov 2022 13:25:26 -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=caJy+WdU; 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 S231818AbiKJVML (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Thu, 10 Nov 2022 16:12:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231243AbiKJVMJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 10 Nov 2022 16:12:09 -0500 Received: from mailfilter06-out40.webhostingserver.nl (mailfilter06-out40.webhostingserver.nl [195.211.73.79]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21F652180B for <linux-kernel@vger.kernel.org>; Thu, 10 Nov 2022 13:12:05 -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=cdesS2DQFWedzwuFw/fxWGknLLF3dzMaZQT1dpDtHwc=; b=caJy+WdUvdRTLCqJVb6LWi2k99CSVAX9qHeRm4DPOqprEfR3XiMiCBE5DIiNwZl8o5XFGSGeA6qC9 Eqp0ADROaIQLGDl3GrQIWo6MLEnpChexBXHJaALaxLkmeN0qvdWfYYmKQe2AyfzzE+BVLKHL2t3UUQ t+AVzLT/+l0RszEnu3EZ5XdbT+CUsQjztrk/oW2rToUEh/8MhxhqapOifrzqii+hrgg9A2Gm6RS9ME i+3iPpZTm1K/3Q0SlTdZ5ixIQzKbUVtaMe5/q28Xw7+CLwsVhWcTBKRa79HrAc+s2gsrLsBYKE6Vo4 PVEtjZOy53fYf/CM8oGguQKP1Vvh19A== X-Halon-ID: 5285229e-613c-11ed-837b-001a4a4cb958 Received: from s198.webhostingserver.nl (s198.webhostingserver.nl [141.138.168.154]) by mailfilter06.webhostingserver.nl (Halon) with ESMTPSA id 5285229e-613c-11ed-837b-001a4a4cb958; Thu, 10 Nov 2022 22:12:03 +0100 (CET) Received: from 2a02-a466-68ed-1-7ff6-3899-7171-85b5.fixed6.kpn.net ([2a02:a466:68ed:1:7ff6:3899:7171:85b5] helo=delfion.fritz.box) by s198.webhostingserver.nl with esmtpa (Exim 4.96) (envelope-from <ftoth@exalondelft.nl>) id 1otEqA-005Dpg-28; Thu, 10 Nov 2022 22:12:02 +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> Subject: [PATCH v2 1/2] usb: ulpi: defer ulpi_register on ulpi_read_id timeout Date: Thu, 10 Nov 2022 22:11:31 +0100 Message-Id: <20221110211132.297512-2-ftoth@exalondelft.nl> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221110211132.297512-1-ftoth@exalondelft.nl> References: <20221110211132.297512-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=ham 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?1749145906935520199?= X-GMAIL-MSGID: =?utf-8?q?1749145906935520199?= |
Series |
usb: dwc3: core: defer probe on ulpi_read_id timeout
|
|
Commit Message
Ferry Toth
Nov. 10, 2022, 9:11 p.m. UTC
Since commit 0f010171
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.
Signed-off-by: Ferry Toth <ftoth@exalondelft.nl>
---
drivers/usb/common/ulpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, Nov 10, 2022 at 10:11:31PM +0100, Ferry Toth wrote: > Since commit 0f010171 > Dual Role support on Intel Merrifield platform broke due to rearranging > the call to dwc3_get_extcon(). Please see the kernel documentation for how to refer to commits. This should be written as: Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present"), Dual role.... > 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. > > Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> What commit does this fix? Should this also get a cc: stable? thanks, greg k-h
+ Stephen Boyd On 10-11-2022 22:11, Ferry Toth wrote: > Since commit 0f010171 > 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. > > 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) Would this affect others phys (like qcom HSIC)? I'm not sure if failing the test write is a normal behavior.
Op 11-11-2022 om 07:08 schreef Greg Kroah-Hartman: > On Thu, Nov 10, 2022 at 10:11:31PM +0100, Ferry Toth wrote: >> Since commit 0f010171 >> Dual Role support on Intel Merrifield platform broke due to rearranging >> the call to dwc3_get_extcon(). > > Please see the kernel documentation for how to refer to commits. This > should be written as: > > Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if > extcon is present"), Dual role.... Thanks I'll fix that in v3. >> 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. >> >> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> > > What commit does this fix? It's complicated, not sure how to explain this clearly: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") started to hide -ETIMEDOUT by returning 0. That problem was hidden due to another problem causing dwc3 to be deferred. But not properly, causing an infinite probe loop. This was fixed for quite some time by an out of tree patch. Now 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") accidentally fixes the probe loop, makes the out tree patch obsolete, but exposes the initial problem. In short this patch fixes ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") by returning -ETIMEDOUT to its user, who should handle it appropriately. In case of dwc3 probe it sets -EPROBE_DEFER and bails out. I'll add the short fixes: in v3. > Should this also get a cc: stable? I will add. > thanks, > > greg k-h
Quoting Ferry Toth (2022-11-11 06:04:16) > + Stephen Boyd > > On 10-11-2022 22:11, Ferry Toth wrote: > > Since commit 0f010171 > > 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. > > > > 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) > > Would this affect others phys (like qcom HSIC)? I'm not sure if failing > the test write is a normal behavior. I don't think failing a test write is normal behavior. I don't have this hardware on hand anymore though, so I can't help test it. Looks OK to me though: Reviewed-by: Stephen Boyd <sboyd@kernel.org>
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)