* [PATCH 3/8] firmware: meson: sm: Add thermal calibration SMC call
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/firmware/meson/meson_sm.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/meson/meson_sm.c b/drivers/firmware/meson/meson_sm.c
index 3ab67aaa9e5da..da0dbcd8a2ff2 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,14 @@ struct meson_sm_firmware *meson_sm_get(struct device_node *sm_node)
}
EXPORT_SYMBOL_GPL(meson_sm_get);
+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 2/8] firmware: meson: sm: Thermal calibration read via secure monitor
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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.
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 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Ronald Claveau @ 2026-04-10 16:48 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: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@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.
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.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../bindings/thermal/amlogic,thermal.yaml | 40 +++++++++++++++++++++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 70b273271754b..85ee73c6e1161 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -22,6 +22,7 @@ properties:
- amlogic,g12a-ddr-thermal
- const: amlogic,g12a-thermal
- const: amlogic,a1-cpu-thermal
+ - const: amlogic,t7-thermal
reg:
maxItems: 1
@@ -42,12 +43,40 @@ 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
+
required:
- compatible
- reg
- interrupts
- clocks
- - amlogic,ao-secure
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - amlogic,a1-cpu-thermal
+ then:
+ required:
+ - amlogic,ao-secure
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: amlogic,t7-thermal
+ then:
+ required:
+ - amlogic,secure-monitor
unevaluatedProperties: false
@@ -62,4 +91,13 @@ examples:
#thermal-sensor-cells = <0>;
amlogic,ao-secure = <&sec_AO>;
};
+ - |
+ 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>;
+ };
...
--
2.49.0
^ permalink raw reply related
* [PATCH 0/8] arm64: amlogic: T7 thermal support
From: Ronald Claveau @ 2026-04-10 16:48 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
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>
---
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 | 40 +++-
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 102 +++++++++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 245 +++++++++++++++++++++
drivers/firmware/meson/meson_sm.c | 19 +-
drivers/thermal/amlogic_thermal.c | 58 ++++-
include/linux/firmware/meson/meson_sm.h | 3 +
6 files changed, 456 insertions(+), 11 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:v2
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: 34a2bbfe3ce30c530e69af5083aa26534b2c2560
prerequisite-patch-id: 406f88d7dabd3a870b358fb53c21686f29eb32b7
prerequisite-patch-id: d7a75ae3be0f54e0a7e81ccb0043a2f05423c9d0
prerequisite-patch-id: 5e19dc5ace12b532284246f5c2ff3f214d8a9c4f
prerequisite-patch-id: d6a87ebcf5246eb67b94ca0908afa3df9f9383fe
prerequisite-patch-id: 4809bbedf79f59e1abc52c17cffc0b1bbb43d365
prerequisite-patch-id: c050e8bac4b5491f6c7008a5ccb26f20fad38b46
prerequisite-patch-id: 30677db8fc57270787245103c0d5acf8791307b0
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: monaco: Add default GIC address cells
From: Manivannan Sadhasivam @ 2026-04-10 16:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Ziyue Zhang, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260407201518.24949-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 10:15:19PM +0200, Krzysztof Kozlowski wrote:
> Add missing address-cells 0 to GIC interrupt node to silence W=1
> warning:
>
> monaco.dtsi:2326.4-2329.30: Warning (interrupt_map): /soc@0/pci@1c00000:interrupt-map:
> Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
>
> Value '0' is correct because:
> 1. GIC interrupt controller does not have children,
> 2. interrupt-map property (in PCI node) consists of five components and
> the fourth component 'parent unit address', which size is defined by
> '#address-cells' of the node pointed to by the interrupt-parent
> component, is not used (=0).
>
> Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
>
> ---
>
> Fix for v7.0-rcX.
> ---
> arch/arm64/boot/dts/qcom/monaco.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
> index 7b1d57460f1e..5f060b24d52e 100644
> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
> @@ -7380,6 +7380,7 @@ intc: interrupt-controller@17a00000 {
> interrupt-controller;
> #redistributor-regions = <1>;
> redistributor-stride = <0x0 0x20000>;
> + #address-cells = <0>;
> };
>
> watchdog@17c10000 {
> --
> 2.51.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH v2 10/10] arm64: dts: renesas: r9a09g087: add MTU3 support
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
The Renesas RZ/N2H (R9A09G087) SoC has an MTU3 block.
Add support for it.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* no changes
arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 68 ++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
index f697e9698ed39..c64b532f3d234 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
@@ -1119,6 +1119,74 @@ gic: interrupt-controller@83000000 {
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
};
+ mtu3: timer@90001200 {
+ compatible = "renesas,r9a09g087-mtu3",
+ "renesas,rz-mtu3";
+ reg = <0 0x90001200 0 0xb00>;
+ interrupts = <GIC_SPI 420 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 421 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 422 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 423 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 424 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 425 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 426 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 427 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 428 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 429 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 430 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 432 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 434 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 435 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 437 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 438 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 439 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 440 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 441 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 442 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 443 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 444 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 445 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 446 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 447 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 450 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 451 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 452 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 453 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 454 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 455 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 456 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 458 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 459 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 460 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 461 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 462 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0",
+ "tciv0", "tgie0", "tgif0",
+ "tgia1", "tgib1", "tciv1", "tciu1",
+ "tgia2", "tgib2", "tciv2", "tciu2",
+ "tgia3", "tgib3", "tgic3", "tgid3",
+ "tciv3",
+ "tgia4", "tgib4", "tgic4", "tgid4",
+ "tciv4",
+ "tgiu5", "tgiv5", "tgiw5",
+ "tgia6", "tgib6", "tgic6", "tgid6",
+ "tciv6",
+ "tgia7", "tgib7", "tgic7", "tgid7",
+ "tciv7",
+ "tgia8", "tgib8", "tgic8", "tgid8",
+ "tciv8";
+ clocks = <&cpg CPG_MOD 200>;
+ power-domains = <&cpg>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
adc0: adc@90014000 {
compatible = "renesas,r9a09g087-adc", "renesas,r9a09g077-adc";
reg = <0 0x90014000 0 0x400>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 09/10] arm64: dts: renesas: r9a09g077: add MTU3 support
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
The Renesas RZ/T2H (R9A09G077) SoC has an MTU3 block.
Add support for it.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* no changes
arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 68 ++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
index 3761551c96472..fe5d206d4defb 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
@@ -1116,6 +1116,74 @@ gic: interrupt-controller@83000000 {
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
};
+ mtu3: timer@90001200 {
+ compatible = "renesas,r9a09g077-mtu3",
+ "renesas,rz-mtu3";
+ reg = <0 0x90001200 0 0xb00>;
+ interrupts = <GIC_SPI 420 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 421 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 422 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 423 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 424 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 425 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 426 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 427 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 428 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 429 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 430 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 432 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 434 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 435 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 437 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 438 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 439 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 440 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 441 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 442 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 443 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 444 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 445 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 446 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 447 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 450 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 451 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 452 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 453 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 454 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 455 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 456 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 457 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 458 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 459 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 460 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 461 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 462 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0",
+ "tciv0", "tgie0", "tgif0",
+ "tgia1", "tgib1", "tciv1", "tciu1",
+ "tgia2", "tgib2", "tciv2", "tciu2",
+ "tgia3", "tgib3", "tgic3", "tgid3",
+ "tciv3",
+ "tgia4", "tgib4", "tgic4", "tgid4",
+ "tciv4",
+ "tgiu5", "tgiv5", "tgiw5",
+ "tgia6", "tgib6", "tgic6", "tgid6",
+ "tciv6",
+ "tgia7", "tgib7", "tgic7", "tgid7",
+ "tciv7",
+ "tgia8", "tgib8", "tgic8", "tgid8",
+ "tciv8";
+ clocks = <&cpg CPG_MOD 200>;
+ power-domains = <&cpg>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
adc0: adc@90014000 {
compatible = "renesas,r9a09g077-adc";
reg = <0 0x90014000 0 0x400>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 08/10] arm64: dts: renesas: r9a07g0{43,44,54}: remove TCIU8 interrupt from MTU3
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
The TCIU8 interrupt used to be documented in earlier revisions of the
user manuals, but has since been removed. The corresponding entry is now
marked as reserved in the interrupt mapping tables of all supported
SoCs.
* Page 486, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2UL
Rev.1.40 User Manual
* Page 363, Table 8.2 Interrupt Mapping (6/13) in the Renesas RZ/Five
Rev.1.30 User Manual
* Page 528, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2L
and RZ/G2LC Rev.1.50 User Manual
* Page 540, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/V2L
Rev.1.50 User Manual
Remove the TCIU8 interrupt. This does not cause any breakage as the
driver does not make use of the interrupts.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* reword to mention that TCIU8 used to exist
arch/arm64/boot/dts/renesas/r9a07g043.dtsi | 5 ++---
arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 5 ++---
arch/arm64/boot/dts/renesas/r9a07g054.dtsi | 5 ++---
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r9a07g043.dtsi b/arch/arm64/boot/dts/renesas/r9a07g043.dtsi
index 593c66b27ad12..7bc37e1015a47 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g043.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g043.dtsi
@@ -120,8 +120,7 @@ mtu3: timer@10001200 {
<SOC_PERIPHERAL_IRQ(209) IRQ_TYPE_EDGE_RISING>,
<SOC_PERIPHERAL_IRQ(210) IRQ_TYPE_EDGE_RISING>,
<SOC_PERIPHERAL_IRQ(211) IRQ_TYPE_EDGE_RISING>,
- <SOC_PERIPHERAL_IRQ(212) IRQ_TYPE_EDGE_RISING>,
- <SOC_PERIPHERAL_IRQ(213) IRQ_TYPE_EDGE_RISING>;
+ <SOC_PERIPHERAL_IRQ(212) IRQ_TYPE_EDGE_RISING>;
interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0",
"tciv0", "tgie0", "tgif0",
"tgia1", "tgib1", "tciv1", "tciu1",
@@ -136,7 +135,7 @@ mtu3: timer@10001200 {
"tgia7", "tgib7", "tgic7", "tgid7",
"tciv7",
"tgia8", "tgib8", "tgic8", "tgid8",
- "tciv8", "tciu8";
+ "tciv8";
clocks = <&cpg CPG_MOD R9A07G043_MTU_X_MCK_MTU3>;
power-domains = <&cpg>;
resets = <&cpg R9A07G043_MTU_X_PRESET_MTU3>;
diff --git a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
index 29273da819951..799a974c4dba1 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi
@@ -220,8 +220,7 @@ mtu3: timer@10001200 {
<GIC_SPI 209 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 210 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 211 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 213 IRQ_TYPE_EDGE_RISING>;
+ <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0",
"tciv0", "tgie0", "tgif0",
"tgia1", "tgib1", "tciv1", "tciu1",
@@ -236,7 +235,7 @@ mtu3: timer@10001200 {
"tgia7", "tgib7", "tgic7", "tgid7",
"tciv7",
"tgia8", "tgib8", "tgic8", "tgid8",
- "tciv8", "tciu8";
+ "tciv8";
clocks = <&cpg CPG_MOD R9A07G044_MTU_X_MCK_MTU3>;
power-domains = <&cpg>;
resets = <&cpg R9A07G044_MTU_X_PRESET_MTU3>;
diff --git a/arch/arm64/boot/dts/renesas/r9a07g054.dtsi b/arch/arm64/boot/dts/renesas/r9a07g054.dtsi
index 0dee48c4f1e44..0dc4c3c8c06b2 100644
--- a/arch/arm64/boot/dts/renesas/r9a07g054.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a07g054.dtsi
@@ -220,8 +220,7 @@ mtu3: timer@10001200 {
<GIC_SPI 209 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 210 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 211 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 213 IRQ_TYPE_EDGE_RISING>;
+ <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0",
"tciv0", "tgie0", "tgif0",
"tgia1", "tgib1", "tciv1", "tciu1",
@@ -236,7 +235,7 @@ mtu3: timer@10001200 {
"tgia7", "tgib7", "tgic7", "tgid7",
"tciv7",
"tgia8", "tgib8", "tgic8", "tgid8",
- "tciv8", "tciu8";
+ "tciv8";
clocks = <&cpg CPG_MOD R9A07G054_MTU_X_MCK_MTU3>;
power-domains = <&cpg>;
resets = <&cpg R9A07G054_MTU_X_PRESET_MTU3>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 07/10] dt-bindings: timer: renesas,rz-mtu3: document RZ/{T2H,N2H}
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
Compared to the previously supported SoCs, the Renesas RZ/T2H and RZ/N2H
SoCs do not have a reset line.
Add support for them by moving the required reset into a conditional
matching all compatibles for the existing SoCs. Disable the resets for
RZ/T2H and RZ/N2H.
Document RZ/T2H and RZ/N2H, and use the generic compatible as a
fallback, as functionality is the same.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* squash "move required resets to conditional" into this
* disable the resets in the else branch of the condition
.../bindings/timer/renesas,rz-mtu3.yaml | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
index 00cd5cbcf6e9b..ecff2912d812b 100644
--- a/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
@@ -112,6 +112,8 @@ properties:
- renesas,r9a07g043-mtu3 # RZ/{G2UL,Five}
- renesas,r9a07g044-mtu3 # RZ/G2{L,LC}
- renesas,r9a07g054-mtu3 # RZ/V2L
+ - renesas,r9a09g077-mtu3 # RZ/T2H
+ - renesas,r9a09g087-mtu3 # RZ/N2H
- const: renesas,rz-mtu3
reg:
@@ -231,7 +233,22 @@ required:
- interrupt-names
- clocks
- power-domains
- - resets
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a07g043-mtu3
+ - renesas,r9a07g044-mtu3
+ - renesas,r9a07g054-mtu3
+ then:
+ required:
+ - resets
+ else:
+ properties:
+ resets: false
additionalProperties: false
--
2.53.0
^ permalink raw reply related
* [PATCH v2 06/10] dt-bindings: timer: renesas,rz-mtu3: remove TCIU8 interrupt
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
The TCIU8 interrupt used to be documented in earlier revisions of the
user manuals, but has since been removed. The corresponding entry is now
marked as reserved in the interrupt mapping tables of all supported
SoCs.
* Page 486, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2UL
Rev.1.40 User Manual
* Page 363, Table 8.2 Interrupt Mapping (6/13) in the Renesas RZ/Five
Rev.1.30 User Manual
* Page 528, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2L
and RZ/G2LC Rev.1.50 User Manual
* Page 540, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/V2L
Rev.1.50 User Manual
Remove the TCIU8 interrupt.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* reword to mention that TCIU8 used to exist
.../devicetree/bindings/timer/renesas,rz-mtu3.yaml | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
index 3ad10c5b66ba5..00cd5cbcf6e9b 100644
--- a/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
@@ -162,7 +162,6 @@ properties:
- description: MTU8.TGRC input capture/compare match
- description: MTU8.TGRD input capture/compare match
- description: MTU8.TCNT overflow
- - description: MTU8.TCNT underflow
interrupt-names:
items:
@@ -209,7 +208,6 @@ properties:
- const: tgic8
- const: tgid8
- const: tciv8
- - const: tciu8
clocks:
maxItems: 1
@@ -287,8 +285,7 @@ examples:
<GIC_SPI 209 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 210 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 211 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>,
- <GIC_SPI 213 IRQ_TYPE_EDGE_RISING>;
+ <GIC_SPI 212 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "tgia0", "tgib0", "tgic0", "tgid0", "tciv0", "tgie0",
"tgif0",
"tgia1", "tgib1", "tciv1", "tciu1",
@@ -298,7 +295,7 @@ examples:
"tgiu5", "tgiv5", "tgiw5",
"tgia6", "tgib6", "tgic6", "tgid6", "tciv6",
"tgia7", "tgib7", "tgic7", "tgid7", "tciv7",
- "tgia8", "tgib8", "tgic8", "tgid8", "tciv8", "tciu8";
+ "tgia8", "tgib8", "tgic8", "tgid8", "tciv8";
clocks = <&cpg CPG_MOD R9A07G044_MTU_X_MCK_MTU3>;
power-domains = <&cpg>;
resets = <&cpg R9A07G044_MTU_X_PRESET_MTU3>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 05/10] mfd: rz-mtu3: make reset optional
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs do not have a
reset line for the MTU3 block.
Prepare for them by making it optional.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* no changes
drivers/mfd/rz-mtu3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/rz-mtu3.c b/drivers/mfd/rz-mtu3.c
index 37d12030e069c..689dbb181d305 100644
--- a/drivers/mfd/rz-mtu3.c
+++ b/drivers/mfd/rz-mtu3.c
@@ -331,7 +331,7 @@ static int rz_mtu3_probe(struct platform_device *pdev)
if (IS_ERR(priv->mmio))
return PTR_ERR(priv->mmio);
- rstc = devm_reset_control_get_exclusive_deasserted(dev, NULL);
+ rstc = devm_reset_control_get_optional_exclusive_deasserted(dev, NULL);
if (IS_ERR(rstc))
return PTR_ERR(rstc);
--
2.53.0
^ permalink raw reply related
* [PATCH v2 04/10] mfd: rz-mtu3: store &pdev->dev in local variable
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
&pdev->dev is accessed multiple times during probe. Store it in a local
variable and use that to simplify the code.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* no changes
drivers/mfd/rz-mtu3.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/rz-mtu3.c b/drivers/mfd/rz-mtu3.c
index 3be6f6c900b82..37d12030e069c 100644
--- a/drivers/mfd/rz-mtu3.c
+++ b/drivers/mfd/rz-mtu3.c
@@ -311,16 +311,17 @@ static const struct mfd_cell rz_mtu3_devs[] = {
static int rz_mtu3_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct reset_control *rstc;
struct rz_mtu3_priv *priv;
struct rz_mtu3 *ddata;
unsigned int i;
- ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
+ ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
- ddata->priv_data = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ ddata->priv_data = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!ddata->priv_data)
return -ENOMEM;
@@ -330,11 +331,11 @@ static int rz_mtu3_probe(struct platform_device *pdev)
if (IS_ERR(priv->mmio))
return PTR_ERR(priv->mmio);
- rstc = devm_reset_control_get_exclusive_deasserted(&pdev->dev, NULL);
+ rstc = devm_reset_control_get_exclusive_deasserted(dev, NULL);
if (IS_ERR(rstc))
return PTR_ERR(rstc);
- ddata->clk = devm_clk_get(&pdev->dev, NULL);
+ ddata->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddata->clk))
return PTR_ERR(ddata->clk);
@@ -347,7 +348,7 @@ static int rz_mtu3_probe(struct platform_device *pdev)
mutex_init(&ddata->channels[i].lock);
}
- return devm_mfd_add_devices(&pdev->dev, 0, rz_mtu3_devs,
+ return devm_mfd_add_devices(dev, 0, rz_mtu3_devs,
ARRAY_SIZE(rz_mtu3_devs), NULL, 0, NULL);
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 03/10] mfd: rz-mtu3: use device-managed mfd_add_devices()
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
Replace mfd_add_devices() and the custom cleanup action with
devm_mfd_add_devices().
Remove the ret variable as it is now unused.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* no changes
drivers/mfd/rz-mtu3.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/rz-mtu3.c b/drivers/mfd/rz-mtu3.c
index 6b9c6831dffa9..3be6f6c900b82 100644
--- a/drivers/mfd/rz-mtu3.c
+++ b/drivers/mfd/rz-mtu3.c
@@ -300,11 +300,6 @@ void rz_mtu3_disable(struct rz_mtu3_channel *ch)
}
EXPORT_SYMBOL_GPL(rz_mtu3_disable);
-static void rz_mtu3_mfd_remove(void *data)
-{
- mfd_remove_devices(data);
-}
-
static const struct mfd_cell rz_mtu3_devs[] = {
{
.name = "rz-mtu3-counter",
@@ -320,7 +315,6 @@ static int rz_mtu3_probe(struct platform_device *pdev)
struct rz_mtu3_priv *priv;
struct rz_mtu3 *ddata;
unsigned int i;
- int ret;
ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
@@ -353,13 +347,8 @@ static int rz_mtu3_probe(struct platform_device *pdev)
mutex_init(&ddata->channels[i].lock);
}
- ret = mfd_add_devices(&pdev->dev, 0, rz_mtu3_devs,
- ARRAY_SIZE(rz_mtu3_devs), NULL, 0, NULL);
- if (ret < 0)
- return ret;
-
- return devm_add_action_or_reset(&pdev->dev, rz_mtu3_mfd_remove,
- &pdev->dev);
+ return devm_mfd_add_devices(&pdev->dev, 0, rz_mtu3_devs,
+ ARRAY_SIZE(rz_mtu3_devs), NULL, 0, NULL);
}
static const struct of_device_id rz_mtu3_of_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 01/10] clk: renesas: r9a09g077: add MTU3 module clock
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have a MTU3
block connected to the PCLKH and with a module clock controlled by
register 0x308, bit 0.
Add support for the module clock.
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* no changes
drivers/clk/renesas/r9a09g077-cpg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r9a09g077-cpg.c b/drivers/clk/renesas/r9a09g077-cpg.c
index 93b15e06a19bc..f777601a23b93 100644
--- a/drivers/clk/renesas/r9a09g077-cpg.c
+++ b/drivers/clk/renesas/r9a09g077-cpg.c
@@ -257,6 +257,7 @@ static const struct mssr_mod_clk r9a09g077_mod_clks[] __initconst = {
DEF_MOD("spi0", 104, CLK_SPI0ASYNC),
DEF_MOD("spi1", 105, CLK_SPI1ASYNC),
DEF_MOD("spi2", 106, CLK_SPI2ASYNC),
+ DEF_MOD("mtu3", 200, R9A09G077_CLK_PCLKH),
DEF_MOD("adc0", 206, R9A09G077_CLK_PCLKH),
DEF_MOD("adc1", 207, R9A09G077_CLK_PCLKH),
DEF_MOD("adc2", 225, R9A09G077_CLK_PCLKM),
--
2.53.0
^ permalink raw reply related
* [PATCH v2 02/10] mfd: rz-mtu3: use device-managed reset deassert
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
In-Reply-To: <20260410163530.383818-1-cosmin-gabriel.tanislav.xa@renesas.com>
Replace devm_reset_control_get_exclusive() and the manual
reset_control_deassert()/reset_control_assert() with handling by
devm_reset_control_get_exclusive_deasserted().
While at it, remove struct rz_mtu3_priv::rstc and use a local variable
for it as it is not needed inside rz_mtu3_reset_assert().
Rename rz_mtu3_reset_assert() to rz_mtu3_mfd_remove() to accurately
describe its usage since it no longer calls reset_control_assert().
Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
---
V2:
* no changes
drivers/mfd/rz-mtu3.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/mfd/rz-mtu3.c b/drivers/mfd/rz-mtu3.c
index 9cdfef610398f..6b9c6831dffa9 100644
--- a/drivers/mfd/rz-mtu3.c
+++ b/drivers/mfd/rz-mtu3.c
@@ -21,7 +21,6 @@
struct rz_mtu3_priv {
void __iomem *mmio;
- struct reset_control *rstc;
spinlock_t lock;
};
@@ -301,13 +300,9 @@ void rz_mtu3_disable(struct rz_mtu3_channel *ch)
}
EXPORT_SYMBOL_GPL(rz_mtu3_disable);
-static void rz_mtu3_reset_assert(void *data)
+static void rz_mtu3_mfd_remove(void *data)
{
- struct rz_mtu3 *mtu = dev_get_drvdata(data);
- struct rz_mtu3_priv *priv = mtu->priv_data;
-
mfd_remove_devices(data);
- reset_control_assert(priv->rstc);
}
static const struct mfd_cell rz_mtu3_devs[] = {
@@ -321,6 +316,7 @@ static const struct mfd_cell rz_mtu3_devs[] = {
static int rz_mtu3_probe(struct platform_device *pdev)
{
+ struct reset_control *rstc;
struct rz_mtu3_priv *priv;
struct rz_mtu3 *ddata;
unsigned int i;
@@ -340,15 +336,14 @@ static int rz_mtu3_probe(struct platform_device *pdev)
if (IS_ERR(priv->mmio))
return PTR_ERR(priv->mmio);
- priv->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
- if (IS_ERR(priv->rstc))
- return PTR_ERR(priv->rstc);
+ rstc = devm_reset_control_get_exclusive_deasserted(&pdev->dev, NULL);
+ if (IS_ERR(rstc))
+ return PTR_ERR(rstc);
ddata->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(ddata->clk))
return PTR_ERR(ddata->clk);
- reset_control_deassert(priv->rstc);
spin_lock_init(&priv->lock);
platform_set_drvdata(pdev, ddata);
@@ -361,14 +356,10 @@ static int rz_mtu3_probe(struct platform_device *pdev)
ret = mfd_add_devices(&pdev->dev, 0, rz_mtu3_devs,
ARRAY_SIZE(rz_mtu3_devs), NULL, 0, NULL);
if (ret < 0)
- goto err_assert;
+ return ret;
- return devm_add_action_or_reset(&pdev->dev, rz_mtu3_reset_assert,
+ return devm_add_action_or_reset(&pdev->dev, rz_mtu3_mfd_remove,
&pdev->dev);
-
-err_assert:
- reset_control_assert(priv->rstc);
- return ret;
}
static const struct of_device_id rz_mtu3_of_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 00/10] Add MTU3 for RZ/T2H and RZ/N2H
From: Cosmin Tanislav @ 2026-04-10 16:35 UTC (permalink / raw)
To: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel
Cc: linux-iio, linux-renesas-soc, linux-kernel, devicetree, linux-clk,
Cosmin Tanislav
The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs have an MTU3
block. Add support for them and fix the non-existing TCIU8 interrupt.
V2:
* reword to mention that TCIU8 used to exist
* squash "move required resets to conditional" into
"document RZ/{T2H,N2H}"
* disable the resets in the else branch of the condition
Cosmin Tanislav (10):
clk: renesas: r9a09g077: add MTU3 module clock
mfd: rz-mtu3: use device-managed reset deassert
mfd: rz-mtu3: use device-managed mfd_add_devices()
mfd: rz-mtu3: store &pdev->dev in local variable
mfd: rz-mtu3: make reset optional
dt-bindings: timer: renesas,rz-mtu3: remove TCIU8 interrupt
dt-bindings: timer: renesas,rz-mtu3: document RZ/{T2H,N2H}
arm64: dts: renesas: r9a07g0{43,44,54}: remove TCIU8 interrupt from
MTU3
arm64: dts: renesas: r9a09g077: add MTU3 support
arm64: dts: renesas: r9a09g087: add MTU3 support
.../bindings/timer/renesas,rz-mtu3.yaml | 26 +++++--
arch/arm64/boot/dts/renesas/r9a07g043.dtsi | 5 +-
arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 5 +-
arch/arm64/boot/dts/renesas/r9a07g054.dtsi | 5 +-
arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 68 +++++++++++++++++++
arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 68 +++++++++++++++++++
drivers/clk/renesas/r9a09g077-cpg.c | 1 +
drivers/mfd/rz-mtu3.c | 39 +++--------
8 files changed, 173 insertions(+), 44 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v4 3/4] PCI: tegra: Add Tegra264 support
From: Manivannan Sadhasivam @ 2026-04-10 16:34 UTC (permalink / raw)
To: Thierry Reding
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <adTAVYEzfD9FQl8N@orome>
On Tue, Apr 07, 2026 at 11:38:28AM +0200, Thierry Reding wrote:
> On Thu, Apr 02, 2026 at 11:02:02PM +0530, Manivannan Sadhasivam wrote:
> > On Thu, Apr 02, 2026 at 04:27:37PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding <treding@nvidia.com>
> > >
> > > Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
> > > driver is very small, with its main purpose being to set up the address
> > > translation registers and then creating a standard PCI host using ECAM.
> > >
> > > Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> >
> > What is the rationale for adding a new driver? Can't you reuse the existing one?
> > If so, that should be mentioned in the description.
>
> Which existing one? Tegra PCI controllers for previou generations
> (Tegra194 and Tegra234) were DesignWare IP, but Tegra264 is an internal
> IP, so the programming is entirely different. I'll add something to that
> effect to the commit message.
>
Yikes! I completely missed that this is a non-dwc driver. Sorry for the noise.
> > > diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> > > index 5aaed8ac6e44..6ead04f7bd6e 100644
> > > --- a/drivers/pci/controller/Kconfig
> > > +++ b/drivers/pci/controller/Kconfig
> > > @@ -254,7 +254,15 @@ config PCI_TEGRA
> > > select IRQ_MSI_LIB
> > > help
> > > Say Y here if you want support for the PCIe host controller found
> > > - on NVIDIA Tegra SoCs.
> > > + on NVIDIA Tegra SoCs (Tegra20 through Tegra186).
> > > +
> > > +config PCIE_TEGRA264
> > > + bool "NVIDIA Tegra264 PCIe controller"
> >
> > This driver seems to be using external MSI controller. So it can be built as a
> > module. Also, you have the remove() callback for some reason.
>
> Okay, I can turn this into a tristate symbol.
>
> > > + depends on ARCH_TEGRA || COMPILE_TEST
> > > + depends on PCI_MSI
> >
> > Why?
>
> I suppose it's not necessary in the sense of it being a build
> dependency. At runtime, however, the root complex is not useful if PCI
> MSI is not enabled. We can drop this dependency and rely on .config to
> have it enabled as needed.
>
Yes. I think the rationale is to depend on the symbols that the driver needs for
build dependency.
> > > diff --git a/drivers/pci/controller/pcie-tegra264.c b/drivers/pci/controller/pcie-tegra264.c
> > > new file mode 100644
> > > index 000000000000..3ce1ad971bdb
> > > --- /dev/null
> > > +++ b/drivers/pci/controller/pcie-tegra264.c
> [...]
> > > +struct tegra264_pcie {
> > > + struct device *dev;
> > > + bool link_up;
> >
> > Keep bool types at the end to avoid holes.
>
> Done.
>
> > > +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> > > +{
> > > + int err;
> > > +
> > > + pcie->wake_gpio = devm_gpiod_get_optional(pcie->dev, "nvidia,pex-wake",
> >
> > You should switch to standard 'wake-gpios' property.
>
> Will do.
>
> > > + GPIOD_IN);
> > > + if (IS_ERR(pcie->wake_gpio))
> > > + return PTR_ERR(pcie->wake_gpio);
> > > +
> > > + if (pcie->wake_gpio) {
> >
> > Since you are bailing out above, you don't need this check.
>
> I think we still want to have this check to handle the case of optional
> wake GPIOs. Not all controllers may have this wired up and
> devm_gpiod_get_optional() will return NULL (not an ERR_PTR()-encoded
> error) if the wake-gpios property is missing.
>
Ok. In that case you can just bail out:
if (!pcie->wake_gpio)
return 0;
> > > +static void tegra264_pcie_bpmp_set_rp_state(struct tegra264_pcie *pcie)
> >
> > I don't think this function name is self explanatory. Looks like it is turning
> > off the PCIe controller, so how about tegra264_pcie_power_off()?
>
> Agreed. The name is a relic from when this was potentially being used to
> toggle on and off the controller. But it's only used for disabling, so
> tegra264_pcie__power_off() sounds much better.
>
> > > +{
> > > + struct tegra_bpmp_message msg = {};
> > > + struct mrq_pcie_request req = {};
> > > + int err;
> > > +
> > > + req.cmd = CMD_PCIE_RP_CONTROLLER_OFF;
> > > + req.rp_ctrlr_off.rp_controller = pcie->ctl_id;
> > > +
> > > + msg.mrq = MRQ_PCIE;
> > > + msg.tx.data = &req;
> > > + msg.tx.size = sizeof(req);
> > > +
> > > + err = tegra_bpmp_transfer(pcie->bpmp, &msg);
> > > + if (err)
> > > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %pe\n",
> >
> > Why not dev_err()?
> >
> > > + pcie->ctl_id, ERR_PTR(err));
> > > +
> > > + if (msg.rx.ret)
> > > + dev_info(pcie->dev, "failed to turn off PCIe #%u: %d\n",
> >
> > Same here.
>
> These are not fatal errors and are safe to ignore. dev_err() seemed too
> strong for this. They also really shouldn't happen. Though I now realize
> that's a bad argument, or rather, actually an argument for making them
> dev_err() so that they do stand out if they really should happen.
>
> >
> > > + pcie->ctl_id, msg.rx.ret);
> > > +}
> > > +
> > > +static void tegra264_pcie_icc_set(struct tegra264_pcie *pcie)
> > > +{
> > > + u32 value, speed, width, bw;
> > > + int err;
> > > +
> > > + value = readw(pcie->ecam + XTL_RC_PCIE_CFG_LINK_STATUS);
> > > + speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, value);
> > > + width = FIELD_GET(PCI_EXP_LNKSTA_NLW, value);
> > > +
> > > + bw = width * (PCIE_SPEED2MBS_ENC(speed) / BITS_PER_BYTE);
> > > + value = MBps_to_icc(bw);
> >
> > So this becomes, 'width * (PCIE_SPEED2MBS_ENC(speed) / 8) * 1000 / 8'. But don't
> > you want, 'width * (PCIE_SPEED2MBS_ENC(speed)) * 1000 / 8'?
>
> This is M*B*ps_to_icc(), not M*b*ps_to_icc(), so we do in fact get the
> latter. I almost fell for this as well because I got confused by some of
> these macros being all-caps and other times the case actually mattering.
>
Oops, I was misleaded too. But you can simply do:
bw = Mbps_to_icc(width * PCIE_SPEED2MBS_ENC(speed));
> > > + err = icc_set_bw(pcie->icc_path, bw, bw);
And here you were setting the MBps, not Kbps.
> > > + if (err < 0)
> > > + dev_err(pcie->dev,
> > > + "failed to request bandwidth (%u MBps): %pe\n",
> > > + bw, ERR_PTR(err));
> >
> > So you don't want to error out if this fails?
>
> No. This is not a fatal error and the system will continue to work,
> albeit perhaps at suboptimal performance. Given that Ethernet and mass
> storage are connected to these, a failure to set the bandwidth and
> erroring out here may leave the system unusable, but continuing on would
> let the system boot and update firmware, kernel or whatever to recover.
>
> I'll add a comment explaining this.
>
Yeah, that'll help.
> [...]
> > > +static void tegra264_pcie_init(struct tegra264_pcie *pcie)
> > > +{
> > > + enum pci_bus_speed speed;
> > > + unsigned int i;
> > > + u32 value;
> > > +
> > > + /* bring the link out of reset */
> >
> > s/link/controller or endpoint?
>
> This controls the PERST# signal, so I guess "endpoint" would be more
> correct.
>
Yes!
> > > + value = readl(pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > > + value |= XTL_RC_MGMT_PERST_CONTROL_PERST_O_N;
> > > + writel(value, pcie->xtl + XTL_RC_MGMT_PERST_CONTROL);
> > > +
> > > + if (!tegra_is_silicon()) {
> >
> > This looks like some pre-silicon validation thing. Do you really want it to be
> > present in the upstream driver?
>
> At this point there is silicon for this chip, but we've been trying to
> get some of the pre-silicon code merged upstream as well because
> occasionally people will want to run upstream on simulation, even after
> silicon is available. At other times we may want to reuse these drivers
> on future chips during pre-silicon validation.
>
> Obviously there needs to be a balance. We don't want to have excessive
> amounts of code specifically for pre-silicon validation, but in
> relatively simple cases like this it is useful.
>
Ok, fine with me.
> >
> > > + dev_info(pcie->dev,
> > > + "skipping link state for PCIe #%u in simulation\n",
> > > + pcie->ctl_id);
> > > + pcie->link_up = true;
> > > + return;
> > > + }
> > > +
> > > + for (i = 0; i < PCIE_LINK_WAIT_MAX_RETRIES; i++) {
> > > + if (tegra264_pcie_link_up(pcie, NULL))
> > > + break;
> > > +
> > > + usleep_range(PCIE_LINK_WAIT_US_MIN, PCIE_LINK_WAIT_US_MAX);
> > > + }
> > > +
[...]
> > > + pm_runtime_get_sync(dev);
> > > +
> > > + /* sanity check that programmed ranges match what's in DT */
> > > + if (!tegra264_pcie_check_ranges(pdev)) {
> > > + err = -EINVAL;
> > > + goto put_pm;
> > > + }
> > > +
> > > + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> > > + if (IS_ERR(pcie->cfg)) {
> > > + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> > > + "failed to create ECAM\n");
> > > + goto put_pm;
> > > + }
> > > +
> > > + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > > + bridge->sysdata = pcie->cfg;
> > > + pcie->ecam = pcie->cfg->win;
> > > +
> > > + tegra264_pcie_init(pcie);
> > > +
> > > + if (!pcie->link_up)
> > > + goto free;
> >
> > goto free_ecam;
>
> It's not clear to me, but are you suggesting to rename the existing
> "free" label to "free_ecam"? I can do that.
>
Yeah, I was just asking for a rename.
> > > + err = pci_host_probe(bridge);
> > > + if (err < 0) {
> > > + dev_err(dev, "failed to register host: %pe\n", ERR_PTR(err));
> >
> > dev_err_probe()
>
> Okay.
>
> >
> > > + goto free;
> > > + }
> > > +
> > > + return err;
> >
> > return 0;
>
> Done.
>
> [...]
> > > +static int tegra264_pcie_resume_noirq(struct device *dev)
> > > +{
> > > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > > + int err;
> > > +
> > > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > > + err = disable_irq_wake(pcie->wake_irq);
> > > + if (err < 0)
> > > + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > > + ERR_PTR(err));
> > > + }
> > > +
> > > + if (pcie->link_up == false)
> > > + return 0;
> > > +
> > > + tegra264_pcie_init(pcie);
> > > +
> >
> > Why do you need init() here without deinit() in tegra264_pcie_suspend_noirq()?
>
> That's because when we come out of suspend the link may have gone down
> again, so we need to take the endpoint out of reset to retrigger the
> link training. I think we could possibly explicitly clear that PERST_O_N
> bit in the PERST_CONTROL register in a new tegra264_pcie_deinit() to
> mirror what tegra264_pcie_init() does, but it's automatically done by
> firmware anyway, so not needed.
>
Hmm, so firmware asserts PERST# at the end of suspend? It is not clear to me why
it is doing so. But for symmetry I'd like to do it in tegra264_pcie_deinit().
Also, I'm not certain about the 'pcie->link_up' check here. If it is 'false',
then probe() should've failed. So why do you need the check here anyway?
Maybe you should get rid of this check and return the link status from
tegra264_pcie_init() directly?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon: (pmbus/q54sj108a2) Add support for q50sn12072 and q54sn120a1
From: Guenter Roeck @ 2026-04-10 16:30 UTC (permalink / raw)
To: Brian Chiang, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: devicetree, linux-kernel, linux-hwmon, Jack Cheng
In-Reply-To: <20260402-add-support-for-q50sn12072-and-q54sn120a1-v3-2-67a5184e93b8@inventec.com>
On 4/1/26 18:29, Brian Chiang wrote:
> From: Jack Cheng <cheng.jackhy@inventec.com>
>
> The Q50SN12072 and Q54SN120A1 are high-efficiency, high-density DC-DC power
> module from Delta Power Modules.
>
> The Q50SN12072, quarter brick, single output 12V. This product provides up
> to 1200 watts of output power at 38~60V. The Q50SN12072 offers peak
> efficiency up to 98.3%@54Vin.
>
> The Q54SN120A1, quarter brick, single output 12V. This product provides up
> to 1300 watts of output power at 40~60V. The Q54SN120A1 offers peak
> efficiency up to 98.1%@54Vin.
>
> Add support for them to q54sj108a2 driver.
>
> Signed-off-by: Jack Cheng <cheng.jackhy@inventec.com>
> Co-developed-by: Brian Chiang <chiang.brian@inventec.com>
> Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
> ---
...
> - /*
> - * The chips support reading PMBUS_MFR_MODEL.
> - */
> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, buf);
> if (ret < 0) {
> dev_err(dev, "Failed to read Manufacturer Model\n");
> return ret;
> }
> - if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10)) {
> + for (mid = q54sj108a2_id; mid->name[0]; mid++) {
> + if (!strncasecmp(mid->name, buf, strlen(mid->name)))
> + break;
> + }
If ret < strlen(mid->name), this check compares uninitialized data.
Also see Sashiko feedback:
https://sashiko.dev/#/patchset/20260402-add-support-for-q50sn12072-and-q54sn120a1-v3-0-67a5184e93b8%40inventec.com
Thanks,
Guenter
^ permalink raw reply
* Re: (subset) [PATCH v6 00/11] Add support for the TI BQ25792 battery charger
From: Mark Brown @ 2026-04-10 10:52 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Morgan, Liam Girdwood, Sebastian Reichel, Alexey Charkov
Cc: devicetree, linux-kernel, Sebastian Reichel, linux-pm,
Krzysztof Kozlowski, stable
In-Reply-To: <20260331-bq25792-v6-0-0278fba33eb9@flipper.net>
On Tue, 31 Mar 2026 19:43:37 +0400, Alexey Charkov wrote:
> Add support for the TI BQ25792 battery charger
>
> This adds support for the TI BQ25792 battery charger, which is similar in
> overall logic to the BQ25703A, but has a different register layout and
> slightly different lower-level programming logic.
>
> The series is organized as follows:
> - Patch 1 adds the new variant to the existing DT binding, including the
> changes in electrical characteristics
> - Patches 2-4 are minor cleanups to the existing BQ25703A OTG regulator
> driver, slimming down the code and making it more reusable for the new
> BQ25792 variant
> - Patch 5 is a logical fix to the BQ25703A clamping logic for VSYSMIN
> (this is a standalone fix which can be applied independently and may be
> backported to stable)
> - Patches 6-8 are slight refactoring of the existing BQ25703A charger
> driver to make it more reusable for the new BQ25792 variant
> - Patch 9 adds platform data to distinguish between the two variants in
> the parent MFD driver, and binds it to the new compatible string
> - Patches 10-11 add variant-specific code to support the new BQ25792
> variant in the regulator part and the charger part respectively,
> selected by the platform data added in patch 9
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-7.1
Thanks!
[02/11] regulator: bq257xx: Remove reference to the parent MFD's dev
https://git.kernel.org/broonie/regulator/c/aef4d87f2c1f
[04/11] regulator: bq257xx: Make OTG enable GPIO really optional
https://git.kernel.org/broonie/regulator/c/de76a763805d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v12 2/2] hwmon: add support for MCP998X
From: Guenter Roeck @ 2026-04-10 16:22 UTC (permalink / raw)
To: Victor Duicu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
linux-hwmon, devicetree, linux-kernel, linux-doc, marius.cristea
In-Reply-To: <20260403-add-mcp9982-hwmon-v12-2-b3bfb26ff136@microchip.com>
On Fri, Apr 03, 2026 at 04:32:17PM +0300, Victor Duicu wrote:
> Add driver for Microchip MCP998X/33 and MCP998XD/33D
> Multichannel Automotive Temperature Monitor Family.
>
> Signed-off-by: Victor Duicu <victor.duicu@microchip.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v8 2/3] spi: spacemit: introduce SpacemiT K1 SPI controller driver
From: Mark Brown @ 2026-04-10 16:11 UTC (permalink / raw)
To: Guodong Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Alex Elder, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, linux-spi, devicetree, linux-riscv,
spacemit, linux-kernel, Alex Elder
In-Reply-To: <20260410-spi-spacemit-k1-v8-2-53ebb48a4146@riscstar.com>
[-- Attachment #1: Type: text/plain, Size: 2679 bytes --]
On Fri, Apr 10, 2026 at 11:04:21PM -0400, Guodong Xu wrote:
>
> This patch introduces the driver for the SPI controller found in the
> SpacemiT K1 SoC. Currently the driver supports master mode only.
> The SPI hardware implements RX and TX FIFOs, 32 entries each, and
> supports both PIO and DMA mode transfers.
> +static struct dma_async_tx_descriptor *
> +k1_spi_dma_prep(struct k1_spi_driver_data *drv_data,
> + struct spi_transfer *transfer, bool tx)
> +{
> + phys_addr_t addr = drv_data->base_addr + SSP_DATAR;
> + u32 burst_size = K1_SPI_THRESH * drv_data->bytes;
> + struct dma_slave_config cfg = { };
> + enum dma_transfer_direction dir;
> + enum dma_slave_buswidth width;
> + struct dma_chan *chan;
> + struct sg_table *sgt;
> +
> + width = drv_data->bytes == 1 ? DMA_SLAVE_BUSWIDTH_1_BYTE :
> + drv_data->bytes == 2 ? DMA_SLAVE_BUSWIDTH_2_BYTES :
> + /* bytes == 4 */ DMA_SLAVE_BUSWIDTH_4_BYTES;
Please use normal conditional statements (in this case a case statement)
to keep the code legible.
> +static irqreturn_t k1_spi_ssp_isr(int irq, void *dev_id)
> +{
> + struct k1_spi_driver_data *drv_data = dev_id;
> + u32 val;
> + /* Return immediately if we're not expecting any interrupts */
> + if (!drv_data->transfer)
> + return IRQ_NONE;
That does't mean the hardware agrees!
> + /* Get status and clear pending interrupts; all are handled below */
> + val = readl(drv_data->base + SSP_STATUS);
> + writel(val, drv_data->base + SSP_STATUS);
Nothing after here can report IRQ_NONE, even if SSP_STATUS didn't flag
anything. I'd just move the checks for transfer to when we're handling
FIFOs and have the IRQ_NONE report be based on there being something set
in the ISR.
> + /*
> + * For SPI, bytes are transferred in both directions equally, and
> + * RX always follows TX. Start by writing if there is anything to
> + * write, then read. Once there's no more to read, we're done.
> + */
> + if (drv_data->tx_resid && (val & SSP_STATUS_TNF)) {
> + /* If we finish writing, disable TX interrupts */
> + if (k1_spi_write(drv_data, val)) {
> + val = SSP_INT_EN_RX | SSP_INT_EN_ERROR;
> + writel(val, drv_data->base + SSP_INT_EN);
> + }
> + }
This overwrites val...
> +
> + /* We're not done unless we've read all that was requested */
> + if (drv_data->rx_resid) {
> + /* Read more if there FIFO is not empty */
> + if (val & SSP_STATUS_RNE)
> + if (k1_spi_read(drv_data, val))
> + goto done;
...so the read won't see that there's data to read and we'll need
another interrupt. I would suggest using a more meaingful name for the
actual interrupt status.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 1/3] hwmon: emc2305: Validate fan channel index
From: Guenter Roeck @ 2026-04-10 16:05 UTC (permalink / raw)
To: florin.leotescu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Michael Shych, linux-hwmon, devicetree, linux-kernel
Cc: daniel.baluta, viorel.suman, linux-arm-kernel, imx, festevam,
Florin Leotescu
In-Reply-To: <20260402122514.1811737-2-florin.leotescu@oss.nxp.com>
On 4/2/26 05:25, florin.leotescu@oss.nxp.com wrote:
> From: Florin Leotescu <florin.leotescu@nxp.com>
>
> The fan channel index is used to access per-channel data structures.
> Validate the index agains the number of available channels
> before use to prevent out-of-bounds access if an invalid
> value is provided.
>
> Signed-off-by: Florin Leotescu <florin.leotescu@nxp.com>
> ---
> drivers/hwmon/emc2305.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/hwmon/emc2305.c b/drivers/hwmon/emc2305.c
> index 64b213e1451e..0b42b82c8e22 100644
> --- a/drivers/hwmon/emc2305.c
> +++ b/drivers/hwmon/emc2305.c
> @@ -548,6 +548,12 @@ static int emc2305_of_parse_pwm_child(struct device *dev,
> return ret;
> }
>
> + if (ch >= data->pwm_num) {
> + dev_err(dev, "invalid reg %u for node %pOF (valid range 0-%u)\n", ch, child,
> + data->pwm_num - 1);
> + return -EINVAL;
> + }
> +
> ret = of_parse_phandle_with_args(child, "pwms", "#pwm-cells", 0, &args);
>
> if (ret)
Please address Sashiko's concerns regarding channel index validation.
It seems valid to me. Feel free to ignore the other comments.
https://sashiko.dev/#/patchset/20260402122514.1811737-1-florin.leotescu%40oss.nxp.com
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 7/7] clk: qcom: Add support for global clock controller on Hawi
From: Mike Tipton @ 2026-04-10 15:58 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
linux-arm-msm, linux-clk, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260409-clk-hawi-v2-7-c7a185389d9a@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 01:51:41PM -0700, Vivek Aknurwar wrote:
> Add support for the global clock controller (GCC) on the
> Qualcomm Hawi SoC.
>
> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 9 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gcc-hawi.c | 3657 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 3667 insertions(+)
Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v2 6/7] clk: qcom: clk-alpha-pll: Add support for Taycan EHA_T PLL
From: Mike Tipton @ 2026-04-10 15:57 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
linux-arm-msm, linux-clk, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260409-clk-hawi-v2-6-c7a185389d9a@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 01:51:40PM -0700, Vivek Aknurwar wrote:
> Add clock operations and register offsets to enable control of the Taycan
> EHA_T PLL, allowing for proper configuration and management of the PLL.
>
> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> drivers/clk/qcom/clk-alpha-pll.h | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH v2 5/7] clk: qcom: Add Hawi TCSR clock controller driver
From: Mike Tipton @ 2026-04-10 15:57 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Taniya Das,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <20260409-clk-hawi-v2-5-c7a185389d9a@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 01:51:39PM -0700, Vivek Aknurwar wrote:
> Add support for the TCSR clock controller found on the Qualcomm Hawi SoC.
> This controller provides reference clocks for various peripherals
> including PCIe, UFS, and USB.
>
> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
> Signed-off-by: Vivek Aknurwar <vivek.aknurwar@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 7 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/tcsrcc-hawi.c | 158 +++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 166 insertions(+)
Reviewed-by: Mike Tipton <mike.tipton@oss.qualcomm.com>
Thanks,
Mike
^ 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