Re: [PATCH] platform/x86: asus-armoury: downgrade missing power limits warning to debug

Re: [PATCH] platform/x86: asus-armoury: downgrade missing power limits warning to debug

[Ilpo Järvinen]

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


-- 
 i.

Re: [PATCH] platform/x86: asus-armoury: downgrade missing power limits warning to debug

[Denis Benato]

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?

My current opinion is that instead of demoting it from a warning I should perhaps phrase it better
as Mario suggests.

Denis

Re: [PATCH] platform/x86: asus-armoury: downgrade missing power limits warning to debug

[Ilpo Järvinen]

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