[PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

This series adds:
- the onboard_usb_hub_driver
- glue in the xhci-plat driver to create and destroy the
  onboard_usb_hub platform devices if needed
- a device tree binding for the Realtek RTS5411 USB hub controller
- device tree changes that add RTS5411 entries for the QCA SC7180
  based boards trogdor and lazor
- a couple of stubs for platform device functions to avoid
  unresolved symbols with certain kernel configs

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.

Changes in v16:
- added patch 'ARM: configs: Explicitly enable USB_XHCI_PLATFORM
  where needed' to keep arm32 defconfigs effectively unchanged

Changes in v15:
- adjusted dependencies of USB_DWC3_CORE to make sure it can only
  be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
  or USB_DWC3_DUAL_ROLE is selectable

Changes in v14:
- rebased on top of v5.14-rc1
- dropped DT binding patch which landed in v5.13

Changes in v13:
- added patch "usb: Specify dependency on USB_XHCI_PLATFORM with
  'depends on'" to the series to avoid Kconfig conflicts
- added patch "arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM"
  to the series to keep effective defconfig unchanged

Changes in v12:
- onboard_hub driver: use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE)
  in onboard_hub.h to also check for the driver built as module
- onboard_hub_driver: include onboard_hub.h again to make sure there
  are prototype declarations for the public functions

Changes in v11:
- support multiple onboard hubs connected to the same parent
- don't include ‘onboard_hub.h’ from the onboard hub driver

Changes in v10:
- always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m
- keep 'regulator-boot-on' property for pp3300_hub

Changes in v9:
- added dependency on ONBOARD_USB_HUB (or !!ONBOARD_USB_HUB) to
  USB_PLATFORM_XHCI

Changes in v7:
- updated DT binding
- series rebased on qcom/arm64-for-5.13

Changes in v6:
- updated summary

Changes in v5:
- cover letter added

Matthias Kaehlcke (7):
  usb: misc: Add onboard_usb_hub driver
  of/platform: Add stubs for of_platform_device_create/destroy()
  ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed
  arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
  usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
  usb: host: xhci-plat: Create platform device for onboard hubs in
    probe()
  arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub

 .../sysfs-bus-platform-onboard-usb-hub        |   8 +
 MAINTAINERS                                   |   7 +
 arch/arm/configs/exynos_defconfig             |   1 +
 arch/arm/configs/keystone_defconfig           |   1 +
 arch/arm/configs/multi_v7_defconfig           |   1 +
 arch/arm/configs/mvebu_v7_defconfig           |   1 +
 arch/arm/configs/omap2plus_defconfig          |   1 +
 arch/arm/configs/pxa_defconfig                |   1 +
 .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts |  19 +-
 .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts |  12 +-
 .../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts |  19 +-
 arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |  19 +-
 arch/arm64/configs/defconfig                  |   1 +
 drivers/usb/cdns3/Kconfig                     |   2 +-
 drivers/usb/dwc3/Kconfig                      |   5 +-
 drivers/usb/host/Kconfig                      |   5 +-
 drivers/usb/host/xhci-plat.c                  |   6 +
 drivers/usb/host/xhci.h                       |   2 +
 drivers/usb/misc/Kconfig                      |  17 +
 drivers/usb/misc/Makefile                     |   1 +
 drivers/usb/misc/onboard_usb_hub.c            | 497 ++++++++++++++++++
 include/linux/of_platform.h                   |  22 +-
 include/linux/usb/onboard_hub.h               |  18 +
 23 files changed, 627 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
 create mode 100644 drivers/usb/misc/onboard_usb_hub.c
 create mode 100644 include/linux/usb/onboard_hub.h

-- 
2.33.0.rc1.237.g0d66db33f3-goog

[PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed

[Matthias Kaehlcke]

The dependency of USB_DWC3 and USB_XHCI_MVEBU on USB_XHCI_PLATFORM
is being changed from 'select' to 'depends on' by another patch.
With that patch the defconfigs that enable one of these host
controllers also need to select USB_XHCI_PLATFORM explicitly
to keep the resulting config unchanged.

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

Changes in v16:
- patch added to the series

 arch/arm/configs/exynos_defconfig    | 1 +
 arch/arm/configs/keystone_defconfig  | 1 +
 arch/arm/configs/multi_v7_defconfig  | 1 +
 arch/arm/configs/mvebu_v7_defconfig  | 1 +
 arch/arm/configs/omap2plus_defconfig | 1 +
 arch/arm/configs/pxa_defconfig       | 1 +
 6 files changed, 6 insertions(+)

diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index f4e1873912a3..660fccb40f34 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -255,6 +255,7 @@ CONFIG_SND_SIMPLE_CARD=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_EXYNOS=y
 CONFIG_USB_OHCI_HCD=y
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index 33c917df7b32..4f66c5a5d94d 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -164,6 +164,7 @@ CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC3=y
 CONFIG_NOP_USB_XCEIV=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 52a0400fdd92..4619418e53f4 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -787,6 +787,7 @@ CONFIG_SND_AUDIO_GRAPH_CARD=m
 CONFIG_USB=y
 CONFIG_USB_OTG=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_XHCI_MVEBU=y
 CONFIG_USB_XHCI_TEGRA=m
 CONFIG_USB_EHCI_HCD=y
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index cddce57fe4b9..6cb85ec4fe54 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -103,6 +103,7 @@ CONFIG_SND_SIMPLE_CARD=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_MVEBU=y
+CONFIG_USB_XHCI_PLATFORM=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_ROOT_HUB_TT=y
 CONFIG_USB_STORAGE=y
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 2ac2418084ab..a015fb04fa25 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -562,6 +562,7 @@ CONFIG_USB=m
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=m
 CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_XHCI_PLATFORM=m
 CONFIG_USB_EHCI_HCD=m
 CONFIG_USB_OHCI_HCD=m
 CONFIG_USB_ACM=m
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index 363f1b1b08e3..e44763fe2b23 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -524,6 +524,7 @@ CONFIG_USB=m
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=m
 CONFIG_USB_XHCI_HCD=m
+CONFIG_USB_XHCI_PLATFORM=m
 CONFIG_USB_EHCI_HCD=m
 CONFIG_USB_EHCI_HCD_PLATFORM=m
 CONFIG_USB_ISP116X_HCD=m
-- 
2.33.0.rc1.237.g0d66db33f3-goog

Re: [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed

[Roger Quadros]

On 13/08/2021 22:52, Matthias Kaehlcke wrote:
> The dependency of USB_DWC3 and USB_XHCI_MVEBU on USB_XHCI_PLATFORM
> is being changed from 'select' to 'depends on' by another patch.
> With that patch the defconfigs that enable one of these host
> controllers also need to select USB_XHCI_PLATFORM explicitly
> to keep the resulting config unchanged.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

Reviewed-by: Roger Quadros <rogerq@kernel.org>

cheers,
-roger

> ---
> 
> Changes in v16:
> - patch added to the series
> 
>  arch/arm/configs/exynos_defconfig    | 1 +
>  arch/arm/configs/keystone_defconfig  | 1 +
>  arch/arm/configs/multi_v7_defconfig  | 1 +
>  arch/arm/configs/mvebu_v7_defconfig  | 1 +
>  arch/arm/configs/omap2plus_defconfig | 1 +
>  arch/arm/configs/pxa_defconfig       | 1 +
>  6 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index f4e1873912a3..660fccb40f34 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -255,6 +255,7 @@ CONFIG_SND_SIMPLE_CARD=y
>  CONFIG_USB=y
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_PLATFORM=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_EXYNOS=y
>  CONFIG_USB_OHCI_HCD=y
> diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
> index 33c917df7b32..4f66c5a5d94d 100644
> --- a/arch/arm/configs/keystone_defconfig
> +++ b/arch/arm/configs/keystone_defconfig
> @@ -164,6 +164,7 @@ CONFIG_USB=y
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_MON=y
>  CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_PLATFORM=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USB_DWC3=y
>  CONFIG_NOP_USB_XCEIV=y
> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 52a0400fdd92..4619418e53f4 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -787,6 +787,7 @@ CONFIG_SND_AUDIO_GRAPH_CARD=m
>  CONFIG_USB=y
>  CONFIG_USB_OTG=y
>  CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_PLATFORM=y
>  CONFIG_USB_XHCI_MVEBU=y
>  CONFIG_USB_XHCI_TEGRA=m
>  CONFIG_USB_EHCI_HCD=y
> diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
> index cddce57fe4b9..6cb85ec4fe54 100644
> --- a/arch/arm/configs/mvebu_v7_defconfig
> +++ b/arch/arm/configs/mvebu_v7_defconfig
> @@ -103,6 +103,7 @@ CONFIG_SND_SIMPLE_CARD=y
>  CONFIG_USB=y
>  CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_MVEBU=y
> +CONFIG_USB_XHCI_PLATFORM=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_EHCI_ROOT_HUB_TT=y
>  CONFIG_USB_STORAGE=y
> diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
> index 2ac2418084ab..a015fb04fa25 100644
> --- a/arch/arm/configs/omap2plus_defconfig
> +++ b/arch/arm/configs/omap2plus_defconfig
> @@ -562,6 +562,7 @@ CONFIG_USB=m
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_MON=m
>  CONFIG_USB_XHCI_HCD=m
> +CONFIG_USB_XHCI_PLATFORM=m
>  CONFIG_USB_EHCI_HCD=m
>  CONFIG_USB_OHCI_HCD=m
>  CONFIG_USB_ACM=m
> diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
> index 363f1b1b08e3..e44763fe2b23 100644
> --- a/arch/arm/configs/pxa_defconfig
> +++ b/arch/arm/configs/pxa_defconfig
> @@ -524,6 +524,7 @@ CONFIG_USB=m
>  CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
>  CONFIG_USB_MON=m
>  CONFIG_USB_XHCI_HCD=m
> +CONFIG_USB_XHCI_PLATFORM=m
>  CONFIG_USB_EHCI_HCD=m
>  CONFIG_USB_EHCI_HCD_PLATFORM=m
>  CONFIG_USB_ISP116X_HCD=m
> 

Re: [PATCH v16 3/7] ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed

[Krzysztof Kozlowski]

On 13/08/2021 21:52, Matthias Kaehlcke wrote:
> The dependency of USB_DWC3 and USB_XHCI_MVEBU on USB_XHCI_PLATFORM
> is being changed from 'select' to 'depends on' by another patch.
> With that patch the defconfigs that enable one of these host
> controllers also need to select USB_XHCI_PLATFORM explicitly
> to keep the resulting config unchanged.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> 
> Changes in v16:
> - patch added to the series
> 
>  arch/arm/configs/exynos_defconfig    | 1 +


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>


Best regards,
Krzysztof

[PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'

[Matthias Kaehlcke]

Some USB controller drivers that depend on the xhci-plat driver
specify this dependency using 'select' in Kconfig. This is not
recommended for symbols that have other dependencies as it may
lead to invalid configurations. Use 'depends on' to specify the
dependency instead of 'select'.

For dwc3 specify the dependency on USB_XHCI_PLATFORM in
USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
dependencies of USB_DWC3_CORE to make sure that at least one
of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
selected.

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

Changes in v16:
- none

Changes in v15:
- adjusted dependencies of USB_DWC3_CORE to make sure it can only
  be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
  or USB_DWC3_DUAL_ROLE is selectable
- updated commit message

Changes in v14:
- none

Changes in v13:
- patch added to the series

 drivers/usb/cdns3/Kconfig | 2 +-
 drivers/usb/dwc3/Kconfig  | 5 +++--
 drivers/usb/host/Kconfig  | 4 ++--
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
index b98ca0a1352a..07e12f786d48 100644
--- a/drivers/usb/cdns3/Kconfig
+++ b/drivers/usb/cdns3/Kconfig
@@ -1,7 +1,7 @@
 config USB_CDNS_SUPPORT
 	tristate "Cadence USB Support"
 	depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
-	select USB_XHCI_PLATFORM if USB_XHCI_HCD
+	depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
 	select USB_ROLE_SWITCH
 	help
 	  Say Y here if your system has a Cadence USBSS or USBSSP
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 66b1454c4db2..870f2251350a 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,8 +2,7 @@
 
 config USB_DWC3
 	tristate "DesignWare USB3 DRD Core Support"
-	depends on (USB || USB_GADGET) && HAS_DMA
-	select USB_XHCI_PLATFORM if USB_XHCI_HCD
+	depends on ((USB && USB_XHCI_PLATFORM) || USB_GADGET) && HAS_DMA
 	select USB_ROLE_SWITCH if USB_DWC3_DUAL_ROLE
 	help
 	  Say Y or M here if your system has a Dual Role SuperSpeed
@@ -30,6 +29,7 @@ choice
 config USB_DWC3_HOST
 	bool "Host only mode"
 	depends on USB=y || USB=USB_DWC3
+	depends on USB_XHCI_PLATFORM
 	help
 	  Select this when you want to use DWC3 in host mode only,
 	  thereby the gadget feature will be regressed.
@@ -44,6 +44,7 @@ config USB_DWC3_GADGET
 config USB_DWC3_DUAL_ROLE
 	bool "Dual Role mode"
 	depends on ((USB=y || USB=USB_DWC3) && (USB_GADGET=y || USB_GADGET=USB_DWC3))
+	depends on USB_XHCI_PLATFORM
 	depends on (EXTCON=y || EXTCON=USB_DWC3)
 	help
 	  This is the default mode of working of DWC3 controller where
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index df9428f1dc5e..518c2312ef0c 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -80,7 +80,7 @@ config USB_XHCI_MTK
 
 config USB_XHCI_MVEBU
 	tristate "xHCI support for Marvell Armada 375/38x/37xx"
-	select USB_XHCI_PLATFORM
+	depends on USB_XHCI_PLATFORM
 	depends on HAS_IOMEM
 	depends on ARCH_MVEBU || COMPILE_TEST
 	help
@@ -112,9 +112,9 @@ config USB_EHCI_BRCMSTB
 config USB_BRCMSTB
 	tristate "Broadcom STB USB support"
 	depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
+	depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
 	select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
 	select USB_EHCI_BRCMSTB if USB_EHCI_HCD
-	select USB_XHCI_PLATFORM if USB_XHCI_HCD
 	help
 	  Enables support for XHCI, EHCI and OHCI host controllers
 	  found in Broadcom STB SoC's.
-- 
2.33.0.rc1.237.g0d66db33f3-goog

Re: [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'

[Roger Quadros]

On 13/08/2021 22:52, Matthias Kaehlcke wrote:
> Some USB controller drivers that depend on the xhci-plat driver
> specify this dependency using 'select' in Kconfig. This is not
> recommended for symbols that have other dependencies as it may
> lead to invalid configurations. Use 'depends on' to specify the
> dependency instead of 'select'.
> 
> For dwc3 specify the dependency on USB_XHCI_PLATFORM in
> USB_DWC3_HOST and USB_DWC3_DUAL_ROLE. Also adjust the
> dependencies of USB_DWC3_CORE to make sure that at least one
> of USB_DWC3_HOST, USB_DWC3_GADGET or USB_DWC3_DUAL_ROLE can be
> selected.
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

Reviewed-by: Roger Quadros <rogerq@kernel.org>

cheers,
-roger

> ---
> 
> Changes in v16:
> - none
> 
> Changes in v15:
> - adjusted dependencies of USB_DWC3_CORE to make sure it can only
>   be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
>   or USB_DWC3_DUAL_ROLE is selectable
> - updated commit message
> 
> Changes in v14:
> - none
> 
> Changes in v13:
> - patch added to the series
> 
>  drivers/usb/cdns3/Kconfig | 2 +-
>  drivers/usb/dwc3/Kconfig  | 5 +++--
>  drivers/usb/host/Kconfig  | 4 ++--
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
> index b98ca0a1352a..07e12f786d48 100644
> --- a/drivers/usb/cdns3/Kconfig
> +++ b/drivers/usb/cdns3/Kconfig
> @@ -1,7 +1,7 @@
>  config USB_CDNS_SUPPORT
>  	tristate "Cadence USB Support"
>  	depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
> -	select USB_XHCI_PLATFORM if USB_XHCI_HCD
> +	depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
>  	select USB_ROLE_SWITCH
>  	help
>  	  Say Y here if your system has a Cadence USBSS or USBSSP
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 66b1454c4db2..870f2251350a 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -2,8 +2,7 @@
>  
>  config USB_DWC3
>  	tristate "DesignWare USB3 DRD Core Support"
> -	depends on (USB || USB_GADGET) && HAS_DMA
> -	select USB_XHCI_PLATFORM if USB_XHCI_HCD
> +	depends on ((USB && USB_XHCI_PLATFORM) || USB_GADGET) && HAS_DMA
>  	select USB_ROLE_SWITCH if USB_DWC3_DUAL_ROLE
>  	help
>  	  Say Y or M here if your system has a Dual Role SuperSpeed
> @@ -30,6 +29,7 @@ choice
>  config USB_DWC3_HOST
>  	bool "Host only mode"
>  	depends on USB=y || USB=USB_DWC3
> +	depends on USB_XHCI_PLATFORM
>  	help
>  	  Select this when you want to use DWC3 in host mode only,
>  	  thereby the gadget feature will be regressed.
> @@ -44,6 +44,7 @@ config USB_DWC3_GADGET
>  config USB_DWC3_DUAL_ROLE
>  	bool "Dual Role mode"
>  	depends on ((USB=y || USB=USB_DWC3) && (USB_GADGET=y || USB_GADGET=USB_DWC3))
> +	depends on USB_XHCI_PLATFORM
>  	depends on (EXTCON=y || EXTCON=USB_DWC3)
>  	help
>  	  This is the default mode of working of DWC3 controller where
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index df9428f1dc5e..518c2312ef0c 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -80,7 +80,7 @@ config USB_XHCI_MTK
>  
>  config USB_XHCI_MVEBU
>  	tristate "xHCI support for Marvell Armada 375/38x/37xx"
> -	select USB_XHCI_PLATFORM
> +	depends on USB_XHCI_PLATFORM
>  	depends on HAS_IOMEM
>  	depends on ARCH_MVEBU || COMPILE_TEST
>  	help
> @@ -112,9 +112,9 @@ config USB_EHCI_BRCMSTB
>  config USB_BRCMSTB
>  	tristate "Broadcom STB USB support"
>  	depends on (ARCH_BRCMSTB && PHY_BRCM_USB) || COMPILE_TEST
> +	depends on !USB_XHCI_HCD || USB_XHCI_PLATFORM
>  	select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
>  	select USB_EHCI_BRCMSTB if USB_EHCI_HCD
> -	select USB_XHCI_PLATFORM if USB_XHCI_HCD
>  	help
>  	  Enables support for XHCI, EHCI and OHCI host controllers
>  	  found in Broadcom STB SoC's.
> 

Re: [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'

[Doug Anderson]

Hi,

On Fri, Aug 13, 2021 at 12:52 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
>  config USB_DWC3
>         tristate "DesignWare USB3 DRD Core Support"
> -       depends on (USB || USB_GADGET) && HAS_DMA
> -       select USB_XHCI_PLATFORM if USB_XHCI_HCD
> +       depends on ((USB && USB_XHCI_PLATFORM) || USB_GADGET) && HAS_DMA

Technically you don't need the "USB &&", right? Since
USB_XHCI_PLATFORM is defined in 'usb/host/Kconfig' and that's only
even included if USB is defined. So it can be just:

depends on (USB_XHCI_PLATFORM || USB_GADGET) && HAS_DMA

That's not terribly important, though, so:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH v16 5/7] usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'

[Matthias Kaehlcke]

On Thu, Nov 11, 2021 at 03:48:06PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Fri, Aug 13, 2021 at 12:52 PM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> >  config USB_DWC3
> >         tristate "DesignWare USB3 DRD Core Support"
> > -       depends on (USB || USB_GADGET) && HAS_DMA
> > -       select USB_XHCI_PLATFORM if USB_XHCI_HCD
> > +       depends on ((USB && USB_XHCI_PLATFORM) || USB_GADGET) && HAS_DMA
> 
> Technically you don't need the "USB &&", right? Since
> USB_XHCI_PLATFORM is defined in 'usb/host/Kconfig' and that's only
> even included if USB is defined. So it can be just:
> 
> depends on (USB_XHCI_PLATFORM || USB_GADGET) && HAS_DMA

True, the dependency on USB isn't strictly needed.

> That's not terribly important, though, so:
> 
> Reviewed-by: Douglas Anderson <dianders@chromium.org>

Thanks!

Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

Hi Greg,

are there any actions pending or can this land in usb-testing?

I confirmed that this series can be rebased on top of v5.15-rc2
without conflicts.

Thanks

m.

On Fri, Aug 13, 2021 at 12:52:21PM -0700, Matthias Kaehlcke wrote:
> This series adds:
> - the onboard_usb_hub_driver
> - glue in the xhci-plat driver to create and destroy the
>   onboard_usb_hub platform devices if needed
> - a device tree binding for the Realtek RTS5411 USB hub controller
> - device tree changes that add RTS5411 entries for the QCA SC7180
>   based boards trogdor and lazor
> - a couple of stubs for platform device functions to avoid
>   unresolved symbols with certain kernel configs
> 
> 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.
> 
> Changes in v16:
> - added patch 'ARM: configs: Explicitly enable USB_XHCI_PLATFORM
>   where needed' to keep arm32 defconfigs effectively unchanged
> 
> Changes in v15:
> - adjusted dependencies of USB_DWC3_CORE to make sure it can only
>   be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
>   or USB_DWC3_DUAL_ROLE is selectable
> 
> Changes in v14:
> - rebased on top of v5.14-rc1
> - dropped DT binding patch which landed in v5.13
> 
> Changes in v13:
> - added patch "usb: Specify dependency on USB_XHCI_PLATFORM with
>   'depends on'" to the series to avoid Kconfig conflicts
> - added patch "arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM"
>   to the series to keep effective defconfig unchanged
> 
> Changes in v12:
> - onboard_hub driver: use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE)
>   in onboard_hub.h to also check for the driver built as module
> - onboard_hub_driver: include onboard_hub.h again to make sure there
>   are prototype declarations for the public functions
> 
> Changes in v11:
> - support multiple onboard hubs connected to the same parent
> - don't include ‘onboard_hub.h’ from the onboard hub driver
> 
> Changes in v10:
> - always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m
> - keep 'regulator-boot-on' property for pp3300_hub
> 
> Changes in v9:
> - added dependency on ONBOARD_USB_HUB (or !!ONBOARD_USB_HUB) to
>   USB_PLATFORM_XHCI
> 
> Changes in v7:
> - updated DT binding
> - series rebased on qcom/arm64-for-5.13
> 
> Changes in v6:
> - updated summary
> 
> Changes in v5:
> - cover letter added
> 
> Matthias Kaehlcke (7):
>   usb: misc: Add onboard_usb_hub driver
>   of/platform: Add stubs for of_platform_device_create/destroy()
>   ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed
>   arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
>   usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
>   usb: host: xhci-plat: Create platform device for onboard hubs in
>     probe()
>   arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub
> 
>  .../sysfs-bus-platform-onboard-usb-hub        |   8 +
>  MAINTAINERS                                   |   7 +
>  arch/arm/configs/exynos_defconfig             |   1 +
>  arch/arm/configs/keystone_defconfig           |   1 +
>  arch/arm/configs/multi_v7_defconfig           |   1 +
>  arch/arm/configs/mvebu_v7_defconfig           |   1 +
>  arch/arm/configs/omap2plus_defconfig          |   1 +
>  arch/arm/configs/pxa_defconfig                |   1 +
>  .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts |  19 +-
>  .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts |  12 +-
>  .../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts |  19 +-
>  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |  19 +-
>  arch/arm64/configs/defconfig                  |   1 +
>  drivers/usb/cdns3/Kconfig                     |   2 +-
>  drivers/usb/dwc3/Kconfig                      |   5 +-
>  drivers/usb/host/Kconfig                      |   5 +-
>  drivers/usb/host/xhci-plat.c                  |   6 +
>  drivers/usb/host/xhci.h                       |   2 +
>  drivers/usb/misc/Kconfig                      |  17 +
>  drivers/usb/misc/Makefile                     |   1 +
>  drivers/usb/misc/onboard_usb_hub.c            | 497 ++++++++++++++++++
>  include/linux/of_platform.h                   |  22 +-
>  include/linux/usb/onboard_hub.h               |  18 +
>  23 files changed, 627 insertions(+), 39 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
>  create mode 100644 drivers/usb/misc/onboard_usb_hub.c
>  create mode 100644 include/linux/usb/onboard_hub.h
> 
> -- 
> 2.33.0.rc1.237.g0d66db33f3-goog
> 

Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Doug Anderson]

Hi,

On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> Hi Greg,
>
> are there any actions pending or can this land in usb-testing?
>
> I confirmed that this series can be rebased on top of v5.15-rc2
> without conflicts.

I'm quite interested to know what the next action items are, too. This
is one of the very few patches we have for trogdor (excluding MIPI
camera, which is a long story) that we're carrying downstream, so I'm
keenly interested in making sure it's unblocked (if, indeed, it's
blocked on anything).

If folks feel that this needs more review eyes before landing again
then I'll try to find some time in the next week or two. If it's just
waiting for the merge window to open/close so it can have maximal bake
time, that's cool too. Please yell if there's something that I can do
to help, though! :-)


> On Fri, Aug 13, 2021 at 12:52:21PM -0700, Matthias Kaehlcke wrote:
> > This series adds:
> > - the onboard_usb_hub_driver
> > - glue in the xhci-plat driver to create and destroy the
> >   onboard_usb_hub platform devices if needed
> > - a device tree binding for the Realtek RTS5411 USB hub controller
> > - device tree changes that add RTS5411 entries for the QCA SC7180
> >   based boards trogdor and lazor
> > - a couple of stubs for platform device functions to avoid
> >   unresolved symbols with certain kernel configs
> >
> > 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.
> >
> > Changes in v16:
> > - added patch 'ARM: configs: Explicitly enable USB_XHCI_PLATFORM
> >   where needed' to keep arm32 defconfigs effectively unchanged
> >
> > Changes in v15:
> > - adjusted dependencies of USB_DWC3_CORE to make sure it can only
> >   be enabled when at least one of USB_DWC3_HOST, USB_DWC3_GADGET
> >   or USB_DWC3_DUAL_ROLE is selectable
> >
> > Changes in v14:
> > - rebased on top of v5.14-rc1
> > - dropped DT binding patch which landed in v5.13
> >
> > Changes in v13:
> > - added patch "usb: Specify dependency on USB_XHCI_PLATFORM with
> >   'depends on'" to the series to avoid Kconfig conflicts
> > - added patch "arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM"
> >   to the series to keep effective defconfig unchanged
> >
> > Changes in v12:
> > - onboard_hub driver: use IS_ENABLED(CONFIG_USB_ONBOARD_HUB_MODULE)
> >   in onboard_hub.h to also check for the driver built as module
> > - onboard_hub_driver: include onboard_hub.h again to make sure there
> >   are prototype declarations for the public functions
> >
> > Changes in v11:
> > - support multiple onboard hubs connected to the same parent
> > - don't include ‘onboard_hub.h’ from the onboard hub driver
> >
> > Changes in v10:
> > - always use of_is_onboard_usb_hub() stub unless ONBOARD_USB_HUB=y/m
> > - keep 'regulator-boot-on' property for pp3300_hub
> >
> > Changes in v9:
> > - added dependency on ONBOARD_USB_HUB (or !!ONBOARD_USB_HUB) to
> >   USB_PLATFORM_XHCI
> >
> > Changes in v7:
> > - updated DT binding
> > - series rebased on qcom/arm64-for-5.13
> >
> > Changes in v6:
> > - updated summary
> >
> > Changes in v5:
> > - cover letter added
> >
> > Matthias Kaehlcke (7):
> >   usb: misc: Add onboard_usb_hub driver
> >   of/platform: Add stubs for of_platform_device_create/destroy()
> >   ARM: configs: Explicitly enable USB_XHCI_PLATFORM where needed
> >   arm64: defconfig: Explicitly enable USB_XHCI_PLATFORM
> >   usb: Specify dependencies on USB_XHCI_PLATFORM with 'depends on'
> >   usb: host: xhci-plat: Create platform device for onboard hubs in
> >     probe()
> >   arm64: dts: qcom: sc7180-trogdor: Add nodes for onboard USB hub
> >
> >  .../sysfs-bus-platform-onboard-usb-hub        |   8 +
> >  MAINTAINERS                                   |   7 +
> >  arch/arm/configs/exynos_defconfig             |   1 +
> >  arch/arm/configs/keystone_defconfig           |   1 +
> >  arch/arm/configs/multi_v7_defconfig           |   1 +
> >  arch/arm/configs/mvebu_v7_defconfig           |   1 +
> >  arch/arm/configs/omap2plus_defconfig          |   1 +
> >  arch/arm/configs/pxa_defconfig                |   1 +
> >  .../boot/dts/qcom/sc7180-trogdor-lazor-r0.dts |  19 +-
> >  .../boot/dts/qcom/sc7180-trogdor-lazor-r1.dts |  12 +-
> >  .../arm64/boot/dts/qcom/sc7180-trogdor-r1.dts |  19 +-
> >  arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi  |  19 +-
> >  arch/arm64/configs/defconfig                  |   1 +
> >  drivers/usb/cdns3/Kconfig                     |   2 +-
> >  drivers/usb/dwc3/Kconfig                      |   5 +-
> >  drivers/usb/host/Kconfig                      |   5 +-
> >  drivers/usb/host/xhci-plat.c                  |   6 +
> >  drivers/usb/host/xhci.h                       |   2 +
> >  drivers/usb/misc/Kconfig                      |  17 +
> >  drivers/usb/misc/Makefile                     |   1 +
> >  drivers/usb/misc/onboard_usb_hub.c            | 497 ++++++++++++++++++
> >  include/linux/of_platform.h                   |  22 +-
> >  include/linux/usb/onboard_hub.h               |  18 +
> >  23 files changed, 627 insertions(+), 39 deletions(-)
> >  create mode 100644 Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub
> >  create mode 100644 drivers/usb/misc/onboard_usb_hub.c
> >  create mode 100644 include/linux/usb/onboard_hub.h
> >
> > --
> > 2.33.0.rc1.237.g0d66db33f3-goog
> >

Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Greg Kroah-Hartman]

On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >
> > Hi Greg,
> >
> > are there any actions pending or can this land in usb-testing?
> >
> > I confirmed that this series can be rebased on top of v5.15-rc2
> > without conflicts.
> 
> I'm quite interested to know what the next action items are, too. This
> is one of the very few patches we have for trogdor (excluding MIPI
> camera, which is a long story) that we're carrying downstream, so I'm
> keenly interested in making sure it's unblocked (if, indeed, it's
> blocked on anything).
> 
> If folks feel that this needs more review eyes before landing again
> then I'll try to find some time in the next week or two. If it's just
> waiting for the merge window to open/close so it can have maximal bake
> time, that's cool too. Please yell if there's something that I can do
> to help, though! :-)

I would love more review-eyes on this please.

It's in my queue to review, I just need to spend the time on it, sorry
for the delay.

greg k-h

Re: Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Fabrice Gasnier]

On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
> On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
>> Hi,
>>
>> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>>>
>>> Hi Greg,
>>>
>>> are there any actions pending or can this land in usb-testing?
>>>
>>> I confirmed that this series can be rebased on top of v5.15-rc2
>>> without conflicts.
>>
>> I'm quite interested to know what the next action items are, too. This
>> is one of the very few patches we have for trogdor (excluding MIPI
>> camera, which is a long story) that we're carrying downstream, so I'm
>> keenly interested in making sure it's unblocked (if, indeed, it's
>> blocked on anything).
>>
>> If folks feel that this needs more review eyes before landing again
>> then I'll try to find some time in the next week or two. If it's just
>> waiting for the merge window to open/close so it can have maximal bake
>> time, that's cool too. Please yell if there's something that I can do
>> to help, though! :-)
> 
> I would love more review-eyes on this please.
> 

