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

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

[Matthias Kaehlcke]

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

-- 
2.30.0.478.g8a0d178c01-goog

[PATCH v5 1/4] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Matthias Kaehlcke]

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
+
+maintainers:
+  - Matthias Kaehlcke <mka@chromium.org>
+
+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

Re: [PATCH v5 1/4] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Rob Herring]

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.

Re: [PATCH v5 1/4] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Rob Herring]

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
> 

Re: [PATCH v5 1/4] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Matthias Kaehlcke]

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.

Re: [PATCH v5 1/4] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Rob Herring]

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

Re: [PATCH v5 1/4] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Matthias Kaehlcke]

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.

[PATCH v5 2/4] USB: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

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).

Note: the current driver/binding only works with hubs connected
directly to a root hub. The reason for this is that USB devices
find their corresponding platform device by iterating over the
child device tree nodes of their parent until they find a node
that has a supported compatible string and an associated platform
device. This works as long as there is only one such device. More
than one supported onboard hub could be connected to the parent
(like on a 2nd, 3rd, ... level hub with multiple downstream
ports) some other way for identifying the platform device is
needed. The relationship could be established through a phandle
in the node of the USB device(s).

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

Changes in v5:
- the platform device is now instantiated from the same DT node
  as the 'primary' USB hub device
  - use the USB compatible strings for the platform device
  - refactored _find_onboard_hub() to search the parents child
    nodes for a platform device with a matching compatible string
  - added exported function of_is_onboard_usb_hub() to allow other
    drivers (like xhci_plat) to check if one of their child DT nodes
    is a supported hub
- use late suspend to make sure info about wakeup enabled descendants
  is updated
- call driver_attach() for the USB driver in onboard_hub_probe() to
  make sure the driver is re-attached after the device_release_driver()
  calls in onboard_hub_remove()
- renamed sysfs attribute 'power_off_in_suspend' to
  'always_powered_in_suspend'
- added sysfs symlinks between platform device and USB devices
- marked 'onboard_hub_pm_ops' as __maybe_unused
- removed 'realtek' compatible string which is not needed at this
  point
- fix log for regulator_disable() failure

Changes in v4:
- updated Kconfig documentation
- changed the loop in onboard_hub_remove() to release the hub lock
  before unbinding the USB device and make self deadlock prevention
  less clunky
- fixed return value in onboard_hub_usbdev_probe()
- added entry to MAINTAINERS file

Changes in v3:
- updated the commit message
- updated description in Kconfig
- remove include of 'core/usb.h'
- use 'is_powered_on' flag instead of 'has_wakeup_capable_descendants'
- added 'going_away' flag to struct onboard_hub
  - don't allow adding new USB devices when the platform device is going away
  - don't bother with deleting the list item in onboard_hub_remove_usbdev()
    when the platform device is going away
- don't assume in onboard_hub_suspend() that all USB hub devices are
  connected to the same controller
- removed unnecessary devm_kfree() from onboard_hub_remove_usbdev()
- fixed error handling in onboard_hub_remove_usbdev()
- use kstrtobool() instead of strtobool() in power_off_in_suspend_store()
- unbind USB devices in onboard_hub_remove() to avoid dangling references
  to the platform device
- moved put_device() for platform device to _find_onboard_hub()
- changed return value of onboard_hub_remove_usbdev() to void
- evaluate return value of onboard_hub_add_usbdev()
- register 'power_off_in_suspend' as managed device attribute
- use USB_DEVICE macro instead manual initialization
- add unwinding to onboard_hub_init()
- updated MODULE_DESCRIPTION
- use module_init() instead of device_initcall()

Changes in v2:
- check wakeup enabled state of the USB controller instead of
  using 'wakeup-source' property
- use sysfs attribute instead of DT property to determine if
  the hub should be powered off at all during system suspend
- added missing brace in onboard_hub_suspend()
- updated commit message
- use pm_ptr for pm_ops as suggested by Alan

Changes in v1:
- renamed the driver to 'onboard_usb_hub'
- single file for platform and USB driver
- USB hub devices register with the platform device
  - the DT includes a phandle of the platform device
- the platform device now controls when power is turned off
- the USB driver became a very thin subclass of the generic USB
  driver
- enabled autosuspend support

 MAINTAINERS                        |   7 +
 drivers/usb/misc/Kconfig           |  18 ++
 drivers/usb/misc/Makefile          |   1 +
 drivers/usb/misc/onboard_usb_hub.c | 409 +++++++++++++++++++++++++++++
 include/linux/usb/onboard_hub.h    |  15 ++
 5 files changed, 450 insertions(+)
 create mode 100644 drivers/usb/misc/onboard_usb_hub.c
 create mode 100644 include/linux/usb/onboard_hub.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d3e847f7f3dc..05502ce8d5c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13188,6 +13188,13 @@ S:	Maintained
 T:	git git://linuxtv.org/media_tree.git
 F:	drivers/media/i2c/ov9734.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 8f1144359012..9a77ce5483dc 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -284,3 +284,21 @@ config BRCM_USB_PINMAP
 	  This option enables support for remapping some USB external
 	  signals, which are typically on dedicated pins on the chip,
 	  to any gpio.
+
+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 5f4e598573ab..2c5aec6f1b26 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_USB_CHAOSKEY)		+= chaoskey.o
 obj-$(CONFIG_USB_SISUSBVGA)		+= sisusbvga/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)	+= lvstest.o
 obj-$(CONFIG_BRCM_USB_PINMAP)		+= brcmstb-usb-pinmap.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..b88aaefa95f4
