mbox series

[v5,0/4] USB: misc: Add onboard_usb_hub driver

Message ID 20210210171040.684659-1-mka@chromium.org
Headers show
Series USB: misc: Add onboard_usb_hub driver | expand

Message

Matthias Kaehlcke Feb. 10, 2021, 5:10 p.m. UTC
This series adds the onboard_usb_hub_driver, the corresponding
device tree bindings and creation of onboard_usb_hub platform in
the xhci-plat driver during probe().

The main issue the 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.

(no changes since v1)

Matthias Kaehlcke (4):
  dt-bindings: usb: Add binding for discrete onboard USB hubs
  USB: misc: Add onboard_usb_hub driver
  usb: host: xhci-plat: Create platform device for onboard hubs in
    probe()
  arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub

 .../bindings/usb/onboard_usb_hub.yaml         |  49 +++
 MAINTAINERS                                   |   7 +
 .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts |  15 +-
 .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts |  11 +-
 .../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts |  15 +-
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |  18 +-
 drivers/usb/host/xhci-plat.c                  |  16 +
 drivers/usb/misc/Kconfig                      |  18 +
 drivers/usb/misc/Makefile                     |   1 +
 drivers/usb/misc/onboard_usb_hub.c            | 409 ++++++++++++++++++
 include/linux/usb/hcd.h                       |   2 +
 include/linux/usb/onboard_hub.h               |  15 +
 12 files changed, 542 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml
 create mode 100644 drivers/usb/misc/onboard_usb_hub.c
 create mode 100644 include/linux/usb/onboard_hub.h

Comments

Krzysztof Kozlowski Feb. 10, 2021, 9:04 p.m. UTC | #1
On Wed, Feb 10, 2021 at 09:10:35AM -0800, Matthias Kaehlcke wrote:
> This series adds the onboard_usb_hub_driver, the corresponding
> device tree bindings and creation of onboard_usb_hub platform in
> the xhci-plat driver during probe().
> 
> The main issue the 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.

It seems you are re-developing the power sequence drivers which perform
exactly this. Peter Chen some time ago was bringing power sequence to
USB devices, but I lost track where this ended up.

Some of his (and my) very old work (2017...) can be found here:
https://github.com/krzk/linux/tree/wip/odroid-u3-usb3503-pwrseq

Instead of adding custom driver hiding some USB hub implementation,
power sequence seems a generic solution. What if you need to power cycle
other embedded USB device? Not a hub?

I was not aware of previous discussions so maybe I am repeating
someone.

Best regards,
Krzysztof
Matthias Kaehlcke Feb. 10, 2021, 10:37 p.m. UTC | #2
Hi Krzysztof,

On Wed, Feb 10, 2021 at 10:04:51PM +0100, Krzysztof Kozlowski wrote:
> On Wed, Feb 10, 2021 at 09:10:35AM -0800, Matthias Kaehlcke wrote:
> > This series adds the onboard_usb_hub_driver, the corresponding
> > device tree bindings and creation of onboard_usb_hub platform in
> > the xhci-plat driver during probe().
> > 
> > The main issue the 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.
> 
> It seems you are re-developing the power sequence drivers which perform
> exactly this. Peter Chen some time ago was bringing power sequence to
> USB devices, but I lost track where this ended up.
> 
> Some of his (and my) very old work (2017...) can be found here:
> https://github.com/krzk/linux/tree/wip/odroid-u3-usb3503-pwrseq

pwrseq was brought up in the discussion about this driver, but wasn't
deemed suitable for this use case which might require more complex
configurations:

https://lore.kernel.org/patchwork/patch/1313000/#1512725

> Instead of adding custom driver hiding some USB hub implementation,
> power sequence seems a generic solution. What if you need to power cycle
> other embedded USB device? Not a hub?

