Re: [PATCH] ARM: shmobile: lager: Remove legacy C board code

[Simon Horman <horms@verge.net.au>]

On Wed, Sep 10, 2014 at 09:50:31AM +0900, Magnus Damm wrote:
> Hi Simon,
> 
> On Wed, Sep 10, 2014 at 9:30 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Fri, Sep 05, 2014 at 12:35:49PM +0900, Magnus Damm wrote:
> >> Hi Simon,
> >>
> >> On Thu, Sep 4, 2014 at 9:14 PM, Simon Horman <horms@verge.net.au> wrote:
> >> > On Thu, Sep 04, 2014 at 08:38:02PM +0900, Magnus Damm wrote:
> >> >> Hi Sergei,
> >> >>
> >> >> On Thu, Sep 4, 2014 at 8:06 PM, Sergei Shtylyov
> >> >> <sergei.shtylyov@cogentembedded.com> wrote:
> >> >> > Hello.
> >> >> >
> >> >> > On 9/4/2014 6:34 AM, Magnus Damm wrote:
> >> >> >
> >> >> >> From: Magnus Damm <damm+renesas@opensource.se>
> >> >> >
> >> >> >
> >> >> >> The Multiplatform r8a7790 Lager board code is at this point
> >> >> >> in equally or better state compared to the legacy code.
> >> >> >
> >> >> >
> >> >> >    I think it's a bit premature to say this. For example, USBHS DT support
> >> >> > hasn't been merged (the .dts[i] part hasn't even been posted yet IIRC).
> >> >> > The USB PHY DT support also hasn't been merged.
> >> >>
> >> >> Thanks for letting us know. It may be a bit early then.
> >> >
> >> > At this point my feeling is that its better to wait if there are still
> >> > features in Legacy-C that haven't made it across to multiplatform yet.
> >>
> >> I agree, waiting must be the best option. Thanks!
> >
> > A general comment about removing board code:
> >
> > As suggested by Arnd elsewhere, please also submit a patch to remove
> > #ifdef CONFIG_USE_OF from the relevant setup-*.c file when you remove
> > the legacy board code if the setup-*.c will thus always be compiled with
> > ARCH_MULTIPLATFORM which selects CONFIG_USE_OF.
> 
> Sure, of course. The main concern from my side was to introduce as few
> difficulties as ever possible merge-wise. I may have misunderstood
> things, but I thought having SoC cleanups that depend on Board
> cleanups in the same merge window may complicate the ARM SoC merge?
> Because of this a SoC cleanup like suggested above cannot easily
> depend on a board cleanup like the legacy board code removal patch. So
> my plan was to first remove the legacy board code in one merge window,
> and in the second one cleanup the SoC bits.
> 
> Please correct me if I'm wrong.

Thanks, that sounds ideal to me.

The main purpose of my previous email was to make a public note about
something Arnd had brought to my attention.  I agree entirely that we
should take care to oder cleanups as you describe.