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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Jan 2013 09:18:14 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Roger Quadros <rogerq@...com>
Cc:	balbi@...com, gregkh@...uxfoundation.org, sameo@...ux.intel.com,
	kishon@...com, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 01/14] mfd: omap-usb-host: Consolidate OMAP USB-HS
 platform data

* Roger Quadros <rogerq@...com> [130114 03:31]:
> On 01/11/2013 08:13 PM, Tony Lindgren wrote:
> > * Roger Quadros <rogerq@...com> [130111 01:43]:
> >> Tony,
> >>
> >> On 01/11/2013 01:45 AM, Tony Lindgren wrote:
> >>> * Roger Quadros <rogerq@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/