linux-kernel - Re: [PATCH v14 0/9] platform/x86: Add asus-armoury driver

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

Message-ID: <97c56897-ed9b-4d4d-ba54-d6e2abbc8b0d@gmail.com>
Date: Wed, 15 Oct 2025 14:00:46 +0200
From: Denis Benato <benato.denis96@...il.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Mario Limonciello <mario.limonciello@....com>
Cc: 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 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?

Thanks,
Denis