Latest build results - errors/warnings - lots of them

Latest build results - errors/warnings - lots of them

[Russell King - ARM Linux]

Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
source of errors.

OMAP stuff needs a serious look at too - much Kconfig madness there
caused by over-use of select, which then goes on to cause build errors
because it assumes some stuff is always enabled.

There's also warnings about of_device_id from include/linux/of_platform.h
via from arch/arm/kernel/setup.c which feature in all the non-OF builds
too which need addressing.

See todays http://www.arm.linux.org.uk/developer/build/ results for all
the details and configs.  Not pushing my tree until some of this stuff
gets fixed.

Latest build results - errors/warnings - lots of them

[Arnd Bergmann]

On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> source of errors.

Yes, I noticed this but haven't gotten around to prepare a patch. I'll comment
below.

> OMAP stuff needs a serious look at too - much Kconfig madness there
> caused by over-use of select, which then goes on to cause build errors
> because it assumes some stuff is always enabled.

Ack. I have not looked much at randconfig output, but this has certianly
grown worse after CONFIG_ARCH_OMAP has gotten included in ARCH_MULTIPLATFORM

> There's also warnings about of_device_id from include/linux/of_platform.h
> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> too which need addressing.

Hmm, I did not get that one, but I think that's from arm-soc and I'll
try to fix it up.

>arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
>arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
>arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
>arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
>arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
>arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
>arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'

Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
We can either fix it up by adding

	.arch	armv7-a

in the assembly files, or by doing the same in the Makefile:

AFLAGS_vlock.S += -march=armv7-a
AFLAGS_mcpm_head.S += -march=armv7-a

If you have a preference one way or another I can send you a proper patch,
or you just fix it up in your tree.

>arch/arm/common/mcpm_platsmp.c: In function 'mcpm_secondary_init':
>arch/arm/common/mcpm_platsmp.c:52:2: error: implicit declaration of function 'gic_secondary_init'

This is from a conflict between Nico's patch and Catalin's removal of the
gic_secondary_init function as part of c0114709ed "irqchip: gic: Perform
the gic_secondary_init() call via CPU notifier". I think we can just remove
the call here, but I'm not completely sure if I understand the patch
right.

>arch/arm/mach-imx/hotplug.c: In function 'imx_cpu_die':
>arch/arm/mach-imx/hotplug.c:53:2: error: implicit declaration of function 'cpu_do_idle'
>arch/arm/mach-imx/hotplug.c: In function 'imx_cpu_kill':
>arch/arm/mach-imx/hotplug.c:58:26: error: 'jiffies' undeclared (first use in this function)
>arch/arm/mach-imx/hotplug.c:58:2: error: implicit declaration of function 'msecs_to_jiffies'
>arch/arm/mach-imx/hotplug.c:61:3: error: implicit declaration of function 'time_after'

I've not seen this one before. There are many randconfig problems remaining I fear.

>In file included from arch/arm/include/asm/kvm_host.h:41:0,
>                 from include/linux/kvm_host.h:33,
>                 from kernel/context_tracking.c:18:
>arch/arm/include/asm/kvm_vgic.h:59:11: error: 'CONFIG_KVM_ARM_MAX_VCPUS' undeclared here (not in a function)

I sent a patch last week for this one, and the patch was applied in the
KVM tree.

>drivers/gpu/drm/tilcdc/tilcdc_slave.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>drivers/gpu/drm/tilcdc/tilcdc_panel.o:(.data+0x54): multiple definition of `__mod_of_device_table'
>drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here
>drivers/gpu/drm/tilcdc/tilcdc_drv.o:(.data+0x184): multiple definition of `__mod_of_device_table'
>drivers/gpu/drm/tilcdc/tilcdc_tfp410.o:(.data+0x54): first defined here

My patch for this one was applied to the DRM tree.

>drivers/tty/serial/omap-serial.c: In function 'serial_omap_console_write':
>drivers/tty/serial/omap-serial.c:1224:14: error: 'struct uart_port' has no member named 'sysrq'

I haven't seen this one.

>Warnings
>
>warning: (BPCTL) selects NET_CORE which has unmet direct dependencies (NETDEVICES)

I'm not that worried about staging drivers, although I sent a couple of fixes for
other staging bugs I found.

>warning: (UX500_SOC_COMMON) selects PINCTRL_ABX500 which has unmet direct dependencies (PINCTRL && AB8500_CORE)

This seems to be newly introduced and should definitely be fixed soon.

>warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION)

This one has been around forever. I had a patch before but it was never urgent enough, since it's
only a harmless warning in randconfig.


>In file included from arch/arm/mach-imx/hotplug.c:16:0:
>arch/arm/mach-imx/common.h:100:29: warning: 'struct pt_regs' declared inside parameter list
>arch/arm/mach-imx/common.h:100:29: warning: its scope is only this definition or declaration, which is probably not what you want
>arch/arm/mach-imx/common.h:101:29: warning: 'struct pt_regs' declared inside parameter list

I don't know this one.

>kernel/time/tick-sched.c:89:16: warning: 'tick_init_jiffy_update' defined but not used
>kernel/time/tick-sched.c:103:13: warning: 'tick_sched_do_timer' defined but not used
>kernel/time/tick-sched.c:124:13: warning: 'tick_sched_handle' defined but not used
>kernel/profile.c:247:13: warning: 'profile_flip_buffers' defined but not used
>kernel/profile.c:270:13: warning: 'profile_discard_flip_buffers' defined but not used
>kernel/profile.c:334:125: warning: 'profile_cpu_callback' defined but not used
>drivers/staging/csr/io.c:80:12: warning: 'uf_read_proc' used but never defined
>drivers/video/aty/radeon_pm.c:1718:13: warning: 'radeon_reinitialize_M10' defined but not used

I think I made a fix for these before but gave up for now with too many other randconfig
warnings without CONFIG_PROC_FS. Same thing for CONFIG_BUG: I ended up just hard enabling
those.

>crypto/wp512.c: In function 'wp512_process_buffer':
>crypto/wp512.c:987:1: warning: the frame size of 1296 bytes is larger than 1024 bytes

My solution to this one was to slightly enlarge the stack size limit on ARM. There are a couple
of functions that have a stack that is just over 1KB on ARM but just under 1KB on other
architectures.

