On Tue, 4 Oct 2011, Felipe Balbi wrote: > > All this is lots more than I had in mind. Really, I was asking why one > > HC driver needs to have a clock pointer, another needs to have some PHY > > data, and the rest don't need to have anything. Shouldn't this be more > > uniform? For example, shouldn't the PHY stuff be handled in a separate > > layer? > > maybe, but is it time to discuss that now ? Sure, why not? We have to get started some time... 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. > > 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. 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