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

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.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-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)

[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)

[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)

[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)

[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)

[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 --]