>drivers/mfd/wm8994-core.c: In function 'wm8994_device_init.clone.1':
>drivers/mfd/wm8994-core.c:408:14: warning: 'patch_regs' may be used uninitialized in this function
>drivers/pinctrl/pinctrl-nomadik.c: In function 'nmk_pmx_enable':
>drivers/pinctrl/pinctrl-nomadik.c:1810:16: warning: 'flags' may be used uninitialized in this function
>drivers/gpu/drm/radeon/r100.c: In function 'r100_bandwidth_update':
>drivers/gpu/drm/radeon/r100.c:3153:50: warning: 'disp_drain_rate.full' may be used uninitialized in this function
>drivers/gpu/drm/radeon/r100.c:3099:63: warning: 'crit_point_ff.full' may be used uninitialized in this function
>drivers/gpu/drm/tegra/dc.c: In function 'tegra_dc_setup_window':
>drivers/gpu/drm/tegra/dc.c:420:12: warning: 'planar' may be used uninitialized in this function
>drivers/gpu/drm/drm_irq.c: In function 'drm_calc_vbltimestamp_from_scanoutpos':
>drivers/gpu/drm/drm_irq.c:587:24: warning: 'mono_time_offset.tv64' may be used uninitialized in this function
>net/wireless/reg.c: In function 'reg_device_uevent':
>net/wireless/reg.c:2271:5: warning: 'alpha2[0]' may be used uninitialized in this function
>net/wireless/reg.c:2271:5: warning: 'alpha2[1]' may be used uninitialized in this function
>net/wireless/nl80211.c: In function '__cfg80211_wdev_from_attrs.clone.61':
>net/wireless/nl80211.c:58:6: warning: 'wdev_id' may be used uninitialized in this function

I have now queued up my patch that removes the bogus "used uninitialized" warnings
we get with gcc-4.7 or later and -Os.

>
>Section mismatch errors
>
>WARNING: arch/arm/mach-tegra/built-in.o(.text+0xb4c): Section mismatch in reference from the function tegra_pmc_parse_dt() to the (unknown reference) .init.rodata:(unknown)
>The function tegra_pmc_parse_dt() references
>the (unknown reference) __initconst (unknown).
>This is often because tegra_pmc_parse_dt lacks a __initconst 
>annotation or the annotation of (unknown) is wrong.

Stupid gcc optimization. I thought this was fixed in gcc. Which version are you using?

	Arnd

Latest build results - errors/warnings - lots of them

[Dave Martin]

On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > source of errors.

[...]
 
> >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> 
> Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> We can either fix it up by adding
> 
> 	.arch	armv7-a
> 
> in the assembly files, or by doing the same in the Makefile:
> 
> AFLAGS_vlock.S += -march=armv7-a
> AFLAGS_mcpm_head.S += -march=armv7-a


Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
no v6 boards were configured in when testing that...


Assuming people are OK with the Makefile route, here's a patch for that,
build-tested with a v6+v7 ARCH_MULTIPLATFORM config.

Cheers
---Dave


>From 193f254689beaa1612d29bcc5ba004a933b37d95 Mon Sep 17 00:00:00 2001
From: Dave Martin <dave.martin@linaro.org>
Date: Tue, 30 Apr 2013 12:25:04 +0100
Subject: [PATCH 1/3] ARM: mcpm: Add explicit AFLAGS to support v6/v7
 multiplatform kernels

The full mcpm layer is not likely to be relevant to v6 based platforms,
so a multiplatform kernel won't use that code if booted on v6 hardware.

This patch modifies the AFLAGS for affected mcpm .S files to specify
armv7-a explicitly for that code.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
 arch/arm/common/Makefile |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index 546a932..d65a0a8 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -12,6 +12,8 @@ obj-$(CONFIG_SHARP_SCOOP)	+= scoop.o
 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)	+= timer-sp.o
 obj-$(CONFIG_MCPM)		+= mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
+AFLAGS_mcpm_head.o		:= -march=armv7-a
+AFLAGS_vlock.o			:= -march=armv7-a
 CFLAGS_REMOVE_mcpm_entry.o	= -pg
 obj-$(CONFIG_FIQ_GLUE)		+= fiq_glue.o fiq_glue_setup.o
 obj-$(CONFIG_FIQ_DEBUGGER)	+= fiq_debugger.o
-- 
1.7.9.5

Latest build results - errors/warnings - lots of them

[Arnd Bergmann]

On Tuesday 30 April 2013, Dave Martin wrote:
> From 193f254689beaa1612d29bcc5ba004a933b37d95 Mon Sep 17 00:00:00 2001
> From: Dave Martin <dave.martin@linaro.org>
> Date: Tue, 30 Apr 2013 12:25:04 +0100
> Subject: [PATCH 1/3] ARM: mcpm: Add explicit AFLAGS to support v6/v7
>  multiplatform kernels
> 
> The full mcpm layer is not likely to be relevant to v6 based platforms,
> so a multiplatform kernel won't use that code if booted on v6 hardware.
> 
> This patch modifies the AFLAGS for affected mcpm .S files to specify
> armv7-a explicitly for that code.
> 
> Signed-off-by: Dave Martin <dave.martin@linaro.org>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Latest build results - errors/warnings - lots of them

[Nicolas Pitre]

On Tue, 30 Apr 2013, Dave Martin wrote:

> On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > source of errors.
> 
> [...]
>  
> > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > 
> > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > We can either fix it up by adding
> > 
> > 	.arch	armv7-a
> > 
> > in the assembly files, or by doing the same in the Makefile:
> > 
> > AFLAGS_vlock.S += -march=armv7-a
> > AFLAGS_mcpm_head.S += -march=armv7-a
> 
> 
> Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> no v6 boards were configured in when testing that...
> 
> 
> Assuming people are OK with the Makefile route, here's a patch for that,
> build-tested with a v6+v7 ARCH_MULTIPLATFORM config.

Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
choice, although I don't feel strongly about it.


Nicolas

Latest build results - errors/warnings - lots of them

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [130430 04:10]:
> On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > source of errors.
> 
> Yes, I noticed this but haven't gotten around to prepare a patch. I'll comment
> below.
> 
> > OMAP stuff needs a serious look at too - much Kconfig madness there
> > caused by over-use of select, which then goes on to cause build errors
> > because it assumes some stuff is always enabled.

I have posted a few randconfig fixes in "[PATCH 0/3] few omap randconfig
fixes for v3.10" that also remove the select of SERIAL_OMAP that I missed
while fixing the 8250 issue. I was planning to send a pull request after
the merge window, but can do it now too if people prefer that.
 
> Ack. I have not looked much at randconfig output, but this has certianly
> grown worse after CONFIG_ARCH_OMAP has gotten included in ARCH_MULTIPLATFORM

I have a patch coming for the "no SoC selected" randconfig issue as
discussed in the "linux-next ARM multi-platform randconfig errors"
thread. I suggest we do the minimal fix I already posted for now,
then reorganize more of the Makefile as Arnd suggested for v3.11.

Regards,

Tony

Latest build results - errors/warnings - lots of them

[Dave Martin]

On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
> On Tue, 30 Apr 2013, Dave Martin wrote:
> 
> > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > > source of errors.
> > 
> > [...]
> >  
> > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > > 
> > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > > We can either fix it up by adding
> > > 
> > > 	.arch	armv7-a
> > > 
> > > in the assembly files, or by doing the same in the Makefile:
> > > 
> > > AFLAGS_vlock.S += -march=armv7-a
> > > AFLAGS_mcpm_head.S += -march=armv7-a
> > 
> > 
> > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> > no v6 boards were configured in when testing that...
> > 
> > 
> > Assuming people are OK with the Makefile route, here's a patch for that,
> > build-tested with a v6+v7 ARCH_MULTIPLATFORM config.
> 
> Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
> choice, although I don't feel strongly about it.

