[0/3] External VBUS port power handling for onboard USB devices

Hi,

some PCB designs don't connect the USB hub port power line to the
dedicated hub port power pin. Instead they use a host controllable GPIO
line to enable the VBUS power.

This patchset addresses this use-case by hooking into the
usb_clear/set_port_feature() function and call the usb-onboard-dev hook
if available. The usb-onboard-dev driver is taking care of the rest.

Regards,
  Marco

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
Marco Felsch (3):
      usb: hub: add infrastructure to pass onboard_dev port features
      dt-bindings: usb: microchip,usb2514: add support for port vbus-supply
      usb: misc: onboard_dev: add ext-vbus-supply handling

 .../devicetree/bindings/usb/microchip,usb2514.yaml |  7 ++
 drivers/usb/core/hub.c                             | 22 ++++++-
 drivers/usb/misc/onboard_usb_dev.c                 | 76 ++++++++++++++++++++++
 drivers/usb/misc/onboard_usb_dev.h                 |  2 +
 include/linux/usb/onboard_dev.h                    |  6 ++
 5 files changed, 111 insertions(+), 2 deletions(-)
---
base-commit: 0c3836482481200ead7b416ca80c68a29cfdaabd
change-id: 20240807-b4-v6-10-topic-usb-onboard-dev-49040782d2f9

Best regards,

On Wed, Aug 07, 2024 at 04:36:52PM +0200, Marco Felsch wrote:
> Some PCB designs don't connect the USB hub port power control GPIO and
> instead make use of an host controllable regulator. Add support for this
> use-case by introducing an portX-vbus-supply property.
> 
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
>  Documentation/devicetree/bindings/usb/microchip,usb2514.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> index 783c27591e56..51d02c4b8f2d 100644
> --- a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> +++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> @@ -35,6 +35,13 @@ required:
>    - compatible
>    - reg
>  
> +patternProperties:
> +  "^port[1-7]-vbus-supply$"
> +    type: object
> +    description:
> +      Regulator controlling the USB VBUS on portX. Only required if the host
> +      controls the portX VBUS.

This is completely external to the Microchip part, right?

I think each port node should have a 'vbus-supply' property instead.

Rob

Hi Rob,

On 24-08-13, Rob Herring wrote:
> On Wed, Aug 07, 2024 at 04:36:52PM +0200, Marco Felsch wrote:
> > Some PCB designs don't connect the USB hub port power control GPIO and
> > instead make use of an host controllable regulator. Add support for this
> > use-case by introducing an portX-vbus-supply property.
> > 
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> >  Documentation/devicetree/bindings/usb/microchip,usb2514.yaml | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> > index 783c27591e56..51d02c4b8f2d 100644
> > --- a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> > +++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
> > @@ -35,6 +35,13 @@ required:
> >    - compatible
> >    - reg
> >  
> > +patternProperties:
> > +  "^port[1-7]-vbus-supply$"
> > +    type: object
> > +    description:
> > +      Regulator controlling the USB VBUS on portX. Only required if the host
> > +      controls the portX VBUS.
> 
> This is completely external to the Microchip part, right?
> 
> I think each port node should have a 'vbus-supply' property instead.

This was my first approach but the problem is that we currently don't
support such use-case:

	parent-node {
		/* Parent controlling the supply of the child node */

		child-node {
			vbus-supply = <&reg>;
		};
	};

at least I didn't found such use-case. I'm happy for pointers if you
know more :) At the moment *-supply properties and device-nodes are
bound together:
	
	parent-node {
		vbus-supply = <&reg>;
	};

Regards,
  Marco

> 
> Rob
>