Messages in this thread |  | | Date | Tue, 10 Mar 2026 10:45:42 +0100 | | Subject | Re: [PATCH V3 4/5] arm64: dts: qcom: x1-crd: Add Embedded controller node | | From | Konrad Dybcio <> |
| |
On 3/9/26 10:13 PM, 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@oss.qualcomm.com> >>>>>> --- >>>>>> 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.
+1
Konrad
|  |