From: sashiko-bot@kernel.org
To: "Anvesh Jain P" <anvesh.p@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add thermal sensors
Date: Mon, 28 Sep 2026 06:48:01 +0000 [thread overview]
Message-ID: <20260928064801.A3A261F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260928-ec_thermistor_support-v1-1-d9c1bae4cd0d@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: qcom,hamoa-crd-ec: unconditional schema ref breaks dtbs_check
--
commit ee4c510364f0a8d45223544f87706874323cd5cb
Author: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Date: Mon Sep 28 06:36:37 2026 +0000
dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add thermal sensors
This commit updates the Hamoa embedded controller bindings to act as a
thermal-sensor provider. It introduces a thermal-sensor schema reference and
defines the #thermal-sensor-cells property.
> 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 ac5a08f8f76df..13de6bed81297 100644
> --- a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
> +++ b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
> @@ -15,6 +15,9 @@ description:
> EC running on different MCU chips. The EC handles things like fan control,
> temperature sensors, access to EC internal state changes.
>
> +allOf:
> + - $ref: /schemas/thermal/thermal-sensor.yaml#
> +
[Severity: Medium]
Will this unconditional reference break schema validation for existing device
trees?
The thermal-sensor.yaml schema enforces the #thermal-sensor-cells property,
but existing in-tree device trees (arch/arm64/boot/dts/qcom/x1-crd.dtsi and
arch/arm64/boot/dts/qcom/hamoa-iot-evk.dts) use the qcom,hamoa-crd-ec
compatible without specifying #thermal-sensor-cells:
embedded-controller@76 {
compatible = "qcom,hamoa-crd-ec";
reg = <0x76>;
interrupts-extended = <&tlmm 66 IRQ_TYPE_EDGE_FALLING>;
Does this patch series need to add the property to those existing users, or
should the $ref be made conditional to preserve backwards compatibility?
> properties:
> compatible:
> oneOf:
[ ... ]
> @@ -32,6 +35,14 @@ properties:
> interrupts:
> maxItems: 1
>
> + "#thermal-sensor-cells":
> + description:
> + The EC exposes up to 7 onboard thermistors (indices 0-6). Which
> + indices are physically populated on a given board is discovered at
> + runtime from EC firmware capabilities; a board may reference any index
> + 0-6.
> + const: 1
> +
> required:
> - compatible
> - reg
[Severity: Medium]
Should #thermal-sensor-cells be added to this explicit required list?
The subsystem guidelines state that when a variant compatible string adds
provider capabilities, the corresponding properties must appear in the required
list with appropriate constraints.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-ec_thermistor_support-v1-0-d9c1bae4cd0d@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-09-28 6:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 6:36 [PATCH 0/3] platform: arm64: qcom-hamoa-ec: Add thermistor support Anvesh Jain P
2026-09-28 6:36 ` [PATCH 1/3] dt-bindings: embedded-controller: qcom,hamoa-crd-ec: Add thermal sensors Anvesh Jain P
2026-09-28 6:48 ` sashiko-bot [this message]
2026-09-28 6:36 ` [PATCH 2/3] platform: arm64: qcom-hamoa-ec: Add thermistor sensors Anvesh Jain P
2026-09-29 7:35 ` Ilpo Järvinen
2026-09-30 5:02 ` Anvesh Jain P
2026-09-28 6:36 ` [PATCH 3/3] arm64: dts: qcom: glymur: Add EC thermal zones Anvesh Jain P
2026-09-28 6:51 ` sashiko-bot
2026-09-29 8:56 ` Krzysztof Kozlowski
2026-09-29 10:07 ` Anvesh Jain P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260928064801.A3A261F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=anvesh.p@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.