Re: [RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys
From: Aditya Garg
Date: Thu Oct 29 2026 - 11:26:30 EST
On 10/29/26 8:23 PM, Sasha Finkelstein wrote:
On Oct 29, 2026, at 15:39, Atharva Tiwari <atharvatiwarilinuxdev@xxxxxxxxx> wrote:
1. The patch is required, atleast on intel macs, as without writing GPU and CPU
states to smc, the system gives PROCHOT signal under small load
, and heats up a lot.
In that case, why are you exposing a generic smc key interface instead
of one that just does that? If you think that this data should be set
from userspace - whitelist the set of keys that are needed.
Whitelisting will create an endless cycle of upstreaming new keys. But considering T2 no longer is receiving updates, Asahi would be happy to send their keys they wish to be whitelisted right ;)>
2. the smc dosent expose keys of nature that can physically damage the system
it only exposes power/volt data, and the most you can poke is reboot
keys and gpu/cpu p-states.
Are you willing to make that claim for every smc-equipped device, not
just T2? Are you willing to make the same claim for future versions of
smc firmware?
Fair enough. We can restrict it to T2 Macs, and Asahi can later adopt if useful?>
3. If a person is randomly touching keys, Its their problem and not ours.
4. There are a lot of things that can mess the system way more and permanently
than smc (undervolting for example), but they are not safe guarded, why
should this be then?
I think it is inadvisable to leave a loaded footgun around and then
blame the user for using it. As an "OS Vendor" you have a duty of care
to your users.
It would say the "duty of care" argument is more of a philosophical thing than a technical argument here. Still, I respect that but there needs to be a balance between adding features and respecting the duty. It seems various vendors have different views in determining the balance. The above 2 arguments look like a good balance. What do you think?