linux-kernel - Re: [PATCH v2] apple-gmux: preserve brightness using EFI

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] [day] [month] [year] [list]

Message-ID: <aYRYRLcf5fgWimDJ@wunner.de>
Date: Thu, 5 Feb 2026 09:43:48 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Atharva Tiwari <atharvatiwarilinuxdev@...il.com>
Cc: hansg@...nel.org, ilpo.jarvinen@...ux.intel.com,
	linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v2] apple-gmux: preserve brightness using EFI

On Wed, Feb 04, 2026 at 06:28:15PM +0000, Atharva Tiwari wrote:
> > Finally, there are Macs which don't have a gmux but which do have a
> > backlight.  They usually control brightness through i915 I think.
> > It would be nice to save brightness to the EFI variable on those as well.
> 
> There should be something for Amdgpus aswell for mac pro, but i cant
> test i915 nor amdgpu, as i dont have these devices. so i think we should
> currently drop this idea.

The ask is not that you should implement something you can't test.
The ask is that you should implement it in a way that is extensible
to be used by i915 and other drivers once someone comes along who can
test it.

I'd suggest adding a new drivers/firmware/efi/apple-bl.c which contains
all the logic to update the variable using a delayed work item.  It could
provide an API call which apple-gmux invokes.  Then i915 and amdgpu can
be retrofitted later on to invoke the API call as well.

Assuming that the new .c file is gated by a new CONFIG_EFI_APPLE_BL symbol,
CONFIG_APPLE_GMUX should "select EFI_APPLE_BL if EFI".

I think there are other EFI variables to store backlight brightness
of the keyboard and so on, so if you anticipate that you or someone
else may later on support those as well, then a more generic solution
would be a drivers/firmware/efi/apple-vars.c file instead of apple-bl.c.

> This function actually writes 6 bytes, which is u32 efi_attr (first 32-bits)
> and u16 efi_data (last 16-bits), but im confused about the fact, that the
> hexdumps show that ur attr are different. the attr should be 07 00 00 00
> but its 07 00 00 80, i think we should retrieve the attr in the probe
> function and use that for writing.

That could just be done in an initcall if you pursue the architecture
outlined above.

Thanks,

Lukas