| Message ID | 20211204173848.873293-1-arnd@kernel.org (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | efdbfa0ad03e764419378485d1b8f6e7706fb1a3 |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | [1/3] iwlwifi: fix LED dependencies | expand |
Arnd Bergmann <arnd@kernel.org> writes: > 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> Luca, I would like to take this to wireless-drivers. Ack?
On Sat, 2021-12-04 at 18:38 +0100, Arnd Bergmann wrote: > > 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? johannes
On Tue, 2021-12-07 at 11:14 +0100, Johannes Berg wrote: > On Sat, 2021-12-04 at 18:38 +0100, Arnd Bergmann wrote: > > > > 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
On Tue, 2021-12-07 at 11:16 +0100, Johannes Berg wrote: > On Tue, 2021-12-07 at 11:14 +0100, Johannes Berg wrote: > > On Sat, 2021-12-04 at 18:38 +0100, Arnd Bergmann wrote: > > > > > > 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: > > On Tue, 2021-12-07 at 11:14 +0100, Johannes Berg wrote: > > > On Sat, 2021-12-04 at 18:38 +0100, Arnd Bergmann wrote: > > > > > > > > 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 <luciano.coelho@intel.com> -- Cheers, Luca.
Arnd Bergmann <arnd@kernel.org> 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 <luciano.coelho@intel.com> 3 patches applied to wireless-drivers.git, thanks. efdbfa0ad03e iwlwifi: fix LED dependencies c68115fc5375 brcmsmac: rework LED dependencies f7d55d2e439f mt76: mt7921: fix build regression
diff --git a/drivers/net/wireless/intel/iwlegacy/Kconfig b/drivers/net/wireless/intel/iwlegacy/Kconfig index 24fe3f63c321..7eacc8e58ee1 100644 --- a/drivers/net/wireless/intel/iwlegacy/Kconfig +++ b/drivers/net/wireless/intel/iwlegacy/Kconfig @@ -2,14 +2,13 @@ config IWLEGACY tristate select FW_LOADER - select NEW_LEDS - select LEDS_CLASS select LEDS_TRIGGERS select MAC80211_LEDS config IWL4965 tristate "Intel Wireless WiFi 4965AGN (iwl4965)" depends on PCI && MAC80211 + depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211 select IWLEGACY help This option enables support for @@ -38,6 +37,7 @@ config IWL4965 config IWL3945 tristate "Intel PRO/Wireless 3945ABG/BG Network Connection (iwl3945)" depends on PCI && MAC80211 + depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211 select IWLEGACY help Select to build the driver supporting the: diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig b/drivers/net/wireless/intel/iwlwifi/Kconfig index 337428ef2e67..cf1125d84929 100644 --- a/drivers/net/wireless/intel/iwlwifi/Kconfig +++ b/drivers/net/wireless/intel/iwlwifi/Kconfig @@ -47,7 +47,7 @@ if IWLWIFI config IWLWIFI_LEDS bool - depends on LEDS_CLASS=y || LEDS_CLASS=IWLWIFI + depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211 depends on IWLMVM || IWLDVM select LEDS_TRIGGERS select MAC80211_LEDS