From: Tomasz Figa <tomasz.figa@gmail.com>
To: "Krzysztof Kozłowski" <k.kozlowski@samsung.com>,
"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
"Mark Brown" <broonie@kernel.org>
Cc: linux-samsung-soc@vger.kernel.org,
linaro-kernel@lists.linaro.org,
linux-arm-kernel@lists.infradead.org,
kernel-build-reports@lists.linaro.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: Exynos build failure in -next allmodconfig
Date: Tue, 16 Sep 2014 14:01:02 +0200 [thread overview]
Message-ID: <5418267E.8070501@gmail.com> (raw)
In-Reply-To: <541822AC.8040805@samsung.com>
On 16.09.2014 13:44, Krzysztof Kozłowski wrote:
> On 15.09.2014 19:57, Russell King - ARM Linux wrote:
>> On Mon, Sep 15, 2014 at 09:34:58AM -0700, Mark Brown wrote:
>>> On Mon, Sep 15, 2014 at 11:57:09AM +0100, Build bot for Mark Brown
>>> wrote:
>>>
>>> Today's -next got a build failure in ARM allmodconfig due to platsmp.c:
>>>
>>> | arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in
>>> return expression (different address spaces)
>>> | arch/arm/mach-exynos/platsmp.c:198:31: expected void [noderef]
>>> <asn:2>*
>>> | arch/arm/mach-exynos/platsmp.c:198:31: got void *
>>> | arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in
>>> return expression (different address spaces)
>>> | arch/arm/mach-exynos/platsmp.c:198:31: expected void [noderef]
>>> <asn:2>*
>>> | arch/arm/mach-exynos/platsmp.c:198:31: got void *
>>> | CC arch/arm/mach-exynos/platsmp.o
>>> | /tmp/ccC9fkwF.s: Assembler messages:
>>> | /tmp/ccC9fkwF.s:423: Error: selected processor does not support ARM
>>> mode `isb '
>>> | /tmp/ccC9fkwF.s:428: Error: selected processor does not support ARM
>>> mode `isb '
>>> | /tmp/ccC9fkwF.s:429: Error: selected processor does not support ARM
>>> mode `dsb '
>>> | scripts/Makefile.build:257: recipe for target
>>> 'arch/arm/mach-exynos/platsmp.o' failed
>>>
>>> Looks like we need a compiler flags override for that file.
>>
>> Or.. the question is why a .c file is not using the proper macros.
>
> Actually I am the one to blame for build failure (commit: "ARM: EXYNOS:
> Move code from hotplug.c to platsmp.c"). The problem is
> v7_exit_coherency_flush() which I think does not make sense on ARMv6.
>
> I'll replace the ISB and DSB commands with macros but the real question
> is whether the mach-exynos/platsmp.c file and mach-exynos directory
> should be compiled when CONFIG_ARCH_EXYNOS is not defined?
I think the problematic case here is v6+v7 multiplatform, where even
though CONFIG_ARCH_EXYNOS is defined, compiler flags for lowest common
denominator (v6) must be used. Using appropriate macros should fix the
problem indeed.
Best regards,
Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: Exynos build failure in -next allmodconfig
Date: Tue, 16 Sep 2014 14:01:02 +0200 [thread overview]
Message-ID: <5418267E.8070501@gmail.com> (raw)
In-Reply-To: <541822AC.8040805@samsung.com>
On 16.09.2014 13:44, Krzysztof Koz?owski wrote:
> On 15.09.2014 19:57, Russell King - ARM Linux wrote:
>> On Mon, Sep 15, 2014 at 09:34:58AM -0700, Mark Brown wrote:
>>> On Mon, Sep 15, 2014 at 11:57:09AM +0100, Build bot for Mark Brown
>>> wrote:
>>>
>>> Today's -next got a build failure in ARM allmodconfig due to platsmp.c:
>>>
>>> | arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in
>>> return expression (different address spaces)
>>> | arch/arm/mach-exynos/platsmp.c:198:31: expected void [noderef]
>>> <asn:2>*
>>> | arch/arm/mach-exynos/platsmp.c:198:31: got void *
>>> | arch/arm/mach-exynos/platsmp.c:198:31: warning: incorrect type in
>>> return expression (different address spaces)
>>> | arch/arm/mach-exynos/platsmp.c:198:31: expected void [noderef]
>>> <asn:2>*
>>> | arch/arm/mach-exynos/platsmp.c:198:31: got void *
>>> | CC arch/arm/mach-exynos/platsmp.o
>>> | /tmp/ccC9fkwF.s: Assembler messages:
>>> | /tmp/ccC9fkwF.s:423: Error: selected processor does not support ARM
>>> mode `isb '
>>> | /tmp/ccC9fkwF.s:428: Error: selected processor does not support ARM
>>> mode `isb '
>>> | /tmp/ccC9fkwF.s:429: Error: selected processor does not support ARM
>>> mode `dsb '
>>> | scripts/Makefile.build:257: recipe for target
>>> 'arch/arm/mach-exynos/platsmp.o' failed
>>>
>>> Looks like we need a compiler flags override for that file.
>>
>> Or.. the question is why a .c file is not using the proper macros.
>
> Actually I am the one to blame for build failure (commit: "ARM: EXYNOS:
> Move code from hotplug.c to platsmp.c"). The problem is
> v7_exit_coherency_flush() which I think does not make sense on ARMv6.
>
> I'll replace the ISB and DSB commands with macros but the real question
> is whether the mach-exynos/platsmp.c file and mach-exynos directory
> should be compiled when CONFIG_ARCH_EXYNOS is not defined?
I think the problematic case here is v6+v7 multiplatform, where even
though CONFIG_ARCH_EXYNOS is defined, compiler flags for lowest common
denominator (v6) must be used. Using appropriate macros should fix the
problem indeed.
Best regards,
Tomasz
next prev parent reply other threads:[~2014-09-16 12:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1XTTy1-0000vT-NC@cassiel.sirena.org.uk>
2014-09-15 16:34 ` Exynos build failure in -next allmodconfig Mark Brown
2014-09-15 17:57 ` Russell King - ARM Linux
2014-09-15 17:57 ` Russell King - ARM Linux
2014-09-16 11:44 ` Krzysztof Kozłowski
2014-09-16 11:44 ` Krzysztof Kozłowski
2014-09-16 11:56 ` Russell King - ARM Linux
2014-09-16 11:56 ` Russell King - ARM Linux
2014-09-16 12:01 ` Tomasz Figa [this message]
2014-09-16 12:01 ` Tomasz Figa
2014-09-16 15:54 ` Mark Brown
2014-09-16 15:54 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5418267E.8070501@gmail.com \
--to=tomasz.figa@gmail.com \
--cc=b.zolnierkie@samsung.com \
--cc=broonie@kernel.org \
--cc=k.kozlowski@samsung.com \
--cc=kernel-build-reports@lists.linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.