On Mon, Sep 03, 2012 at 10:09:34AM -0500, Rob Herring wrote:

On 09/03/2012 09:35 AM, Linus Walleij wrote:

quoted

On Mon, Sep 3, 2012 at 4:33 PM, Stephen Warren [off-list ref] wrote:

quoted

On 09/03/2012 05:58 AM, Linus Walleij wrote:

quoted

On Mon, Sep 3, 2012 at 1:32 PM, Lee Jones [off-list ref] wrote:

quoted

No, this is wrong. Platform data should not override DT.

If DT is enabled and passed, it should have highest priority.

No, that's wrong. If platform data is specified, it overrides DT, so
that if the DT needs any fixup, it can be provided using platform data.

Thanks Stephen, now there are two of us saying this, Lee please
follow this design pattern.

(Unless Rob/Grant start shouting counter-orders...)

Ideally, you only use DT or platform_data and you override DT with a new
DTB. Hopefully we can ultimately remove platform_data or all but parts
that can't be described in DT (i.e. function callouts).

Exactly. I don't believe that AUX_DATA() should be used as a facility to
override DT settings from platform_data.

But if you are handling both, then I agree that platform_data should
override DT.

I do agree with this, but I haven't stumbled over such a use-case yet.
I have only provided; clock names, DMA settings and call-back information
via AUX_DATA() thus far, and those are being removed too when a) the 
correct bindings are mainlined and b) I have the time.

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog