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@xxxxxxx> > > > > 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
