Hi, On 24-12-31, Junzhong Pan wrote: > Hi Marco, > > On Mon, 28 Oct 2024 22:49:56 +0100 Marco Felsch wrote: > > I found two mistakes I made in my v1. I would send a v2 if this series > > is interesting for upstream. The remaining open question is how the > > driver dependencies should be handled (see idea-1,2,3). > > How's everything going? I wish you all good! I'm fine, thanks for asking. > It's a very useful series for various hubs, gentle ping on it. Nice to hear that others find this series useful too :) I prepared a v2 but wanted to get some feedback from the maintainers first mainly regarding the dependency handling. > On Mon, 28 Oct 2024 22:49:56 +0100 Marco Felsch wrote: > > > > Idea-3: > > > > ------- > > > > > > > > Adding a function to the hub.c usbcore which can be used by the > > > > usb-onboard-dev driver to register this function as hook. This removes> > > the dependency from the core and the usb-onboard-dev module is only > > > > pulled if really required. Of course this require that the hub.c usbcore> > > driver allows custom hooks. > > > > > > This seems like the best approach IMO, if USB maintainers are onboard with> > it. > Use the existing onboard_hub.h header to do the hooks looks fine. > > I recently encountered some kind of platforms using an existing onboard > hub yet their HW don't utilize the USBPE port power control feature > while the hub support it. > Instead, we have another GPIO for controlling the vbus of those ports > to cut the cost. That's exactly our use-case too. > Wonder any idea could use this driver considering the limitation of > the usb compatible set the properties of onboard_dev_pdata hard coded? Sorry but I don't get this. Regards, Marco
