[PATCH 00/11] ARM: random randconfig fixes, soc specific

[PATCH 00/11] ARM: random randconfig fixes, soc specific

[Arnd Bergmann]

Hello maintainers,

I've kept these to myself for too long, and would like to get them into
v3.20. I hope all of these are noncontroversial, but please have
a look and provide an Ack/Nak where appropriate so we can stick
them into the first fixes pull request after the initial merge
for -rc1.

     Arnd

Arnd Bergmann (11):
  ARM: vexpress: use ARM_CPU_SUSPEND if needed
  ARM: sunxi: always select RESET_CONTROLLER
  ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile
  ARM: davinci: davinci_cfg_reg cannot be init
  ARM: davinci: multi-soc kernels require AUTO_ZRELADDR
  ARM: at91: fix pm declarations
  ARM: prima2: do not select SMP_ON_UP
  ARM: ixp4xx: fix {in,out}s{bwl} data types
  ARM: rockchip: make rockchip_suspend_init conditional
  ARM: sti: always enable RESET_CONTROLLER
  ARM: mvebu: build armada375-smp code conditionally

 arch/arm/mach-at91/generic.h            |  8 ++++----
 arch/arm/mach-bcm/Kconfig               |  4 ++--
 arch/arm/mach-davinci/Kconfig           |  2 ++
 arch/arm/mach-davinci/mux.c             |  4 ++--
 arch/arm/mach-ixp4xx/include/mach/io.h  | 19 +++++++++++++------
 arch/arm/mach-mvebu/system-controller.c |  2 +-
 arch/arm/mach-prima2/Kconfig            |  1 -
 arch/arm/mach-rockchip/pm.h             |  6 ++++++
 arch/arm/mach-sti/Kconfig               |  1 +
 arch/arm/mach-sunxi/Kconfig             |  8 ++------
 arch/arm/mach-vexpress/Kconfig          |  1 +
 11 files changed, 34 insertions(+), 22 deletions(-)

-- 
2.1.0.rc2

Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Barry Song <Baohua.Song@csr.com>
Cc: Christian Daudt <bcm@fixthebug.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Krzysztof Halasa <khalasa@piap.pl>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Maxime Coquelin <maxime.coquelin@st.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@gmail.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Arnd Bergmann]

The vexpress tc2 power management code calls mcpm_loopback, which
is only available if ARM_CPU_SUSPEND is enabled, otherwise we
get a link error:

arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'

This explicitly selects ARM_CPU_SUSPEND like other platforms that
need it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
Cc: Nicolas Pitre <nico@linaro.org>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 arch/arm/mach-vexpress/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index d6b16d9a7838..3c2509b4b694 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
 	depends on MCPM
 	select ARM_CCI
 	select ARCH_VEXPRESS_SPC
+	select ARM_CPU_SUSPEND
 	help
 	  Support for CPU and cluster power management on Versatile Express
 	  with a TC2 (A15x2 A7x3) big.LITTLE core tile.
-- 
2.1.0.rc2

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Nicolas Pitre]

On Thu, 12 Feb 2015, Arnd Bergmann wrote:

> The vexpress tc2 power management code calls mcpm_loopback, which
> is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> get a link error:
> 
> arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> 
> This explicitly selects ARM_CPU_SUSPEND like other platforms that
> need it.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> Cc: Nicolas Pitre <nico@linaro.org>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Acked-by: Nicolas Pitre <nico@linaro.org>

> ---
>  arch/arm/mach-vexpress/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index d6b16d9a7838..3c2509b4b694 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
>  	depends on MCPM
>  	select ARM_CCI
>  	select ARCH_VEXPRESS_SPC
> +	select ARM_CPU_SUSPEND
>  	help
>  	  Support for CPU and cluster power management on Versatile Express
>  	  with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> -- 
> 2.1.0.rc2
> 
> 

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Liviu Dudau]

On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> The vexpress tc2 power management code calls mcpm_loopback, which
> is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> get a link error:
> 
> arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'

Arnd,

We are having reports of TC2 not booting with MCPM enabled. Lorenzo
was investigating this but then headed for Linaro Connect this week,
so we don't have yet a resolution. Can this patch be postponed for
a later -rc?

Best regards,
Liviu


> 
> This explicitly selects ARM_CPU_SUSPEND like other platforms that
> need it.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> Cc: Nicolas Pitre <nico@linaro.org>
> Cc: Kevin Hilman <khilman@linaro.org>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
>  arch/arm/mach-vexpress/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index d6b16d9a7838..3c2509b4b694 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
>  	depends on MCPM
>  	select ARM_CCI
>  	select ARCH_VEXPRESS_SPC
> +	select ARM_CPU_SUSPEND
>  	help
>  	  Support for CPU and cluster power management on Versatile Express
>  	  with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> -- 
> 2.1.0.rc2
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Russell King - ARM Linux]

On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > The vexpress tc2 power management code calls mcpm_loopback, which
> > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > get a link error:
> > 
> > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> 
> Arnd,
> 
> We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> was investigating this but then headed for Linaro Connect this week,
> so we don't have yet a resolution. Can this patch be postponed for
> a later -rc?

Why?

This patch isn't forcing MCPM to be enabled for Versatile Express.

* In order to build tc2_pm.c, MCPM must already be enabled (the
  feature depends on MCPM in the Kconfig already)
* When this feature is enabled, the above link error occurs if
  ARM_CPU_SUSPEND is not also enabled.

So, it is merely fixing the requirement that tc2_pm.c needs the CPU
suspend infrastructure, which in turn has no effect on whether MCPM
is enabled or not.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Liviu Dudau]

On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > get a link error:
> > > 
> > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > 
> > Arnd,
> > 
> > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > was investigating this but then headed for Linaro Connect this week,
> > so we don't have yet a resolution. Can this patch be postponed for
> > a later -rc?
> 
> Why?
> 
> This patch isn't forcing MCPM to be enabled for Versatile Express.
> 
> * In order to build tc2_pm.c, MCPM must already be enabled (the
>   feature depends on MCPM in the Kconfig already)
> * When this feature is enabled, the above link error occurs if
>   ARM_CPU_SUSPEND is not also enabled.
> 
> So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> suspend infrastructure, which in turn has no effect on whether MCPM
> is enabled or not.

Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
make this patch moot.

Best regards,
Liviu

> 
> -- 
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Russell King - ARM Linux]

