[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1a33c7a6-a04d-4c53-b8f2-02431a1073b3@amd.com>
Date: Tue, 28 May 2024 16:37:56 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Luke Jones <luke@...nes.dev>, Hans de Goede <hdegoede@...hat.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: corentin.chary@...il.com, platform-driver-x86@...r.kernel.org,
linux-kernel@...r.kernel.org, richard@...hsie.com
Subject: Re: [PATCH 8/9] platform/x86: asus-wmi: add apu_mem setting
On 5/28/2024 16:34, Luke Jones wrote:
>
>
> On Wed, 29 May 2024, at 9:16 AM, Mario Limonciello wrote:
>>>> For any "new" attributes it's better to put them in that API than code
>>>> duplication of the BIOS attributes API as well as a random sysfs file
>>>> API that you can never discard.
>>>
>>> Do you mean the firmware_attributes API? If so, I'm not opposed to adding all the existing ROG attributes to it also.
>>>
>>> If I'm understanding the docs correctly, for example this apu_mem attr would then become:
>>> - /sys/class/firmware-attributes/asus-bios/attributes/apu_mem/type
>>> - /sys/class/firmware-attributes/*/attributes/apu_mem/current_value
>>> - /sys/class/firmware-attributes/*/attributes/apu_mem/default_value
>>> - /sys/class/firmware-attributes/*/attributes/apu_mem/display_name
>>> - /sys/class/firmware-attributes/*/attributes/apu_mem/possible_values
>>> - ..etc
>>>
>>> That's absolutely much better than what I've been doing and I wish I'd known about it sooner.
>>
>> Yup! And even better "fwupdmgr get-bios-setting" and "fwupdmgr
>> set-bios-setting" [1] will work with bash completion too.
>>
>> If you want to build a GUI around it, it could use the fwupd dbus
>> interface for getting those settings and manipulating them.
>
> My existing GUI effort revolves around me adding these attrs to both kernel and a dbus interface. So if I can drop that then all the better
Awesome! You can either use libfwupd or the dbus interface. After
you're done with the kernel work ping me or Richard if you have problems.
>
>> The dbus
>> interface policy is protected by PK.
>
> What is PK? And I'm guessing this restricts users to requiring permissions to change settings?
>
Whoops forgot to respond to these.
PK = PolicyKit.
Powered by blists - more mailing lists