next-20151126 build: 3 failures 15 warnings (next-20151126)

next-20151126 build: 3 failures 15 warnings (next-20151126)

[Build bot for Mark Brown]

Tree/Branch: next-20151126
Git describe: next-20151126
Commit: 7dd2ecb6fa Add linux-next specific files for 20151126

Build Time: 64 min 1 sec

Passed:    6 / 9   ( 66.67 %)
Failed:    3 / 9   ( 33.33 %)

Errors: 7
Warnings: 15
Section Mismatches: 0

Failed defconfigs:
	arm64-allnoconfig
	arm64-allmodconfig
	arm-allmodconfig

Errors:

	arm64-allnoconfig
../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)

	arm64-allmodconfig
../drivers/net/ethernet/freescale/gianfar.c:650:33: error: 'NO_IRQ' undeclared (first use in this function)
../drivers/net/ethernet/freescale/gianfar_ptp.c:470:22: error: 'NO_IRQ' undeclared (first use in this function)
../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'

-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
      4 warnings    0 mismatches  : arm64-allmodconfig
      2 warnings    0 mismatches  : arm-multi_v5_defconfig
      7 warnings    0 mismatches  : arm-multi_v7_defconfig
      1 warnings    0 mismatches  : x86_64-defconfig
      5 warnings    0 mismatches  : arm-allmodconfig
      1 warnings    0 mismatches  : arm-allnoconfig

-------------------------------------------------------------------------------

Errors summary: 7
	  1 ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'
	  1 ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
	  1 ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
	  1 ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
	  1 ../drivers/net/ethernet/freescale/gianfar_ptp.c:470:22: error: 'NO_IRQ' undeclared (first use in this function)
	  1 ../drivers/net/ethernet/freescale/gianfar.c:650:33: error: 'NO_IRQ' undeclared (first use in this function)
	  1 ../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)

Warnings Summary: 15
	  6 <stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
	  1 ../sound/soc/sh/rcar/mix.c:127:13: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
	  1 ../sound/soc/sh/rcar/dvc.c:315:13: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
	  1 ../sound/soc/sh/rcar/ctu.c:88:13: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
	  1 ../net/bluetooth/mgmt.c:5470:8: warning: 'r192' may be used uninitialized in this function [-Wmaybe-uninitialized]
	  1 ../net/bluetooth/mgmt.c:5470:8: warning: 'h192' may be used uninitialized in this function [-Wmaybe-uninitialized]
	  1 ../mm/page_alloc.c:4185:16: warning: comparison between 'enum zone_type' and 'enum <anonymous>' [-Wenum-compare]
	  1 ../drivers/staging/emxx_udc/emxx_udc.c:843:45: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	  1 ../drivers/staging/emxx_udc/emxx_udc.c:2731:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	  1 ../drivers/staging/emxx_udc/emxx_udc.c:1085:45: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	  1 ../drivers/net/ethernet/qlogic/qed/qed_dev.c:1676:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
	  1 ../drivers/net/ethernet/freescale/fsl_pq_mdio.c:468:6: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long int' [-Wformat=]
	  1 ../drivers/gpu/drm/exynos/exynos5433_drm_decon.c:381:6: warning: unused variable 'i' [-Wunused-variable]
	  1 ../drivers/gpu/drm/exynos/exynos5433_drm_decon.c:380:6: warning: unused variable 'ret' [-Wunused-variable]
	  1 ../crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=]



===============================================================================
Detailed per-defconfig build reports below:


-------------------------------------------------------------------------------
arm64-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches

Errors:
	../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)

-------------------------------------------------------------------------------
arm64-allmodconfig : FAIL, 6 errors, 4 warnings, 0 section mismatches

Errors:
	../drivers/net/ethernet/freescale/gianfar.c:650:33: error: 'NO_IRQ' undeclared (first use in this function)
	../drivers/net/ethernet/freescale/gianfar_ptp.c:470:22: error: 'NO_IRQ' undeclared (first use in this function)
	../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
	../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
	../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
	../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'

Warnings:
	../drivers/net/ethernet/freescale/fsl_pq_mdio.c:468:6: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long int' [-Wformat=]
	../drivers/staging/emxx_udc/emxx_udc.c:843:45: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	../drivers/staging/emxx_udc/emxx_udc.c:1085:45: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	../drivers/staging/emxx_udc/emxx_udc.c:2731:6: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches

