Re: [PATCH V3 4/5] arm64: dts: qcom: x1-crd: Add Embedded controller node

From: Sibi Sankar

Date: Mon Mar 09 2026 - 07:51:47 EST



On 3/9/2026 4:23 PM, Krzysztof Kozlowski wrote:
On 09/03/2026 11:51, Sibi Sankar wrote:
On 3/9/2026 2:39 PM, Krzysztof Kozlowski wrote:
On 09/03/2026 10:03, Sibi Sankar wrote:
On 3/9/2026 12:55 PM, Krzysztof Kozlowski wrote:
On Mon, Mar 09, 2026 at 05:06:45AM +0530, Sibi Sankar wrote:
Add embedded controller node for Hamoa/Purwa CRDs which adds fan control,
temperature sensors, access to EC internal state changes and suspend
entry/exit notifications to the EC.

Signed-off-by: Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/x1-crd.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/x1-crd.dtsi b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
index ded96fb43489..29a1aeb98353 100644
--- a/arch/arm64/boot/dts/qcom/x1-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1-crd.dtsi
@@ -1042,6 +1042,16 @@ eusb6_repeater: redriver@4f {
#phy-cells = <0>;
};
+
+ embedded-controller@76 {
+ compatible = "qcom,hamoa-it8987-ec", "qcom,hamoa-ec";
I don't see updates to other x1e boards, thus my arguments from v2 stay
valid. It's wrong to call it "hamoa-ec" since only one Hamoa board has
it. All of other Hamoa boards apparently do not have it.
Hey Krzysztof,
Thanks for taking time to review the series :)

What other Hamoa boards are you referring to? The series
mentions that the driver and bindings is meant for Qualcomm
Hamoa/Purwa/Glymur "reference" devices, so it only covers
CRD and IOT-EVK. It definitely does not cover all Hamoa boards
boards like you are assuming.
hamoa-ec compatible implies that and that's something I raised in v2
already. You need a specific compatible.

Hamoa/Glymur reference devices can have different EC MCUs
depending on the SKU. This introduces the need to deal with
possibility of quirks and bugs introduced by these differences.
Hamoa/Purwa CRDs and IOT EVK runs on IT8987, while Glymur
reference devices run on NPCX498/488. This pretty much was
None of these answer my comments from here and v2.

the rationale to make the MCU part of the compatible. Anyway
I can keep it as qcom,hamoa-ec and qcom,glymur-ec for now
No. You cannot add a generic compatible when you claim it is not even
correct - "different EC depending on the SKU".

https://lore.kernel.org/lkml/1336e1c3-6ee9-4a19-976b-0bfdc02fc8e6@xxxxxxxxxxx/

The explanation mentioned ^^ was the motivation
to have a extremely generic compatible as a fallback
since the firmware basically implements the same
exact specification.

https://lore.kernel.org/lkml/def949f2-301d-4edc-b303-0fbe02a18c3c@xxxxxxxxxx/

I'll stick to your suggestion mentioned ^^ and use the
following compatibles instead:

qcom,hamoa-crd-it8987-ec
qcom,hamoa-iot-evk-it8987-ec
qcom,glymur-crd-ncpx498s-ec

I'll continue to use the hamoa-crd based compatible
as the fallback since they implement the same firmware
on different MCUs.

+properties: + compatible: + items: + - enum: + - qcom,glymur-crd-npcx498s-ec + - qcom,hamoa-iot-evk-it8987-ec + - const: qcom,hamoa-crd-it8987-ec Thanks again!


Best regards,
Krzysztof