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

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]

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).

-- 
 i.