Re: disabling CONFIG_LED_CLASS

Re: disabling CONFIG_LED_CLASS

[Randy Dunlap]

[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] && 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. None of the devices as dependencies (on the
>> left) are enabled.
>> SND_HDA_GENERIC_LEDS is automagically enabled and disabling it via vi is
>> no option.
>> So how do I disable this stuff?
>>
>> Kind regards,
>> Udo
>>
> 


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@infradead.org>

Re: disabling CONFIG_LED_CLASS

[Randy Dunlap]

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] && 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. None of the devices as dependencies (on the
>>> left) are enabled.
>>> SND_HDA_GENERIC_LEDS is automagically enabled and disabling it via vi is
>>> no option.
>>> So how do I disable this stuff?
>>>
>>> Kind regards,
>>> Udo

Hi,

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.


-- 
~Randy

Re: disabling CONFIG_LED_CLASS

[Udo van den Heuvel]

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

[Randy Dunlap]

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

Please post your .config file.

-- 
~Randy

Re: disabling CONFIG_LED_CLASS

[Randy Dunlap]

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

[Udo van den Heuvel]

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.977774] 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

[Randy Dunlap]

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.977774] 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 <tiwai@suse.de>
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

[Udo van den Heuvel]

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 (SND_HDA_CODEC_REALTEK)

[Randy Dunlap]

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 <tiwai@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?

thanks.
-- 
~Randy

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

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 <tiwai@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?


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 (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

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 <tiwai@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 :)


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)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Udo van den Heuvel]

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)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Udo van den Heuvel]

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)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Udo van den Heuvel]

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 (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Udo van den Heuvel]

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 (SND_HDA_CODEC_REALTEK)

[Marek Behún]

On Mon, 19 Oct 2020 10:35:12 +0200
Udo van den Heuvel <udovdh@xs4all.nl> 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)

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

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

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)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: disabling CONFIG_LED_CLASS (SND_HDA_CODEC_REALTEK)

[Takashi Iwai]

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