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