From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, rafael@kernel.org,
pavel@kernel.org, catalin.marinas@arm.com, will@kernel.org,
anshuman.khandual@arm.com, ryan.roberts@arm.com,
yang@os.amperecomputing.com, joey.gouly@arm.com
Subject: Re: [PATCH] arm64: fix cleared E0POE bit after cpu_suspend()/resume()
Date: Wed, 7 Jan 2026 10:50:20 +0000 [thread overview]
Message-ID: <aV46bBotl53gf3Kb@e129823.arm.com> (raw)
In-Reply-To: <f555454a-3eb9-4537-8f69-66ec36931966@arm.com>
Hi Kevin,
> On 07/01/2026 10:57, Yeoreum Yun wrote:
> >>> @@ -97,8 +97,11 @@ SYM_FUNC_START(cpu_do_suspend)
> >>> mrs x9, mdscr_el1
> >>> mrs x10, oslsr_el1
> >>> mrs x11, sctlr_el1
> >>> - get_this_cpu_offset x12
> >>> - mrs x13, sp_el0
> >>> +alternative_if ARM64_HAS_TCR2
> >>> + mrs x12, REG_TCR2_EL1
> >>> +alternative_else_nop_endif
> >>> + get_this_cpu_offset x13
> >>> + mrs x14, sp_el0
> >>> stp x2, x3, [x0]
> >>> stp x4, x5, [x0, #16]
> >>> stp x6, x7, [x0, #32]
> >>> @@ -109,7 +112,7 @@ SYM_FUNC_START(cpu_do_suspend)
> >>> * Save x18 as it may be used as a platform register, e.g. by shadow
> >>> * call stack.
> >>> */
> >>> - str x18, [x0, #96]
> >>> + stp x14, x18, [x0, #96]
> >> If TCR2_EL1 isn't supported, we store and reload an unused arbitrary
> >> value. I think it'd be better to make it all conditional and add it at
> >> the end, something like:
> >>
> >> � � alternative_if ARM64_HAS_TCR2
> >> � � � � mrs� � x2, REG_TCR2_EL1
> >> � � � � str� � x2, [x0, #104]
> >> � � alternative_else_nop_endif
> >>
> >> Same idea on the resume path. This also avoids the noise of renaming
> >> existing registers.
> > IMHO, I think it would be better to sustain the change since
> > it seems more simpler to maintain and x12 is temporary regsiter
> > so leaking whatever was in x12 does not really feel like a concern...
>
> Leaking is not a concern, but I don't think it's really easier to
> maintain. We can have all the conditional registers grouped together,
> like DISR_EL1 and soon SCTLR2_EL1. This avoids renaming a bunch of
> registers every time we save/restore a new register here.
Oh. I overlooked that point.
I'll follow your suggestion.
Thanks!
--
Sincerely,
Yeoreum Yun
prev parent reply other threads:[~2026-01-07 10:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 20:07 [PATCH] arm64: fix cleared E0POE bit after cpu_suspend()/resume() Yeoreum Yun
2026-01-07 9:43 ` Kevin Brodsky
2026-01-07 9:57 ` Yeoreum Yun
2026-01-07 10:29 ` Kevin Brodsky
2026-01-07 10:50 ` Yeoreum Yun [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=aV46bBotl53gf3Kb@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=rafael@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.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.