On Fri, Feb 13, 2015 at 11:01:52AM +0000, Liviu Dudau wrote:
> On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > get a link error:
> > > > 
> > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > > 
> > > Arnd,
> > > 
> > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > was investigating this but then headed for Linaro Connect this week,
> > > so we don't have yet a resolution. Can this patch be postponed for
> > > a later -rc?
> > 
> > Why?
> > 
> > This patch isn't forcing MCPM to be enabled for Versatile Express.
> > 
> > * In order to build tc2_pm.c, MCPM must already be enabled (the
> >   feature depends on MCPM in the Kconfig already)
> > * When this feature is enabled, the above link error occurs if
> >   ARM_CPU_SUSPEND is not also enabled.
> > 
> > So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> > suspend infrastructure, which in turn has no effect on whether MCPM
> > is enabled or not.
> 
> Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
> make this patch moot.

I don't think that makes a difference - the two issues are orthogonal.

As the code stands today, it requires ARM_CPU_SUSPEND to be set, so
merging this change makes total sense.

If the code is temporarily disabled, then we still need this patch
merged to fix the error when the feature is re-enabled.  If the code
is changed later such that it doesn't need mcpm_loopback, then that's
the time to remove the select of this symbol.

If the code is removed, that is something which is not going to happen
during this merge window, so the patch still might as well be applied
to prevent build errors.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Liviu Dudau]

On Fri, Feb 13, 2015 at 11:16:12AM +0000, Russell King - ARM Linux wrote:
> On Fri, Feb 13, 2015 at 11:01:52AM +0000, Liviu Dudau wrote:
> > On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> > > On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > > get a link error:
> > > > > 
> > > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > > > 
> > > > Arnd,
> > > > 
> > > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > > was investigating this but then headed for Linaro Connect this week,
> > > > so we don't have yet a resolution. Can this patch be postponed for
> > > > a later -rc?
> > > 
> > > Why?
> > > 
> > > This patch isn't forcing MCPM to be enabled for Versatile Express.
> > > 
> > > * In order to build tc2_pm.c, MCPM must already be enabled (the
> > >   feature depends on MCPM in the Kconfig already)
> > > * When this feature is enabled, the above link error occurs if
> > >   ARM_CPU_SUSPEND is not also enabled.
> > > 
> > > So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> > > suspend infrastructure, which in turn has no effect on whether MCPM
> > > is enabled or not.
> > 
> > Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
> > make this patch moot.
> 
> I don't think that makes a difference - the two issues are orthogonal.
> 
> As the code stands today, it requires ARM_CPU_SUSPEND to be set, so
> merging this change makes total sense.
> 
> If the code is temporarily disabled, then we still need this patch
> merged to fix the error when the feature is re-enabled.  If the code
> is changed later such that it doesn't need mcpm_loopback, then that's
> the time to remove the select of this symbol.
> 
> If the code is removed, that is something which is not going to happen
> during this merge window, so the patch still might as well be applied
> to prevent build errors.

Russell,

I'm not arguing either way, I was just asking for a delay until Lorenzo
(one other maintainer of the code that is in the Cc) has a chance to
have his say, because I thought it was relevant (and I have explained why).

If Arnd feels he would rather push the patch now rather than (let say) late
Monday, then I can give my Acked-by.

Best regards,
Liviu

> 
> -- 
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Nicolas Pitre]

On Fri, 13 Feb 2015, Liviu Dudau wrote:

> On Fri, Feb 13, 2015 at 11:16:12AM +0000, Russell King - ARM Linux wrote:
> > On Fri, Feb 13, 2015 at 11:01:52AM +0000, Liviu Dudau wrote:
> > > On Fri, Feb 13, 2015 at 10:57:53AM +0000, Russell King - ARM Linux wrote:
> > > > On Fri, Feb 13, 2015 at 10:37:16AM +0000, Liviu Dudau wrote:
> > > > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > > > get a link error:
> > > > > > 
> > > > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > > > > 
> > > > > Arnd,
> > > > > 
> > > > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > > > was investigating this but then headed for Linaro Connect this week,
> > > > > so we don't have yet a resolution. Can this patch be postponed for
> > > > > a later -rc?
> > > > 
> > > > Why?
> > > > 
> > > > This patch isn't forcing MCPM to be enabled for Versatile Express.
> > > > 
> > > > * In order to build tc2_pm.c, MCPM must already be enabled (the
> > > >   feature depends on MCPM in the Kconfig already)
> > > > * When this feature is enabled, the above link error occurs if
> > > >   ARM_CPU_SUSPEND is not also enabled.
> > > > 
> > > > So, it is merely fixing the requirement that tc2_pm.c needs the CPU
> > > > suspend infrastructure, which in turn has no effect on whether MCPM
> > > > is enabled or not.
> > > 
> > > Because I think Lorenzo's plan was to disable MCPM for TC2. Which would
> > > make this patch moot.
> > 
> > I don't think that makes a difference - the two issues are orthogonal.
> > 
> > As the code stands today, it requires ARM_CPU_SUSPEND to be set, so
> > merging this change makes total sense.
> > 
> > If the code is temporarily disabled, then we still need this patch
> > merged to fix the error when the feature is re-enabled.  If the code
> > is changed later such that it doesn't need mcpm_loopback, then that's
> > the time to remove the select of this symbol.
> > 
> > If the code is removed, that is something which is not going to happen
> > during this merge window, so the patch still might as well be applied
> > to prevent build errors.
> 
> Russell,
> 
> I'm not arguing either way, I was just asking for a delay until Lorenzo
> (one other maintainer of the code that is in the Cc) has a chance to
> have his say, because I thought it was relevant (and I have explained why).
> 
> If Arnd feels he would rather push the patch now rather than (let say) late
> Monday, then I can give my Acked-by.

Sorry but I must disagree.

As the original author of that file _and_ actually being responsible for 
the bug fixed by that patch, I really don't understand why waiting for 
Lorenzo would be necessary here.


Nicolas

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Nicolas Pitre]

On Fri, 13 Feb 2015, Liviu Dudau wrote:

> On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > The vexpress tc2 power management code calls mcpm_loopback, which
> > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > get a link error:
> > 
> > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> 
> Arnd,
> 
> We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> was investigating this but then headed for Linaro Connect this week,
> so we don't have yet a resolution. Can this patch be postponed for
> a later -rc?

Can you share those reports?  I did boot my TC2 with v3.19-rc7 before 
leaving for Linaro Connect and it just worked.

