Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Mon, 19 Oct 2020 10:35:12 +0200 Udo van den Heuvel wrote: > People, > > At https://www.kernel.org/doc/html/latest/leds/leds-class.html we can > read that the LEDS code supposedly optimizes away when certain > conditions are met. > Especially the Realtek HDA driver *unconditionally* (as found in > 5.9.1) *wants* to enable LED functionality. > I.e.: if this blockade is lifted in the source tree then I can live > with the 'is optimized out' predictions, assuming that gcc (from > Fedora 32) can do this. > So the request is clear; we're almost there. > Please make it so that the compiler can do the 'optimize away' work > bij changing a tad in the Realtek HDA driver, along the lines of the > patch sent to me earlier or something even more beautiful. > > Thanks in advance and kind regards, > Udo Udo, The documentation says that LED trigger code optimises away, not LED core. But yes, something similar could maybe be done for the whole LED class... (maybe!) BTW, you are welcome to propose a patch as well, since it seems that nobody else is interested as much as you are in this :) Marek
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
People, At https://www.kernel.org/doc/html/latest/leds/leds-class.html we can read that the LEDS code supposedly optimizes away when certain conditions are met. Especially the Realtek HDA driver *unconditionally* (as found in 5.9.1) *wants* to enable LED functionality. I.e.: if this blockade is lifted in the source tree then I can live with the 'is optimized out' predictions, assuming that gcc (from Fedora 32) can do this. So the request is clear; we're almost there. Please make it so that the compiler can do the 'optimize away' work bij changing a tad in the Realtek HDA driver, along the lines of the patch sent to me earlier or something even more beautiful. Thanks in advance and kind regards, Udo On 14-10-2020 10:37, Pavel Machek wrote: > On Wed 2020-10-14 10:34:21, Udo van den Heuvel wrote: >> On 14-10-2020 10:27, Pavel Machek wrote: One should have thought about stuff beforehand. >>> >>> We did. And decided this is best solution. >> >> Then the thought process went awry. >> The non-selectability is not my fault. >>> >>> It also does not affect you in any way. >> >> It does. >> /boot fills up even sooner thanks to this unused code. >> Compiles last longer because of this unused code. > > Have you measured how much slower and how much bigger it is? Do you > understand that you propose to make source code bigger and slower to > compile for everyone else? > > You are filling my inbox. > >>> Feel free to go to the mic LED discussion to see why we did it like >>> this. Then you can come up with better solution for problem at hand. >> >> I did not think of forcing code onto somebody. Someone else did. >> This is effectively the effect of the LEDs thing. > > Without understanding what was decided and why, this discussion is not > useful. > > > Pavel >
Re: disabling CONFIG_LED_CLASS
On 10/13/20 9:29 PM, Udo van den Heuvel wrote: > > > On 13-10-2020 18:03, Randy Dunlap wrote: >> On 10/13/20 8:53 AM, Randy Dunlap wrote: >>> [adding LED people + list] >>> >>> On 10/13/20 6:24 AM, Udo van den Heuvel wrote: > (...) > So how do I disable this stuff? > >> >> I was able to disable LEDS_CLASS and NEW_LEDS after I disabled the following >> config symbols: >> >> >> --- xx64/config-def642020-10-13 08:53:56.050501724 -0700 >> +++ xx64/.config 2020-10-13 08:58:12.439205389 -0700 >> -CONFIG_MAC80211_LEDS=y >> -CONFIG_RFKILL_LEDS=y >> -# CONFIG_LED_TRIGGER_PHY is not set >> -CONFIG_INPUT_LEDS=y >> -# CONFIG_HID_LED is not set >> -# CONFIG_USB_LED_TRIG is not set >> -# CONFIG_USB_LEDS_TRIGGER_USBPORT is not set >> -CONFIG_LEDS_TRIGGERS=y >> -CONFIG_EEEPC_LAPTOP=y >> +# CONFIG_EEEPC_LAPTOP is not set >> >> This last one was the biggest problem for me. >> I started with x86_64 defconfig. > > # grep LED .config > # grep LEDS .config > # grep EEPC .config > # make oldconfig > (...) > * > * LED Support > * > LED Support (NEW_LEDS) [Y/?] (NEW) y > LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n > > So we still are stuck. > > Udo > Please post your .config file. -- ~Randy
Re: disabling CONFIG_LED_CLASS
On 10/13/20 9:56 PM, Udo van den Heuvel wrote: > On 14-10-2020 06:49, Randy Dunlap wrote: >> If you disable SND_HDA_CODEC_REALTEK, then the rest of the >> LED kconfig symbols can be disabled. > > Sure, > > but: > > # dmesg|grep audi > (...) > > [ 19.971537] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x7, too > many assigned pins > [ 19.973547] snd_hda_codec_generic hdaudioC0D0: autoconfig for > Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line > [ 19.975642] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 > (0x0/0x0/0x0/0x0/0x0) > [ 19.94] snd_hda_codec_generic hdaudioC0D0:hp_outs=0 > (0x0/0x0/0x0/0x0/0x0) > [ 19.980176] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0 > [ 19.982257] snd_hda_codec_generic hdaudioC0D0:dig-out=0x3/0x5 > [ 19.984412] snd_hda_codec_generic hdaudioC0D0:inputs: > [ 20.035088] snd_hda_codec_realtek hdaudioC1D0: autoconfig for > ALC1220: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line > [ 20.036940] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 > (0x0/0x0/0x0/0x0/0x0) > [ 20.039579] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 > (0x1b/0x0/0x0/0x0/0x0) > [ 20.041690] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 > [ 20.044076] snd_hda_codec_realtek hdaudioC1D0:dig-out=0x1e/0x0 > [ 20.046173] snd_hda_codec_realtek hdaudioC1D0:inputs: > [ 20.049252] snd_hda_codec_realtek hdaudioC1D0: Front Mic=0x19 > [ 20.051287] snd_hda_codec_realtek hdaudioC1D0: Rear Mic=0x18 > [ 20.053084] snd_hda_codec_realtek hdaudioC1D0: Line=0x1a > [ 20.427487] usbcore: registered new interface driver snd-usb-audio > > 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. According to this commit: commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc Author: Takashi Iwai Date: Thu Jun 18 13:08:31 2020 +0200 ALSA: hda: generic: Add a helper for mic-mute LED with LED classdev the Realtek and other drivers need LED support: """ Also, introduce a new kconfig CONFIG_SND_HDA_GENERIC_LEDS, to indicate the usage of mute / mic-mute LED helpers. It's selected by the codec drivers (Realtek, Conexant and Sigmatel), while it selects the necessary LED class dependencies. """ -- ~Randy
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Wed 2020-10-14 10:34:21, Udo van den Heuvel wrote: > On 14-10-2020 10:27, Pavel Machek wrote: > >> One should have thought about stuff beforehand. > > > > We did. And decided this is best solution. > > Then the thought process went awry. > > >> The non-selectability is not my fault. > > > > It also does not affect you in any way. > > It does. > /boot fills up even sooner thanks to this unused code. > Compiles last longer because of this unused code. Have you measured how much slower and how much bigger it is? Do you understand that you propose to make source code bigger and slower to compile for everyone else? You are filling my inbox. > > Feel free to go to the mic LED discussion to see why we did it like > > this. Then you can come up with better solution for problem at hand. > > I did not think of forcing code onto somebody. Someone else did. > This is effectively the effect of the LEDs thing. Without understanding what was decided and why, this discussion is not useful. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On 14-10-2020 10:27, Pavel Machek wrote: >> One should have thought about stuff beforehand. > > We did. And decided this is best solution. Then the thought process went awry. >> The non-selectability is not my fault. > > It also does not affect you in any way. It does. /boot fills up even sooner thanks to this unused code. Compiles last longer because of this unused code. > Feel free to go to the mic LED discussion to see why we did it like > this. Then you can come up with better solution for problem at hand. I did not think of forcing code onto somebody. Someone else did. This is effectively the effect of the LEDs thing. So why should I `fix` this when a Kconfig thing is considered 'expensive'? If reasonable arguments fall to the floor then where do you go? This is the same as some useless things in Fedora that one cannot simply uninstall. Udo
Re: disabling CONFIG_LED_CLASS
On 10/13/20 9:39 PM, Udo van den Heuvel wrote: > On 14-10-2020 06:34, Randy Dunlap wrote: >> On 10/13/20 9:29 PM, Udo van den Heuvel wrote: >>> So we still are stuck. > > (...) > > >> Please post your .config file. > > Attached to this message. > This is the version stripped from LED references. This is the problem: config SND_HDA_CODEC_REALTEK tristate "Build Realtek HD-audio codec support" select SND_HDA_GENERIC select SND_HDA_GENERIC_LEDS If you disable SND_HDA_CODEC_REALTEK, then the rest of the LED kconfig symbols can be disabled. lnx-59> grep LEDS xx64/.config # CONFIG_NEW_LEDS is not set -- ~Randy
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Wed 2020-10-14 10:22:01, Udo van den Heuvel wrote: > On 14-10-2020 10:11, Pavel Machek wrote: > >> It's a computer, not a disco-light or anything like that. > > > > And you probably have numlock LED. > > On the case? no way. > It is on the keyboard, a separate device, and already has a function. > We also have a caps lock LED and scroll lock LED there, with separate > functions. > I do not need 'extra' functionality for those. > > > Additional config options have costs, too, and we don't want to > > support gazillion config options. > > That is not the issue. > One should have thought about stuff beforehand. We did. And decided this is best solution. > The non-selectability is not my fault. It also does not affect you in any way. Feel free to go to the mic LED discussion to see why we did it like this. Then you can come up with better solution for problem at hand. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On 14-10-2020 10:11, Pavel Machek wrote: >> It's a computer, not a disco-light or anything like that. > > And you probably have numlock LED. On the case? no way. It is on the keyboard, a separate device, and already has a function. We also have a caps lock LED and scroll lock LED there, with separate functions. I do not need 'extra' functionality for those. > Additional config options have costs, too, and we don't want to > support gazillion config options. That is not the issue. One should have thought about stuff beforehand. One changes an existing situation and one should have understood that new stuff should never be forced, no matter what the size or functionality. The non-selectability is not my fault. The perceived 'complexity' in the patch is not my fault. My points of view w.r.t. the situation are fairly reasonable and common. The fact that this change made it to the kernel means that people did not look into it that well. Kind regards, Udo
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On 10/13/20 10:16 PM, Udo van den Heuvel wrote: > On 14-10-2020 07:07, Randy Dunlap wrote: >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote: > >>> 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. > > Kind regards, > Udo Hi Takashi, Regarding commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc Author: Takashi Iwai 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? thanks. -- ~Randy
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
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
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... Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Wed 2020-10-14 10:05:42, Udo van den Heuvel wrote: > On 14-10-2020 09:58, Pavel Machek wrote: > > Contrary to his claims, Udo very probably has LEDs in his systems... > > We have a visible power LED. > WE have a HDD LED. > The board has LEDs, yes, but the SilverStone Fortress FT02 hides them > fairly well. > I did not ask for LEDs nor need them this way. > It's a computer, not a disco-light or anything like that. And you probably have numlock LED. > Whether the code is big or not does not matter, it is a matter of being > able to select what one needs without getting bothered with other code > that will do nothing. No. Additional config options have costs, too, and we don't want to support gazillion config options. LED core should be small enough that it does not matter. Sound was inventing its own "tiny LED core" before. > So please consider. I did. Answer is no. Please accept it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
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. thanks, Takashi
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
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 > > > > 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
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On 14-10-2020 09:58, Pavel Machek wrote: > Contrary to his claims, Udo very probably has LEDs in his systems... We have a visible power LED. WE have a HDD LED. The board has LEDs, yes, but the SilverStone Fortress FT02 hides them fairly well. I did not ask for LEDs nor need them this way. It's a computer, not a disco-light or anything like that. Whether the code is big or not does not matter, it is a matter of being able to select what one needs without getting bothered with other code that will do nothing. So please consider. Kind regards, Udo
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
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 > > > 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? Lets keep things as they are. Contrary to his claims, Udo very probably has LEDs in his systems... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
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. Best regards, Pavel > 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? > > thanks. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Wed, 14 Oct 2020 09:49:49 +0200,
Takashi Iwai wrote:
>
> On Wed, 14 Oct 2020 07:54:15 +0200,
> Randy Dunlap wrote:
> >
> > On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> > > On 14-10-2020 07:07, Randy Dunlap wrote:
> > >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> > >
> > >>> 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.
> > >
> > > Kind regards,
> > > Udo
> >
> > Hi Takashi,
> >
> > Regarding
> > commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
> > Author: Takashi Iwai
> > 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 :)
Takashi
---
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -94,7 +94,7 @@ config SND_HDA_PATCH_LOADER
config SND_HDA_CODEC_REALTEK
tristate "Build Realtek HD-audio codec support"
select SND_HDA_GENERIC
- select SND_HDA_GENERIC_LEDS
+ select SND_HDA_GENERIC_LEDS if !EXPERT
help
Say Y or M here to include Realtek HD-audio codec support in
snd-hda-intel driver, such as ALC880.
@@ -115,7 +115,7 @@ comment "Set to Y if you want auto-loading the codec driver"
config SND_HDA_CODEC_SIGMATEL
tristate "Build IDT/Sigmatel HD-audio codec support"
select SND_HDA_GENERIC
- select SND_HDA_GENERIC_LEDS
+ select SND_HDA_GENERIC_LEDS if !EXPERT
help
Say Y or M here to include IDT (Sigmatel) HD-audio codec support in
snd-hda-intel driver, such as STAC9200.
@@ -160,7 +160,7 @@ comment "Set to Y if you want auto-loading the codec driver"
config SND_HDA_CODEC_CONEXANT
tristate "Build Conexant HD-audio codec support"
select SND_HDA_GENERIC
- select SND_HDA_GENERIC_LEDS
+ select SND_HDA_GENERIC_LEDS if !EXPERT
help
Say Y or M here to include Conexant HD-audio codec support in
snd-hda-intel driver, such as CX20549.
--- a/sound/pci/hda/hda_generic.h
+++ b/sound/pci/hda/hda_generic.h
@@ -354,11 +354,29 @@ unsigned int snd_hda_gen_path_power_filter(struct
hda_codec *codec,
void snd_hda_gen_stream_pm(struct hda_codec *codec, hda_nid_t nid, bool on);
int snd_hda_gen_fix_pin_power(struct hda_codec *codec, hda_nid_t pin);
+#ifdef CONFIG_SND_HDA_GENERIC_LEDS
int snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
int (*callback)(struct led_classdev *,
enum led_brightness));
int snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
int (*callback)(struct led_classdev *,
enum led_brightness));
+#else /* CONFIG_SND_HDA_GENERIC_LEDS */
+static inline int
+snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
+ int (*callback)(struct led_classdev *,
+ enum led_brightness))
+{
+ return -ENODEV;
+}
+
+static inline int
+snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
+int (*callback)(struct led_classdev *,
+enum led_brightness))
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_SND_HDA_GENERIC_LEDS */
#endif /* __SOUND_HDA_GENERIC_H */
Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)
On Wed, 14 Oct 2020 07:54:15 +0200,
Randy Dunlap wrote:
>
> On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> > On 14-10-2020 07:07, Randy Dunlap wrote:
> >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> >
> >>> 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.
> >
> > Kind regards,
> > Udo
>
> Hi Takashi,
>
> Regarding
> commit 7cdf8c49b1df0a385db06c4f9a5ba1b16510fdcc
> Author: Takashi Iwai
> 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?
Takashi
---
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1390,6 +1390,11 @@ menuconfig EXPERT
environments which can tolerate a "non-standard" kernel.
Only use this if you really know what you are doing.
+config SUPERHACKER
+ bool "Rule the world" if EXPERT
+ help
+ You are allowed to break things at your own risk.
+
config UID16
bool "Enable 16-bit UID system calls" if EXPERT
depends on HAVE_UID16 && MULTIUSER
--- a/sound/pci/hda/Kconfig
+++ b/sound/pci/hda/Kconfig
@@ -94,7 +94,7 @@ config SND_HDA_PATCH_LOADER
config SND_HDA_CODEC_REALTEK
tristate "Build Realtek HD-audio codec support"
select SND_HDA_GENERIC
- select SND_HDA_GENERIC_LEDS
+ select SND_HDA_GENERIC_LEDS if !SUPERHACKER
help
Say Y or M here to include Realtek HD-audio codec support in
snd-hda-intel driver, such as ALC880.
@@ -115,7 +115,7 @@ comment "Set to Y if you want auto-loading the codec driver"
config SND_HDA_CODEC_SIGMATEL
tristate "Build IDT/Sigmatel HD-audio codec support"
select SND_HDA_GENERIC
- select SND_HDA_GENERIC_LEDS
+ select SND_HDA_GENERIC_LEDS if !SUPERHACKER
help
Say Y or M here to include IDT (Sigmatel) HD-audio codec support in
snd-hda-intel driver, such as STAC9200.
@@ -160,7 +160,7 @@ comment "Set to Y if you want auto-loading the codec driver"
config SND_HDA_CODEC_CONEXANT
tristate "Build Conexant HD-audio codec support"
select SND_HDA_GENERIC
- select SND_HDA_GENERIC_LEDS
+ select SND_HDA_GENERIC_LEDS if !SUPERHACKER
help
Say Y or M here to include Conexant HD-audio codec support in
snd-hda-intel driver, such as CX20549.
--- a/sound/pci/hda/hda_generic.h
+++ b/sound/pci/hda/hda_generic.h
@@ -354,11 +354,29 @@ unsigned int snd_hda_gen_path_power_filter(struct
hda_codec *codec,
void snd_hda_gen_stream_pm(struct hda_codec *codec, hda_nid_t nid, bool on);
int snd_hda_gen_fix_pin_power(struct hda_codec *codec, hda_nid_t pin);
+#ifdef CONFIG_SND_HDA_GENERIC_LEDS
int snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
int (*callback)(struct led_classdev *,
enum led_brightness));
int snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
int (*callback)(struct led_classdev *,
enum led_brightness));
+#else /* CONFIG_SND_HDA_GENERIC_LEDS */
+static inline int
+snd_hda_gen_add_mute_led_cdev(struct hda_codec *codec,
+ int (*callback)(struct led_classdev *,
+ enum led_brightness))
+{
+ return -ENODEV;
+}
+
+static inline int
+snd_hda_gen_add_micmute_led_cdev(struct hda_codec *codec,
+int (*callback)(struct led_classdev *,
+enum led_brightness))
+{
+ return -ENODEV;
+}
+#endif /* CONFIG_SND_HDA_GENERIC_LEDS */
#endif /* __SOUND_HDA_GENERIC_H */
Re: disabling CONFIG_LED_CLASS
On 14-10-2020 07:07, Randy Dunlap wrote: > On 10/13/20 9:56 PM, Udo van den Heuvel wrote: >> 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. Kind regards, Udo
Re: disabling CONFIG_LED_CLASS
On 14-10-2020 06:49, Randy Dunlap wrote: > If you disable SND_HDA_CODEC_REALTEK, then the rest of the > LED kconfig symbols can be disabled. Sure, but: # dmesg|grep audi (...) [ 19.971537] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x7, too many assigned pins [ 19.973547] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=0 (0x0/0x0/0x0/0x0/0x0) type:line [ 19.975642] snd_hda_codec_generic hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 19.94] snd_hda_codec_generic hdaudioC0D0:hp_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 19.980176] snd_hda_codec_generic hdaudioC0D0:mono: mono_out=0x0 [ 19.982257] snd_hda_codec_generic hdaudioC0D0:dig-out=0x3/0x5 [ 19.984412] snd_hda_codec_generic hdaudioC0D0:inputs: [ 20.035088] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC1220: line_outs=3 (0x14/0x15/0x16/0x0/0x0) type:line [ 20.036940] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 20.039579] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) [ 20.041690] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [ 20.044076] snd_hda_codec_realtek hdaudioC1D0:dig-out=0x1e/0x0 [ 20.046173] snd_hda_codec_realtek hdaudioC1D0:inputs: [ 20.049252] snd_hda_codec_realtek hdaudioC1D0: Front Mic=0x19 [ 20.051287] snd_hda_codec_realtek hdaudioC1D0: Rear Mic=0x18 [ 20.053084] snd_hda_codec_realtek hdaudioC1D0: Line=0x1a [ 20.427487] usbcore: registered new interface driver snd-usb-audio I.e.: it looks like I will lose some funcionality when I disable SND_HDA_CODEC_REALTEK. Kind regards, Udo
Re: disabling CONFIG_LED_CLASS
On 13-10-2020 18:03, Randy Dunlap wrote: > On 10/13/20 8:53 AM, Randy Dunlap wrote: >> [adding LED people + list] >> >> On 10/13/20 6:24 AM, Udo van den Heuvel wrote: (...) So how do I disable this stuff? > > I was able to disable LEDS_CLASS and NEW_LEDS after I disabled the following > config symbols: > > > --- xx64/config-def64 2020-10-13 08:53:56.050501724 -0700 > +++ xx64/.config 2020-10-13 08:58:12.439205389 -0700 > -CONFIG_MAC80211_LEDS=y > -CONFIG_RFKILL_LEDS=y > -# CONFIG_LED_TRIGGER_PHY is not set > -CONFIG_INPUT_LEDS=y > -# CONFIG_HID_LED is not set > -# CONFIG_USB_LED_TRIG is not set > -# CONFIG_USB_LEDS_TRIGGER_USBPORT is not set > -CONFIG_LEDS_TRIGGERS=y > -CONFIG_EEEPC_LAPTOP=y > +# CONFIG_EEEPC_LAPTOP is not set > > This last one was the biggest problem for me. > I started with x86_64 defconfig. # grep LED .config # grep LEDS .config # grep EEPC .config # make oldconfig (...) * * LED Support * LED Support (NEW_LEDS) [Y/?] (NEW) y LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n So we still are stuck. Udo
Re: disabling CONFIG_LED_CLASS
On 10/13/20 8:53 AM, Randy Dunlap wrote: > [adding LED people + list] > > On 10/13/20 6:24 AM, Udo van den Heuvel wrote: >> L.S., >> >> Even after removing all LED referneces from .config, a `make oldconfig` >> leads to: >> >> * >> * LED Support >> * >> LED Support (NEW_LEDS) [Y/?] (NEW) y >> LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n >> >> Where 'n' is not a valid choice. >> So why is this LED thing forced upon us and how do we get rid of it? >> >> Or else please explain how to make this work on a Gigabyte Technology >> Co., Ltd. X570 AORUS PRO... >> >> Kind regards, >> Udo >> >> >> On 13-10-2020 11:24, Udo van den Heuvel wrote: >>> Hello, >>> >>> While looking at the 5.9 kernel config I noticed there is no easy way to >>> disable LED support in general. >>> There's this NEW_LEDS thing that is not shown, etc. >>> So I get: >>> >>> # make oldconfig >>> scripts/kconfig/conf --oldconfig Kconfig >>> * >>> * Restart config... >>> * >>> * >>> * LED Support >>> * >>> LED Support (NEW_LEDS) [Y/?] (NEW) y >>> LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n >>> >>> CONFIG_LEDS_CLASS: >>> >>> This option enables the LED sysfs class in /sys/class/leds. You'll >>> need this to do anything useful with LEDs. If unsure, say N. >>> >>> Symbol: LEDS_CLASS [=m] >>> Type : tristate >>> Defined at drivers/leds/Kconfig:17 >>> Prompt: LED Class Support >>> Depends on: NEW_LEDS [=y] >>> Location: >>> -> Device Drivers >>> -> LED Support (NEW_LEDS [=y]) >>> Selected by [m]: >>> - SND_HDA_GENERIC [=m] && SOUND [=y] && !UML && SND [=m] && SND_HDA >>> [=m] && SND_HDA_GENERIC_LEDS [=y] >>> Selected by [n]: >>> - TS5500 [=n] && X86_32 [=n] && MELAN [=n] >>> - ADB_PMU_LED [=n] && MACINTOSH_DRIVERS [=n] && PPC_PMAC && ADB_PMU [=n] >>> - ATH5K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] >>> && (PCI [=y] || ATH25) && MAC80211 [=n] >>> - ATH9K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] >>> && MAC80211 [=n] && HAS_DMA [=y] >>> - ATH9K_HTC [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH >>> [=n] && USB [=y] && MAC80211 [=n] >>> - CARL9170_LEDS [=n] && NETDEVICES [=y] && WLAN [=n] && >>> WLAN_VENDOR_ATH [=n] && CARL9170 [=n] >>> - BRCMSMAC [=n] && NETDEVICES [=y] && WLAN [=n] && >>> WLAN_VENDOR_BROADCOM [=n] && MAC80211 [=n] && BCMA_POSSIBLE [=y] && >>> BCMA_DRIVER_GPIO [=n] >>> - IWLEGACY [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_INTEL [=n] >>> - INPUT_WISTRON_BTNS [=n] && !UML && INPUT [=y] && INPUT_MISC [=y] && >>> X86_32 [=n] >>> - SENSORS_APPLESMC [=n] && HWMON [=y] && INPUT [=y] && X86 [=y] >>> - IR_REDRAT3 [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && >>> RC_CORE [=n] >>> - IR_WINBOND_CIR [=n] && RC_DEVICES [=n] && (X86 [=y] && PNP [=y] || >>> COMPILE_TEST [=n]) && RC_CORE [=n] >>> - IR_TTUSBIR [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && >>> RC_CORE [=n] >>> - BACKLIGHT_ADP8860 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE >>> [=y] && I2C [=y] >>> - BACKLIGHT_ADP8870 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE >>> [=y] && I2C [=y] >>> - BACKLIGHT_LM3639 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE >>> [=y] && I2C [=y] >>> - SND_USB_TONEPORT [=n] && SOUND [=y] && !UML && SND [=m] && SND_USB >>> [=y] && USB [=y] >>> - HID_LENOVO [=n] && INPUT [=y] && HID [=y] >>> - HID_WACOM [=n] && INPUT [=y] && HID [=y] && USB_HID [=m] >>> - HUAWEI_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && >>> ACPI_BATTERY [=n] && ACPI_WMI [=n] && INPUT [=y] >>> - ACER_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] >>> && BACKLIGHT_CLASS_DEVICE [=y] && SERIO_I8042 [=y] && INPUT [=y] && >>> (RFKILL [=n] || RFKILL [=n]=n) && ACPI_WMI [=n] >>> - ASUS_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >>> [=y] && BACKLIGHT_CLASS_DEVICE [=y] && INPUT [=y] && (RFKILL [=n] || >>> RFKILL [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) >>> - ASUS_WIRELESS [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >>> [=y] && INPUT [=y] >>> - ASUS_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI_WMI >>> [=n] && ACPI_BATTERY [=n] && INPUT [=y] && HWMON [=y] && >>> BACKLIGHT_CLASS_DEVICE [=y] && (RFKILL [=n] || RFKILL [=n]=n) && >>> HOTPLUG_PCI [=n] && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) >>> - EEEPC_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >>> [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) && (ACPI_VIDEO [=n] >>> || ACPI_VIDEO [=n]=n) && HOTPLUG_PCI [=n] && BACKLIGHT_CLASS_DEVICE [=y] >>> - DELL_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && DMI >>> [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || ACPI_VIDEO >>> [=n]=n) && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y] && >>> DELL_SMBIOS [=n] >>> - FUJITSU_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >>> [=y] && INPUT [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || >>> ACPI_VIDEO [=n]=n) >>> - HP_ACCEL [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n]
Re: disabling CONFIG_LED_CLASS
[adding LED people + list] On 10/13/20 6:24 AM, Udo van den Heuvel wrote: > L.S., > > Even after removing all LED referneces from .config, a `make oldconfig` > leads to: > > * > * LED Support > * > LED Support (NEW_LEDS) [Y/?] (NEW) y > LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n > > Where 'n' is not a valid choice. > So why is this LED thing forced upon us and how do we get rid of it? > > Or else please explain how to make this work on a Gigabyte Technology > Co., Ltd. X570 AORUS PRO... > > Kind regards, > Udo > > > On 13-10-2020 11:24, Udo van den Heuvel wrote: >> Hello, >> >> While looking at the 5.9 kernel config I noticed there is no easy way to >> disable LED support in general. >> There's this NEW_LEDS thing that is not shown, etc. >> So I get: >> >> # make oldconfig >> scripts/kconfig/conf --oldconfig Kconfig >> * >> * Restart config... >> * >> * >> * LED Support >> * >> LED Support (NEW_LEDS) [Y/?] (NEW) y >> LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n >> >> CONFIG_LEDS_CLASS: >> >> This option enables the LED sysfs class in /sys/class/leds. You'll >> need this to do anything useful with LEDs. If unsure, say N. >> >> Symbol: LEDS_CLASS [=m] >> Type : tristate >> Defined at drivers/leds/Kconfig:17 >> Prompt: LED Class Support >> Depends on: NEW_LEDS [=y] >> Location: >> -> Device Drivers >> -> LED Support (NEW_LEDS [=y]) >> Selected by [m]: >> - SND_HDA_GENERIC [=m] && SOUND [=y] && !UML && SND [=m] && SND_HDA >> [=m] && SND_HDA_GENERIC_LEDS [=y] >> Selected by [n]: >> - TS5500 [=n] && X86_32 [=n] && MELAN [=n] >> - ADB_PMU_LED [=n] && MACINTOSH_DRIVERS [=n] && PPC_PMAC && ADB_PMU [=n] >> - ATH5K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] >> && (PCI [=y] || ATH25) && MAC80211 [=n] >> - ATH9K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] >> && MAC80211 [=n] && HAS_DMA [=y] >> - ATH9K_HTC [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH >> [=n] && USB [=y] && MAC80211 [=n] >> - CARL9170_LEDS [=n] && NETDEVICES [=y] && WLAN [=n] && >> WLAN_VENDOR_ATH [=n] && CARL9170 [=n] >> - BRCMSMAC [=n] && NETDEVICES [=y] && WLAN [=n] && >> WLAN_VENDOR_BROADCOM [=n] && MAC80211 [=n] && BCMA_POSSIBLE [=y] && >> BCMA_DRIVER_GPIO [=n] >> - IWLEGACY [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_INTEL [=n] >> - INPUT_WISTRON_BTNS [=n] && !UML && INPUT [=y] && INPUT_MISC [=y] && >> X86_32 [=n] >> - SENSORS_APPLESMC [=n] && HWMON [=y] && INPUT [=y] && X86 [=y] >> - IR_REDRAT3 [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && >> RC_CORE [=n] >> - IR_WINBOND_CIR [=n] && RC_DEVICES [=n] && (X86 [=y] && PNP [=y] || >> COMPILE_TEST [=n]) && RC_CORE [=n] >> - IR_TTUSBIR [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && >> RC_CORE [=n] >> - BACKLIGHT_ADP8860 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE >> [=y] && I2C [=y] >> - BACKLIGHT_ADP8870 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE >> [=y] && I2C [=y] >> - BACKLIGHT_LM3639 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE >> [=y] && I2C [=y] >> - SND_USB_TONEPORT [=n] && SOUND [=y] && !UML && SND [=m] && SND_USB >> [=y] && USB [=y] >> - HID_LENOVO [=n] && INPUT [=y] && HID [=y] >> - HID_WACOM [=n] && INPUT [=y] && HID [=y] && USB_HID [=m] >> - HUAWEI_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && >> ACPI_BATTERY [=n] && ACPI_WMI [=n] && INPUT [=y] >> - ACER_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] >> && BACKLIGHT_CLASS_DEVICE [=y] && SERIO_I8042 [=y] && INPUT [=y] && >> (RFKILL [=n] || RFKILL [=n]=n) && ACPI_WMI [=n] >> - ASUS_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >> [=y] && BACKLIGHT_CLASS_DEVICE [=y] && INPUT [=y] && (RFKILL [=n] || >> RFKILL [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) >> - ASUS_WIRELESS [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >> [=y] && INPUT [=y] >> - ASUS_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI_WMI >> [=n] && ACPI_BATTERY [=n] && INPUT [=y] && HWMON [=y] && >> BACKLIGHT_CLASS_DEVICE [=y] && (RFKILL [=n] || RFKILL [=n]=n) && >> HOTPLUG_PCI [=n] && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) >> - EEEPC_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >> [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) && (ACPI_VIDEO [=n] >> || ACPI_VIDEO [=n]=n) && HOTPLUG_PCI [=n] && BACKLIGHT_CLASS_DEVICE [=y] >> - DELL_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && DMI >> [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || ACPI_VIDEO >> [=n]=n) && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y] && >> DELL_SMBIOS [=n] >> - FUJITSU_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >> [=y] && INPUT [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || >> ACPI_VIDEO [=n]=n) >> - HP_ACCEL [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && INPUT [=y] >> && ACPI [=y] && SERIO_I8042 [=y] >> - THINKPAD_ACPI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI >> [=y] && ACPI_BATTERY [=n]
Re: disabling CONFIG_LED_CLASS
L.S., Even after removing all LED referneces from .config, a `make oldconfig` leads to: * * LED Support * LED Support (NEW_LEDS) [Y/?] (NEW) y LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n Where 'n' is not a valid choice. So why is this LED thing forced upon us and how do we get rid of it? Or else please explain how to make this work on a Gigabyte Technology Co., Ltd. X570 AORUS PRO... Kind regards, Udo On 13-10-2020 11:24, Udo van den Heuvel wrote: > Hello, > > While looking at the 5.9 kernel config I noticed there is no easy way to > disable LED support in general. > There's this NEW_LEDS thing that is not shown, etc. > So I get: > > # make oldconfig > scripts/kconfig/conf --oldconfig Kconfig > * > * Restart config... > * > * > * LED Support > * > LED Support (NEW_LEDS) [Y/?] (NEW) y > LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n > > CONFIG_LEDS_CLASS: > > This option enables the LED sysfs class in /sys/class/leds. You'll > need this to do anything useful with LEDs. If unsure, say N. > > Symbol: LEDS_CLASS [=m] > Type : tristate > Defined at drivers/leds/Kconfig:17 > Prompt: LED Class Support > Depends on: NEW_LEDS [=y] > Location: > -> Device Drivers > -> LED Support (NEW_LEDS [=y]) > Selected by [m]: > - SND_HDA_GENERIC [=m] && SOUND [=y] && !UML && SND [=m] && SND_HDA > [=m] && SND_HDA_GENERIC_LEDS [=y] > Selected by [n]: > - TS5500 [=n] && X86_32 [=n] && MELAN [=n] > - ADB_PMU_LED [=n] && MACINTOSH_DRIVERS [=n] && PPC_PMAC && ADB_PMU [=n] > - ATH5K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] > && (PCI [=y] || ATH25) && MAC80211 [=n] > - ATH9K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] > && MAC80211 [=n] && HAS_DMA [=y] > - ATH9K_HTC [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH > [=n] && USB [=y] && MAC80211 [=n] > - CARL9170_LEDS [=n] && NETDEVICES [=y] && WLAN [=n] && > WLAN_VENDOR_ATH [=n] && CARL9170 [=n] > - BRCMSMAC [=n] && NETDEVICES [=y] && WLAN [=n] && > WLAN_VENDOR_BROADCOM [=n] && MAC80211 [=n] && BCMA_POSSIBLE [=y] && > BCMA_DRIVER_GPIO [=n] > - IWLEGACY [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_INTEL [=n] > - INPUT_WISTRON_BTNS [=n] && !UML && INPUT [=y] && INPUT_MISC [=y] && > X86_32 [=n] > - SENSORS_APPLESMC [=n] && HWMON [=y] && INPUT [=y] && X86 [=y] > - IR_REDRAT3 [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && > RC_CORE [=n] > - IR_WINBOND_CIR [=n] && RC_DEVICES [=n] && (X86 [=y] && PNP [=y] || > COMPILE_TEST [=n]) && RC_CORE [=n] > - IR_TTUSBIR [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && > RC_CORE [=n] > - BACKLIGHT_ADP8860 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE > [=y] && I2C [=y] > - BACKLIGHT_ADP8870 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE > [=y] && I2C [=y] > - BACKLIGHT_LM3639 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE > [=y] && I2C [=y] > - SND_USB_TONEPORT [=n] && SOUND [=y] && !UML && SND [=m] && SND_USB > [=y] && USB [=y] > - HID_LENOVO [=n] && INPUT [=y] && HID [=y] > - HID_WACOM [=n] && INPUT [=y] && HID [=y] && USB_HID [=m] > - HUAWEI_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && > ACPI_BATTERY [=n] && ACPI_WMI [=n] && INPUT [=y] > - ACER_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] > && BACKLIGHT_CLASS_DEVICE [=y] && SERIO_I8042 [=y] && INPUT [=y] && > (RFKILL [=n] || RFKILL [=n]=n) && ACPI_WMI [=n] > - ASUS_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI > [=y] && BACKLIGHT_CLASS_DEVICE [=y] && INPUT [=y] && (RFKILL [=n] || > RFKILL [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) > - ASUS_WIRELESS [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI > [=y] && INPUT [=y] > - ASUS_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI_WMI > [=n] && ACPI_BATTERY [=n] && INPUT [=y] && HWMON [=y] && > BACKLIGHT_CLASS_DEVICE [=y] && (RFKILL [=n] || RFKILL [=n]=n) && > HOTPLUG_PCI [=n] && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) > - EEEPC_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI > [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) && (ACPI_VIDEO [=n] > || ACPI_VIDEO [=n]=n) && HOTPLUG_PCI [=n] && BACKLIGHT_CLASS_DEVICE [=y] > - DELL_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && DMI > [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || ACPI_VIDEO > [=n]=n) && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y] && > DELL_SMBIOS [=n] > - FUJITSU_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI > [=y] && INPUT [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || > ACPI_VIDEO [=n]=n) > - HP_ACCEL [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && INPUT [=y] > && ACPI [=y] && SERIO_I8042 [=y] > - THINKPAD_ACPI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI > [=y] && ACPI_BATTERY [=n] && INPUT [=y] && (RFKILL [=n] || RFKILL > [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) && > BACKLIGHT_CLASS_DEVICE [=y] > - SAMSUNG_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && > (RFKILL [=n]
disabling CONFIG_LED_CLASS
Hello, While looking at the 5.9 kernel config I noticed there is no easy way to disable LED support in general. There's this NEW_LEDS thing that is not shown, etc. So I get: # make oldconfig scripts/kconfig/conf --oldconfig Kconfig * * Restart config... * * * LED Support * LED Support (NEW_LEDS) [Y/?] (NEW) y LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n CONFIG_LEDS_CLASS: This option enables the LED sysfs class in /sys/class/leds. You'll need this to do anything useful with LEDs. If unsure, say N. Symbol: LEDS_CLASS [=m] Type : tristate Defined at drivers/leds/Kconfig:17 Prompt: LED Class Support Depends on: NEW_LEDS [=y] Location: -> Device Drivers -> LED Support (NEW_LEDS [=y]) Selected by [m]: - SND_HDA_GENERIC [=m] && SOUND [=y] && !UML && SND [=m] && SND_HDA [=m] && SND_HDA_GENERIC_LEDS [=y] Selected by [n]: - TS5500 [=n] && X86_32 [=n] && MELAN [=n] - ADB_PMU_LED [=n] && MACINTOSH_DRIVERS [=n] && PPC_PMAC && ADB_PMU [=n] - ATH5K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] && (PCI [=y] || ATH25) && MAC80211 [=n] - ATH9K [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] && MAC80211 [=n] && HAS_DMA [=y] - ATH9K_HTC [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] && USB [=y] && MAC80211 [=n] - CARL9170_LEDS [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_ATH [=n] && CARL9170 [=n] - BRCMSMAC [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_BROADCOM [=n] && MAC80211 [=n] && BCMA_POSSIBLE [=y] && BCMA_DRIVER_GPIO [=n] - IWLEGACY [=n] && NETDEVICES [=y] && WLAN [=n] && WLAN_VENDOR_INTEL [=n] - INPUT_WISTRON_BTNS [=n] && !UML && INPUT [=y] && INPUT_MISC [=y] && X86_32 [=n] - SENSORS_APPLESMC [=n] && HWMON [=y] && INPUT [=y] && X86 [=y] - IR_REDRAT3 [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && RC_CORE [=n] - IR_WINBOND_CIR [=n] && RC_DEVICES [=n] && (X86 [=y] && PNP [=y] || COMPILE_TEST [=n]) && RC_CORE [=n] - IR_TTUSBIR [=n] && RC_DEVICES [=n] && USB_ARCH_HAS_HCD [=y] && RC_CORE [=n] - BACKLIGHT_ADP8860 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y] && I2C [=y] - BACKLIGHT_ADP8870 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y] && I2C [=y] - BACKLIGHT_LM3639 [=n] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y] && I2C [=y] - SND_USB_TONEPORT [=n] && SOUND [=y] && !UML && SND [=m] && SND_USB [=y] && USB [=y] - HID_LENOVO [=n] && INPUT [=y] && HID [=y] - HID_WACOM [=n] && INPUT [=y] && HID [=y] && USB_HID [=m] - HUAWEI_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI_BATTERY [=n] && ACPI_WMI [=n] && INPUT [=y] - ACER_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && BACKLIGHT_CLASS_DEVICE [=y] && SERIO_I8042 [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) && ACPI_WMI [=n] - ASUS_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && BACKLIGHT_CLASS_DEVICE [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) - ASUS_WIRELESS [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && INPUT [=y] - ASUS_WMI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI_WMI [=n] && ACPI_BATTERY [=n] && INPUT [=y] && HWMON [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (RFKILL [=n] || RFKILL [=n]=n) && HOTPLUG_PCI [=n] && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) - EEEPC_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) && HOTPLUG_PCI [=n] && BACKLIGHT_CLASS_DEVICE [=y] - DELL_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && DMI [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) && (RFKILL [=n] || RFKILL [=n]=n) && SERIO_I8042 [=y] && DELL_SMBIOS [=n] - FUJITSU_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && INPUT [=y] && BACKLIGHT_CLASS_DEVICE [=y] && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) - HP_ACCEL [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && INPUT [=y] && ACPI [=y] && SERIO_I8042 [=y] - THINKPAD_ACPI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && ACPI_BATTERY [=n] && INPUT [=y] && (RFKILL [=n] || RFKILL [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) && BACKLIGHT_CLASS_DEVICE [=y] - SAMSUNG_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && (RFKILL [=n] || RFKILL [=n]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) && BACKLIGHT_CLASS_DEVICE [=y] - ACPI_TOSHIBA [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && ACPI_WMI [=n] && BACKLIGHT_CLASS_DEVICE [=y] && INPUT [=y] && (SERIO_I8042 [=y] || SERIO_I8042 [=y]=n) && (ACPI_VIDEO [=n] || ACPI_VIDEO [=n]=n) && (RFKILL [=n] || RFKILL [=n]=n) && IIO [=n] - LG_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && ACPI_WMI [=n] && INPUT [=y] - SYSTEM76_ACPI [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] - TOPSTAR_LAPTOP [=n] && X86 [=y] && X86_PLATFORM_DEVICES [=n] && ACPI [=y] && INPUT [=y] And there is no 'n' option.