--- /dev/null
+++ b/drivers/usb/misc/onboard_usb_hub.c
@@ -0,0 +1,409 @@
+// 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/sysfs.h>
+#include <linux/usb.h>
+#include <linux/usb/hcd.h>
+
+static struct usb_device_driver onboard_hub_usbdev_driver;
+
+/************************** Platform driver **************************/
+
+struct udev_node {
+	struct usb_device *udev;
+	struct list_head list;
+};
+
+struct onboard_hub {
+	struct regulator *vdd;
+	struct device *dev;
+	bool always_powered_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 disable 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->always_powered_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;
+	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));
+
+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);
+}
+
+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);
+	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);
+
+	return 0;
+}
+
+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 = "usbbda,411" },
+	{ .compatible = "usbbda,5411" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, onboard_hub_match);
+
+bool of_is_onboard_usb_hub(const struct device_node *np)
+{
+	return !!of_match_node(onboard_hub_match, np);
+}
+EXPORT_SYMBOL_GPL(of_is_onboard_usb_hub);
+
+static const struct dev_pm_ops __maybe_unused onboard_hub_pm_ops = {
+	SET_LATE_SYSTEM_SLEEP_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
+
+/*
+ * Returns the onboard_hub platform device that is associated with the USB
+ * device passed as parameter.
+ *
+ * The function assumes that only one physical hub is connected to the
+ * parent, more complex configurations are not supported.
+ */
+static struct onboard_hub *_find_onboard_hub(struct device *dev)
+{
+	struct device_node *np;
+
+	for_each_child_of_node(dev->of_node->parent, np) {
+		struct platform_device *pdev;
+
+		if (!of_match_node(onboard_hub_match, np))
+			continue;
+
+		pdev = of_find_device_by_node(np);
+		if (pdev) {
+			of_node_put(np);
+			put_device(&pdev->dev);
+			return dev_get_drvdata(&pdev->dev);
+		}
+	}
+
+	return ERR_PTR(-EPROBE_DEFER);
+}
+
+static int onboard_hub_usbdev_probe(struct usb_device *udev)
+{
+	struct device *dev = &udev->dev;
+	struct onboard_hub *hub;
+	int err;
+
+	/* 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);
+
+	err = onboard_hub_add_usbdev(hub, udev);
+	if (err)
+		return err;
+
+	WARN_ON(sysfs_create_link(&udev->dev.kobj, &hub->dev->kobj, "onboard_hub_dev"));
+
+	return 0;
+}
+
+static void onboard_hub_usbdev_disconnect(struct usb_device *udev)
+{
+	struct onboard_hub *hub = dev_get_drvdata(&udev->dev);
+
+	sysfs_remove_link(&udev->dev.kobj, "onboard_hub_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");
diff --git a/include/linux/usb/onboard_hub.h b/include/linux/usb/onboard_hub.h
new file mode 100644
index 000000000000..9be52dfae653
--- /dev/null
+++ b/include/linux/usb/onboard_hub.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __LINUX_USB_ONBOARD_HUB_H
+#define __LINUX_USB_ONBOARD_HUB_H
+
+#ifdef CONFIG_USB_ONBOARD_HUB
+bool of_is_onboard_usb_hub(const struct device_node *np);
+#else
+static inline bool of_is_onboard_usb_hub(const struct device_node *np)
+{
+	return false;
+}
+#endif
+
+#endif /* __LINUX_USB_ONBOARD_HUB_H */
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH v5 2/4] USB: misc: Add onboard_usb_hub driver

[Greg Kroah-Hartman]

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

Re: [PATCH v5 2/4] USB: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

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

[PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Matthias Kaehlcke]

Check during probe() if a hub supported by the onboard_usb_hub
driver is connected to the controller. If such a hub is found
create the corresponding platform device. This requires the
device tree to have a node for the hub with its vendor and
product id (which is not common for USB devices). Further the
platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.

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

Changes in v5:
- patch added to the series

 drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
 include/linux/usb/hcd.h      |  2 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 4d34f6005381..e785fa109eea 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -15,6 +15,7 @@
 #include <linux/of.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/usb/onboard_hub.h>
 #include <linux/usb/phy.h>
 #include <linux/slab.h>
 #include <linux/acpi.h>
@@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	int			ret;
 	int			irq;
 	struct xhci_plat_priv	*priv = NULL;
+	struct device_node	*np;
 
 
 	if (usb_disabled())
@@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
 	 */
 	pm_runtime_forbid(&pdev->dev);
 
+	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
+	if (np && of_is_onboard_usb_hub(np)) {
+		struct platform_device *pdev;
+
+		pdev = of_platform_device_create(np, NULL, NULL);
+		if (pdev)
+			hcd->onboard_hub_dev = &pdev->dev;
+		else
+			xhci_warn(xhci, "failed to create onboard hub platform device\n");
+	}
+
 	return 0;
 
 
@@ -402,6 +415,9 @@ static int xhci_plat_remove(struct platform_device *dev)
 	usb_remove_hcd(hcd);
 	usb_put_hcd(shared_hcd);
 
+	if (hcd->onboard_hub_dev)
+		of_platform_device_destroy(hcd->onboard_hub_dev, NULL);
+
 	clk_disable_unprepare(clk);
 	clk_disable_unprepare(reg_clk);
 	usb_put_hcd(hcd);
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index 96281cd50ff6..d02a508e19b0 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -225,6 +225,8 @@ struct usb_hcd {
 	 * (ohci 32, uhci 1024, ehci 256/512/1024).
 	 */
 
+	struct device *onboard_hub_dev;
+
 	/* The HC driver's private data is stored at the end of
 	 * this structure.
 	 */
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Krzysztof Kozlowski]

On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> Check during probe() if a hub supported by the onboard_usb_hub
> driver is connected to the controller. If such a hub is found
> create the corresponding platform device. This requires the
> device tree to have a node for the hub with its vendor and
> product id (which is not common for USB devices). Further the
> platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> 
> Changes in v5:
> - patch added to the series
> 
>  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
>  include/linux/usb/hcd.h      |  2 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 4d34f6005381..e785fa109eea 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -15,6 +15,7 @@
>  #include <linux/of.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> +#include <linux/usb/onboard_hub.h>
>  #include <linux/usb/phy.h>
>  #include <linux/slab.h>
>  #include <linux/acpi.h>
> @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  	int			ret;
>  	int			irq;
>  	struct xhci_plat_priv	*priv = NULL;
> +	struct device_node	*np;
>  
>  
>  	if (usb_disabled())
> @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  	 */
>  	pm_runtime_forbid(&pdev->dev);
>  
> +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
> +	if (np && of_is_onboard_usb_hub(np)) {

This looks hackish... what if later we have something else than hub?
Another if()?

What if hub could be connected to something else than XHCI controller?

Best regards,
Krzysztof

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Matthias Kaehlcke]

Hi Krzysztof,

On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> > Check during probe() if a hub supported by the onboard_usb_hub
> > driver is connected to the controller. If such a hub is found
> > create the corresponding platform device. This requires the
> > device tree to have a node for the hub with its vendor and
> > product id (which is not common for USB devices). Further the
> > platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.
> > 
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > 
> > Changes in v5:
> > - patch added to the series
> > 
> >  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
> >  include/linux/usb/hcd.h      |  2 ++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > index 4d34f6005381..e785fa109eea 100644
> > --- a/drivers/usb/host/xhci-plat.c
> > +++ b/drivers/usb/host/xhci-plat.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/of.h>
> >  #include <linux/of_device.h>
> >  #include <linux/platform_device.h>
> > +#include <linux/usb/onboard_hub.h>
> >  #include <linux/usb/phy.h>
> >  #include <linux/slab.h>
> >  #include <linux/acpi.h>
> > @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
> >  	int			ret;
> >  	int			irq;
> >  	struct xhci_plat_priv	*priv = NULL;
> > +	struct device_node	*np;
> >  
> >  
> >  	if (usb_disabled())
> > @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
> >  	 */
> >  	pm_runtime_forbid(&pdev->dev);
> >  
> > +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
> > +	if (np && of_is_onboard_usb_hub(np)) {
> 
> This looks hackish... what if later we have something else than hub?
> Another if()?
> 
> What if hub could be connected to something else than XHCI controller?

In earlier versions this was standalone driver, which was more flexible and
didn't require cooperation from the XHCI driver:

https://lore.kernel.org/patchwork/patch/1313001/

Rob Herring raised objections about the DT bindings, since the USB hub would be
represented twice in the DT, once in the USB hierachry (with an explicit node or
implicitly) plus a node for the platform device for the new driver:

https://lore.kernel.org/patchwork/patch/1305395/
https://lore.kernel.org/patchwork/patch/1313000/

Alan Stern suggested to create the platform device in the XHCI platform driver:

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

I wasn't super happy about involving xhci-plat, but at least the code is minimal
and all the device specific stuff is handled by the onboard_usb_hub driver.

If you have better suggestions that might satisfy all parties please let us
know :)

Matthias

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Stephen Boyd]

