Re: [PATCH v3 2/2] wl18xx: add basic device-tree support

[Arnd Bergmann <arnd@arndb.de>]

On Monday 09 March 2015 09:18:46 Eliad Peller wrote:
> On Sun, Mar 8, 2015 at 11:53 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday 08 March 2015 13:13:13 Eliad Peller wrote:
> >>
> >> > I've looked up the what boards actually use this data and found that
> >> > all of them already support booting from DT: some omap2 boards using
> >> > arch/arm/mach-omap2/pdata-quirks.c to provide the data, and the
> >> > davinci 850evm. Can you make sure you add the correct data to all
> >> > of these dts files as part of your series and remove the
> >> > wl12xx_platform_data references?
> >>
> >> AFAICT, these board files add wl12xx platform data, while the new DT
> >> support is only for wl18xx.
> >>
> >
> > How can you tell the difference? What I see is that omap3pandora
> > (and nothing else) calls wl1251_set_platform_data(), while
> > da850-evm and all omap3/omap4 boards use wl12xx_set_platform_data().
> >
> > The latter seems to refer to all wl12xx and wl18xx variants except
> > for wl1251, based on my (very limited) understanding of that code.
> 
> right.
> i got mislead because legacy_init_wl12xx() is defined there only for
> CONFIG_WL12XX (and not for CONFIG_WL18XX).
> it looks like only "isee,omap3-igep0020-rev-f" and
> "isee,omap3-igep0020-rev-g" have pdata quirks for wl18xx (and thus
> initialize the pdata clocks to 0).

Ok.

> sorry for the trivial question, but what's the standard way to submit
> such patch? should i simply add a third patch to the patchset which
> removes the pdata quirk and adds the missing dts definition? i don't
> have such board, so i can only compile-test it.

Yes, I think that would be good. Depending on the complexity of the
patch, you can do it in multiple ways:

a) one patch to all the dts files, which also removes the
   legacy_init_wl12xx() infrastructure

b) one patch to add the .dts changes, a second patch to remove the
   code from pdata-quirks.c and a third to remove the functionality
   in the driver

c) one patch per board.

I'm fine with any of these, but the omap maintainers might have a
preference.

	Arnd