drivers/acpi/acpica/pswalk.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
From: David Laight <david.laight.linux@gmail.com>
The debug code in acpi_ps_delete_parse_tree() uses ("%*.s", level * 4, " ")
to indent traces.
POSIX requires the empty precision be treated as zero, but the kernel treats
is as 'no precision specified'.
Change to ("%*s", level * 4, "") since there is additional whitespace and no
reason to indent by one space when level is zero.
Signed-off-by: David Laight <david.laight.linux@gmail.com>
---
drivers/acpi/acpica/pswalk.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/pswalk.c b/drivers/acpi/acpica/pswalk.c
index 2f3ebcd8aebe..b1ec75e277ab 100644
--- a/drivers/acpi/acpica/pswalk.c
+++ b/drivers/acpi/acpica/pswalk.c
@@ -49,8 +49,7 @@ void acpi_ps_delete_parse_tree(union acpi_parse_object *subtree_root)
/* This debug option will print the entire parse tree */
- acpi_os_printf(" %*.s%s %p", (level * 4),
- " ",
+ acpi_os_printf(" %*s%s %p", (level * 4), "",
acpi_ps_get_opcode_name(op->
common.
aml_opcode),
--
2.39.5
On Thu 2026-03-26 20:18:30, david.laight.linux@gmail.com wrote:
> From: David Laight <david.laight.linux@gmail.com>
>
> The debug code in acpi_ps_delete_parse_tree() uses ("%*.s", level * 4, " ")
> to indent traces.
> POSIX requires the empty precision be treated as zero, but the kernel treats
> is as 'no precision specified'.
> Change to ("%*s", level * 4, "") since there is additional whitespace and no
> reason to indent by one space when level is zero.
>
> --- a/drivers/acpi/acpica/pswalk.c
> +++ b/drivers/acpi/acpica/pswalk.c
> @@ -49,8 +49,7 @@ void acpi_ps_delete_parse_tree(union acpi_parse_object *subtree_root)
>
> /* This debug option will print the entire parse tree */
>
> - acpi_os_printf(" %*.s%s %p", (level * 4),
> - " ",
> + acpi_os_printf(" %*s%s %p", (level * 4), "",
> acpi_ps_get_opcode_name(op->
> common.
> aml_opcode),
The change has no visible effect. The precision defines how many
characters are copied from the given string. It does not matter
here because the given string is empty "". The number of added
spaces ' ' is defined by the field width parameter (level * 4).
Anyway, the change makes sense:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
On Thu, Mar 26, 2026 at 08:18:30PM +0000, david.laight.linux@gmail.com wrote:
> The debug code in acpi_ps_delete_parse_tree() uses ("%*.s", level * 4, " ")
> to indent traces.
> POSIX requires the empty precision be treated as zero, but the kernel treats
> is as 'no precision specified'.
> Change to ("%*s", level * 4, "") since there is additional whitespace and no
> reason to indent by one space when level is zero.
This is cross-platform code. Does the same applies to MS VC compiler, for
example?
--
With Best Regards,
Andy Shevchenko
On Fri, 27 Mar 2026 11:28:26 +0200
Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Thu, Mar 26, 2026 at 08:18:30PM +0000, david.laight.linux@gmail.com wrote:
>
> > The debug code in acpi_ps_delete_parse_tree() uses ("%*.s", level * 4, " ")
> > to indent traces.
> > POSIX requires the empty precision be treated as zero, but the kernel treats
> > is as 'no precision specified'.
> > Change to ("%*s", level * 4, "") since there is additional whitespace and no
> > reason to indent by one space when level is zero.
>
> This is cross-platform code. Does the same applies to MS VC compiler, for
> example?
>
Everything except the linux kernel will treat "%*.s" as "%*.0s".
Regardless of anything else specifying a 'precision' when printing
a constant string is entirely pointless - it limits the number of
characters copied from the string.
Basically "%*.s" is always a typo, either for "%.*s" or "%*s".
David
On Fri, Mar 27, 2026 at 10:45 AM David Laight
<david.laight.linux@gmail.com> wrote:
>
> On Fri, 27 Mar 2026 11:28:26 +0200
> Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>
> > On Thu, Mar 26, 2026 at 08:18:30PM +0000, david.laight.linux@gmail.com wrote:
> >
> > > The debug code in acpi_ps_delete_parse_tree() uses ("%*.s", level * 4, " ")
> > > to indent traces.
> > > POSIX requires the empty precision be treated as zero, but the kernel treats
> > > is as 'no precision specified'.
> > > Change to ("%*s", level * 4, "") since there is additional whitespace and no
> > > reason to indent by one space when level is zero.
> >
> > This is cross-platform code. Does the same applies to MS VC compiler, for
> > example?
> >
>
> Everything except the linux kernel will treat "%*.s" as "%*.0s".
>
> Regardless of anything else specifying a 'precision' when printing
> a constant string is entirely pointless - it limits the number of
> characters copied from the string.
>
> Basically "%*.s" is always a typo, either for "%.*s" or "%*s".
So this change should be made in upstream ACPICA in the first place as
per Documentation/driver-api/acpi/linuxized-acpica.rst.
Would you please send a PR to the upstream ACPICA project on GH?
Alternatively, someone else may make that change upstream with a
Suggested-by tag pointing to you.
On Fri, 27 Mar 2026 10:58:14 +0100
"Rafael J. Wysocki" <rafael@kernel.org> wrote:
> On Fri, Mar 27, 2026 at 10:45 AM David Laight
> <david.laight.linux@gmail.com> wrote:
> >
> > On Fri, 27 Mar 2026 11:28:26 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >
> > > On Thu, Mar 26, 2026 at 08:18:30PM +0000, david.laight.linux@gmail.com wrote:
> > >
> > > > The debug code in acpi_ps_delete_parse_tree() uses ("%*.s", level * 4, " ")
> > > > to indent traces.
> > > > POSIX requires the empty precision be treated as zero, but the kernel treats
> > > > is as 'no precision specified'.
> > > > Change to ("%*s", level * 4, "") since there is additional whitespace and no
> > > > reason to indent by one space when level is zero.
> > >
> > > This is cross-platform code. Does the same applies to MS VC compiler, for
> > > example?
> > >
> >
> > Everything except the linux kernel will treat "%*.s" as "%*.0s".
> >
> > Regardless of anything else specifying a 'precision' when printing
> > a constant string is entirely pointless - it limits the number of
> > characters copied from the string.
> >
> > Basically "%*.s" is always a typo, either for "%.*s" or "%*s".
>
> So this change should be made in upstream ACPICA in the first place as
> per Documentation/driver-api/acpi/linuxized-acpica.rst.
>
> Would you please send a PR to the upstream ACPICA project on GH?
I'd have to go through a lot of hoops to do that.
I've never used GH.
David
> Alternatively, someone else may make that change upstream with a
> Suggested-by tag pointing to you.
On Fri, Mar 27, 2026 at 11:58 AM David Laight
<david.laight.linux@gmail.com> wrote:
>
> On Fri, 27 Mar 2026 10:58:14 +0100
> "Rafael J. Wysocki" <rafael@kernel.org> wrote:
>
> > On Fri, Mar 27, 2026 at 10:45 AM David Laight
> > <david.laight.linux@gmail.com> wrote:
> > >
> > > On Fri, 27 Mar 2026 11:28:26 +0200
> > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > > On Thu, Mar 26, 2026 at 08:18:30PM +0000, david.laight.linux@gmail.com wrote:
> > > >
> > > > > The debug code in acpi_ps_delete_parse_tree() uses ("%*.s", level * 4, " ")
> > > > > to indent traces.
> > > > > POSIX requires the empty precision be treated as zero, but the kernel treats
> > > > > is as 'no precision specified'.
> > > > > Change to ("%*s", level * 4, "") since there is additional whitespace and no
> > > > > reason to indent by one space when level is zero.
> > > >
> > > > This is cross-platform code. Does the same applies to MS VC compiler, for
> > > > example?
> > > >
> > >
> > > Everything except the linux kernel will treat "%*.s" as "%*.0s".
> > >
> > > Regardless of anything else specifying a 'precision' when printing
> > > a constant string is entirely pointless - it limits the number of
> > > characters copied from the string.
> > >
> > > Basically "%*.s" is always a typo, either for "%.*s" or "%*s".
> >
> > So this change should be made in upstream ACPICA in the first place as
> > per Documentation/driver-api/acpi/linuxized-acpica.rst.
> >
> > Would you please send a PR to the upstream ACPICA project on GH?
>
> I'd have to go through a lot of hoops to do that.
> I've never used GH.
OK, we'll go for the second option then.
> > Alternatively, someone else may make that change upstream with a
> > Suggested-by tag pointing to you.
© 2016 - 2026 Red Hat, Inc.