I don't feel strongly either.  We already have the CFLAGS_DISABLE stuff,
so it didn't feel that unnatural to add this in the Makefile; but .arch
would work equally well.

If somebody wants to change it, it's not a problem for me, but I didn't
want to create extra disruption by proposing a different patch...

Cheers
---Dave

Latest build results - errors/warnings - lots of them

[Nicolas Pitre]

On Tue, 30 Apr 2013, Dave Martin wrote:

> On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
> > On Tue, 30 Apr 2013, Dave Martin wrote:
> > 
> > > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > > > source of errors.
> > > 
> > > [...]
> > >  
> > > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > > > 
> > > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > > > We can either fix it up by adding
> > > > 
> > > > 	.arch	armv7-a
> > > > 
> > > > in the assembly files, or by doing the same in the Makefile:
> > > > 
> > > > AFLAGS_vlock.S += -march=armv7-a
> > > > AFLAGS_mcpm_head.S += -march=armv7-a
> > > 
> > > 
> > > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> > > no v6 boards were configured in when testing that...
> > > 
> > > 
> > > Assuming people are OK with the Makefile route, here's a patch for that,
> > > build-tested with a v6+v7 ARCH_MULTIPLATFORM config.
> > 
> > Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
> > choice, although I don't feel strongly about it.
> 
> I don't feel strongly either.  We already have the CFLAGS_DISABLE stuff,
> so it didn't feel that unnatural to add this in the Makefile; but .arch
> would work equally well.
> 
> If somebody wants to change it, it's not a problem for me, but I didn't
> want to create extra disruption by proposing a different patch...

Fair enough.

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



> 
> Cheers
> ---Dave
> 

Latest build results - errors/warnings - lots of them

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [130430 09:19]:
> * Arnd Bergmann <arnd@arndb.de> [130430 04:10]:
> > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > source of errors.
> > 
> > Yes, I noticed this but haven't gotten around to prepare a patch. I'll comment
> > below.
> > 
> > > OMAP stuff needs a serious look at too - much Kconfig madness there
> > > caused by over-use of select, which then goes on to cause build errors
> > > because it assumes some stuff is always enabled.
> 
> I have posted a few randconfig fixes in "[PATCH 0/3] few omap randconfig
> fixes for v3.10" that also remove the select of SERIAL_OMAP that I missed
> while fixing the 8250 issue. I was planning to send a pull request after
> the merge window, but can do it now too if people prefer that.

I'll apply only the SERIAL_OMAP fix into omap-for-v3.10/fixes-randconfig
against v3.9-rc7 as the two other warning fixes depend on other branches
and can be merged after -rc1.
  
> > Ack. I have not looked much at randconfig output, but this has certianly
> > grown worse after CONFIG_ARCH_OMAP has gotten included in ARCH_MULTIPLATFORM
> 
> I have a patch coming for the "no SoC selected" randconfig issue as
> discussed in the "linux-next ARM multi-platform randconfig errors"
> thread. I suggest we do the minimal fix I already posted for now,
> then reorganize more of the Makefile as Arnd suggested for v3.11.

Got the fix for "no SoC selected" boiled down to a minimal Makefile only
fix as Arnd suggested, will post shortly.

Regards,

Tony

Latest build results - errors/warnings - lots of them

[Arnd Bergmann]

On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> source of errors.
> 
> OMAP stuff needs a serious look at too - much Kconfig madness there
> caused by over-use of select, which then goes on to cause build errors
> because it assumes some stuff is always enabled.
> 
> There's also warnings about of_device_id from include/linux/of_platform.h
> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> too which need addressing.
> 
> See todays http://www.arm.linux.org.uk/developer/build/ results for all
> the details and configs.  Not pushing my tree until some of this stuff
> gets fixed.

A couple hundred kernel builds and 50 patches later, I actually managed to
get a reliably building randconfig.  There are no proper changeset
comments yet, and no Signed-off-by.

I've uploaded this to the test-merge-20130430 branch in the arm-soc
tree if anyone is curious. I suppose we should get all the changes
in arch/arm included in the merge window and then work with the
subsystem maintainers on the other bugs.

	Arnd

---
 arch/Kconfig                                  |   1 +
 arch/arm/Kconfig                              |   4 +-
 arch/arm/boot/compressed/Makefile             |   2 +-
 arch/arm/boot/compressed/head-sa1100.S        |   1 +
 arch/arm/boot/compressed/head-shark.S         |   1 +
 arch/arm/boot/compressed/head.S               |  13 +--
 arch/arm/configs/omap2plus_defconfig          |   6 +-
 arch/arm/kernel/psci_smp.c                    |   4 +-
 arch/arm/kvm/Kconfig                          |  26 ++---
 arch/arm/mach-imx/headsmp.S                   |   2 +-
 arch/arm/mach-imx/src.c                       |   3 +-
 arch/arm/mach-omap2/Kconfig                   | 133 +++++++++++++-------------
 arch/arm/mach-omap2/Makefile                  |   8 +-
 arch/arm/mach-prima2/Kconfig                  |   2 +-
 arch/arm/mach-spear/Makefile                  |   6 +-
 arch/arm/mach-spear/spear13xx.c               |   2 +
 arch/arm/mach-tegra/Kconfig                   |   5 +-
 arch/arm/mach-ux500/Kconfig                   |   2 +
 crypto/Kconfig                                |   2 +
 drivers/cpufreq/Kconfig.arm                   |   1 +
 drivers/cpuidle/Kconfig                       |   1 +
 drivers/gpu/drm/tilcdc/Kconfig                |   1 +
 drivers/gpu/host1x/drm/Kconfig                |   1 +
 drivers/media/platform/Kconfig                |   1 +
 drivers/media/platform/davinci/Kconfig        |   3 +
 drivers/media/radio/Kconfig                   |   1 +
 drivers/mfd/Kconfig                           |   2 +-
 drivers/net/can/Kconfig                       |   6 +-
 drivers/net/ethernet/mellanox/mlx4/en_clock.c |   2 +-
 drivers/net/wireless/iwlegacy/common.h        |   2 +-
 drivers/staging/android/logger.c              |   4 +-
 drivers/staging/android/logger.h              |   2 +-
 drivers/staging/imx-drm/Kconfig               |   4 +
 drivers/staging/media/solo6x10/Kconfig        |   1 +
 drivers/usb/host/Kconfig                      |  76 ++++++++++++---
 drivers/usb/host/Makefile                     |   4 +-
 drivers/usb/host/ehci-hcd.c                   |  17 ----
 drivers/usb/host/ohci-hcd.c                   |  19 ----
 drivers/usb/host/uhci-hcd.c                   |   4 +-
 drivers/usb/storage/realtek_cr.c              |   3 -
 drivers/video/console/Makefile                |   2 +
 drivers/video/omap2/dss/Kconfig               |   1 +
 drivers/xen/Kconfig                           |   2 +-
 include/drm/drmP.h                            |   3 +-
 include/linux/cpu_cooling.h                   |   2 +-
 45 files changed, 207 insertions(+), 181 deletions(-)

