disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

On Wed, 14 Oct 2020 09:58:53 +0200,
Pavel Machek wrote:
> 
> Hi!
> 
> > > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > > >>> SND_HDA_CODEC_REALTEK.
> > > > >>
> > > > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > > > >> with no LEDS. That driver apparently wants LEDS.
> > > > > 
> > > > > Thanks but why have I gone for years without LEDS?
> > > > > I do not need LEDS, I do not want LEDS, I do not have LEDS (that are
> > > > > visible, usable, etc).
> > > > > 
> > > > > Please make this selectable instead of forcing more bulk into my kernel.
> > > > 
> > > > Hi Takashi,
> > > > 
> > > > Regarding
> > > > commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
> > > > Author: Takashi Iwai <tiwai at suse.de>
> > > > Date:   Thu Jun 18 13:08:31 2020 +0200
> > > >     ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev
> > > > 
> > > > and this Kconfig entry:
> > > > 
> > > > config SND_HDA_CODEC_REALTEK
> > > > 	tristate "Build Realtek HD-audio codec support"
> > > > 	select SND_HDA_GENERIC
> > > > 	select SND_HDA_GENERIC_LEDS
> > > > 
> > > > it seems that LED support is not always wanted (please see above).
> > > > I.e., user(s) would like to build a kernel without LED support at all.
> > > > 
> > > > Can you make it a build option?
> > > 
> > > Something like this?
> > 
> > This one is more suitable for the merge :)
> 
> That will still break the build if SND_HDA_CODEC_REALTEK=y and
> SND_HDA_GENERIC_LEDS=m, no?

SND_HDA_GENERIC_LEDS is a bool, and this selects the actual LEDS_*
stuff from SND_HDA_GENERIC, so the builtin vs module problem shouldn't
happen.  So I don't think the suggested patch would break builds.
It'll hit an error at probe if the hardware actually uses the LEDs.

> Lets keep things as they are.
> 
> Contrary to his claims, Udo very probably has LEDs in his systems...

Heh, a surprise :)


thanks,

Takashi