Quoting Matthias Kaehlcke (2021-02-10 14:20:18)
> 
> On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> > 
> > This looks hackish... what if later we have something else than hub?
> > Another if()?
> > 
> > What if hub could be connected to something else than XHCI controller?
> 
> In earlier versions this was standalone driver, which was more flexible and
> didn't require cooperation from the XHCI driver:
> 
> https://lore.kernel.org/patchwork/patch/1313001/
> 
> Rob Herring raised objections about the DT bindings, since the USB hub would be
> represented twice in the DT, once in the USB hierachry (with an explicit node or
> implicitly) plus a node for the platform device for the new driver:
> 
> https://lore.kernel.org/patchwork/patch/1305395/
> https://lore.kernel.org/patchwork/patch/1313000/
> 
> Alan Stern suggested to create the platform device in the XHCI platform driver:
> 
> https://lore.kernel.org/patchwork/patch/1313000/#1510227
> 
> I wasn't super happy about involving xhci-plat, but at least the code is minimal
> and all the device specific stuff is handled by the onboard_usb_hub driver.
> 
> If you have better suggestions that might satisfy all parties please let us
> know :)
> 

Is it possible to use the graph binding to connect the USB controller on
the SoC to the port on the hub? Then the hub would be a standalone node
at the root of DT connected to the USB controller (or phy) and xhci code
could probe the firmware to see if there's a graph connection downstream
that is a powered hub like this. I didn't see this idea mentioned in the
previous discussions, but maybe I missed it.

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Matthias Kaehlcke]

Hi Stephen,

On Thu, Feb 11, 2021 at 11:14:39AM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2021-02-10 14:20:18)
> > 
> > On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> > > 
> > > This looks hackish... what if later we have something else than hub?
> > > Another if()?
> > > 
> > > What if hub could be connected to something else than XHCI controller?
> > 
> > In earlier versions this was standalone driver, which was more flexible and
> > didn't require cooperation from the XHCI driver:
> > 
> > https://lore.kernel.org/patchwork/patch/1313001/
> > 
> > Rob Herring raised objections about the DT bindings, since the USB hub would be
> > represented twice in the DT, once in the USB hierachry (with an explicit node or
> > implicitly) plus a node for the platform device for the new driver:
> > 
> > https://lore.kernel.org/patchwork/patch/1305395/
> > https://lore.kernel.org/patchwork/patch/1313000/
> > 
> > Alan Stern suggested to create the platform device in the XHCI platform driver:
> > 
> > https://lore.kernel.org/patchwork/patch/1313000/#1510227
> > 
> > I wasn't super happy about involving xhci-plat, but at least the code is minimal
> > and all the device specific stuff is handled by the onboard_usb_hub driver.
> > 
> > If you have better suggestions that might satisfy all parties please let us
> > know :)
> > 
> 
> Is it possible to use the graph binding to connect the USB controller on
> the SoC to the port on the hub? Then the hub would be a standalone node
> at the root of DT connected to the USB controller (or phy) and xhci code
> could probe the firmware to see if there's a graph connection downstream
> that is a powered hub like this. I didn't see this idea mentioned in the
> previous discussions, but maybe I missed it.

Thanks for bringing this up. I'm not sure I completely understand your
suggestion, but in general it seems a direction that could be worth
exploring.

I think something like the following should work even without requiring
cooperation from the XHCI code:

onboard-usb-hub {
    compatible = “realtek,rts5411”, “onboard_usb_hub”;
    #address-cells = <1>;
    #size-cells = <0>;

    vdd-supply = <&pp3300_hub>;

    port@0 {
        reg = <0>;

        rts5411_3_0: endpoint {
            // should not be needed
            remote-endpoint = <&usb_1_dwc3_port1>;
        };
    };

    port@1 {
        reg = <1>;

        rts5411_2_0: endpoint {
            // should not be needed
            remote-endpoint = <&usb_1_dwc3_port2>;
        };
    };
};