Latest build results - errors/warnings - lots of them

[Tony Lindgren]

* Arnd Bergmann <arnd@arndb.de> [130430 16:16]:
> 
> I've uploaded this to the test-merge-20130430 branch in the arm-soc
> tree if anyone is curious. I suppose we should get all the changes
> in arch/arm included in the merge window and then work with the
> subsystem maintainers on the other bugs.

>  arch/arm/mach-omap2/Kconfig                   | 133 +++++++++++++-------------
>  arch/arm/mach-omap2/Makefile                  |   8 +-

Nice, I like your changes to flip ARCH_OMAP2PLUS to be selected
by the SoC. That's a better way to fix things than just tinkering
with the Makefile like I posted earlier today.

Now you have SOC_OMAP5 selected twice in omap2plus_defconfig though,
which causes:

.config:283:warning: override: reassigning to symbol SOC_OMAP5

For the SERIAL_OMAP change, let's just use my earlier patch
"ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP".
We should not select optional drivers at all in Kconfig.

Regards,

Tony

Latest build results - errors/warnings - lots of them

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [130430 16:57]:
> * Arnd Bergmann <arnd@arndb.de> [130430 16:16]:
> > 
> > I've uploaded this to the test-merge-20130430 branch in the arm-soc
> > tree if anyone is curious. I suppose we should get all the changes
> > in arch/arm included in the merge window and then work with the
> > subsystem maintainers on the other bugs.
> 
> >  arch/arm/mach-omap2/Kconfig                   | 133 +++++++++++++-------------
> >  arch/arm/mach-omap2/Makefile                  |   8 +-
> 
> Nice, I like your changes to flip ARCH_OMAP2PLUS to be selected
> by the SoC. That's a better way to fix things than just tinkering
> with the Makefile like I posted earlier today.
> 
> Now you have SOC_OMAP5 selected twice in omap2plus_defconfig though,
> which causes:
> 
> .config:283:warning: override: reassigning to symbol SOC_OMAP5
> 
> For the SERIAL_OMAP change, let's just use my earlier patch
> "ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP".
> We should not select optional drivers at all in Kconfig.

And looks like also the following should be folded in to allow building
ARCH_OMAP2. Other than that your branch seems to build & boot
fine on omaps.

Regards,

Tony


--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -21,6 +21,7 @@ CONFIG_MODVERSIONS=y
 CONFIG_MODULE_SRCVERSION_ALL=y
 # CONFIG_BLK_DEV_BSG is not set
 CONFIG_ARCH_OMAP2=y
+CONFIG_ARCH_MULTI_V6=y
 CONFIG_ARCH_OMAP3=y
 CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y

Latest build results - errors/warnings - lots of them

[Shawn Guo]

On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> >arch/arm/mach-imx/hotplug.c: In function 'imx_cpu_die':
> >arch/arm/mach-imx/hotplug.c:53:2: error: implicit declaration of function 'cpu_do_idle'
> >arch/arm/mach-imx/hotplug.c: In function 'imx_cpu_kill':
> >arch/arm/mach-imx/hotplug.c:58:26: error: 'jiffies' undeclared (first use in this function)
> >arch/arm/mach-imx/hotplug.c:58:2: error: implicit declaration of function 'msecs_to_jiffies'
> >arch/arm/mach-imx/hotplug.c:61:3: error: implicit declaration of function 'time_after'

...

> >In file included from arch/arm/mach-imx/hotplug.c:16:0:
> >arch/arm/mach-imx/common.h:100:29: warning: 'struct pt_regs' declared inside parameter list
> >arch/arm/mach-imx/common.h:100:29: warning: its scope is only this definition or declaration, which is probably not what you want
> >arch/arm/mach-imx/common.h:101:29: warning: 'struct pt_regs' declared inside parameter list

I just send a patch [1] to fix these.

Shawn

[1] http://www.spinics.net/lists/arm-kernel/msg241316.html

Latest build results - errors/warnings - lots of them

[Russell King - ARM Linux]

On Tue, Apr 30, 2013 at 09:17:39AM +0100, Russell King - ARM Linux wrote:
> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> source of errors.
> 
> OMAP stuff needs a serious look at too - much Kconfig madness there
> caused by over-use of select, which then goes on to cause build errors
> because it assumes some stuff is always enabled.
> 
> There's also warnings about of_device_id from include/linux/of_platform.h
> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> too which need addressing.
> 
> See todays http://www.arm.linux.org.uk/developer/build/ results for all
> the details and configs.  Not pushing my tree until some of this stuff
> gets fixed.

And now we have a new bunch of warnings from OMAP stuff which weren't
previously there...

arch/arm/mach-omap2/omap_device.c: In function 'omap_device_get_by_hwmod_name':
arch/arm/mach-omap2/omap_device.c:821:3: warning: return makes pointer from integer without a cast
arch/arm/mach-omap2/omap_device.c:826:3: warning: return makes pointer from integer without a cast
drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result

include/linux/thermal.h:254:12: warning: 'thermal_generate_netlink_event' defined but not used

Latest build results - errors/warnings - lots of them

[Russell King - ARM Linux]

On Tue, Apr 30, 2013 at 02:18:42PM -0400, Nicolas Pitre wrote:
> On Tue, 30 Apr 2013, Dave Martin wrote:
> 
> > On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
> > > On Tue, 30 Apr 2013, Dave Martin wrote:
> > > 
> > > > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > > > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > > > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > > > > source of errors.
> > > > 
> > > > [...]
> > > >  
> > > > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > > > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > > > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > > > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > > > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > > > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > > > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > > > > 
> > > > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > > > > We can either fix it up by adding
> > > > > 
> > > > > 	.arch	armv7-a
> > > > > 
> > > > > in the assembly files, or by doing the same in the Makefile:
> > > > > 
> > > > > AFLAGS_vlock.S += -march=armv7-a
> > > > > AFLAGS_mcpm_head.S += -march=armv7-a
> > > > 
> > > > 
> > > > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> > > > no v6 boards were configured in when testing that...
> > > > 
> > > > 
> > > > Assuming people are OK with the Makefile route, here's a patch for that,
> > > > build-tested with a v6+v7 ARCH_MULTIPLATFORM config.
> > > 
> > > Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
> > > choice, although I don't feel strongly about it.
> > 
> > I don't feel strongly either.  We already have the CFLAGS_DISABLE stuff,
> > so it didn't feel that unnatural to add this in the Makefile; but .arch
> > would work equally well.
> > 
> > If somebody wants to change it, it's not a problem for me, but I didn't
> > want to create extra disruption by proposing a different patch...
> 
> Fair enough.
> 
> Acked-by: Nicolas Pitre <nico@linaro.org>

I see Dave Martin has sent a patch for this without your ack.  Was that
a mistake?

Latest build results - errors/warnings - lots of them

[Russell King - ARM Linux]

