* [PATCH v2 08/12] ARM: dts: microchip: sama7d65_curiosity: Enable ADC, DVFS
From: Varshini Rajendran @ 2026-06-23 10:59 UTC (permalink / raw)
To: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
Cc: varshini.rajendran
In-Reply-To: <20260623105944.128840-1-varshini.rajendran@microchip.com>
Add regulator, pinmux and enable ADC for sama7d65 curiosity. Add
cpu-supply regulator for DVFS.
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
---
.../dts/microchip/at91-sama7d65_curiosity.dts | 27 +++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/at91-sama7d65_curiosity.dts b/arch/arm/boot/dts/microchip/at91-sama7d65_curiosity.dts
index 927c27260b6c..a6a44a176f56 100644
--- a/arch/arm/boot/dts/microchip/at91-sama7d65_curiosity.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama7d65_curiosity.dts
@@ -97,6 +97,18 @@ &can3 {
status = "okay";
};
+&adc {
+ vddana-supply = <&vddout25>;
+ vref-supply = <&vddout25>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc_default &pinctrl_adtrg_default>;
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vddcpu>;
+};
+
&dma0 {
status = "okay";
};
@@ -334,6 +346,16 @@ &main_xtal {
};
&pioa {
+ pinctrl_adc_default: adc-default {
+ pinmux = <PIN_PC5__GPIO>;
+ bias-disable;
+ };
+
+ pinctrl_adtrg_default: adtrg-default {
+ pinmux = <PIN_PB7__ADTRG>;
+ bias-pull-up;
+ };
+
pinctrl_can1_default: can1-default {
pinmux = <PIN_PD10__CANTX1>,
<PIN_PD11__CANRX1>;
@@ -457,3 +479,8 @@ input@0 {
&slow_xtal {
clock-frequency = <32768>;
};
+
+&vddout25 {
+ vin-supply = <&vdd_3v3>;
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 09/12] ARM: dts: microchip: sama7d65: add otpc node
From: Varshini Rajendran @ 2026-06-23 10:59 UTC (permalink / raw)
To: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
Cc: varshini.rajendran
In-Reply-To: <20260623105944.128840-1-varshini.rajendran@microchip.com>
Add OTPC node along with temperature calibration cell.
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
---
arch/arm/boot/dts/microchip/sama7d65.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
index ba775459a816..5867fda378b1 100644
--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
+++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
@@ -15,6 +15,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/mfd/at91-usart.h>
+#include <dt-bindings/nvmem/microchip,sama7g5-otpc.h>
/ {
model = "Microchip SAMA7D65 family SoC";
@@ -1112,6 +1113,21 @@ ddr3phy: ddr3phy@e3804000 {
reg = <0xe3804000 0x1000>;
};
+ otpc: efuse@e8c00000 {
+ compatible = "microchip,sama7d65-otpc", "microchip,sama7g5-otpc", "syscon";
+ reg = <0xe8c00000 0x100>;
+
+ nvmem-layout {
+ compatible = "fixed-layout";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ temperature_calib: calib@41435354 {
+ reg = <0x41435354 0x2c>; /* Temp calib data packet TAG */
+ };
+ };
+ };
+
gic: interrupt-controller@e8c11000 {
compatible = "arm,cortex-a7-gic";
reg = <0xe8c11000 0x1000>,
--
2.34.1
^ permalink raw reply related
* [PATCH v2 10/12] ARM: dts: microchip: sama7d65: add cells for temperature calibration
From: Varshini Rajendran @ 2026-06-23 10:59 UTC (permalink / raw)
To: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
Cc: varshini.rajendran
In-Reply-To: <20260623105944.128840-1-varshini.rajendran@microchip.com>
Add NVMEM cell to ADC for temperature calibration data.
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
---
arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
index 5867fda378b1..c336f863406d 100644
--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
+++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
@@ -323,6 +323,8 @@ adc: adc@e1000000 {
atmel,trigger-edge-type = <IRQ_TYPE_EDGE_RISING>;
atmel,startup-time-ms = <4>;
#io-channel-cells = <1>;
+ nvmem-cells = <&temperature_calib>;
+ nvmem-cell-names = "temperature_calib";
status = "disabled";
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 11/12] ARM: dts: microchip: sama7d65: add temperature sensor
From: Varshini Rajendran @ 2026-06-23 10:59 UTC (permalink / raw)
To: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
Cc: varshini.rajendran
In-Reply-To: <20260623105944.128840-1-varshini.rajendran@microchip.com>
Add temperature sensor node.
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
---
arch/arm/boot/dts/microchip/sama7d65.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
index c336f863406d..89904397d021 100644
--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
+++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
@@ -120,6 +120,13 @@ pmu {
interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
};
+ thermal_sensor: thermal-sensor {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = <&adc AT91_SAMA7G5_ADC_TEMP_CHANNEL>;
+ io-channel-names = "sensor-channel";
+ };
+
soc {
compatible = "simple-bus";
ranges;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 12/12] ARM: dts: microchip: sama7d65: add thermal zones node
From: Varshini Rajendran @ 2026-06-23 10:59 UTC (permalink / raw)
To: ehristev, jic23, dlechner, nuno.sa, andy, robh, krzk+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, srini,
linux-iio, devicetree, linux-arm-kernel, linux-kernel
Cc: varshini.rajendran
In-Reply-To: <20260623105944.128840-1-varshini.rajendran@microchip.com>
Add thermal zones node with its associated trips and cooling-maps.
It uses CPUFreq as cooling device for temperatures in the interval
[90, 100) degrees Celsius and describe the temperature of 100 degrees
Celsius as critical temperature. System will shut down when reaching
critical temperature.
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
---
arch/arm/boot/dts/microchip/sama7d65.dtsi | 42 +++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi
index 89904397d021..f2140010d337 100644
--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi
+++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi
@@ -16,6 +16,7 @@
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/mfd/at91-usart.h>
#include <dt-bindings/nvmem/microchip,sama7g5-otpc.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
model = "Microchip SAMA7D65 family SoC";
@@ -38,6 +39,7 @@ cpu0: cpu@0 {
i-cache-size = <0x8000>; // L1, 32 KB
next-level-cache = <&L2>;
operating-points-v2 = <&cpu_opp_table>;
+ #cooling-cells = <2>; /* min followed by max */
L2: l2-cache {
compatible = "cache";
@@ -127,6 +129,46 @@ thermal_sensor: thermal-sensor {
io-channel-names = "sensor-channel";
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <&thermal_sensor>;
+
+ trips {
+ cpu_normal: cpu-alert0 {
+ temperature = <90000>;
+ hysteresis = <0>;
+ type = "passive";
+ };
+
+ cpu_hot: cpu-alert1 {
+ temperature = <95000>;
+ hysteresis = <0>;
+ type = "passive";
+ };
+
+ cpu_critical: cpu-critical {
+ temperature = <100000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_normal>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map1 {
+ trip = <&cpu_hot>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
soc {
compatible = "simple-bus";
ranges;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Konrad Dybcio @ 2026-06-23 11:02 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-2-37e2ee8df9da@proton.me>
On 6/23/26 2:54 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> These nodes are not present on downstream device trees and only take
> memory away from the AP.
> No crashes occur without these nodes, so remove them.
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 15 ---------------
> 1 file changed, 15 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 56cb6e959e4e..e34e3c05bf74 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -752,11 +752,6 @@ oem_vm_mem: memory@bb000000 {
> no-map;
> };
>
> - mte_mem: memory@c0000000 {
> - reg = <0x0 0xc0000000 0x0 0x20000000>;
> - no-map;
> - };
This is mentioned in the memory map description, but is not part
of it.
I booted up a 8450 HDK and it doesn't even have MTE, so it's
probably valid
> -
> qheebsp_reserved_mem: memory@e0000000 {
> reg = <0x0 0xe0000000 0x0 0x600000>;
> no-map;
> @@ -806,16 +801,6 @@ qtee_mem: memory@e9b00000 {
> reg = <0x0 0xe9b00000 0x0 0x500000>;
> no-map;
> };
> -
> - trusted_apps_mem: memory@ea000000 {
> - reg = <0x0 0xea000000 0x0 0x3900000>;
> - no-map;
> - };
> -
> - trusted_apps_ext_mem: memory@ed900000 {
> - reg = <0x0 0xed900000 0x0 0x3b00000>;
> - no-map;
> - };
These exist in the memory map, but I'd guess they may be unused if
you don't load any trusted apps
Konrad
^ permalink raw reply
* Re: [PATCH v4 06/12] iio: dac: ad5686: consume optional reset signal
From: sashiko-bot @ 2026-06-23 11:03 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260623-ad5686-new-features-v4-6-28962a57db0f@analog.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing power-up/reset recovery delay after reset deassertion.
- [Medium] Ignored return values from reset control operations.
--
commit 6b4f1604bc9722fb4790d1198babf7ca8eb4d482
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: dac: ad5686: consume optional reset signal
This commit adds support for an optional reset control in the probe
function. It manually generates a reset pulse after the device is
powered up.
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
[ ... ]
> @@ -509,6 +516,11 @@ int ad5686_probe(struct device *dev,
> /* 4.5us power-up time: Datasheet Table 4: Timing Characteristics */
> fsleep(5);
>
> + /* 1us >> 30ns reset pulse activation time: Datasheet Table 4 */
> + reset_control_assert(rstc);
> + fsleep(1);
> + reset_control_deassert(rstc);
[Severity: Medium]
Should we check the return values of reset_control_assert() and
reset_control_deassert() here?
If the reset controller is backed by a fallible bus (such as an I2C or
SPI GPIO expander), these calls can fail. If deassertion fails and the
return value is ignored, the driver might proceed while the hardware
is still stuck in reset, causing subsequent bus communications to silently
fail.
[Severity: Medium]
Does the hardware require a stabilization delay after the reset line is
deasserted before we start communicating with it?
Similar to the 4.5us power-up time handled above, if the device needs
recovery time after a hardware reset, proceeding immediately to the
initialization and first register writes might result in corrupted or
dropped commands.
> +
> /* Initialize masks to all ones */
> st->pwr_down_mask = ~0;
> st->pwr_down_mode = ~0;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-ad5686-new-features-v4-0-28962a57db0f@analog.com?part=6
^ permalink raw reply
* Re: [PATCH 2/8] arm64: dts: qcom: sm8450: Remove unneeded reserved memory nodes
From: Konrad Dybcio @ 2026-06-23 11:03 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <e1e492ab-884e-442b-8410-cc100c54fd5f@oss.qualcomm.com>
On 6/23/26 1:02 PM, Konrad Dybcio wrote:
> On 6/23/26 2:54 AM, Esteban Urrutia via B4 Relay wrote:
>> From: Esteban Urrutia <esteuwu@proton.me>
>>
>> These nodes are not present on downstream device trees and only take
>> memory away from the AP.
>> No crashes occur without these nodes, so remove them.
>>
>> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
>> ---
>> arch/arm64/boot/dts/qcom/sm8450.dtsi | 15 ---------------
>> 1 file changed, 15 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>> index 56cb6e959e4e..e34e3c05bf74 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>> @@ -752,11 +752,6 @@ oem_vm_mem: memory@bb000000 {
>> no-map;
>> };
>>
>> - mte_mem: memory@c0000000 {
>> - reg = <0x0 0xc0000000 0x0 0x20000000>;
>> - no-map;
>> - };
>
> This is mentioned in the memory map description, but is not part
> of it.
>
> I booted up a 8450 HDK and it doesn't even have MTE, so it's
> probably valid
i.e. it doesn't report MTE to Linux. I don't know if it's Gunyah
trapping it.
Konrad
^ permalink raw reply
* Re: [PATCH v4 04/12] dt-bindings: iio: dac: ad5686: rework on power supplies
From: sashiko-bot @ 2026-06-23 11:05 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260623-ad5686-new-features-v4-4-28962a57db0f@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The dt-binding makes `vdd-supply`, `vlogic-supply`, and conditionally `vref-supply` strictly required, which breaks schema validation for existing device trees.
--
commit 91cd8407525317fa145de80deea6f4d2c2d3a4d3
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
dt-bindings: iio: dac: ad5686: rework on power supplies
This commit updates the AD5686 binding to add vdd, vlogic, and vref power
supplies. It also deprecates the misleading vcc-supply property in favor of
vref-supply.
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
> index d781baca6a6c2..02e8c78e36d3d 100644
> --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml
[ ... ]
> @@ -60,9 +74,23 @@ properties:
> required:
> - compatible
> - reg
> + - vdd-supply
> + - vlogic-supply
[Severity: Medium]
Does adding vdd-supply and vlogic-supply to the unconditional required list
break dtbs_check for older device trees?
Since existing unmodified device trees lack these newly introduced supplies,
making them strictly required violates device tree backward compatibility.
While the driver handles missing supplies via dummy regulators, the schema
will flag older device trees as invalid.
>
> allOf:
> - $ref: /schemas/spi/spi-peripheral-props.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - adi,ad5676
> + - adi,ad5683
> + - adi,ad5684
> + - adi,ad5686
> + then:
> + required:
> + - vref-supply
[Severity: Medium]
Will this conditional block cause validation failures for legacy device trees
that define the previously valid vcc-supply instead of vref-supply?
The driver code continues to support the deprecated vcc-supply for backward
compatibility, but this schema update does not mirror that logic. Could this
use an anyOf block to allow either vref-supply or vcc-supply to satisfy the
reference voltage requirement for these chips?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-ad5686-new-features-v4-0-28962a57db0f@analog.com?part=4
^ permalink raw reply
* Re: [PATCH v4 01/12] dt-bindings: iio: dac: ad5696: add reset/ldac/gain support
From: sashiko-bot @ 2026-06-23 11:06 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260623-ad5686-new-features-v4-1-28962a57db0f@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `allOf` conditional block fails to restrict `gain-gpios` for all applicable devices that lack a GAIN pin.
--
commit 23c63e7ff1a35cdc5b325bc954025b5cf88c49f5
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
dt-bindings: iio: dac: ad5696: add reset/ldac/gain support
This commit adds optional GPIO properties for the RESET, LDAC, and GAIN
pins to the AD5696 device tree binding. It also includes an if-then block
to restrict the use of the gain-gpios property on devices that do not
support it.
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
[ ... ]
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - adi,ad5311r
> + - adi,ad5691r
> + - adi,ad5692r
> + - adi,ad5693
> + - adi,ad5693r
[Severity: Medium]
Should the 8-pin dual-channel DACs adi,ad5337r and adi,ad5338r be included
in this enum as well?
If these hardware variants also lack a GAIN pin, omitting them from this
restriction block would allow an invalid device tree configuration specifying
gain-gpios for an adi,ad5337r or adi,ad5338r device to silently pass
validation.
> + then:
> + properties:
> + gain-gpios: false
>
> additionalProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-ad5686-new-features-v4-0-28962a57db0f@analog.com?part=1
^ permalink raw reply
* Re: [PATCH 6/6] clk: qcom: gpucc: Add Nord graphics clock controller support
From: sashiko-bot @ 2026-06-23 11:06 UTC (permalink / raw)
To: Taniya Das; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260623-nords_mm_v1-v1-6-860c84539804@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Incorrect frequency table reused for gpu_2_cc_hub_clk_src.
- [High] Missing resets in gpu_cc_nord_resets leading to potential PLL corruption, and missing AHB divider in GPU2CC.
- [Medium] Mismatched clock halt_check flags between GPUCC and GPU2CC controllers.
--
commit b571fd2818fe3ed8089ed7cac4ad63964b0b6f76
Author: Taniya Das <taniya.das@oss.qualcomm.com>
clk: qcom: gpucc: Add Nord graphics clock controller support
Add support for the GPU clock controllers (GPUCC) on the Qualcomm
Nord platform. The platform includes two GPU clock controller instances,
GPUCC and GPU2CC, which provide clocks required for the graphics subsystem.
> diff --git a/drivers/clk/qcom/gpu2cc-nord.c b/drivers/clk/qcom/gpu2cc-nord.c
> new file mode 100644
> index 0000000000000..d1baf019704c4
> --- /dev/null
> +++ b/drivers/clk/qcom/gpu2cc-nord.c
[ ... ]
> +static struct clk_rcg2 gpu_2_cc_hub_clk_src = {
> + .cmd_rcgr = 0x91a8,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = gpu_2_cc_parent_map_2,
> + .freq_tbl = ftbl_gpu_2_cc_ff_clk_src,
[Severity: High]
Is it intentional to use ftbl_gpu_2_cc_ff_clk_src for the hub clock
frequency table?
Could this cause incorrect frequency configurations, such as using the
ff clock's frequency settings instead of a dedicated hub frequency table?
> + .hw_clk_ctrl = true,
> + .clkr.hw.init = &(const struct clk_init_data) {
[ ... ]
> +static struct clk_branch gpu_2_cc_ahb_clk = {
> + .halt_reg = 0x90cc,
> + .halt_check = BRANCH_HALT_VOTED,
[Severity: Medium]
Does this halt_check mismatch with the equivalent clock in gpucc?
This branch uses BRANCH_HALT_VOTED, but looking at gpu_cc_ahb_clk in
gpucc-nord.c, it uses BRANCH_HALT_DELAY.
Could an incorrect halt check cause the common clock framework to improperly
wait for clock status changes during enable/disable operations?
> + .clkr = {
> + .enable_reg = 0x90cc,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "gpu_2_cc_ahb_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &gpu_2_cc_hub_clk_src.clkr.hw,
[Severity: High]
Are we missing the hub divider block in the parent chain here?
The parent is set directly to gpu_2_cc_hub_clk_src, whereas the equivalent
gpu_cc_ahb_clk in gpucc-nord.c is parented to a gpu_cc_hub_div_clk_src
divider block.
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
[ ... ]
> diff --git a/drivers/clk/qcom/gpucc-nord.c b/drivers/clk/qcom/gpucc-nord.c
> new file mode 100644
> index 0000000000000..407cf7e5ad437
> --- /dev/null
> +++ b/drivers/clk/qcom/gpucc-nord.c
[ ... ]
> +static const struct qcom_reset_map gpu_cc_nord_resets[] = {
> + [GPU_CC_ACD_BCR] = { 0x92f8 },
> + [GPU_CC_CB_BCR] = { 0x9340 },
> + [GPU_CC_CX_BCR] = { 0x90e4 },
> + [GPU_CC_FAST_HUB_BCR] = { 0x9384 },
> + [GPU_CC_GFX3D_AON_BCR] = { 0x91ac },
> + [GPU_CC_GX_BCR] = { 0x9058 },
> + [GPU_CC_XO_BCR] = { 0x9000 },
> +};
[Severity: High]
Are we missing entries for GPU_CC_FF_BCR and GPU_CC_GMU_BCR in this list?
Since qcom_reset_map uses sparse static array initialization, any
uninitialized IDs below the maximum enum value will default to 0x0.
If a client attempts to assert these missing resets, could it inadvertently
write to offset 0x0 and corrupt the gpu_cc_pll0 state?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-nords_mm_v1-v1-0-860c84539804@oss.qualcomm.com?part=6
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 11:10 UTC (permalink / raw)
To: Daniele Briguglio, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <20260419-rk3588-mclk-gate-grf-v4-5-513a42dd1dcc@superkali.me>
[Resending it against v4 which wasn't present in my INBOX, but was the
version accepted and used in my kernel]
On Tue Jun 23, 2026 at 1:08 PM CEST, Daniele Briguglio wrote:
> The I2S MCLK outputs on RK3588 are gated by bits in the SYS_GRF
> register SOC_CON6 (offset 0x318). These gates control whether the
> internal CRU MCLK signals reach the external IO pins connected to
> audio codecs.
>
> The kernel should explicitly manage these gates so that audio
> functionality does not depend on bootloader register state. This is
> analogous to what was done for RK3576 SAI MCLK outputs [1].
>
> Register the SYS_GRF as an auxiliary GRF with grf_type_sys using
> rockchip_clk_add_grf(), and add GATE_GRF entries for all four I2S
> MCLK output gates:
>
> - I2S0_8CH_MCLKOUT_TO_IO (bit 0)
> - I2S1_8CH_MCLKOUT_TO_IO (bit 1)
> - I2S2_2CH_MCLKOUT_TO_IO (bit 2)
> - I2S3_2CH_MCLKOUT_TO_IO (bit 7)
>
> Board DTS files that need MCLK on an IO pin can reference these
> clocks, e.g.:
>
> clocks = <&cru I2S0_8CH_MCLKOUT_TO_IO>;
>
> Tested on the Youyeetoo YY3588 (RK3588) with an ES8388 codec on I2S0.
Doesn't this break audio on a lot of RK3588 based boards?
I have a kernel with this patch set and since then analog audio on my NanoPC-T6
LTS and my WIP NanoPC-T6 Plus stopped working.
Until I did s/I2S0_8CH_MCLKOUT/I2S0_8CH_MCLKOUT_TO_IO/ in my dts[i] files.
And I wouldn't be surprised if the same thing applies to other RK3588 based
boards? The same dtb file with a 7.1 kernel, without this patch set, works.
Cheers,
Diederik
> [1] https://lore.kernel.org/r/20250305-rk3576-sai-v1-2-64e6cf863e9a@collabora.com/
>
> Tested-by: Ricardo Pardini <ricardo@pardini.net>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
> drivers/clk/rockchip/clk-rk3588.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c
> index 1694223f4f84..2ba9976654cf 100644
> --- a/drivers/clk/rockchip/clk-rk3588.c
> +++ b/drivers/clk/rockchip/clk-rk3588.c
> @@ -5,11 +5,13 @@
> */
>
> #include <linux/clk-provider.h>
> +#include <linux/mfd/syscon.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/platform_device.h>
> #include <linux/syscore_ops.h>
> #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> +#include <soc/rockchip/rk3588_grf.h>
> #include "clk.h"
>
> #define RK3588_GRF_SOC_STATUS0 0x600
> @@ -892,6 +894,8 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> RK3588_CLKGATE_CON(8), 0, GFLAGS),
> MUX(I2S2_2CH_MCLKOUT, "i2s2_2ch_mclkout", i2s2_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(30), 2, 1, MFLAGS),
> + GATE_GRF(I2S2_2CH_MCLKOUT_TO_IO, "i2s2_2ch_mclkout_to_io", "i2s2_2ch_mclkout",
> + 0, RK3588_SYSGRF_SOC_CON6, 2, GFLAGS, grf_type_sys),
>
> COMPOSITE(CLK_I2S3_2CH_SRC, "clk_i2s3_2ch_src", gpll_aupll_p, 0,
> RK3588_CLKSEL_CON(30), 8, 1, MFLAGS, 3, 5, DFLAGS,
> @@ -907,6 +911,8 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> RK3588_CLKGATE_CON(8), 4, GFLAGS),
> MUX(I2S3_2CH_MCLKOUT, "i2s3_2ch_mclkout", i2s3_2ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(32), 2, 1, MFLAGS),
> + GATE_GRF(I2S3_2CH_MCLKOUT_TO_IO, "i2s3_2ch_mclkout_to_io", "i2s3_2ch_mclkout",
> + 0, RK3588_SYSGRF_SOC_CON6, 7, GFLAGS, grf_type_sys),
> GATE(PCLK_ACDCDIG, "pclk_acdcdig", "pclk_audio_root", 0,
> RK3588_CLKGATE_CON(7), 11, GFLAGS),
> GATE(HCLK_I2S0_8CH, "hclk_i2s0_8ch", "hclk_audio_root", 0,
> @@ -935,6 +941,8 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> RK3588_CLKGATE_CON(7), 10, GFLAGS),
> MUX(I2S0_8CH_MCLKOUT, "i2s0_8ch_mclkout", i2s0_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_CLKSEL_CON(28), 2, 2, MFLAGS),
> + GATE_GRF(I2S0_8CH_MCLKOUT_TO_IO, "i2s0_8ch_mclkout_to_io", "i2s0_8ch_mclkout",
> + 0, RK3588_SYSGRF_SOC_CON6, 0, GFLAGS, grf_type_sys),
>
> GATE(HCLK_PDM1, "hclk_pdm1", "hclk_audio_root", 0,
> RK3588_CLKGATE_CON(9), 6, GFLAGS),
> @@ -2220,6 +2228,8 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = {
> RK3588_PMU_CLKGATE_CON(2), 13, GFLAGS),
> MUX(I2S1_8CH_MCLKOUT, "i2s1_8ch_mclkout", i2s1_8ch_mclkout_p, CLK_SET_RATE_PARENT,
> RK3588_PMU_CLKSEL_CON(9), 2, 2, MFLAGS),
> + GATE_GRF(I2S1_8CH_MCLKOUT_TO_IO, "i2s1_8ch_mclkout_to_io", "i2s1_8ch_mclkout",
> + 0, RK3588_SYSGRF_SOC_CON6, 1, GFLAGS, grf_type_sys),
> GATE(PCLK_PMU1, "pclk_pmu1", "pclk_pmu0_root", CLK_IS_CRITICAL,
> RK3588_PMU_CLKGATE_CON(1), 0, GFLAGS),
> GATE(CLK_DDR_FAIL_SAFE, "clk_ddr_fail_safe", "clk_pmu0", CLK_IGNORE_UNUSED,
> @@ -2439,6 +2449,7 @@ static struct rockchip_clk_branch rk3588_clk_branches[] = {
> static void __init rk3588_clk_early_init(struct device_node *np)
> {
> struct rockchip_clk_provider *ctx;
> + struct regmap *sys_grf;
> unsigned long clk_nr_clks, max_clk_id1, max_clk_id2;
> void __iomem *reg_base;
>
> @@ -2479,6 +2490,11 @@ static void __init rk3588_clk_early_init(struct device_node *np)
> &rk3588_cpub1clk_data, rk3588_cpub1clk_rates,
> ARRAY_SIZE(rk3588_cpub1clk_rates));
>
> + /* Register SYS_GRF for I2S MCLK output to IO gate clocks */
> + sys_grf = syscon_regmap_lookup_by_compatible("rockchip,rk3588-sys-grf");
> + if (!IS_ERR(sys_grf))
> + rockchip_clk_add_grf(ctx, sys_grf, grf_type_sys);
> +
> rockchip_clk_register_branches(ctx, rk3588_early_clk_branches,
> ARRAY_SIZE(rk3588_early_clk_branches));
>
^ permalink raw reply
* Re: [PATCH v2 2/3] powercap: qcom: Add SPEL powercap driver
From: Konrad Dybcio @ 2026-06-23 11:11 UTC (permalink / raw)
To: Manaf Meethalavalappu Pallikunhi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio, Daniel Lezcano
Cc: Gaurav Kohli, linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <298cf2f5-64eb-4430-b264-0d046df14dbf@oss.qualcomm.com>
On 6/23/26 12:58 PM, Manaf Meethalavalappu Pallikunhi wrote:
> Hi Konrad,
>
>
> On 6/22/2026 4:31 PM, Konrad Dybcio wrote:
>> On 6/19/26 10:39 PM, Manaf Meethalavalappu Pallikunhi wrote:
>>> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
>>> based power monitoring and limiting capabilities for various power
>>> domains including System, SoC, CPU clusters, GPU, and various other
>>> subsystems.
>>>
>>> The driver integrates with the Linux powercap framework, exposing SPEL
>>> capabilities through powercap sysfs interfaces.
>>>
>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>>> ---
[...]
>>> +/* Domain configuration */
>>> +static const struct spel_domain_info domain_info[SPEL_DOMAIN_MAX] = {
>>> + [SPEL_DOMAIN_SYS] = { "sys", 0x40 },
>>> + [SPEL_DOMAIN_SOC] = { "soc", 0x00 },
>>> + [SPEL_DOMAIN_CL0] = { "cl0", 0x5c },
>>> + [SPEL_DOMAIN_CL1] = { "cl1", 0x60 },
>>> + [SPEL_DOMAIN_CL2] = { "cl2", 0x64 },
>>> + [SPEL_DOMAIN_IGPU] = { "igpu", 0x08 },
>>> + [SPEL_DOMAIN_DGPU] = { "dgpu", 0x44 },
>>> + [SPEL_DOMAIN_NSP] = { "nsp", 0x0c },
>>> + [SPEL_DOMAIN_MMCX] = { "mmcx", 0x10 },
>>> + [SPEL_DOMAIN_INFRA] = { "infra", 0x18 },
>>> + [SPEL_DOMAIN_DRAM] = { "dram", 0x1c },
>>> + [SPEL_DOMAIN_MDM] = { "mdm", 0x48 },
>>> + [SPEL_DOMAIN_WLAN] = { "wlan", 0x4c },
>>> + [SPEL_DOMAIN_USB1] = { "usb1", 0x50 },
>>> + [SPEL_DOMAIN_USB2] = { "usb2", 0x54 },
>>> + [SPEL_DOMAIN_USB3] = { "usb3", 0x58 },
>>> +};
>>
>> I would expect that the names are going to stay common, but the offsets
>
> Names also can be different here. For example, hawi, It has only subset of these domain and it doesn't have dgpu, it has only "gpu". cpu domain
> names also different there.
Presumably we can unify the names (i.e. use SPEL_DOMAIN_IGPU on both
hawi and glymur)
>
>> will be different. This array should probably be called
>> glymur_domain_info[]. We may have another LUT just for names of indices
>
> ACK for glymur_domain_info.
>> (i.e. [SPEL_DOMAIN_xxx] = "xxx")
This approach would still save us quite some bytes for the names that are
the same
i.e.
foobar_names_lut[] = {
[SPEL_DOMAIN_xxx] = "xxx",
[SPEL_DOMAIN_yyy] = "yyy",
[SPEL_DOMAIN_zzz] = "zzz"
};
glymur_domain_offsets[] = {
[SPEL_DOMAIN_xxx] = 0x20,
[SPEL_DOMAIN_yyy] = 0x24,
[SPEL_DOMAIN_zzz] = 0x28
};
Konrad
^ permalink raw reply
* Re: [PATCH v4 12/12] iio: dac: ad5686: add gain control support
From: sashiko-bot @ 2026-06-23 11:13 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260623-ad5686-new-features-v4-12-28962a57db0f@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Data race in `ad5686_read_avail()` due to lockless access of `st->double_scale`, which is temporarily mutated in `ad5686_write_raw()`.
--
commit 7b5b8c7fbbe74efe7dd9f093ff8593661667e614
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: dac: ad5686: add gain control support
Adds gain control support to the ad5686 driver, allowing a 2x multiplier
to be applied to the output voltage either via a dedicated GAIN pin or
a control register bit field. It exposes available scales to userspace
and adds tracking of the double scale state.
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index 4dc681eb077d6..bad214b89257f 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
[ ... ]
> @@ -217,6 +229,84 @@ static int ad5686_write_raw(struct iio_dev *indio_dev,
>
> return ad5686_write(st, AD5686_CMD_WRITE_INPUT_N_UPDATE_N,
> chan->address, val << chan->scan_type.shift);
> + case IIO_CHAN_INFO_SCALE:
> + if (val == st->scale_avail[0] && val2 == st->scale_avail[1])
> + double_scale = false;
> + else if (val == st->scale_avail[2] && val2 == st->scale_avail[3])
> + double_scale = true;
> + else
> + return -EINVAL;
> +
> + if (st->double_scale == double_scale)
> + return 0; /* no change */
> +
> + st->double_scale = double_scale;
> + switch (st->chip_info->regmap_type) {
> + case AD5310_REGMAP:
> + ret = ad5310_control_sync(st);
> + break;
> + case AD5683_REGMAP:
> + ret = ad5683_control_sync(st);
> + break;
> + case AD5686_REGMAP:
> + if (!st->gain_gpio) {
> + ret = -EINVAL;
> + break;
> + }
> +
> + ret = gpiod_set_value_cansleep(st->gain_gpio,
> + st->double_scale ? 1 : 0);
> + break;
> + default:
> + ret = -EINVAL;
> + }
> + if (ret)
> + st->double_scale = !double_scale; /* revert on failure */
> + return ret;
[ ... ]
> +static int ad5686_read_avail(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + const int **vals, int *type, int *length,
> + long mask)
> +{
> + struct ad5686_state *st = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + *type = IIO_VAL_INT_PLUS_NANO;
> +
> + if (st->chip_info->regmap_type == AD5686_REGMAP && !st->gain_gpio) {
> + /*
> + * GAIN pin is board-strapped, so only the current
> + * scale is available.
> + */
> + *vals = st->double_scale ? &st->scale_avail[2] :
> + &st->scale_avail[0];
[Severity: Medium]
Is there a potential data race on st->double_scale here?
In ad5686_write_raw(), st->double_scale is temporarily modified and then
reverted on failure under st->lock. However, ad5686_read_avail() accesses
st->double_scale without holding st->lock.
If a sysfs read on in_voltage_scale_available happens concurrently with a
failing sysfs write on in_voltage_scale for a board-strapped device, could
the read observe the temporary invalid state of st->double_scale before
it is reverted and returned to userspace?
> + *length = 2;
> + return IIO_AVAIL_LIST;
> + }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-ad5686-new-features-v4-0-28962a57db0f@analog.com?part=12
^ permalink raw reply
* Re: [PATCH v4 11/12] iio: dac: ad5686: add triggered buffer support
From: sashiko-bot @ 2026-06-23 11:14 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260623-ad5686-new-features-v4-11-28962a57db0f@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The ad5686_trigger_handler fails to convert Big Endian buffer data to native CPU endianness before passing it to the write operations, causing scrambled DAC values on Little Endian systems.
--
commit b9bb35e4f394ef5515930983f7b76ce0cae1335e
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: dac: ad5686: add triggered buffer support
This commit implements a trigger handler for the AD5686 DAC driver to update
all channels simultaneously when the LDAC GPIO is available. It also flushes
multiple channel writes at once using the sync() operation.
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index db175e77b0b7c..4dc681eb077d6 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
[ ... ]
> @@ -467,6 +472,60 @@ const struct ad5686_chip_info ad5679r_chip_info = {
> };
> EXPORT_SYMBOL_NS_GPL(ad5679r_chip_info, "IIO_AD5686");
>
> +static irqreturn_t ad5686_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct iio_buffer *buffer = indio_dev->buffer;
> + struct ad5686_state *st = iio_priv(indio_dev);
> + u16 val[AD5686_MAX_CHANNELS] = { };
> + unsigned int scan_count, ch, i;
> + bool async_update;
> + int ret;
> + u8 cmd;
> +
> + ret = iio_pop_from_buffer(buffer, val);
> + if (ret) {
> + iio_trigger_notify_done(indio_dev->trig);
> + return IRQ_HANDLED;
> + }
> +
> + guard(mutex)(&st->lock);
> +
> + scan_count = bitmap_weight(indio_dev->active_scan_mask,
> + iio_get_masklength(indio_dev));
> + async_update = st->ldac_gpio && scan_count > 1;
> + if (async_update) {
> + /* use LDAC to update all channels simultaneously */
> + cmd = AD5686_CMD_WRITE_INPUT_N;
> + gpiod_set_value_cansleep(st->ldac_gpio, 0);
> + } else {
> + cmd = AD5686_CMD_WRITE_INPUT_N_UPDATE_N;
> + }
> +
> + i = 0;
> + iio_for_each_active_channel(indio_dev, ch) {
> + ret = st->ops->write(st, cmd, indio_dev->channels[ch].address, val[i++]);
[Severity: High]
Will this send scrambled data on Little Endian CPUs?
Since the driver declares IIO_BE, the data populated by iio_pop_from_buffer()
into the val array is in Big Endian format. Passing val[i++] directly to
st->ops->write() as a native u16 without using be16_to_cpu() means the bytes
might be incorrectly byte-swapped before transmission.
> + if (ret)
> + break;
> + }
> +
> + /*
> + * If sync() is available, it is called here regardless of write
> + * failure to allow bus implementation to reset. In that case, partial
> + * writes are unlikely as the write operations would just queue up
> + * the transfers.
> + */
> + if (st->ops->sync)
> + st->ops->sync(st);
> +
> + if (async_update)
> + gpiod_set_value_cansleep(st->ldac_gpio, 1);
> +
> + iio_trigger_notify_done(indio_dev->trig);
> + return IRQ_HANDLED;
> +}
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623-ad5686-new-features-v4-0-28962a57db0f@analog.com?part=11
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: ti,clockdomain: Convert to DT schema
From: kernel test robot @ 2026-06-23 11:14 UTC (permalink / raw)
To: Bhargav Joshi, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tero Kristo
Cc: oe-kbuild-all, linux-clk, devicetree, linux-kernel, goledhruva,
m-chawdhry, daniel.baluta, simona.toaca, j.bhargav.u
In-Reply-To: <20260621-ti-clockdomain-v1-1-e99a56af98ea@gmail.com>
Hi Bhargav,
kernel test robot noticed the following build warnings:
[auto build test WARNING on acb7500801e98639f6d8c2d796ed9f64cba83d3a]
url: https://github.com/intel-lab-lkp/linux/commits/Bhargav-Joshi/dt-bindings-clock-ti-clockdomain-Convert-to-DT-schema/20260623-022037
base: acb7500801e98639f6d8c2d796ed9f64cba83d3a
patch link: https://lore.kernel.org/r/20260621-ti-clockdomain-v1-1-e99a56af98ea%40gmail.com
patch subject: [PATCH] dt-bindings: clock: ti,clockdomain: Convert to DT schema
compiler: clang version 22.1.8 (https://github.com/llvm/llvm-project ca7933e47d3a3451d81e72ac174dcb5aa28b59d1)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260623/202606231306.COGVL9ZT-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606231306.COGVL9ZT-lkp@intel.com/
All warnings (new ones prefixed by >>):
from /zdci/src/kernel-tests/common.sh:210: redirect_command_errors
from /zdci/src/kernel-tests/lib/builder/htmldocs.sh:86: builder_execute_build
from /zdci/src/kernel-tests/lib/kbuild.sh:6419: compile_one_config
from /zdci/src/kernel-tests/lib/builder/base.sh:88: builder_compile
from /zdci/src/kernel-tests/bisect-test-build-error.sh:102: main
>> Warning: Documentation/devicetree/bindings/clock/ti/ti,gate-clock.yaml references a file that doesn't exist: Documentation/devicetree/bindings/clock/ti/clockdomain.txt
Warning: Documentation/devicetree/bindings/mfd/motorola-cpcap.txt references a file that doesn't exist: Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
Warning: Documentation/devicetree/bindings/mfd/motorola-cpcap.txt references a file that doesn't exist: Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
Warning: Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
Warning: Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/siliconmitus,sm5703.yaml
Warning: Documentation/devicetree/bindings/rtc/motorola,cpcap-rtc.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 0/2] arm64: dts: socfpga: agilex7-gen2: Add initial device tree support
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-23 11:17 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
This series introduces initial device tree support for the Intel
SoCFPGA Agilex7 Gen2 platform.
The first patch registers the new SoC and board compatible strings in
the DT binding. The second patch adds the SoC DTSI and board DTS with
basic platform nodes.
Nazim Amirul (2):
dt-bindings: arm: altera: Add Agilex7 Gen2 SoCFPGA compatible strings
arm64: dts: socfpga: agilex7-gen2: Add initial device tree
.../devicetree/bindings/arm/altera.yaml | 6 +
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex7_gen2.dtsi | 175 ++++++++++++++++++
.../dts/intel/socfpga_agilex7_gen2_socdk.dts | 15 ++
4 files changed, 197 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex7_gen2_socdk.dts
--
2.43.7
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: altera: Add Agilex7 Gen2 SoCFPGA compatible strings
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-23 11:17 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260623111716.16690-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add the SoC and board compatible strings for the Intel SoCFPGA
Agilex7 Gen2 platform.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
Documentation/devicetree/bindings/arm/altera.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 4b096e52243e..da32ff31aea0 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -115,6 +115,12 @@ properties:
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5
+ - description: Agilex7 Gen2 boards
+ items:
+ - enum:
+ - intel,socfpga-agilex7-gen2-socdk
+ - const: intel,socfpga-agilex7-gen2
+
- description: Agilex7m boards
items:
- enum:
--
2.43.7
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: socfpga: agilex7-gen2: Add initial device tree
From: muhammad.nazim.amirul.nazle.asmade @ 2026-06-23 11:17 UTC (permalink / raw)
To: dinguyen; +Cc: robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260623111716.16690-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Add initial device tree support for the Intel SoCFPGA Agilex7 Gen2
platform. This introduces the SoC DTSI and the SoCDK board DTS as
the first upstream submission for this platform.
The Agilex7 Gen2 SoC features a heterogeneous CPU cluster with
Cortex-A520 and Cortex-A720 cores, and includes an SMMU v3 for
memory management.
Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex7_gen2.dtsi | 119 ++++++++++++++++++
.../dts/intel/socfpga_agilex7_gen2_socdk.dts | 15 +++
3 files changed, 135 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex7_gen2_socdk.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 088a03b89c99..7a53b3c174a1 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex5_socdk_013b.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
+ socfpga_agilex7_gen2_socdk.dtb \
socfpga_agilex7m_socdk.dtb \
socfpga_n5x_socdk.dtb
dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi
new file mode 100644
index 000000000000..e3b777408f9a
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+/dts-v1/;
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+ compatible = "intel,socfpga-agilex7-gen2";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ atf_reserved: atf@80000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80000000 0x0 0x100000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ service_reserved: svcbuffer@80100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x80100000 0x0 0xf00000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x0>;
+ };
+
+ cpu1: cpu@100 {
+ compatible = "arm,cortex-a520";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x100>;
+ };
+
+ cpu2: cpu@200 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x200>;
+ };
+
+ cpu3: cpu@300 {
+ compatible = "arm,cortex-a720";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x300>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ intc: interrupt-controller@7000000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x7000000 0x0 0x10000>,
+ <0x0 0x7080000 0x0 0x100000>;
+ ranges;
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-controller;
+ #redistributor-regions = <1>;
+ redistributor-stride = <0x0 0x40000>;
+
+ its: msi-controller@7040000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x0 0x7040000 0x0 0x20000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ soc: soc@0 {
+ compatible = "simple-bus";
+ ranges = <0 0 0 0xffffffff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ interrupt-parent = <&intc>;
+
+ smmu: iommu@c100000 {
+ compatible = "arm,smmu-v3";
+ reg = <0x0c100000 0x30000>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "eventq", "gerror", "priq";
+ dma-coherent;
+ #iommu-cells = <1>;
+ };
+
+ ocram: sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x00000000 0x80000>;
+ ranges = <0 0 0x80000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2_socdk.dts
new file mode 100644
index 000000000000..416d033445ff
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2_socdk.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026, Altera Corporation
+ */
+#include "socfpga_agilex7_gen2.dtsi"
+
+/ {
+ model = "Altera SoCFPGA Agilex7 Gen2 SoCDK";
+ compatible = "intel,socfpga-agilex7-gen2-socdk", "intel,socfpga-agilex7-gen2";
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x80000000>;
+ };
+};
--
2.43.7
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: qcom: glymur-crd: merge duplicate &pmh0101_gpios node extensions
From: Pankaj Patil @ 2026-06-23 11:22 UTC (permalink / raw)
To: Gopikrishna Garmidi, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov
Cc: Sibi Sankar, Rajendra Nayak, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260602-merge-duplicate-pmh0101-gpios-node-v2-1-251107b3d9fe@oss.qualcomm.com>
On 6/2/2026 3:18 PM, Gopikrishna Garmidi wrote:
> The &pmh0101_gpios node is extended twice in glymur-crd.dtsi. The first
> extension defines the nvme_reg_en pinctrl state for the NVMe regulator
> enable GPIO (gpio14), and the second adds key_vol_up_default for the
> volume-up key (gpio6).
>
> Merge both pinctrl states into a single &pmh0101_gpios block to avoid
> the duplicate node extension.
>
> No functional change intended.
>
> Fixes: a5ad8a8e473c ("arm64: dts: qcom: Commonize Glymur CRD DTSI")
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
> Changes in v2:
> - Reorder nodes in alphabetical order
> - Link to v1: https://lore.kernel.org/r/20260526-merge-duplicate-pmh0101-gpios-node-v1-1-c4ab4983f8be@oss.qualcomm.com
> ---
> arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> index e784b538f42e..782578a2c5ff 100644
> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
> @@ -538,6 +538,13 @@ &pcie6_port0 {
> };
>
> &pmh0101_gpios {
> + key_vol_up_default: key-vol-up-default-state {
> + pins = "gpio6";
> + function = "normal";
> + output-disable;
> + bias-pull-up;
> + };
> +
> nvme_reg_en: nvme-reg-en-state {
> pins = "gpio14";
> function = "normal";
> @@ -553,15 +560,6 @@ nvme_sec_reg_en: nvme-reg-en-state {
> };
> };
>
> -&pmh0101_gpios {
> - key_vol_up_default: key-vol-up-default-state {
> - pins = "gpio6";
> - function = "normal";
> - output-disable;
> - bias-pull-up;
> - };
> -};
> -
> &pmk8850_rtc {
> qcom,no-alarm;
> };
>
> ---
> base-commit: 08484c504b55a98bd100527fbe10a3caf55ff3ff
> change-id: 20260526-merge-duplicate-pmh0101-gpios-node-52eaf99f8485
>
> Best regards,
Reviewed-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 3/8] arm64: dts: qcom: sm8450: Modify GPU operating points
From: Konrad Dybcio @ 2026-06-23 11:23 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-3-37e2ee8df9da@proton.me>
On 6/23/26 2:54 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> These frecuencies don't exist in downstream device trees.
> Both 220MHz and 285MHz belong to SM8475, and I'm not sure where 317MHz
> came from.
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 15 ---------------
> 1 file changed, 15 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index e34e3c05bf74..5e331a25e22a 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -2495,21 +2495,6 @@ opp-350000000 {
> opp-hz = /bits/ 64 <350000000>;
> opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
> };
> -
> - opp-317000000 {
> - opp-hz = /bits/ 64 <317000000>;
> - opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS>;
> - };
> -
> - opp-285000000 {
> - opp-hz = /bits/ 64 <285000000>;
> - opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
> - };
> -
> - opp-220000000 {
> - opp-hz = /bits/ 64 <220000000>;
> - opp-level = <RPMH_REGULATOR_LEVEL_LOW_SVS_D1>;
> - };
These are valid frequency points, although downstream didn't advertize
them.
Funnily enough, the frequency plan lists them as:
LOWSVS_D2 -> 317 MHz // in downstream, at LOW_SVS
LOWSVS_D1 -> 285 MHz // in downstream as-is
LOWSVS_D0 -> 220 MHz // in downstream, LOW_SVS_D1
(the above are what it says in the doc, yes, lower voltage for
higher frequencies.. certainly seems like a bug..)
LOW_SVS -> 350 Mhz // this and the following are in downstream too
LOW_SVS_L1-> 421 MHz
SVS -> 492 MHz
SVS_L0 -> 545 MHz
SVS_L1 -> 599 MHz
SVS_L2 -> 640 MHz
NOM -> 734 MHz
NOM_L1 -> 791 MHz
TURBO -> 818 MHz
so in short, the existing map seems to be OK
Konrad
^ permalink raw reply
* Re: [PATCH 5/8] iommu/arm-smmu-qcom: Add SM8450 MDSS compatible
From: Konrad Dybcio @ 2026-06-23 11:23 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-5-37e2ee8df9da@proton.me>
On 6/23/26 2:54 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Add the compatible for the MDSS client on the Snapdragon 8 Gen 1 so it
> can be properly configured by the IOMMU driver.
>
> Otherwise, there is an unhandled context fault.
"because the framebuffer is already configured in UEFI"
>
> Signed-off-by: Esteban Urrutia <esteuwu@proton.me>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: qcom: eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK
From: Krzysztof Kozlowski @ 2026-06-23 11:27 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its
Display Clock Controller is enabled and references parent clocks from
DSI PHYs. Devices which in base DTSI do not have all required resources
available (e.g. because they are simply disabled), should not be enabled
in the first place.
Having DISPCC enabled without DSI PHYs causes clock reparenting issues
and warning on Eliza EVK:
disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration.
WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273
...
update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P)
clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471)
clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540)
__clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368)
devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1))
devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104)
qcom_cc_really_probe (drivers/clk/qcom/common.c:418)
qcom_cc_probe (drivers/clk/qcom/common.c:445)
disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza
platform_probe (drivers/base/platform.c:1432)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza-mtp.dts | 4 ++++
arch/arm64/boot/dts/qcom/eliza.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza-mtp.dts b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
index 7b42e37e5bf8..28063e952f69 100644
--- a/arch/arm64/boot/dts/qcom/eliza-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
@@ -425,6 +425,10 @@ vreg_l7k: ldo7 {
};
};
+&dispcc {
+ status = "okay";
+};
+
&gpi_dma1 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index aa72d5f042a7..5b62272e242f 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -3220,6 +3220,7 @@ dispcc: clock-controller@af00000 {
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
+ status = "disabled";
};
videocc: clock-controller@aaf0000 {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 03/12] iio: adc: at91-sama5d2_adc: adapt the driver for sama7d65
From: sashiko-bot @ 2026-06-23 11:28 UTC (permalink / raw)
To: Varshini Rajendran; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260623105944.128840-4-varshini.rajendran@microchip.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Uninitialized touch channel indices incorrectly configure regular channel 0 as a touchscreen channel, breaking IIO buffered reads.
- [High] Temperature channel scan_index (31) exceeds the defined max_index (25), breaking IIO bitmap validations and hardware triggers.
--
commit 2d567bf99b76168b7ea132082c84ddd5029c1706
Author: Varshini Rajendran <varshini.rajendran@microchip.com>
iio: adc: at91-sama5d2_adc: adapt the driver for sama7d65
Add support for sama7d65 ADC. The differences are highlighted with the
compatible. The calibration data layout is the main difference.
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c
> index b569d175f4c3d..237d339f342a1 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
[ ... ]
> @@ -768,6 +778,24 @@ static const struct at91_adc_platform sama7g5_platform = {
> .temp_calib_layout = &sama7g5_temp_calib,
> };
>
> +static const struct at91_adc_platform sama7d65_platform = {
> + .layout = &sama7g5_layout,
> + .adc_channels = &at91_sama7g5_adc_channels,
> + .nr_channels = AT91_SAMA7G5_SINGLE_CHAN_CNT +
> + AT91_SAMA7G5_DIFF_CHAN_CNT +
> + AT91_SAMA7G5_TEMP_CHAN_CNT,
[Severity: High]
This isn't a bug introduced by this patch, but inherited from the SAMA7G5
implementation. Does omitting the touch channel indices cause an issue for
channel 0?
By omitting touch_chan_x and similar fields, they default to 0. Later,
during probe, this zero-initialized value is used:
at91_adc_probe() {
...
bitmap_set(&st->touch_st.channels_bitmask,
st->soc_info.platform->touch_chan_x, 1);
...
}
Will this cause the driver to incorrectly set bit 0 in the touchscreen
bitmask, diverting regular channel 0 captures into the touchscreen logic
and breaking IIO buffered reads for that channel?
> + .max_channels = ARRAY_SIZE(at91_sama7g5_adc_channels),
> + .max_index = AT91_SAMA7G5_MAX_CHAN_IDX,
[Severity: High]
This is also a pre-existing issue inherited from the SAMA7G5 implementation,
but does this max_index configuration conflict with the temperature channel?
The max_index is configured to 25 (AT91_SAMA7G5_MAX_CHAN_IDX), but the
temperature channel has a scan_index of 31. This mismatch appears to break
IIO bitmap validations and hardware triggers.
For instance, in the hardware enablement path:
at91_adc_active_scan_mask_to_reg() {
...
for_each_set_bit(bit, indio_dev->active_scan_mask,
indio_dev->num_channels) {
...
return mask & GENMASK(st->soc_info.platform->nr_channels, 0);
}
This applies a 26-bit mask, which permanently ignores the temperature channel
at index 31. Does this structurally break the temperature channel for IIO
buffered reads by causing the core to expect data that the driver never
fetches?
> + .hw_trig_cnt = AT91_SAMA7G5_HW_TRIG_CNT,
> + .osr_mask = GENMASK(18, 16),
> + .oversampling_avail = { 1, 4, 16, 64, 256, },
> + .oversampling_avail_no = 5,
> + .chan_realbits = 16,
> + .temp_sensor = true,
> + .temp_chan = AT91_SAMA7G5_ADC_TEMP_CHANNEL,
> + .temp_calib_layout = &sama7d65_temp_calib,
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623105944.128840-1-varshini.rajendran@microchip.com?part=3
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: socfpga: agilex7-gen2: Add initial device tree
From: sashiko-bot @ 2026-06-23 11:28 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260623111716.16690-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
Thank you for your contribution! Sashiko AI review found 7 potential issue(s) to consider:
- [Critical] Missing mandatory ARM architected timer (`arm,armv8-timer`) node.
- [High] The ATF (ARM Trusted Firmware) reserved memory is improperly declared as a shared DMA pool.
- [Medium] Missing Energy Aware Scheduling (EAS) capacity and topology maps for heterogeneous big.LITTLE CPUs.
- [Medium] Missing UART/serial console and `chosen` node.
- [Medium] Missing VGIC maintenance interrupt in the GICv3 node.
- [Low] Invalid combination of `reg` and `alignment` properties in `reserved-memory` nodes.
- [Low] Incorrect `#address-cells` for 64-bit CPUs.
--
commit 686f550501dd7f94cdc969838594ed32ff4cbd42
Author: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
arm64: dts: socfpga: agilex7-gen2: Add initial device tree
This patch adds the initial device tree support for the Intel SoCFPGA Agilex7
Gen2 platform. It includes the SoC DTSI and the SoCDK board DTS, featuring
a heterogeneous CPU cluster with Cortex-A520 and Cortex-A720 cores.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi
> new file mode 100644
> index 0000000000000..e3b777408f9a6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex7_gen2.dtsi
> @@ -0,0 +1,119 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026, Altera Corporation
> + */
> +/dts-v1/;
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> + compatible = "intel,socfpga-agilex7-gen2";
> + #address-cells = <2>;
> + #size-cells = <2>;
[Severity: Critical]
Is it intentional to omit the arm,armv8-timer node from the root level? Without
the architectural timer node, the system may fail to establish a clocksource
and clockevents, which typically leads to an indefinite hang during early boot
when timer_probe() fails.
[Severity: Medium]
Does this platform need a chosen node and UART serial console configured at
the root level? Omitting them usually results in no interactive console or
kernel boot logs over serial, which makes early boot validation very difficult.
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + atf_reserved: atf@80000000 {
> + compatible = "shared-dma-pool";
[Severity: High]
Does declaring the ATF reserved memory as a shared-dma-pool expose the secure
EL3 memory region to the kernel's DMA allocator? If the kernel resolves a DMA
allocation to this region and a device writes to it, it could overwrite the
TrustZone firmware, potentially triggering a secure access violation (SError).
> + reg = <0x0 0x80000000 0x0 0x100000>;
> + alignment = <0x1000>;
[Severity: Low]
Is it necessary to include the alignment property when reg is already
explicitly provided? Device tree schema validation typically rejects combining
reg and alignment in reserved-memory nodes, as the kernel parser typically
ignores alignment when reg is present.
> + no-map;
> + };
> +
> + service_reserved: svcbuffer@80100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x0 0x80100000 0x0 0xf00000>;
> + alignment = <0x1000>;
[Severity: Low]
Similar to the ATF reserved node, is the alignment property needed here when a
reg property is explicitly defined?
> + no-map;
> + };
> + };
> +
> + cpus {
> + #address-cells = <1>;
[Severity: Low]
Should #address-cells be 2 for 64-bit ARM CPUs? While it might work if the
Aff3 field is zero, setting it to 1 truncates the MPIDR_EL1 representation to
32 bits and violates ARM64 device tree binding conventions.
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a520";
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x0>;
> + };
[ ... ]
> + cpu3: cpu@300 {
> + compatible = "arm,cortex-a720";
[Severity: Medium]
Are the Energy Aware Scheduling (EAS) capacity and topology maps missing for
these heterogeneous cores? Without them, the scheduler might treat the
Cortex-A520 and Cortex-A720 as having identical performance capabilities,
leading to suboptimal task placement.
> + device_type = "cpu";
> + enable-method = "psci";
> + reg = <0x300>;
> + };
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + intc: interrupt-controller@7000000 {
> + compatible = "arm,gic-v3";
> + reg = <0x0 0x7000000 0x0 0x10000>,
> + <0x0 0x7080000 0x0 0x100000>;
> + ranges;
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-controller;
> + #redistributor-regions = <1>;
> + redistributor-stride = <0x0 0x40000>;
[Severity: Medium]
Does the GICv3 node need to declare a VGIC maintenance interrupt? Without this
interrupt, the KVM hypervisor might not receive maintenance interrupts,
which can break virtualized interrupt state management for guest VMs.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260623111716.16690-1-muhammad.nazim.amirul.nazle.asmade@altera.com?part=2
^ 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