Regardless, this patch is about a build fix and doesn't change any 
functionality, so I wouldn't postpone it.



> 
> Best regards,
> Liviu
> 
> 
> > 
> > This explicitly selects ARM_CPU_SUSPEND like other platforms that
> > need it.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> > Cc: Nicolas Pitre <nico@linaro.org>
> > Cc: Kevin Hilman <khilman@linaro.org>
> > Cc: Liviu Dudau <liviu.dudau@arm.com>
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > ---
> >  arch/arm/mach-vexpress/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> > index d6b16d9a7838..3c2509b4b694 100644
> > --- a/arch/arm/mach-vexpress/Kconfig
> > +++ b/arch/arm/mach-vexpress/Kconfig
> > @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> >  	depends on MCPM
> >  	select ARM_CCI
> >  	select ARCH_VEXPRESS_SPC
> > +	select ARM_CPU_SUSPEND
> >  	help
> >  	  Support for CPU and cluster power management on Versatile Express
> >  	  with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> > -- 
> > 2.1.0.rc2
> > 
> > 
> 
> -- 
> ====================
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---------------
>     ?\_(?)_/?
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Liviu Dudau]

On Sat, Feb 14, 2015 at 06:55:05AM +0800, Nicolas Pitre wrote:
> On Fri, 13 Feb 2015, Liviu Dudau wrote:
> 
> > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > get a link error:
> > > 
> > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > 
> > Arnd,
> > 
> > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > was investigating this but then headed for Linaro Connect this week,
> > so we don't have yet a resolution. Can this patch be postponed for
> > a later -rc?
> 
> Can you share those reports?  I did boot my TC2 with v3.19-rc7 before 
> leaving for Linaro Connect and it just worked.
> 
> Regardless, this patch is about a build fix and doesn't change any 
> functionality, so I wouldn't postpone it.
> 

OK. Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>

Best regards,
Liviu

> 
> 
> > 
> > Best regards,
> > Liviu
> > 
> > 
> > > 
> > > This explicitly selects ARM_CPU_SUSPEND like other platforms that
> > > need it.
> > > 
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
> > > Cc: Nicolas Pitre <nico@linaro.org>
> > > Cc: Kevin Hilman <khilman@linaro.org>
> > > Cc: Liviu Dudau <liviu.dudau@arm.com>
> > > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > ---
> > >  arch/arm/mach-vexpress/Kconfig | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> > > index d6b16d9a7838..3c2509b4b694 100644
> > > --- a/arch/arm/mach-vexpress/Kconfig
> > > +++ b/arch/arm/mach-vexpress/Kconfig
> > > @@ -73,6 +73,7 @@ config ARCH_VEXPRESS_TC2_PM
> > >  	depends on MCPM
> > >  	select ARM_CCI
> > >  	select ARCH_VEXPRESS_SPC
> > > +	select ARM_CPU_SUSPEND
> > >  	help
> > >  	  Support for CPU and cluster power management on Versatile Express
> > >  	  with a TC2 (A15x2 A7x3) big.LITTLE core tile.
> > > -- 
> > > 2.1.0.rc2
> > > 
> > > 
> > 
> > -- 
> > ====================
> > | I would like to |
> > | fix the world,  |
> > | but they're not |
> > | giving me the   |
> >  \ source code!  /
> >   ---------------
> >     ?\_(?)_/?
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 


-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH 01/11] ARM: vexpress: use ARM_CPU_SUSPEND if needed

[Lorenzo Pieralisi]

On Sat, Feb 14, 2015 at 01:34:34AM +0000, Liviu Dudau wrote:
> On Sat, Feb 14, 2015 at 06:55:05AM +0800, Nicolas Pitre wrote:
> > On Fri, 13 Feb 2015, Liviu Dudau wrote:
> > 
> > > On Thu, Feb 12, 2015 at 07:42:33PM +0000, Arnd Bergmann wrote:
> > > > The vexpress tc2 power management code calls mcpm_loopback, which
> > > > is only available if ARM_CPU_SUSPEND is enabled, otherwise we
> > > > get a link error:
> > > > 
> > > > arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
> > > > arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'
> > > 
> > > Arnd,
> > > 
> > > We are having reports of TC2 not booting with MCPM enabled. Lorenzo
> > > was investigating this but then headed for Linaro Connect this week,
> > > so we don't have yet a resolution. Can this patch be postponed for
> > > a later -rc?
> > 
> > Can you share those reports?  I did boot my TC2 with v3.19-rc7 before 
> > leaving for Linaro Connect and it just worked.
> > 
> > Regardless, this patch is about a build fix and doesn't change any 
> > functionality, so I wouldn't postpone it.
> > 
> 
> OK. Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>

There is no reason to postpone it, even though TC2 builds with MCPM
enabled and both bL switcher and bL CPUidle driver disabled are
questionable but possible.

There are other issues with PM on TC2 that are not related to this
patch anyway, they can't be since this is a fix for a build issue on
a config that does not enable any PM at all.

Lorenzo

[PATCH 02/11] ARM: sunxi: always select RESET_CONTROLLER

[Arnd Bergmann]

A lot of drivers for mach-sunxi depend on RESET_CONTROLLER. While
this is selected for the drivers that have it, we keep running
into build errors in drivers that are used on both the SoCs with
and without a reset controller.

This patch moves the select statements into the common sunxi
Kconfig option, which solves multiple such problems.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
---
 arch/arm/mach-sunxi/Kconfig | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index a77604fbaf25..8f9f5abf5674 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1,9 +1,11 @@
 menuconfig ARCH_SUNXI
 	bool "Allwinner SoCs" if ARCH_MULTI_V7
 	select ARCH_REQUIRE_GPIOLIB
+	select ARCH_HAS_RESET_CONTROLLER
 	select CLKSRC_MMIO
 	select GENERIC_IRQ_CHIP
 	select PINCTRL
+	select RESET_CONTROLLER
 	select SUN4I_TIMER
 
 if ARCH_SUNXI
@@ -20,10 +22,8 @@ config MACH_SUN5I
 config MACH_SUN6I
 	bool "Allwinner A31 (sun6i) SoCs support"
 	default ARCH_SUNXI
-	select ARCH_HAS_RESET_CONTROLLER
 	select ARM_GIC
 	select MFD_SUN6I_PRCM
-	select RESET_CONTROLLER
 	select SUN5I_HSTIMER
 
 config MACH_SUN7I