&usb_1_dwc3 {
    dr_mode = "host";
    #address-cells = <1>;
    #size-cells = <0>;

    port@1 {
        reg = <1>;

        usb_1_dwc3_port1: endpoint {
            remote-endpoint = <&rts5411_3_0>;
        };
    };

    port@2 {
        reg = <2>;

        usb_1_dwc3_port2: endpoint {
            remote-endpoint = <&rts5411_2_0>;
        };
    };
};

That looks like an actual description of the hardware, without multiple DT
nodes for the hub.

The USB part of the onboard_hub driver could determine the platform device
from the remote endpoint and register the USB device with it.

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Stephen Boyd]

Quoting Matthias Kaehlcke (2021-02-11 12:36:35)
> Hi Stephen,
> 
> On Thu, Feb 11, 2021 at 11:14:39AM -0800, Stephen Boyd wrote:
> > 
> > Is it possible to use the graph binding to connect the USB controller on
> > the SoC to the port on the hub? Then the hub would be a standalone node
> > at the root of DT connected to the USB controller (or phy) and xhci code
> > could probe the firmware to see if there's a graph connection downstream
> > that is a powered hub like this. I didn't see this idea mentioned in the
> > previous discussions, but maybe I missed it.
> 
> Thanks for bringing this up. I'm not sure I completely understand your
> suggestion, but in general it seems a direction that could be worth
> exploring.

Cool.

> 
> I think something like the following should work even without requiring
> cooperation from the XHCI code:
> 
> onboard-usb-hub {
>     compatible = “realtek,rts5411”, “onboard_usb_hub”;
>     #address-cells = <1>;
>     #size-cells = <0>;
> 
>     vdd-supply = <&pp3300_hub>;
> 
>     port@0 {
>         reg = <0>;
> 
>         rts5411_3_0: endpoint {
>             // should not be needed
>             remote-endpoint = <&usb_1_dwc3_port1>;
>         };
>     };
> 
>     port@1 {
>         reg = <1>;
> 
>         rts5411_2_0: endpoint {
>             // should not be needed
>             remote-endpoint = <&usb_1_dwc3_port2>;
>         };
>     };
> };
> 
> &usb_1_dwc3 {
>     dr_mode = "host";
>     #address-cells = <1>;
>     #size-cells = <0>;
> 
>     port@1 {
>         reg = <1>;
> 
>         usb_1_dwc3_port1: endpoint {
>             remote-endpoint = <&rts5411_3_0>;
>         };
>     };
> 
>     port@2 {
>         reg = <2>;
> 
>         usb_1_dwc3_port2: endpoint {
>             remote-endpoint = <&rts5411_2_0>;
>         };
>     };
> };
> 
> That looks like an actual description of the hardware, without multiple DT
> nodes for the hub.
> 
> The USB part of the onboard_hub driver could determine the platform device
> from the remote endpoint and register the USB device with it.

Yeah you got it, this is what I'm suggesting. I'd like to go even
further and also describe the ports on "the other side" or "downstream
facing side" of the USB hub that go to things like type-c ports or
type-a ports. This would allow us to describe the USB topology and how
it is physically connected to ports on the device that humans see. But
that's mostly a job for the type-c subsystem, so it's a parallel
discussion that's only related because of the graph binding.

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Rob Herring]