The driver could be extended to also cover other types of devices if desired.
Maybe it should be called usb-pwrseq then, even though it's not directly
related with the original pwrseq series.
Greg Kroah-Hartman Feb. 11, 2021, 7:03 a.m. UTC | #3
On Wed, Feb 10, 2021 at 09:10:37AM -0800, Matthias Kaehlcke wrote:
> +static int onboard_hub_add_usbdev(struct onboard_hub *hub, struct usb_device *udev)
> +{
> +	struct udev_node *node;
> +	char link_name[64];
> +	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);
> +
> +	snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));
> +	WARN_ON(sysfs_create_link(&hub->dev->kobj, &udev->dev.kobj, link_name));

Never use WARN_ON() unless you want the machine to reboot if it triggers
(panic on warn).

But the larger question is what is this sysfs link for?  It's not
documented anywhere, and so, shouldn't be allowed.  Who is going to use
it and why is it needed?



> +
> +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;
> +	char link_name[64];
> +
> +	snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));
> +	sysfs_remove_link(&hub->dev->kobj, link_name);
> +
> +	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 always_powered_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->always_powered_in_suspend);

sysfs_emit()?

And you forgot the Documentation/ABI/ entries for this driver, so it
really can not be reviewed...


> +}
> +
> +static ssize_t always_powered_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->always_powered_in_suspend = val;
> +
> +	return count;
> +}
> +static DEVICE_ATTR_RW(always_powered_in_suspend);
> +
> +static struct attribute *onboard_hub_sysfs_entries[] = {
> +	&dev_attr_always_powered_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);

You just raced userspace and lost :(

Please use the correct api to add sysfs attributes to the device
automatically by the driver core.  But the larger question is why do you
need them at all?  What do they do that we can't already do with
existing apis that you feel a one-off api for this driver is required?



> +	if (err) {
> +		dev_err(dev, "failed to create sysfs entries: %d\n", err);
> +		return err;
> +	}
> +
> +	err = onboard_hub_power_on(hub);
> +	if (err)
> +		return err;
> +
> +	/*
> +	 * The USB driver might have been detached from the USB devices by
> +	 * onboard_hub_remove() make sure to re-attach it if needed.
> +	 */
> +	(void)driver_attach(&onboard_hub_usbdev_driver.drvwrap.driver);

(void)????

Please no, do it right.

But, why is a driver calling this function anyway?  That feels really
really wrong...

thanks,

greg k-h
Rob Herring (Arm) Feb. 11, 2021, 2:56 p.m. UTC | #4
On Wed, 10 Feb 2021 09:10:36 -0800, Matthias Kaehlcke wrote:
> Discrete onboard USB hubs (an example for such a hub is the Realtek

> RTS5411) need to be powered and may require initialization of other

> resources (like GPIOs or clocks) to work properly. This adds a device

> tree binding for these hubs.

> 

> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

> ---

> 

> Changes in v5:

> - updated 'title'

> - only use standard USB compatible strings

> - deleted 'usb_hub' node

> - renamed 'usb_controller' node to 'usb-controller'

> - removed labels from USB nodes

> - added 'vdd-supply' to USB nodes

> 

> Changes in v4:

> - none

> 

> Changes in v3:

> - updated commit message

> - removed recursive reference to $self

> - adjusted 'compatible' definition to support multiple entries

> - changed USB controller phandle to be a node

> 

> Changes in v2:

> - removed 'wakeup-source' and 'power-off-in-suspend' properties

> - consistently use spaces for indentation in example

> 

>  .../bindings/usb/onboard_usb_hub.yaml         | 49 +++++++++++++++++++

>  1 file changed, 49 insertions(+)

>  create mode 100644 Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml:16:9: [warning] wrong indentation: expected 10 but found 8 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml: 'additionalProperties' is a required property
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml: ignoring, error in schema: 
warning: no schema found in file: ./Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

See https://patchwork.ozlabs.org/patch/1439137

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.
Matthias Kaehlcke Feb. 11, 2021, 6:04 p.m. UTC | #5
Hi Greg,

On Thu, Feb 11, 2021 at 08:03:01AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2021 at 09:10:37AM -0800, Matthias Kaehlcke wrote:

> > +static int onboard_hub_add_usbdev(struct onboard_hub *hub, struct usb_device *udev)

> > +{

> > +	struct udev_node *node;

> > +	char link_name[64];

> > +	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);

> > +

> > +	snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));

