Re: [PATCH] wifi: rtw89: fix LED dependencies

From: Arnd Bergmann

Date: Fri Oct 02 2026 - 02:12:38 EST


On Fri, Oct 2, 2026, at 02:22, Ping-Ke Shih wrote:
> Arnd Bergmann <arnd@xxxxxxxx> wrote:
>> On Wed, Sep 30, 2026, at 02:28, Ping-Ke Shih wrote:
>> - we already have a mix of 'depends on' and 'select'
>> for the LED support, which can lead to circular dependencies
>> and other problems. Adding a third way can only make it
>> worse.
>>
>
> Agree. I'll remove these two discouraged 'imply'.

Ok, thanks!

>> The way this was meant to be used is to have
>>
>> config RTW89_LEDS
>> def_bool RTW89_CORE && MAC80211_LEDS
>>
>
> I'd keep first block as
>
> depends on LEDS_CLASS=y || LEDS_CLASS=MAC80211
>
> mac80211 implements ieee80211_get_assoc_led_name() used by this driver as
>
> static inline const char *ieee80211_get_assoc_led_name(struct
> ieee80211_hw *hw)
> {
> #ifdef CONFIG_MAC80211_LEDS
> return __ieee80211_get_assoc_led_name(hw);
> #else
> return NULL;
> #endif
> }
>
> That means if CONFIG_MAC80211_LEDS wasn't defined, driver can still use
> ieee80211_get_assoc_led_name() as default trigger, but just NULL.
> More, use space can adjust LED trigger via sysfs, so having LED support
> is still usable if LEDS_CLASS exists.

Right, this should work and is consistent with how other wireless
drivers do this.

I think it would be nicer to just use MAC80211_LEDS as a simple
dependency as I suggested above. If we do that, it should
be done the same way for all the wireless drivers, but that
is a probably something for another day.

Arnd