master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

[Mark Brown]

On Fri, Sep 11, 2015 at 11:01:35AM +0100, Build bot for Mark Brown wrote:

> 	arm64-allmodconfig
> ../drivers/firmware/qcom_scm-32.c:196:4: error: expected string literal before '__asmeq'
> ../drivers/firmware/qcom_scm-32.c:221:2: error: implicit declaration of function 'secure_flush_area' [-Werror=implicit-function-declaration]
> ../drivers/firmware/qcom_scm-32.c:239:2: error: implicit declaration of function 'outer_inv_range' [-Werror=implicit-function-declaration]
> ../drivers/firmware/qcom_scm-32.c:331:4: error: expected string literal before '__asmeq'
> ../drivers/firmware/qcom_scm-32.c:361:4: error: expected string literal before '__asmeq'

Today's mainline fails to build on arm64 due to the above, introduced by
efaa6e266ba (firmware: qcom_scm-32: replace open-coded call to
__cpuc_flush_dcache_area()) which introduces a call to
secure_flush_area() which isn't defined on arm64.  This does not happen
in -next as 626ffb400e1e781 (firmware: qcom: scm: Add function stubs for
ARM64) which fixes this and IIRC other issues on arm64 - what is the
plan for getting that change into mainline?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150911/b2ab4134/attachment.sig>

master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

[Will Deacon]

On Fri, Sep 11, 2015 at 01:01:51PM +0100, Mark Brown wrote:
> On Fri, Sep 11, 2015 at 11:01:35AM +0100, Build bot for Mark Brown wrote:
> 
> > 	arm64-allmodconfig
> > ../drivers/firmware/qcom_scm-32.c:196:4: error: expected string literal before '__asmeq'
> > ../drivers/firmware/qcom_scm-32.c:221:2: error: implicit declaration of function 'secure_flush_area' [-Werror=implicit-function-declaration]
> > ../drivers/firmware/qcom_scm-32.c:239:2: error: implicit declaration of function 'outer_inv_range' [-Werror=implicit-function-declaration]
> > ../drivers/firmware/qcom_scm-32.c:331:4: error: expected string literal before '__asmeq'
> > ../drivers/firmware/qcom_scm-32.c:361:4: error: expected string literal before '__asmeq'
> 
> Today's mainline fails to build on arm64 due to the above, introduced by
> efaa6e266ba (firmware: qcom_scm-32: replace open-coded call to
> __cpuc_flush_dcache_area()) which introduces a call to
> secure_flush_area() which isn't defined on arm64.  This does not happen
> in -next as 626ffb400e1e781 (firmware: qcom: scm: Add function stubs for
> ARM64) which fixes this and IIRC other issues on arm64 - what is the
> plan for getting that change into mainline?

There's no way in hell that driver is going to build for arm64, so I'd
suggest something like the following until it's sorted out.

Will

--->8

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 99c69a3205c4..2f51e249829f 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -134,7 +134,7 @@ config ISCSI_IBFT
 
 config QCOM_SCM
 	bool
-	depends on ARM || ARM64
+	depends on ARM
 
 source "drivers/firmware/broadcom/Kconfig"
 source "drivers/firmware/google/Kconfig"

master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

[Russell King - ARM Linux]

On Fri, Sep 11, 2015 at 01:01:51PM +0100, Mark Brown wrote:
> On Fri, Sep 11, 2015 at 11:01:35AM +0100, Build bot for Mark Brown wrote:
> 
> > 	arm64-allmodconfig
> > ../drivers/firmware/qcom_scm-32.c:196:4: error: expected string literal before '__asmeq'
> > ../drivers/firmware/qcom_scm-32.c:221:2: error: implicit declaration of function 'secure_flush_area' [-Werror=implicit-function-declaration]
> > ../drivers/firmware/qcom_scm-32.c:239:2: error: implicit declaration of function 'outer_inv_range' [-Werror=implicit-function-declaration]
> > ../drivers/firmware/qcom_scm-32.c:331:4: error: expected string literal before '__asmeq'
> > ../drivers/firmware/qcom_scm-32.c:361:4: error: expected string literal before '__asmeq'
> 
> Today's mainline fails to build on arm64 due to the above, introduced by
> efaa6e266ba (firmware: qcom_scm-32: replace open-coded call to
> __cpuc_flush_dcache_area()) which introduces a call to
> secure_flush_area() which isn't defined on arm64.

That commit has been in mainline for over a week now, so it shouldn't
be "today's mainline" but mainline from a week ago.

Olof's builder didn't find this error, even when building just my for-next
branch.  I don't remember whether it builds arm64-allmodconfig though, but
I do, and the error hasn't cropped up there.

However, I've educated myself to hardly ever look at arm64-allmodconfig
because it's always broken for one reason or another, and the amount of
warnings it spits out is rediculous, many of them not the fault of ARM64
code, but of crappy driver code.

In my arm64-allmodconfig builds, qcom_scm-32.c never gets built:

  LD [M]  drivers/firewire/firewire-net.o
  CC      drivers/firmware/psci.o
  CC      drivers/firmware/memmap.o
  LD      drivers/firmware/broadcom/built-in.o
  LD      drivers/firmware/built-in.o

That's because QCOM_SCM has to be selected by something:

+config QCOM_SCM
+       bool
+       depends on ARM || ARM64
+

and currently the only place that's selected is:

arch/arm/mach-qcom/Kconfig:     select QCOM_SCM if SMP

Changing the "depends" on QCOM_SCM won't fix it - I think something's
been recently merged which has added another select QCOM_SCM which has
the effect of enabling this on ARM64.  _That_ is the cause of this
breakage.

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

master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

[Russell King - ARM Linux]

On Fri, Sep 11, 2015 at 01:40:45PM +0100, Will Deacon wrote:
> On Fri, Sep 11, 2015 at 01:01:51PM +0100, Mark Brown wrote:
> > On Fri, Sep 11, 2015 at 11:01:35AM +0100, Build bot for Mark Brown wrote:
> > 
> > > 	arm64-allmodconfig
> > > ../drivers/firmware/qcom_scm-32.c:196:4: error: expected string literal before '__asmeq'
> > > ../drivers/firmware/qcom_scm-32.c:221:2: error: implicit declaration of function 'secure_flush_area' [-Werror=implicit-function-declaration]
> > > ../drivers/firmware/qcom_scm-32.c:239:2: error: implicit declaration of function 'outer_inv_range' [-Werror=implicit-function-declaration]
> > > ../drivers/firmware/qcom_scm-32.c:331:4: error: expected string literal before '__asmeq'
> > > ../drivers/firmware/qcom_scm-32.c:361:4: error: expected string literal before '__asmeq'
> > 
> > Today's mainline fails to build on arm64 due to the above, introduced by
> > efaa6e266ba (firmware: qcom_scm-32: replace open-coded call to
> > __cpuc_flush_dcache_area()) which introduces a call to
> > secure_flush_area() which isn't defined on arm64.  This does not happen
> > in -next as 626ffb400e1e781 (firmware: qcom: scm: Add function stubs for
> > ARM64) which fixes this and IIRC other issues on arm64 - what is the
> > plan for getting that change into mainline?
> 
> There's no way in hell that driver is going to build for arm64, so I'd
> suggest something like the following until it's sorted out.

The below doesn't help.  QCOM_SCM can only be enabled if something
selects it (it has no prompt).  Somewhere, a new commit selecting
this option from ARM64 builds has appeared.

Modifying the dependencies of this option in the way you're doing will
cause a Kconfig warning, because the dependencies of a selected option
are not met.

> --->8
> 
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 99c69a3205c4..2f51e249829f 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -134,7 +134,7 @@ config ISCSI_IBFT
>  
>  config QCOM_SCM
>  	bool
> -	depends on ARM || ARM64
> +	depends on ARM
>  
>  source "drivers/firmware/broadcom/Kconfig"
>  source "drivers/firmware/google/Kconfig"
> 

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

master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

[Will Deacon]

On Fri, Sep 11, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 01:40:45PM +0100, Will Deacon wrote:
> > On Fri, Sep 11, 2015 at 01:01:51PM +0100, Mark Brown wrote:
> > > On Fri, Sep 11, 2015 at 11:01:35AM +0100, Build bot for Mark Brown wrote:
> > > 
> > > > 	arm64-allmodconfig
> > > > ../drivers/firmware/qcom_scm-32.c:196:4: error: expected string literal before '__asmeq'
> > > > ../drivers/firmware/qcom_scm-32.c:221:2: error: implicit declaration of function 'secure_flush_area' [-Werror=implicit-function-declaration]
> > > > ../drivers/firmware/qcom_scm-32.c:239:2: error: implicit declaration of function 'outer_inv_range' [-Werror=implicit-function-declaration]
> > > > ../drivers/firmware/qcom_scm-32.c:331:4: error: expected string literal before '__asmeq'
> > > > ../drivers/firmware/qcom_scm-32.c:361:4: error: expected string literal before '__asmeq'
> > > 
> > > Today's mainline fails to build on arm64 due to the above, introduced by
> > > efaa6e266ba (firmware: qcom_scm-32: replace open-coded call to
> > > __cpuc_flush_dcache_area()) which introduces a call to
> > > secure_flush_area() which isn't defined on arm64.  This does not happen
> > > in -next as 626ffb400e1e781 (firmware: qcom: scm: Add function stubs for
> > > ARM64) which fixes this and IIRC other issues on arm64 - what is the
> > > plan for getting that change into mainline?
> > 
> > There's no way in hell that driver is going to build for arm64, so I'd
> > suggest something like the following until it's sorted out.
> 
> The below doesn't help.  QCOM_SCM can only be enabled if something
> selects it (it has no prompt).  Somewhere, a new commit selecting
> this option from ARM64 builds has appeared.

