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