[RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys

[Aditya Garg]

On 10/29/26 8:23 PM, Sasha Finkelstein wrote:
> On Oct 29, 2026, at 15:39, Atharva Tiwari <atharvatiwarilinuxdev at gmail.com> 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?