@@ -37,16 +37,12 @@ config MACH_SUN7I
 config MACH_SUN8I
 	bool "Allwinner A23 (sun8i) SoCs support"
 	default ARCH_SUNXI
-	select ARCH_HAS_RESET_CONTROLLER
 	select ARM_GIC
 	select MFD_SUN6I_PRCM
-	select RESET_CONTROLLER
 
 config MACH_SUN9I
 	bool "Allwinner (sun9i) SoCs support"
 	default ARCH_SUNXI
-	select ARCH_HAS_RESET_CONTROLLER
 	select ARM_GIC
-	select RESET_CONTROLLER
 
 endif
-- 
2.1.0.rc2

[PATCH 02/11] ARM: sunxi: always select RESET_CONTROLLER

[Maxime Ripard]

Hi Arnd,

On Thu, Feb 12, 2015 at 08:42:34PM +0100, Arnd Bergmann wrote:
> A lot of drivers for mach-sunxi depend on RESET_CONTROLLER. While
> this is selected for the drivers that have it, we keep running
> into build errors in drivers that are used on both the SoCs with
> and without a reset controller.
> 
> This patch moves the select statements into the common sunxi
> Kconfig option, which solves multiple such problems.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>

Chen-Yu already submitted the exact same patch a few days ago:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322806.html

I was waiting for -rc1 to merge it, but I guess your way would work
too.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150213/4cfd5442/attachment.sig>

[PATCH 02/11] ARM: sunxi: always select RESET_CONTROLLER

[Arnd Bergmann]

On Friday 13 February 2015 10:09:19 Maxime Ripard wrote:
> Hi Arnd,
> 
> On Thu, Feb 12, 2015 at 08:42:34PM +0100, Arnd Bergmann wrote:
> > A lot of drivers for mach-sunxi depend on RESET_CONTROLLER. While
> > this is selected for the drivers that have it, we keep running
> > into build errors in drivers that are used on both the SoCs with
> > and without a reset controller.
> > 
> > This patch moves the select statements into the common sunxi
> > Kconfig option, which solves multiple such problems.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> 
> Chen-Yu already submitted the exact same patch a few days ago:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/322806.html
> 
> I was waiting for -rc1 to merge it, but I guess your way would work
> too.

It's not urgent, and since he came first, let's use that patch.

Feel free to add my 'Acked-by: Arnd Bergmann <arnd@arndb.de>' if you
haven't already applied it.

	Arnd

[PATCH 03/11] ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile

[Arnd Bergmann]

A recent cleanup rearranged the Kconfig file for mach-bcm and
accidentally dropped the dependency on ARCH_MULTI_V7, which
makes it possible to now build the two mobile SoC platforms
on an ARMv6-only kernel, resulting in a log of Kconfig
warnings like

warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)

and which of course cannot work on any machine.

This puts back the dependencies as before.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Christian Daudt <bcm@fixthebug.org>
Cc: Scott Branden <sbranden@broadcom.com>
---
 arch/arm/mach-bcm/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78c3ec4..8b11f44bb36e 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
 	  This enables support for systems based on Broadcom mobile SoCs.
 
 config ARCH_BCM_281XX
-	bool "Broadcom BCM281XX SoC family"
+	bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
 	select ARCH_BCM_MOBILE
 	select HAVE_SMP
 	help
@@ -77,7 +77,7 @@ config ARCH_BCM_281XX
 	  variants.
 
 config ARCH_BCM_21664
-	bool "Broadcom BCM21664 SoC family"
+	bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
 	select ARCH_BCM_MOBILE
 	select HAVE_SMP
 	help
-- 
2.1.0.rc2

[PATCH 03/11] ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile

[Florian Fainelli]

2015-02-12 11:42 GMT-08:00 Arnd Bergmann <arnd@arndb.de>:
> A recent cleanup rearranged the Kconfig file for mach-bcm and
> accidentally dropped the dependency on ARCH_MULTI_V7, which
> makes it possible to now build the two mobile SoC platforms
> on an ARMv6-only kernel, resulting in a log of Kconfig
> warnings like
>
> warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
>
> and which of course cannot work on any machine.
>
> This puts back the dependencies as before.

Since both of these Kconfig options also select ARCH_BCM_MOBILE, you
could put the select there instead?

>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Christian Daudt <bcm@fixthebug.org>
> Cc: Scott Branden <sbranden@broadcom.com>
> ---
>  arch/arm/mach-bcm/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index aaeec78c3ec4..8b11f44bb36e 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
>           This enables support for systems based on Broadcom mobile SoCs.
>
>  config ARCH_BCM_281XX
> -       bool "Broadcom BCM281XX SoC family"
> +       bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
>         select ARCH_BCM_MOBILE
>         select HAVE_SMP
>         help
> @@ -77,7 +77,7 @@ config ARCH_BCM_281XX
>           variants.
>
>  config ARCH_BCM_21664
> -       bool "Broadcom BCM21664 SoC family"
> +       bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
>         select ARCH_BCM_MOBILE
>         select HAVE_SMP
>         help
> --
> 2.1.0.rc2
>



-- 
Florian

[PATCH 03/11] ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile

[arnd at arndb.de]

> Florian Fainelli <f.fainelli@gmail.com> hat am 12. Februar 2015 um 21:02
> geschrieben:
> 2015-02-12 11:42 GMT-08:00 Arnd Bergmann <arnd@arndb.de>:
> > A recent cleanup rearranged the Kconfig file for mach-bcm and
> > accidentally dropped the dependency on ARCH_MULTI_V7, which
> > makes it possible to now build the two mobile SoC platforms
> > on an ARMv6-only kernel, resulting in a log of Kconfig
> > warnings like
> >
> > warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct
> > dependencies (CPU_V7)
> >
> > and which of course cannot work on any machine.
> >
> > This puts back the dependencies as before.
>
> Since both of these Kconfig options also select ARCH_BCM_MOBILE, you
> could put the select there instead?

No, that would only work with 'select', but we need 'depends on' here.

    Arnd

[PATCH 03/11] ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile

[Florian Fainelli]

2015-02-12 11:42 GMT-08:00 Arnd Bergmann <arnd@arndb.de>:
> A recent cleanup rearranged the Kconfig file for mach-bcm and
> accidentally dropped the dependency on ARCH_MULTI_V7, which
> makes it possible to now build the two mobile SoC platforms
> on an ARMv6-only kernel, resulting in a log of Kconfig
> warnings like
>
> warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
>
> and which of course cannot work on any machine.
>
> This puts back the dependencies as before.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Christian Daudt <bcm@fixthebug.org>
> Cc: Scott Branden <sbranden@broadcom.com>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>

