All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.