On 09/02/2011 07:00 PM, Alan Stern wrote:
To make this work, we have to find a way to handle all the individual
differences in the various hc_driver structures. Most of the
differences lie in the product_desc and reset fields.
Yes, and I proposed to handle reset as an argument to usb_add_hcd()
Is that really the best way?
I think so.
I have the feeling that in many or most
cases, the reset routine could easily be invoked directly from the
probe routine before it calls usb_add_hcd(). One of the most difficult
cases would be the PCI host drivers, oddly enough, because they all
share a common probe routine. But even that could be handled.
The setup routine requires the ehci_hcd struct in case
of ehci. It sets some parameters here and there like the reg & caps
offset members or hcs_params and of course the quirks. I don't think
you can move them out because some of them call generic routines like
ehci_reset() or init and those may require some quirks to be set.
We could rewrite those functions to do the same thing without the ehci
struct but this will most likely duplicate code we still don't have the
fields (quirks) set in the ehci struct and some platforms requires them
to be set upfront like a few ppc where you have to use a different
read/write routine.
We might get away with it if each platform driver allocates the
ehci_hcd + usb_hcd those structs in usb_create_hcd(). However I'm not
sure how smart it is to poke around in registers without the initialized
root hub, or flags HCD_FLAG_RH_RUNNING +
HCD_FLAG_HW_ACCESSIBLE set.
I'm open for alternatives :)
Alan Stern
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
