| Message ID | 20210813195228.2003500-1-mka@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | usb: misc: Add onboard_usb_hub driver | expand |
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 >
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 > >
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
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 >
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/
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
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.
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