> > +	WARN_ON(sysfs_create_link(&hub->dev->kobj, &udev->dev.kobj, link_name));

> 

> Never use WARN_ON() unless you want the machine to reboot if it triggers

> (panic on warn).


Ah, thanks, I wasn't aware of that. Will change to some type of log if the
sysfs attributes stick around.

> But the larger question is what is this sysfs link for?  It's not

> documented anywhere, and so, shouldn't be allowed.  Who is going to use

> it and why is it needed?


Alan asked to add them: https://lore.kernel.org/patchwork/patch/1313000/#1514338

I'm fine with either way, let's just agree on something :)

> > +

> > +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;

> > +	char link_name[64];

> > +

> > +	snprintf(link_name, sizeof(link_name), "usb_dev.%s", dev_name(&udev->dev));

> > +	sysfs_remove_link(&hub->dev->kobj, link_name);

> > +

> > +	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 always_powered_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->always_powered_in_suspend);

> 

> sysfs_emit()?


ok

> And you forgot the Documentation/ABI/ entries for this driver, so it

> really can not be reviewed...


I'll add it in the next version.

> > +}

> > +

> > +static ssize_t always_powered_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->always_powered_in_suspend = val;

> > +

> > +	return count;

> > +}

> > +static DEVICE_ATTR_RW(always_powered_in_suspend);

> > +

> > +static struct attribute *onboard_hub_sysfs_entries[] = {

> > +	&dev_attr_always_powered_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);

> 

