Hi, > On Wed, Sep 30, 2020 at 7:44 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > We already have hubs in DT. See [1][2][3][4]. What's new here? After I sent my response I kept thinking about this and I realized that I have prior art I can point out too! :-) Check out "smsc,usb3503a". That is describing a USB hub too and, at least on "exynos5250-spring.dts" is is a top level node. Since "smsc,usb3503a" can be optionally connected to an i2c bus too, it could be listed under an i2c controller as well (I believe it wasn't hooked up to i2c on spring). Interestingly enough, the USB Hub that Matthias is trying to add support for can _also_ be hooked up to i2c. We don't actually have i2c hooked up on our board, but conceivably it could be. Presumably, if i2c was hooked up, we would have no other choice but to represent this chip as several device tree nodes: at least one under the i2c controller and one (or two) under the USB controller. Just because (on this board) i2c isn't hooked up doesn't change the fact that there is some extra control logic that could be represented in its own device tree node. To me, this seems to give extra evidence that the correct way to model this device in device tree is with several nodes. I'll point out that on "exynos5250-spring.dts" we didn't have to solve the problem that Matthias is trying to solve here because we never actually supported waking up from USB devices there. Thus the regulator for the hub on spring can be unconditionally powered off in suspend. On newer boards we'd like to support waking up from USB devices but also to save power if no wakeup devices are plugged into USB. In order to achieve this we need some type of link from the top-level hub device to the actual USB devices that were enumerated. -Doug
