On Mon, Sep 03, 2012 at 03:19:13PM +0200, Linus Walleij wrote: > On Mon, Sep 3, 2012 at 2:34 PM, Lee Jones <lee.jones@xxxxxxxxxx> wrote: > > > When booting DT booting take a different path and no platform data > > is passed. We can't boot DT AND register devices with platform data > > or else we will double probe every device. The only way to pass > > pdata when booting with DT is with AUX_DATA() and that's a hack to > > get around things we don't have support for yet. Up until now that > > has been DMA bindings, clock and pinctrl names and call-backs. > > So if we pass some augmented platform data using AUX_DATA() > that appears as pdata in this case, and gets discarded. > > Thus we cannot use AUX_DATA() to override a broken, as in > "the interrupt number is wrong" device tree. No, you cannot to that. You'd have to fix it in DT (which is easier). > > If DT is corrupt or missing the kernel will boot using platform > > data, but np will always be NULL, so we don't have the problem you > > were alluding to above. > > That was not the problem I had in mind. > > I had a valid, but incorrect device tree in mind. I.e the device > is there, but with wrong base address, or wrong IRQ number. > > If pdata takes precedence, we can use AUX_DATA() to > override such errors from the platform, since drivers/of/platform.c > helpfully pokes in the auxdata as the platform data. Yes, that's what happens. > I thought this was one of the reasons why auxdata exist > at all. I don't think so. I've been told that AUXDATA is just a hack. My aim is to rid the boardfile of all AUXDATA entries. > Or is the proper solution to runtime-patch the device tree > per se in such cases? How is that actually done then? No, you can't do that either. DT is only read once at boot-time. The correct solution would be to fix the broken DT. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
