From: Heiner Kallweit <hkallweit1@gmail.com>
To: Lee Jones <lee@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Pavel Machek <pavel@ucw.cz>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>,
linux-leds@vger.kernel.org, linux-sound@vger.kernel.org,
linux-mips@vger.kernel.org
Subject: Re: [PATCH v2 0/3] leds: trigger: Improve handling of led_trigger_event() and simplify mute audio trigger
Date: Fri, 8 Mar 2024 18:30:00 +0100 [thread overview]
Message-ID: <9c256c60-3baa-429f-979b-8e60ef03fed3@gmail.com> (raw)
In-Reply-To: <20240305160626.GH86322@google.com>
On 05.03.2024 17:06, Lee Jones wrote:
> On Tue, 05 Mar 2024, Heiner Kallweit wrote:
>
>> On 05.03.2024 15:54, Lee Jones wrote:
>>> On Tue, 05 Mar 2024, Lee Jones wrote:
>>>
>>>> On Tue, 05 Mar 2024, Lee Jones wrote:
>>>>
>>>>> On Mon, 04 Mar 2024 21:56:29 +0100, Heiner Kallweit wrote:
>>>>>> If a simple trigger is assigned to a LED, then the LED may be off until
>>>>>> the next led_trigger_event() call. This may be an issue for simple
>>>>>> triggers with rare led_trigger_event() calls, e.g. power supply
>>>>>> charging indicators (drivers/power/supply/power_supply_leds.c).
>>>>>> Therefore persist the brightness value of the last led_trigger_event()
>>>>>> call and use this value if the trigger is assigned to a LED.
>>>>>> This change allows to use simple triggers in more cases.
>>>>>> As a first use case simplify handling of the mute audio trigger.
>>>>>>
>>>>>> [...]
>>>>>
>>>>> Applied, thanks!
>>>>>
>>>>> [1/3] leds: trigger: Store brightness set by led_trigger_event()
>>>>> commit: 575129855dee0e364af7df84a77ab5cca54b1442
>>>>> [2/3] ALSA: control-led: Integrate mute led trigger
>>>>> commit: ba8adb1646ee498029ac12b20e792d9d0dd17920
>>>>> [3/3] leds: trigger: audio: Remove this trigger
>>>>> commit: 2c61168294d0ea42a5542dbc864afb03a76bbc11
>>>>
>>>> Submitted for build testing.
>>>>
>>>> Once succeeded, a PR will follow for other maintainers to pull from.
>>>
>>> make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=x86_64 SRCARCH=x86 CROSS_COMPILE=x86_64-linux-gnu- 'CC=sccache x86_64-linux-gnu-gcc' 'HOSTCC=sccache gcc' allmodconfig
>>> make --silent --keep-going --jobs=8 O=/home/tuxbuild/.cache/tuxmake/builds/1/build ARCH=x86_64 SRCARCH=x86 CROSS_COMPILE=x86_64-linux-gnu- 'CC=sccache x86_64-linux-gnu-gcc' 'HOSTCC=sccache gcc'
>>> x86_64-linux-gnu-ld: warning: arch/x86/entry/vdso/vclock_gettime-x32.o: corrupt GNU_PROPERTY_TYPE (5) size: 0x10
>>> x86_64-linux-gnu-ld: warning: arch/x86/entry/vdso/vgetcpu-x32.o: corrupt GNU_PROPERTY_TYPE (5) size: 0x10
>>> /builds/linux/drivers/platform/x86/dell/dell-laptop.c: In function 'dell_init':
>>> /builds/linux/drivers/platform/x86/dell/dell-laptop.c:2255:33: error: implicit declaration of function 'ledtrig_audio_get'; did you mean 'led_trigger_set'? [-Werror=implicit-function-declaration]
>>> micmute_led_cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
>>> ^~~~~~~~~~~~~~~~~
>>> led_trigger_set
>>> cc1: all warnings being treated as errors
>>> make[7]: *** [/builds/linux/scripts/Makefile.build:243: drivers/platform/x86/dell/dell-laptop.o] Error 1
>>> make[7]: Target 'drivers/platform/x86/dell/' not remade because of errors.
>>> make[6]: *** [/builds/linux/scripts/Makefile.build:481: drivers/platform/x86/dell] Error 2
>>> /builds/linux/drivers/platform/x86/huawei-wmi.c: In function 'huawei_wmi_leds_setup':
>>> /builds/linux/drivers/platform/x86/huawei-wmi.c:313:28: error: implicit declaration of function 'ledtrig_audio_get'; did you mean 'led_trigger_set'? [-Werror=implicit-function-declaration]
>>> huawei->cdev.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
>>> ^~~~~~~~~~~~~~~~~
>>> led_trigger_set
>>> cc1: all warnings being treated as errors
>>> make[6]: *** [/builds/linux/scripts/Makefile.build:243: drivers/platform/x86/huawei-wmi.o] Error 1
>>> /builds/linux/drivers/platform/x86/asus-wmi.c: In function 'asus_wmi_led_init':
>>> /builds/linux/drivers/platform/x86/asus-wmi.c:1623:34: error: implicit declaration of function 'ledtrig_audio_get'; did you mean 'led_trigger_set'? [-Werror=implicit-function-declaration]
>>> asus->micmute_led.brightness = ledtrig_audio_get(LED_AUDIO_MICMUTE);
>>> ^~~~~~~~~~~~~~~~~
>>> led_trigger_set
>>> cc1: all warnings being treated as errors
>>> make[6]: *** [/builds/linux/scripts/Makefile.build:243: drivers/platform/x86/asus-wmi.o] Error 1
>>> /builds/linux/drivers/platform/x86/thinkpad_acpi.c: In function 'mute_led_init':
>>> /builds/linux/drivers/platform/x86/thinkpad_acpi.c:9288:33: error: implicit declaration of function 'ledtrig_audio_get'; did you mean 'led_trigger_set'? [-Werror=implicit-function-declaration]
>>> mute_led_cdev[i].brightness = ledtrig_audio_get(i);
>>> ^~~~~~~~~~~~~~~~~
>>> led_trigger_set
>>>
>>> ############################3
>>>
>>> Errors were caused
>>>
>>> [v6.8-rc1] ib-leds-mips-sound-6.9 2c61168294d0e ("leds: trigger: audio: Remove this trigger")
>>>
>>> x86_64 allmodconfig gcc-8
>>> https://storage.tuxsuite.com/public/google/lee.jones/builds/2dGhtQpYDimIIpMqO0Qm4AMAAPU/ Pass (0 errors - 2 warnings) : v6.8-rc1
>>> https://storage.tuxsuite.com/public/google/lee.jones/builds/2dGhvxgZA6moBZmToTavyY4Eita/ Fail (7 errors - 2 warnings) : ib-leds-mips-sound-6.9
>>>
>>> x86_64 allmodconfig gcc-9
>>> https://storage.tuxsuite.com/public/google/lee.jones/builds/2dGhtYCYEqxnUFmoH73iKlcEIV8/ Pass (0 errors - 0 warnings) : v6.8-rc1
>>> https://storage.tuxsuite.com/public/google/lee.jones/builds/2dGhw2i4B539YZXCoSN2LSRvsW8/ Fail (7 errors - 0 warnings) : ib-leds-mips-sound-6.9
>>>
>>> x86_64 allyesconfig gcc-8
>>> https://storage.tuxsuite.com/public/google/lee.jones/builds/2dGhtTzCsCxRpl9loRyfPrD1uhR/ Pass (0 errors - 2 warnings) : v6.8-rc1
>>> https://storage.tuxsuite.com/public/google/lee.jones/builds/2dGhw1WQ2BIpJRoyK7ruVCtihSN/ Fail (7 errors - 2 warnings) : ib-leds-mips-sound-6.9
>>>
>>
>> Right, I forgot, there are patches applied via a different tree end of January,
>> that this series depends on. I assume this means that the series can be applied
>> only after the merge window.
>
> Yes, unless there is a succinct immutable branch I can pull from.
>
I'm not aware of such a branch. 6.9-rc1 isn't too far away, so let's wait for it.
next prev parent reply other threads:[~2024-03-08 17:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 20:56 [PATCH v2 0/3] leds: trigger: Improve handling of led_trigger_event() and simplify mute audio trigger Heiner Kallweit
2024-03-04 20:57 ` [PATCH v2 1/3] leds: trigger: Store brightness set by led_trigger_event() Heiner Kallweit
2024-03-04 20:58 ` [PATCH v2 2/3] ALSA: control-led: Integrate mute led trigger Heiner Kallweit
2024-03-04 20:59 ` [PATCH v2 3/3] leds: trigger: audio: Remove this trigger Heiner Kallweit
2024-03-05 9:08 ` [PATCH v2 0/3] leds: trigger: Improve handling of led_trigger_event() and simplify mute audio trigger Takashi Iwai
2024-03-05 12:08 ` Lee Jones
2024-03-05 12:09 ` Lee Jones
2024-03-05 14:54 ` Lee Jones
2024-03-05 15:56 ` Heiner Kallweit
2024-03-05 16:06 ` Lee Jones
2024-03-08 17:30 ` Heiner Kallweit [this message]
2024-03-27 12:08 ` Heiner Kallweit
2024-03-27 13:14 ` Lee Jones
2024-03-28 10:42 ` Lee Jones
2024-04-05 9:22 ` Heiner Kallweit
2024-04-11 9:22 ` Lee Jones
2024-04-11 15:44 ` [GIT PULL] Immutable branch between MFD, MIPS and Sound due for the v6.10 merge window Lee Jones
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9c256c60-3baa-429f-979b-8e60ef03fed3@gmail.com \
--to=hkallweit1@gmail.com \
--cc=lee@kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=tsbogend@alpha.franken.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).