From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "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>,
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>,
Zhang Rui <rui.zhang@intel.com>, Zhao Liu <zhao1.liu@intel.com>,
stable@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org,
Zhao Liu <zhao1.liu@linux.intel.com>
Subject: Re: [PATCH 4/4] thermal: intel: hfi: Add a suspend notifier
Date: Mon, 1 Jan 2024 19:40:50 -0800 [thread overview]
Message-ID: <20240102034050.GA8661@ranerica-svr.sc.intel.com> (raw)
In-Reply-To: <CAJZ5v0hHu7R+mnW=w1NM80=Ha0QL853+O6i3RKrw18wuhRPUOg@mail.gmail.com>
On Fri, Dec 29, 2023 at 06:27:30PM +0100, Rafael J. Wysocki wrote:
> On Wed, Dec 27, 2023 at 7:28 AM Ricardo Neri
> <ricardo.neri-calderon@linux.intel.com> wrote:
> >
> > The kernel gives the HFI hardware a memory region that the latter uses to
> > provide updates to the HFI table. The kernel allocates this memory region
> > at boot. It remains constant throughout runtime time.
> >
> > When resuming from suspend or hibernation, the restore kernel allocates a
> > second memory buffer and reprograms the HFI hardware with the new location
> > as part of a normal boot. The location of the second memory buffer may
> > differ from the one allocated by the image kernel. Subsequently, when the
> > restore kernel transfers control to the image kernel, the second buffer
> > becomes invalid, potentially leading to memory corruption if the hardware
> > writes to it (hardware continues using the buffer from the restore kernel).
> >
> > Add a suspend notifier to disable all HFI instances before jumping to the
> > image kernel and enable them once the image kernel has been restored. Use
> > the memory buffer that the image kernel allocated.
> >
> > For non-boot CPUs, rely on the CPU hotplug callbacks as CPUs are disabled
> > and enabled during suspend and resume, respectively.
> >
> > The CPU hotplug callbacks do not cover the boot CPU. Handle the HFI
> > instance of the boot CPU from the suspend notifier callback.
> >
> > Cc: Chen Yu <yu.c.chen@intel.com>
> > Cc: Len Brown <len.brown@intel.com>
> > Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> > Cc: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
> > Cc: Zhang Rui <rui.zhang@intel.com>
> > Cc: Zhao Liu <zhao1.liu@linux.intel.com>
> > Cc: linux-pm@vger.kernel.org
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
> > ---
> > drivers/thermal/intel/intel_hfi.c | 53 +++++++++++++++++++++++++++++++
> > 1 file changed, 53 insertions(+)
> >
> > diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/intel_hfi.c
> > index d2c874f43786..965c245e5e78 100644
> > --- a/drivers/thermal/intel/intel_hfi.c
> > +++ b/drivers/thermal/intel/intel_hfi.c
> > @@ -30,11 +30,13 @@
> > #include <linux/kernel.h>
> > #include <linux/math.h>
> > #include <linux/mutex.h>
> > +#include <linux/notifier.h>
> > #include <linux/percpu-defs.h>
> > #include <linux/printk.h>
> > #include <linux/processor.h>
> > #include <linux/slab.h>
> > #include <linux/spinlock.h>
> > +#include <linux/suspend.h>
> > #include <linux/string.h>
> > #include <linux/topology.h>
> > #include <linux/workqueue.h>
> > @@ -569,11 +571,62 @@ static __init int hfi_parse_features(void)
> > return 0;
> > }
> >
> > +static void hfi_do_pm_enable(void *info)
> > +{
> > + struct hfi_instance *hfi_instance = info;
> > +
> > + hfi_set_hw_table(hfi_instance);
> > + hfi_enable();
>
> The above do RMW, so should locking be used here?
>
> > +}
> > +
> > +static void hfi_do_pm_disable(void *info)
> > +{
> > + hfi_disable();
> > +}
>
> And here?
On single-package systems, HFI enable/disable only happens on the boot CPU,
via either the CPU hotplug callbacks or the suspend notifier. It is
unlikely they will run concurrently, IMO. It also looks as good hygiene to
me to use locking, just in case. I will use the hfi_instance_lock in my
next version.
On multi-package systems, HFI instance of non-boot packages are always
handled via the CPU hotplug callbacks.
>
> > +
> > +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_instance = info->hfi_instance;
> > +
> > + /* HFI may not be in use. */
> > + if (!hfi_instance)
> > + return 0;
> > +
> > + /*
> > + * 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:
> > + return smp_call_function_single(0, hfi_do_pm_disable,
> > + NULL, true);
> > +
> > + case PM_POST_RESTORE:
> > + case PM_POST_HIBERNATION:
> > + case PM_POST_SUSPEND:
> > + return smp_call_function_single(0, hfi_do_pm_enable,
> > + hfi_instance, true);
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static struct notifier_block hfi_pm_nb = {
> > + .notifier_call = hfi_pm_notify,
> > +};
> > +
> > void __init intel_hfi_init(void)
> > {
> > struct hfi_instance *hfi_instance;
> > int i, j;
> >
> > + if (register_pm_notifier(&hfi_pm_nb))
> > + return;
> > +
> > if (hfi_parse_features())
> > return;
> >
> > --
prev parent reply other threads:[~2024-01-02 3:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-27 6:29 [PATCH 0/4] thermal: intel: hfi: Fix memory corruption on resume from hibernation Ricardo Neri
2023-12-27 6:29 ` [PATCH 1/4] thermal: intel: hfi: Refactor enabling code into helper functions Ricardo Neri
2023-12-29 17:22 ` Rafael J. Wysocki
2024-01-01 23:12 ` Ricardo Neri
2023-12-27 6:29 ` [PATCH 2/4] thermal: intel: hfi: Enable an HFI instance from its first online CPU Ricardo Neri
2023-12-27 6:29 ` [PATCH 3/4] thermal: intel: hfi: Disable an HFI instance when all its CPUs go offline Ricardo Neri
2023-12-27 6:29 ` [PATCH 4/4] thermal: intel: hfi: Add a suspend notifier Ricardo Neri
2023-12-29 17:27 ` Rafael J. Wysocki
2024-01-02 3:40 ` Ricardo Neri [this message]
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=20240102034050.GA8661@ranerica-svr.sc.intel.com \
--to=ricardo.neri-calderon@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=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=stable@vger.kernel.org \
--cc=stanislaw.gruszka@linux.intel.com \
--cc=yu.c.chen@intel.com \
--cc=zhao1.liu@intel.com \
--cc=zhao1.liu@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®