On Thu, May 02, 2013 at 09:34:30AM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 30, 2013 at 02:18:42PM -0400, Nicolas Pitre wrote:
> > On Tue, 30 Apr 2013, Dave Martin wrote:
> > 
> > > On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
> > > > On Tue, 30 Apr 2013, Dave Martin wrote:
> > > > 
> > > > > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > > > > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > > > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > > > > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > > > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > > > > > source of errors.
> > > > > 
> > > > > [...]
> > > > >  
> > > > > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > > > > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > > > > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > > > > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > > > > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > > > > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > > > > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > > > > > 
> > > > > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > > > > > We can either fix it up by adding
> > > > > > 
> > > > > > 	.arch	armv7-a
> > > > > > 
> > > > > > in the assembly files, or by doing the same in the Makefile:
> > > > > > 
> > > > > > AFLAGS_vlock.S += -march=armv7-a
> > > > > > AFLAGS_mcpm_head.S += -march=armv7-a
> > > > > 
> > > > > 
> > > > > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> > > > > no v6 boards were configured in when testing that...
> > > > > 
> > > > > 
> > > > > Assuming people are OK with the Makefile route, here's a patch for that,
> > > > > build-tested with a v6+v7 ARCH_MULTIPLATFORM config.
> > > > 
> > > > Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
> > > > choice, although I don't feel strongly about it.
> > > 
> > > I don't feel strongly either.  We already have the CFLAGS_DISABLE stuff,
> > > so it didn't feel that unnatural to add this in the Makefile; but .arch
> > > would work equally well.
> > > 
> > > If somebody wants to change it, it's not a problem for me, but I didn't
> > > want to create extra disruption by proposing a different patch...
> > 
> > Fair enough.
> > 
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> 
> I see Dave Martin has sent a patch for this without your ack.  Was that
> a mistake?

... and the patch in the patch system doesn't apply anyway because its
against some other tree.  I've no idea what it's against, it's not as
the version on the patch advertises (v3.9-rc7) and not even the build
tree has the three additional FIQ lines at the end (so it's not in
arm-soc):

 obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
 obj-$(CONFIG_ARM_TIMER_SP804)  += timer-sp.o
 obj-$(CONFIG_MCPM)             += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock...
+AFLAGS_mcpm_head.o             := -march=armv7-a
+AFLAGS_vlock.o                 := -march=armv7-a
 CFLAGS_REMOVE_mcpm_entry.o     = -pg
 obj-$(CONFIG_FIQ_GLUE)         += fiq_glue.o fiq_glue_setup.o
 obj-$(CONFIG_FIQ_DEBUGGER)     += fiq_debugger.o

So, this is unapplyable.

Latest build results - errors/warnings - lots of them

[Dave Martin]

On Thu, May 02, 2013 at 10:46:21AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 02, 2013 at 09:34:30AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Apr 30, 2013 at 02:18:42PM -0400, Nicolas Pitre wrote:
> > > On Tue, 30 Apr 2013, Dave Martin wrote:
> > > 
> > > > On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
> > > > > On Tue, 30 Apr 2013, Dave Martin wrote:
> > > > > 
> > > > > > On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
> > > > > > > On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
> > > > > > > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > > > > > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > > > > > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > > > > > > source of errors.
> > > > > > 
> > > > > > [...]
> > > > > >  
> > > > > > > >arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8'
> > > > > > > >arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8'
> > > > > > > >arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb'
> > > > > > > >arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb'
> > > > > > > >arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb'
> > > > > > > >arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb'
> > > > > > > >arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb'
> > > > > > > 
> > > > > > > Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config.
> > > > > > > We can either fix it up by adding
> > > > > > > 
> > > > > > > 	.arch	armv7-a
> > > > > > > 
> > > > > > > in the assembly files, or by doing the same in the Makefile:
> > > > > > > 
> > > > > > > AFLAGS_vlock.S += -march=armv7-a
> > > > > > > AFLAGS_mcpm_head.S += -march=armv7-a
> > > > > > 
> > > > > > 
> > > > > > Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like
> > > > > > no v6 boards were configured in when testing that...
> > > > > > 
> > > > > > 
> > > > > > Assuming people are OK with the Makefile route, here's a patch for that,
> > > > > > build-tested with a v6+v7 ARCH_MULTIPLATFORM config.
> > > > > 
> > > > > Isn't the .arch armv7-a route a bit cleaner?  That would have been my 
> > > > > choice, although I don't feel strongly about it.
> > > > 
> > > > I don't feel strongly either.  We already have the CFLAGS_DISABLE stuff,
> > > > so it didn't feel that unnatural to add this in the Makefile; but .arch
> > > > would work equally well.
> > > > 
> > > > If somebody wants to change it, it's not a problem for me, but I didn't
> > > > want to create extra disruption by proposing a different patch...
> > > 
> > > Fair enough.
> > > 
> > > Acked-by: Nicolas Pitre <nico@linaro.org>
> > 
> > I see Dave Martin has sent a patch for this without your ack.  Was that
> > a mistake?

My bad -- Nico asked me to send you the patch, but I neglected to add
his ack.
 
> ... and the patch in the patch system doesn't apply anyway because its
> against some other tree.  I've no idea what it's against, it's not as
> the version on the patch advertises (v3.9-rc7) and not even the build
> tree has the three additional FIQ lines at the end (so it's not in
> arm-soc):
> 
>  obj-$(CONFIG_PCI_HOST_ITE8152)  += it8152.o
>  obj-$(CONFIG_ARM_TIMER_SP804)  += timer-sp.o
>  obj-$(CONFIG_MCPM)             += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock...
> +AFLAGS_mcpm_head.o             := -march=armv7-a
> +AFLAGS_vlock.o                 := -march=armv7-a
>  CFLAGS_REMOVE_mcpm_entry.o     = -pg
>  obj-$(CONFIG_FIQ_GLUE)         += fiq_glue.o fiq_glue_setup.o
>  obj-$(CONFIG_FIQ_DEBUGGER)     += fiq_debugger.o
> 
> So, this is unapplyable.

...and this was a plain screwup up my part.  v3.9* could not possibly
contain the relevant patches, but somehow I convinced myself I had test-
applied the patch on 3.9-rc7, instead of a local tree based on that.

I've sent you a patch based on devel-stable which should apply.

Apologies for the churn.

Cheers
---Dave

Latest build results - errors/warnings - lots of them

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [130502 01:27]:
> On Tue, Apr 30, 2013 at 09:17:39AM +0100, Russell King - ARM Linux wrote:
> > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > source of errors.
> > 
> > OMAP stuff needs a serious look at too - much Kconfig madness there
> > caused by over-use of select, which then goes on to cause build errors
> > because it assumes some stuff is always enabled.
> > 
> > There's also warnings about of_device_id from include/linux/of_platform.h
> > via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> > too which need addressing.
> > 
> > See todays http://www.arm.linux.org.uk/developer/build/ results for all
> > the details and configs.  Not pushing my tree until some of this stuff
> > gets fixed.
> 
> And now we have a new bunch of warnings from OMAP stuff which weren't
> previously there...
> 
> arch/arm/mach-omap2/omap_device.c: In function 'omap_device_get_by_hwmod_name':
> arch/arm/mach-omap2/omap_device.c:821:3: warning: return makes pointer from integer without a cast
> arch/arm/mach-omap2/omap_device.c:826:3: warning: return makes pointer from integer without a cast

