From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Denis Benato <denis.benato@linux.dev>
Cc: Armandas Kvietkus <armundunelis@gmail.com>,
luke@ljones.dev, Hans de Goede <hansg@kernel.org>,
platform-driver-x86@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
fxzxaxon@outlook.com
Subject: Re: [PATCH] platform/x86: asus-armoury: downgrade missing power limits warning to debug
Date: Thu, 7 May 2026 16:56:01 +0300 (EEST) [thread overview]
Message-ID: <2e6d1880-fd4c-e00d-3042-0913bedb7456@linux.intel.com> (raw)
In-Reply-To: <dfe28a80-6ce8-4bba-b151-3c24d385782c@linux.dev>
[-- Attachment #1: Type: text/plain, Size: 4221 bytes --]
On Wed, 6 May 2026, Denis Benato wrote:
> On 5/6/26 13:26, Ilpo Järvinen wrote:
> > On Mon, 4 May 2026, Denis Benato wrote:
> >> On 5/3/26 19:57, Armandas Kvietkus wrote:
> >>> When a system is not found in the power_limits DMI table,
> >>> init_rog_tunables() emits a pr_warn() and returns. This is
> >>> expected behaviour for hardware that does not support ROG
> >>> power limit tunables, not an error condition.
> >>>
> >>> Downgrade to pr_debug() to avoid spurious boot noise on
> >>> unsupported systems while preserving the message for debugging.
> >>>
> >>> Reported-by: fxzxaxon@outlook.com
> >>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221441
> >>> Signed-off-by: Armandas Kvietkus <armundunelis@gmail.com>
> >>> ---
> >>> drivers/platform/x86/asus-armoury.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/platform/x86/asus-armoury.c b/drivers/platform/x86/asus-armoury.c
> >>> index 5b0987ccc..c8e9ff89f 100644
> >>> --- a/drivers/platform/x86/asus-armoury.c
> >>> +++ b/drivers/platform/x86/asus-armoury.c
> >>> @@ -991,7 +991,7 @@ static void init_rog_tunables(void)
> >>> /* Match the system against the power_limits table */
> >>> dmi_id = dmi_first_match(power_limits);
> >>> if (!dmi_id) {
> >>> - pr_warn("No matching power limits found for this system\n");
> >>> + pr_debug("No matching power limits found for this system\n");
> >> Maybe this is right to get downgraded, but still no debug: I think info is better,
> >> but I would like to hear from Luke what this is about.
> > Hi Denis,
> >
> > When kernel is built with CONFIG_DYNAMIC_DEBUG=y, all debug messages
> > will appear if kernel's cmdline enables it:
> >
> > dyndbg="file drivers/platform/x86/asus-armoury.c +p"
> >
> > (wildcards too could be used where helpful and semicolon as a separator
> > if, in rare cases, more than one filter should be necessary).
> >
> > So all we need is to ask the reporter to boot with dyndbg enabled for the
> > relevant file(s), no recompiling the kernel required.
> >
> >
> > I suspect most distros do have dynamic debugging capability in their
> > kernel configs so it shouldn't be a problem when they don't by default
> > show these messages (at least the two major ones I just checked have it).
> >
> Hi!
>
> My position is that the experience of most users is:
> they boot linux, install asusctl, notice that not only is less fancy than the windows counterpart,
> but it also lacks TDP sliders so they enter in discord and ask "why can't I control my TDP".
>
> As of now one just answers "dmesg | grep asus" and the warning appears, while if this becomes a debug
> the process becomes more involved, for both parts, as most people know dmesg, but a person randomly
> hanging in the discord doesn't usually know how to enable dynamic debugging, or how to reconfigure
> a bootloader. I surely don't know how to configure every bootloader under the sun for every major distro.
>
> My point of view is that said warning guided someone straight to me, so it reached its objective effectively,
> why changing something that works?
>
> The only reason I can think of is people who run with panic on warning, but since I have yet to see an asus
> laptop that doesn't make linux spam a bunch of acpi errors and warnings such a kernel (as of now) is
> unbootable on these machines.
>
> Perhaps you have a stronger motivation and can point me to it?
I don't have strong motivation here, other than shooting down the false
claim that debug level messages are not available when it comes to distro
settings.
Debug message can be enabled also through
/sys/kernel/debug/dynamic_debug/control
...but yes, there will be more steps in that case too as that requires
mounting debugfs, and reloading the driver too to retrigger the message
(and I'm not sure if the userspace program likes that, etc. :-)).
So I understand if you prefer to not go there.
> My current opinion is that instead of demoting it from a warning I should perhaps phrase it better
> as Mario suggests.
I don't have a problem with the message wording myself.
--
i.
prev parent reply other threads:[~2026-05-07 13:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260503175734.27795-1-armundunelis@gmail.com>
[not found] ` <6460ef7c-b4d9-4106-95cc-35710b4798bb@linux.dev>
2026-05-06 11:26 ` [PATCH] platform/x86: asus-armoury: downgrade missing power limits warning to debug Ilpo Järvinen
2026-05-06 21:44 ` Denis Benato
2026-05-07 13:56 ` Ilpo Järvinen [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=2e6d1880-fd4c-e00d-3042-0913bedb7456@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=armundunelis@gmail.com \
--cc=denis.benato@linux.dev \
--cc=fxzxaxon@outlook.com \
--cc=hansg@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox