Hi Alexander,

On Wed, May 12, 2021 at 09:19:54AM +0200, Alexander Dahl wrote:

Hello Matthias,

just a curious informal question, see below.

Am Tue, May 11, 2021 at 03:52:18PM -0700 schrieb Matthias Kaehlcke:

quoted

This series adds:
- the onboard_usb_hub_driver
- glue in the xhci-plat driver to create the onboard_usb_hub
  platform device 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.

This sounds like it would be useful for other hub controllers as well?
For example, would the Microchip USB3503 (former SMSC,
drivers/usb/misc/usb3503.c, [1]) fall into this category? That chip is
used on the "Cubietech Cubietruck Plus" for example.

usb3503.c provides two 'separate' USB3503 drivers (which share some
code), a i2c client driver and a platform driver. IIUC on a system with
an USB3503 only one of these drivers is used. Theoretically it should be
feasible to extend the onboard_usb_hub driver to cover the functionality
of the platform driver in usb3503.c (essentially to control GPIOs and
clocks at initialization time and suspend/resume). Another question is
whether that would be desirable, since the i2c and the platform driver
share code, which then would be duplicated in the i2c and onboard_usb_hub
driver, unless a way is found to keep sharing that code.

The i2c driver can't be completely replaced by the onboard_usb_hub
driver, due to the i2c communications. It might be possible to have the
i2c driver and the onboard_usb_hub collaborate, however I expect it
would take a certain effort to design and implement a solid solution.

Thanks

Matthias