From: Agustin Santiago Isasmendi <isasmendi.agus@gmail.com>
To: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, "Arnd Bergmann" <arnd@arndb.de>,
"Stefan Dösinger" <stefandoesinger@gmail.com>,
"Navid Ghahremani" <ghahramani.navid@gmail.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
devicetree@vger.kernel.org
Subject: [PATCH v2 0/2] ARM: l2c: honour status = "disabled" on the L2 cache node
Date: Thu, 12 Nov 2026 08:29:51 +0100 [thread overview]
Message-ID: <20261112072953.989664-1-isasmendi.agus@gmail.com> (raw)
Hi Russell,
l2x0_of_init() finds the L2 cache node by compatible and never looks at
its status property, so a device tree cannot keep the L2 cache off.
Patch 2 makes it leave a disabled node alone; patch 1 notes in the
binding that the firmware must then leave the cache disabled.
The user is the ZTE ZX279128S (dual Cortex-A9, L2C-310 r3p3), where a
PCIe read on one CPU deadlocks against an L2C-310 line operation by
physical address or a Cache Sync on the other CPU, and the board hangs
within seconds of WiFi traffic. Running with the L2 cache off avoids
it, and that was suggested as the fallback for the platform when a
lock-based workaround was found too invasive for generic code:
https://lore.kernel.org/r/20261110153522.1620088-1-isasmendi.agus@gmail.com
Whether the ZX279128S device tree disables the cache is a decision for
that thread; this series only makes the property work.
No in-tree L2 cache node is disabled, so existing device trees are not
affected. Tested on the ZTE ZXHN H3600 (not in mainline yet, on top of
Navid Ghahremani's v2 platform series): with the node disabled the cache
stays off (control register 0) and the system runs normally; with it
enabled the cache comes up as before. Builds without warnings with W=1
(board config and multi_v7_defconfig); checkpatch --strict and
dt_binding_check are clean.
Changes in v2 (after Arnd's review):
- drop the clean-invalidate-disable path for a cache the firmware left
enabled, and with it the "factor out the number of ways" patch: the
firmware is responsible for leaving the cache off, the kernel does not
touch a disabled node;
- new patch 1 saying so in the binding.
v1: https://lore.kernel.org/r/20261111133930.3665251-1-isasmendi.agus@gmail.com
Agustin Santiago Isasmendi (2):
dt-bindings: cache: l2c2x0: a disabled node is left to the firmware
ARM: l2c: honour status = "disabled" on the L2 cache node
Documentation/devicetree/bindings/cache/l2c2x0.yaml | 3 +++
arch/arm/mm/cache-l2x0.c | 5 +++++
2 files changed, 8 insertions(+)
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
--
2.30.2
next reply other threads:[~2026-11-12 7:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 7:29 Agustin Santiago Isasmendi [this message]
2026-11-12 7:29 ` [PATCH v2 1/2] dt-bindings: cache: l2c2x0: a disabled node is left to the firmware Agustin Santiago Isasmendi
2026-11-12 7:29 ` [PATCH v2 2/2] ARM: l2c: honour status = "disabled" on the L2 cache node Agustin Santiago Isasmendi
2026-11-12 7:37 ` sashiko-bot
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=20261112072953.989664-1-isasmendi.agus@gmail.com \
--to=isasmendi.agus@gmail.com \
--cc=arnd@arndb.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=ghahramani.navid@gmail.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=robh@kernel.org \
--cc=stefandoesinger@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox