Arnd Bergmann <arnd@xxxxxxxxxx> writes: > From: Arnd Bergmann <arnd@xxxxxxxx> > > 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@xxxxxxxx> Luca, I would like to take this to wireless-drivers. Ack? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
