From: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Chen Yu <yu.c.chen@intel.com>, Len Brown <len.brown@intel.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Zhang Rui <rui.zhang@intel.com>, Zhao Liu <zhao1.liu@intel.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 4/4] thermal: intel: hfi: Add a suspend notifier
Date: Wed, 3 Jan 2024 16:02:34 +0100 [thread overview]
Message-ID: <ZZV3CgnaWznmzFKF@linux.intel.com> (raw)
In-Reply-To: <CAJZ5v0jSERoeMki9ZvWtTqiZidETeo1Xm_Qb0Oo2qRG0PMrSJQ@mail.gmail.com>
On Wed, Jan 03, 2024 at 02:34:26PM +0100, Rafael J. Wysocki wrote:
> > +static int hfi_pm_notify(struct notifier_block *nb,
> > + unsigned long mode, void *unused)
> > +{
> > + struct hfi_cpu_info *info = &per_cpu(hfi_cpu_info, 0);
> > + struct hfi_instance *hfi = info->hfi_instance;
> > + int ret = 0;
> > +
> > + /* HFI may not be in use. */
> > + if (!hfi)
> > + return ret;
> > +
> > + mutex_lock(&hfi_instance_lock);
> > + /*
> > + * Only handle the HFI instance of the package of the boot CPU. The
> > + * instances of other packages are handled in the CPU hotplug callbacks.
> > + */
> > + switch (mode) {
> > + case PM_HIBERNATION_PREPARE:
> > + case PM_SUSPEND_PREPARE:
> > + case PM_RESTORE_PREPARE:
> > + ret = smp_call_function_single(0, hfi_do_disable, NULL, true);
> > + break;
> > +
> > + case PM_POST_RESTORE:
> > + case PM_POST_HIBERNATION:
> > + case PM_POST_SUSPEND:
> > + ret = smp_call_function_single(0, hfi_do_enable, hfi, true);
> > + break;
>
> Because this handles the boot CPU only, one has to wonder if it should
> be a syscore op rather than a PM notifier.
>
> It does not sleep AFAICS, so it can run in that context, and it is
> guaranteed to run on the boot CPU then, so it is not necessary to
> force that. Moreover, syscore ops are guaranteed to be
> non-concurrent, so locking is not needed.
There are below warnings in smp_call_function_single() :
/*
* Can deadlock when called with interrupts disabled.
* We allow cpu's that are not yet online though, as no one else can
* send smp call function interrupt to this cpu and as such deadlocks
* can't happen.
*/
WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
&& !oops_in_progress);
/*
* When @wait we can deadlock when we interrupt between llist_add() and
* arch_send_call_function_ipi*(); when !@wait we can deadlock due to
* csd_lock() on because the interrupt context uses the same csd
* storage.
*/
WARN_ON_ONCE(!in_task());
And this one in syscore_suspend():
WARN_ONCE(!irqs_disabled(),
"Interrupts enabled before system core suspend.\n");
So seems they are not compatible.
Regards
Stanislaw
next prev parent reply other threads:[~2024-01-03 17:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-03 4:14 [PATCH v2 0/4] thermal: intel: hfi: Fix memory corruption on resume from hibernation Ricardo Neri
2024-01-03 4:14 ` [PATCH v2 1/4] thermal: intel: hfi: Refactor enabling code into helper functions Ricardo Neri
2024-01-03 4:14 ` [PATCH v2 2/4] thermal: intel: hfi: Enable an HFI instance from its first online CPU Ricardo Neri
2024-01-03 4:14 ` [PATCH v2 3/4] thermal: intel: hfi: Disable an HFI instance when all its CPUs go offline Ricardo Neri
2024-01-03 4:14 ` [PATCH v2 4/4] thermal: intel: hfi: Add a suspend notifier Ricardo Neri
2024-01-03 13:34 ` Rafael J. Wysocki
2024-01-03 13:38 ` Rafael J. Wysocki
2024-01-04 3:02 ` Ricardo Neri
2024-01-03 15:02 ` Stanislaw Gruszka [this message]
2024-01-03 18:21 ` Rafael J. Wysocki
2024-01-04 3:04 ` Ricardo Neri
2024-01-03 13:15 ` [PATCH v2 0/4] thermal: intel: hfi: Fix memory corruption on resume from hibernation Rafael J. Wysocki
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=ZZV3CgnaWznmzFKF@linux.intel.com \
--to=stanislaw.gruszka@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rafael@kernel.org \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=yu.c.chen@intel.com \
--cc=zhao1.liu@intel.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.