On 15.01.24 19:11, Krzysztof Kozlowski wrote: > On 15/01/2024 17:24, Javier Carrasco wrote: >> Do you mean that the XVF3500 should not be represented as a platform >> device and instead it should turn into an USB device represented as a >> node of an USB controller? Something like this (Rockchip SoC): >> >> &usb_host1_xhci { >> ... >> >> xvf3500 { >> ... >> }; >> }; >> >> Did I get you right or is that not the correct representation? Thank you >> again. > > I believe it should be just like onboard hub. I don't understand why > onboard hub was limited to hub, because other USB devices also could be > designed similarly by hardware folks :/ > > And if we talk about Linux drivers, then your current solution does not > support suspend/resume and device unbind. > > Best regards, > Krzysztof > Actually this series is an attempt to get rid of a misuse of the onboard_usb_hub driver by a device that is not a HUB, but requires the platform-part of that driver for the initialization. What would be the best approach to provide support upstream? Should I turn this driver into a generic USB driver that does what the platform-part of the onboard HUB does? Or are we willing to accept non-HUB devices in the onboard_usb_hub driver even though it supports more operations? I am adding linux-usb to this thread in case someone has other suggestions. Thanks and best regards, Javier Carrasco