On Mon, 5 Sep 2011, Sebastian Andrzej Siewior wrote: > >> 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. Are you saying that these reset routines need to do some extra work after calling ehci_reset()? I bet much of that work could be done before ehci_reset(). However, for the stuff that can't, we can fall back on your idea of an extra parameter. > 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(). They already do. > 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. Those things don't matter. The root hub isn't running anyway at the time the reset callback occurs. Alan Stern -- 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
