From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Vimal Kumar <vimal.kumar32@gmail.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
chinmoyghosh2001@gmail.com, badolevishal1116@gmail.com,
mintupatel89@gmail.com
Subject: Re: [PATCH v4] PM / sleep: Mechanism to find source aborting kernel suspend transition
Date: Mon, 5 Feb 2024 19:33:17 +0000 [thread overview]
Message-ID: <2024020555-usable-hardy-345e@gregkh> (raw)
In-Reply-To: <20240205170747.19748-1-vimal.kumar32@gmail.com>
On Mon, Feb 05, 2024 at 10:37:45PM +0530, Vimal Kumar wrote:
> Sometimes kernel suspend transitions can be aborted unconditionally by
> manipulating pm_abort_suspend value using "hard" wakeup triggers or
> through "pm_system_wakeup()".
>
> There is no way to trace the source path of module or subsystem which
> aborted the suspend transitions. This change will create a list of
> wakeup sources aborting suspend in progress through "hard" events as
> well as subsytems aborting suspend using "pm_system_wakeup()".
>
> Example: Existing suspend failure logs:
> [ 349.708359] PM: Some devices failed to suspend, or early wake event detected
> [ 350.327842] PM: suspend exit
>
> Suspend failure logs with this change:
> [ 518.761835] PM: Some devices failed to suspend, or early wake event detected
> [ 519.486939] PM: wakeup source or subsystem uart_suspend_port aborted suspend
> [ 519.500594] PM: suspend exit
>
> Here we can clearly identify the module triggerring abort suspend.
>
> Co-developed-by: Chinmoy Ghosh <chinmoyghosh2001@gmail.com>
> Signed-off-by: Chinmoy Ghosh <chinmoyghosh2001@gmail.com>
> Co-developed-by: Mintu Patel <mintupatel89@gmail.com>
> Signed-off-by: Mintu Patel <mintupatel89@gmail.com>
> Co-developed-by: Vishal Badole <badolevishal1116@gmail.com>
> Signed-off-by: Vishal Badole <badolevishal1116@gmail.com>
> Signed-off-by: Vimal Kumar <vimal.kumar32@gmail.com>
> ---
> Changes in v4:
> - Changed GFP_KERNEL flag to GFP_ATOMIC
> - Changed mutex_lock to raw_spin_lock
why raw?
> ---
> drivers/base/power/wakeup.c | 100 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 99 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index a917219feea6..b04794557eef 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -73,6 +73,16 @@ static struct wakeup_source deleted_ws = {
>
> static DEFINE_IDA(wakeup_ida);
>
> +#ifdef CONFIG_PM_DEBUG
> +static DEFINE_RAW_SPINLOCK(pm_abort_suspend_list_lock);
> +
> +struct pm_abort_suspend_source {
> + struct list_head list;
> + char *source_triggering_abort_suspend;
> +};
> +static LIST_HEAD(pm_abort_suspend_list);
> +#endif
> +
> /**
> * wakeup_source_create - Create a struct wakeup_source object.
> * @name: Name of the new wakeup source.
> @@ -575,6 +585,54 @@ static void wakeup_source_activate(struct wakeup_source *ws)
> trace_wakeup_source_activate(ws->name, cec);
> }
>
> +#ifdef CONFIG_PM_DEBUG
Please do not add #ifdef to .c files, this makes this file even messier.
> @@ -590,8 +648,13 @@ static void wakeup_source_report_event(struct wakeup_source *ws, bool hard)
> if (!ws->active)
> wakeup_source_activate(ws);
>
> - if (hard)
> + if (hard) {
> +#ifdef CONFIG_PM_DEBUG
> + if (pm_suspend_target_state != PM_SUSPEND_ON)
> + pm_abort_suspend_source_add(ws->name);
> +#endif
Especially for stuff like this, if you write your .h files properly, no
#ifdef are needed.
> pm_system_wakeup();
> + }
> }
>
> /**
> @@ -893,12 +956,47 @@ bool pm_wakeup_pending(void)
> pm_print_active_wakeup_sources();
> }
>
> +#ifdef CONFIG_PM_DEBUG
> + if (atomic_read(&pm_abort_suspend) > 0) {
> + struct pm_abort_suspend_source *info;
> +
> + raw_spin_lock_irqsave(&pm_abort_suspend_list_lock, flags);
> + list_for_each_entry(info, &pm_abort_suspend_list, list) {
> + pm_pr_dbg("wakeup source or subsystem %s aborted suspend\n",
> + info->source_triggering_abort_suspend);
> + }
> + raw_spin_unlock_irqrestore(&pm_abort_suspend_list_lock, flags);
> + pm_abort_suspend_list_clear();
> + }
> +#endif
> +
> return ret || atomic_read(&pm_abort_suspend) > 0;
> }
> EXPORT_SYMBOL_GPL(pm_wakeup_pending);
>
> void pm_system_wakeup(void)
> {
> +
> +#ifdef CONFIG_PM_DEBUG
> +#ifdef CONFIG_DEBUG_INFO
> + if (pm_suspend_target_state != PM_SUSPEND_ON) {
> + char *source_name = kasprintf(GFP_ATOMIC,
> + "%ps",
> + __builtin_return_address(0));
> + if (!source_name)
> + goto exit;
> +
> + if (strcmp(source_name, "pm_wakeup_ws_event"))
> + pm_abort_suspend_source_add(source_name);
> +
> + kfree(source_name);
> + }
> +exit:
> +#else
> + if (pm_suspend_target_state != PM_SUSPEND_ON)
> + pm_pr_dbg("Some wakeup source or subsystem aborted suspend\n");
> +#endif
> +#endif
Would you want to maintain this #ifdef nesting mess for the next 20
years? Please do not do this.
thanks,
greg k-h
next prev parent reply other threads:[~2024-02-05 19:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-05 17:07 [PATCH v4] PM / sleep: Mechanism to find source aborting kernel suspend transition Vimal Kumar
2024-02-05 19:33 ` Greg Kroah-Hartman [this message]
2024-02-07 3:54 ` Vimal Kumar
2024-02-07 10:25 ` Greg Kroah-Hartman
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=2024020555-usable-hardy-345e@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=badolevishal1116@gmail.com \
--cc=chinmoyghosh2001@gmail.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mintupatel89@gmail.com \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=vimal.kumar32@gmail.com \
/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.