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

[Sibi Sankar]

On 3/10/2026 2:43 AM, Dmitry Baryshkov wrote:
> On Mon, Mar 09, 2026 at 04:21:50PM +0530, 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
> > 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
> > and add specific compatibles when we upstream those boards?
> Why do you need a generic compat at all? Glancing at the database, at
> least the following laptops seem to have similar protocol (I might be
> wrong, this is based on a very quick glance):
>
> acer-sfa14-11
> asus-vivobook-s-15
> asus-vivobook-s15-q5507
> asus-vivobook-s15-s5507
> honor-magicbook-art-14
> honor-mro-521
> hp-elitebook-6-g1q
> hp-omnibook-5-14-he0xxx
> lenovo-ideacentre-01q8x10
> lenovo-ideapad-slim3x-15q8x10-WCN7850
> lenovo-thinkpad-t14s-120hz-64gb
> lenovo-thinkpad-t14s
> lenovo-yoga-slim-7x
> medion-14-s1-elite-sprchrgd
> medion-14-s1-sprchrgd
> qualcomm-snapdragon-dev-kit
> tuxedo-elite-14-gen1
>
> I assume that some of them might be false positives and others will use
> vendor (or device) extensions to your protocol.
>
> I'd suggest implicitly using "qcom,hamoa-crd-ec" / "qcom,glymyr-crd-ec",
> because then we can use something like "asus,vivobook-s15-ec" to
> identify the EC on VivoBook S15.

Ack, this was the consensus reached as well.

> > > Best regards,
> > > Krzysztof