> ---
>  arch/arm/mach-bcm/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index aaeec78c3ec4..8b11f44bb36e 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
>           This enables support for systems based on Broadcom mobile SoCs.
>
>  config ARCH_BCM_281XX
> -       bool "Broadcom BCM281XX SoC family"
> +       bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
>         select ARCH_BCM_MOBILE
>         select HAVE_SMP
>         help
> @@ -77,7 +77,7 @@ config ARCH_BCM_281XX
>           variants.
>
>  config ARCH_BCM_21664
> -       bool "Broadcom BCM21664 SoC family"
> +       bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
>         select ARCH_BCM_MOBILE
>         select HAVE_SMP
>         help
> --
> 2.1.0.rc2
>



-- 
Florian

[PATCH 03/11] ARM: BCM: put back ARCH_MULTI_V7 dependency for mobile

[Scott Branden]

On 15-02-12 01:57 PM, Florian Fainelli wrote:
> 2015-02-12 11:42 GMT-08:00 Arnd Bergmann <arnd@arndb.de>:
>> A recent cleanup rearranged the Kconfig file for mach-bcm and
>> accidentally dropped the dependency on ARCH_MULTI_V7, which
>> makes it possible to now build the two mobile SoC platforms
>> on an ARMv6-only kernel, resulting in a log of Kconfig
>> warnings like
>>
>> warning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
>>
>> and which of course cannot work on any machine.
>>
>> This puts back the dependencies as before.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>> Cc: Christian Daudt <bcm@fixthebug.org>
>> Cc: Scott Branden <sbranden@broadcom.com>
>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Scott Branden <sbranden@broadcom.com>
>
>> ---
>>   arch/arm/mach-bcm/Kconfig | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index aaeec78c3ec4..8b11f44bb36e 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -68,7 +68,7 @@ config ARCH_BCM_MOBILE
>>            This enables support for systems based on Broadcom mobile SoCs.
>>
>>   config ARCH_BCM_281XX
>> -       bool "Broadcom BCM281XX SoC family"
>> +       bool "Broadcom BCM281XX SoC family" if ARCH_MULTI_V7
>>          select ARCH_BCM_MOBILE
>>          select HAVE_SMP
>>          help
>> @@ -77,7 +77,7 @@ config ARCH_BCM_281XX
>>            variants.
>>
>>   config ARCH_BCM_21664
>> -       bool "Broadcom BCM21664 SoC family"
>> +       bool "Broadcom BCM21664 SoC family" if ARCH_MULTI_V7
>>          select ARCH_BCM_MOBILE
>>          select HAVE_SMP
>>          help
>> --
>> 2.1.0.rc2
>>
>
>
>

[PATCH 04/11] ARM: davinci: davinci_cfg_reg cannot be init

[Arnd Bergmann]

davinci_cfg_reg gets called from a lot of locations that
might get called after the init section has been discarded,
so the function itself must not be marked __init either.

The kernel build currently warns about this with lots of
messages like:

WARNING: vmlinux.o(.text.unlikely+0x24c): Section mismatch in reference from the function dm365evm_mmc_configure() to the function .init.text:davinci_cfg_reg()
The function dm365evm_mmc_configure() references
the function __init davinci_cfg_reg().
This is often because dm365evm_mmc_configure lacks a __init
annotation or the annotation of davinci_cfg_reg is wrong.

This removes the extraneous __init_or_module annotation.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-davinci/mux.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-davinci/mux.c b/arch/arm/mach-davinci/mux.c
index a8eb909a2b6c..6a2ff0a654a5 100644
--- a/arch/arm/mach-davinci/mux.c
+++ b/arch/arm/mach-davinci/mux.c
@@ -30,7 +30,7 @@ static void __iomem *pinmux_base;
 /*
  * Sets the DAVINCI MUX register based on the table
  */
-int __init_or_module davinci_cfg_reg(const unsigned long index)
+int davinci_cfg_reg(const unsigned long index)
 {
 	static DEFINE_SPINLOCK(mux_spin_lock);
 	struct davinci_soc_info *soc_info = &davinci_soc_info;
@@ -101,7 +101,7 @@ int __init_or_module davinci_cfg_reg(const unsigned long index)
 }
 EXPORT_SYMBOL(davinci_cfg_reg);
 
