David S. Ahern wrote: >>> As an alternative, what about enhancing the -usb option to note the >>> maximum version to enable: e.g., -usb v2[,v3]? -usb alone defaults to >>> uhci/ohci for compatibility with current design. Then ehci can be >>> enabled by the user. Enabling v2 means v1 is also enabled. Similarly >>> when v3 comes along -usb v3 means uhci/ohci, ehci and xhci are all enabled. >> I think we either go for your current proposal as an intermediate >> solution and fix the routing later on, or we find a way to do it >> correctly on first run. > > Moving devices from ehci to uhci and vice versa can be implemented later > if there is agreement that a simplified ehci model (ie, no companion > controllers) is acceptable.
Now I see clearer. Zero-companion EHCIs are allowed by the spec, so I see no reason to not support this option as well - and specifically make it the first step towards full EHCI emulation. Adding companion support with port routing to EHCI is indeed an exercise that can be done later on. Regarding how to configure things: We only need a way to explicitly specify the controller bus (or some to-be-implemented hub bus) that an USB device shall be attached to. And that could become a qdev property. We can still apply some smart selection logic to the legacy interfaces as you suggested. But for anything special, there will be -device / device_add with full control over the setup. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
