Many physical hub chips include multiple logical hubs to handle both
USB and 2 and 3. Both logical hubs will then match the onboard hub
driver, which means we'll end up with two driver instances trying to
control the reset GPIO that is only present once on the physical chip.
As this doesn't make sense, just bail out of the probe function when
the peer-hub is already probed and can be assumed to handle power,
clocks and reset resources of the chip.
Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
---
drivers/usb/misc/onboard_usb_hub.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c
index 6339a3e4ec18..9e94caaa8456 100644
--- a/drivers/usb/misc/onboard_usb_hub.c
+++ b/drivers/usb/misc/onboard_usb_hub.c
@@ -53,8 +53,17 @@ static int onboard_hub_power_on(struct onboard_hub *hub)
static int onboard_hub_probe(struct device *dev)
{
+ struct device_node *peer_node;
+ struct device *peer_dev;
struct onboard_hub *hub;
+ peer_node = of_parse_phandle(dev->of_node, "peer-hub", 0);
+ if (peer_node) {
+ peer_dev = of_find_device_by_node(peer_node);
+ if (peer_dev && peer_dev->priv)
+ return 0;
+ }
+
hub = xzalloc(sizeof(*hub));
hub->pdata = device_get_match_data(dev);
@@ -71,6 +80,7 @@ static int onboard_hub_probe(struct device *dev)
"failed to get reset GPIO\n");
hub->dev = dev;
+ dev->priv = hub;
return onboard_hub_power_on(hub);
}
--
2.44.0