Hmm these I already fixed earlier along with a merge resolution, and
I'm not seeing them in next/master or arm-soc/for-next. What do you
have merged into your current tree?

> drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
> drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result

Neil, care to provide a fix for this? It's from your commit ab37813
(twl4030_charger: Allow charger to control the regulator that feeds it).

> include/linux/thermal.h:254:12: warning: 'thermal_generate_netlink_event' defined but not used

Eduardo, can you fix that one? It seems to be from your commit 8ab3e6a
(thermal: Use thermal zone device id in netlink messages).

Regards,

Tony

Latest build results - errors/warnings - lots of them

[Eduardo Valentin]

Arnd, Tony,

On 02-05-2013 11:38, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [130502 01:27]:
>> On Tue, Apr 30, 2013 at 09:17:39AM +0100, Russell King - ARM Linux wrote:
>>> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
>>> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
>>> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
>>> source of errors.
>>>
>>> OMAP stuff needs a serious look at too - much Kconfig madness there
>>> caused by over-use of select, which then goes on to cause build errors
>>> because it assumes some stuff is always enabled.
>>>
>>> There's also warnings about of_device_id from include/linux/of_platform.h
>>> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
>>> too which need addressing.
>>>
>>> See todays http://www.arm.linux.org.uk/developer/build/ results for all
>>> the details and configs.  Not pushing my tree until some of this stuff
>>> gets fixed.
>>
>> And now we have a new bunch of warnings from OMAP stuff which weren't
>> previously there...
>>
>> arch/arm/mach-omap2/omap_device.c: In function 'omap_device_get_by_hwmod_name':
>> arch/arm/mach-omap2/omap_device.c:821:3: warning: return makes pointer from integer without a cast
>> arch/arm/mach-omap2/omap_device.c:826:3: warning: return makes pointer from integer without a cast
> 
> Hmm these I already fixed earlier along with a merge resolution, and
> I'm not seeing them in next/master or arm-soc/for-next. What do you
> have merged into your current tree?
> 
>> drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
>> drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result
> 
> Neil, care to provide a fix for this? It's from your commit ab37813
> (twl4030_charger: Allow charger to control the regulator that feeds it).
> 
>> include/linux/thermal.h:254:12: warning: 'thermal_generate_netlink_event' defined but not used
> 
> Eduardo, can you fix that one? It seems to be from your commit 8ab3e6a
> (thermal: Use thermal zone device id in netlink messages).

Yeah sure I can fix it. As simple as the following:
>From c04244c87312f5bfc61d9e12ba3fbaa0fdd81adb Mon Sep 17 00:00:00 2001
From: Eduardo Valentin <eduardo.valentin@ti.com>
Date: Thu, 2 May 2013 12:58:20 -0400
Subject: [PATCH 1/1] thermal: remove stub for thermal_generate_netlink_event

This patch removes the stub for thermal_generate_netlink_event
because this function is not used anywhere inside the kernel.

In case CONFIG_NET is not set we get:
include/linux/thermal.h:254:12: warning:
'thermal_generate_netlink_event' defined but not used

Thus removing it.

Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
---
 include/linux/thermal.h | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index e3c0ae9..e3f3cba 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -250,12 +250,6 @@ void thermal_unregister_governor(struct
thermal_governor *);
 #ifdef CONFIG_NET
 extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
 						enum events event);
-#else
-static int thermal_generate_netlink_event(struct thermal_zone_device *tz,
-						enum events event)
-{
-	return 0;
-}
 #endif

 #endif /* __THERMAL_H__ */
-- 
1.8.2.1.342.gfa7285d

However,...

Rui, Durga,

 That function was used in the previous thermal  layer design. Now the
notification is done via sysfs, not netlink. The netlink interface needs
to be flagged as DEPRECATED and then we would remove it.

