On Fri, Mar 11, 2016 at 10:54:15AM +0900, Simon Horman wrote: > On Mon, Mar 07, 2016 at 01:47:36PM +0100, Geert Uytterhoeven wrote: > > Hi Simon, > > > > On Thu, Mar 3, 2016 at 1:56 AM, Simon Horman <[email protected]> wrote: > > > On Thu, Mar 03, 2016 at 09:07:13AM +0900, Simon Horman wrote: > > >> On Wed, Mar 02, 2016 at 09:25:54AM +0100, Geert Uytterhoeven wrote: > > >> > On Wed, Mar 2, 2016 at 2:43 AM, Simon Horman > > >> > <[email protected]> wrote: > > >> > > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > >> > > > > >> > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > > >> > > ARCH_RENESAS the motivation for which being that RENESAS seems to be > > >> > > a more > > >> > > appropriate name than SHMOBILE for the majority of Renesas ARM based > > >> > > SoCs. > > >> > > > > >> > > ARCH_RENESAS should cover all cases where both CONFIG_OF and > > >> > > ARCH_SHMOBILE are enabled. > > >> > > > > >> > > Signed-off-by: Simon Horman <[email protected]> > > >> > > > >> > Acked-by: Geert Uytterhoeven <[email protected]> > > >> > > > >> > If you intend to drop ARCH_SHMOBILE from > > >> > arch/arm/mach-shmobile/Kconfig before > > >> > dropping the whole "if (...) { ... }" block below" (cfr. "drivers: sh: > > >> > Stop > > >> > using the legacy clock domain on ARM", > > >> > http://www.spinics.net/lists/linux-renesas-soc/msg00869.html). > > >> > > >> At this point that is my intention. > > > > > > I have queued this patch up for v4.6. > > > > BTW, you also have to update drivers/Makefile. > > Ok, that is a bit of a tricky one as we would need (ARCH_SHMOBILE || > ARCH_RENESAS) and I'm not sure how to express that other than by > introducing a cover-all Kconfig symbol, which is more or less the opposite > direction to where I was hoping to go with the transition to ARCH_RENESAS. > > In the mean time Renesas ARM-based SoCs need to keep selecting > ARCH_SHMOBILE, which is something I was hoping to change sooner than later. > > I think your patches at the link above neatly resolve this. At least for > sh-drives. Perhaps I need to convince myself there is no fallout from > patches 1 and 2 of that series and go ahead and queue up patches 3 and 4.
I have decided to drop this patch for now as being a partial solution it doesn't seem to buy us much. I am currently thinking in terms of queuing up your patches to drop the whole if block etc... for v4.8 which would neatly give a few cycles for the fallout from the dependencies to appear. Geert, how does that plan sound to you?