-int __init_or_module davinci_cfg_reg_list(const short pins[])
+int davinci_cfg_reg_list(const short pins[])
 {
 	int i, error = -EINVAL;
 
-- 
2.1.0.rc2

[PATCH 04/11] ARM: davinci: davinci_cfg_reg cannot be init

[Sekhar Nori]

On Friday 13 February 2015 01:12 AM, Arnd Bergmann wrote:
> davinci_cfg_reg gets called from a lot of locations that
> might get called after the init section has been discarded,
> so the function itself must not be marked __init either.
> 
> The kernel build currently warns about this with lots of
> messages like:
> 
> WARNING: vmlinux.o(.text.unlikely+0x24c): Section mismatch in reference from the function dm365evm_mmc_configure() to the function .init.text:davinci_cfg_reg()
> The function dm365evm_mmc_configure() references
> the function __init davinci_cfg_reg().
> This is often because dm365evm_mmc_configure lacks a __init
> annotation or the annotation of davinci_cfg_reg is wrong.
> 
> This removes the extraneous __init_or_module annotation.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>

Acked-by: Sekhar Nori <nsekhar@ti.com>

Thanks,
Sekhar

[PATCH 05/11] ARM: davinci: multi-soc kernels require AUTO_ZRELADDR

[Arnd Bergmann]

The davinci DA8xx and DMx families have incompatible zreladdr
settings, and attempting to build a kernel with both enabled
results in an error unless AUTO_ZRELADDR is set:

multiple zreladdrs: 0xc0008000 0x80008000
This needs CONFIG_AUTO_ZRELADDR to be set

This patch changes Kconfig to make the two families mutually
exclusive when this is unset.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-davinci/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 584e8d4e2892..cd30f6f5f2ff 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -32,12 +32,14 @@ config ARCH_DAVINCI_DM646x
 
 config ARCH_DAVINCI_DA830
 	bool "DA830/OMAP-L137/AM17x based system"
+	depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
 	select ARCH_DAVINCI_DA8XX
 	select CPU_DCACHE_WRITETHROUGH # needed on silicon revs 1.0, 1.1
 	select CP_INTC
 
 config ARCH_DAVINCI_DA850
 	bool "DA850/OMAP-L138/AM18x based system"
+	depends on !ARCH_DAVINCI_DMx || AUTO_ZRELADDR
 	select ARCH_DAVINCI_DA8XX
 	select CP_INTC
 
-- 
2.1.0.rc2

[PATCH 05/11] ARM: davinci: multi-soc kernels require AUTO_ZRELADDR

[Sekhar Nori]

On Friday 13 February 2015 01:12 AM, Arnd Bergmann wrote:
> The davinci DA8xx and DMx families have incompatible zreladdr
> settings, and attempting to build a kernel with both enabled
> results in an error unless AUTO_ZRELADDR is set:
> 
> multiple zreladdrs: 0xc0008000 0x80008000
> This needs CONFIG_AUTO_ZRELADDR to be set
> 
> This patch changes Kconfig to make the two families mutually
> exclusive when this is unset.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>

Acked-by: Sekhar Nori <nsekhar@ti.com>

Thanks for the fixes, Arnd!

Regards,
Sekhar

[PATCH 06/11] ARM: at91: fix pm declarations

[Arnd Bergmann]

In a recent rearrangement of the at91 pm initialization code, a broken
set of declarations was added for the !CONFIG_PM-case, leading to
this link error:

arch/arm/mach-at91/board-dt-sama5.o: In function `at91_rm9200_pm_init':
arch/arm/mach-at91/generic.h:40: multiple definition of `at91_rm9200_pm_init'
arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:40: first defined here
arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9260_pm_init':
arch/arm/mach-at91/generic.h:41: multiple definition of `at91_sam9260_pm_init'
arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:41: first defined here
arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9g45_pm_init':
arch/arm/mach-at91/generic.h:42: multiple definition of `at91_sam9g45_pm_init'
arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:42: first defined here

This adds the missing 'static inline' to the declarations to avoid
creating a copy of the functions in each file that includes the
header.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4db0ba22da9 ("ARM: at91: pm: prepare for multiplatform")
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
 arch/arm/mach-at91/generic.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index a6e726a6e0b5..583369ffc284 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -35,10 +35,10 @@ extern void __init at91sam9260_pm_init(void);
 extern void __init at91sam9g45_pm_init(void);
 extern void __init at91sam9x5_pm_init(void);
 #else
-void __init at91rm9200_pm_init(void) { }
-void __init at91sam9260_pm_init(void) { }
-void __init at91sam9g45_pm_init(void) { }
-void __init at91sam9x5_pm_init(void) { }
+static inline void __init at91rm9200_pm_init(void) { }
+static inline void __init at91sam9260_pm_init(void) { }
+static inline void __init at91sam9g45_pm_init(void) { }
+static inline void __init at91sam9x5_pm_init(void) { }
 #endif
 
 #endif /* _AT91_GENERIC_H */
-- 
2.1.0.rc2

[PATCH 06/11] ARM: at91: fix pm declarations

[Nicolas Ferre]

Le 12/02/2015 20:42, Arnd Bergmann a ?crit :
> In a recent rearrangement of the at91 pm initialization code, a broken
> set of declarations was added for the !CONFIG_PM-case, leading to
> this link error:
> 
> arch/arm/mach-at91/board-dt-sama5.o: In function `at91_rm9200_pm_init':
> arch/arm/mach-at91/generic.h:40: multiple definition of `at91_rm9200_pm_init'
> arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:40: first defined here
> arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9260_pm_init':
> arch/arm/mach-at91/generic.h:41: multiple definition of `at91_sam9260_pm_init'
> arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:41: first defined here
> arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9g45_pm_init':
> arch/arm/mach-at91/generic.h:42: multiple definition of `at91_sam9g45_pm_init'
> arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:42: first defined here
> 
> This adds the missing 'static inline' to the declarations to avoid
> creating a copy of the functions in each file that includes the
> header.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 4db0ba22da9 ("ARM: at91: pm: prepare for multiplatform")
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>

Yes:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Thanks Arnd. Bye,

> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>  arch/arm/mach-at91/generic.h | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
> index a6e726a6e0b5..583369ffc284 100644
> --- a/arch/arm/mach-at91/generic.h
> +++ b/arch/arm/mach-at91/generic.h
> @@ -35,10 +35,10 @@ extern void __init at91sam9260_pm_init(void);
>  extern void __init at91sam9g45_pm_init(void);
>  extern void __init at91sam9x5_pm_init(void);
>  #else
> -void __init at91rm9200_pm_init(void) { }
> -void __init at91sam9260_pm_init(void) { }
> -void __init at91sam9g45_pm_init(void) { }
> -void __init at91sam9x5_pm_init(void) { }
> +static inline void __init at91rm9200_pm_init(void) { }
> +static inline void __init at91sam9260_pm_init(void) { }
> +static inline void __init at91sam9g45_pm_init(void) { }
> +static inline void __init at91sam9x5_pm_init(void) { }
>  #endif
>  
>  #endif /* _AT91_GENERIC_H */
> 


-- 
Nicolas Ferre

[PATCH 07/11] ARM: prima2: do not select SMP_ON_UP

[Arnd Bergmann]

The new Atlas7 platform implicitly selects 'CONFIG_SMP_ON_UP',
which leads to problems if we enable building the platform without
MMU, as that combination is not allowed and causes a link error:

arch/arm/kernel/built-in.o: In function `c_show':
:(.text+0x1872): undefined reference to `smp_on_up'
:(.text+0x1876): undefined reference to `smp_on_up'
arch/arm/kernel/built-in.o: In function `arch_irq_work_raise':
:(.text+0x3d48): undefined reference to `smp_on_up'
:(.text+0x3d4c): undefined reference to `smp_on_up'
arch/arm/kernel/built-in.o: In function `smp_setup_processor_id':
:(.init.text+0x180): undefined reference to `smp_on_up'

This removes the 'select' statement.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 4cba058526a7 ("ARM: sirf: add Atlas7 machine support")
Cc: Zhiwu Song <Zhiwu.Song@csr.com>
Cc: Barry Song <Baohua.Song@csr.com>
---
 arch/arm/mach-prima2/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index a219dc310d5d..e03d8b5c9ad0 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -27,7 +27,6 @@ config ARCH_ATLAS7
 	select CPU_V7
 	select HAVE_ARM_SCU if SMP
 	select HAVE_SMP
-	select SMP_ON_UP if SMP
 	help
           Support for CSR SiRFSoC ARM Cortex A7 Platform
 
-- 
2.1.0.rc2

[PATCH 07/11] ARM: prima2: do not select SMP_ON_UP

[Barry Song]

2015-02-13 3:42 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> The new Atlas7 platform implicitly selects 'CONFIG_SMP_ON_UP',
> which leads to problems if we enable building the platform without
> MMU, as that combination is not allowed and causes a link error:
>
> arch/arm/kernel/built-in.o: In function `c_show':
> :(.text+0x1872): undefined reference to `smp_on_up'
> :(.text+0x1876): undefined reference to `smp_on_up'
> arch/arm/kernel/built-in.o: In function `arch_irq_work_raise':
> :(.text+0x3d48): undefined reference to `smp_on_up'
> :(.text+0x3d4c): undefined reference to `smp_on_up'
> arch/arm/kernel/built-in.o: In function `smp_setup_processor_id':
> :(.init.text+0x180): undefined reference to `smp_on_up'
>
> This removes the 'select' statement.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 4cba058526a7 ("ARM: sirf: add Atlas7 machine support")
> Cc: Zhiwu Song <Zhiwu.Song@csr.com>
> Cc: Barry Song <Baohua.Song@csr.com>
> ---
>  arch/arm/mach-prima2/Kconfig | 1 -
>  1 file changed, 1 deletion(-)

Acked-by: Barry Song <Baohua.Song@csr.com>

>
> diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
> index a219dc310d5d..e03d8b5c9ad0 100644
> --- a/arch/arm/mach-prima2/Kconfig
> +++ b/arch/arm/mach-prima2/Kconfig
> @@ -27,7 +27,6 @@ config ARCH_ATLAS7
>         select CPU_V7
>         select HAVE_ARM_SCU if SMP
>         select HAVE_SMP
> -       select SMP_ON_UP if SMP
>         help
>            Support for CSR SiRFSoC ARM Cortex A7 Platform
>
> --
> 2.1.0.rc2
>

-barry

[PATCH 08/11] ARM: ixp4xx: fix {in,out}s{bwl} data types

[Arnd Bergmann]

Most platforms use void pointer arguments in these functions, but
ixp4xx does not, which triggers lots of warnings in device drivers like:

net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr':
net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argument 2 of 'insw' from incompatible pointer type
   insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1);
   ^
