From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 680B91862BB for ; Wed, 26 Mar 2025 08:59:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742979546; cv=none; b=j/Q4yBmas2EkJBf1z9f3h6pQlEtc3wtB+Q+mnWBahkda1whldjYR9IuAFNjarC6dSuDsfwgY+Z35MJ9StA+Ju5cfDv6f5KK2FAY0fDl/1vlWsgvGPapDOOnIEthOzSleWJbuHV9c4fJcBwMTa/NiP7AmYP5JSaTeOx8u5BTcbXA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742979546; c=relaxed/simple; bh=FdsJiAbVWh4zlGzzu5hykozqWOHEFR+0JZ6czLPTNlY=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=KmEJfieQC039ldI2s3cAXyfQrlWNPKCYatMOT1pwMOWhWM3LZhi3g8hmvuSJHc3z0gvtMYhhFRoPBMXunsZqRfnsvZ2DBOoWNUZOuzgXLFyHOEWylbtRcuDhG2ybFwr28u7VXtX+nNo4Fup0/pp1lCVXPqANGIn59mKZv3/m2hA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mc4mL7AH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mc4mL7AH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7173C4CEE2; Wed, 26 Mar 2025 08:59:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742979545; bh=FdsJiAbVWh4zlGzzu5hykozqWOHEFR+0JZ6czLPTNlY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mc4mL7AHlA+W62MdbSABDrCa62oQwnlMkklcTzJtGgQvAA2TI3V/6g0F+0acT9ffp QyI6c7bi261DOnwOHOe3uQ27s2HqUkvQvVaP3KqeefOCoRTI0ekVNxJhqVpK9DpeZV mP3jrrkGwYspWw7VqrdfG1RMxivRS/gEW4+HyNDm6BpABQShW8BvS0THY3vJnrBcgu 8sd5ftOv87zMV8xTtMok2ZUZQDxnATJi87fGaICmHRXe7BqjCM1MBNA71mURG7aYJ6 tblU4kcC4WF1eu+lKBq7tPpcVlDzJKj2oVDFfJVc9frsYwFjdKNxAlK4udy4sdBBR4 PyjTHNymuWekg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1txMbH-00HE1j-6p; Wed, 26 Mar 2025 08:59:03 +0000 Date: Wed, 26 Mar 2025 08:59:02 +0000 Message-ID: <8634f0mall.wl-maz@kernel.org> From: Marc Zyngier To: Youngmin Nam Cc: Thomas Gleixner , Saravana Kannan , Ulf Hansson , Vincent Guittot , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com, hajun.sung@samsung.com, d7271.choe@samsung.com, joonki.min@samsung.com Subject: Re: [GICv3 ITS]S2IDLE framework does not invoke syscore_ops in GICv3 ITS driver In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: youngmin.nam@samsung.com, tglx@linutronix.de, saravanak@google.com, ulf.hansson@linaro.org, vincent.guittot@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com, hajun.sung@samsung.com, d7271.choe@samsung.com, joonki.min@samsung.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 26 Mar 2025 03:09:37 +0000, Youngmin Nam wrote: > > Hi. > > On our SoC, we are using S2IDLE instead of S2R as a system suspend mode. > However, when I try to enable ARM GICv3 ITS driver (drivers/irqchip/irq-gic-v3-its.c), > I noticed that there is no proper way to invoke suspend/resume callback, > because it only uses syscore_ops, which is not called in an s2idle scenario. This is *by design*. > Please refer to the codes below. > > > 5028 static struct syscore_ops its_syscore_ops = { > 5029 .suspend = its_save_disable, > 5030 .resume = its_restore_enable, > 5031 }; > ... > 5803 register_syscore_ops(&its_syscore_ops); > > > 444 if (state == PM_SUSPEND_TO_IDLE) { > 445 s2idle_loop(); > 446 goto Platform_wake; > 447 } > 448 > 449 error = pm_sleep_disable_secondary_cpus(); > 450 if (error || suspend_test(TEST_CPUS)) { > 451 log_suspend_abort_reason("Disabling non-boot cpus failed"); > 452 goto Enable_cpus; > 453 } > 454 > 455 arch_suspend_disable_irqs(); > 456 BUG_ON(!irqs_disabled()); > 457 > 458 system_state = SYSTEM_SUSPEND; > 459 > 460 error = syscore_suspend(); > > How should we handle this situation ? By implementing anything related to GIC power-management in your EL3 firmware. Only your firmware knows whether you are going into a state where the GIC (and the ITS) is going to lose its state (because power is going to be removed) or if the sleep period is short enough that you can come back from idle without loss of context. Furthermore, there is a lot of things that non-secure cannot do when it comes to GIC power management (most the controls are secure only), so it is pretty clear that the kernel is the wrong place for this. I'd suggest you look at what TF-A provides, because this is not exactly a new problem (it has been solved several years ago). M. -- Without deviation from the norm, progress is not possible.