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: <66bb61ca-94ae-7f0a-ce9f-f5c13b51eb01@linux.intel.com>
Date: Wed, 15 Oct 2025 15:06:25 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Denis Benato <benato.denis96@...il.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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