From: Srirangan Madhavan <smadhavan@nvidia•com>
To: Mark Rutland <mark.rutland@arm•com>,
Lorenzo Pieralisi <lpieralisi@kernel•org>,
Sudeep Holla <sudeep.holla@kernel•org>,
Conor Dooley <conor@kernel•org>,
Jonathan Cameron <jic23@kernel•org>
Cc: Catalin Marinas <catalin.marinas@arm•com>,
Will Deacon <will@kernel•org>, Dan Williams <djbw@kernel•org>,
Thierry Reding <treding@nvidia•com>,
Jonathan Hunter <jonathanh@nvidia•com>,
linux-arm-kernel@lists•infradead.org,
linux-kernel@vger•kernel.org, linux-tegra@vger•kernel.org,
Srirangan Madhavan <smadhavan@nvidia•com>
Subject: [PATCH v1 0/2] Add SMCCC cache clean/invalidate provider
Date: Tue, 2 Jun 2026 08:21:43 +0000 [thread overview]
Message-ID: <20260602082145.404939-1-smadhavan@nvidia.com> (raw)
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.
Reference:
[1] https://developer.arm.com/documentation/den0028/latest
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 | 1 +
drivers/cache/arm_smccc_cache.c | 160 ++++++++++++++++++++++++++++++++
include/linux/arm-smccc.h | 21 ++++-
tools/include/linux/arm-smccc.h | 21 ++++-
5 files changed, 210 insertions(+), 4 deletions(-)
create mode 100644 drivers/cache/arm_smccc_cache.c
base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
--
2.43.0
next reply other threads:[~2026-06-02 8:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 8:21 Srirangan Madhavan [this message]
2026-06-02 8:21 ` [PATCH v1 1/2] arm64: smccc: add cache clean/invalidate IDs and return codes Srirangan Madhavan
2026-06-02 14:49 ` Jonathan Cameron
2026-06-02 8:21 ` [PATCH v1 2/2] cache: add SMCCC-backed cache invalidate provider Srirangan Madhavan
2026-06-02 15:03 ` 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=20260602082145.404939-1-smadhavan@nvidia.com \
--to=smadhavan@nvidia$(echo .)com \
--cc=catalin.marinas@arm$(echo .)com \
--cc=conor@kernel$(echo .)org \
--cc=djbw@kernel$(echo .)org \
--cc=jic23@kernel$(echo .)org \
--cc=jonathanh@nvidia$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-tegra@vger$(echo .)kernel.org \
--cc=lpieralisi@kernel$(echo .)org \
--cc=mark.rutland@arm$(echo .)com \
--cc=sudeep.holla@kernel$(echo .)org \
--cc=treding@nvidia$(echo .)com \
--cc=will@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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