[PATCH v2 0/2] Add EC support for Purwa IOT EVK

[PATCH v2 0/2] Add EC support for Purwa IOT EVK

[Anvesh Jain P]

Add the embedded controller node to the Purwa IOT EVK board and document
its compatible. The EC provides fan control, temperature sensors and EC
state change notifications.

Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
Changes in v2:
- dt-bindings: Reworded the commit message to describe the EC hardware
  details. [Krzysztof]
- Collected Reviewed-by and Tested-by tags on the dts patch.
- Link to v1: https://lore.kernel.org/r/20260629-ec_support_for_purwa_evk-v1-0-e082b70138d6@oss.qualcomm.com

---
Anvesh Jain P (2):
      dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add Purwa IOT EVK
      arm64: dts: qcom: purwa-iot-evk: Add Embedded controller node

 .../bindings/embedded-controller/qcom,hamoa-crd-ec.yaml  |  1 +
 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts               | 16 ++++++++++++++++
 2 files changed, 17 insertions(+)
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260629-ec_support_for_purwa_evk-687780bec098

Best regards,
-- 
Anvesh Jain P <anvesh.p@oss.qualcomm.com>

[PATCH v2 1/2] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add Purwa IOT EVK

[Anvesh Jain P]

Document the qcom,purwa-iot-evk-ec compatible for the embedded controller
found on Purwa IOT EVK boards.

Like the CRD, the Purwa IOT EVK carries an on-board embedded controller,
provided by ITE and running on a separate MCU, which handles fan control,
temperature sensors and EC state-change/suspend notifications. The existing
Hamoa IOT EVK documents the same EC via qcom,hamoa-iot-evk-ec.

Like the other reference designs, it uses qcom,hamoa-crd-ec as its fallback
compatible.

Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
 .../devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml       | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
index ac5a08f8f76d..c07483aa5937 100644
--- a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
+++ b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
@@ -22,6 +22,7 @@ properties:
           - enum:
               - qcom,glymur-crd-ec
               - qcom,hamoa-iot-evk-ec
+              - qcom,purwa-iot-evk-ec
           - const: qcom,hamoa-crd-ec
       - enum:
           - qcom,hamoa-crd-ec

-- 
2.34.1

Re: [PATCH v2 1/2] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add Purwa IOT EVK

[Krzysztof Kozlowski]

On Fri, Jul 03, 2026 at 03:23:41PM +0530, Anvesh Jain P wrote:
> Document the qcom,purwa-iot-evk-ec compatible for the embedded controller
> found on Purwa IOT EVK boards.
> 
> Like the CRD, the Purwa IOT EVK carries an on-board embedded controller,
> provided by ITE and running on a separate MCU, which handles fan control,
> temperature sensors and EC state-change/suspend notifications. The existing
> Hamoa IOT EVK documents the same EC via qcom,hamoa-iot-evk-ec.
> 
> Like the other reference designs, it uses qcom,hamoa-crd-ec as its fallback
> compatible.
> 
> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
> ---
>  .../devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml       | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH v2 2/2] arm64: dts: qcom: purwa-iot-evk: Add Embedded controller node

[Anvesh Jain P]

Add embedded controller node for Purwa IOT EVK boards which adds fan
control, temperature sensors, access to EC internal state changes and
suspend entry/exit notifications to the EC.

Tested-by: Yushan Li <yushan.li@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
index ad503beec1d3..491ea7769cd7 100644
--- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
@@ -837,6 +837,16 @@ eusb6_repeater: redriver@4f {
 		pinctrl-0 = <&eusb6_reset_n>;
 		pinctrl-names = "default";
 	};
