From: "Bence Csókás" <bence.csokas@arm.com>
To: Srirangan Madhavan <smadhavan@nvidia.com>,
mark.rutland@arm.com, lpieralisi@kernel.org,
sudeep.holla@kernel.org, conor@kernel.org, jic23@kernel.org
Cc: catalin.marinas@arm.com, will@kernel.org, treding@nvidia.com,
jonathanh@nvidia.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH v3 0/2] Add SMCCC cache clean/invalidate provider
Date: Mon, 14 Sep 2026 09:53:44 +0200 [thread overview]
Message-ID: <32b15e37-4938-4af2-a880-273a3eee5164@arm.com> (raw)
In-Reply-To: <20260910082142.1522865-1-smadhavan@nvidia.com>
Hi,
On 2026. 09. 10. 10:21, Srirangan Madhavan wrote:
> Apologies for the delay in posting v3. We waited until the corresponding
> firmware support was available in TF-A. This allowed the provider to be
> tested end to end with the CXL Reset series [2].
>
> This series adds an arm64 backend for memregion cache invalidation users
> based on the Arm SMCCC cache clean+invalidate interface.
>
> Per DEN0028, this interface targets systems where a Normal Cacheable
> memory region can be modified in ways that are not handled by usual PE
> coherency mechanisms, and where VA-based CMOs may be too slow or
> insufficient for large ranges and/or system-cache implementations.
>
> Representative use cases include device-backed memory state transitions
> where stale CPU/system cache lines must be invalidated reliably (for
> example secure erase, reset/offline flows, and dynamic memory
> reconfiguration).
>
> Patch 1 introduces the Arm SMCCC cache clean/invalidate function IDs and
> transient return codes needed by callers [1].
>
> Patch 2 adds a cache maintenance provider that:
> - discovers SMCCC support and attributes at init time
> - registers with the generic cache coherency framework used by
> cpu_cache_invalidate_memregion()
> - handles transient BUSY/RATE_LIMITED responses with bounded retries
>
> This patch set does not add a software fallback path; when firmware does
> not implement the SMCCC cache maintenance interface, the provider is not
> registered and existing behavior is preserved.
>
> References:
> [1] https://developer.arm.com/documentation/den0028/h
> [2] https://lore.kernel.org/linux-cxl/20260902072804.665639-1-smadhavan@nvidia.com/
>
> DEN0028 v1.7 has since been confirmed as stable.
>
> Testing:
> - With corresponding TF-A support enabled, exercised the provider through
> the CXL Reset path and verified that it invokes the SMCCC call and
> completes the cache flush successfully.
> - ARM64 defconfig with CONFIG_CACHEMAINT_FOR_HOTPLUG=y and
> CONFIG_ARM_SMCCC_CACHE=y
> - W=1 build of drivers/cache/arm_smccc_cache.o
> - W=1 build of the ARM64 Image
>
> Changes since v2:
> - Rebased onto Linux v7.3-rc1.
> - Preserved the final BUSY or RATE_LIMITED error after retry exhaustion.
> - Dropped the redundant feature query for the mandatory ATTRIBUTES call.
> - Preserved the full 64-bit maximum-call-rate value returned in X3.
> - Reordered local declarations in reverse-fir-tree order.
> - Removed the routine provider registration message.
Reviewed-by: Bence Csókás <bence.csokas@arm.com>
I have yet to try it out on actual hardware, but from looking at the
code, it now seems to match the spec.
> Changes since v1:
> - Added Jonathan Cameron's Reviewed-by tags.
> - Clarified the ARM_SMCCC_CACHE Kconfig help text.
> - Added a Makefile comment identifying the providers that depend on
> CACHEMAINT_FOR_HOTPLUG.
> - Dropped the final-backoff-sleep skip in the retry loop.
>
> Changes since RFC:
> - Dropped the RFC tag.
> - Moved the provider from arch/arm64/mm to drivers/cache.
> - Added a dedicated CONFIG_ARM_SMCCC_CACHE option under the existing
> CACHEMAINT_FOR_HOTPLUG menu.
> - Dropped the global-operation coalescing optimization.
> - Dropped provider handling for SMCCC_RET_NOT_REQUIRED.
> - Removed the unnecessary global provider pointer.
> - Removed arm64_ prefixes from static provider-local names.
> - Documented why these SMCCC Arch cache maintenance calls use SMC64.
> - Anchored the SMCCC return-code comment to DEN0028 v1.7.
> - Used fsleep() for retry backoff.
> - Used unsigned long for retry delay values passed to fsleep().
> - Skipped the final backoff sleep when no retry remains.
> - Documented the bounded mutex hold time across the serialized retry
> sequence.
> - Added mutex_destroy() on the registration failure path.
>
> Srirangan Madhavan (2):
> arm64: smccc: add cache clean/invalidate IDs and return codes
> cache: add SMCCC-backed cache invalidate provider
>
> drivers/cache/Kconfig | 11 +++
> drivers/cache/Makefile | 2 +
> drivers/cache/arm_smccc_cache.c | 149 ++++++++++++++++++++++++++++++++
> include/linux/arm-smccc.h | 21 ++++-
> tools/include/linux/arm-smccc.h | 21 ++++-
> 5 files changed, 200 insertions(+), 4 deletions(-)
> create mode 100644 drivers/cache/arm_smccc_cache.c
>
>
> base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
Bence
prev parent reply other threads:[~2026-09-14 7:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 8:21 Srirangan Madhavan
2026-09-10 8:21 ` [PATCH v3 1/2] arm64: smccc: add cache clean/invalidate IDs and return codes Srirangan Madhavan
2026-09-10 8:21 ` [PATCH v3 2/2] cache: add SMCCC-backed cache invalidate provider Srirangan Madhavan
2026-09-10 18:52 ` Jonathan Cameron
2026-09-12 11:05 ` Conor Dooley
2026-09-14 7:53 ` Bence Csókás [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=32b15e37-4938-4af2-a880-273a3eee5164@arm.com \
--to=bence.csokas@arm.com \
--cc=catalin.marinas@arm.com \
--cc=conor@kernel.org \
--cc=jic23@kernel.org \
--cc=jonathanh@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=smadhavan@nvidia.com \
--cc=sudeep.holla@kernel.org \
--cc=treding@nvidia.com \
--cc=will@kernel.org \
/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®