Hi, On Tue, Oct 04, 2011 at 03:28:43PM -0400, Alan Stern 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. 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 and (at least for PM) would all be handled automagically by pm_runtime ;-) > > > 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