Hi,

I noticed this series some time ago, and wanted to take a closer look.

The same issue this series address is seen on stm32 board for instance.
(arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
the DT) is supplied by an always-on regulator.
So it could could be interesting/useful to address the same case ,
on stm32 boards, where USB2 (ehci-platform driver) is used currently.

I noticed a few things, especially on the dt-bindings. I've some
questions here.

In this series, RTS5411 is used. The dt-bindings documents it as a child
node of the USB controller. E.g.

&usb {
	usb_hub_2_0: hub@1 {
		...
	};

	usb_hub_3_0: hub@2 {
	};
}

I had a quick look at RTS5411 datasheet. It looks like there's an i2c
interface too.
- I guess the I2C interface isn't used in your case ?
  (I haven't checked what it could be used for...)

In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
- that also could be wired on I2C interface (0R mount option)
- unused on stm32 boards by default

usb2514b chip already has a dt-bindings (with compatible), and a driver:
- drivers/usb/misc/usb251xb.c
- Documentation/devicetree/bindings/usb/usb251xb.txt

It is defined more as an i2c chip, so I'd expect it as an i2c child,
e.g. like:

&i2c {
	usb2514b@2c {
		compatible = "microchip,usb2514b";
		...
	};
};


This way, I don't see how it could be used together with onboard_usb_hub
driver ? (But I may have missed it)
Is it possible to use a phandle, instead of a child node ?

However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
default. So obviously the i2c driver isn't used. In this case, could the
"microchip,usb2514b" be listed in onboard_usb_hub driver ?
(wouldn't it be redundant ?)

In this case it would be a child node of the usb DT node... Maybe that's
more a question for Rob: would it be "legal" regarding existing
dt-bindings ?


Thanks in advance
Best Regards,
Fabrice


> It's in my queue to review, I just need to spend the time on it, sorry
> for the delay.
> 
> greg k-h
> 

Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Tue, Oct 19, 2021 at 06:04:06PM +0200, Fabrice Gasnier wrote:
> On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
> > On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> >>>
> >>> Hi Greg,
> >>>
> >>> are there any actions pending or can this land in usb-testing?
> >>>
> >>> I confirmed that this series can be rebased on top of v5.15-rc2
> >>> without conflicts.
> >>
> >> I'm quite interested to know what the next action items are, too. This
> >> is one of the very few patches we have for trogdor (excluding MIPI
> >> camera, which is a long story) that we're carrying downstream, so I'm
> >> keenly interested in making sure it's unblocked (if, indeed, it's
> >> blocked on anything).
> >>
> >> If folks feel that this needs more review eyes before landing again
> >> then I'll try to find some time in the next week or two. If it's just
> >> waiting for the merge window to open/close so it can have maximal bake
> >> time, that's cool too. Please yell if there's something that I can do
> >> to help, though! :-)
> > 
> > I would love more review-eyes on this please.
> > 
> 
> Hi,
> 
> I noticed this series some time ago, and wanted to take a closer look.
> 
> The same issue this series address is seen on stm32 board for instance.
> (arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
> the DT) is supplied by an always-on regulator.
> So it could could be interesting/useful to address the same case ,
> on stm32 boards, where USB2 (ehci-platform driver) is used currently.
> 
> I noticed a few things, especially on the dt-bindings. I've some
> questions here.
> 
> In this series, RTS5411 is used. The dt-bindings documents it as a child
> node of the USB controller. E.g.
> 
> &usb {
> 	usb_hub_2_0: hub@1 {
> 		...
> 	};
> 
> 	usb_hub_3_0: hub@2 {
> 	};
> }
> 
> I had a quick look at RTS5411 datasheet. It looks like there's an i2c
> interface too.
> - I guess the I2C interface isn't used in your case ?
>   (I haven't checked what it could be used for...)

Correct, the i2c interface isn't used on my board.

Also the binding isn't completely new, it is based on the generic USB
binding (https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/usb-device.txt)

> In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
> - that also could be wired on I2C interface (0R mount option)
> - unused on stm32 boards by default
> 
> usb2514b chip already has a dt-bindings (with compatible), and a driver:
> - drivers/usb/misc/usb251xb.c
> - Documentation/devicetree/bindings/usb/usb251xb.txt
> 
> It is defined more as an i2c chip, so I'd expect it as an i2c child,
> e.g. like:
> 
> &i2c {
> 	usb2514b@2c {
> 		compatible = "microchip,usb2514b";
> 		...
> 	};
> };
> 
> 
> This way, I don't see how it could be used together with onboard_usb_hub
> driver ? (But I may have missed it)

Indeed, you can either use the i2c driver for the hub or the onboard_usb_hub
driver, but not both at the same time. The i2c driver requires the hub to be
powered before communicating with it over i2c, hence the power sequence
should not be delegated to the onboard_usb_hub driver.

> Is it possible to use a phandle, instead of a child node ?

The child node is part of the generic USB binding. The onboard_usb_hub
driver needs it to find the USB device(s) that correspond to the hub,
to optionally power the hub off during system suspend when no wakeup
capable devices are connected.

> However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
> default. So obviously the i2c driver isn't used. In this case, could the
> "microchip,usb2514b" be listed in onboard_usb_hub driver ?
> (wouldn't it be redundant ?)

You would use the compatible string of the generic USB binding, i.e.
"usbVID,PID", which would have to be added to the onboard_usb_hub driver.

> In this case it would be a child node of the usb DT node... Maybe that's
> more a question for Rob: would it be "legal" regarding existing
> dt-bindings ?

The USB node is always there implicitly (the USB device exists), the only
difference is that the node is added explicitly (plus additional
properties).

There was a somewhat related long-winded discussion with Rob on an earlier
version of the driver/binding:
https://lore.kernel.org/linux-usb/1613055380.685661.519681.nullmailer@robh.at.kernel.org/

Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Michal Simek]

On 10/19/21 18:04, Fabrice Gasnier wrote:
> On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
>> On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>>>>
>>>> Hi Greg,
>>>>
>>>> are there any actions pending or can this land in usb-testing?
>>>>
>>>> I confirmed that this series can be rebased on top of v5.15-rc2
>>>> without conflicts.
>>>
>>> I'm quite interested to know what the next action items are, too. This
>>> is one of the very few patches we have for trogdor (excluding MIPI
>>> camera, which is a long story) that we're carrying downstream, so I'm
>>> keenly interested in making sure it's unblocked (if, indeed, it's
>>> blocked on anything).
>>>
>>> If folks feel that this needs more review eyes before landing again
>>> then I'll try to find some time in the next week or two. If it's just
>>> waiting for the merge window to open/close so it can have maximal bake
>>> time, that's cool too. Please yell if there's something that I can do
>>> to help, though! :-)
>>
>> I would love more review-eyes on this please.
>>
> 
> Hi,
> 
> I noticed this series some time ago, and wanted to take a closer look.
> 
> The same issue this series address is seen on stm32 board for instance.
> (arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
> the DT) is supplied by an always-on regulator.
> So it could could be interesting/useful to address the same case ,
> on stm32 boards, where USB2 (ehci-platform driver) is used currently.
> 
> I noticed a few things, especially on the dt-bindings. I've some
> questions here.
> 
> In this series, RTS5411 is used. The dt-bindings documents it as a child
> node of the USB controller. E.g.
> 
> &usb {
> 	usb_hub_2_0: hub@1 {
> 		...
> 	};
> 
> 	usb_hub_3_0: hub@2 {
> 	};
> }
> 
> I had a quick look at RTS5411 datasheet. It looks like there's an i2c
> interface too.
> - I guess the I2C interface isn't used in your case ?
>    (I haven't checked what it could be used for...)
> 
> In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
> - that also could be wired on I2C interface (0R mount option)
> - unused on stm32 boards by default
> 
> usb2514b chip already has a dt-bindings (with compatible), and a driver:
> - drivers/usb/misc/usb251xb.c
> - Documentation/devicetree/bindings/usb/usb251xb.txt
> 
> It is defined more as an i2c chip, so I'd expect it as an i2c child,
> e.g. like:
> 
> &i2c {
> 	usb2514b@2c {
> 		compatible = "microchip,usb2514b";
> 		...
> 	};
> };
> 
> 
> This way, I don't see how it could be used together with onboard_usb_hub
> driver ? (But I may have missed it)
> Is it possible to use a phandle, instead of a child node ?
> 
> However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
> default. So obviously the i2c driver isn't used. In this case, could the
> "microchip,usb2514b" be listed in onboard_usb_hub driver ?
> (wouldn't it be redundant ?)
> 
> In this case it would be a child node of the usb DT node... Maybe that's
> more a question for Rob: would it be "legal" regarding existing
> dt-bindings ?

We wanted to upstream driver for microchip usb5744 and based on this 
thread with Rob

https://lore.kernel.org/all/CAL_JsqJZBbu+UXqUNdZwg-uv0PAsNg55026PTwhKr5wQtxCjVQ@mail.gmail.com/

the recommendation was to use i2c-bus link. And in our usb5744 case 
where usb hub has only one i2c address we just hardcoded it in the 
driver. I should be pushing this driver to xilinx soc tree soon if you 
want to take a look.

Thanks,
Michal

Re: [PATCH v16 0/7] usb: misc: Add onboard_usb_hub driver

[Matthias Kaehlcke]

On Wed, Oct 20, 2021 at 08:21:21AM +0200, Michal Simek wrote:
> 
> 
> On 10/19/21 18:04, Fabrice Gasnier wrote:
> > On 10/15/21 8:39 AM, Greg Kroah-Hartman wrote:
> > > On Thu, Oct 14, 2021 at 02:38:55PM -0700, Doug Anderson wrote:
> > > > Hi,
> > > > 
> > > > On Tue, Sep 21, 2021 at 10:09 AM Matthias Kaehlcke <mka@chromium.org> wrote:
> > > > > 
> > > > > Hi Greg,
> > > > > 
> > > > > are there any actions pending or can this land in usb-testing?
> > > > > 
> > > > > I confirmed that this series can be rebased on top of v5.15-rc2
> > > > > without conflicts.
> > > > 
> > > > I'm quite interested to know what the next action items are, too. This
> > > > is one of the very few patches we have for trogdor (excluding MIPI
> > > > camera, which is a long story) that we're carrying downstream, so I'm
> > > > keenly interested in making sure it's unblocked (if, indeed, it's
> > > > blocked on anything).
> > > > 
> > > > If folks feel that this needs more review eyes before landing again
> > > > then I'll try to find some time in the next week or two. If it's just
> > > > waiting for the merge window to open/close so it can have maximal bake
> > > > time, that's cool too. Please yell if there's something that I can do
> > > > to help, though! :-)
> > > 
> > > I would love more review-eyes on this please.
> > > 
> > 
> > Hi,
> > 
> > I noticed this series some time ago, and wanted to take a closer look.
> > 
> > The same issue this series address is seen on stm32 board for instance.
> > (arch/arm/boot/dts/stm32mp15xx-dkx.dtsi). On board HUB (not described in
> > the DT) is supplied by an always-on regulator.
> > So it could could be interesting/useful to address the same case ,
> > on stm32 boards, where USB2 (ehci-platform driver) is used currently.
> > 
> > I noticed a few things, especially on the dt-bindings. I've some
> > questions here.
> > 
> > In this series, RTS5411 is used. The dt-bindings documents it as a child
> > node of the USB controller. E.g.
> > 
> > &usb {
> > 	usb_hub_2_0: hub@1 {
> > 		...
> > 	};
> > 
> > 	usb_hub_3_0: hub@2 {
> > 	};
> > }
> > 
> > I had a quick look at RTS5411 datasheet. It looks like there's an i2c
> > interface too.
> > - I guess the I2C interface isn't used in your case ?
> >    (I haven't checked what it could be used for...)
> > 
> > In the stm32 boards (stm32mp15xx-dkx), there's an usb2514b chip
> > - that also could be wired on I2C interface (0R mount option)
> > - unused on stm32 boards by default
> > 
> > usb2514b chip already has a dt-bindings (with compatible), and a driver:
> > - drivers/usb/misc/usb251xb.c
> > - Documentation/devicetree/bindings/usb/usb251xb.txt
> > 
> > It is defined more as an i2c chip, so I'd expect it as an i2c child,
> > e.g. like:
> > 
> > &i2c {
> > 	usb2514b@2c {
> > 		compatible = "microchip,usb2514b";
> > 		...
> > 	};
> > };
> > 
> > 
> > This way, I don't see how it could be used together with onboard_usb_hub
> > driver ? (But I may have missed it)
> > Is it possible to use a phandle, instead of a child node ?
> > 
> > However, in the stm32mp15xx-dkx case, i2c interface isn't wired/used by
> > default. So obviously the i2c driver isn't used. In this case, could the
> > "microchip,usb2514b" be listed in onboard_usb_hub driver ?
> > (wouldn't it be redundant ?)
> > 
> > In this case it would be a child node of the usb DT node... Maybe that's
> > more a question for Rob: would it be "legal" regarding existing
> > dt-bindings ?
> 
> We wanted to upstream driver for microchip usb5744 and based on this thread
> with Rob
> 
> https://lore.kernel.org/all/CAL_JsqJZBbu+UXqUNdZwg-uv0PAsNg55026PTwhKr5wQtxCjVQ@mail.gmail.com/
> 
> the recommendation was to use i2c-bus link. And in our usb5744 case where
> usb hub has only one i2c address we just hardcoded it in the driver. I
> should be pushing this driver to xilinx soc tree soon if you want to take a
> look.

Interesting, with the 'i2c-bus' link it might be feasible to support the
i2c functionality in the onboard_usb_hub driver if desired. Not sure how
things would look when the hub can have different i2c addresses. Also in
case of powering down the hub during system suspend any configuration
through i2c would have to be done again on resume.