Message-ID: <ada4c640-1d35-4e79-bc00-e88bc60f646d@gmail.com>
Date: Wed, 15 Oct 2025 14:27:20 +0200
From: Denis Benato <benato.denis96@...il.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Mario Limonciello <mario.limonciello@....com>,
 LKML <linux-kernel@...r.kernel.org>, platform-driver-x86@...r.kernel.org,
 Hans de Goede <hdegoede@...hat.com>, "Luke D . Jones" <luke@...nes.dev>,
 Alok Tiwari <alok.a.tiwari@...cle.com>,
 Derek John Clark <derekjohn.clark@...il.com>,
 Mateusz Schyboll <dragonn@...pl>, porfet828@...il.com
Subject: Re: [PATCH v14 0/9] platform/x86: Add asus-armoury driver


On 10/15/25 14:06, Ilpo Järvinen wrote:
> On Wed, 15 Oct 2025, Denis Benato wrote:
>
>> On 10/15/25 11:38, Ilpo Järvinen wrote:
>>> On Wed, 15 Oct 2025, Mario Limonciello wrote:
>>>> On 10/14/2025 8:47 PM, Denis Benato wrote:
>>>>> Hi all,
>>>>>
>>>>> the TL;DR:
>>>>> 1. Introduce new module to contain bios attributes, using
>>>>> fw_attributes_class
>>>>> 2. Deprecate all possible attributes from asus-wmi that were added ad-hoc
>>>>> 3. Remove those in the next LTS cycle
>>>>>
>>>>> The idea for this originates from a conversation with Mario Limonciello
>>>>> https://lore.kernel.org/platform-driver-x86/371d4109-a3bb-4c3b-802f-4ec27a945c99@amd.com/
>>>>>
>>>>> It is without a doubt much cleaner to use, easier to discover, and the
>>>>> API is well defined as opposed to the random clutter of attributes I had
>>>>> been placing in the platform sysfs. Given that Derek is also working on a
>>>>> similar approach to Lenovo in part based on my initial work I'd like to
>>>>> think
>>>>> that the overall approach is good and may become standardised for these
>>>>> types
>>>>> of things.
>>>>>
>>>>> Regarding PPT: it is intended to add support for "custom" platform profile
>>>>> soon. If it's a blocker for this patch series being accepted I will drop the
>>>>> platform-x86-asus-armoury-add-ppt_-and-nv_-tuning.patch and get that done
>>>>> separately to avoid holding the bulk of the series up. Ideally I would like
>>>>> to get the safe limits in so users don't fully lose functionality or
>>>>> continue
>>>>> to be exposed to potential instability from setting too low, or be mislead
>>>>> in to thinking they can set limits higher than actual limit.
>>>>>
>>>>> The bulk of the PPT patch is data, the actual functional part is relatively
>>>>> small and similar to the last version.
>>>>>
>>>>> Unfortunately I've been rather busy over the months and may not cover
>>>>> everything in the v7 changelog but I've tried to be as comprehensive as I
>>>>> can.
>>>>>
>>>>> Regards,
>>>>> Luke
>>>> As a general comment that applies to a few patches in the series.
>>>>
>>>> The S-o-b means that YOU sign off on them, it's like a chain of custody.
>>>>
>>>> Any patches that you're sending need your own S-o-B, even if they're 100% the
>>>> same as the original from Luke.
>>> There's also Co-developed-by tag which may be appropriate in cases where 
>>> both have touched the patch.
>>>
>> I have re-read the submission documentation and confirmed I need at least
>> S-o-b for all of them. Is it acceptable if I simply answer to the email with my S-o-b
>> and Co-developed-by (on patches I have touched) or do I need to resend
>> the whole patchset creating a v15?
> Hi Denis,
>
> Please wait a bit with v15, I'll try to take a look at this series 
> hopefully before the end of this week and I suspect there will be more 
> changes needed as a result (not to doubt your effort but it's long time 
> since I've looked at it).
>
Sure! I will fix everything that needs fixing! I'm just happy seeing progress
since this is a work that is both extensively used (valve and other distros)
and very requested.

Thanks for your time!

Powered by blists - more mailing lists