* Roger Quadros <rogerq@xxxxxx> [130114 03:31]: > On 01/11/2013 08:13 PM, Tony Lindgren wrote: > > * Roger Quadros <rogerq@xxxxxx> [130111 01:43]: > >> Tony, > >> > >> On 01/11/2013 01:45 AM, Tony Lindgren wrote: > >>> * Roger Quadros <rogerq@xxxxxx> [130110 08:54]: > >>>> Let's have a single platform data structure for the OMAP's High-Speed > >>>> USB host subsystem instead of having 3 separate ones i.e. one for > >>>> board data, one for USB Host (UHH) module and one for USB-TLL module. > >>>> > >>>> This makes the code much simpler and avoids creating multiple copies of > >>>> platform data. > >>> > >>> I can apply just this patch alone into an immutable branch that > >>> we all can merge in as needed as long as we have acks for the USB > >>> and MFD parts. > >>> > >>> Or does this one need to be changed based on Alan's comments > >>> on the EHCI lib related changes? > >>> > >> > >> This does not depend on EHCI lib based changes but it depends on the > >> OMAP USB Host cleanup series posted earlier. > > > > Can we first apply just the minimal platform_data + board file + clock > > changes? > > > We could, but I'll then have to make changes to the patches in the first > series and re-post them. Do you want me to do that? Yes please. Otherwise we'll unnecessarily complicate the dependencies between arch/arm/*omap* code and the drivers. And we've certainly had enough of self-inflicted merge conflicts with the omap usb code already :) > > That way I can apply those to some immutable tree for everybody to use, > > and we cut off the dependency to the driver changes for the rest of the > > patches. And then I'm off the hook for the rest of the patches :) > > > > Or you could just ack this patch ;). The platform data is specific to > USB host only :) Well it's not just this patch. It's the clock related patches in your earlier seriers that will conflict with any attempts to move the clock data to live under drivers/clk/omap where it needs to go. And the three patches at the end of this series to add platform data (which look fine), but will likely conflict with something else. Let's try do do these changes in a way where the dependencies are cut to minimum where possible. Regards, Tony -- 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