> You just raced userspace and lost :(

> 

> Please use the correct api to add sysfs attributes to the device

> automatically by the driver core.


ok

> But the larger question is why do you need them at all?  What do they

> do that we can't already do with existing apis that you feel a one-off

> api for this driver is required?


The 'always_powered_in_suspend' attribute allows the admin to configure whether
the hub should always been kept on in suspend. I'm know about existing APIs that
would be suitable for that, but that might be just my ignorance. If you have any
suggestions please let me know.

> > +	if (err) {

> > +		dev_err(dev, "failed to create sysfs entries: %d\n", err);

> > +		return err;

> > +	}

> > +

> > +	err = onboard_hub_power_on(hub);

> > +	if (err)

> > +		return err;

> > +

> > +	/*

> > +	 * The USB driver might have been detached from the USB devices by

> > +	 * onboard_hub_remove() make sure to re-attach it if needed.

> > +	 */

> > +	(void)driver_attach(&onboard_hub_usbdev_driver.drvwrap.driver);

> 

> (void)????

> 

> Please no, do it right.


Ok, driver_attach() does not return an error when the driver is already
attached, so it should be fine to change this to an error check.

> But, why is a driver calling this function anyway?  That feels really

> really wrong...


I found during testing that this is needed to make sure the driver is attached
again after it was released in onboard_hub_remove(). Alan requested to release
the driver to avoid dangling references:
https://lore.kernel.org/patchwork/patch/1310889/#1506598

Thanks

Matthias
Rob Herring (Arm) Feb. 17, 2021, 9:04 p.m. UTC | #6
On Wed, Feb 10, 2021 at 09:10:36AM -0800, Matthias Kaehlcke wrote:
> Discrete onboard USB hubs (an example for such a hub is the Realtek

> RTS5411) need to be powered and may require initialization of other

> resources (like GPIOs or clocks) to work properly. This adds a device

> tree binding for these hubs.

> 

> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

> ---

> 

> Changes in v5:

> - updated 'title'

> - only use standard USB compatible strings

> - deleted 'usb_hub' node

> - renamed 'usb_controller' node to 'usb-controller'

> - removed labels from USB nodes

> - added 'vdd-supply' to USB nodes

> 

> Changes in v4:

> - none

> 

> Changes in v3:

> - updated commit message

> - removed recursive reference to $self

> - adjusted 'compatible' definition to support multiple entries

> - changed USB controller phandle to be a node

> 

> Changes in v2:

> - removed 'wakeup-source' and 'power-off-in-suspend' properties

> - consistently use spaces for indentation in example

> 

>  .../bindings/usb/onboard_usb_hub.yaml         | 49 +++++++++++++++++++

>  1 file changed, 49 insertions(+)

>  create mode 100644 Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> 

> diff --git a/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml b/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> new file mode 100644

> index 000000000000..bf4ec52e6c7b

> --- /dev/null

> +++ b/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> @@ -0,0 +1,49 @@

> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause

> +%YAML 1.2

> +---

> +$id: http://devicetree.org/schemas/usb/onboard_usb_hub.yaml#

> +$schema: http://devicetree.org/meta-schemas/core.yaml#

> +

> +title: Binding for discrete onboard USB hubs


This isn't really generic. Maybe there's a set of hubs with only a 
single supply much like 'simple-panel', but I kind of doubt that here. 
There aren't hundreds of hub chips like panels. Though, we should put 
this into bindings/usb/hub/ so we start collecting hub bindings in one 
place.

A generic driver doesn't have to have a generic binding. You can have a 
specific device binding which is handled by a generic driver. Or not. 
Who knows. Maybe a simple user like u-boot has a generic driver while 
something more feature rich has a device specific binding.

> +

> +maintainers:

> +  - Matthias Kaehlcke <mka@chromium.org>


Now we have usb-device.yaml, you need:

allOf:
  - $ref: usb-device.yaml#

> +

> +properties:

> +  compatible:

> +    items:

> +      - enum:

> +        - usbbda,5411

> +        - usbbda,411

> +

> +  vdd-supply:

> +    description:

> +      phandle to the regulator that provides power to the hub.

> +

> +required:

> +  - compatible

> +  - vdd-supply

> +

> +examples:

> +  - |

> +    usb-controller {

> +        dr_mode = "host";

> +        #address-cells = <1>;

> +        #size-cells = <0>;

> +

> +        /* 2.0 hub on port 1 */

> +        hub_2_0: hub@1 {

> +            compatible = "usbbda,5411";

> +            reg = <1>;

> +            vdd-supply = <&pp3300_hub>;

> +        };

> +

> +        /* 3.0 hub on port 2 */

> +        hub_3_0: hub@2 {

> +            compatible = "usbbda,411";

> +            reg = <2>;

> +            vdd-supply = <&pp3300_hub>;

> +        };

> +    };

> +

> +...

> -- 

> 2.30.0.478.g8a0d178c01-goog

>
Rob Herring (Arm) Feb. 19, 2021, 3:05 p.m. UTC | #7
On Wed, Feb 17, 2021 at 7:33 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>

> Hi Rob,

>

> thanks for your review!

>

> On Wed, Feb 17, 2021 at 03:04:41PM -0600, Rob Herring wrote:

> > On Wed, Feb 10, 2021 at 09:10:36AM -0800, Matthias Kaehlcke wrote:

> > > Discrete onboard USB hubs (an example for such a hub is the Realtek

> > > RTS5411) need to be powered and may require initialization of other

> > > resources (like GPIOs or clocks) to work properly. This adds a device

> > > tree binding for these hubs.

> > >

> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

> > > ---

> > >

> > > Changes in v5:

> > > - updated 'title'

> > > - only use standard USB compatible strings

> > > - deleted 'usb_hub' node

> > > - renamed 'usb_controller' node to 'usb-controller'

> > > - removed labels from USB nodes

> > > - added 'vdd-supply' to USB nodes

> > >

> > > Changes in v4:

> > > - none

> > >

> > > Changes in v3:

> > > - updated commit message

> > > - removed recursive reference to $self

> > > - adjusted 'compatible' definition to support multiple entries

> > > - changed USB controller phandle to be a node

> > >

> > > Changes in v2:

> > > - removed 'wakeup-source' and 'power-off-in-suspend' properties

> > > - consistently use spaces for indentation in example

> > >

> > >  .../bindings/usb/onboard_usb_hub.yaml         | 49 +++++++++++++++++++

> > >  1 file changed, 49 insertions(+)

> > >  create mode 100644 Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> > >

> > > diff --git a/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml b/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> > > new file mode 100644

> > > index 000000000000..bf4ec52e6c7b

> > > --- /dev/null

> > > +++ b/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> > > @@ -0,0 +1,49 @@

> > > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause

> > > +%YAML 1.2

> > > +---

> > > +$id: http://devicetree.org/schemas/usb/onboard_usb_hub.yaml#

> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#

> > > +

> > > +title: Binding for discrete onboard USB hubs

> >

> > This isn't really generic. Maybe there's a set of hubs with only a

> > single supply much like 'simple-panel', but I kind of doubt that here.

> > There aren't hundreds of hub chips like panels. Though, we should put

> > this into bindings/usb/hub/ so we start collecting hub bindings in one

> > place.

>

> Ok, I agree that the name of the binding is too generic, I anticipated that

> the power supply section would need to be extended to support other hub

> chips.

>

> > A generic driver doesn't have to have a generic binding.

>

> That's a good point, it seems to make sense to have separate bindings in

> this case.

>

> > You can have a specific device binding which is handled by a generic

> > driver. Or not. Who knows. Maybe a simple user like u-boot has a generic

> > driver while something more feature rich has a device specific binding.

> >

> > > +

> > > +maintainers:

> > > +  - Matthias Kaehlcke <mka@chromium.org>

> >

> > Now we have usb-device.yaml, you need:

> >

> > allOf:

> >   - $ref: usb-device.yaml#

>

> ok

>

> So with your comments addressed it seems we have a binding that could be

> acceptable. I'll still hold back a bit to see if we can make progress with

> the discussion about using the 'graph' binding (https://lore.kernel.org/patchwork/patch/1379002/#1578294).

> The one thing I don't like about the current binding is that it wouldn't

> work out of the box with a hierarchy of hubs. To make that work on the

> driver side an additional property would be needed to indicate that two

> (or more) USB hub devices are related (i.e. are provided by the same

> chip). This is needed to be able to decide whether the hub should be

> powered down during system suspend.


How about a 'hub-companion' property or similar?

Rob
Matthias Kaehlcke Feb. 22, 2021, 5:39 p.m. UTC | #8
On Fri, Feb 19, 2021 at 09:05:32AM -0600, Rob Herring wrote:
> On Wed, Feb 17, 2021 at 7:33 PM Matthias Kaehlcke <mka@chromium.org> wrote:

> >

> > Hi Rob,

> >

> > thanks for your review!

> >

> > On Wed, Feb 17, 2021 at 03:04:41PM -0600, Rob Herring wrote:

> > > On Wed, Feb 10, 2021 at 09:10:36AM -0800, Matthias Kaehlcke wrote:

> > > > Discrete onboard USB hubs (an example for such a hub is the Realtek

> > > > RTS5411) need to be powered and may require initialization of other

> > > > resources (like GPIOs or clocks) to work properly. This adds a device

> > > > tree binding for these hubs.

> > > >

> > > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

> > > > ---

> > > >

> > > > Changes in v5:

> > > > - updated 'title'

> > > > - only use standard USB compatible strings

> > > > - deleted 'usb_hub' node

> > > > - renamed 'usb_controller' node to 'usb-controller'

> > > > - removed labels from USB nodes

> > > > - added 'vdd-supply' to USB nodes

> > > >

> > > > Changes in v4:

> > > > - none

> > > >

> > > > Changes in v3:

> > > > - updated commit message

> > > > - removed recursive reference to $self

> > > > - adjusted 'compatible' definition to support multiple entries

> > > > - changed USB controller phandle to be a node

> > > >

> > > > Changes in v2:

> > > > - removed 'wakeup-source' and 'power-off-in-suspend' properties

> > > > - consistently use spaces for indentation in example

> > > >

> > > >  .../bindings/usb/onboard_usb_hub.yaml         | 49 +++++++++++++++++++

> > > >  1 file changed, 49 insertions(+)

> > > >  create mode 100644 Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> > > >

> > > > diff --git a/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml b/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> > > > new file mode 100644

> > > > index 000000000000..bf4ec52e6c7b

> > > > --- /dev/null

> > > > +++ b/Documentation/devicetree/bindings/usb/onboard_usb_hub.yaml

> > > > @@ -0,0 +1,49 @@

> > > > +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause

> > > > +%YAML 1.2

> > > > +---

> > > > +$id: http://devicetree.org/schemas/usb/onboard_usb_hub.yaml#

> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#

> > > > +

> > > > +title: Binding for discrete onboard USB hubs

> > >

> > > This isn't really generic. Maybe there's a set of hubs with only a

> > > single supply much like 'simple-panel', but I kind of doubt that here.

> > > There aren't hundreds of hub chips like panels. Though, we should put

> > > this into bindings/usb/hub/ so we start collecting hub bindings in one

> > > place.

> >

> > Ok, I agree that the name of the binding is too generic, I anticipated that

> > the power supply section would need to be extended to support other hub

> > chips.

> >

> > > A generic driver doesn't have to have a generic binding.

> >

> > That's a good point, it seems to make sense to have separate bindings in

> > this case.

> >

> > > You can have a specific device binding which is handled by a generic

> > > driver. Or not. Who knows. Maybe a simple user like u-boot has a generic

> > > driver while something more feature rich has a device specific binding.

> > >

> > > > +

> > > > +maintainers:

> > > > +  - Matthias Kaehlcke <mka@chromium.org>

> > >

> > > Now we have usb-device.yaml, you need:

> > >

> > > allOf:

> > >   - $ref: usb-device.yaml#

> >

> > ok

> >

> > So with your comments addressed it seems we have a binding that could be

> > acceptable. I'll still hold back a bit to see if we can make progress with

> > the discussion about using the 'graph' binding (https://lore.kernel.org/patchwork/patch/1379002/#1578294).

> > The one thing I don't like about the current binding is that it wouldn't

> > work out of the box with a hierarchy of hubs. To make that work on the

> > driver side an additional property would be needed to indicate that two

> > (or more) USB hub devices are related (i.e. are provided by the same

> > chip). This is needed to be able to decide whether the hub should be

> > powered down during system suspend.

> 

> How about a 'hub-companion' property or similar?


Yes, something like that is what I had in mind.

Another inconvenient is that collaboration from the controller /
generic hub driver is needed, however it seems at least Alan would be
ok with that.
Michal Simek Feb. 24, 2021, 1:25 p.m. UTC | #9
Hi Matthias,

On 2/10/21 6:10 PM, Matthias Kaehlcke wrote:
> This series adds the onboard_usb_hub_driver, the corresponding

> device tree bindings and creation of onboard_usb_hub platform in

> the xhci-plat driver during probe().

> 

> The main issue the 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.

> 


Rob pointed me here at your series.
http://lore.kernel.org/r/CAL_JsqJedhX6typpUKbnzV7CLK6UZVjq3CyG9iY_j5DLPqvVdw@mail.gmail.com

And I have looked at RTS5411 datasheet and it looks very similar to
Microchip usb5744 chip we use.
Both have i2c/smbus and spi interfaces and also input clock.
usb5744 has also external gpio reset.

There are also usb3503 and others which should fit to this generic DT
binding.

Thanks,
Michal

That's why please keep me in the loop on v6 because I think