[PATCH 01/14] mfd: omap-usb-host: Consolidate OMAP USB-HS platform data

[Tony Lindgren]

* Roger Quadros <rogerq at ti.com> [130114 03:31]:
> On 01/11/2013 08:13 PM, Tony Lindgren wrote:
> > * Roger Quadros <rogerq at ti.com> [130111 01:43]:
> >> Tony,
> >>
> >> On 01/11/2013 01:45 AM, Tony Lindgren wrote:
> >>> * Roger Quadros <rogerq at ti.com> [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