In file included from include/asm/io.h:214:0,
                 from /git/arm-soc/include/linux/io.h:22,
                 from /git/arm-soc/include/linux/pci.h:31,
                 from net/ethernet/8390/ne2k-pci.c:48:
mach-ixp4xx/include/mach/io.h:316:91: note: expected 'u16 *' but argument is of type 'struct e8390_pkt_hdr *'
 static inline void insw(u32 io_addr, u16 *vaddr, u32 count)

Fixing the drivers seems hopeless, so this changes the ixp4xx code
to do the same as the others to avoid the warnings.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Krzysztof Halasa <khalasa@piap.pl>
---
 arch/arm/mach-ixp4xx/include/mach/io.h | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/include/mach/io.h b/arch/arm/mach-ixp4xx/include/mach/io.h
index 6a722860e34d..b02439019963 100644
--- a/arch/arm/mach-ixp4xx/include/mach/io.h
+++ b/arch/arm/mach-ixp4xx/include/mach/io.h
@@ -245,8 +245,10 @@ static inline void outb(u8 value, u32 addr)
 }
 
 #define outsb outsb
-static inline void outsb(u32 io_addr, const u8 *vaddr, u32 count)
+static inline void outsb(u32 io_addr, const void *p, u32 count)
 {
+	const u8 *vaddr = p;
+
 	while (count--)
 		outb(*vaddr++, io_addr);
 }
@@ -262,8 +264,9 @@ static inline void outw(u16 value, u32 addr)
 }
 
 #define outsw outsw
-static inline void outsw(u32 io_addr, const u16 *vaddr, u32 count)
+static inline void outsw(u32 io_addr, const void *p, u32 count)
 {
+	const u16 *vaddr = p;
 	while (count--)
 		outw(cpu_to_le16(*vaddr++), io_addr);
 }
@@ -275,8 +278,9 @@ static inline void outl(u32 value, u32 addr)
 }
 
 #define outsl outsl
-static inline void outsl(u32 io_addr, const u32 *vaddr, u32 count)
+static inline void outsl(u32 io_addr, const void *p, u32 count)
 {
+	const u32 *vaddr = p;
 	while (count--)
 		outl(cpu_to_le32(*vaddr++), io_addr);
 }
@@ -294,8 +298,9 @@ static inline u8 inb(u32 addr)
 }
 
 #define insb insb
-static inline void insb(u32 io_addr, u8 *vaddr, u32 count)
+static inline void insb(u32 io_addr, void *p, u32 count)
 {
+	u8 *vaddr = p;
 	while (count--)
 		*vaddr++ = inb(io_addr);
 }
@@ -313,8 +318,9 @@ static inline u16 inw(u32 addr)
 }
 
 #define insw insw
-static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
+static inline void insw(u32 io_addr, void *p, u32 count)
 {
+	u16 *vaddr = p;
 	while (count--)
 		*vaddr++ = le16_to_cpu(inw(io_addr));
 }
@@ -330,8 +336,9 @@ static inline u32 inl(u32 addr)
 }
 
 #define insl insl
-static inline void insl(u32 io_addr, u32 *vaddr, u32 count)
+static inline void insl(u32 io_addr, void *p, u32 count)
 {
+	u32 *vaddr = p;
 	while (count--)
 		*vaddr++ = le32_to_cpu(inl(io_addr));
 }
-- 
2.1.0.rc2

[PATCH 08/11] ARM: ixp4xx: fix {in,out}s{bwl} data types

[Krzysztof Hałasa]

Arnd Bergmann <arnd@arndb.de> writes:

> Most platforms use void pointer arguments in these functions, but
> ixp4xx does not, which triggers lots of warnings in device drivers like:
>
> net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr':
> net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argument 2 of 'insw' from incompatible pointer type
>    insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1);
>    ^
> In file included from include/asm/io.h:214:0,
>                  from /git/arm-soc/include/linux/io.h:22,
>                  from /git/arm-soc/include/linux/pci.h:31,
>                  from net/ethernet/8390/ne2k-pci.c:48:
> mach-ixp4xx/include/mach/io.h:316:91: note: expected 'u16 *' but argument is of type 'struct e8390_pkt_hdr *'
>  static inline void insw(u32 io_addr, u16 *vaddr, u32 count)
>
> Fixing the drivers seems hopeless, so this changes the ixp4xx code
> to do the same as the others to avoid the warnings.

