linux-kernel - Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Oct 2020 10:22:01 +0200
From:   Udo van den Heuvel <udovdh@...all.nl>
To:     Pavel Machek <pavel@....cz>
Cc:     Takashi Iwai <tiwai@...e.de>, Randy Dunlap <rdunlap@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-leds@...r.kernel.org, Dan Murphy <dmurphy@...com>,
        moderated for non-subscribers <alsa-devel@...a-project.org>
Subject: 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