2009-06-03 15:20:52

by Randy Dunlap

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

Stephen Rothwell wrote:
> Hi all,
>
> Looks like a real rush since -rc7 ...


CFG80211=y
MAC80211=y
RFKILL=m

net/built-in.o: In function `cfg80211_netdev_notifier_call':
core.c:(.text+0xa678b): undefined reference to `rfkill_blocked'
net/built-in.o: In function `cfg80211_dev_free':
(.text+0xa67e2): undefined reference to `rfkill_destroy'
net/built-in.o: In function `cfg80211_rfkill_sync_work':
core.c:(.text+0xa686e): undefined reference to `rfkill_blocked'
net/built-in.o: In function `wiphy_new':
(.text+0xa69f2): undefined reference to `rfkill_alloc'
net/built-in.o: In function `wiphy_rfkill_start_polling':
(.text+0xa6bd2): undefined reference to `rfkill_resume_polling'
net/built-in.o: In function `wiphy_rfkill_stop_polling':
(.text+0xa6bdf): undefined reference to `rfkill_pause_polling'
net/built-in.o: In function `wiphy_unregister':
(.text+0xa6bf4): undefined reference to `rfkill_unregister'
net/built-in.o: In function `wiphy_rfkill_set_hw_state':
(.text+0xa6c64): undefined reference to `rfkill_set_hw_state'
net/built-in.o: In function `wiphy_register':
(.text+0xa6db4): undefined reference to `rfkill_register'
net/built-in.o: In function `cfg80211_wext_giwtxpower':
(.text+0xb01e9): undefined reference to `rfkill_blocked'
net/built-in.o: In function `cfg80211_wext_siwtxpower':
(.text+0xb0cf3): undefined reference to `rfkill_set_sw_state'
net/built-in.o: In function `cfg80211_wext_siwtxpower':
(.text+0xb0d1f): undefined reference to `rfkill_set_sw_state'


--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/


2009-06-03 16:27:30

by Johannes Berg

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

On Wed, 2009-06-03 at 08:22 -0700, Randy Dunlap wrote:
> Stephen Rothwell wrote:
> > Hi all,
> >
> > Looks like a real rush since -rc7 ...
>
>
> CFG80211=y
> MAC80211=y
> RFKILL=m

Hmm. I see, it's mac80211's broken select CFG80211. I'll fix it.

johannes


Attachments:
signature.asc (801.00 B)
This is a digitally signed message part

2009-06-03 16:14:39

by Gábor Stefanik

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

On Wed, Jun 3, 2009 at 5:29 PM, Johannes Berg <[email protected]> wrote:
> On Wed, 2009-06-03 at 08:22 -0700, Randy Dunlap wrote:
>> Stephen Rothwell wrote:
>
>> CFG80211=y
>> MAC80211=y
>> RFKILL=m
>>
>> net/built-in.o: In function `cfg80211_netdev_notifier_call':
>> core.c:(.text+0xa678b): undefined reference to `rfkill_blocked'
>> net/built-in.o: In function `cfg80211_dev_free':
>
> Hrm. I thought
>
> config CFG80211
> ? ? ? ?tristate "Improved wireless configuration API"
> ? ? ? ?depends on RFKILL || !RFKILL
>
> would avoid that. Why doesn't it?
>
> johannes
>

Maybe the "y" state of CFG80211 specifically needs to depend on
RFKILL=y || !RFKILL.

BTW should CFG80211=y really be blocked when RFKILL=m? Shouldn't we
just disable CFG80211 RFKILL support in this case (perhaps via a
separate CONFIG_CFG80211_RFKILL automatically configured depending on
CONFIG_RFKILL)?

--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

2009-06-03 17:18:04

by Randy Dunlap

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

Randy Dunlap wrote:
> Stephen Rothwell wrote:
>> Hi all,
>>
>> Looks like a real rush since -rc7 ...
>
>
> CFG80211=y
> MAC80211=y
> RFKILL=m
>
> net/built-in.o: In function `cfg80211_netdev_notifier_call':
> core.c:(.text+0xa678b): undefined reference to `rfkill_blocked'
> net/built-in.o: In function `cfg80211_dev_free':
> (.text+0xa67e2): undefined reference to `rfkill_destroy'
> net/built-in.o: In function `cfg80211_rfkill_sync_work':
> core.c:(.text+0xa686e): undefined reference to `rfkill_blocked'
> net/built-in.o: In function `wiphy_new':
> (.text+0xa69f2): undefined reference to `rfkill_alloc'
> net/built-in.o: In function `wiphy_rfkill_start_polling':
> (.text+0xa6bd2): undefined reference to `rfkill_resume_polling'
> net/built-in.o: In function `wiphy_rfkill_stop_polling':
> (.text+0xa6bdf): undefined reference to `rfkill_pause_polling'
> net/built-in.o: In function `wiphy_unregister':
> (.text+0xa6bf4): undefined reference to `rfkill_unregister'
> net/built-in.o: In function `wiphy_rfkill_set_hw_state':
> (.text+0xa6c64): undefined reference to `rfkill_set_hw_state'
> net/built-in.o: In function `wiphy_register':
> (.text+0xa6db4): undefined reference to `rfkill_register'
> net/built-in.o: In function `cfg80211_wext_giwtxpower':
> (.text+0xb01e9): undefined reference to `rfkill_blocked'
> net/built-in.o: In function `cfg80211_wext_siwtxpower':
> (.text+0xb0cf3): undefined reference to `rfkill_set_sw_state'
> net/built-in.o: In function `cfg80211_wext_siwtxpower':
> (.text+0xb0d1f): undefined reference to `rfkill_set_sw_state'


Ugh, there are similar errors in the wimax area, which doesn't
seem to mention RFKILL in its Kconfig file at all. :(

net/built-in.o: In function `wimax_rfkill':
(.text+0x81996): undefined reference to `rfkill_set_sw_state'
net/built-in.o: In function `wimax_report_rfkill_sw':
(.text+0x81ac0): undefined reference to `rfkill_set_sw_state'
net/built-in.o: In function `wimax_report_rfkill_hw':
(.text+0x81bd3): undefined reference to `rfkill_set_hw_state'
net/built-in.o: In function `wimax_rfkill_rm':
(.text+0x81c8f): undefined reference to `rfkill_unregister'
net/built-in.o: In function `wimax_rfkill_rm':
(.text+0x81c9a): undefined reference to `rfkill_destroy'
net/built-in.o: In function `wimax_rfkill_add':
(.text+0x81d52): undefined reference to `rfkill_alloc'
net/built-in.o: In function `wimax_rfkill_add':
(.text+0x81db3): undefined reference to `rfkill_register'
net/built-in.o: In function `wimax_rfkill_add':
(.text+0x81e2d): undefined reference to `rfkill_destroy'


--
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/

2009-06-03 15:29:17

by Johannes Berg

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

On Wed, 2009-06-03 at 08:22 -0700, Randy Dunlap wrote:
> Stephen Rothwell wrote:

> CFG80211=y
> MAC80211=y
> RFKILL=m
>
> net/built-in.o: In function `cfg80211_netdev_notifier_call':
> core.c:(.text+0xa678b): undefined reference to `rfkill_blocked'
> net/built-in.o: In function `cfg80211_dev_free':

Hrm. I thought

config CFG80211
tristate "Improved wireless configuration API"
depends on RFKILL || !RFKILL

would avoid that. Why doesn't it?

johannes


Attachments:
signature.asc (801.00 B)
This is a digitally signed message part

2009-06-03 17:33:31

by Johannes Berg

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

On Wed, 2009-06-03 at 10:20 -0700, Randy Dunlap wrote:

> Ugh, there are similar errors in the wimax area, which doesn't
> seem to mention RFKILL in its Kconfig file at all. :(

Guess it too will have to get a

depends on RFKILL || !RFKILL

I can take care of it after dinner.

johannes


Attachments:
signature.asc (801.00 B)
This is a digitally signed message part

2009-06-03 22:48:54

by Inaky Perez-Gonzalez

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

On Thursday 04 June 2009, Johannes Berg wrote:
> On Wed, 2009-06-03 at 10:20 -0700, Randy Dunlap wrote:
> > Ugh, there are similar errors in the wimax area, which doesn't
> > seem to mention RFKILL in its Kconfig file at all. :(
>
> Guess it too will have to get a
>
> depends on RFKILL || !RFKILL
>
> I can take care of it after dinner.

Ugh...bitten again by Randy's evil autobuilder. Thanks for fixing
it, Johannes.

--
Inaky

2009-06-03 15:53:45

by Johannes Berg

[permalink] [raw]
Subject: Re: linux-next: Tree for June 3 (rfkill)

On Wed, 2009-06-03 at 17:47 +0200, Gábor Stefanik wrote:

> >> CFG80211=y
> >> MAC80211=y
> >> RFKILL=m
> >>
> >> net/built-in.o: In function `cfg80211_netdev_notifier_call':
> >> core.c:(.text+0xa678b): undefined reference to `rfkill_blocked'
> >> net/built-in.o: In function `cfg80211_dev_free':
> >
> > Hrm. I thought
> >
> > config CFG80211
> > tristate "Improved wireless configuration API"
> > depends on RFKILL || !RFKILL
> >
> > would avoid that. Why doesn't it?
> >
> > johannes
> >
>
> Maybe the "y" state of CFG80211 specifically needs to depend on
> RFKILL=y || !RFKILL.

Maybe doesn't help me at all.

> BTW should CFG80211=y really be blocked when RFKILL=m?

Yes.

> Shouldn't we
> just disable CFG80211 RFKILL support in this case (perhaps via a
> separate CONFIG_CFG80211_RFKILL automatically configured depending on
> CONFIG_RFKILL)?

That would be immensely stupid. You might as well just make cfg80211 a
module then.

johannes


Attachments:
signature.asc (801.00 B)
This is a digitally signed message part