Acked-by: Krzysztof Halasa <khalasa@piap.pl>
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH 09/11] ARM: rockchip: make rockchip_suspend_init conditional

[Arnd Bergmann]

If CONFIG_PM_SLEEP is disabled, we get a build error for rockchips:

arch/arm/mach-rockchip/built-in.o: In function `rockchip_dt_init':
:(.init.text+0x1c): undefined reference to `rockchip_suspend_init'

This adds an inline alternative for that case.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-rockchip at lists.infradead.org
---
 arch/arm/mach-rockchip/pm.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-rockchip/pm.h b/arch/arm/mach-rockchip/pm.h
index 7d752ff39f91..7c889c04604b 100644
--- a/arch/arm/mach-rockchip/pm.h
+++ b/arch/arm/mach-rockchip/pm.h
@@ -24,7 +24,13 @@ extern unsigned long rkpm_bootdata_ddr_data;
 extern unsigned long rk3288_bootram_sz;
 
 void rockchip_slp_cpu_resume(void);
+#ifdef CONFIG_PM_SLEEP
 void __init rockchip_suspend_init(void);
+#else
+static inline void rockchip_suspend_init(void)
+{
+}
+#endif
 
 /****** following is rk3288 defined **********/
 #define RK3288_PMU_WAKEUP_CFG0		0x00
-- 
2.1.0.rc2

[PATCH 09/11] ARM: rockchip: make rockchip_suspend_init conditional

[Heiko Stübner]

Am Donnerstag, 12. Februar 2015, 20:42:41 schrieb Arnd Bergmann:
> If CONFIG_PM_SLEEP is disabled, we get a build error for rockchips:
> 
> arch/arm/mach-rockchip/built-in.o: In function `rockchip_dt_init':
> :(.init.text+0x1c): undefined reference to `rockchip_suspend_init'
> 
> This adds an inline alternative for that case.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: linux-rockchip at lists.infradead.org

thanks for the catch,
Reviewed-by: Heiko Stuebner <heiko@sntech.de>

I guess you will apply the whole 11-patch series en block to arm-soc, right?


Heiko

[PATCH 10/11] ARM: sti: always enable RESET_CONTROLLER

[Arnd Bergmann]

A lot of the sti device drivers require reset controller support,
but do not all have individual 'depends on RESET_CONTROLLER'
statements. Using 'select' here once avoids a lot of build errors
resulting from this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Maxime Coquelin <maxime.coquelin@st.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
 arch/arm/mach-sti/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index 8825bc9e2553..3b1ac463a494 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -13,6 +13,7 @@ menuconfig ARCH_STI
 	select ARM_ERRATA_775420
 	select PL310_ERRATA_753970 if CACHE_L2X0
 	select PL310_ERRATA_769419 if CACHE_L2X0
+	select RESET_CONTROLLER
 	help
 	  Include support for STiH41x SOCs like STiH415/416 using the device tree
 	  for discovery
-- 
2.1.0.rc2

[PATCH 10/11] ARM: sti: always enable RESET_CONTROLLER

[Patrice Chotard]

Hi Arnd

On 02/12/2015 08:42 PM, Arnd Bergmann wrote:
> A lot of the sti device drivers require reset controller support,
> but do not all have individual 'depends on RESET_CONTROLLER'
> statements. Using 'select' here once avoids a lot of build errors
> resulting from this.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Coquelin <maxime.coquelin@st.com>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@gmail.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
>   arch/arm/mach-sti/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
> index 8825bc9e2553..3b1ac463a494 100644
> --- a/arch/arm/mach-sti/Kconfig
> +++ b/arch/arm/mach-sti/Kconfig
> @@ -13,6 +13,7 @@ menuconfig ARCH_STI
>   	select ARM_ERRATA_775420
>   	select PL310_ERRATA_753970 if CACHE_L2X0
>   	select PL310_ERRATA_769419 if CACHE_L2X0
> +	select RESET_CONTROLLER
>   	help
>   	  Include support for STiH41x SOCs like STiH415/416 using the device tree
>   	  for discovery

Acked-by: Patrice Chotard <patrice.chotard@st.com>

Thanks

[PATCH 10/11] ARM: sti: always enable RESET_CONTROLLER

[Maxime Coquelin]

Hi Arnd,
On 02/12/2015 08:42 PM, Arnd Bergmann wrote:
> A lot of the sti device drivers require reset controller support,
> but do not all have individual 'depends on RESET_CONTROLLER'
> statements. Using 'select' here once avoids a lot of build errors
> resulting from this.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Maxime Coquelin <maxime.coquelin@st.com>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@gmail.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
>   arch/arm/mach-sti/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
>

I agree with you, the board is useless without all the drivers depending 
on the resets.

You can add my:
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>

Br,
Maxime

[PATCH 11/11] ARM: mvebu: build armada375-smp code conditionally

[Arnd Bergmann]

mvebu_armada375_smp_wa_init is only used on armada 375 but is defined
for all mvebu machines. As it calls a function that is only provided
sometimes, this can result in a link error:

arch/arm/mach-mvebu/built-in.o: In function `mvebu_armada375_smp_wa_init':
:(.text+0x228): undefined reference to `mvebu_setup_boot_addr_wa'

To solve this, we can just change the existing #ifdef around the
function to also check for Armada375 SMP platforms.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 305969fb6292 ("ARM: mvebu: use the common function for Armada 375 SMP workaround")
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
---
 arch/arm/mach-mvebu/system-controller.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/system-controller.c b/arch/arm/mach-mvebu/system-controller.c
index a068cb5c2ce8..c6c132acd7a6 100644
--- a/arch/arm/mach-mvebu/system-controller.c
+++ b/arch/arm/mach-mvebu/system-controller.c
@@ -126,7 +126,7 @@ int mvebu_system_controller_get_soc_id(u32 *dev, u32 *rev)
 		return -ENODEV;
 }
 
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && defined(CONFIG_MACH_MVEBU_V7)
 void mvebu_armada375_smp_wa_init(void)
 {
 	u32 dev, rev;
-- 
2.1.0.rc2