On Thu, Feb 11, 2021 at 2:45 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Matthias Kaehlcke (2021-02-11 12:36:35)
> > Hi Stephen,
> >
> > On Thu, Feb 11, 2021 at 11:14:39AM -0800, Stephen Boyd wrote:
> > >
> > > Is it possible to use the graph binding to connect the USB controller on
> > > the SoC to the port on the hub? Then the hub would be a standalone node
> > > at the root of DT connected to the USB controller (or phy) and xhci code
> > > could probe the firmware to see if there's a graph connection downstream
> > > that is a powered hub like this. I didn't see this idea mentioned in the
> > > previous discussions, but maybe I missed it.
> >
> > Thanks for bringing this up. I'm not sure I completely understand your
> > suggestion, but in general it seems a direction that could be worth
> > exploring.
>
> Cool.
>
> >
> > I think something like the following should work even without requiring
> > cooperation from the XHCI code:
> >
> > onboard-usb-hub {
> >     compatible = “realtek,rts5411”, “onboard_usb_hub”;
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> >
> >     vdd-supply = <&pp3300_hub>;
> >
> >     port@0 {
> >         reg = <0>;
> >
> >         rts5411_3_0: endpoint {
> >             // should not be needed
> >             remote-endpoint = <&usb_1_dwc3_port1>;
> >         };
> >     };
> >
> >     port@1 {
> >         reg = <1>;
> >
> >         rts5411_2_0: endpoint {
> >             // should not be needed
> >             remote-endpoint = <&usb_1_dwc3_port2>;
> >         };
> >     };
> > };
> >
> > &usb_1_dwc3 {
> >     dr_mode = "host";
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> >
> >     port@1 {
> >         reg = <1>;
> >
> >         usb_1_dwc3_port1: endpoint {
> >             remote-endpoint = <&rts5411_3_0>;
> >         };
> >     };
> >
> >     port@2 {
> >         reg = <2>;
> >
> >         usb_1_dwc3_port2: endpoint {
> >             remote-endpoint = <&rts5411_2_0>;
> >         };
> >     };
> > };
> >
> > That looks like an actual description of the hardware, without multiple DT
> > nodes for the hub.
> >
> > The USB part of the onboard_hub driver could determine the platform device
> > from the remote endpoint and register the USB device with it.
>
> Yeah you got it, this is what I'm suggesting. I'd like to go even
> further and also describe the ports on "the other side" or "downstream
> facing side" of the USB hub that go to things like type-c ports or
> type-a ports. This would allow us to describe the USB topology and how
> it is physically connected to ports on the device that humans see. But
> that's mostly a job for the type-c subsystem, so it's a parallel
> discussion that's only related because of the graph binding.

I'd like to see a complete case that includes connectors. I really
need someone to worry about USB bindings with a view on the big
picture. The piecemeal additions don't result in the best design.

Rob

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Rob Herring]

On Thu, Feb 11, 2021 at 1:14 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Matthias Kaehlcke (2021-02-10 14:20:18)
> >
> > On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> > >
> > > This looks hackish... what if later we have something else than hub?
> > > Another if()?
> > >
> > > What if hub could be connected to something else than XHCI controller?
> >
> > In earlier versions this was standalone driver, which was more flexible and
> > didn't require cooperation from the XHCI driver:
> >
> > https://lore.kernel.org/patchwork/patch/1313001/
> >
> > Rob Herring raised objections about the DT bindings, since the USB hub would be
> > represented twice in the DT, once in the USB hierachry (with an explicit node or
> > implicitly) plus a node for the platform device for the new driver:
> >
> > https://lore.kernel.org/patchwork/patch/1305395/
> > https://lore.kernel.org/patchwork/patch/1313000/
> >
> > Alan Stern suggested to create the platform device in the XHCI platform driver:
> >
> > https://lore.kernel.org/patchwork/patch/1313000/#1510227
> >
> > I wasn't super happy about involving xhci-plat, but at least the code is minimal
> > and all the device specific stuff is handled by the onboard_usb_hub driver.
> >
> > If you have better suggestions that might satisfy all parties please let us
> > know :)
> >
>
> Is it possible to use the graph binding to connect the USB controller on
> the SoC to the port on the hub? Then the hub would be a standalone node
> at the root of DT connected to the USB controller (or phy) and xhci code
> could probe the firmware to see if there's a graph connection downstream
> that is a powered hub like this. I didn't see this idea mentioned in the
> previous discussions, but maybe I missed it.

An orphan at the root node is exactly what I don't want to see here.
I'm happy with the binding now from a skim of it. The kernel support
does seem kind of hacky though.

Rob

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Greg Kroah-Hartman]

On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> Check during probe() if a hub supported by the onboard_usb_hub
> driver is connected to the controller. If such a hub is found
> create the corresponding platform device. This requires the
> device tree to have a node for the hub with its vendor and
> product id (which is not common for USB devices). Further the
> platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> 
> Changes in v5:
> - patch added to the series
> 
>  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
>  include/linux/usb/hcd.h      |  2 ++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 4d34f6005381..e785fa109eea 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -15,6 +15,7 @@
>  #include <linux/of.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> +#include <linux/usb/onboard_hub.h>
>  #include <linux/usb/phy.h>
>  #include <linux/slab.h>
>  #include <linux/acpi.h>
> @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  	int			ret;
>  	int			irq;
>  	struct xhci_plat_priv	*priv = NULL;
> +	struct device_node	*np;
>  
>  
>  	if (usb_disabled())
> @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  	 */
>  	pm_runtime_forbid(&pdev->dev);
>  
> +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
> +	if (np && of_is_onboard_usb_hub(np)) {
> +		struct platform_device *pdev;
> +
> +		pdev = of_platform_device_create(np, NULL, NULL);

A platform device is a child of another platform device?  Ok, but
really, why?  What uses this device?

thanks,

greg k-h

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Matthias Kaehlcke]

Hi Greg,

