Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1026798imu; Wed, 16 Jan 2019 11:25:33 -0800 (PST) X-Google-Smtp-Source: ALg8bN6sxldMVVdRYJm5c4xUtbbxmnmpquSu61PcyMxb7s1zefy03swqN1xi95nnsf6xjwzl5teu X-Received: by 2002:a62:60c5:: with SMTP id u188mr11466222pfb.4.1547666733307; Wed, 16 Jan 2019 11:25:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547666733; cv=none; d=google.com; s=arc-20160816; b=u/aklfIK8YicacwXiB7b/GYWDVugUlzCN1/7uqnNqDfZeNcOzJuVzgyPLpHrRK31it wxMCbjbZqTIvk4u0xZmEYsBId/cV8nrlTqJ2BglsaJcQBFCWSkfBLGYOt5ZQYNo2oVdP TBgbKIJVlOG1Qjd2lxeF18huWeE8TSSEit/6Fxs08ZsbFhO8vr3YrVsvujzEyBIGikL/ A2Wg4OHwEGvl9GRi46pBj07M6VSgkWMpdCfbgWtcZgefo8MqXbpcFVgIpi1TuetKjVrv VsHxEkVehyqrSS6R8eTZrFZ9T2GEneDEGcCMhAg0mbBdHZBwdV+Kydo7Ufc37A2anAdY cFHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=GOp7uufARUO322Qyi7WuOLnQTxkLRWOgkhwGQjj3G5Y=; b=UimZ+9jyCKAxj/coaB6pPuQF/TAdsFDFpbzEahMebYzCNQPCsc63uM8PTqgzMDeG0T FmFzZXX3Cr1qqdWHBjHhp+or/NJ/t9xFtjttPORMvArSSRj8/WiCD5dynqBXvJVHhAsr DmqIGv5T0Wc8HaQMW3Zv72sDI8+SFw7WJCTcf9KAJqCGUOahLlHZLAA5/9FFAwb2Vr1p pZ4/9oErHcKx/8nEagFczGSVSMFPwmhIPY3DMJ/GE+FXUZwWDxPiBDR636pyB2BM4TgH nR2LNNEkqZa7QPvTlZrB7PtCsTEVpjZyj5c9CkKAO/HLwmchdy1Yr2xA1VRau6i7EKZ5 FUaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z8si6767760pgk.183.2019.01.16.11.25.09; Wed, 16 Jan 2019 11:25:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404115AbfAPKyE (ORCPT + 99 others); Wed, 16 Jan 2019 05:54:04 -0500 Received: from mail.bootlin.com ([62.4.15.54]:54674 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731772AbfAPKyD (ORCPT ); Wed, 16 Jan 2019 05:54:03 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id BD945207B0; Wed, 16 Jan 2019 11:54:00 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.2 Received: from windsurf (aaubervilliers-681-1-37-87.w90-88.abo.wanadoo.fr [90.88.156.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 7EE7F20758; Wed, 16 Jan 2019 11:53:50 +0100 (CET) Date: Wed, 16 Jan 2019 11:53:50 +0100 From: Thomas Petazzoni To: Paul Kocialkowski Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Peter Chen , Greg Kroah-Hartman Subject: Re: [PATCH] usb: chipidea: Grab the (legacy) USB PHY by phandle first Message-ID: <20190116115350.3daa9b4f@windsurf> In-Reply-To: <20190116101051.21202-1-paul.kocialkowski@bootlin.com> References: <20190116101051.21202-1-paul.kocialkowski@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Thanks for the patch! On Wed, 16 Jan 2019 11:10:51 +0100, Paul Kocialkowski wrote: > According to the chipidea driver bindings, the USB PHY is specified via > the "phys" phandle node. However, this only takes effect for USB PHYs > that use the common PHY framework. For legacy USB PHYs, a simple lookup > based on the USB PHY type is done instead. > > This does not play out well when more than USB PHY is registered, since "more than *one*" > the first registered PHY matching the type will always be returned > regardless of what the driver was bound to. > > Fix this by looking up the PHY based on the "phys" phandle node. > Although generic PHYS and rather matched by their "phys-name" I'm confused by "Although generic PHYS and rather matched". Perhaps s/and/are/ ? Also PHYS -> PHYs > and not > the "phys" phandle directly, there is no helper for similar lookup on > legacy PHYs and it's probably not worth the effort to add it. > > When no legacy USB PHY is found by phandle, fallback to grabbing any > registered USB2 PHY. This ensures backward compatibility if some users > were actually relying on this mechanism. > > Signed-off-by: Paul Kocialkowski > --- > drivers/usb/chipidea/core.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c > index 7bfcbb23c2a4..11d3ee1e3fe5 100644 > --- a/drivers/usb/chipidea/core.c > +++ b/drivers/usb/chipidea/core.c > @@ -954,8 +954,14 @@ static int ci_hdrc_probe(struct platform_device *pdev) > } else if (ci->platdata->usb_phy) { > ci->usb_phy = ci->platdata->usb_phy; > } else { > + ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys", > + 0); > ci->phy = devm_phy_get(dev->parent, "usb-phy"); > - ci->usb_phy = devm_usb_get_phy(dev->parent, USB_PHY_TYPE_USB2); I'm not sure why you change the order of legacy PHY lookup vs. generic PHY lookup. > + > + /* Fallback to grabbing any registered USB2 PHY */ > + if (IS_ERR(ci->phy) && IS_ERR(ci->usb_phy)) > + ci->usb_phy = devm_usb_get_phy(dev->parent, > + USB_PHY_TYPE_USB2); Why is this conditional on the generic PHY lookup failing? Don't we simply want: ci->phy = devm_phy_get(dev->parent, "usb-phy"); ci->usb_phy = devm_usb_get_phy_by_phandle(dev->parent, "phys", 0); if (IS_ERR(ci->usb_phy)) ci->usb_phy = devm_usb_get_phy(dev->parent, USB_PHY_TYPE_USB2); ? Does this needs a "Fixes:" tag ? It's not fixing a regression because nobody complained until now, but it's really fixing a behavior that wasn't correct. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com