On Tue, 4 Oct 2011, Felipe Balbi wrote: > > This is all part of the same project. We want to merge as much of the > > separate code as possible for all the different EHCI drivers. That > > means we have to make them all as similar as possible. Which means we > > have to look into why there are few odd things sticking out, like clock > > pointers or PHY resources. Especially when it's questionable whether > > these things should be handled in the EHCI layer in the first place. > > another argument to split EHCI to its own platform_driver: by doing so, > the platform-specific details, such as clock, PHYs, PM, etc will be > phased out to a parent driver If you want to split some of the existing EHCI platform drivers in two, that's okay with me (although it seems inefficient). In most of the cases, though, it doesn't appear to be needed. > and (at least for PM) would all be handled > automagically by pm_runtime ;-) It already is. > > > > What extra data is it reasonable to expect a driver to want? Whatever > > > > that is, we can add it directly into the usb_hcd structure. > > > > > > I don't think we can come up with a truly generic solution for all hcs. > > > For all EHCIs, maybe, but not for all HCs. > > > > That's okay, then let's start with EHCI controllers. When that's > > finished we can move on to do the same with OHCI. > > sounds good then. But you still haven't answered my question. What extra fields should be added to the ehci_hcd structure to accomodate all the various platform drivers? The real problem here is that the programming model we're evolving is not a good match to the original model for the HCD layer. The original idea was that each HC driver has its own hc_driver structure, which specifies what that driver needs. Now we're trying to change things so that a bunch of different EHCI drivers all share a large amount of common data, including the hc_driver structure, but still have differing detailed requirements. I'm beginning to think the best answer might be to have each EHCI platform driver make a copy of the generic ehci_hc_driver structure and then overwrite some of the fields (such as hcd_priv_size) with its own specific values. 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
