* [PATCH] arm64: dts: rockchip: Add DT overlay to use Sige5 SD slot for SPI flashing
From: Alexey Charkov @ 2026-04-24 14:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Alexey Charkov
ArmSoM Sige5, just as most RK3576 based boards, has its SD card pins
multiplexed with the FSPI1 controller, allowing for high-speed SPI access
to flash chips. If one has a microSD breakout board, a voltage regulator
to provide the necessary 1.8V power, a 6x5mm flash socket, and some jumper
wires, it's possible to use this to flash SPI chips directly from the
Sige5 with full hardware acceleration.
Add a DT overlay to set up the necessary pinmux and enable the FSPI1
controller for this purpose. This is specifically targeted at 1.8V flash
chips, and relies on an external regulator or power supply to provide the
necessary 1.8V power to the flash chip.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
arch/arm64/boot/dts/rockchip/Makefile | 5 ++
.../rk3576-armsom-sige5-fspi1-flasher.dtso | 80 ++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index cb55c6b70d0e..ece5bdb387bc 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-display-vz.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-100ask-dshanpi-a1.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-fspi1-flasher.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10-pcie1.dtbo
@@ -289,6 +290,10 @@ rk3568-wolfvision-pf5-vz-2-uhd-dtbs := rk3568-wolfvision-pf5.dtb \
rk3568-wolfvision-pf5-display-vz.dtbo \
rk3568-wolfvision-pf5-io-expander.dtbo
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-fspi1-flasher.dtb
+rk3576-armsom-sige5-fspi1-flasher-dtbs := rk3576-armsom-sige5.dtb \
+ rk3576-armsom-sige5-fspi1-flasher.dtbo
+
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtb
rk3576-armsom-sige5-v1.2-wifibt-dtbs := rk3576-armsom-sige5.dtb \
rk3576-armsom-sige5-v1.2-wifibt.dtbo
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-fspi1-flasher.dtso b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-fspi1-flasher.dtso
new file mode 100644
index 000000000000..b2ed735a43fc
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-fspi1-flasher.dtso
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * DT-overlay to use the SD card slot on the Sige5 for flashing SPI chips via
+ * the hardware FSPI1 controller.
+ *
+ * This is specifically targeted at 1.8V SPI flash chips, and requires an
+ * external regulator or power supply to provide the power to the flash chip,
+ * as the one on Sige5 is fixed at 3.3V.
+ *
+ * Here's an example circuit:
+ * -----------------------------------------------------------------
+ * SD card slot SPI flash chip (e.g. MX25U12832F)
+ * (Pin 1) DAT2 <----------------------------> WP/SIO2 (Pin 3)
+ * (Pin 2) CD/DAT3 <----------------------------> RESET/SIO3 (Pin 7)
+ * (Pin 3) CMD <----------------------------> CS# (Pin 1)
+ * (Pin 5) CLK <----------------------------> SCLK (Pin 6)
+ * (Pin 7) DAT0 <----------------------------> SI/SIO0 (Pin 5)
+ * (Pin 8) DAT1 <----------------------------> SO/SIO1 (Pin 2)
+ * +-------+
+ * (Pin 4) 3V3 VDD <-> VIN 3 |MCP1700| 2 VOUT <-> 1V8 VCC (Pin 8)
+ * +-------+
+ * 1 GND
+ * |
+ * (Pin 6) VSS <-------------+--------------> GND (Pin 4)
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+&{/} {
+ vcc3v3_sd_s0: regulator-vcc-3v3-sd {
+ compatible = "regulator-fixed";
+ pinctrl-0 = <&sdmmc0_pwren>;
+ pinctrl-names = "default";
+ regulator-name = "vcc3v3_sd_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+};
+
+&pinctrl {
+ sd {
+ sdmmc0_pwren: sdmmc0-pwren {
+ rockchip,pins = <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&sfc1 {
+ pinctrl-0 = <&fspi1m0_csn0>, <&fspi1m0_pins>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <50000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <1>;
+ vcc-supply = <&vcc3v3_sd_s0>; /* Need a discrete LDO!!! */
+ };
+};
+
+&sdmmc {
+ status = "disabled";
+};
+
+&vccio_sd_s0 {
+ regulator-max-microvolt = <1800000>;
+};
---
base-commit: 7080e32d3f09d8688c4a87d81bdcc71f7f606b16
change-id: 20260424-sige5-flasher-e745282292bd
Best regards,
--
Alexey Charkov <alchark@flipper.net>
^ permalink raw reply related
* Re: [PATCH v11 00/14] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Andrew Morton @ 2026-04-24 14:28 UTC (permalink / raw)
To: Ankur Arora
Cc: linux-kernel, linux-arch, linux-arm-kernel, linux-pm, bpf, arnd,
catalin.marinas, will, peterz, mark.rutland, harisokn, cl, ast,
rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai, rdunlap,
david.laight.linux, joao.m.martins, boris.ostrovsky, konrad.wilk,
ashok.bhat
In-Reply-To: <20260408122538.3610871-1-ankur.a.arora@oracle.com>
On Wed, 8 Apr 2026 17:55:24 +0530 Ankur Arora <ankur.a.arora@oracle.com> wrote:
> The core kernel often uses smp_cond_load_{relaxed,acquire}() to spin
> on condition variables with architectural primitives used to avoid
> hammering the relevant cachelines.
>
> ...
>
> Accordingly add two interfaces (with their generic and arm64 specific
> implementations):
>
> smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, timeout)
> smp_cond_load_acquire_timeout(ptr, cond_expr, time_expr, timeout)
>
> Also add tif_need_resched_relaxed_wait() which wraps the polling
> pattern and its scheduler specific details in poll_idle().
> In addition add atomic_cond_read_*_timeout(),
> atomic64_cond_read_*_timeout(), and atomic_long wrappers.
AI review has been busy:
https://sashiko.dev/#/patchset/20260408122538.3610871-1-ankur.a.arora@oracle.com
^ permalink raw reply
* Re: [PATCH v22 3/8] dt-bindings: display: bridge: Add Cadence MHDP8501
From: Laurentiu Palcu @ 2026-04-24 14:37 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Krzysztof Kozlowski, dri-devel, Jonas Karlman, Maarten Lankhorst,
linux-kernel, Thomas Zimmermann, Jernej Skrabec, Neil Armstrong,
Simona Vetter, linux-arm-kernel, Maxime Ripard, imx, linux,
devicetree, linux-phy, Alexander Stein, Robert Foss, Conor Dooley,
Ying Liu, Laurent Pinchart, David Airlie, Andrzej Hajda
In-Reply-To: <177703391401.3671402.9330071570952735700.robh@kernel.org>
On Fri, Apr 24, 2026 at 07:31:54AM -0500, Rob Herring (Arm) wrote:
>
> On Fri, 24 Apr 2026 11:07:16 +0000, Laurentiu Palcu wrote:
> > From: Sandor Yu <Sandor.yu@nxp.com>
> >
> > Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
> >
> > Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
> > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> > ---
> > .../bindings/display/bridge/cdns,mhdp8501.yaml | 135 +++++++++++++++++++++
> > 1 file changed, 135 insertions(+)
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml: Unresolvable reference: /schemas/phy/fsl,imx8mq-hdptx-phy.yaml#
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.example.dtb: display-bridge@32c00000 (fsl,imx8mq-mhdp8501): phy: False schema does not allow {'compatible': ['fsl,imx8mq-hdptx-phy'], '#phy-cells': 0, 'clocks': [[4294967295], [4294967295, 248]], 'clock-names': ['ref', 'apb'], 'phandle': 2}
> from schema $id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.example.dtb: /example-0/display-bridge@32c00000/phy: failed to match any schema with compatible: ['fsl,imx8mq-hdptx-phy']
>
> doc reference errors (make refcheckdocs):
>
> See https://patchwork.kernel.org/project/devicetree/patch/20260424-dcss-hdmi-upstreaming-v22-3-30a28f89298d@oss.nxp.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
>
It appears the problem is triggered by the fact that the dt-binding
patch adding fsl,imx8mq-hdptx-phy.yaml comes later than this patch... I
only tested with dt_binding_check after all patches were applied. :/
I'll reorder the patches in the next version.
--
Thanks,
Laurentiu
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Peter Zijlstra @ 2026-04-24 15:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mathias Stearn, Dmitry Vyukov, Jinjie Ruan, linux-man,
Mark Rutland, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Blake Oler
In-Reply-To: <87v7dgzbo7.ffs@tglx>
On Fri, Apr 24, 2026 at 04:16:08PM +0200, Thomas Gleixner wrote:
> On Fri, Apr 24 2026 at 10:32, Mathias Stearn wrote:
> > On Fri, Apr 24, 2026 at 9:57 AM Dmitry Vyukov <dvyukov@google.com> wrote:
> >> The only problem is with membarrier (it used to force write to
> >> __rseq_abi.cpu_id_start for all threads, but now it does not).
> >> Otherwise the caching scheme works.
> >
> > I almost wrote a message last night saying that we didn't need
> > cpu_id_start invalidation on preemption. However, I remembered that
> > the Grow() function[1] does a load outside of a critical section then
> > stores a derived value inside the critical section, guarded only by
> > the cpu_id_start invalidation check in StoreCurrentCpu[2]. It really
> > should be doing a compare against the original value inside the
> > critical section (or just do the whole thing inside), but it doesn't.
> > I haven't reasoned end-to-end through this fully to prove corruption
> > is possible, but I suspect that it is if another thread same-cpu
> > preempts between the loads and the store and updates the header before
> > the original thread resumes and writes its original intended header
> > value. Ditto for signals, which sometimes allocate even though they
> > shouldn't.
> >
> > I was really hoping that we would only need to do the "redundant"
> > cpu_id_start writes would only be needed on membarrier_rseq IPIs where
> > it really is a pay-for-what-you-use functionality,
>
> That's fine and can be solved without adding this sequence overhead into
> the scheduler hotpath.
Something like so? (probably needs help for !GENERIC bits)
---
diff --git a/include/asm-generic/thread_info_tif.h b/include/asm-generic/thread_info_tif.h
index 528e6fc7efe9..1d786003e42a 100644
--- a/include/asm-generic/thread_info_tif.h
+++ b/include/asm-generic/thread_info_tif.h
@@ -48,7 +48,10 @@
#define TIF_RSEQ 11 // Run RSEQ fast path
#define _TIF_RSEQ BIT(TIF_RSEQ)
-#define TIF_HRTIMER_REARM 12 // re-arm the timer
+#define TIF_RSEQ_FORCE_RESTART 12 // Reset RSEQ-CS from membarrier
+#define _TIF_RSEQ_FORCE_RESTART BIT(TIF_RSEQ_FORCE_RESTART)
+
+#define TIF_HRTIMER_REARM 13 // re-arm the timer
#define _TIF_HRTIMER_REARM BIT(TIF_HRTIMER_REARM)
#endif /* _ASM_GENERIC_THREAD_INFO_TIF_H_ */
diff --git a/include/linux/rseq.h b/include/linux/rseq.h
index b9d62fc2140d..2cbee6d41198 100644
--- a/include/linux/rseq.h
+++ b/include/linux/rseq.h
@@ -158,6 +158,8 @@ static inline unsigned int rseq_alloc_align(void)
return 1U << get_count_order(offsetof(struct rseq, end));
}
+extern void rseq_prepare_membarrier(struct mm_struct *mm);
+
#else /* CONFIG_RSEQ */
static inline void rseq_handle_slowpath(struct pt_regs *regs) { }
static inline void rseq_signal_deliver(struct ksignal *ksig, struct pt_regs *regs) { }
@@ -167,6 +169,7 @@ static inline void rseq_force_update(void) { }
static inline void rseq_virt_userspace_exit(void) { }
static inline void rseq_fork(struct task_struct *t, u64 clone_flags) { }
static inline void rseq_execve(struct task_struct *t) { }
+static inline void rseq_prepare_membarrier(struct mm_struct *mm) { }
#endif /* !CONFIG_RSEQ */
#ifdef CONFIG_DEBUG_RSEQ
diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
index f11ebd34f8b9..3dfaca776971 100644
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -686,7 +686,12 @@ static __always_inline bool __rseq_exit_to_user_mode_restart(struct pt_regs *reg
#ifdef CONFIG_HAVE_GENERIC_TIF_BITS
static __always_inline bool test_tif_rseq(unsigned long ti_work)
{
- return ti_work & _TIF_RSEQ;
+ return ti_work & (_TIF_RSEQ | _TIF_RSEQ_FORCE_RESTART);
+}
+
+static __always_inline void clear_tif_rseq_force_restart(void)
+{
+ clear_thread_flag(TIF_RSEQ_FORCE_RESTART);
}
static __always_inline void clear_tif_rseq(void)
@@ -696,6 +701,7 @@ static __always_inline void clear_tif_rseq(void)
}
#else
static __always_inline bool test_tif_rseq(unsigned long ti_work) { return true; }
+static __always_inline void clear_tif_rseq_force_restart(void) { }
static __always_inline void clear_tif_rseq(void) { }
#endif
@@ -703,6 +709,11 @@ static __always_inline bool
rseq_exit_to_user_mode_restart(struct pt_regs *regs, unsigned long ti_work)
{
if (unlikely(test_tif_rseq(ti_work))) {
+ if (unlikely(ti_work & _TIF_RSEQ_FORCE_RESTART)) {
+ current->rseq.event.sched_switch = true;
+ current->rseq.event.ids_changed = true;
+ clear_tif_rseq_force_restart();
+ }
if (unlikely(__rseq_exit_to_user_mode_restart(regs))) {
current->rseq.event.slowpath = true;
set_tsk_thread_flag(current, TIF_NOTIFY_RESUME);
diff --git a/kernel/rseq.c b/kernel/rseq.c
index 38d3ef540760..9adc7f63adf5 100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -255,6 +255,19 @@ static bool rseq_handle_cs(struct task_struct *t, struct pt_regs *regs)
return false;
}
+void rseq_prepare_membarrier(struct mm_struct *mm)
+{
+ struct task_struct *t;
+
+ guard(mutex)(&mm->mm_cid.mutex);
+
+ hlist_for_each_entry(t, &mm->mm_cid.user_list, mm_cid.node) {
+ if (t == current)
+ continue;
+ set_tsk_thread_flag(t, TIF_RSEQ_FORCE_RESTART);
+ }
+}
+
static void rseq_slowpath_update_usr(struct pt_regs *regs)
{
/*
diff --git a/kernel/sched/membarrier.c b/kernel/sched/membarrier.c
index 623445603725..696988bb991b 100644
--- a/kernel/sched/membarrier.c
+++ b/kernel/sched/membarrier.c
@@ -334,6 +334,7 @@ static int membarrier_private_expedited(int flags, int cpu_id)
MEMBARRIER_STATE_PRIVATE_EXPEDITED_RSEQ_READY))
return -EPERM;
ipi_func = ipi_rseq;
+ rseq_prepare_membarrier(mm);
} else {
WARN_ON_ONCE(flags);
if (!(atomic_read(&mm->membarrier_state) &
^ permalink raw reply related
* Re: [PATCH v5 5/8] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
From: Neil Armstrong @ 2026-04-24 15:12 UTC (permalink / raw)
To: linux-kernel-dev, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <20260424-add-mcu-fan-khadas-vim4-v5-5-afcfa7157b23@aliel.fr>
On 4/24/26 16:17, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> Replace the hardcoded MAX_LEVEL constant and fan register
> with values read from platform_data (fan_reg, max_level),
> as new MCUs need different values.
>
> Optionally acquire and enable a "fan" regulator supply
> at probe time and on resume,
> so boards that gate fan power through a regulator are handled.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> drivers/thermal/khadas_mcu_fan.c | 37 ++++++++++++++++++++++++++++++-------
> 1 file changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
> index d35e5313bea41..5603fa099a858 100644
> --- a/drivers/thermal/khadas_mcu_fan.c
> +++ b/drivers/thermal/khadas_mcu_fan.c
> @@ -13,13 +13,15 @@
> #include <linux/regmap.h>
> #include <linux/sysfs.h>
> #include <linux/thermal.h>
> -
> -#define MAX_LEVEL 3
> +#include <linux/regulator/consumer.h>
>
> struct khadas_mcu_fan_ctx {
> struct khadas_mcu *mcu;
> + unsigned int fan_reg;
> unsigned int level;
> + unsigned int max_level;
> struct thermal_cooling_device *cdev;
> + struct regulator *power;
> };
>
> static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> @@ -27,8 +29,7 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> {
> int ret;
>
> - ret = regmap_write(ctx->mcu->regmap, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> - level);
> + ret = regmap_write(ctx->mcu->regmap, ctx->fan_reg, level);
> if (ret)
> return ret;
>
> @@ -40,7 +41,9 @@ static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
> static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
> unsigned long *state)
> {
> - *state = MAX_LEVEL;
> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
> +
> + *state = ctx->max_level;
>
> return 0;
> }
> @@ -61,7 +64,7 @@ khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
> {
> struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>
> - if (state > MAX_LEVEL)
> + if (state > ctx->max_level)
> return -EINVAL;
>
> if (state == ctx->level)
> @@ -78,6 +81,7 @@ static const struct thermal_cooling_device_ops khadas_mcu_fan_cooling_ops = {
>
> static int khadas_mcu_fan_probe(struct platform_device *pdev)
> {
> + const struct khadas_mcu_fan_pdata *pdata = dev_get_platdata(&pdev->dev);
> struct khadas_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
> struct thermal_cooling_device *cdev;
> struct device *dev = &pdev->dev;
> @@ -87,7 +91,21 @@ static int khadas_mcu_fan_probe(struct platform_device *pdev)
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> return -ENOMEM;
> +
> ctx->mcu = mcu;
> + ctx->fan_reg = pdata->fan_reg;
> + ctx->max_level = pdata->max_level;
> +
> + ctx->power = devm_regulator_get(dev->parent, "fan");
> + if (IS_ERR(ctx->power))
> + return PTR_ERR(ctx->power);
> +
> + ret = regulator_enable(ctx->power);
> + if (ret) {
> + dev_err(dev, "Failed to enable fan power supply: %d\n", ret);
> + return ret;
> + }
> +
> platform_set_drvdata(pdev, ctx);
>
> cdev = devm_thermal_of_cooling_device_register(dev->parent,
> @@ -124,12 +142,17 @@ static int khadas_mcu_fan_suspend(struct device *dev)
>
> ctx->level = level_save;
>
> - return 0;
> + return regulator_disable(ctx->power);
> }
>
> static int khadas_mcu_fan_resume(struct device *dev)
> {
> struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = regulator_enable(ctx->power);
> + if (ret)
> + return ret;
>
> return khadas_mcu_fan_set_level(ctx, ctx->level);
> }
>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* [PATCH v2 1/2] scsi: ufs: core: Introduce function ufshcd_query_attr_qword()
From: Can Guo @ 2026-04-24 15:14 UTC (permalink / raw)
To: avri.altman, bvanassche, beanhuo, peter.wang, martin.petersen,
mani
Cc: linux-scsi, Can Guo, Alim Akhtar, James E.J. Bottomley,
Matthias Brugger, AngeloGioacchino Del Regno, Neil Armstrong,
Ram Kumar Dwivedi, Zhongqiu Han, Huan Tang, Daniel Lee, Liu Song,
Bean Huo, vamshi gajjela, Rafael J. Wysocki, Adrian Hunter,
open list,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek
In-Reply-To: <20260424151420.111675-1-can.guo@oss.qualcomm.com>
Introduce a new generic function ufshcd_query_attr_qword() to handle
quad-word (64-bit) UFS attribute operations. This consolidates the
handling of 64-bit attributes which was previously scattered across
multiple specialized functions.
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
drivers/ufs/core/ufs-sysfs.c | 30 ++++++--
drivers/ufs/core/ufshcd-priv.h | 3 +-
drivers/ufs/core/ufshcd.c | 126 +++++++++++++++++----------------
3 files changed, 94 insertions(+), 65 deletions(-)
diff --git a/drivers/ufs/core/ufs-sysfs.c b/drivers/ufs/core/ufs-sysfs.c
index 99af3c73f1af..d9dc4cc3452e 100644
--- a/drivers/ufs/core/ufs-sysfs.c
+++ b/drivers/ufs/core/ufs-sysfs.c
@@ -594,8 +594,13 @@ static ssize_t device_lvl_exception_id_show(struct device *dev,
u64 exception_id;
int err;
+ if (hba->dev_info.wspecversion < 0x410)
+ return -EOPNOTSUPP;
+
ufshcd_rpm_get_sync(hba);
- err = ufshcd_read_device_lvl_exception_id(hba, &exception_id);
+ err = ufshcd_query_attr_qword(hba, UPIU_QUERY_OPCODE_READ_ATTR,
+ QUERY_ATTR_IDN_DEV_LVL_EXCEPTION_ID,
+ 0, 0, &exception_id);
ufshcd_rpm_put_sync(hba);
if (err)
@@ -1670,6 +1675,12 @@ static inline bool ufshcd_is_wb_attrs(enum attr_idn idn)
idn <= QUERY_ATTR_IDN_CURR_WB_BUFF_SIZE;
}
+static inline bool ufshcd_is_qword_attr(enum attr_idn idn)
+{
+ return idn == QUERY_ATTR_IDN_TIMESTAMP ||
+ idn == QUERY_ATTR_IDN_DEV_LVL_EXCEPTION_ID;
+}
+
static int wb_read_resize_attrs(struct ufs_hba *hba,
enum attr_idn idn, u32 *attr_val)
{
@@ -1736,6 +1747,7 @@ static ssize_t _name##_show(struct device *dev, \
struct device_attribute *attr, char *buf) \
{ \
struct ufs_hba *hba = dev_get_drvdata(dev); \
+ u64 qword_value; \
u32 value; \
int ret; \
u8 index = 0; \
@@ -1748,14 +1760,24 @@ static ssize_t _name##_show(struct device *dev, \
if (ufshcd_is_wb_attrs(QUERY_ATTR_IDN##_uname)) \
index = ufshcd_wb_get_query_index(hba); \
ufshcd_rpm_get_sync(hba); \
- ret = ufshcd_query_attr(hba, UPIU_QUERY_OPCODE_READ_ATTR, \
- QUERY_ATTR_IDN##_uname, index, 0, &value); \
+ if (ufshcd_is_qword_attr(QUERY_ATTR_IDN##_uname)) \
+ ret = ufshcd_query_attr_qword(hba, \
+ UPIU_QUERY_OPCODE_READ_ATTR, \
+ QUERY_ATTR_IDN##_uname, \
+ index, 0, &qword_value); \
+ else \
+ ret = ufshcd_query_attr(hba, \
+ UPIU_QUERY_OPCODE_READ_ATTR, \
+ QUERY_ATTR_IDN##_uname, index, 0, &value); \
ufshcd_rpm_put_sync(hba); \
if (ret) { \
ret = -EINVAL; \
goto out; \
} \
- ret = sysfs_emit(buf, "0x%08X\n", value); \
+ if (ufshcd_is_qword_attr(QUERY_ATTR_IDN##_uname)) \
+ ret = sysfs_emit(buf, "0x%016llX\n", qword_value); \
+ else \
+ ret = sysfs_emit(buf, "0x%08X\n", value); \
out: \
up(&hba->host_sem); \
return ret; \
diff --git a/drivers/ufs/core/ufshcd-priv.h b/drivers/ufs/core/ufshcd-priv.h
index 0a72148cb053..ed1adeb22ec6 100644
--- a/drivers/ufs/core/ufshcd-priv.h
+++ b/drivers/ufs/core/ufshcd-priv.h
@@ -60,6 +60,8 @@ int ufshcd_query_attr_retry(struct ufs_hba *hba, enum query_opcode opcode,
u32 *attr_val);
int ufshcd_query_attr(struct ufs_hba *hba, enum query_opcode opcode,
enum attr_idn idn, u8 index, u8 selector, u32 *attr_val);
+int ufshcd_query_attr_qword(struct ufs_hba *hba, enum query_opcode opcode,
+ enum attr_idn idn, u8 index, u8 sel, u64 *attr_val);
int ufshcd_query_flag(struct ufs_hba *hba, enum query_opcode opcode,
enum flag_idn idn, u8 index, bool *flag_res);
void ufshcd_auto_hibern8_update(struct ufs_hba *hba, u32 ahit);
@@ -106,7 +108,6 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
enum query_opcode desc_op);
int ufshcd_wb_toggle(struct ufs_hba *hba, bool enable);
-int ufshcd_read_device_lvl_exception_id(struct ufs_hba *hba, u64 *exception_id);
int ufshcd_uic_tx_eqtr(struct ufs_hba *hba, int gear);
void ufshcd_apply_valid_tx_eq_settings(struct ufs_hba *hba);
diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index 4805e40ed4d7..c92e0409c793 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -3611,6 +3611,67 @@ int ufshcd_query_attr_retry(struct ufs_hba *hba,
return ret;
}
+/**
+ * ufshcd_query_attr_qword - Function of sending query requests for quad-word attributes
+ * @hba: per-adapter instance
+ * @opcode: attribute opcode
+ * @idn: attribute idn to access
+ * @index: index field
+ * @sel: selector field
+ * @attr_val: the attribute value after the query request completes
+ *
+ * Return: 0 for success, non-zero in case of failure.
+ */
+int ufshcd_query_attr_qword(struct ufs_hba *hba, enum query_opcode opcode,
+ enum attr_idn idn, u8 index, u8 sel, u64 *attr_val)
+{
+ struct utp_upiu_query_v4_0 *upiu_req;
+ struct utp_upiu_query_v4_0 *upiu_resp;
+ struct ufs_query_req *request = NULL;
+ struct ufs_query_res *response = NULL;
+ int err;
+
+ if (!attr_val) {
+ dev_err(hba->dev, "%s: attribute value required for opcode 0x%x\n",
+ __func__, opcode);
+ return -EINVAL;
+ }
+
+ ufshcd_dev_man_lock(hba);
+
+ ufshcd_init_query(hba, &request, &response, opcode, idn, index, sel);
+
+ switch (opcode) {
+ case UPIU_QUERY_OPCODE_WRITE_ATTR:
+ request->query_func = UPIU_QUERY_FUNC_STANDARD_WRITE_REQUEST;
+ upiu_req = (struct utp_upiu_query_v4_0 *)&request->upiu_req;
+ put_unaligned_be64(*attr_val, &upiu_req->osf3);
+ break;
+ case UPIU_QUERY_OPCODE_READ_ATTR:
+ request->query_func = UPIU_QUERY_FUNC_STANDARD_READ_REQUEST;
+ break;
+ default:
+ dev_err(hba->dev, "%s: Expected query attr opcode but got = 0x%.2x\n",
+ __func__, opcode);
+ err = -EINVAL;
+ goto out_unlock;
+ }
+
+ err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, dev_cmd_timeout);
+ if (err) {
+ dev_err(hba->dev, "%s: opcode 0x%.2x for idn %d failed, index %d, selector %d, err = %d\n",
+ __func__, opcode, idn, index, sel, err);
+ goto out_unlock;
+ }
+
+ upiu_resp = (struct utp_upiu_query_v4_0 *)response;
+ *attr_val = get_unaligned_be64(&upiu_resp->osf3);
+
+out_unlock:
+ ufshcd_dev_man_unlock(hba);
+ return err;
+}
+
/*
* Return: 0 upon success; > 0 in case the UFS device reported an OCS error;
* < 0 if another error occurred.
@@ -6224,46 +6285,6 @@ static void ufshcd_bkops_exception_event_handler(struct ufs_hba *hba)
__func__, err);
}
-/*
- * Return: 0 upon success; > 0 in case the UFS device reported an OCS error;
- * < 0 if another error occurred.
- */
-int ufshcd_read_device_lvl_exception_id(struct ufs_hba *hba, u64 *exception_id)
-{
- struct utp_upiu_query_v4_0 *upiu_resp;
- struct ufs_query_req *request = NULL;
- struct ufs_query_res *response = NULL;
- int err;
-
- if (hba->dev_info.wspecversion < 0x410)
- return -EOPNOTSUPP;
-
- ufshcd_hold(hba);
- mutex_lock(&hba->dev_cmd.lock);
-
- ufshcd_init_query(hba, &request, &response,
- UPIU_QUERY_OPCODE_READ_ATTR,
- QUERY_ATTR_IDN_DEV_LVL_EXCEPTION_ID, 0, 0);
-
- request->query_func = UPIU_QUERY_FUNC_STANDARD_READ_REQUEST;
-
- err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, dev_cmd_timeout);
-
- if (err) {
- dev_err(hba->dev, "%s: failed to read device level exception %d\n",
- __func__, err);
- goto out;
- }
-
- upiu_resp = (struct utp_upiu_query_v4_0 *)response;
- *exception_id = get_unaligned_be64(&upiu_resp->osf3);
-out:
- mutex_unlock(&hba->dev_cmd.lock);
- ufshcd_release(hba);
-
- return err;
-}
-
static int __ufshcd_wb_toggle(struct ufs_hba *hba, bool set, enum flag_idn idn)
{
u8 index;
@@ -9113,35 +9134,20 @@ static int ufshcd_device_params_init(struct ufs_hba *hba)
static void ufshcd_set_timestamp_attr(struct ufs_hba *hba)
{
- int err;
- struct ufs_query_req *request = NULL;
- struct ufs_query_res *response = NULL;
struct ufs_dev_info *dev_info = &hba->dev_info;
- struct utp_upiu_query_v4_0 *upiu_data;
+ u64 ts_ns;
+ int err;
if (dev_info->wspecversion < 0x400 ||
hba->dev_quirks & UFS_DEVICE_QUIRK_NO_TIMESTAMP_SUPPORT)
return;
- ufshcd_dev_man_lock(hba);
-
- ufshcd_init_query(hba, &request, &response,
- UPIU_QUERY_OPCODE_WRITE_ATTR,
- QUERY_ATTR_IDN_TIMESTAMP, 0, 0);
-
- request->query_func = UPIU_QUERY_FUNC_STANDARD_WRITE_REQUEST;
-
- upiu_data = (struct utp_upiu_query_v4_0 *)&request->upiu_req;
-
- put_unaligned_be64(ktime_get_real_ns(), &upiu_data->osf3);
-
- err = ufshcd_exec_dev_cmd(hba, DEV_CMD_TYPE_QUERY, dev_cmd_timeout);
-
+ ts_ns = ktime_get_real_ns();
+ err = ufshcd_query_attr_qword(hba, UPIU_QUERY_OPCODE_WRITE_ATTR,
+ QUERY_ATTR_IDN_TIMESTAMP, 0, 0, &ts_ns);
if (err)
dev_err(hba->dev, "%s: failed to set timestamp %d\n",
__func__, err);
-
- ufshcd_dev_man_unlock(hba);
}
/**
--
2.34.1
^ permalink raw reply related
* [GIT PULL] KVM/arm64 fixes for 7.1, take #1
From: Marc Zyngier @ 2026-04-24 15:14 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Ben Simner, David Woodhouse, Fuad Tabba, Quentin Perret,
Sebastian Ene, Vincent Donnefort, Will Deacon, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu, kvmarm,
linux-arm-kernel, kvm
Paolo,
This is the first drop of KVM/arm64 fixes for 7.1. Nothing really
major so far, but a rather wide range of fixes for idreg handling,
long standing regressions, SMCCC compliance and more. Add a few
cleanups to the fix, and that's about it. As usual, gory details in
the tag below.
Please pull,
M.
The following changes since commit 94b4ae79ebb42a8a6f2124b4d4b033b15a98e4f9:
Merge branch kvm-arm64/misc-7.1 into kvmarm-master/next (2026-04-08 12:26:11 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-1
for you to fetch changes up to 4ce98bf0865c349e7026ad9c14f48da264920953:
KVM: arm64: Wake-up from WFI when iqrchip is in userspace (2026-04-24 12:03:57 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for 7.1, take #1
- Allow tracing for non-pKVM, which was accidentally disabled when
the series was merged
- Rationalise the way the pKVM hypercall ranges are defined by using
the same mechanism as already used for the vcpu_sysreg enum
- Enforce that SMCCC function numbers relayed by the pKVM proxy are
actually compliant with the specification
- Fix a couple of feature to idreg mappings which resulted in the
wrong sanitisation being applied
- Fix the GICD_IIDR revision number field that could never been
written correctly by userspace
- Make kvm_vcpu_initialized() correctly use its parameter instead
of relying on the surrounding context
- Enforce correct ordering in __pkvm_init_vcpu(), plugging a
potential pin leak at the same time
- Move __pkvm_init_finalise() to a less dangerous spot, avoiding
future problems
- Restore functional userspace irqchip support after a four year
breakage (last functional kernel was 5.18...). This is obviously
ripe for garbage collection.
- ... and the usual lot of spelling fixes
----------------------------------------------------------------
David Woodhouse (1):
KVM: arm64: vgic: Fix IIDR revision field extracted from wrong value
Fuad Tabba (5):
KVM: arm64: Fix FEAT_Debugv8p9 to check DebugVer, not PMUVer
KVM: arm64: Fix typo in feature check comments
KVM: arm64: Fix FEAT_SPE_FnE to use PMSIDR_EL1.FnE, not PMSVer
KVM: arm64: Fix kvm_vcpu_initialized() macro parameter
KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu()
Marc Zyngier (2):
KVM: arm64: pkvm: Adopt MARKER() to define host hypercall ranges
KVM: arm64: Wake-up from WFI when iqrchip is in userspace
Quentin Perret (1):
KVM: arm64: Fix initialisation order in __pkvm_init_finalise()
Sebastian Ene (1):
KVM: arm64: Reject non compliant SMCCC function calls in pKVM
Vincent Donnefort (1):
KVM: arm64: Re-allow hyp tracing HVCs for [nh]VHE
arch/arm64/include/asm/kvm_asm.h | 28 ++++++++++++++++++----------
arch/arm64/include/asm/kvm_host.h | 5 +----
arch/arm64/kvm/arm.c | 4 ++++
arch/arm64/kvm/config.c | 23 ++++++++++++++++-------
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 30 +++++++++++++++++-------------
arch/arm64/kvm/hyp/nvhe/pkvm.c | 38 +++++++++++++++++++++++++-------------
arch/arm64/kvm/hyp/nvhe/setup.c | 6 +++---
arch/arm64/kvm/vgic/vgic-mmio-v2.c | 2 +-
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 2 +-
9 files changed, 86 insertions(+), 52 deletions(-)
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation
From: Will Deacon @ 2026-04-24 15:16 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Evangelos Petrongonas, Robin Murphy, Joerg Roedel, Nicolin Chen,
Pranjal Shrivastava, Lu Baolu, linux-arm-kernel, iommu,
linux-kernel, nh-open-source, Zeev Zilberman
In-Reply-To: <20260423223716.GS3611611@ziepe.ca>
On Thu, Apr 23, 2026 at 07:37:16PM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 23, 2026 at 06:07:23PM +0100, Will Deacon wrote:
>
> > I don't think it's that odd given that the STE/CD entries are bigger
> > than PTEs and the SMMU permits a lot more relaxations about how they are
> > accessed and cached compared to the PTW.
>
> Well I'm not sure bigger really matters, but I wasn't aware there was
> a spec relaxation here that would make the cachable path not viable
> for STE but not PTW...
Things like the SMMU being allowed to cache invalid structures and
loading structures using multiple, unordered accesses are the things
that worry me relative to the page-tables. But see below.
> > Having said that, the page-table code looks broken to me even in the
> > coherent case:
> >
> > ptep[i] = pte | paddr_to_iopte(paddr + i * sz, data);
> >
> > as the compiler can theoretically make a right mess of that.
>
> Heh, great. The iommupt stuff does better.. It does a 64 bit cmpxchg
> to store a table pointer and a 64 bit WRITE_ONCE to store the pte,
> then a CMO through the DMA API.
>
> DMA API has to guarentee the right ordering, so we only have the
> question below:
>
> > > STE/CD is pretty simple now, there is only one place to put the CMO
> > > and the ordering is all handled with that shared code. We no longer
> > > care about ordering beyond all the writes must be visible to HW before
> > > issuing the CMDQ invalidation command - which is the same environment
> > > as the pagetable.
> >
> > You presumably rely on 64-bit single-copy atomicity for hitless updates,
> > no?
>
> Yes, just like the page table does..
>
> I hope that's not a problem or we have a issue with the PTW :)
You trimmed the part from my reply where I think we _do_ have an issue
with the PTW. Here it is again:
The non-coherent case looks more fragile, because I don't _think_ the
architecture provides any ordering or atomicity guarantees about cache
cleaning to the PoC. Presumably, the correct sequence would be to write
the PTE with the valid bit clear, do the CMO (with completion barrier),
*then* write the bottom byte with the valid bit set and do another CMO.
> > > I also don't like this "lot of systems thing". I don't want these
> > > powerful capabilities locked up in some giant CSP's proprietary
> > > kernel. I want all the companies in the cloud market to have access
> > > to the same feature set. That's what open source is supposed to be
> > > driving toward. I have several interesting use cases for this
> > > functionality already.
> >
> > Sorry, the point here was definitely _not_ about keeping this out of
> > tree, nor was I trying to say that this stuff isn't important. But the
> > mobile world doesn't give a hoot about KHO and _does_ tend to care about
> > the impact of CMO, so we have to find a way to balance the two worlds.
>
> Yes, that make sense.
>
> My argument is that the CMO on STE/CD shouldn't bother mobile, you
> could even view it as an micro-optimization because we do occasionally
> read-back the STE/CD fields.
I was against that read-back, iirc :)
> And if Samiullah can tackle dma_alloc_coherent then maybe the whole
> question is moot.
Yes, that would be great, but we probably need to fix the page-table
code too.
Will
^ permalink raw reply
* [PATCH] clk: bcm: rpi: Mark VEC clock as CLK_IGNORE_UNUSED
From: Mark Brown @ 2026-04-24 15:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael Turquette, Stephen Boyd, Florian Fainelli,
Broadcom internal kernel review list, Maxime Ripard,
Maíra Canal, Brian Masney, linux-clk, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Mark Brown
From: Maíra Canal <mcanal@igalia.com>
On Raspberry Pi 3B, the VEC clock is used by the VideoCore firmware
display driver, which remains active until the vc4 driver loads and
sends NOTIFY_DISPLAY_DONE. If this clock is disabled during boot, a bus
lockup happens and the firmware becomes unresponsive, causing a complete
system lockup.
Mark the VEC clock with CLK_IGNORE_UNUSED so it survives the unused
clock disablement and remains available until the vc4 driver takes over
display management.
Fixes: 672299736af6 ("clk: bcm: rpi: Manage clock rate in prepare/unprepare callbacks")
Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/r/5f0bec08-f458-4fba-8bf3-06817a100c4c@sirena.org.uk
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Link: https://patch.msgid.link/20260401111416.562279-2-mcanal@igalia.com
Tested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Resending this fix directly in the hope of getting it into -rc1 since
this is a clear boot regression and neither the original report nor the
fix have had any response for some reason.
---
drivers/clk/bcm/clk-raspberrypi.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index df2d246eb6ef..f1a99de6de4f 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -160,6 +160,13 @@ raspberrypi_clk_variants[RPI_FIRMWARE_NUM_CLK_ID] = {
[RPI_FIRMWARE_VEC_CLK_ID] = {
.export = true,
.minimize = true,
+
+ /*
+ * If this clock is disabled during boot, it causes a bus
+ * lockup in RPi 3B. Therefore, make sure it's left enabled
+ * during boot.
+ */
+ .flags = CLK_IGNORE_UNUSED,
},
[RPI_FIRMWARE_DISP_CLK_ID] = {
.export = true,
---
base-commit: 672299736af6c398e867782708b7400957e62c76
change-id: 20260423-clk-bcm-fix-pi3-24feb4f409fd
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation
From: Jason Gunthorpe @ 2026-04-24 15:42 UTC (permalink / raw)
To: Will Deacon
Cc: Evangelos Petrongonas, Robin Murphy, Joerg Roedel, Nicolin Chen,
Pranjal Shrivastava, Lu Baolu, linux-arm-kernel, iommu,
linux-kernel, nh-open-source, Zeev Zilberman
In-Reply-To: <aeuJQW8bGLY-O_vv@willie-the-truck>
On Fri, Apr 24, 2026 at 04:16:17PM +0100, Will Deacon wrote:
> > > > STE/CD is pretty simple now, there is only one place to put the CMO
> > > > and the ordering is all handled with that shared code. We no longer
> > > > care about ordering beyond all the writes must be visible to HW before
> > > > issuing the CMDQ invalidation command - which is the same environment
> > > > as the pagetable.
> > >
> > > You presumably rely on 64-bit single-copy atomicity for hitless updates,
> > > no?
> >
> > Yes, just like the page table does..
> >
> > I hope that's not a problem or we have a issue with the PTW :)
>
> You trimmed the part from my reply where I think we _do_ have an issue
> with the PTW. Here it is again:
>
> The non-coherent case looks more fragile, because I don't _think_ the
> architecture provides any ordering or atomicity guarantees about cache
> cleaning to the PoC. Presumably, the correct sequence would be to write
> the PTE with the valid bit clear, do the CMO (with completion barrier),
> *then* write the bottom byte with the valid bit set and do another CMO.
I wasn't sure if you are being serious.
CMO + barriers must provide an ordering guarentee about cache cleaning
to POC otherwise the entire Linux DMA API is broken. dma_sync must
order with following device DMA. IMHO that's not negotiable for Linux.
All ARM iommus rely on 64 bit atomic non tearing. No bugs reported?
Any fix to that is going to have major performance downsides..
I also strongly suspect it is provided on real HW. It would be hard to
even build HW where <= 64 bit quanta can tear.
Maybe this is something ARM should take a look at.
At the very least it would warrant an IORT flag for safe HW to use to
opt into the faster cachable flow.
> > My argument is that the CMO on STE/CD shouldn't bother mobile, you
> > could even view it as an micro-optimization because we do occasionally
> > read-back the STE/CD fields.
>
> I was against that read-back, iirc :)
Yes, but it is OK :)
> > And if Samiullah can tackle dma_alloc_coherent then maybe the whole
> > question is moot.
>
> Yes, that would be great, but we probably need to fix the page-table
> code too.
You really want to deal with the likely perf regressions that would
cause on Android/etc?
Jason
^ permalink raw reply
* [PATCH v5 3/8] firmware: meson: sm: Add thermal calibration SMC call
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add SM_THERMAL_CALIB_READ at SMC ID 0x82000047 in the command
table and implement meson_sm_get_thermal_calib(), which forwards the
tsensor_id argument to the secure monitor and returns the calibration data.
Also realign the CMD() column to improve readability.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/firmware/meson/meson_sm.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 3ab67aaa9e5da..4e57986724212 100644
--- a/drivers/firmware/meson/meson_sm.c
+++ b/drivers/firmware/meson/meson_sm.c
@@ -41,12 +41,13 @@ static const struct meson_sm_chip gxbb_chip = {
.cmd_shmem_in_base = 0x82000020,
.cmd_shmem_out_base = 0x82000021,
.cmd = {
- CMD(SM_EFUSE_READ, 0x82000030),
- CMD(SM_EFUSE_WRITE, 0x82000031),
+ CMD(SM_EFUSE_READ, 0x82000030),
+ CMD(SM_EFUSE_WRITE, 0x82000031),
CMD(SM_EFUSE_USER_MAX, 0x82000033),
- CMD(SM_GET_CHIP_ID, 0x82000044),
- CMD(SM_A1_PWRC_SET, 0x82000093),
- CMD(SM_A1_PWRC_GET, 0x82000095),
+ CMD(SM_GET_CHIP_ID, 0x82000044),
+ CMD(SM_THERMAL_CALIB_READ, 0x82000047),
+ CMD(SM_A1_PWRC_SET, 0x82000093),
+ CMD(SM_A1_PWRC_GET, 0x82000095),
{ /* sentinel */ },
},
};
@@ -245,6 +246,24 @@ struct meson_sm_firmware *meson_sm_get(struct device_node *sm_node)
}
EXPORT_SYMBOL_GPL(meson_sm_get);
+/**
+ *
+ * meson_sm_get_thermal_calib - Read thermal sensor calibration data.
+ * @fw: Pointer to secure-monitor firmware.
+ * @trim_info: Pointer to store the returned calibration data.
+ * @tsensor_id: Sensor index to identify which sensor's calibration data
+ * to retrieve
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id)
+{
+ return meson_sm_call(fw, SM_THERMAL_CALIB_READ, trim_info, tsensor_id,
+ 0, 0, 0, 0);
+}
+EXPORT_SYMBOL_GPL(meson_sm_get_thermal_calib);
+
#define SM_CHIP_ID_LENGTH 119
#define SM_CHIP_ID_OFFSET 4
#define SM_CHIP_ID_SIZE 12
--
2.49.0
^ permalink raw reply related
* [PATCH v5 2/8] firmware: meson: sm: Thermal calibration read via secure monitor
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add SM_THERMAL_CALIB_READ to the secure monitor command enum and
introduce meson_sm_get_thermal_calib() to allow drivers to retrieve
thermal sensor calibration data through the firmware interface.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
include/linux/firmware/meson/meson_sm.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/firmware/meson/meson_sm.h b/include/linux/firmware/meson/meson_sm.h
index 8eaf8922ab020..3ebc2bd9a9760 100644
--- a/include/linux/firmware/meson/meson_sm.h
+++ b/include/linux/firmware/meson/meson_sm.h
@@ -12,6 +12,7 @@ enum {
SM_EFUSE_WRITE,
SM_EFUSE_USER_MAX,
SM_GET_CHIP_ID,
+ SM_THERMAL_CALIB_READ,
SM_A1_PWRC_SET,
SM_A1_PWRC_GET,
};
@@ -27,5 +28,7 @@ int meson_sm_call_read(struct meson_sm_firmware *fw, void *buffer,
unsigned int bsize, unsigned int cmd_index, u32 arg0,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
struct meson_sm_firmware *meson_sm_get(struct device_node *firmware_node);
+int meson_sm_get_thermal_calib(struct meson_sm_firmware *fw, u32 *trim_info,
+ u32 tsensor_id);
#endif /* _MESON_SM_FW_H_ */
--
2.49.0
^ permalink raw reply related
* [PATCH v5 0/8] arm64: amlogic: T7 thermal support
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau, Conor Dooley
This series adds thermal monitoring support for the Amlogic T7 SoC,
used on the Khadas VIM4 board.
The T7 exposes six thermal sensors (a53, a73, gpu, nna, vpu, hevc),
each accessible through the secure monitor firmware interface rather
than a directly mapped eFuse register as on older SoCs.
The series is organized as follows:
- Patch 1 extends the amlogic,t7-thermal DT binding to describe the
new amlogic,secure-monitor property.
- Patches 2-3 extend the Meson secure monitor driver to expose a
thermal calibration read command (SMC ID 0x82000047).
- Patch 4 adds the secure monitor readout path to the amlogic thermal
driver and introduces the amlogic,t7-thermal compatible.
- Patches 5-7 wire up the T7 DTSI with CPU cooling cells, sensor
nodes, and thermal zones.
- Patch 8 extends the Khadas VIM4 DTS to map all thermal zones to the
on-board MCU fan controller (states 30–100, corresponding to the
FAN_CTRL register range 0x1E–0x64).
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v5:
- PATCH 4: Remove unnecessary variable and coding style alignment
according to Neil's feedback.
- Link to v4: https://lore.kernel.org/r/20260423-add-thermal-t7-vim4-v4-0-d4c1528d5044@aliel.fr
Changes in v4:
- PATCH 4: Extract SM and syscon setup into amlogic_thermal_probe_sm() and
amlogic_thermal_probe_syscon() removing amlogic_thermal_initialize()
from Daniel's feedback.
Also fix pre-existing bug: move calibration readout before
devm_thermal_of_zone_register() to avoid reading uninitialized
trim_info, according to Daniel's feedback.
- Link to v3: https://lore.kernel.org/r/20260421-add-thermal-t7-vim4-v3-0-a2e7215ed003@aliel.fr
Changes in v3:
- PATCH 1: Replace second if check by an else statement.
Remove unnecessary label in example according to Conor's feedback
- Link to v2: https://lore.kernel.org/r/20260413-add-thermal-t7-vim4-v2-0-1002d90a0602@aliel.fr
Changes in v2:
- PATCH 1: change two const entries to enum, explain why sensor index is needed
reorder conditional compatible for required, and fallback only according to
Krzysztof's feedback.
- PATCH 3: Add kerneldoc for meson_sm_get_thermal_calib exported function
according to Krzysztof's feedback.
- Link to v1: https://lore.kernel.org/r/20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr
---
Ronald Claveau (8):
dt-bindings: thermal: amlogic: Add support for T7
firmware: meson: sm: Thermal calibration read via secure monitor
firmware: meson: sm: Add thermal calibration SMC call
thermal: amlogic: Add support for secure monitor calibration readout
arm64: dts: amlogic: t7: Add cooling cells to all CPUs
arm64: dts: amlogic: t7: Add thermal sensor nodes
arm64: dts: amlogic: t7: Add thermal zones
arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
.../bindings/thermal/amlogic,thermal.yaml | 37 +++-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 245 +++++++++++++++++++++
drivers/firmware/meson/meson_sm.c | 29 ++-
drivers/thermal/amlogic_thermal.c | 112 +++++++---
include/linux/firmware/meson/meson_sm.h | 3 +
6 files changed, 491 insertions(+), 37 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260410-add-thermal-t7-vim4-00e571badcc1
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b:v5
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
prerequisite-patch-id: e6a1b58b91a877504a12ae68bee71eb4e496c33b
prerequisite-patch-id: 406f88d7dabd3a870b358fb53c21686f29eb32b7
prerequisite-patch-id: d7a75ae3be0f54e0a7e81ccb0043a2f05423c9d0
prerequisite-patch-id: 5e19dc5ace12b532284246f5c2ff3f214d8a9c4f
prerequisite-patch-id: 06e85862f502b682dac8a0932986d43f0bb82770
prerequisite-patch-id: 4809bbedf79f59e1abc52c17cffc0b1bbb43d365
prerequisite-patch-id: c050e8bac4b5491f6c7008a5ccb26f20fad38b46
prerequisite-patch-id: 30677db8fc57270787245103c0d5acf8791307b0
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* [PATCH v5 6/8] arm64: dts: amlogic: t7: Add thermal sensor nodes
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add six temperature sensor nodes using the amlogic,t7-thermal compatible:
a73, a53, gpu, nna, vpu, and hevc. Each sensor retrieves its calibration
data from the secure monitor via the amlogic,secure-monitor phandle with
the corresponding tsensor_id argument.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 58 +++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7aec65f036a9c..62f259b2b17d2 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -656,6 +656,24 @@ sec_ao: ao-secure@10220 {
amlogic,has-chip-id;
};
+ a73_tsensor: temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
+
+ a53_tsensor: temperature-sensor@22000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x22000 0x0 0x50>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 2>;
+ };
+
pwm_ao_ef: pwm@30000 {
compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
reg = <0x0 0x30000 0x0 0x24>;
@@ -770,6 +788,46 @@ sd_emmc_c: mmc@8c000 {
assigned-clock-parents = <&xtal>;
status = "disabled";
};
+
+ gpu_tsensor: temperature-sensor@94000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x94000 0x0 0x50>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_MALI_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 3>;
+ };
+
+ nna_tsensor: temperature-sensor@96000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x96000 0x0 0x50>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_NNA_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 4>;
+ };
+
+ vpu_tsensor: temperature-sensor@98000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x98000 0x0 0x50>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_VPU_HDMI_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 6>;
+ };
+
+ hevc_tsensor: temperature-sensor@9a000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x9a000 0x0 0x50>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_DOS_HEVC_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 5>;
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH v5 4/8] thermal: amlogic: Add support for secure monitor calibration readout
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Some SoCs (e.g. T7) expose thermal calibration data through the secure
monitor rather than a directly accessible eFuse register. Add a use_sm
flag to amlogic_thermal_data to select this path, and retrieve the
firmware handle and tsensor_id from the "amlogic,secure-monitor" DT
phandle with one fixed argument.
Also introduce the amlogic,t7-thermal compatible using this new path.
While refactoring, fix a pre-existing bug where
amlogic_thermal_initialize() was called after
devm_thermal_of_zone_register(), causing the thermal framework to
read an uninitialized trim_info on zone registration.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/thermal/amlogic_thermal.c | 112 ++++++++++++++++++++++++++++----------
1 file changed, 82 insertions(+), 30 deletions(-)
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
index 5448d772db12a..a0b530624b60c 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -25,6 +25,7 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/thermal.h>
+#include <linux/firmware/meson/meson_sm.h>
#include "thermal_hwmon.h"
@@ -84,12 +85,14 @@ struct amlogic_thermal_soc_calib_data {
* @u_efuse_off: register offset to read fused calibration value
* @calibration_parameters: calibration parameters structure pointer
* @regmap_config: regmap config for the device
+ * @use_sm: read data from secure monitor instead of efuse
* This structure is required for configuration of amlogic thermal driver.
*/
struct amlogic_thermal_data {
int u_efuse_off;
const struct amlogic_thermal_soc_calib_data *calibration_parameters;
const struct regmap_config *regmap_config;
+ bool use_sm;
};
struct amlogic_thermal {
@@ -100,6 +103,8 @@ struct amlogic_thermal {
struct clk *clk;
struct thermal_zone_device *tzd;
u32 trim_info;
+ struct meson_sm_firmware *sm_fw;
+ u32 tsensor_id;
};
/*
@@ -133,26 +138,6 @@ static int amlogic_thermal_code_to_millicelsius(struct amlogic_thermal *pdata,
return temp;
}
-static int amlogic_thermal_initialize(struct amlogic_thermal *pdata)
-{
- int ret = 0;
- int ver;
-
- regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
- &pdata->trim_info);
-
- ver = TSENSOR_TRIM_VERSION(pdata->trim_info);
-
- if ((ver & TSENSOR_TRIM_CALIB_VALID_MASK) == 0) {
- ret = -EINVAL;
- dev_err(&pdata->pdev->dev,
- "tsensor thermal calibration not supported: 0x%x!\n",
- ver);
- }
-
- return ret;
-}
-
static int amlogic_thermal_enable(struct amlogic_thermal *data)
{
int ret;
@@ -190,6 +175,67 @@ static int amlogic_thermal_get_temp(struct thermal_zone_device *tz, int *temp)
return 0;
}
+static int amlogic_thermal_probe_sm(struct platform_device *pdev,
+ struct amlogic_thermal *pdata)
+{
+ struct device *dev = &pdev->dev;
+ struct of_phandle_args ph_args;
+ int ret;
+
+ ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node,
+ "amlogic,secure-monitor",
+ 1, 0, &ph_args);
+ if (ret)
+ return ret;
+
+ if (!ph_args.np) {
+ dev_err(dev, "Failed to parse secure monitor phandle\n");
+ return -ENODEV;
+ }
+
+ pdata->sm_fw = meson_sm_get(ph_args.np);
+ of_node_put(ph_args.np);
+ if (!pdata->sm_fw) {
+ dev_err(dev, "Failed to get secure monitor firmware\n");
+ return -EPROBE_DEFER;
+ }
+
+ pdata->tsensor_id = ph_args.args[0];
+
+ return meson_sm_get_thermal_calib(pdata->sm_fw,
+ &pdata->trim_info,
+ pdata->tsensor_id);
+}
+
+static int amlogic_thermal_probe_syscon(struct platform_device *pdev,
+ struct amlogic_thermal *pdata)
+{
+ struct device *dev = &pdev->dev;
+ int ver;
+
+ pdata->sec_ao_map =
+ syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+ "amlogic,ao-secure");
+ if (IS_ERR(pdata->sec_ao_map)) {
+ dev_err(dev, "syscon regmap lookup failed.\n");
+ return PTR_ERR(pdata->sec_ao_map);
+ }
+
+ regmap_read(pdata->sec_ao_map, pdata->data->u_efuse_off,
+ &pdata->trim_info);
+
+ ver = TSENSOR_TRIM_VERSION(pdata->trim_info);
+
+ if ((ver & TSENSOR_TRIM_CALIB_VALID_MASK) == 0) {
+ dev_err(&pdata->pdev->dev,
+ "tsensor thermal calibration not supported: 0x%x!\n",
+ ver);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct thermal_zone_device_ops amlogic_thermal_ops = {
.get_temp = amlogic_thermal_get_temp,
};
@@ -226,6 +272,12 @@ static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
.regmap_config = &amlogic_thermal_regmap_config_g12a,
};
+static const struct amlogic_thermal_data amlogic_thermal_t7_param = {
+ .use_sm = true,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
static const struct of_device_id of_amlogic_thermal_match[] = {
{
.compatible = "amlogic,g12a-ddr-thermal",
@@ -239,6 +291,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
.compatible = "amlogic,a1-cpu-thermal",
.data = &amlogic_thermal_a1_cpu_param,
},
+ {
+ .compatible = "amlogic,t7-thermal",
+ .data = &amlogic_thermal_t7_param,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
@@ -271,12 +327,12 @@ static int amlogic_thermal_probe(struct platform_device *pdev)
if (IS_ERR(pdata->clk))
return dev_err_probe(dev, PTR_ERR(pdata->clk), "failed to get clock\n");
- pdata->sec_ao_map = syscon_regmap_lookup_by_phandle
- (pdev->dev.of_node, "amlogic,ao-secure");
- if (IS_ERR(pdata->sec_ao_map)) {
- dev_err(dev, "syscon regmap lookup failed.\n");
- return PTR_ERR(pdata->sec_ao_map);
- }
+ if (pdata->data->use_sm)
+ ret = amlogic_thermal_probe_sm(pdev, pdata);
+ else
+ ret = amlogic_thermal_probe_syscon(pdev, pdata);
+ if (ret)
+ return ret;
pdata->tzd = devm_thermal_of_zone_register(&pdev->dev,
0,
@@ -290,10 +346,6 @@ static int amlogic_thermal_probe(struct platform_device *pdev)
devm_thermal_add_hwmon_sysfs(&pdev->dev, pdata->tzd);
- ret = amlogic_thermal_initialize(pdata);
- if (ret)
- return ret;
-
ret = amlogic_thermal_enable(pdata);
return ret;
--
2.49.0
^ permalink raw reply related
* [PATCH v5 5/8] arm64: dts: amlogic: t7: Add cooling cells to all CPUs
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add #cooling-cells = <2> to all CPU nodes (both little and big cluster)
to allow them to be used as cooling devices in thermal zone mappings.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 560c9dce35266..7aec65f036a9c 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -63,6 +63,7 @@ cpu100: cpu@100 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu101: cpu@101 {
@@ -77,6 +78,7 @@ cpu101: cpu@101 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu102: cpu@102 {
@@ -91,6 +93,7 @@ cpu102: cpu@102 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu103: cpu@103 {
@@ -105,6 +108,7 @@ cpu103: cpu@103 {
i-cache-size = <0x8000>;
i-cache-sets = <32>;
next-level-cache = <&l2_cache_l>;
+ #cooling-cells = <2>;
};
cpu0: cpu@0 {
@@ -119,6 +123,7 @@ cpu0: cpu@0 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -133,6 +138,7 @@ cpu1: cpu@1 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu2: cpu@2 {
@@ -147,6 +153,7 @@ cpu2: cpu@2 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
cpu3: cpu@3 {
@@ -161,6 +168,7 @@ cpu3: cpu@3 {
i-cache-size = <0x10000>;
i-cache-sets = <64>;
next-level-cache = <&l2_cache_b>;
+ #cooling-cells = <2>;
};
l2_cache_l: l2-cache-cluster0 {
--
2.49.0
^ permalink raw reply related
* [PATCH v5 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau, Conor Dooley
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
Unlike existing variants which use a phandle to the ao-secure syscon,
the T7 relies on a secure monitor interface described by a phandle and
a sensor index argument.
The T7 integrates multiple thermal sensors, all accessed through the
same SMC call. The sensor index argument is required to identify which
sensor's calibration data the secure monitor should return, as a single
SM_THERMAL_CALIB_READ command serves all of them.
Introduce the amlogic,secure-monitor property as a phandle-array and
make amlogic,ao-secure or amlogic,secure-monitor conditionally required
depending on the compatible.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../bindings/thermal/amlogic,thermal.yaml | 37 ++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 70b273271754b..e28612510d679 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -21,7 +21,9 @@ properties:
- amlogic,g12a-cpu-thermal
- amlogic,g12a-ddr-thermal
- const: amlogic,g12a-thermal
- - const: amlogic,a1-cpu-thermal
+ - enum:
+ - amlogic,a1-cpu-thermal
+ - amlogic,t7-thermal
reg:
maxItems: 1
@@ -42,12 +44,34 @@ properties:
'#thermal-sensor-cells':
const: 0
+ amlogic,secure-monitor:
+ description: phandle to the secure monitor
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ - items:
+ - description: phandle to the secure monitor
+ - description: sensor index to get specific calibration data
+
required:
- compatible
- reg
- interrupts
- clocks
- - amlogic,ao-secure
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,a1-cpu-thermal
+ - amlogic,g12a-thermal
+ then:
+ required:
+ - amlogic,ao-secure
+ else:
+ required:
+ - amlogic,secure-monitor
unevaluatedProperties: false
@@ -62,4 +86,13 @@ examples:
#thermal-sensor-cells = <0>;
amlogic,ao-secure = <&sec_AO>;
};
+ - |
+ temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
...
--
2.49.0
^ permalink raw reply related
* [PATCH v5 7/8] arm64: dts: amlogic: t7: Add thermal zones
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add thermal zones for all six sensors: a53, a73, gpu, nna, vpu, and hevc.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 179 ++++++++++++++++++++++++++++
1 file changed, 179 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 62f259b2b17d2..c6ea0f20a879f 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -9,6 +9,7 @@
#include <dt-bindings/clock/amlogic,t7-scmi.h>
#include <dt-bindings/clock/amlogic,t7-pll-clkc.h>
#include <dt-bindings/clock/amlogic,t7-peripherals-clkc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
interrupt-parent = <&gic>;
@@ -829,6 +830,184 @@ hevc_tsensor: temperature-sensor@9a000 {
amlogic,secure-monitor = <&sm 5>;
};
};
+ };
+
+ thermal-zones {
+ a53_thermal: a53-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a53_tsensor>;
+
+ trips {
+ a53_passive: a53-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a53_hot: a53-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a53_critical: a53-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a53 {
+ trip = <&a53_passive>;
+ cooling-device =
+ <&cpu100 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu101 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu102 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu103 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ a73_thermal: a73-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&a73_tsensor>;
+
+ trips {
+ a73_passive: a73-passive {
+ temperature = <85000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ a73_hot: a73-hot {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "hot";
+ };
+
+ a73_critical: a73-critical {
+ temperature = <110000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map-a73 {
+ trip = <&a73_passive>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+
+ gpu_thermal: gpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&gpu_tsensor>;
+
+ trips {
+ gpu_passive: gpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ gpu_hot: gpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+ gpu_critical: gpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ hevc_thermal: hevc-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&hevc_tsensor>;
+
+ trips {
+ hevc_passive: hevc-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_hot: hevc-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ hevc_critical: hevc-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ nna_thermal: nna-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&nna_tsensor>;
+
+ trips {
+ nna_passive: nna-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_hot: nna-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ nna_critical: nna-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
+
+ vpu_thermal: vpu-thermal {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ thermal-sensors = <&vpu_tsensor>;
+
+ trips {
+ vpu_passive: vpu-passive {
+ temperature = <95000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_hot: vpu-hot {
+ temperature = <105000>;
+ hysteresis = <5000>;
+ type = "passive";
+ };
+
+ vpu_critical: vpu-critical {
+ temperature = <115000>;
+ hysteresis = <1000>;
+ type = "critical";
+ };
+ };
+ };
};
};
--
2.49.0
^ permalink raw reply related
* [PATCH v5 8/8] arm64: dts: amlogic: t7: khadas-vim4: Add fan cooling to thermal zones
From: Ronald Claveau via B4 Relay @ 2026-04-24 15:45 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260424-add-thermal-t7-vim4-v5-0-9040ca36afe2@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
Add an active trip at 50°C to all six thermal zones and map it to the
khadas_mcu fan controller, using cooling states 30 to 100.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++++++++++++++
1 file changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 5d7f5390f3a66..ba9219073dd0a 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -157,6 +157,74 @@ wifi32k: wifi32k {
};
};
+&a53_thermal {
+ trips {
+ a53_active: a53-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a53_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&a73_thermal {
+ trips {
+ a73_active: a73-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&a73_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&gpu_thermal {
+ trips {
+ gpu_active: gpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&gpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
+&hevc_thermal {
+ trips {
+ hevc_active: hevc-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&hevc_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&i2c_m_ao_a {
status = "okay";
pinctrl-0 = <&i2c0_ao_d_pins>;
@@ -170,6 +238,23 @@ khadas_mcu: system-controller@18 {
};
};
+&nna_thermal {
+ trips {
+ nna_active: nna-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&nna_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_pins>;
@@ -266,3 +351,20 @@ &uart_a {
clocks = <&xtal>, <&xtal>, <&xtal>;
clock-names = "xtal", "pclk", "baud";
};
+
+&vpu_thermal {
+ trips {
+ vpu_active: vpu-active {
+ temperature = <50000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map {
+ trip = <&vpu_active>;
+ cooling-device = <&khadas_mcu 30 100>;
+ };
+ };
+};
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v2] kselftest/arm64: Fix build failure with GCC-15
From: Catalin Marinas @ 2026-04-24 15:51 UTC (permalink / raw)
To: Leo Yan
Cc: Will Deacon, Shuah Khan, Mark Brown, Thiago Jung Bauermann,
linux-arm-kernel, linux-kselftest, linux-kernel
In-Reply-To: <20260422-selftests_arm64_gcc15-v2-1-c0134de8838a@arm.com>
On Wed, Apr 22, 2026 at 06:42:54PM +0100, Leo Yan wrote:
> Building on Debian sid with GCC 15 fails:
>
> CC libc-gcs
> libc-gcs.c: In function 'ptrace_read_write':
> libc-gcs.c:142:25: error: storage size of 'child_gcs' isn't known
> 142 | struct user_gcs child_gcs;
> | ^~~~~~~~~
> libc-gcs.c:142:25: warning: unused variable 'child_gcs' [-Wunused-variable]
>
> For GCC-15, NT_ARM_GCS is defined in the libc header, causing gcs-util.h
> to skip its fallback definition of struct user_gcs. This leads to the
> compiler error.
>
> Fix this by including <asm/ptrace.h> to provide the proper definition.
This is not caused by GCC-15 as it doesn't provide these headers. AFAICT
on Debian we have NT_ARM_GCS coming from glibc and user_gcs from the
kernel asm/ptrace.h uapi header (linux-libc-dev). We also have
NT_ARM_GCS in linux/elf.h as part of the kernel headers.
While the kernel exposed the macro and structure in the same commit, I
don't think it is required distros to align the glibc macro with the
linux headers. Glibc does not even use the kernel's linux/elf.h for the
macros, it just adds the definitions when they turn up in a released
kernel.
So you can have a glibc that defines NT_ARM_GCS but a linux-libc-dev
package that is not up to date to include struct user_gcs.
I think a better fix is to always define struct user_gcs and only
conditionally define NT_ARM_GCS (IOW, move the #endif higher).
--
Catalin
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Allow disabling Stage 1 translation
From: Will Deacon @ 2026-04-24 16:01 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Evangelos Petrongonas, Robin Murphy, Joerg Roedel, Nicolin Chen,
Pranjal Shrivastava, Lu Baolu, linux-arm-kernel, iommu,
linux-kernel, nh-open-source, Zeev Zilberman
In-Reply-To: <20260424154256.GF3611611@ziepe.ca>
On Fri, Apr 24, 2026 at 12:42:56PM -0300, Jason Gunthorpe wrote:
> On Fri, Apr 24, 2026 at 04:16:17PM +0100, Will Deacon wrote:
> > > > > STE/CD is pretty simple now, there is only one place to put the CMO
> > > > > and the ordering is all handled with that shared code. We no longer
> > > > > care about ordering beyond all the writes must be visible to HW before
> > > > > issuing the CMDQ invalidation command - which is the same environment
> > > > > as the pagetable.
> > > >
> > > > You presumably rely on 64-bit single-copy atomicity for hitless updates,
> > > > no?
> > >
> > > Yes, just like the page table does..
> > >
> > > I hope that's not a problem or we have a issue with the PTW :)
> >
> > You trimmed the part from my reply where I think we _do_ have an issue
> > with the PTW. Here it is again:
> >
> > The non-coherent case looks more fragile, because I don't _think_ the
> > architecture provides any ordering or atomicity guarantees about cache
> > cleaning to the PoC. Presumably, the correct sequence would be to write
> > the PTE with the valid bit clear, do the CMO (with completion barrier),
> > *then* write the bottom byte with the valid bit set and do another CMO.
>
> I wasn't sure if you are being serious.
>
> CMO + barriers must provide an ordering guarentee about cache cleaning
> to POC otherwise the entire Linux DMA API is broken. dma_sync must
> order with following device DMA. IMHO that's not negotiable for Linux.
The problem is with concurrent DMA (from the page-table walker) and I
don't see anything that guarantees that in the CPU architecture. I don't
think the streaming DMA API pretends to handle that case, does it? It
relies on a pretty rigid ownership concept from what I understand.
> All ARM iommus rely on 64 bit atomic non tearing. No bugs reported?
It's hard to judge as I don't think SMMUs tend to perform a lot of
speculative address translation when DMA isn't active.
> Any fix to that is going to have major performance downsides..
>
> I also strongly suspect it is provided on real HW. It would be hard to
> even build HW where <= 64 bit quanta can tear.
>
> Maybe this is something ARM should take a look at.
Yes, we should ask. Maybe I missed something in the Arm ARM, but I can
also seeing it being a pain to specify this behaviour all the way out to
the PoC and I wouldn't be so bold as to say that it's hard to build HW
that would exhibit problems here.
> > > And if Samiullah can tackle dma_alloc_coherent then maybe the whole
> > > question is moot.
> >
> > Yes, that would be great, but we probably need to fix the page-table
> > code too.
>
> You really want to deal with the likely perf regressions that would
> cause on Android/etc?
Of course I'd rather that the architecture said that our current code
is fine, but if it doesn't then I don't have much choice, really. At the
very least, we should minimise the number of places where we rely on
non-architected behaviour and so keeping the CDs and STEs non-cacheable
remains my preference.
Will
^ permalink raw reply
* Re: [PATCH v2] kselftest/arm64: Fix build failure with GCC-15
From: Mark Brown @ 2026-04-24 16:07 UTC (permalink / raw)
To: Catalin Marinas
Cc: Leo Yan, Will Deacon, Shuah Khan, Thiago Jung Bauermann,
linux-arm-kernel, linux-kselftest, linux-kernel
In-Reply-To: <aeuRfEeOUWEHzPix@arm.com>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
On Fri, Apr 24, 2026 at 04:51:24PM +0100, Catalin Marinas wrote:
> On Wed, Apr 22, 2026 at 06:42:54PM +0100, Leo Yan wrote:
> > Building on Debian sid with GCC 15 fails:
> I think a better fix is to always define struct user_gcs and only
> conditionally define NT_ARM_GCS (IOW, move the #endif higher).
I've not actually double checked that everything is wired up properly
but I believe these days this should actually pick up asm/ptrace.h from
the headers_install target so a current kernel copy. We ought to be
able to remove the local definition of struct user_gcs I think, there's
still some weirdness with the NT_ definitions I can't remember but the
struct should be fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v3 4/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
From: Sudeep Holla @ 2026-04-24 16:09 UTC (permalink / raw)
To: Jonathan McDowell
Cc: linux-security-module, linux-kernel, Sudeep Holla,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene, Yeoreum Yun
In-Reply-To: <2e7b4dc552b45ddf14cc43bc449cbebb4ade0027.1777036497.git.noodles@meta.com>
On Fri, Apr 24, 2026 at 02:24:42PM +0100, Jonathan McDowell wrote:
> From: Yeoreum Yun <yeoreum.yun@arm.com>
>
> This reverts commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75, which was
> added to address ordering issues with the IMA LSM initialisation where
> the TPM would not be fully ready by the time IMA wanted it. This has
> been resolved within IMA by retrying setup during late_initcall_sync if
> the TPM is not available at first.
>
Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH v3 3/4] Revert "tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in"
From: Sudeep Holla @ 2026-04-24 16:10 UTC (permalink / raw)
To: Jonathan McDowell
Cc: linux-security-module, linux-kernel, Sudeep Holla,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene, Yeoreum Yun
In-Reply-To: <f8d6dcbeb5bf2d4316989d05dcaae20225774d51.1777036497.git.noodles@meta.com>
On Fri, Apr 24, 2026 at 02:24:30PM +0100, Jonathan McDowell wrote:
> From: Yeoreum Yun <yeoreum.yun@arm.com>
>
> This reverts commit 746d9e9f62a6e8ba0eba2b83fc61cfe7fa8797ce.
>
> Now that IMA will retry in the late_initcall_sync level if the TPM is
> not available at first, this change is no longer required.
>
Acked-by: Sudeep Holla <sudeep.holla@kernel.org>
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 15/15] arm64: dts: ti: beagley-ai: Enable HDMI display and audio
From: Robert Nelson @ 2026-04-24 16:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet, devicetree,
dri-devel, linux-kernel, linux-arm-kernel, Andrew Davis
In-Reply-To: <20260420-beagley-ai-display-v1-15-f628543dfd14@ideasonboard.com>
On Mon, Apr 20, 2026 at 8:04 AM Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
>
> From: Andrew Davis <afd@ti.com>
>
> Enable HDMI support for BeagleY-AI platform. The display controller used is
> TIDSS and the HDMI bridge used is IT66122.
>
> Based on DT by: Robert Nelson <robertcnelson@gmail.com>
> Signed-off-by: Andrew Davis <afd@ti.com>
> Signed-off-by: Swamil Jain <s-jain1@ti.com>
> [tomi.valkeinen: cosmetic fixes]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Thank you for getting the display back end working on j722s family!
After this goes in, I need to submit the usb/usb-hub changes to enable
USB support...
Regards,
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox