From: Arnd Bergmann <arnd@arndb.de>
The dependencies for LED configuration are highly inconsistent and too
complicated at the moment. One of the results is a randconfig failure I
get very rarely when LEDS_CLASS is in a loadable module, but the wireless
core is built-in:
WARNING: unmet direct dependencies detected for MAC80211_LEDS
Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
Selected by [m]:
- IWLEGACY [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y]
- IWLWIFI_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y] && IWLWIFI [=m] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=IWLWIFI [=m]) && (IWLMVM [=m] || IWLDVM [=m])
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_register_led':
led.c:(.text+0x60): undefined reference to `led_classdev_register_ext'
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_unregister_leds':
led.c:(.text+0x200): undefined reference to `led_classdev_unregister'
For iwlwifi, the dependency is wrong, since this config prevents the
MAC80211_LEDS code from being part of a built-in MAC80211 driver.
For iwlegacy, this is worse because the driver tries to force-enable
the other subsystems, which is both a layering violation and a bug
because it will still fail with MAC80211=y and IWLEGACY=m, leading
to LEDS_CLASS being a module as well.
The actual link failure in the ath5k driver is a result of MAC80211_LEDS
being enabled but not usable. With the Kconfig logic fixed in the
Intel drivers, the ath5k driver works as expected again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/intel/iwlegacy/Kconfig | 4 ++--
drivers/net/wireless/intel/iwlwifi/Kconfig | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
From: Arnd Bergmann <arnd@arndb.de>
This is now the only driver that selects the LEDS_CLASS framework,
which is normally user-selectable. While it doesn't strictly cause
a bug, rework the Kconfig logic to be more consistent with what
other drivers do, and only enable LED support in brcmsmac if the
dependencies are all there, rather than using 'select' to enable
what it needs.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/broadcom/brcm80211/Kconfig | 14 +++++++++-----
.../wireless/broadcom/brcm80211/brcmsmac/Makefile | 2 +-
.../net/wireless/broadcom/brcm80211/brcmsmac/led.h | 2 +-
3 files changed, 11 insertions(+), 7 deletions(-)
From: Arnd Bergmann <arnd@arndb.de>
After mt7921s got added, there are two possible build problems:
a) mt7921s does not get built at all if mt7921e is not also enabled
b) there is a link error when mt7921e is a loadable module, but mt7921s
configured as built-in:
ERROR: modpost: "mt7921_mac_sta_add" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_assoc" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_remove" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_write_txwi" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_drv_pmctrl" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_fill_message" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_parse_response" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_ops" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_queue_rx_skb" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_update_channel" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
Fix both by making sure that Kbuild enters the subdirectory when
either one is enabled.
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/mediatek/mt76/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Felix Fietkau <nbd@nbd.name> Date: 2021-12-04 17:52:19
On 2021-12-04 18:38, Arnd Bergmann wrote:
From: Arnd Bergmann <arnd@arndb.de>
After mt7921s got added, there are two possible build problems:
a) mt7921s does not get built at all if mt7921e is not also enabled
b) there is a link error when mt7921e is a loadable module, but mt7921s
configured as built-in:
ERROR: modpost: "mt7921_mac_sta_add" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_assoc" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_sta_remove" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mac_write_txwi" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_drv_pmctrl" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_fill_message" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_mcu_parse_response" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_ops" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_queue_rx_skb" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
ERROR: modpost: "mt7921_update_channel" [drivers/net/wireless/mediatek/mt76/mt7921/mt7921e.ko] undefined!
Fix both by making sure that Kbuild enters the subdirectory when
either one is enabled.
Fixes: 48fab5bbef40 ("mt76: mt7921: introduce mt7921s support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-12-07 10:16:22
On Tue, 2021-12-07 at 11:14 +0100, Johannes Berg wrote:
On Sat, 2021-12-04 at 18:38 +0100, Arnd Bergmann wrote:
quoted
config IWLWIFI_LEDS bool- depends on LEDS_CLASS=y || LEDS_CLASS=IWLWIFI+ depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
Hm. Can we really not have this if LEDS_CLASS=n?
Well, umm. That wouldn't make sense for IWLWIFI_LEDS, sorry.
Might be simpler to express this as "depends on MAC80211_LEDS" which has
the same condition, and it feels like that makes more sense than
referencing MAC80211 here?
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2021-12-07 10:49:34
On Tue, 2021-12-07 at 11:16 +0100, Johannes Berg wrote:
On Tue, 2021-12-07 at 11:14 +0100, Johannes Berg wrote:
quoted
On Sat, 2021-12-04 at 18:38 +0100, Arnd Bergmann wrote:
quoted
config IWLWIFI_LEDS bool- depends on LEDS_CLASS=y || LEDS_CLASS=IWLWIFI+ depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
Hm. Can we really not have this if LEDS_CLASS=n?
Well, umm. That wouldn't make sense for IWLWIFI_LEDS, sorry.
Might be simpler to express this as "depends on MAC80211_LEDS" which has
the same condition, and it feels like that makes more sense than
referencing MAC80211 here?
Hm, maybe not. Sorry for the monologue here - but MAC80211_LEDS is user
selectable, and so I guess that's a different thing.
johannes
On Tue, 2021-12-07 at 11:49 +0100, Johannes Berg wrote:
On Tue, 2021-12-07 at 11:16 +0100, Johannes Berg wrote:
quoted
On Tue, 2021-12-07 at 11:14 +0100, Johannes Berg wrote:
quoted
On Sat, 2021-12-04 at 18:38 +0100, Arnd Bergmann wrote:
quoted
config IWLWIFI_LEDS bool- depends on LEDS_CLASS=y || LEDS_CLASS=IWLWIFI+ depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
Hm. Can we really not have this if LEDS_CLASS=n?
Well, umm. That wouldn't make sense for IWLWIFI_LEDS, sorry.
Might be simpler to express this as "depends on MAC80211_LEDS" which has
the same condition, and it feels like that makes more sense than
referencing MAC80211 here?
Hm, maybe not. Sorry for the monologue here - but MAC80211_LEDS is user
selectable, and so I guess that's a different thing.
Thanks for checking this, Johannes!
So, if you think we can take Arnd's patch, Kalle has my ack:
Acked-by: Luca Coelho <redacted>
--
Cheers,
Luca.
From: Kalle Valo <kvalo@kernel.org> Date: 2021-12-08 18:17:49
Arnd Bergmann [off-list ref] wrote:
From: Arnd Bergmann <arnd@arndb.de>
The dependencies for LED configuration are highly inconsistent and too
complicated at the moment. One of the results is a randconfig failure I
get very rarely when LEDS_CLASS is in a loadable module, but the wireless
core is built-in:
WARNING: unmet direct dependencies detected for MAC80211_LEDS
Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
Selected by [m]:
- IWLEGACY [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y]
- IWLWIFI_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL [=y] && IWLWIFI [=m] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=IWLWIFI [=m]) && (IWLMVM [=m] || IWLDVM [=m])
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_register_led':
led.c:(.text+0x60): undefined reference to `led_classdev_register_ext'
aarch64-linux-ld: drivers/net/wireless/ath/ath5k/led.o: in function `ath5k_unregister_leds':
led.c:(.text+0x200): undefined reference to `led_classdev_unregister'
For iwlwifi, the dependency is wrong, since this config prevents the
MAC80211_LEDS code from being part of a built-in MAC80211 driver.
For iwlegacy, this is worse because the driver tries to force-enable
the other subsystems, which is both a layering violation and a bug
because it will still fail with MAC80211=y and IWLEGACY=m, leading
to LEDS_CLASS being a module as well.
The actual link failure in the ath5k driver is a result of MAC80211_LEDS
being enabled but not usable. With the Kconfig logic fixed in the
Intel drivers, the ath5k driver works as expected again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Luca Coelho <redacted>