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

["Arnd Bergmann" <arnd@arndb.de>]

On Fri, Oct 2, 2026, at 02:22, Ping-Ke Shih wrote:
> Arnd Bergmann <arnd@arndb.de> 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