d496f75
From patchwork Mon Jan  8 13:01:10 2018
d496f75
Content-Type: text/plain; charset="utf-8"
d496f75
MIME-Version: 1.0
d496f75
Content-Transfer-Encoding: 7bit
d496f75
Subject: phy: work around 'phys' references to usb-phy devices
d496f75
From: Arnd Bergmann <arnd@arndb.de>
d496f75
X-Patchwork-Id: 10149439
d496f75
Message-Id: <20180108130116.80148-1-arnd@arndb.de>
d496f75
To: Kishon Vijay Abraham I <kishon@ti.com>
d496f75
Cc: Stefan Wahren <stefan.wahren@i2se.com>, devicetree@vger.kernel.org,
d496f75
 Florian Fainelli <f.fainelli@gmail.com>, Arnd Bergmann <arnd@arndb.de>,
d496f75
 Felipe Balbi <balbi@kernel.org>, linux-usb@vger.kernel.org,
d496f75
 linux-kernel@vger.kernel.org, stable@vger.kernel.org,
d496f75
 Eric Anholt <eric@anholt.net>, Rob Herring <robh+dt@kernel.org>,
d496f75
 Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
d496f75
 linux-arm-kernel@lists.infradead.org
d496f75
Date: Mon,  8 Jan 2018 14:01:10 +0100
d496f75
d496f75
Stefan Wahren reports a problem with a warning fix that was merged
d496f75
for v4.15: we had lots of device nodes with a 'phys' property pointing
d496f75
to a device node that is not compliant with the binding documented in
d496f75
Documentation/devicetree/bindings/phy/phy-bindings.txt
d496f75
d496f75
This generally works because USB HCD drivers that support both the generic
d496f75
phy subsystem and the older usb-phy subsystem ignore most errors from
d496f75
phy_get() and related calls and then use the usb-phy driver instead.
d496f75
d496f75
However, usb_add_hcd() (along with the respective functions in dwc2 and
d496f75
dwc3) propagate the EPROBE_DEFER return code so we can try again whenever
d496f75
the driver gets loaded. In case the driver is written for the usb-phy
d496f75
subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load
d496f75
a generic-phy driver for it, and keep failing here.
d496f75
d496f75
There is only a small number of remaining usb-phy drivers that support
d496f75
device tree, so this adds a workaround by providing a full list of the
d496f75
potentially affected drivers, and always failing the probe with -ENODEV
d496f75
here, which is the same behavior that we used to get with incorrect
d496f75
device tree files. Since we generally want older kernels to also want
d496f75
to work with the fixed devicetree files, it would be good to backport
d496f75
the patch into stable kernels as well (3.13+ are possibly affected).
d496f75
Reverting back to the DTS sources that work would in theory fix USB
d496f75
support for now, but in the long run we'd run into the same problem
d496f75
again when the drivers get ported from usb-phy to generic-phy.
d496f75
d496f75
Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells")
d496f75
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
d496f75
Cc: stable@vger.kernel.org
d496f75
Cc: Stefan Wahren <stefan.wahren@i2se.com>
d496f75
Cc: Felipe Balbi <balbi@kernel.org>
d496f75
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
d496f75
---
d496f75
This obviously needs to be tested, I wrote this up as a reply to
d496f75
Stefan's bug report. I'm fairly sure that I covered all usb-phy
d496f75
driver strings here. My goal is to have a fix merged into 4.15
d496f75
rather than reverting all the DT fixes.
d496f75
---
d496f75
 drivers/phy/phy-core.c | 27 +++++++++++++++++++++++++++
d496f75
 1 file changed, 27 insertions(+)
d496f75
d496f75
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
d496f75
index b4964b067aec..bb4dd2a2de2d 100644
d496f75
--- a/drivers/phy/phy-core.c
d496f75
+++ b/drivers/phy/phy-core.c
d496f75
@@ -387,6 +387,24 @@ int phy_calibrate(struct phy *phy)
d496f75
 }
d496f75
 EXPORT_SYMBOL_GPL(phy_calibrate);
d496f75
 
d496f75
+static struct of_device_id __maybe_unused legacy_usbphy[] = {
d496f75
+	{ .compatible = "fsl,imx23-usbphy" },
d496f75
+	{ .compatible = "fsl,imx6q-usbphy" },
d496f75
+	{ .compatible = "fsl,imx6sl-usbphy" },
d496f75
+	{ .compatible = "fsl,imx6sx-usbphy" },
d496f75
+	{ .compatible = "fsl,imx6ul-usbphy" },
d496f75
+	{ .compatible = "fsl,vf610-usbphy" },
d496f75
+	{ .compatible = "nvidia,tegra20-usb-phy" },
d496f75
+	{ .compatible = "nvidia,tegra30-usb-phy" },
d496f75
+	{ .compatible = "nxp,isp1301" },
d496f75
+	{ .compatible = "ti,am335x-usb-ctrl-module" },
d496f75
+	{ .compatible = "ti,am335x-usb-phy" },
d496f75
+	{ .compatible = "ti,keystone-usbphy" },
d496f75
+	{ .compatible = "ti,twl6030-usb" },
d496f75
+	{ .compatible = "usb-nop-xceiv" },
d496f75
+	{},
d496f75
+};
d496f75
+
d496f75
 /**
d496f75
  * _of_phy_get() - lookup and obtain a reference to a phy by phandle
d496f75
  * @np: device_node for which to get the phy
d496f75
@@ -410,6 +428,15 @@ static struct phy *_of_phy_get(struct device_node *np, int index)
d496f75
 	if (ret)
d496f75
 		return ERR_PTR(-ENODEV);
d496f75
 
d496f75
+	/*
d496f75
+	 * Some USB host controllers use a "phys" property to refer to
d496f75
+	 * a device that does not have a generic phy driver but that
d496f75
+	 * has a driver for the older usb-phy framework.
d496f75
+	 * We must not return -EPROBE_DEFER for those, so bail out early.
d496f75
+	 */
d496f75
+	if (of_match_node(legacy_usbphy, args.np))
d496f75
+		return ERR_PTR(-ENODEV);
d496f75
+
d496f75
 	mutex_lock(&phy_provider_mutex);
d496f75
 	phy_provider = of_phy_provider_lookup(args.np);
d496f75
 	if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {