Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7124853rdb; Wed, 3 Jan 2024 05:35:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IGpTN4mwUyjHViv0PX9GBq755Lu79y5cmXqFfFPsIMobdSvLY8d/z3U8P6lvx8xoFpnlYQx X-Received: by 2002:a05:6a00:9290:b0:6d9:df28:73df with SMTP id jw16-20020a056a00929000b006d9df2873dfmr7196146pfb.6.1704288901271; Wed, 03 Jan 2024 05:35:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704288901; cv=none; d=google.com; s=arc-20160816; b=Oyh8ucA5zWd8TPPXSAb4UzllkrV8/kmq+ViyPg2ugU+tAYVSHiGc1OSXc9ivV0fZ4N aF5LStUwCPUb0/hXZRF6ZEovj5FhSMTeQxICV7diV8WRy6ae6uuODHjzlvlI1FVahZPL 3Zugd7dDkyj1hchEijWb4moGAKQIPr5cUzDJhfxes+1T1XmKEXmoWck5UvnHywhwh6QG 2yItSVFBz2/+Vc84PqUPLHFQkvnPjkpPddo3mvvzeKNqeC1C6hfvGXFcKzUyYsUr/5n4 b8tOBJWGrsqSfBDZ2IJqQTvhOkMq3LTtjTFM3tLB7mV4hT3TUMKgcu5feurjeTCSQBzc jUMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence; bh=G9Bgrg98jxZjd7ez0NoKDpKp4vfROtPramNH7zK9BAo=; fh=qNgA8ULuMwq/RXcnF3RQ7xN0qHNetO4DNf0lC0Dfxtw=; b=ONp+QQgGwv1pJUr22vRdrFRmOKiNo3lC6SiLZsb/zkfv5Cfx4rwGGbMJK/2AKdO54y snMp+8xhuc3pNmf8Vd4sIf88dT3JG0Qp+u9ZwRTiFJaZfFnl05RCXLFsYUdS0zWmBkje Y1X/FY3934b34sn18gDtpvzpPuxxfT/mKS6jxXt4C34sfrVmwvB3SFEtiW6JZf9rVRNH 1eSMN5K9ZfA5Z79nvOjbx7Muo4I12nJPMBKNHw99ciEKoRTwin0CQdFMBMSpeQRLU0aB 9vO0m9XvvUEnr+dkHp/tenoqc5pJ19EzWsB95vI5gEcU305M17KceLKzAq5shQcsM6TR en1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-15588-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15588-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id z6-20020aa78886000000b006dab36291d7si1389437pfe.4.2024.01.03.05.35.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 05:35:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-15588-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-15588-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15588-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id D12FC280FB4 for ; Wed, 3 Jan 2024 13:34:49 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 94CF919BBA; Wed, 3 Jan 2024 13:34:40 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A9DCC19BAF; Wed, 3 Jan 2024 13:34:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-59584f41f1eso326532eaf.1; Wed, 03 Jan 2024 05:34:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704288877; x=1704893677; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=G9Bgrg98jxZjd7ez0NoKDpKp4vfROtPramNH7zK9BAo=; b=FBZHwHrlSGKlbHPEqJwa6HFJE/2fi1qUpFNpmk37DXsBcwpN7xwBkBbhTMH/BN/DXo xRU7MjZ1JtpdZ9zMGGcNSTuO9lW+V4o138iwWRSOHRGfVjrcFH+V8dyRqm1Mn4+scog6 FRDev7Yrfy2yWKyjK0HspFAKZMCPPWnd3LYJIXjR3zi5PZjCmOSqKcenW0r4twgC9G3i f1u6de+oTRccNjsdA37iRHeeht+W79vnqFDn22MbUwea6T3HKt+G9cFHq3uZxI7LWauj 2ZRUEC7pfLdqqkyV8sbqbaJWbqsPzeBGDLQXbAk+/SEVuL+Dcp4wR+yB269Bm6V472p7 vVfA== X-Gm-Message-State: AOJu0Yz3uQL+PZuw6pV/dxABkWZrQq4M7bSad4bAWCX5d4m4a5EmUoBp GP1xCw+kycB38sVp6bqOq+lcio8a7SofQ/xmXCs= X-Received: by 2002:a05:6870:9192:b0:204:208c:aa68 with SMTP id b18-20020a056870919200b00204208caa68mr30552051oaf.2.1704288877615; Wed, 03 Jan 2024 05:34:37 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240103041459.11113-1-ricardo.neri-calderon@linux.intel.com> <20240103041459.11113-5-ricardo.neri-calderon@linux.intel.com> In-Reply-To: <20240103041459.11113-5-ricardo.neri-calderon@linux.intel.com> From: "Rafael J. Wysocki" Date: Wed, 3 Jan 2024 14:34:26 +0100 Message-ID: Subject: Re: [PATCH v2 4/4] thermal: intel: hfi: Add a suspend notifier To: Ricardo Neri Cc: "Rafael J. Wysocki" , Chen Yu , Len Brown , Srinivas Pandruvada , Stanislaw Gruszka , Zhang Rui , Zhao Liu , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The subject should say "add a PM notifier" to indicate that hibernation is covered too. On Wed, Jan 3, 2024 at 5:13=E2=80=AFAM Ricardo Neri 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 The restore kernel is only used during resume from hibernation, so this particular problem is hibernation-specific. It is possible, at least in principle, that the address of the HFI table is "lost" by the processor during resume from "deep" suspend (ACPI S3), in which case it may not survive the firmware-driven part of the suspend-resume cycle. It is thus prudent to disable HFI on suspend and re-enable it on resume for the boot CPU (under the assumption that the other CPUs will be taken care of by CPU offline), but for a somewhat different reason than in the hibernation case. > second memory buffer and reprograms the HFI hardware with the new locatio= n > 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 > Cc: Len Brown > Cc: Srinivas Pandruvada > Cc: Stanislaw Gruszka > Cc: Zhang Rui > Cc: Zhao Liu > Cc: linux-pm@vger.kernel.org > Cc: stable@vger.kernel.org # 6.1 > Signed-off-by: Ricardo Neri > -- > Changes since v1: > * Moved registration of the suspend notifier towards the end of > intel_hfi_init(). (Stan) > * Renamed hfi_do_pm_[enable|disable]() to hfi_do_[enable|disable](). Sta= n > will use these functions outside the suspend notifier. (Stan) > * Added locking to calls to hfi_[enable|disable]() from the suspend > notifier. (Rafael) > --- > drivers/thermal/intel/intel_hfi.c | 62 +++++++++++++++++++++++++++++++ > 1 file changed, 62 insertions(+) > > diff --git a/drivers/thermal/intel/intel_hfi.c b/drivers/thermal/intel/in= tel_hfi.c > index 22445403b520..8d6e4f8dc67a 100644 > --- a/drivers/thermal/intel/intel_hfi.c > +++ b/drivers/thermal/intel/intel_hfi.c > @@ -30,11 +30,13 @@ > #include > #include > #include > +#include > #include > #include > #include > #include > #include > +#include > #include > #include > #include > @@ -571,6 +573,60 @@ static __init int hfi_parse_features(void) > return 0; > } > > +static void hfi_do_enable(void *info) > +{ > + struct hfi_instance *hfi_instance =3D info; > + > + hfi_set_hw_table(hfi_instance); > + hfi_enable(); > +} > + > +static void hfi_do_disable(void *info) > +{ > + hfi_disable(); > +} > + > +static int hfi_pm_notify(struct notifier_block *nb, > + unsigned long mode, void *unused) > +{ > + struct hfi_cpu_info *info =3D &per_cpu(hfi_cpu_info, 0); > + struct hfi_instance *hfi =3D info->hfi_instance; > + int ret =3D 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. T= he > + * instances of other packages are handled in the CPU hotplug cal= lbacks. > + */ > + switch (mode) { > + case PM_HIBERNATION_PREPARE: > + case PM_SUSPEND_PREPARE: > + case PM_RESTORE_PREPARE: > + ret =3D smp_call_function_single(0, hfi_do_disable, NULL,= true); > + break; > + > + case PM_POST_RESTORE: > + case PM_POST_HIBERNATION: > + case PM_POST_SUSPEND: > + ret =3D smp_call_function_single(0, hfi_do_enable, hfi, t= rue); > + 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. In addition, disabling HFI from a PM notifier is generally observable by user space, because PM notifiers run before user space is frozen, but doing it from a syscore op wouldn't be.