From: Srirangan Madhavan <smadhavan@nvidia.com>
To: 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, bence.csokas@arm.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
Srirangan Madhavan <smadhavan@nvidia.com>
Subject: [PATCH v3 0/2] Add SMCCC cache clean/invalidate provider
Date: Thu, 10 Sep 2026 08:21:40 +0000 [thread overview]
Message-ID: <20260910082142.1522865-1-smadhavan@nvidia.com> (raw)
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.
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
--
2.43.0
next reply other threads:[~2026-09-10 8:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 8:21 Srirangan Madhavan [this message]
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
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=20260910082142.1522865-1-smadhavan@nvidia.com \
--to=smadhavan@nvidia.com \
--cc=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=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®