[PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[David Cohen]

Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
to filter pm debug messages based on pm_debug_messages_on flag.
According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()
which does support dynamic debug.

The problem is if we enable/disable dynamic debug inside __pm_pr_debug()
it will affect all pm_pr_debug() calls at once, so we can't individually
control them.

This patch changes __pm_pr_debug() implementation into macros to make
pr_debug() to be directly called by all pm_pr_debug() cases. As a direct
side effect all pm_pr_debug() can be individually controlled by dynamic
debug feature.

Signed-off-by: David Cohen <dacohen@pm.me>
---
 include/linux/suspend.h | 19 +++++++++++++++----
 kernel/power/main.c     | 29 -----------------------------
 2 files changed, 15 insertions(+), 33 deletions(-)

diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 300273ff40cc..d727d3c867e3 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -542,22 +542,33 @@ static inline void unlock_system_sleep(void) {}
 #ifdef CONFIG_PM_SLEEP_DEBUG
 extern bool pm_print_times_enabled;
 extern bool pm_debug_messages_on;
-extern __printf(2, 3) void __pm_pr_dbg(bool defer, const char *fmt, ...);
+#define __pm_pr_dbg(fmt, ...)					\
+	do {							\
+		if (pm_debug_messages_on)			\
+			pr_debug("PM: " fmt, ##__VA_ARGS__);	\
+	} while(0)
+#define __pm_deferred_pr_dbg(fmt, ...)				\
+	do {							\
+		if (pm_debug_messages_on)			\
+			printk_deferred(KERN_DEBUG "PM: " fmt, ##__VA_ARGS__);	\
+	} while(0)
 #else
 #define pm_print_times_enabled	(false)
 #define pm_debug_messages_on	(false)

 #include <linux/printk.h>

-#define __pm_pr_dbg(defer, fmt, ...) \
+#define __pm_pr_dbg(fmt, ...) \
+	no_printk(KERN_DEBUG fmt, ##__VA_ARGS__)
+#define __pm_deferred_pr_dbg(fmt, ...) \
 	no_printk(KERN_DEBUG fmt, ##__VA_ARGS__)
 #endif

 #define pm_pr_dbg(fmt, ...) \
-	__pm_pr_dbg(false, fmt, ##__VA_ARGS__)
+	__pm_pr_dbg(fmt, ##__VA_ARGS__)

 #define pm_deferred_pr_dbg(fmt, ...) \
-	__pm_pr_dbg(true, fmt, ##__VA_ARGS__)
+	__pm_deferred_pr_dbg(fmt, ##__VA_ARGS__)

 #ifdef CONFIG_PM_AUTOSLEEP

diff --git a/kernel/power/main.c b/kernel/power/main.c
index 7e646079fbeb..5242bf2ee469 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -545,35 +545,6 @@ static int __init pm_debug_messages_setup(char *str)
 }
 __setup("pm_debug_messages", pm_debug_messages_setup);

-/**
- * __pm_pr_dbg - Print a suspend debug message to the kernel log.
- * @defer: Whether or not to use printk_deferred() to print the message.
- * @fmt: Message format.
- *
- * The message will be emitted if enabled through the pm_debug_messages
- * sysfs attribute.
- */
-void __pm_pr_dbg(bool defer, const char *fmt, ...)
-{
-	struct va_format vaf;
-	va_list args;
-
-	if (!pm_debug_messages_on)
-		return;
-
-	va_start(args, fmt);
-
-	vaf.fmt = fmt;
-	vaf.va = &args;
-
-	if (defer)
-		printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
-	else
-		printk(KERN_DEBUG "PM: %pV", &vaf);
-
-	va_end(args);
-}
-
 #else /* !CONFIG_PM_SLEEP_DEBUG */
 static inline void pm_print_times_init(void) {}
 #endif /* CONFIG_PM_SLEEP_DEBUG */
--
2.35.1

Re: [PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[Rafael J. Wysocki]

On Sat, Mar 12, 2022 at 5:37 AM David Cohen <dacohen@pm.me> wrote:
>
> Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
> to filter pm debug messages based on pm_debug_messages_on flag.
> According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
> indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
> support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()

I'm not sure what you mean by pm_pr_debug().  There's no such thing in
the kernel tree.

Assuming that it means pm_pr_dbg(), it doesn't call pr_debug():

#define pm_pr_dbg(fmt, ...) __pm_pr_dbg(false, fmt, ##__VA_ARGS__)

and

void __pm_pr_dbg(bool defer, const char *fmt, ...)
{
...
        if (defer)
               printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
        else
               printk(KERN_DEBUG "PM: %pV", &vaf);

And as I said printk(KERN_DEBUG ...) is not equivalent to
pr_debug(...), because it is not dynamic printk().

pm_pr_dbg() is not dynamic printk() on purpose, so they both can be
controlled independently.

Re: [PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[David Cohen]

On Thu, Mar 17, 2022 at 02:45:11PM +0100, Rafael J. Wysocki wrote:
> On Sat, Mar 12, 2022 at 5:37 AM David Cohen <dacohen@pm.me> wrote:
> >
> > Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
> > to filter pm debug messages based on pm_debug_messages_on flag.
> > According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
> > indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
> > support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()
>
> I'm not sure what you mean by pm_pr_debug().  There's no such thing in
> the kernel tree.
>
> Assuming that it means pm_pr_dbg(), it doesn't call pr_debug():

Yeah, I apologize for the typo. I meant pm_pr_dbg(). I can fix that if
you're ok with the patch as per comments below.

>
> #define pm_pr_dbg(fmt, ...) __pm_pr_dbg(false, fmt, ##__VA_ARGS__)
>
> and
>
> void __pm_pr_dbg(bool defer, const char *fmt, ...)
> {
> ...
>         if (defer)
>                printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
>         else
>                printk(KERN_DEBUG "PM: %pV", &vaf);
>
> And as I said printk(KERN_DEBUG ...) is not equivalent to
> pr_debug(...), because it is not dynamic printk().

The problem is not about __pm_pr_dbg() calling printk(). The problem is
the pm files that used to call pr_debug() were modified to call
pm_pr_dbg() in order to be behing the pm_debug_messages_on flag, as per
this commit:
8d8b2441db96 PM / sleep: Do not print debug messages by default

That's the moment dynamic debug was no longer available for kernel pm files.

>
> pm_pr_dbg() is not dynamic printk() on purpose, so they both can be
> controlled independently.

The current solution is all or nothing (using pm_debug_messages_on). The
patch I'm sending is making dynamic debug available on the kernel pm
files, while still allowing the pm_debug_messages_on flag to work
independently.

Regards, David

Re: [PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[Rafael J. Wysocki]

On Sat, Mar 19, 2022 at 2:54 AM David Cohen <dacohen@pm.me> wrote:
>
> On Thu, Mar 17, 2022 at 02:45:11PM +0100, Rafael J. Wysocki wrote:
> > On Sat, Mar 12, 2022 at 5:37 AM David Cohen <dacohen@pm.me> wrote:
> > >
> > > Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
> > > to filter pm debug messages based on pm_debug_messages_on flag.
> > > According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
> > > indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
> > > support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()
> >
> > I'm not sure what you mean by pm_pr_debug().  There's no such thing in
> > the kernel tree.
> >
> > Assuming that it means pm_pr_dbg(), it doesn't call pr_debug():
>
> Yeah, I apologize for the typo. I meant pm_pr_dbg(). I can fix that if
> you're ok with the patch as per comments below.
>
> >
> > #define pm_pr_dbg(fmt, ...) __pm_pr_dbg(false, fmt, ##__VA_ARGS__)
> >
> > and
> >
> > void __pm_pr_dbg(bool defer, const char *fmt, ...)
> > {
> > ...
> >         if (defer)
> >                printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
> >         else
> >                printk(KERN_DEBUG "PM: %pV", &vaf);
> >
> > And as I said printk(KERN_DEBUG ...) is not equivalent to
> > pr_debug(...), because it is not dynamic printk().
>
> The problem is not about __pm_pr_dbg() calling printk(). The problem is
> the pm files that used to call pr_debug() were modified to call
> pm_pr_dbg() in order to be behing the pm_debug_messages_on flag, as per
> this commit:
> 8d8b2441db96 PM / sleep: Do not print debug messages by default

So what's the problem with setting pm_debug_messages_on in addition to
enabling dynamic debug for a given file?

> That's the moment dynamic debug was no longer available for kernel pm files.
>
> >
> > pm_pr_dbg() is not dynamic printk() on purpose, so they both can be
> > controlled independently.
>
> The current solution is all or nothing (using pm_debug_messages_on). The
> patch I'm sending is making dynamic debug available on the kernel pm
> files, while still allowing the pm_debug_messages_on flag to work
> independently.

If you need a combination of pm_debug_messages_on and the pr_debug()
type of dynamic debug, I would suggest adding a new macro, say
pm_pr_dbg_dyn() or similar, for this purpose and use it as needed
instead of attempting to modify the existing behavior everywhere.

Re: [PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[David Cohen]

On Mon, Mar 21, 2022 at 03:20:20PM +0100, Rafael J. Wysocki wrote:
> On Sat, Mar 19, 2022 at 2:54 AM David Cohen <dacohen@pm.me> wrote:
> >
> > On Thu, Mar 17, 2022 at 02:45:11PM +0100, Rafael J. Wysocki wrote:
> > > On Sat, Mar 12, 2022 at 5:37 AM David Cohen <dacohen@pm.me> wrote:
> > > >
> > > > Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
> > > > to filter pm debug messages based on pm_debug_messages_on flag.
> > > > According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
> > > > indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
> > > > support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()
> > >
> > > I'm not sure what you mean by pm_pr_debug().  There's no such thing in
> > > the kernel tree.
> > >
> > > Assuming that it means pm_pr_dbg(), it doesn't call pr_debug():
> >
> > Yeah, I apologize for the typo. I meant pm_pr_dbg(). I can fix that if
> > you're ok with the patch as per comments below.
> >
> > >
> > > #define pm_pr_dbg(fmt, ...) __pm_pr_dbg(false, fmt, ##__VA_ARGS__)
> > >
> > > and
> > >
> > > void __pm_pr_dbg(bool defer, const char *fmt, ...)
> > > {
> > > ...
> > >         if (defer)
> > >                printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
> > >         else
> > >                printk(KERN_DEBUG "PM: %pV", &vaf);
> > >
> > > And as I said printk(KERN_DEBUG ...) is not equivalent to
> > > pr_debug(...), because it is not dynamic printk().
> >
> > The problem is not about __pm_pr_dbg() calling printk(). The problem is
> > the pm files that used to call pr_debug() were modified to call
> > pm_pr_dbg() in order to be behing the pm_debug_messages_on flag, as per
> > this commit:
> > 8d8b2441db96 PM / sleep: Do not print debug messages by default
>
> So what's the problem with setting pm_debug_messages_on in addition to
> enabling dynamic debug for a given file?

Let me be a bit more detailed:

Before "8d8b2441db96 PM / sleep: Do not print debug messages by default":
- pr_debug() was used
- The kernel pm files had dynamic debug support
- All the instances using pr_debug() are visible on
  /sys/kernel/debug/dynamic_debug/control
- pm_debug_messages_on flag was not supported

After "8d8b2441db96 PM / sleep: Do not print debug messages by default":
- pr_debug() was replaced with pm_pr_dbg()
- The kernel pm files where pm_pr_dbg() replaced pr_debug() *lost* dynamic
  debug support and they are no longer visible on
  /sys/kernel/debug/dynamic_debug/control
- pm_debug_messages_on flag was introduced

What my patch is doing:
- Reintroducing dynamic debug support to the same files who lost it
  after the patch mentioned above
- The instances using pr_pm_dbg() (which originally came from pr_debug())
  are reintroduced to /sys/kernel/debug/dynamic_debug/control
- pm_debug_messages_on flag is unaltered

Regards, David

Re: [PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[Rafael J. Wysocki]

On Mon, Mar 21, 2022 at 3:51 PM David Cohen <dacohen@pm.me> wrote:
>
> On Mon, Mar 21, 2022 at 03:20:20PM +0100, Rafael J. Wysocki wrote:
> > On Sat, Mar 19, 2022 at 2:54 AM David Cohen <dacohen@pm.me> wrote:
> > >
> > > On Thu, Mar 17, 2022 at 02:45:11PM +0100, Rafael J. Wysocki wrote:
> > > > On Sat, Mar 12, 2022 at 5:37 AM David Cohen <dacohen@pm.me> wrote:
> > > > >
> > > > > Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
> > > > > to filter pm debug messages based on pm_debug_messages_on flag.
> > > > > According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
> > > > > indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
> > > > > support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()
> > > >
> > > > I'm not sure what you mean by pm_pr_debug().  There's no such thing in
> > > > the kernel tree.
> > > >
> > > > Assuming that it means pm_pr_dbg(), it doesn't call pr_debug():
> > >
> > > Yeah, I apologize for the typo. I meant pm_pr_dbg(). I can fix that if
> > > you're ok with the patch as per comments below.
> > >
> > > >
> > > > #define pm_pr_dbg(fmt, ...) __pm_pr_dbg(false, fmt, ##__VA_ARGS__)
> > > >
> > > > and
> > > >
> > > > void __pm_pr_dbg(bool defer, const char *fmt, ...)
> > > > {
> > > > ...
> > > >         if (defer)
> > > >                printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
> > > >         else
> > > >                printk(KERN_DEBUG "PM: %pV", &vaf);
> > > >
> > > > And as I said printk(KERN_DEBUG ...) is not equivalent to
> > > > pr_debug(...), because it is not dynamic printk().
> > >
> > > The problem is not about __pm_pr_dbg() calling printk(). The problem is
> > > the pm files that used to call pr_debug() were modified to call
> > > pm_pr_dbg() in order to be behing the pm_debug_messages_on flag, as per
> > > this commit:
> > > 8d8b2441db96 PM / sleep: Do not print debug messages by default
> >
> > So what's the problem with setting pm_debug_messages_on in addition to
> > enabling dynamic debug for a given file?
>
> Let me be a bit more detailed:
>
> Before "8d8b2441db96 PM / sleep: Do not print debug messages by default":
> - pr_debug() was used
> - The kernel pm files had dynamic debug support
> - All the instances using pr_debug() are visible on
>   /sys/kernel/debug/dynamic_debug/control
> - pm_debug_messages_on flag was not supported
>
> After "8d8b2441db96 PM / sleep: Do not print debug messages by default":
> - pr_debug() was replaced with pm_pr_dbg()

Just for some PM-related messages, not in general.

> - The kernel pm files where pm_pr_dbg() replaced pr_debug() *lost* dynamic
>   debug support and they are no longer visible on
>   /sys/kernel/debug/dynamic_debug/control

Again, some of them.

> - pm_debug_messages_on flag was introduced

So what exactly is the problem you are trying to address?

> What my patch is doing:
> - Reintroducing dynamic debug support to the same files who lost it
>   after the patch mentioned above

Why is this necessary?

> - The instances using pr_pm_dbg() (which originally came from pr_debug())
>   are reintroduced to /sys/kernel/debug/dynamic_debug/control
> - pm_debug_messages_on flag is unaltered

I think that you really want to turn off some PM messages by default
when pm_debug_messages_on is set.

OTOH I want to be able to see pr_pm_dbg() messages in the log when
pm_debug_messages_on is set without having to turn on dynamic debug
for every file in which pr_pm_dbg() is used.  Your patch breaks this.

Re: [PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[David Cohen]

On Mon, Mar 21, 2022 at 04:12:24PM +0100, Rafael J. Wysocki wrote:
> On Mon, Mar 21, 2022 at 3:51 PM David Cohen <dacohen@pm.me> wrote:
> >
> > On Mon, Mar 21, 2022 at 03:20:20PM +0100, Rafael J. Wysocki wrote:
> > > On Sat, Mar 19, 2022 at 2:54 AM David Cohen <dacohen@pm.me> wrote:
> > > >
> > > > On Thu, Mar 17, 2022 at 02:45:11PM +0100, Rafael J. Wysocki wrote:
> > > > > On Sat, Mar 12, 2022 at 5:37 AM David Cohen <dacohen@pm.me> wrote:
> > > > > >
> > > > > > Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
> > > > > > to filter pm debug messages based on pm_debug_messages_on flag.
> > > > > > According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
> > > > > > indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
> > > > > > support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()
> > > > >
> > > > > I'm not sure what you mean by pm_pr_debug().  There's no such thing in
> > > > > the kernel tree.
> > > > >
> > > > > Assuming that it means pm_pr_dbg(), it doesn't call pr_debug():
> > > >
> > > > Yeah, I apologize for the typo. I meant pm_pr_dbg(). I can fix that if
> > > > you're ok with the patch as per comments below.
> > > >
> > > > >
> > > > > #define pm_pr_dbg(fmt, ...) __pm_pr_dbg(false, fmt, ##__VA_ARGS__)
> > > > >
> > > > > and
> > > > >
> > > > > void __pm_pr_dbg(bool defer, const char *fmt, ...)
> > > > > {
> > > > > ...
> > > > >         if (defer)
> > > > >                printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
> > > > >         else
> > > > >                printk(KERN_DEBUG "PM: %pV", &vaf);
> > > > >
> > > > > And as I said printk(KERN_DEBUG ...) is not equivalent to
> > > > > pr_debug(...), because it is not dynamic printk().
> > > >
> > > > The problem is not about __pm_pr_dbg() calling printk(). The problem is
> > > > the pm files that used to call pr_debug() were modified to call
> > > > pm_pr_dbg() in order to be behing the pm_debug_messages_on flag, as per
> > > > this commit:
> > > > 8d8b2441db96 PM / sleep: Do not print debug messages by default
> > >
> > > So what's the problem with setting pm_debug_messages_on in addition to
> > > enabling dynamic debug for a given file?
> >
> > Let me be a bit more detailed:
> >
> > Before "8d8b2441db96 PM / sleep: Do not print debug messages by default":
> > - pr_debug() was used
> > - The kernel pm files had dynamic debug support
> > - All the instances using pr_debug() are visible on
> >   /sys/kernel/debug/dynamic_debug/control
> > - pm_debug_messages_on flag was not supported
> >
> > After "8d8b2441db96 PM / sleep: Do not print debug messages by default":
> > - pr_debug() was replaced with pm_pr_dbg()
>
> Just for some PM-related messages, not in general.

Yes, I'm only addressing the kernel PM cases.

>
> > - The kernel pm files where pm_pr_dbg() replaced pr_debug() *lost* dynamic
> >   debug support and they are no longer visible on
> >   /sys/kernel/debug/dynamic_debug/control
>
> Again, some of them.
>
> > - pm_debug_messages_on flag was introduced
>
> So what exactly is the problem you are trying to address?
>
> > What my patch is doing:
> > - Reintroducing dynamic debug support to the same files who lost it
> >   after the patch mentioned above
>
> Why is this necessary?

I'm trying to have more granularity when enabling the debug messages.
See below for more context.

>
> > - The instances using pr_pm_dbg() (which originally came from pr_debug())
> >   are reintroduced to /sys/kernel/debug/dynamic_debug/control
> > - pm_debug_messages_on flag is unaltered
>
> I think that you really want to turn off some PM messages by default
> when pm_debug_messages_on is set.
>
> OTOH I want to be able to see pr_pm_dbg() messages in the log when
> pm_debug_messages_on is set without having to turn on dynamic debug
> for every file in which pr_pm_dbg() is used.  Your patch breaks this.

When debugging an issue with s2idle on my laptop where it enters an
infinite loop instead of suspending, the excess of PM messages were
changing the behavior and making it more a lot difficult to reproduce
the issue (and a less severe side effect, printing many debug info I
didn't need).

But as you pointed out, my patch is indeed changing the behavior for
when the pm_debug_messages_on is enabled. Would you be open for this
behavior instead:
 - If dynamic debug support is disabled, pm_pr_dbg() is printed if
   pm_debug_messages_on == 1
 - If dynamic debug support is enabled, pm_pr_dbg() is printed if
   pm_debug_messages_on == 1 or if pm_pr_dbg() was explicitly enabled on
   /sys/kernel/debug/dynamic_debug/control

Regards, David

Re: [PATCH v2] PM: fix dynamic debug within pm_pr_debug()

[Rafael J. Wysocki]

On Mon, Mar 21, 2022 at 4:57 PM David Cohen <dacohen@pm.me> wrote:
>
> On Mon, Mar 21, 2022 at 04:12:24PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Mar 21, 2022 at 3:51 PM David Cohen <dacohen@pm.me> wrote:
> > >
> > > On Mon, Mar 21, 2022 at 03:20:20PM +0100, Rafael J. Wysocki wrote:
> > > > On Sat, Mar 19, 2022 at 2:54 AM David Cohen <dacohen@pm.me> wrote:
> > > > >
> > > > > On Thu, Mar 17, 2022 at 02:45:11PM +0100, Rafael J. Wysocki wrote:
> > > > > > On Sat, Mar 12, 2022 at 5:37 AM David Cohen <dacohen@pm.me> wrote:
> > > > > > >
> > > > > > > Currently, pm_pr_debug() and pm_deferred_pr_debug() use __pm_pr_debug()
> > > > > > > to filter pm debug messages based on pm_debug_messages_on flag.
> > > > > > > According to __pm_pr_debug() implementation, pm_deferred_pr_debug()
> > > > > > > indirectly calls printk_deferred() within __pm_pr_debug() which doesn't
> > > > > > > support dynamic debug, but pm_pr_debug() indirectly calls pr_debug()
> > > > > >
> > > > > > I'm not sure what you mean by pm_pr_debug().  There's no such thing in
> > > > > > the kernel tree.
> > > > > >
> > > > > > Assuming that it means pm_pr_dbg(), it doesn't call pr_debug():
> > > > >
> > > > > Yeah, I apologize for the typo. I meant pm_pr_dbg(). I can fix that if
> > > > > you're ok with the patch as per comments below.
> > > > >
> > > > > >
> > > > > > #define pm_pr_dbg(fmt, ...) __pm_pr_dbg(false, fmt, ##__VA_ARGS__)
> > > > > >
> > > > > > and
> > > > > >
> > > > > > void __pm_pr_dbg(bool defer, const char *fmt, ...)
> > > > > > {
> > > > > > ...
> > > > > >         if (defer)
> > > > > >                printk_deferred(KERN_DEBUG "PM: %pV", &vaf);
> > > > > >         else
> > > > > >                printk(KERN_DEBUG "PM: %pV", &vaf);
> > > > > >
> > > > > > And as I said printk(KERN_DEBUG ...) is not equivalent to
> > > > > > pr_debug(...), because it is not dynamic printk().
> > > > >
> > > > > The problem is not about __pm_pr_dbg() calling printk(). The problem is
> > > > > the pm files that used to call pr_debug() were modified to call
> > > > > pm_pr_dbg() in order to be behing the pm_debug_messages_on flag, as per
> > > > > this commit:
> > > > > 8d8b2441db96 PM / sleep: Do not print debug messages by default
> > > >
> > > > So what's the problem with setting pm_debug_messages_on in addition to
> > > > enabling dynamic debug for a given file?
> > >
> > > Let me be a bit more detailed:
> > >
> > > Before "8d8b2441db96 PM / sleep: Do not print debug messages by default":
> > > - pr_debug() was used
> > > - The kernel pm files had dynamic debug support
> > > - All the instances using pr_debug() are visible on
> > >   /sys/kernel/debug/dynamic_debug/control
> > > - pm_debug_messages_on flag was not supported
> > >
> > > After "8d8b2441db96 PM / sleep: Do not print debug messages by default":
> > > - pr_debug() was replaced with pm_pr_dbg()
> >
> > Just for some PM-related messages, not in general.
>
> Yes, I'm only addressing the kernel PM cases.
>
> >
> > > - The kernel pm files where pm_pr_dbg() replaced pr_debug() *lost* dynamic
> > >   debug support and they are no longer visible on
> > >   /sys/kernel/debug/dynamic_debug/control
> >
> > Again, some of them.
> >
> > > - pm_debug_messages_on flag was introduced
> >
> > So what exactly is the problem you are trying to address?
> >
> > > What my patch is doing:
> > > - Reintroducing dynamic debug support to the same files who lost it
> > >   after the patch mentioned above
> >
> > Why is this necessary?
>
> I'm trying to have more granularity when enabling the debug messages.
> See below for more context.
>
> >
> > > - The instances using pr_pm_dbg() (which originally came from pr_debug())
> > >   are reintroduced to /sys/kernel/debug/dynamic_debug/control
> > > - pm_debug_messages_on flag is unaltered
> >
> > I think that you really want to turn off some PM messages by default
> > when pm_debug_messages_on is set.
> >
> > OTOH I want to be able to see pr_pm_dbg() messages in the log when
> > pm_debug_messages_on is set without having to turn on dynamic debug
> > for every file in which pr_pm_dbg() is used.  Your patch breaks this.
>
> When debugging an issue with s2idle on my laptop where it enters an
> infinite loop instead of suspending, the excess of PM messages were
> changing the behavior and making it more a lot difficult to reproduce
> the issue (and a less severe side effect, printing many debug info I
> didn't need).

I see.

> But as you pointed out, my patch is indeed changing the behavior for
> when the pm_debug_messages_on is enabled. Would you be open for this
> behavior instead:
>  - If dynamic debug support is disabled, pm_pr_dbg() is printed if
>    pm_debug_messages_on == 1
>  - If dynamic debug support is enabled, pm_pr_dbg() is printed if
>    pm_debug_messages_on == 1 or if pm_pr_dbg() was explicitly enabled on
>    /sys/kernel/debug/dynamic_debug/control

Yes, that would work.