Warnings:
	<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
	<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]

-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 7 warnings, 0 section mismatches

Warnings:
	<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
	../net/bluetooth/mgmt.c:5470:8: warning: 'r192' may be used uninitialized in this function [-Wmaybe-uninitialized]
	../net/bluetooth/mgmt.c:5470:8: warning: 'h192' may be used uninitialized in this function [-Wmaybe-uninitialized]
	../sound/soc/sh/rcar/ctu.c:88:13: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
	../sound/soc/sh/rcar/mix.c:127:13: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
	../sound/soc/sh/rcar/dvc.c:315:13: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
	<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]

-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches

Warnings:
	../mm/page_alloc.c:4185:16: warning: comparison between 'enum zone_type' and 'enum <anonymous>' [-Wenum-compare]

-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 5 warnings, 0 section mismatches

Warnings:
	<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
	../crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than 1024 bytes [-Wframe-larger-than=]
	../drivers/gpu/drm/exynos/exynos5433_drm_decon.c:381:6: warning: unused variable 'i' [-Wunused-variable]
	../drivers/gpu/drm/exynos/exynos5433_drm_decon.c:380:6: warning: unused variable 'ret' [-Wunused-variable]
	../drivers/net/ethernet/qlogic/qed/qed_dev.c:1676:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]

-------------------------------------------------------------------------------
arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches

Warnings:
	<stdin>:1307:2: warning: #warning syscall copy_file_range not implemented [-Wcpp]
-------------------------------------------------------------------------------

Passed with no errors, warnings or mismatches:

x86_64-allnoconfig
arm64-defconfig

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allnoconfig due to:

> 	arm64-allnoconfig
> ../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)

which was introduced by a combination of 8f62c06c279a3 (mm: mmap: add
new /proc tunable for mmap_base ASLR) and 9411708692954 (arm64: mm:
support ARCH_MMAP_RND_BITS).  These add an unconditional use of
mmap_rnd_compat_bits which is only defined in linux/mmap.h if
HAVE_ARCH_MMAP_RND_COMPAT_BITS is selected but that is only enabled for
arm64 if COMPAT is enabled.  Either the select needs to be unconditional
or the use needs to be.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allnoconfig due to:

> 	arm64-allnoconfig
> ../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)

which was introduced by a combination of 8f62c06c279a3 (mm: mmap: add
new /proc tunable for mmap_base ASLR) and 9411708692954 (arm64: mm:
support ARCH_MMAP_RND_BITS).  These add an unconditional use of
mmap_rnd_compat_bits which is only defined in linux/mmap.h if
HAVE_ARCH_MMAP_RND_COMPAT_BITS is selected but that is only enabled for
arm64 if COMPAT is enabled.  Either the select needs to be unconditional
or the use needs to be.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151126/74d1d735/attachment.sig>

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 816 bytes --]

On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:

For the past couple of days an arm64 allmodconfig has been failing to
build due to:

> 	arm64-allmodconfig
> ../drivers/net/ethernet/freescale/gianfar.c:650:33: error: 'NO_IRQ' undeclared (first use in this function)
> ../drivers/net/ethernet/freescale/gianfar_ptp.c:470:22: error: 'NO_IRQ' undeclared (first use in this function)

introduced by fe761bcb9046029 (net: fsl: expands dependencies of
NET_VENDOR_FREESCALE) which enables build of the Freescale networking
drivers on arm64.  Since in common with many other architectures arm64
does not provide a NO_IRQ (and even those that do aren't consistent) the
driver should be modified to not rely on this and instead check the
return values of the functions it uses to look up interrupts.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

> 	arm64-allmodconfig
> ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
> ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
> ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
> ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'

This is happening because there are stub functions provided in the
driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef
not an #if and so fails to do the right thing if the thermal code is
built as a module.  It looks like this was somehow triggered as part of
the reorganisation of the WiFi directory structure.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 920 bytes --]

On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:

Today's -next fails to build an arm64 allmodconfig due to:

> 	arm64-allmodconfig
> ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
> ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
> ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
> ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'

This is happening because there are stub functions provided in the
driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef
not an #if and so fails to do the right thing if the thermal code is
built as a module.  It looks like this was somehow triggered as part of
the reorganisation of the WiFi directory structure.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
>> 	arm64-allmodconfig
>> ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'
>
> This is happening because there are stub functions provided in the
> driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef
> not an #if and so fails to do the right thing if the thermal code is
> built as a module.

Thanks, I'll apply the fix soon. Just wait for comments from others
first.

> It looks like this was somehow triggered as part of the reorganisation
> of the WiFi directory structure.

This is surprising and also worrying, any ideas why? It would be good to
understand the root cause in case there's a bug in wireless drivers
directory reorganisation.

-- 
Kalle Valo

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:

> On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
>> 	arm64-allmodconfig
>> ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'
>
> This is happening because there are stub functions provided in the
> driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef
> not an #if and so fails to do the right thing if the thermal code is
> built as a module.

Thanks, I'll apply the fix soon. Just wait for comments from others
first.

> It looks like this was somehow triggered as part of the reorganisation
> of the WiFi directory structure.

This is surprising and also worrying, any ideas why? It would be good to
understand the root cause in case there's a bug in wireless drivers
directory reorganisation.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:

> On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
>> 	arm64-allmodconfig
>> ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'
>
> This is happening because there are stub functions provided in the
> driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef
> not an #if and so fails to do the right thing if the thermal code is
> built as a module.

Thanks, I'll apply the fix soon. Just wait for comments from others
first.

> It looks like this was somehow triggered as part of the reorganisation
> of the WiFi directory structure.

This is surprising and also worrying, any ideas why? It would be good to
understand the root cause in case there's a bug in wireless drivers
directory reorganisation.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 09:06:25AM +0000, Build bot for Mark Brown wrote:
>
> Today's -next fails to build an arm64 allmodconfig due to:
>
>> 	arm64-allmodconfig
>> ../drivers/net/wireless/ath/ath10k/thermal.c:119:6: error: redefinition of 'ath10k_thermal_event_temperature'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:136:6: error: redefinition of 'ath10k_thermal_set_throttling'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:162:5: error: redefinition of 'ath10k_thermal_register'
>> ../drivers/net/wireless/ath/ath10k/thermal.c:216:6: error: redefinition of 'ath10k_thermal_unregister'
>
> This is happening because there are stub functions provided in the
> driver's thermal.h for !THERMAL cases but these are guarded by an #ifdef
> not an #if and so fails to do the right thing if the thermal code is
> built as a module.

Thanks, I'll apply the fix soon. Just wait for comments from others
first.

> It looks like this was somehow triggered as part of the reorganisation
> of the WiFi directory structure.

This is surprising and also worrying, any ideas why? It would be good to
understand the root cause in case there's a bug in wireless drivers
directory reorganisation.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On Thu, Nov 26, 2015 at 02:39:40PM +0200, Kalle Valo wrote:
> Mark Brown <broonie@kernel.org> writes:

> > It looks like this was somehow triggered as part of the reorganisation
> > of the WiFi directory structure.

> This is surprising and also worrying, any ideas why? It would be good to
> understand the root cause in case there's a bug in wireless drivers
> directory reorganisation.

No, I didn't make much effort to check though since the use of ifdef was
clearly a bug waiting to happen anyway, I was more surprised it worked
at all than anything.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 556 bytes --]

On Thu, Nov 26, 2015 at 02:39:40PM +0200, Kalle Valo wrote:
> Mark Brown <broonie@kernel.org> writes:

> > It looks like this was somehow triggered as part of the reorganisation
> > of the WiFi directory structure.

> This is surprising and also worrying, any ideas why? It would be good to
> understand the root cause in case there's a bug in wireless drivers
> directory reorganisation.

No, I didn't make much effort to check though since the use of ifdef was
clearly a bug waiting to happen anyway, I was more surprised it worked
at all than anything.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Catalin Marinas]

On Thu, Nov 26, 2015 at 11:32:13AM +0000, Mark Brown wrote:
> Today's -next fails to build an arm64 allnoconfig due to:
> 
> > 	arm64-allnoconfig
> > ../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)
> 
> which was introduced by a combination of 8f62c06c279a3 (mm: mmap: add
> new /proc tunable for mmap_base ASLR) and 9411708692954 (arm64: mm:
> support ARCH_MMAP_RND_BITS).  These add an unconditional use of
> mmap_rnd_compat_bits which is only defined in linux/mmap.h if
> HAVE_ARCH_MMAP_RND_COMPAT_BITS is selected but that is only enabled for
> arm64 if COMPAT is enabled.  Either the select needs to be unconditional
> or the use needs to be.

There are other problems with these patches for arm64, I already replied
here:

http://lkml.kernel.org/g/20151125120601.GC3109@e104818-lin.cambridge.arm.com

So I don't think they should be in -next.

-- 
Catalin

next-20151126 build: 3 failures 15 warnings (next-20151126)

[Catalin Marinas]

On Thu, Nov 26, 2015 at 11:32:13AM +0000, Mark Brown wrote:
> Today's -next fails to build an arm64 allnoconfig due to:
> 
> > 	arm64-allnoconfig
> > ../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)
> 
> which was introduced by a combination of 8f62c06c279a3 (mm: mmap: add
> new /proc tunable for mmap_base ASLR) and 9411708692954 (arm64: mm:
> support ARCH_MMAP_RND_BITS).  These add an unconditional use of
> mmap_rnd_compat_bits which is only defined in linux/mmap.h if
> HAVE_ARCH_MMAP_RND_COMPAT_BITS is selected but that is only enabled for
> arm64 if COMPAT is enabled.  Either the select needs to be unconditional
> or the use needs to be.

There are other problems with these patches for arm64, I already replied
here:

http://lkml.kernel.org/g/20151125120601.GC3109 at e104818-lin.cambridge.arm.com

So I don't think they should be in -next.

-- 
Catalin

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 02:39:40PM +0200, Kalle Valo wrote:
>> Mark Brown <broonie@kernel.org> writes:
>
>> > It looks like this was somehow triggered as part of the reorganisation
>> > of the WiFi directory structure.
>
>> This is surprising and also worrying, any ideas why? It would be good to
>> understand the root cause in case there's a bug in wireless drivers
>> directory reorganisation.
>
> No, I didn't make much effort to check though since the use of ifdef was
> clearly a bug waiting to happen anyway, I was more surprised it worked
> at all than anything.

Michal Marek explains[1] that this is due to commit cf4f21938e13
("kbuild: Allow to specify composite modules with modname-m") and has
nothing to do with the wireless drivers reorganisation. I'll drop this
patch as Michal will apply his fix to the kbuild tree.

[1] https://patchwork.kernel.org/patch/7707801/

-- 
Kalle Valo

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 02:39:40PM +0200, Kalle Valo wrote:
>> Mark Brown <broonie@kernel.org> writes:
>
>> > It looks like this was somehow triggered as part of the reorganisation
>> > of the WiFi directory structure.
>
>> This is surprising and also worrying, any ideas why? It would be good to
>> understand the root cause in case there's a bug in wireless drivers
>> directory reorganisation.
>
> No, I didn't make much effort to check though since the use of ifdef was
> clearly a bug waiting to happen anyway, I was more surprised it worked
> at all than anything.

Michal Marek explains[1] that this is due to commit cf4f21938e13
("kbuild: Allow to specify composite modules with modname-m") and has
nothing to do with the wireless drivers reorganisation. I'll drop this
patch as Michal will apply his fix to the kbuild tree.

[1] https://patchwork.kernel.org/patch/7707801/

-- 
Kalle Valo

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 02:39:40PM +0200, Kalle Valo wrote:
>> Mark Brown <broonie@kernel.org> writes:
>
>> > It looks like this was somehow triggered as part of the reorganisation
>> > of the WiFi directory structure.
>
>> This is surprising and also worrying, any ideas why? It would be good to
>> understand the root cause in case there's a bug in wireless drivers
>> directory reorganisation.
>
> No, I didn't make much effort to check though since the use of ifdef was
> clearly a bug waiting to happen anyway, I was more surprised it worked
> at all than anything.

Michal Marek explains[1] that this is due to commit cf4f21938e13
("kbuild: Allow to specify composite modules with modname-m") and has
nothing to do with the wireless drivers reorganisation. I'll drop this
patch as Michal will apply his fix to the kbuild tree.

[1] https://patchwork.kernel.org/patch/7707801/

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Thu, Nov 26, 2015 at 06:58:32PM +0200, Kalle Valo wrote:
> Mark Brown <broonie@kernel.org> writes:

> > No, I didn't make much effort to check though since the use of ifdef was
> > clearly a bug waiting to happen anyway, I was more surprised it worked
> > at all than anything.

> Michal Marek explains[1] that this is due to commit cf4f21938e13
> ("kbuild: Allow to specify composite modules with modname-m") and has
> nothing to do with the wireless drivers reorganisation. I'll drop this
> patch as Michal will apply his fix to the kbuild tree.

It still ought to be fixed regardless of why it showed up - the
intention of the code is that we build the real thermal code regardless
of if that's modular or not but that's not what the code actually does.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 760 bytes --]

On Thu, Nov 26, 2015 at 06:58:32PM +0200, Kalle Valo wrote:
> Mark Brown <broonie@kernel.org> writes:

> > No, I didn't make much effort to check though since the use of ifdef was
> > clearly a bug waiting to happen anyway, I was more surprised it worked
> > at all than anything.

> Michal Marek explains[1] that this is due to commit cf4f21938e13
> ("kbuild: Allow to specify composite modules with modname-m") and has
> nothing to do with the wireless drivers reorganisation. I'll drop this
> patch as Michal will apply his fix to the kbuild tree.

It still ought to be fixed regardless of why it showed up - the
intention of the code is that we build the real thermal code regardless
of if that's modular or not but that's not what the code actually does.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 06:58:32PM +0200, Kalle Valo wrote:
>> Mark Brown <broonie@kernel.org> writes:
>
>> > No, I didn't make much effort to check though since the use of ifdef was
>> > clearly a bug waiting to happen anyway, I was more surprised it worked
>> > at all than anything.
>
>> Michal Marek explains[1] that this is due to commit cf4f21938e13
>> ("kbuild: Allow to specify composite modules with modname-m") and has
>> nothing to do with the wireless drivers reorganisation. I'll drop this
>> patch as Michal will apply his fix to the kbuild tree.
>
> It still ought to be fixed regardless of why it showed up - the
> intention of the code is that we build the real thermal code regardless
> of if that's modular or not but that's not what the code actually does.

Like I said above Michal will apply a fix to his tree. Read the full
discussion from patchwork:

https://patchwork.kernel.org/patch/7707801/

-- 
Kalle Valo

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 06:58:32PM +0200, Kalle Valo wrote:
>> Mark Brown <broonie@kernel.org> writes:
>
>> > No, I didn't make much effort to check though since the use of ifdef was
>> > clearly a bug waiting to happen anyway, I was more surprised it worked
>> > at all than anything.
>
>> Michal Marek explains[1] that this is due to commit cf4f21938e13
>> ("kbuild: Allow to specify composite modules with modname-m") and has
>> nothing to do with the wireless drivers reorganisation. I'll drop this
>> patch as Michal will apply his fix to the kbuild tree.
>
> It still ought to be fixed regardless of why it showed up - the
> intention of the code is that we build the real thermal code regardless
> of if that's modular or not but that's not what the code actually does.

Like I said above Michal will apply a fix to his tree. Read the full
discussion from patchwork:

https://patchwork.kernel.org/patch/7707801/

-- 
Kalle Valo

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Kalle Valo]

Mark Brown <broonie@kernel.org> writes:

> On Thu, Nov 26, 2015 at 06:58:32PM +0200, Kalle Valo wrote:
>> Mark Brown <broonie@kernel.org> writes:
>
>> > No, I didn't make much effort to check though since the use of ifdef was
>> > clearly a bug waiting to happen anyway, I was more surprised it worked
>> > at all than anything.
>
>> Michal Marek explains[1] that this is due to commit cf4f21938e13
>> ("kbuild: Allow to specify composite modules with modname-m") and has
>> nothing to do with the wireless drivers reorganisation. I'll drop this
>> patch as Michal will apply his fix to the kbuild tree.
>
> It still ought to be fixed regardless of why it showed up - the
> intention of the code is that we build the real thermal code regardless
> of if that's modular or not but that's not what the code actually does.

Like I said above Michal will apply a fix to his tree. Read the full
discussion from patchwork:

https://patchwork.kernel.org/patch/7707801/

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]

On Thu, Nov 26, 2015 at 08:34:20PM +0200, Kalle Valo wrote:
> Mark Brown <broonie@kernel.org> writes:

> > It still ought to be fixed regardless of why it showed up - the
> > intention of the code is that we build the real thermal code regardless
> > of if that's modular or not but that's not what the code actually does.

> Like I said above Michal will apply a fix to his tree. Read the full
> discussion from patchwork:

> https://patchwork.kernel.org/patch/7707801/

Oh, right - a fix for this specific issue rather than a fix for whatever
change he made.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Thu, Nov 26, 2015 at 08:34:20PM +0200, Kalle Valo wrote:
> Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:

> > It still ought to be fixed regardless of why it showed up - the
> > intention of the code is that we build the real thermal code regardless
> > of if that's modular or not but that's not what the code actually does.

> Like I said above Michal will apply a fix to his tree. Read the full
> discussion from patchwork:

> https://patchwork.kernel.org/patch/7707801/

Oh, right - a fix for this specific issue rather than a fix for whatever
change he made.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 561 bytes --]

On Thu, Nov 26, 2015 at 08:34:20PM +0200, Kalle Valo wrote:
> Mark Brown <broonie@kernel.org> writes:

> > It still ought to be fixed regardless of why it showed up - the
> > intention of the code is that we build the real thermal code regardless
> > of if that's modular or not but that's not what the code actually does.

> Like I said above Michal will apply a fix to his tree. Read the full
> discussion from patchwork:

> https://patchwork.kernel.org/patch/7707801/

Oh, right - a fix for this specific issue rather than a fix for whatever
change he made.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: next-20151126 build: 3 failures 15 warnings (next-20151126)

[Daniel Cashman]

I think the proper course here is to make the use conditional,
assuming that there will never be a 32-bit application running if
CONFIG_COMPAT is not enabled.  Thank you Mark for catching this, and
Catalin for your suggestions.  I've just posted patch-set v4, which
addresses some of Catalin's remarks and this breakage; I'd have no
objection to removing v3 from next, especially in light of this.

Thank You,
Dan

On Thu, Nov 26, 2015 at 7:10 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Thu, Nov 26, 2015 at 11:32:13AM +0000, Mark Brown wrote:
>> Today's -next fails to build an arm64 allnoconfig due to:
>>
>> >     arm64-allnoconfig
>> > ../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)
>>
>> which was introduced by a combination of 8f62c06c279a3 (mm: mmap: add
>> new /proc tunable for mmap_base ASLR) and 9411708692954 (arm64: mm:
>> support ARCH_MMAP_RND_BITS).  These add an unconditional use of
>> mmap_rnd_compat_bits which is only defined in linux/mmap.h if
>> HAVE_ARCH_MMAP_RND_COMPAT_BITS is selected but that is only enabled for
>> arm64 if COMPAT is enabled.  Either the select needs to be unconditional
>> or the use needs to be.
>
> There are other problems with these patches for arm64, I already replied
> here:
>
> http://lkml.kernel.org/g/20151125120601.GC3109@e104818-lin.cambridge.arm.com
>
> So I don't think they should be in -next.
>
> --
> Catalin



-- 
Dan Cashman

next-20151126 build: 3 failures 15 warnings (next-20151126)

[Daniel Cashman]

I think the proper course here is to make the use conditional,
assuming that there will never be a 32-bit application running if
CONFIG_COMPAT is not enabled.  Thank you Mark for catching this, and
Catalin for your suggestions.  I've just posted patch-set v4, which
addresses some of Catalin's remarks and this breakage; I'd have no
objection to removing v3 from next, especially in light of this.

Thank You,
Dan

On Thu, Nov 26, 2015 at 7:10 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Thu, Nov 26, 2015 at 11:32:13AM +0000, Mark Brown wrote:
>> Today's -next fails to build an arm64 allnoconfig due to:
>>
>> >     arm64-allnoconfig
>> > ../arch/arm64/mm/mmap.c:55:49: error: 'mmap_rnd_compat_bits' undeclared (first use in this function)
>>
>> which was introduced by a combination of 8f62c06c279a3 (mm: mmap: add
>> new /proc tunable for mmap_base ASLR) and 9411708692954 (arm64: mm:
>> support ARCH_MMAP_RND_BITS).  These add an unconditional use of
>> mmap_rnd_compat_bits which is only defined in linux/mmap.h if
>> HAVE_ARCH_MMAP_RND_COMPAT_BITS is selected but that is only enabled for
>> arm64 if COMPAT is enabled.  Either the select needs to be unconditional
>> or the use needs to be.
>
> There are other problems with these patches for arm64, I already replied
> here:
>
> http://lkml.kernel.org/g/20151125120601.GC3109 at e104818-lin.cambridge.arm.com
>
> So I don't think they should be in -next.
>
> --
> Catalin



-- 
Dan Cashman