So it's one of these guys:

drivers/gpu/drm/msm/Kconfig:	select QCOM_SCM
drivers/soc/qcom/Kconfig:	select QCOM_SCM

The latter has a "depends on !ARM64", so I guess it's the former (which
depends on ARCH_QCOM and is selectable on arm64).

> Modifying the dependencies of this option in the way you're doing will
> cause a Kconfig warning, because the dependencies of a selected option
> are not met.

Damn. I wonder why the dependency is there in the first place if it's just
selected by another symbol?

Will

master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

[Mark Brown]

On Fri, Sep 11, 2015 at 01:58:30PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 01:01:51PM +0100, Mark Brown wrote:

> > Today's mainline fails to build on arm64 due to the above, introduced by
> > efaa6e266ba (firmware: qcom_scm-32: replace open-coded call to
> > __cpuc_flush_dcache_area()) which introduces a call to
> > secure_flush_area() which isn't defined on arm64.

> That commit has been in mainline for over a week now, so it shouldn't
> be "today's mainline" but mainline from a week ago.

I only noticed it today, given the thing selects with it's likely that
as you say it's been triggered by a change in another tree rather than
having been an issue in itself.

> However, I've educated myself to hardly ever look at arm64-allmodconfig
> because it's always broken for one reason or another, and the amount of
> warnings it spits out is rediculous, many of them not the fault of ARM64
> code, but of crappy driver code.

Indeed, the initial reason I set up my builder was that I was doing work
on arm64 and got fed up with the constant breakage in -next.  It's
getting better slowly, we mostly at least compile now which wasn't the
case originally.

> Changing the "depends" on QCOM_SCM won't fix it - I think something's
> been recently merged which has added another select QCOM_SCM which has
> the effect of enabling this on ARM64.  _That_ is the cause of this
> breakage.

Yes, it'll be the combination of the two commits (hopefully whatever
patch introduced the issue builds on its own branch as well).  There's a
fix been merged into -next somewhere which fixes this - like I said I'm
fairly sure that's 626ffb400e1e781 (firmware: qcom: scm: Add function
stubs for ARM64) which means that an alternative stub implementation in
qcom_scm-64.c gets build on arm64 but that's not hit mainline yet and
we're getting near the end of the merge window.

It would be sad to have yet another release where -rc1 doesn't build for
common test configurations :/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150911/c70665e1/attachment.sig>

master build: 1 failures 73 warnings (v4.2-11142-gb0a1ea5)

[Andy Gross]

On Fri, Sep 11, 2015 at 03:56:38PM +0100, Mark Brown wrote:
> On Fri, Sep 11, 2015 at 01:58:30PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Sep 11, 2015 at 01:01:51PM +0100, Mark Brown wrote:

<snip>

> 
> Indeed, the initial reason I set up my builder was that I was doing work
> on arm64 and got fed up with the constant breakage in -next.  It's
> getting better slowly, we mostly at least compile now which wasn't the
> case originally.
> 
> > Changing the "depends" on QCOM_SCM won't fix it - I think something's
> > been recently merged which has added another select QCOM_SCM which has
> > the effect of enabling this on ARM64.  _That_ is the cause of this
> > breakage.

Right.  The driver which needs the SCM infrastructure selected the QCOM_SCM.
However, since the correct 64-bit version of the SCM hasn't been added, it uses
the current scm driver.
> 
> Yes, it'll be the combination of the two commits (hopefully whatever
> patch introduced the issue builds on its own branch as well).  There's a
> fix been merged into -next somewhere which fixes this - like I said I'm
> fairly sure that's 626ffb400e1e781 (firmware: qcom: scm: Add function
> stubs for ARM64) which means that an alternative stub implementation in
> qcom_scm-64.c gets build on arm64 but that's not hit mainline yet and
> we're getting near the end of the merge window.
> 
> It would be sad to have yet another release where -rc1 doesn't build for
> common test configurations :/

I dropped the ball on this.  I am sending the patch and pull request shortly.

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project