+
+	embedded-controller@76 {
+		compatible = "qcom,purwa-iot-evk-ec", "qcom,hamoa-crd-ec";
+		reg = <0x76>;
+
+		interrupts-extended = <&tlmm 66 IRQ_TYPE_EDGE_FALLING>;
+
+		pinctrl-0 = <&ec_int_n_default>;
+		pinctrl-names = "default";
+	};
 };
 
 &i2c7 {
@@ -1326,6 +1336,12 @@ right_tweeter: speaker@0,1 {
 };
 
 &tlmm {
+	ec_int_n_default: ec-int-n-state {
+		pins = "gpio66";
+		function = "gpio";
+		bias-disable;
+	};
+
 	edp_reg_en: edp-reg-en-state {
 		pins = "gpio70";
 		function = "gpio";

-- 
2.34.1

Re: [PATCH v2 2/2] arm64: dts: qcom: purwa-iot-evk: Add Embedded controller node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] Configuring the EC interrupt as IRQ_TYPE_EDGE_FALLING causes a stuck IRQ line and lost events.

Pre-existing issues:
- [High] The driver registers all cooling devices with cdev_id = 0, breaking multi-fan thermal device tree bindings.
- [High] Probe function fails to disable EC SCI events on error paths, leading to corrupted EC state and unhandled interrupts.
- [High] qcom_ec_read() ignores partial I2C block reads, causing callers to use uninitialized stack memory as hardware state.
--

commit 30f797509dd26f2c0981b525ba3d62d1173ae857
Author: Anvesh Jain P <anvesh.p@oss.qualcomm.com>

arm64: dts: qcom: purwa-iot-evk: Add Embedded controller node

This commit adds the embedded controller node for Purwa IOT EVK boards.
It configures fan control, temperature sensors, access to EC internal state
changes, and suspend notifications to the EC.

> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> index ad503beec1d3d..491ea7769cd71 100644
> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> @@ -837,6 +837,16 @@ eusb6_repeater: redriver@4f {
[ ... ]
> +
> +	embedded-controller@76 {
> +		compatible = "qcom,purwa-iot-evk-ec", "qcom,hamoa-crd-ec";
> +		reg = <0x76>;
> +
> +		interrupts-extended = <&tlmm 66 IRQ_TYPE_EDGE_FALLING>;

[Severity: High]
Does configuring the EC interrupt as IRQ_TYPE_EDGE_FALLING cause a stuck
IRQ line and lost events?

The EC asserts an interrupt while multiple events are pending, but the driver's
interrupt handler reads exactly one event and returns without looping. 

Because the trigger is configured as edge-falling, the persistent low state
of the line does not trigger another interrupt, causing the line to stall
permanently.  Should this use level-triggered interrupts instead?

> +
> +		pinctrl-0 = <&ec_int_n_default>;
> +		pinctrl-names = "default";
> +	};
>  };


While reviewing this patch, I also noticed a few pre-existing issues in
drivers/platform/arm64/qcom-hamoa-ec.c that handles this device tree node:

drivers/platform/arm64/qcom-hamoa-ec.c:qcom_ec_probe()
[ ... ]
> 	ret = qcom_ec_sci_evt_control(dev, true);
> 	if (ret < 0)
> 		return dev_err_probe(dev, ret, "Failed to enable SCI events\n");
> 
> 	ret = qcom_ec_thermal_capabilities(dev);
> 	if (ret < 0)
> 		return dev_err_probe(dev, ret, "Failed to read thermal capabilities\n");

[Severity: High]
This is a pre-existing issue, but does the probe function fail to disable
EC SCI events on error paths?

If qcom_ec_thermal_capabilities() or the subsequent memory allocation fails,
probe returns an error. The previously enabled SCI events are never disabled
because no devm action was registered and remove() is not called.

The EC is left actively generating events, but the OS interrupt handler is
freed by devres. The EC will assert the IRQ line, which goes unhandled,
potentially stalling the EC and causing battery drain.


drivers/platform/arm64/qcom-hamoa-ec.c:qcom_ec_probe()
[ ... ]
> 	for (i = 0; i < ec->thermal_cap.fan_cnt; i++) {
> 		struct qcom_ec_cooling_dev *ec_cdev = &ec->ec_cdev[i];
> 		char name[EC_FAN_NAME_SIZE];
> 
> 		scnprintf(name, sizeof(name), "qcom_ec_fan_%u", i);
> 		ec_cdev->fan_id = i + 1;
> 		ec_cdev->parent_dev = dev;
> 
> 		ec_cdev->cdev = devm_thermal_of_cooling_device_register(dev, 0, NULL, ec_cdev,
> 									&qcom_ec_thermal_ops);

[Severity: High]
This isn't a bug introduced by this patch, but does hardcoding the cdev_id 
to 0 break multi-fan thermal device tree bindings?

By looping over fan_cnt and passing 0 for every fan instance rather than
the iteration index, the OF thermal core cannot distinguish between multiple
cooling devices under the same node.  

This breaks thermal zone mappings and can cause undefined behavior when
binding thermal states.


drivers/platform/arm64/qcom-hamoa-ec.c:qcom_ec_read()
[ ... ]
> static int qcom_ec_read(struct qcom_ec *ec, u8 cmd, u8 resp_len, u8 *resp)
> {
> 	int ret;
> 
> 	ret = i2c_smbus_read_i2c_block_data(ec->client, cmd, resp_len, resp);
> 	if (ret < 0)
> 		return ret;
> 	else if (ret == 0 || ret == 0xff)
> 		return -EOPNOTSUPP;
> 
> 	if (resp[0] >= resp_len)
> 		return -EINVAL;
> 
> 	return 0;
> }

[Severity: High]
This isn't a bug introduced by this patch, but does qcom_ec_read() ignore
partial I2C block reads?

i2c_smbus_read_i2c_block_data() returns the number of bytes read. If a short
read occurs, this returns success (0) because it only checks if ret < 0,
ret == 0, or ret == 0xff. It does not verify if ret matches the expected
resp_len.

Callers are then exposed to using uninitialized stack memory as hardware
state for firmware version data, fan counts, or thermistor masks. This can
lead to out-of-bounds memory allocations if a bogus fan count is read.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-ec_support_for_purwa_evk-v2-0-c59aac5c6aac@oss.qualcomm.com?part=2