Message ID | 20200928101326.v4.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v4,1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs | expand |
On Mon, Sep 28, 2020 at 10:13:55AM -0700, Matthias Kaehlcke wrote: > The main issue this driver addresses is that a USB hub needs to be > powered before it can be discovered. For discrete onboard hubs (an > example for such a hub is the Realtek RTS5411) this is often solved > by supplying the hub with an 'always-on' regulator, which is kind > of a hack. Some onboard hubs may require further initialization > steps, like changing the state of a GPIO or enabling a clock, which > requires even more hacks. This driver creates a platform device > representing the hub which performs the necessary initialization. > Currently it only supports switching on a single regulator, support > for multiple regulators or other actions can be added as needed. > Different initialization sequences can be supported based on the > compatible string. > > Besides performing the initialization the driver can be configured > to power the hub off during system suspend. This can help to extend > battery life on battery powered devices which have no requirements > to keep the hub powered during suspend. The driver can also be > configured to leave the hub powered when a wakeup capable USB device > is connected when suspending, and power it off otherwise. > > Technically the driver consists of two drivers, the platform driver > described above and a very thin USB driver that subclasses the > generic driver. The purpose of this driver is to provide the platform > driver with the USB devices corresponding to the hub(s) (a hub > controller may provide multiple 'logical' hubs, e.g. one to support > USB 2.0 and another for USB 3.x). > > Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> > Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > --- Minor cut & paste error: > +static int onboard_hub_power_off(struct onboard_hub *hub) > +{ > + int err; > + > + err = regulator_disable(hub->vdd); > + if (err) { > + dev_err(hub->dev, "failed to enable regulator: %d\n", err); s/enable/disable/ Have you tried manually unbinding and rebinding the two drivers a few times to make sure they will still work? I'm a little concerned about all the devm_* stuff in here; does that get released when the driver is unbound from the device or when the device is unregistered? And if the latter, what happens if you have multiple sysfs attribute groups going at the same time? Apart from those worries and the typo, this looks pretty good to me. Acked-by: Alan Stern <stern@rowland.harvard.edu> Alan Stern
Hi, On Mon, Sep 28, 2020 at 10:14 AM Matthias Kaehlcke <mka@chromium.org> wrote: > > +static ssize_t power_off_in_suspend_show(struct device *dev, struct device_attribute *attr, > + char *buf) > +{ > + struct onboard_hub *hub = dev_get_drvdata(dev); > + > + return sprintf(buf, "%d\n", hub->power_off_in_suspend); > +} > + > +static ssize_t power_off_in_suspend_store(struct device *dev, struct device_attribute *attr, > + const char *buf, size_t count) > +{ > + struct onboard_hub *hub = dev_get_drvdata(dev); > + bool val; > + int ret; > + > + ret = kstrtobool(buf, &val); > + if (ret < 0) > + return ret; > + > + hub->power_off_in_suspend = val; > + > + return count; > +} > +static DEVICE_ATTR_RW(power_off_in_suspend); I wish there was a short name that meant "try to power off in suspend unless there's an active wakeup source underneath you". The name here is a bit misleading since we might keep this powered if there's an active wakeup source even if "power_off_in_suspend" is true... I wonder if it's easier to describe the opposite, like "always_power_in_suspend". Then, if that's false, it'll be in "automatic" mode and if it's true it'll always keep powered. I guess you can also argue about what the default should be. I guess if you just left it as zero-initted then we'd (by default) power off in suspend. To me that seems like a saner default, but I'm probably biased. > +static int onboard_hub_remove(struct platform_device *pdev) > +{ > + struct onboard_hub *hub = dev_get_drvdata(&pdev->dev); > + struct udev_node *node; > + struct usb_device *udev; > + > + hub->going_away = true; > + > + mutex_lock(&hub->lock); > + > + /* unbind the USB devices to avoid dangling references to this device */ > + while (!list_empty(&hub->udev_list)) { > + node = list_first_entry(&hub->udev_list, struct udev_node, list); > + udev = node->udev; > + > + /* > + * Unbinding the driver will call onboard_hub_remove_usbdev(), > + * which acquires hub->lock. We must release the lock first. > + */ > + get_device(&udev->dev); > + mutex_unlock(&hub->lock); > + device_release_driver(&udev->dev); > + put_device(&udev->dev); > + mutex_lock(&hub->lock); I didn't try to grok all the removal corner cases since it seems like you and Alan have been going over that. If you feel like this needs extra attention then yell and I'll look closer. > +static const struct of_device_id onboard_hub_match[] = { > + { .compatible = "onboard-usb-hub" }, > + { .compatible = "realtek,rts5411" }, You only need "onboard-usb-hub" here. The bindings still have "realtek,rts5411" in them in case we later have to do something different/special on that device, but the whole idea of including the generic is that we don't need to add every specific instance to this table. The above is pretty much nits, though, so: Reviewed-by: Douglas Anderson <dianders@chromium.org>
On Mon, Sep 28, 2020 at 02:47:59PM -0400, Alan Stern wrote: > On Mon, Sep 28, 2020 at 10:13:55AM -0700, Matthias Kaehlcke wrote: > > The main issue this driver addresses is that a USB hub needs to be > > powered before it can be discovered. For discrete onboard hubs (an > > example for such a hub is the Realtek RTS5411) this is often solved > > by supplying the hub with an 'always-on' regulator, which is kind > > of a hack. Some onboard hubs may require further initialization > > steps, like changing the state of a GPIO or enabling a clock, which > > requires even more hacks. This driver creates a platform device > > representing the hub which performs the necessary initialization. > > Currently it only supports switching on a single regulator, support > > for multiple regulators or other actions can be added as needed. > > Different initialization sequences can be supported based on the > > compatible string. > > > > Besides performing the initialization the driver can be configured > > to power the hub off during system suspend. This can help to extend > > battery life on battery powered devices which have no requirements > > to keep the hub powered during suspend. The driver can also be > > configured to leave the hub powered when a wakeup capable USB device > > is connected when suspending, and power it off otherwise. > > > > Technically the driver consists of two drivers, the platform driver > > described above and a very thin USB driver that subclasses the > > generic driver. The purpose of this driver is to provide the platform > > driver with the USB devices corresponding to the hub(s) (a hub > > controller may provide multiple 'logical' hubs, e.g. one to support > > USB 2.0 and another for USB 3.x). > > > > Co-developed-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> > > Signed-off-by: Ravi Chandra Sadineni <ravisadineni@chromium.org> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org> > > --- > > Minor cut & paste error: > > > +static int onboard_hub_power_off(struct onboard_hub *hub) > > +{ > > + int err; > > + > > + err = regulator_disable(hub->vdd); > > + if (err) { > > + dev_err(hub->dev, "failed to enable regulator: %d\n", err); > > s/enable/disable/ yup, will fix > Have you tried manually unbinding and rebinding the two drivers a few > times to make sure they will still work? I went through a few dozen bund/unbind cycles for both drivers and things looked good overall, but then last minute I found that determining whether wakeup capable devices are connected doesn't always work as (I) expected. I didn't see this earlier, it seems to be reproduce more easily after unbinding and rebinding the platform driver. During development I already noticed that usb_wakeup_enabled_descendants() returns a cached value, which was a problem for an earlier version of the driver. The values are updated by hub_suspend(), my (flawed) assumption was that the USB driver would always suspend before the platform driver. This generally seems to be the case on my development platform after boot, but not necessarily after unbinding and rebinding the driver. Using the _suspend_late hook instead of _suspend seems to be a reliable workaround. > I'm a little concerned about all the devm_* stuff in here; does that > get released when the driver is unbound from the device or when the device > is unregistered? And if the latter, what happens if you have multiple > sysfs attribute groups going at the same time? The memory gets released when the device is unbound: device_release_driver device_release_driver_internal __device_release_driver devres_release_all Anyway, if you prefer I can change the driver to use kmalloc/kfree. > Apart from those worries and the typo, this looks pretty good to me. > > Acked-by: Alan Stern <stern@rowland.harvard.edu> Great, thanks for taking the time to review!
Hi Doug, On Mon, Sep 28, 2020 at 03:03:20PM -0700, Doug Anderson wrote: > Hi, > > On Mon, Sep 28, 2020 at 10:14 AM Matthias Kaehlcke <mka@chromium.org> wrote: > > > > +static ssize_t power_off_in_suspend_show(struct device *dev, struct device_attribute *attr, > > + char *buf) > > +{ > > + struct onboard_hub *hub = dev_get_drvdata(dev); > > + > > + return sprintf(buf, "%d\n", hub->power_off_in_suspend); > > +} > > + > > +static ssize_t power_off_in_suspend_store(struct device *dev, struct device_attribute *attr, > > + const char *buf, size_t count) > > +{ > > + struct onboard_hub *hub = dev_get_drvdata(dev); > > + bool val; > > + int ret; > > + > > + ret = kstrtobool(buf, &val); > > + if (ret < 0) > > + return ret; > > + > > + hub->power_off_in_suspend = val; > > + > > + return count; > > +} > > +static DEVICE_ATTR_RW(power_off_in_suspend); > > I wish there was a short name that meant "try to power off in suspend > unless there's an active wakeup source underneath you". The name here > is a bit misleading since we might keep this powered if there's an > active wakeup source even if "power_off_in_suspend" is true... I > wonder if it's easier to describe the opposite, like > "always_power_in_suspend". Then, if that's false, it'll be in > "automatic" mode and if it's true it'll always keep powered. I agree that the name is somewhat misleading and it's hard find something concise. 'always_power_in_suspend' would certainly be more correct, it would make it slightly harder to configure the 'always power off' case though, since you would have to make sure that USB wakeup is disabled. IIUC this should be the default though (unless explicitly enabled), so probably it's not so bad. I'm somewhat undecided between 'always_power_in_suspend' and 'keep_powered_in_suspend'. > I guess you can also argue about what the default should be. I guess > if you just left it as zero-initted then we'd (by default) power off > in suspend. To me that seems like a saner default, but I'm probably > biased. I tend to agree, though yes, you could make a valid argument for either value. > > +static int onboard_hub_remove(struct platform_device *pdev) > > +{ > > + struct onboard_hub *hub = dev_get_drvdata(&pdev->dev); > > + struct udev_node *node; > > + struct usb_device *udev; > > + > > + hub->going_away = true; > > + > > + mutex_lock(&hub->lock); > > + > > + /* unbind the USB devices to avoid dangling references to this device */ > > + while (!list_empty(&hub->udev_list)) { > > + node = list_first_entry(&hub->udev_list, struct udev_node, list); > > + udev = node->udev; > > + > > + /* > > + * Unbinding the driver will call onboard_hub_remove_usbdev(), > > + * which acquires hub->lock. We must release the lock first. > > + */ > > + get_device(&udev->dev); > > + mutex_unlock(&hub->lock); > > + device_release_driver(&udev->dev); > > + put_device(&udev->dev); > > + mutex_lock(&hub->lock); > > I didn't try to grok all the removal corner cases since it seems like > you and Alan have been going over that. If you feel like this needs > extra attention then yell and I'll look closer. Thanks, I think we are good, especially after the additional testing I did today. > > +static const struct of_device_id onboard_hub_match[] = { > > + { .compatible = "onboard-usb-hub" }, > > + { .compatible = "realtek,rts5411" }, > > You only need "onboard-usb-hub" here. The bindings still have > "realtek,rts5411" in them in case we later have to do something > different/special on that device, but the whole idea of including the > generic is that we don't need to add every specific instance to this > table. right, I'll remove the realtek string in the next version. > The above is pretty much nits, though, so: > > Reviewed-by: Douglas Anderson <dianders@chromium.org> Thanks!
On Mon, Sep 28, 2020 at 06:43:55PM -0700, Matthias Kaehlcke wrote: > > Have you tried manually unbinding and rebinding the two drivers a few > > times to make sure they will still work? > > I went through a few dozen bund/unbind cycles for both drivers and things > looked good overall, but then last minute I found that determining whether > wakeup capable devices are connected doesn't always work as (I) expected. > I didn't see this earlier, it seems to be reproduce more easily after > unbinding and rebinding the platform driver. > > During development I already noticed that usb_wakeup_enabled_descendants() > returns a cached value, which was a problem for an earlier version of the > driver. The values are updated by hub_suspend(), my (flawed) assumption > was that the USB driver would always suspend before the platform driver. > This generally seems to be the case on my development platform after boot, > but not necessarily after unbinding and rebinding the driver. Using the > _suspend_late hook instead of _suspend seems to be a reliable workaround. Yes, for unrelated (i.e., not in a parent-child relation) devices, the PM subsystem doesn't guarantee ordering of suspend and resume callbacks. You can enforce the ordering by using device_pm_wait_for_dev(). But the suspend_late approach seems like a better solution in this case. > > I'm a little concerned about all the devm_* stuff in here; does that > > get released when the driver is unbound from the device or when the device > > is unregistered? And if the latter, what happens if you have multiple > > sysfs attribute groups going at the same time? > > The memory gets released when the device is unbound: > > device_release_driver > device_release_driver_internal > __device_release_driver > devres_release_all > > Anyway, if you prefer I can change the driver to use kmalloc/kfree. No, that's fine. I just wasn't sure about this and wanted to check. Alan Stern
On Tue, Sep 29, 2020 at 12:00:36PM -0400, Alan Stern wrote: > On Mon, Sep 28, 2020 at 06:43:55PM -0700, Matthias Kaehlcke wrote: > > > Have you tried manually unbinding and rebinding the two drivers a few > > > times to make sure they will still work? > > > > I went through a few dozen bund/unbind cycles for both drivers and things > > looked good overall, but then last minute I found that determining whether > > wakeup capable devices are connected doesn't always work as (I) expected. > > I didn't see this earlier, it seems to be reproduce more easily after > > unbinding and rebinding the platform driver. > > > > During development I already noticed that usb_wakeup_enabled_descendants() > > returns a cached value, which was a problem for an earlier version of the > > driver. The values are updated by hub_suspend(), my (flawed) assumption > > was that the USB driver would always suspend before the platform driver. > > This generally seems to be the case on my development platform after boot, > > but not necessarily after unbinding and rebinding the driver. Using the > > _suspend_late hook instead of _suspend seems to be a reliable workaround. > > Yes, for unrelated (i.e., not in a parent-child relation) devices, the > PM subsystem doesn't guarantee ordering of suspend and resume callbacks. > You can enforce the ordering by using device_pm_wait_for_dev(). But the > suspend_late approach seems like a better solution in this case. Thanks for the confirmation. Good to know about device_pm_wait_for_dev(), even if we are not going to use it in this case. > > > I'm a little concerned about all the devm_* stuff in here; does that > > > get released when the driver is unbound from the device or when the device > > > is unregistered? And if the latter, what happens if you have multiple > > > sysfs attribute groups going at the same time? > > > > The memory gets released when the device is unbound: > > > > device_release_driver > > device_release_driver_internal > > __device_release_driver > > devres_release_all > > > > Anyway, if you prefer I can change the driver to use kmalloc/kfree. > > No, that's fine. I just wasn't sure about this and wanted to check. I think the only concern would be a scenario where the USB devices are unbound and rebound over and over again, which would result in a struct udev_node being kept around for every bind until the platform device is removed. It seems unlikely and shouldn't be a big problem as long as the number of bind/unbind cycles is in the thousands rather than millions.
diff --git a/MAINTAINERS b/MAINTAINERS index 0d0862b19ce5..fa7502ed6771 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12859,6 +12859,13 @@ T: git git://linuxtv.org/media_tree.git F: Documentation/devicetree/bindings/media/i2c/ov9650.txt F: drivers/media/i2c/ov9650.c +ONBOARD USB HUB DRIVER +M: Matthias Kaehlcke <mka@chromium.org> +L: linux-usb@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml +F: drivers/usb/misc/onboard_usb_hub.c + ONENAND FLASH DRIVER M: Kyungmin Park <kyungmin.park@samsung.com> L: linux-mtd@lists.infradead.org diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig index 6818ea689cd9..09e6ca1a004c 100644 --- a/drivers/usb/misc/Kconfig +++ b/drivers/usb/misc/Kconfig @@ -275,3 +275,20 @@ config USB_CHAOSKEY To compile this driver as a module, choose M here: the module will be called chaoskey. + +config USB_ONBOARD_HUB + tristate "Onboard USB hub support" + depends on OF || COMPILE_TEST + help + Say Y here if you want to support discrete onboard USB hubs that + don't require an additional control bus for initialization, but + need some nontrivial form of initialization, such as enabling a + power regulator. An example for such a hub is the Realtek + RTS5411. + + The driver can be configured to turn off the power of the hub + during system suspend. This may reduce power consumption while + the system is suspended. + + To compile this driver as a module, choose M here: the + module will be called onboard_usb_hub. diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile index da39bddb0604..6f10a1c6f7e9 100644 --- a/drivers/usb/misc/Makefile +++ b/drivers/usb/misc/Makefile @@ -31,3 +31,4 @@ obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o obj-$(CONFIG_USB_SISUSBVGA) += sisusbvga/ obj-$(CONFIG_USB_LINK_LAYER_TEST) += lvstest.o +obj-$(CONFIG_USB_ONBOARD_HUB) += onboard_usb_hub.o diff --git a/drivers/usb/misc/onboard_usb_hub.c b/drivers/usb/misc/onboard_usb_hub.c new file mode 100644 index 000000000000..eb3ba7512c69 --- /dev/null +++ b/drivers/usb/misc/onboard_usb_hub.c @@ -0,0 +1,371 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Driver for onboard USB hubs + * + * Copyright (c) 2020, Google LLC + */ + +#include <linux/device.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/of.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> +#include <linux/regulator/consumer.h> +#include <linux/suspend.h> +#include <linux/usb.h> +#include <linux/usb/hcd.h> + +/************************** Platform driver **************************/ + +struct udev_node { + struct usb_device *udev; + struct list_head list; +}; + +struct onboard_hub { + struct regulator *vdd; + struct device *dev; + bool power_off_in_suspend; + bool is_powered_on; + bool going_away; + struct list_head udev_list; + struct mutex lock; +}; + +static int onboard_hub_power_on(struct onboard_hub *hub) +{ + int err; + + err = regulator_enable(hub->vdd); + if (err) { + dev_err(hub->dev, "failed to enable regulator: %d\n", err); + return err; + } + + hub->is_powered_on = true; + + return 0; +} + +static int onboard_hub_power_off(struct onboard_hub *hub) +{ + int err; + + err = regulator_disable(hub->vdd); + if (err) { + dev_err(hub->dev, "failed to enable regulator: %d\n", err); + return err; + } + + hub->is_powered_on = false; + + return 0; +} + +static int __maybe_unused onboard_hub_suspend(struct device *dev) +{ + struct onboard_hub *hub = dev_get_drvdata(dev); + struct udev_node *node; + bool power_off; + int rc = 0; + + if (!hub->power_off_in_suspend) + return 0; + + power_off = true; + + mutex_lock(&hub->lock); + + list_for_each_entry(node, &hub->udev_list, list) { + if (!device_may_wakeup(node->udev->bus->controller)) + continue; + + if (usb_wakeup_enabled_descendants(node->udev)) { + power_off = false; + break; + } + } + + mutex_unlock(&hub->lock); + + if (power_off) + rc = onboard_hub_power_off(hub); + + return rc; +} + +static int __maybe_unused onboard_hub_resume(struct device *dev) +{ + struct onboard_hub *hub = dev_get_drvdata(dev); + int rc = 0; + + if (!hub->is_powered_on) + rc = onboard_hub_power_on(hub); + + return rc; +} + +static int onboard_hub_add_usbdev(struct onboard_hub *hub, struct usb_device *udev) +{ + struct udev_node *node; + int ret = 0; + + mutex_lock(&hub->lock); + + if (hub->going_away) { + ret = -EINVAL; + goto unlock; + } + + node = devm_kzalloc(hub->dev, sizeof(*node), GFP_KERNEL); + if (!node) { + ret = -ENOMEM; + goto unlock; + } + + node->udev = udev; + + list_add(&node->list, &hub->udev_list); + +unlock: + mutex_unlock(&hub->lock); + + return ret; +} + +static void onboard_hub_remove_usbdev(struct onboard_hub *hub, struct usb_device *udev) +{ + struct udev_node *node; + + mutex_lock(&hub->lock); + + list_for_each_entry(node, &hub->udev_list, list) { + if (node->udev == udev) { + list_del(&node->list); + break; + } + } + + mutex_unlock(&hub->lock); +} + +static ssize_t power_off_in_suspend_show(struct device *dev, struct device_attribute *attr, + char *buf) +{ + struct onboard_hub *hub = dev_get_drvdata(dev); + + return sprintf(buf, "%d\n", hub->power_off_in_suspend); +} + +static ssize_t power_off_in_suspend_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct onboard_hub *hub = dev_get_drvdata(dev); + bool val; + int ret; + + ret = kstrtobool(buf, &val); + if (ret < 0) + return ret; + + hub->power_off_in_suspend = val; + + return count; +} +static DEVICE_ATTR_RW(power_off_in_suspend); + +static struct attribute *onboard_hub_sysfs_entries[] = { + &dev_attr_power_off_in_suspend.attr, + NULL, +}; + +static const struct attribute_group onboard_hub_sysfs_group = { + .attrs = onboard_hub_sysfs_entries, +}; + +static int onboard_hub_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct onboard_hub *hub; + int err; + + hub = devm_kzalloc(dev, sizeof(*hub), GFP_KERNEL); + if (!hub) + return -ENOMEM; + + hub->vdd = devm_regulator_get(dev, "vdd"); + if (IS_ERR(hub->vdd)) + return PTR_ERR(hub->vdd); + + hub->dev = dev; + mutex_init(&hub->lock); + INIT_LIST_HEAD(&hub->udev_list); + + dev_set_drvdata(dev, hub); + + err = devm_device_add_group(dev, &onboard_hub_sysfs_group); + if (err) { + dev_err(dev, "failed to create sysfs entries: %d\n", err); + return err; + } + + return onboard_hub_power_on(hub); +} + +static int onboard_hub_remove(struct platform_device *pdev) +{ + struct onboard_hub *hub = dev_get_drvdata(&pdev->dev); + struct udev_node *node; + struct usb_device *udev; + + hub->going_away = true; + + mutex_lock(&hub->lock); + + /* unbind the USB devices to avoid dangling references to this device */ + while (!list_empty(&hub->udev_list)) { + node = list_first_entry(&hub->udev_list, struct udev_node, list); + udev = node->udev; + + /* + * Unbinding the driver will call onboard_hub_remove_usbdev(), + * which acquires hub->lock. We must release the lock first. + */ + get_device(&udev->dev); + mutex_unlock(&hub->lock); + device_release_driver(&udev->dev); + put_device(&udev->dev); + mutex_lock(&hub->lock); + } + + mutex_unlock(&hub->lock); + + return onboard_hub_power_off(hub); +} + +static const struct of_device_id onboard_hub_match[] = { + { .compatible = "onboard-usb-hub" }, + { .compatible = "realtek,rts5411" }, + {} +}; +MODULE_DEVICE_TABLE(of, onboard_hub_match); + +static SIMPLE_DEV_PM_OPS(onboard_hub_pm_ops, onboard_hub_suspend, onboard_hub_resume); + +static struct platform_driver onboard_hub_driver = { + .probe = onboard_hub_probe, + .remove = onboard_hub_remove, + + .driver = { + .name = "onboard-usb-hub", + .of_match_table = onboard_hub_match, + .pm = pm_ptr(&onboard_hub_pm_ops), + }, +}; + +/************************** USB driver **************************/ + +#define VENDOR_ID_REALTEK 0x0bda + +static struct onboard_hub *_find_onboard_hub(struct device *dev) +{ + const phandle *ph; + struct device_node *np; + struct platform_device *pdev; + + ph = of_get_property(dev->of_node, "hub", NULL); + if (!ph) { + dev_err(dev, "failed to read 'hub' property\n"); + return ERR_PTR(-EINVAL); + } + + np = of_find_node_by_phandle(be32_to_cpu(*ph)); + if (!np) { + dev_err(dev, "failed find device node for onboard hub\n"); + return ERR_PTR(-EINVAL); + } + + pdev = of_find_device_by_node(np); + of_node_put(np); + if (!pdev) + return ERR_PTR(-EPROBE_DEFER); + + put_device(&pdev->dev); + + return dev_get_drvdata(&pdev->dev); +} + +static int onboard_hub_usbdev_probe(struct usb_device *udev) +{ + struct device *dev = &udev->dev; + struct onboard_hub *hub; + + /* ignore supported hubs without device tree node */ + if (!dev->of_node) + return -ENODEV; + + hub = _find_onboard_hub(dev); + if (IS_ERR(hub)) + return PTR_ERR(hub); + + dev_set_drvdata(dev, hub); + + return onboard_hub_add_usbdev(hub, udev); +} + +static void onboard_hub_usbdev_disconnect(struct usb_device *udev) +{ + struct onboard_hub *hub = dev_get_drvdata(&udev->dev); + + onboard_hub_remove_usbdev(hub, udev); +} + +static const struct usb_device_id onboard_hub_id_table[] = { + { USB_DEVICE(VENDOR_ID_REALTEK, 0x0411) }, /* RTS5411 USB 3.0 */ + { USB_DEVICE(VENDOR_ID_REALTEK, 0x5411) }, /* RTS5411 USB 2.0 */ + {}, +}; + +MODULE_DEVICE_TABLE(usb, onboard_hub_id_table); + +static struct usb_device_driver onboard_hub_usbdev_driver = { + + .name = "onboard-usb-hub", + .probe = onboard_hub_usbdev_probe, + .disconnect = onboard_hub_usbdev_disconnect, + .generic_subclass = 1, + .supports_autosuspend = 1, + .id_table = onboard_hub_id_table, +}; + +/************************** Driver (de)registration **************************/ + +static int __init onboard_hub_init(void) +{ + int ret; + + ret = platform_driver_register(&onboard_hub_driver); + if (ret) + return ret; + + ret = usb_register_device_driver(&onboard_hub_usbdev_driver, THIS_MODULE); + if (ret) + platform_driver_unregister(&onboard_hub_driver); + + return ret; +} +module_init(onboard_hub_init); + +static void __exit onboard_hub_exit(void) +{ + usb_deregister_device_driver(&onboard_hub_usbdev_driver); + platform_driver_unregister(&onboard_hub_driver); +} +module_exit(onboard_hub_exit); + +MODULE_AUTHOR("Matthias Kaehlcke <mka@chromium.org>"); +MODULE_DESCRIPTION("Driver for discrete onboard USB hubs"); +MODULE_LICENSE("GPL v2");