All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Scardovi <scardracs@disroot.org>
To: Hans de Goede <hansg@kernel.org>,
	platform-driver-x86@vger.kernel.org,
	Denis Benato <denis.benato@linux.dev>
Cc: luke@ljones.dev, ilpo.jarvinen@linux.intel.com,
	corentin.chary@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] platform/x86: asus-armoury: add Whisper Mode support
Date: Wed, 29 Jul 2026 16:43:32 +0200	[thread overview]
Message-ID: <wArK7qMITou2-I6Hv4EmsA@disroot.org> (raw)
In-Reply-To: <a2efcc14-c4a5-4b16-9fed-c01176cc34b6@linux.dev>

In data mercoledì 29 luglio 2026 15:34:28 Ora legale dell’Europa centrale, Denis Benato ha scritto:
> 
> On 7/29/26 15:22, Marco Scardovi wrote:
> > In data mercoledì 29 luglio 2026 15:10:56 Ora legale dell’Europa centrale, Denis Benato ha scritto:
> >> On 7/29/26 09:32, Hans de Goede wrote:
> >>> Hi Marco,
> >>>
> >>> On 28-Jul-26 15:56, Marco Scardovi wrote:
> >>>> In data martedì 28 luglio 2026 13:39:39 Ora legale dell’Europa centrale, Hans 
> >>>> de Goede ha scritto:
> >>>>> Hi,
> >>>>>
> >>>>> Thank you for your patch.
> >>>>>
> >>>>> On 28-Jul-26 09:18, Marco Scardovi wrote:
> >>>>>> This series introduces support for ASUS WMI Whisper Mode hardware controls
> >>>>>> in the asus-wmi header and asus-armoury driver.
> >>>>>>
> >>>>>> Background & Findings:
> >>>>>> ----------------------
> >>>>>> After talking with Denis and thanks to NeuroMarshal reverse engineering
> >>>>>> and
> >>>>>> firmware trace analysis on modern ASUS laptops, three specific WMI Device
> >>>>>> IDs were identified that manage acoustic profiles and thermal regulation
> >>>>>> under ASUS Whisper Mode:
> >>>>>>
> >>>>>> 1. ASUS_WMI_DEVID_WHISPER_MODE (0x0012007A):
> >>>>>>    - Controls the BIOS-level Whisper Mode acoustic profile toggle
> >>>>>>    (read/write boolean).> 
> >>>>>> 2. ASUS_WMI_DEVID_WHISPER_ENABLE (0x00090022):
> >>>>>>    - Enables or disables Dynamic Whisper acoustic regulation (read/write
> >>>>>>    boolean).> 
> >>>>>> 3. ASUS_WMI_DEVID_WHISPER_STATUS (0x00090023):
> >>>>>>    - Reports status and allows runtime control over Dynamic Whisper state
> >>>>>>    (read/write boolean).
> >>>>> I wonder how this interacts with the platform_profile stuff ?
> >>>>>
> >>>>> I would expect enabling whisper mode to lower the max performance,
> >>>>> so does this automatically change the platform_profile away
> >>>>> from performance when it is set to performance ?
> >>>>>
> >>>>> Note the platform_profile API is extensible. To me it seems more
> >>>>> logical to expose this as a whisper mode platform-profile ?
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Hans
> >>>> Hi Hans,
> >>>>
> >>>> Thanks for the feedback!
> >>>> Here you can find my opinions on your questions.
> >>>>
> >>>> 1. Interaction with platform_profile:
> >>>> In ASUS laptops, where presents, Whisper Mode operates as an
> >>>> independent boolean toggle/feature controlling fan acoustic target limits in
> >>>> firmware/EC, rather than acting as a global thermal profile. Setting 
> >>>> WHISPER_MODE or WHISPER_ENABLE via WMI sends a direct call to the EC/BIOS, 
> >>>> which adjusts acoustic thresholds internally without altering the active 
> >>>> platform_profile state (throttle_thermal_policy) in asus-wmi. IIRC on Windows 
> >>>> it even permits to "hear" the ambient to make the fans run in a way to blend 
> >>>> with the ambient noise.
> >>>>
> >>>> 2. platform_profile vs firmware_attributes (asus-armoury):
> >>>> platform_profile is designed for mutually exclusive global power/thermal
> >>>> modes (Quiet, Balanced, Performance). Whisper Mode, on the other hand, 
> >>>> consists of independent BIOS feature toggles (0/1 controls for BIOS Whisper 
> >>>> Mode, Dynamic Whisper Enable, and Status).
> >>>> Since asus-armoury is dedicated to exposing BIOS/Armoury Crate firmware
> >>>> attributes via fw_attributes_class (similar to nv_dynamic_boost,
> >>>> nv_temp_target, panel_od, etc.), exposing these three WMI controls as
> >>>> sysfs firmware attributes fits the overall design of asus-armoury much
> >>>> better than extending platform_profile.
> >>>>
> >>>> I hope I've been of help. Feel free to let me know if you have more 
> >>>> questions: I'll try to answer the best of my capacities.
> >>> Thank you for clarifying things. Since the EC/BIOS interface sees this
> >>> as 2 independent settings, I agree that exposing this as a firmware
> >>> attr is the best way to expose this.
> >>>
> >>> Its a bit weird that one can select Performance profile and enable
> >>> whisper mode at the same time. But if that is how the Asus firmware
> >>> interfaces work, then that is how it is.
> >> Hello Hans and Marco,
> >>
> >> I agree that this is weird and we don't have a device with whisper mode,
> >> but there is the possibility of the official windows app allowing whisper mode
> >> only on certain modes: we would need to find someone with windows
> >> to confirm this, but I also don't think binding whisper to quiet/low performance
> >> is a bad idea.
> >>
> >> My opinion is that either whisper gets its own profile and is a combination of
> >> quiet + whisper set to 1 or we check what windows does since I don't want
> >> to have hardware running in configurations that ASUS never intended to.
> >>
> >> Best regards,
> >> Denis
> >>> Regards,
> >>>
> >>> Hans
> >>>
> >>>
> > Hi Denis,
> > I made more checks on Whisper Mode and find out why it isn't under a single
> > power profile: it works the contrary of power profiles.
> >
> > To be more specific: while power profiles tends to match the fans with the
> > TDP, in Whisper Mode it sets the max power (if under performance) but cut
> > it if the dB/RPMs are too high to respect the Whisper Mode. So it basically
> > works for any power profiles but instead of pushing up the fans to cool the
> > CPU/GPU, it kills the power to maintain the loudness in check
> Alright, perfect.
> > Let me know if it is a feature you want or not. If we end up deciding to kill
> > it feel free to let me know.
> Yes I want this to be in the kernel: I simply don't want to do things that
> were never intended to be done, other than that I have no reservations.
> 
> So you have my OK with these.
> 
> 
> Thank you,
> Denis
> 
> > Best regards,
> > Marco
> >
> >
> 
Hi everyone,

I've made more and more studies about Whisper Mode and dumped my own laptop
to set my mind straight about Whisper Mode, because I had some more doubts
about it.

TL;DR: Adding Whisper Mode is not useful for our drivers.
TL;DR 2: Whisper Mode enables only when power profile Quiet is set.

Whole version:
After dumping the ACPI DSDT tables and testing runtime calls via a diagnostic 
module on real hardware, I verified that the Embedded Controller (EC) automatically 
manages Whisper Mode acoustic capping whenever `platform_profile` is set to "quiet" 
(thermal policy 0x00120075 = 2).

This behavior applies to both internal hardware and connected eGPUs. Because the 
EC handles Whisper Mode natively within the quiet profile, discrete queries/writes 
to WMI IDs 0x0012007A and 0x00090022 return 0xFFFFFFFE (unsupported). 

Therefore, exposing standalone Whisper Mode sysfs attributes is unnecessary, 
as `platform_profile = quiet` already provides full Whisper Mode functionality.

Best regards,
Marco



      reply	other threads:[~2026-07-29 14:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  7:18 [PATCH 0/2] platform/x86: asus-armoury: add Whisper Mode support Marco Scardovi
2026-07-28  7:18 ` [PATCH 1/2] platform/x86: asus-wmi: add Whisper Mode WMI device ID defines Marco Scardovi
2026-07-28  7:18 ` [PATCH 2/2] platform/x86: asus-armoury: add Whisper Mode attributes Marco Scardovi
2026-07-28 11:39 ` [PATCH 0/2] platform/x86: asus-armoury: add Whisper Mode support Hans de Goede
2026-07-28 13:56   ` Marco Scardovi
2026-07-29  7:32     ` Hans de Goede
2026-07-29 13:10       ` Denis Benato
2026-07-29 13:22         ` Marco Scardovi
2026-07-29 13:34           ` Denis Benato
2026-07-29 14:43             ` Marco Scardovi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wArK7qMITou2-I6Hv4EmsA@disroot.org \
    --to=scardracs@disroot.org \
    --cc=corentin.chary@gmail.com \
    --cc=denis.benato@linux.dev \
    --cc=hansg@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luke@ljones.dev \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.