Hi Russell,
After merging the arm tree, today's linux-next build (arm defconfig)
produced this warning:
arch/arm/vfp/vfpmodule.c: In function 'vfp_init':
arch/arm/vfp/vfpmodule.c:725:6: warning: unused variable 'mvfr0' [-Wunused-variable]
u32 mvfr0;
^
Introduced by commit 3f4c9f8f0a20 ("ARM: 8197/1: vfp: Fix VFPv3 hwcap
detection on CPUID based cpus").
--
Cheers,
Stephen Rothwell [email protected]
On 11/18/2014 12:25 AM, Stephen Rothwell wrote:
> Hi Russell,
>
> After merging the arm tree, today's linux-next build (arm defconfig)
> produced this warning:
>
> arch/arm/vfp/vfpmodule.c: In function 'vfp_init':
> arch/arm/vfp/vfpmodule.c:725:6: warning: unused variable 'mvfr0' [-Wunused-variable]
> u32 mvfr0;
> ^
>
> Introduced by commit 3f4c9f8f0a20 ("ARM: 8197/1: vfp: Fix VFPv3 hwcap
> detection on CPUID based cpus").
>
Urgh, I thought I fixed that but I guess I only took care of not
assigning it unless we actually need it. Well we can do the #ifdef
thing, or move to IS_ENABLED. Here's both options.
---8<----
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 5002d002f6e3..216cd78f64aa 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -752,30 +752,30 @@ static int __init vfp_init(void)
* precision floating point operations. Only check
* for NEON if the hardware has the MVFR registers.
*/
-#ifdef CONFIG_NEON
- if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
+ if (IS_ENABLED(CONFIG_NEON) &&
+ (fmrx(MVFR1) & 0x000fff00) == 0x00011100)
elf_hwcap |= HWCAP_NEON;
-#endif
-#ifdef CONFIG_VFPv3
- mvfr0 = fmrx(MVFR0);
- if (((mvfr0 & MVFR0_DP_MASK) >> MVFR0_DP_BIT) == 0x2 ||
- ((mvfr0 & MVFR0_SP_MASK) >> MVFR0_SP_BIT) == 0x2) {
- elf_hwcap |= HWCAP_VFPv3;
- /*
- * Check for VFPv3 D16 and VFPv4 D16. CPUs in
- * this configuration only have 16 x 64bit
- * registers.
- */
- if ((mvfr0 & MVFR0_A_SIMD_MASK) == 1)
- /* also v4-D16 */
- elf_hwcap |= HWCAP_VFPv3D16;
- else
- elf_hwcap |= HWCAP_VFPD32;
- }
- if ((fmrx(MVFR1) & 0xf0000000) == 0x10000000)
- elf_hwcap |= HWCAP_VFPv4;
-#endif
+ if (IS_ENABLED(CONFIG_VFPv3)) {
+ mvfr0 = fmrx(MVFR0);
+ if (((mvfr0 & MVFR0_DP_MASK) >> MVFR0_DP_BIT) == 0x2 ||
+ ((mvfr0 & MVFR0_SP_MASK) >> MVFR0_SP_BIT) == 0x2) {
+ elf_hwcap |= HWCAP_VFPv3;
+ /*
+ * Check for VFPv3 D16 and VFPv4 D16. CPUs in
+ * this configuration only have 16 x 64bit
+ * registers.
+ */
+ if ((mvfr0 & MVFR0_A_SIMD_MASK) == 1)
+ /* also v4-D16 */
+ elf_hwcap |= HWCAP_VFPv3D16;
+ else
+ elf_hwcap |= HWCAP_VFPD32;
+ }
+
+ if ((fmrx(MVFR1) & 0xf0000000) == 0x10000000)
+ elf_hwcap |= HWCAP_VFPv4;
+ }
/* Extract the architecture version on pre-cpuid scheme */
} else {
if (vfpsid & FPSID_NODOUBLE) {
or
---8<----
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 5002d002f6e3..19a9338117bd 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -722,7 +722,9 @@ static int __init vfp_init(void)
{
unsigned int vfpsid;
unsigned int cpu_arch = cpu_architecture();
+#ifdef CONFIG_VFPv3
u32 mvfr0;
+#endif
if (cpu_arch >= CPU_ARCH_ARMv6)
on_each_cpu(vfp_enable, NULL, 1);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On Tue, Nov 18, 2014 at 10:57:26AM -0800, Stephen Boyd wrote:
> Urgh, I thought I fixed that but I guess I only took care of not
> assigning it unless we actually need it. Well we can do the #ifdef
> thing, or move to IS_ENABLED. Here's both options.
I'd prefer the first as it increases compiler coverage.
Thanks.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On 11/18/2014 11:21 AM, Russell King - ARM Linux wrote:
> On Tue, Nov 18, 2014 at 10:57:26AM -0800, Stephen Boyd wrote:
>> Urgh, I thought I fixed that but I guess I only took care of not
>> assigning it unless we actually need it. Well we can do the #ifdef
>> thing, or move to IS_ENABLED. Here's both options.
> I'd prefer the first as it increases compiler coverage.
>
> Thanks.
>
Ok I'll ship it into your patch system in a little bit with some real
commit text.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
On Tue, 28 Nov 2017, Russell King wrote:
> On Wed, Nov 29, 2017 at 10:38:05AM +1100, Stephen Rothwell wrote:
> > Hi Russell,
> >
> > On Tue, 28 Nov 2017 23:19:59 +0000 Russell King <[email protected]> wrote:
> > >
> > > Stephen, which binutils version are you using?
> >
> > GNU ld (GNU Binutils) 2.25.2
> >
> > built from upstream source some time ago.
>
> Hmm, so slightly younger than mine (2.25) which also generates the
> warnings.
Well... somehow I failed to notice those warning when I initially tested
the patch. Sorry about that.
Now that I do see those warnings, that patch just needs the following to
"fix" them the way they just like we already do for a Thumb2 build:
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 80351e505f..e83f5161fd 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -115,9 +115,11 @@ ifeq ($(CONFIG_ARM_UNWIND),y)
CFLAGS_ABI +=-funwind-tables
endif
+# Accept old syntax despite ".syntax unified"
+AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
+
ifeq ($(CONFIG_THUMB2_KERNEL),y)
AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
-AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
CFLAGS_ISA :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb
# Work around buggy relocation from gas if requested:
@@ -125,7 +127,7 @@ ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
KBUILD_CFLAGS_MODULE +=-fno-optimize-sibling-calls
endif
else
-CFLAGS_ISA :=$(call cc-option,-marm,)
+CFLAGS_ISA :=$(call cc-option,-marm,) $(AFLAGS_NOWARN)
AFLAGS_ISA :=$(CFLAGS_ISA)
endif
New patch submitted.
Nicolas
From 1585355193967571154@xxx Tue Nov 28 23:42:10 +0000 2017
X-GM-THRID: 1585353650103574448
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Wed, Nov 29, 2017 at 10:38:05AM +1100, Stephen Rothwell wrote:
> Hi Russell,
>
> On Tue, 28 Nov 2017 23:19:59 +0000 Russell King <[email protected]> wrote:
> >
> > Stephen, which binutils version are you using?
>
> GNU ld (GNU Binutils) 2.25.2
>
> built from upstream source some time ago.
Hmm, so slightly younger than mine (2.25) which also generates the
warnings.
--
Russell King
ARM architecture Linux Kernel maintainer
From 1585355120502817787@xxx Tue Nov 28 23:41:00 +0000 2017
X-GM-THRID: 1585353650103574448
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Tue, 28 Nov 2017, Russell King wrote:
> On Wed, Nov 29, 2017 at 10:16:37AM +1100, Stephen Rothwell wrote:
> > Hi Russell,
> >
> > After merging the arm tree, today's linux-next build (arm
> > multi_v7_defconfig) produced this warning:
> >
> > arch/arm/vfp/vfphw.S: Assembler messages:
> > arch/arm/vfp/vfphw.S:158: Warning: conditional infixes are deprecated in unified syntax
> > arch/arm/vfp/vfphw.S:233: Warning: conditional infixes are deprecated in unified syntax
> > arch/arm/kernel/entry-common.S: Assembler messages:
> > arch/arm/kernel/entry-common.S:285: Warning: conditional infixes are deprecated in unified syntax
> > arch/arm/kernel/entry-common.S:286: Warning: conditional infixes are deprecated in unified syntax
> > arch/arm/kernel/entry-common.S:365: Warning: conditional infixes are deprecated in unified syntax
> >
> > And many more similar.
> >
> > Presumably introduced by commit
> >
> > cabcafe5d1a5 ("ARM: 8723/1: always assume the "unified" syntax for assembly code")
>
> Well, I seem to be missing all results from the various kernel build
> systems, so I've no idea what's going on with those - although kernelci
> has sent me boot results with no build results... our test systems
> seem to be unreliable.
>
> Dropping Nicolas' commit, there's obviously something wrong with it
> somewhere. Nicolas, can you reproduce these problems?
I'll investigate right away.
Nicolas
From 1585354998419018893@xxx Tue Nov 28 23:39:04 +0000 2017
X-GM-THRID: 1585353650103574448
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
Hi Russell,
On Tue, 28 Nov 2017 23:19:59 +0000 Russell King <[email protected]> wrote:
>
> Stephen, which binutils version are you using?
GNU ld (GNU Binutils) 2.25.2
built from upstream source some time ago.
--
Cheers,
Stephen Rothwell
From 1585354570049764751@xxx Tue Nov 28 23:32:15 +0000 2017
X-GM-THRID: 1585353650103574448
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Wed, Nov 29, 2017 at 10:16:37AM +1100, Stephen Rothwell wrote:
> Hi Russell,
>
> After merging the arm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> arch/arm/vfp/vfphw.S: Assembler messages:
> arch/arm/vfp/vfphw.S:158: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/vfp/vfphw.S:233: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/kernel/entry-common.S: Assembler messages:
> arch/arm/kernel/entry-common.S:285: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/kernel/entry-common.S:286: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/kernel/entry-common.S:365: Warning: conditional infixes are deprecated in unified syntax
>
> And many more similar.
>
> Presumably introduced by commit
>
> cabcafe5d1a5 ("ARM: 8723/1: always assume the "unified" syntax for assembly code")
Well, I seem to be missing all results from the various kernel build
systems, so I've no idea what's going on with those - although kernelci
has sent me boot results with no build results... our test systems
seem to be unreliable.
Dropping Nicolas' commit, there's obviously something wrong with it
somewhere. Nicolas, can you reproduce these problems?
--
Russell King
ARM architecture Linux Kernel maintainer
From 1585353862494618165@xxx Tue Nov 28 23:21:01 +0000 2017
X-GM-THRID: 1585353650103574448
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
On Wed, Nov 29, 2017 at 10:16:37AM +1100, Stephen Rothwell wrote:
> Hi Russell,
>
> After merging the arm tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> arch/arm/vfp/vfphw.S: Assembler messages:
> arch/arm/vfp/vfphw.S:158: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/vfp/vfphw.S:233: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/kernel/entry-common.S: Assembler messages:
> arch/arm/kernel/entry-common.S:285: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/kernel/entry-common.S:286: Warning: conditional infixes are deprecated in unified syntax
> arch/arm/kernel/entry-common.S:365: Warning: conditional infixes are deprecated in unified syntax
>
> And many more similar.
>
> Presumably introduced by commit
>
> cabcafe5d1a5 ("ARM: 8723/1: always assume the "unified" syntax for assembly code")
Nicolas, was your patch tested? Is this another binutils weirdness?
Stephen, which binutils version are you using?
Thanks.
--
Russell King
ARM architecture Linux Kernel maintainer
From 1585353650103574448@xxx Tue Nov 28 23:17:38 +0000 2017
X-GM-THRID: 1585353650103574448
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread