Messages in this thread | | | Date | Wed, 14 Oct 2020 10:17:08 +0200 | From | Takashi Iwai <> | Subject | Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK) |
| |
On Wed, 14 Oct 2020 10:13:05 +0200, Pavel Machek wrote: > > On Wed 2020-10-14 10:08:27, Takashi Iwai wrote: > > On Wed, 14 Oct 2020 09:54:59 +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. > > > > > > LED core is not that big, and this avoided some rather "interesting" > > > hacks IIRC. If Udo wants more config complexity, lets first make him > > > measure the benefits, second submit a patch. > > > > > > But I'd suggest to just live with it. > > > > > > And yes, we should probably get rid of "CONFIG_NEW_LEDS" symbol. That > > > one is actually useless. > > > > IIRC, this was needed for the reverse selection of CONFIG_LEDS_CLASS > > and co. But if it's really useless, I'll happily delete it. > > It is needed for now. It is just something we should remove in > future. CONFIG options are not that cheap...
Ah I see. Yes, the config itself is superfluous.
thanks,
Takashi
| |