On Thu, Feb 11, 2021 at 07:58:23AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> > Check during probe() if a hub supported by the onboard_usb_hub
> > driver is connected to the controller. If such a hub is found
> > create the corresponding platform device. This requires the
> > device tree to have a node for the hub with its vendor and
> > product id (which is not common for USB devices). Further the
> > platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.
> > 
> > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > ---
> > 
> > Changes in v5:
> > - patch added to the series
> > 
> >  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
> >  include/linux/usb/hcd.h      |  2 ++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > index 4d34f6005381..e785fa109eea 100644
> > --- a/drivers/usb/host/xhci-plat.c
> > +++ b/drivers/usb/host/xhci-plat.c
> > @@ -15,6 +15,7 @@
> >  #include <linux/of.h>
> >  #include <linux/of_device.h>
> >  #include <linux/platform_device.h>
> > +#include <linux/usb/onboard_hub.h>
> >  #include <linux/usb/phy.h>
> >  #include <linux/slab.h>
> >  #include <linux/acpi.h>
> > @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
> >  	int			ret;
> >  	int			irq;
> >  	struct xhci_plat_priv	*priv = NULL;
> > +	struct device_node	*np;
> >  
> >  
> >  	if (usb_disabled())
> > @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
> >  	 */
> >  	pm_runtime_forbid(&pdev->dev);
> >  
> > +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
> > +	if (np && of_is_onboard_usb_hub(np)) {
> > +		struct platform_device *pdev;
> > +
> > +		pdev = of_platform_device_create(np, NULL, NULL);
> 
> A platform device is a child of another platform device?  Ok, but
> really, why?  What uses this device?

In earlier versions there was a standalone platform device:
https://lore.kernel.org/patchwork/patch/1313001/

However this was rejected by Rob, since the DT would require a node for the
platform device and (implicit or explicit) nodes for the USB devices,
representing the same physical device:

https://lore.kernel.org/patchwork/patch/1305395/
https://lore.kernel.org/patchwork/patch/1313000/

Both Doug Anderson and myself argued that it seems legitimate to distinguish
between the devices connected to the USB bus, and the chip which might have
GPIOs, regulators, clocks, ... but apparently our arguments were not
convincing enough.

Re: [PATCH v5 3/4] usb: host: xhci-plat: Create platform device for onboard hubs in probe()

[Matthias Kaehlcke]

On Thu, Feb 11, 2021 at 10:45:48AM -0800, Matthias Kaehlcke wrote:
> Hi Greg,
> 
> On Thu, Feb 11, 2021 at 07:58:23AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> > > Check during probe() if a hub supported by the onboard_usb_hub
> > > driver is connected to the controller. If such a hub is found
> > > create the corresponding platform device. This requires the
> > > device tree to have a node for the hub with its vendor and
> > > product id (which is not common for USB devices). Further the
> > > platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.
> > > 
> > > Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> > > ---
> > > 
> > > Changes in v5:
> > > - patch added to the series
> > > 
> > >  drivers/usb/host/xhci-plat.c | 16 ++++++++++++++++
> > >  include/linux/usb/hcd.h      |  2 ++
> > >  2 files changed, 18 insertions(+)
> > > 
> > > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > > index 4d34f6005381..e785fa109eea 100644
> > > --- a/drivers/usb/host/xhci-plat.c
> > > +++ b/drivers/usb/host/xhci-plat.c
> > > @@ -15,6 +15,7 @@
> > >  #include <linux/of.h>
> > >  #include <linux/of_device.h>
> > >  #include <linux/platform_device.h>
> > > +#include <linux/usb/onboard_hub.h>
> > >  #include <linux/usb/phy.h>
> > >  #include <linux/slab.h>
> > >  #include <linux/acpi.h>
> > > @@ -184,6 +185,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
> > >  	int			ret;
> > >  	int			irq;
> > >  	struct xhci_plat_priv	*priv = NULL;
> > > +	struct device_node	*np;
> > >  
> > >  
> > >  	if (usb_disabled())
> > > @@ -356,6 +358,17 @@ static int xhci_plat_probe(struct platform_device *pdev)
> > >  	 */
> > >  	pm_runtime_forbid(&pdev->dev);
> > >  
> > > +	np = usb_of_get_device_node(hcd->self.root_hub, hcd->self.busnum);
> > > +	if (np && of_is_onboard_usb_hub(np)) {
> > > +		struct platform_device *pdev;
> > > +
> > > +		pdev = of_platform_device_create(np, NULL, NULL);
> > 
> > A platform device is a child of another platform device?  Ok, but
> > really, why?  What uses this device?
> 
> In earlier versions there was a standalone platform device:
> https://lore.kernel.org/patchwork/patch/1313001/
> 
> However this was rejected by Rob, since the DT would require a node for the
> platform device and (implicit or explicit) nodes for the USB devices,
> representing the same physical device:
> 
> https://lore.kernel.org/patchwork/patch/1305395/
> https://lore.kernel.org/patchwork/patch/1313000/
> 
> Both Doug Anderson and myself argued that it seems legitimate to distinguish
> between the devices connected to the USB bus, and the chip which might have
> GPIOs, regulators, clocks, ... but apparently our arguments were not
> convincing enough.

To let the xhci-plat driver create the platform device was suggested by Alan:

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

Personally I would favor a standalone platform device, since it provides more
flexiblity (also works for hubs connected to a non-root hub) and doesn't require
cooperation from other driver, however I doubt I could convince Rob of the
corresponding DT bindings.

[PATCH v5 4/4] arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub

[Matthias Kaehlcke]

Add nodes for the onboard USB hub on trogdor devices. Remove the
'always-on' and 'boot-on' properties from the hub regulator, since
the regulator is now managed by the onboard_usb_hub driver.

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

Changes in v5:
 - patch added to the series

 .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts  | 15 ++++-----------
 .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts  | 11 ++---------
 arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts | 15 ++++-----------
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi   | 18 +++++++++++++++---
 4 files changed, 25 insertions(+), 34 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
index 30e3e769d2b4..a557c269b998 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r0.dts
@@ -14,17 +14,6 @@ / {
 	compatible = "google,lazor-rev0", "qcom,sc7180";
 };
 
-&pp3300_hub {
-	/* pp3300_l7c is used to power the USB hub */
-	/delete-property/regulator-always-on;
-	/delete-property/regulator-boot-on;
-};
-
-&pp3300_l7c {
-	regulator-always-on;
-	regulator-boot-on;
-};
-
 &sn65dsi86_out {
 	/*
 	 * Lane 0 was incorrectly mapped on the cable, but we've now decided
@@ -33,3 +22,7 @@ &sn65dsi86_out {
 	 */
 	lane-polarities = <1 0>;
 };
+
+&usb_hub_2_0 {
+	 vdd-supply = <&pp3300_l7c>;
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
index c2ef06367baf..d182b7a231f4 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor-r1.dts
@@ -14,13 +14,6 @@ / {
 	compatible = "google,lazor-rev1", "google,lazor-rev2", "qcom,sc7180";
 };
 
-&pp3300_hub {
-	/* pp3300_l7c is used to power the USB hub */
-	/delete-property/regulator-always-on;
-	/delete-property/regulator-boot-on;
-};
-
-&pp3300_l7c {
-	regulator-always-on;
-	regulator-boot-on;
+&usb_hub_2_0 {
+	 vdd-supply = <&pp3300_l7c>;
 };
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts b/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
index 2cb522d6962e..699e7815697a 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-r1.dts
@@ -53,21 +53,14 @@ ap_ts: touchscreen@10 {
 	};
 };
 
-&pp3300_hub {
-	/* pp3300_l7c is used to power the USB hub */
-	/delete-property/regulator-always-on;
-	/delete-property/regulator-boot-on;
-};
-
-&pp3300_l7c {
-	regulator-always-on;
-	regulator-boot-on;
-};
-
 &sdhc_2 {
 	status = "okay";
 };
 
+&usb_hub_2_0 {
+	 vdd-supply = <&pp3300_l7c>;
+};
+
 /* PINCTRL - board-specific pinctrl */
 
 &tlmm {
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 8ed7dd39f6e3..9add00cc32a5 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -203,9 +203,6 @@ pp3300_hub: pp3300-hub {
 		pinctrl-names = "default";
 		pinctrl-0 = <&en_pp3300_hub>;
 
-		regulator-always-on;
-		regulator-boot-on;
-
 		vin-supply = <&pp3300_a>;
 	};
 
@@ -894,6 +891,21 @@ &usb_1 {
 
 &usb_1_dwc3 {
 	dr_mode = "host";
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	/* 2.0 hub on port 1 */
+	usb_hub_2_0: hub@1 {
+		compatible = "usbbda,5411";
+		reg = <1>;
+		vdd-supply = <&pp3300_hub>;
+	};
+
+	/* 3.0 hub on port 2 */
+	usb_hub_3_0: hub@2 {
+		compatible = "usbbda,411";
+		reg = <2>;
+	};
 };
 
 &usb_1_hsphy {
-- 
2.30.0.478.g8a0d178c01-goog

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

[Krzysztof Kozlowski]

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

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

[Matthias Kaehlcke]

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.

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

[Michal Simek]

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