In any case, the above function is used by no one within the kernel:
$ git grep thermal_generate_netlink_event
Documentation/thermal/sysfs-api.txt:just need to call
thermal_generate_netlink_event() with two arguments viz
drivers/thermal/thermal_core.c:int thermal_generate_netlink_event(struct
thermal_zone_device *tz,
drivers/thermal/thermal_core.c:EXPORT_SYMBOL_GPL(thermal_generate_netlink_event);
include/linux/thermal.h:extern int thermal_generate_netlink_event(struct
thermal_zone_device *tz,
include/linux/thermal.h:static inline int
thermal_generate_netlink_event(struct thermal_zone_device *tz,


For that reason, I d propose to simply remove it, as I do not have any
user space application that uses that net link interface. But that needs
a confirmation from the Intel folks.

Rui, Durga? Last merge window we discussed to remove this API, do you
guys have dependency on this one still?


Cheers,

> 
> Regards,
> 
> Tony
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130502/32cdf421/attachment-0001.sig>

Latest build results - errors/warnings - lots of them

[Arnd Bergmann]

On Thursday 02 May 2013, Eduardo Valentin wrote:
> index e3c0ae9..e3f3cba 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -250,12 +250,6 @@ void thermal_unregister_governor(struct
> thermal_governor *);
>  #ifdef CONFIG_NET
>  extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>                                                 enum events event);
> -#else
> -static int thermal_generate_netlink_event(struct thermal_zone_device *tz,
> -                                               enum events event)
> -{
> -       return 0;
> -}
>  #endif

Actually it seems this bug is already fixed in linux-next:

commit f8b587055a793c7719f0d4f41b7b4aeeef43aa2d
Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date:   Wed Mar 20 21:38:07 2013 +0000

    thermal: Fix compiler warning
    
    The following warning is obtained when CONFIG_NET is not defined:
    
    In file included from drivers/thermal/mvebu_thermal.c:27:0:
    include/linux/thermal.h:254:12: warning: 'thermal_generate_netlink_event'
    defined but not used [-Wunused-function]
    
    This patch fixes the warning by properly inlining
    thermal_generate_netlink_event().
    
    Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
    Signed-off-by: Zhang Rui <rui.zhang@intel.com>

diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index f0bd7f9..fd7b8f3 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -251,7 +251,7 @@ void thermal_unregister_governor(struct thermal_governor *);
 extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
                                                enum events event);
 #else
-static int thermal_generate_netlink_event(struct thermal_zone_device *tz,
+static inline int thermal_generate_netlink_event(struct thermal_zone_device *tz,
                                                enum events event)
 {
        return 0;


Your patch also seems correct, but it would conflict with Ezequiel's.
The problem was apparently that you removed the 'inline' keyword
in 8ab3e6a08a "thermal: Use thermal zone device id in netlink messages",
I assume by accident, since defining a non-inline function in a header
file is obviously wrong.

	Arnd

Latest build results - errors/warnings - lots of them

[Felipe Balbi]

Hi,

On Thu, May 02, 2013 at 01:07:49PM -0400, Eduardo Valentin wrote:
> Arnd, Tony,
> 
> On 02-05-2013 11:38, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [130502 01:27]:
> >> On Tue, Apr 30, 2013 at 09:17:39AM +0100, Russell King - ARM Linux wrote:
> >>> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> >>> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> >>> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> >>> source of errors.
> >>>
> >>> OMAP stuff needs a serious look at too - much Kconfig madness there
> >>> caused by over-use of select, which then goes on to cause build errors
> >>> because it assumes some stuff is always enabled.
> >>>
> >>> There's also warnings about of_device_id from include/linux/of_platform.h
> >>> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> >>> too which need addressing.
> >>>
> >>> See todays http://www.arm.linux.org.uk/developer/build/ results for all
> >>> the details and configs.  Not pushing my tree until some of this stuff
> >>> gets fixed.
> >>
> >> And now we have a new bunch of warnings from OMAP stuff which weren't
> >> previously there...
> >>
> >> arch/arm/mach-omap2/omap_device.c: In function 'omap_device_get_by_hwmod_name':
> >> arch/arm/mach-omap2/omap_device.c:821:3: warning: return makes pointer from integer without a cast
> >> arch/arm/mach-omap2/omap_device.c:826:3: warning: return makes pointer from integer without a cast
> > 
> > Hmm these I already fixed earlier along with a merge resolution, and
> > I'm not seeing them in next/master or arm-soc/for-next. What do you
> > have merged into your current tree?
> > 
> >> drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
> >> drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result
> > 
> > Neil, care to provide a fix for this? It's from your commit ab37813
> > (twl4030_charger: Allow charger to control the regulator that feeds it).
> > 
> >> include/linux/thermal.h:254:12: warning: 'thermal_generate_netlink_event' defined but not used
> > 
> > Eduardo, can you fix that one? It seems to be from your commit 8ab3e6a
> > (thermal: Use thermal zone device id in netlink messages).
> 
> Yeah sure I can fix it. As simple as the following:
> From c04244c87312f5bfc61d9e12ba3fbaa0fdd81adb Mon Sep 17 00:00:00 2001
> From: Eduardo Valentin <eduardo.valentin@ti.com>
> Date: Thu, 2 May 2013 12:58:20 -0400
> Subject: [PATCH 1/1] thermal: remove stub for thermal_generate_netlink_event
> 
> This patch removes the stub for thermal_generate_netlink_event
> because this function is not used anywhere inside the kernel.
> 
> In case CONFIG_NET is not set we get:
> include/linux/thermal.h:254:12: warning:
> 'thermal_generate_netlink_event' defined but not used
> 
> Thus removing it.
> 
> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> ---
>  include/linux/thermal.h | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index e3c0ae9..e3f3cba 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -250,12 +250,6 @@ void thermal_unregister_governor(struct
> thermal_governor *);
>  #ifdef CONFIG_NET
>  extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>  						enum events event);
> -#else
> -static int thermal_generate_netlink_event(struct thermal_zone_device *tz,

just adding 'inline' would be an easier patch and lets you compile fine
on !CONFIG_NET when you starting using thermal_generate_netlink_event().

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130502/024a20b2/attachment-0001.sig>

Latest build results - errors/warnings - lots of them

[Eduardo Valentin]

On 02-05-2013 14:03, Arnd Bergmann wrote:
> On Thursday 02 May 2013, Eduardo Valentin wrote:
>> index e3c0ae9..e3f3cba 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -250,12 +250,6 @@ void thermal_unregister_governor(struct
>> thermal_governor *);
>>  #ifdef CONFIG_NET
>>  extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>>                                                 enum events event);
>> -#else
>> -static int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>> -                                               enum events event)
>> -{
>> -       return 0;
>> -}
>>  #endif
> 
> Actually it seems this bug is already fixed in linux-next:
> 
> commit f8b587055a793c7719f0d4f41b7b4aeeef43aa2d
> Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Date:   Wed Mar 20 21:38:07 2013 +0000
> 
>     thermal: Fix compiler warning
>     
>     The following warning is obtained when CONFIG_NET is not defined:
>     
>     In file included from drivers/thermal/mvebu_thermal.c:27:0:
>     include/linux/thermal.h:254:12: warning: 'thermal_generate_netlink_event'
>     defined but not used [-Wunused-function]
>     
>     This patch fixes the warning by properly inlining
>     thermal_generate_netlink_event().
>     
>     Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
>     Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index f0bd7f9..fd7b8f3 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -251,7 +251,7 @@ void thermal_unregister_governor(struct thermal_governor *);
>  extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>                                                 enum events event);
>  #else
> -static int thermal_generate_netlink_event(struct thermal_zone_device *tz,
> +static inline int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>                                                 enum events event)
>  {
>         return 0;
> 
> 
> Your patch also seems correct, but it would conflict with Ezequiel's.
> The problem was apparently that you removed the 'inline' keyword
> in 8ab3e6a08a "thermal: Use thermal zone device id in netlink messages",
> I assume by accident, since defining a non-inline function in a header
> file is obviously wrong.

Yeah, that was my bad. I am fine with Ezequiel s patch.

Thanks.

> 
> 	Arnd
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130502/39ed3af9/attachment.sig>

Latest build results - errors/warnings - lots of them

[Eduardo Valentin]

On 02-05-2013 14:06, Felipe Balbi wrote:
> Hi,
> 
> On Thu, May 02, 2013 at 01:07:49PM -0400, Eduardo Valentin wrote:
>> Arnd, Tony,
>>
>> On 02-05-2013 11:38, Tony Lindgren wrote:
>>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [130502 01:27]:
>>>> On Tue, Apr 30, 2013 at 09:17:39AM +0100, Russell King - ARM Linux wrote:
>>>>> Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
>>>>> great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
>>>>> arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
>>>>> source of errors.
>>>>>
>>>>> OMAP stuff needs a serious look at too - much Kconfig madness there
>>>>> caused by over-use of select, which then goes on to cause build errors
>>>>> because it assumes some stuff is always enabled.
>>>>>
>>>>> There's also warnings about of_device_id from include/linux/of_platform.h
>>>>> via from arch/arm/kernel/setup.c which feature in all the non-OF builds
>>>>> too which need addressing.
>>>>>
>>>>> See todays http://www.arm.linux.org.uk/developer/build/ results for all
>>>>> the details and configs.  Not pushing my tree until some of this stuff
>>>>> gets fixed.
>>>>
>>>> And now we have a new bunch of warnings from OMAP stuff which weren't
>>>> previously there...
>>>>
>>>> arch/arm/mach-omap2/omap_device.c: In function 'omap_device_get_by_hwmod_name':
>>>> arch/arm/mach-omap2/omap_device.c:821:3: warning: return makes pointer from integer without a cast
>>>> arch/arm/mach-omap2/omap_device.c:826:3: warning: return makes pointer from integer without a cast
>>>
>>> Hmm these I already fixed earlier along with a merge resolution, and
>>> I'm not seeing them in next/master or arm-soc/for-next. What do you
>>> have merged into your current tree?
>>>
>>>> drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
>>>> drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result
>>>
>>> Neil, care to provide a fix for this? It's from your commit ab37813
>>> (twl4030_charger: Allow charger to control the regulator that feeds it).
>>>
>>>> include/linux/thermal.h:254:12: warning: 'thermal_generate_netlink_event' defined but not used
>>>
>>> Eduardo, can you fix that one? It seems to be from your commit 8ab3e6a
>>> (thermal: Use thermal zone device id in netlink messages).
>>
>> Yeah sure I can fix it. As simple as the following:
>> From c04244c87312f5bfc61d9e12ba3fbaa0fdd81adb Mon Sep 17 00:00:00 2001
>> From: Eduardo Valentin <eduardo.valentin@ti.com>
>> Date: Thu, 2 May 2013 12:58:20 -0400
>> Subject: [PATCH 1/1] thermal: remove stub for thermal_generate_netlink_event
>>
>> This patch removes the stub for thermal_generate_netlink_event
>> because this function is not used anywhere inside the kernel.
>>
>> In case CONFIG_NET is not set we get:
>> include/linux/thermal.h:254:12: warning:
>> 'thermal_generate_netlink_event' defined but not used
>>
>> Thus removing it.
>>
>> Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
>> ---
>>  include/linux/thermal.h | 6 ------
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
>> index e3c0ae9..e3f3cba 100644
>> --- a/include/linux/thermal.h
>> +++ b/include/linux/thermal.h
>> @@ -250,12 +250,6 @@ void thermal_unregister_governor(struct
>> thermal_governor *);
>>  #ifdef CONFIG_NET
>>  extern int thermal_generate_netlink_event(struct thermal_zone_device *tz,
>>  						enum events event);
>> -#else
>> -static int thermal_generate_netlink_event(struct thermal_zone_device *tz,
> 
> just adding 'inline' would be an easier patch and lets you compile fine
> on !CONFIG_NET when you starting using thermal_generate_netlink_event().
> 

Yeah, that is one thing. But as I pointed, the fix is actually to remove
the whole netlink thing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130502/e79404d7/attachment.sig>

Latest build results - errors/warnings - lots of them

[Russell King - ARM Linux]

On Thu, May 02, 2013 at 08:38:34AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [130502 01:27]:
> > On Tue, Apr 30, 2013 at 09:17:39AM +0100, Russell King - ARM Linux wrote:
> > > Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
> > > great load of new warnings and errors.  arch/arm/common/mcpm_head.S,
> > > arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest
> > > source of errors.
> > > 
> > > OMAP stuff needs a serious look at too - much Kconfig madness there
> > > caused by over-use of select, which then goes on to cause build errors
> > > because it assumes some stuff is always enabled.
> > > 
> > > There's also warnings about of_device_id from include/linux/of_platform.h
> > > via from arch/arm/kernel/setup.c which feature in all the non-OF builds
> > > too which need addressing.
> > > 
> > > See todays http://www.arm.linux.org.uk/developer/build/ results for all
> > > the details and configs.  Not pushing my tree until some of this stuff
> > > gets fixed.
> > 
> > And now we have a new bunch of warnings from OMAP stuff which weren't
> > previously there...
> > 
> > arch/arm/mach-omap2/omap_device.c: In function 'omap_device_get_by_hwmod_name':
> > arch/arm/mach-omap2/omap_device.c:821:3: warning: return makes pointer from integer without a cast
> > arch/arm/mach-omap2/omap_device.c:826:3: warning: return makes pointer from integer without a cast
> 
> Hmm these I already fixed earlier along with a merge resolution, and
> I'm not seeing them in next/master or arm-soc/for-next. What do you
> have merged into your current tree?

I just found the cause, and it's my cleanup branch.  Odd that it only
started appearing a couple of days ago.  Should now be fixed.

Latest build results - errors/warnings - lots of them

[NeilBrown]

On Thu, 2 May 2013 08:38:34 -0700 Tony Lindgren <tony@atomide.com> wrote:

> > drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
> > drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result
> 
> Neil, care to provide a fix for this? It's from your commit ab37813
> (twl4030_charger: Allow charger to control the regulator that feeds it).
> 
>
This the sort of thing that might be appropriate?

NeilBrown


From: NeilBrown <neilb@suse.de>
Date: Mon, 6 May 2013 12:35:59 +1000
Subject: [PATCH] twl4030_charger: don't ignore regulator_enable()

regulator_enable() doesn't like being ignored.  If it does fail there
is nothing we can do except not set usb_enabled (which is necessary
else a subsequent regulator_disable() will be unbalanced).

We cannot usefully return an error here as errors from
twl4030_charger_enable_usb() are ignored.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index bed4581..8b0ec70 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -189,8 +189,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci *bci, bool enable)
 
 		/* Need to keep regulator on */
 		if (!bci->usb_enabled) {
-			regulator_enable(bci->usb_reg);
-			bci->usb_enabled = 1;
+			if (regulator_enable(bci->usb_reg) == 0)
+				bci->usb_enabled = 1;
 		}
 
 		/* forcing the field BCIAUTOUSB (BOOT_BCI[1]) to 1 */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130506/119fb117/attachment.sig>

Latest build results - errors/warnings - lots of them

[Tony Lindgren]

* NeilBrown <neilb@suse.de> [130505 19:45]:
> On Thu, 2 May 2013 08:38:34 -0700 Tony Lindgren <tony@atomide.com> wrote:
> 
> > > drivers/power/twl4030_charger.c: In function 'twl4030_charger_enable_usb':
> > > drivers/power/twl4030_charger.c:192:20: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result
> > 
> > Neil, care to provide a fix for this? It's from your commit ab37813
> > (twl4030_charger: Allow charger to control the regulator that feeds it).
> > 
> >
> This the sort of thing that might be appropriate?

Thanks looks good to me. Care to send it to the appropriate
mailing lists and maintainers for drivers/power?

Regards,

Tony
 
> From: NeilBrown <neilb@suse.de>
> Date: Mon, 6 May 2013 12:35:59 +1000
> Subject: [PATCH] twl4030_charger: don't ignore regulator_enable()
> 
> regulator_enable() doesn't like being ignored.  If it does fail there
> is nothing we can do except not set usb_enabled (which is necessary
> else a subsequent regulator_disable() will be unbalanced).
> 
> We cannot usefully return an error here as errors from
> twl4030_charger_enable_usb() are ignored.
> 
> Signed-off-by: NeilBrown <neilb@suse.de>
> 
> diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
> index bed4581..8b0ec70 100644
> --- a/drivers/power/twl4030_charger.c
> +++ b/drivers/power/twl4030_charger.c
> @@ -189,8 +189,8 @@ static int twl4030_charger_enable_usb(struct twl4030_bci *bci, bool enable)
>  
>  		/* Need to keep regulator on */
>  		if (!bci->usb_enabled) {
> -			regulator_enable(bci->usb_reg);
> -			bci->usb_enabled = 1;
> +			if (regulator_enable(bci->usb_reg) == 0)
> +				bci->usb_enabled = 1;
>  		}
>  
>  		/* forcing the field BCIAUTOUSB (BOOT_BCI[1]) to 1 */