All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Gaurav Kohli" <gaurav.kohli@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
Date: Tue, 09 Jun 2026 10:36:42 +0000	[thread overview]
Message-ID: <20260609103643.45B631F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260609-qmi-tmd-v3-1-291a2ff4c634@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The `#cooling-cells` property uses an `enum` constraint instead of a hardware-matching `const` constraint.
- [Medium] Schema fails to enforce the mutual dependency between `#cooling-cells: 3` and `tmd-names`.
- [Low] The newly introduced 'tmd-names' property is missing the 'qcom,' vendor prefix.
--

commit ff18b7a7814a6d6f6545f74edd22e93602470084
Author: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
Date:   Tue Jun 9 10:22:56 2026 +0000

dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties

Document Qualcomm PAS remoteproc thermal mitigation properties used for
QMI-based throttling.

> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> index 4607b459131b4..0d07a07507620 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> @@ -79,6 +79,20 @@ properties:
>        channels and devices related to the ADSP.
>      unevaluatedProperties: false
>  
> +  '#cooling-cells':
> +    description:
> +      Number of cooling cells; 2 for min/max cooling state and 3 when
> +      selecting a thermal mitigation device index.
> +    enum: [2, 3]

[Severity: Medium]
The device tree bindings guidelines state that each cell-count property must
have a const constraint matching the hardware. Is it possible to enforce a
strict const constraint in the specific hardware variant schemas rather than
allowing an enum here, so we prevent misconfigured device tree nodes from
passing validation?

> +
> +  tmd-names:

[Severity: Low]
Since this property is specific to Qualcomm's QMI-based thermal mitigation
device (TMD) throttling mechanism and not a standard core thermal binding,
should this have the "qcom," vendor prefix added to avoid namespace
collisions?

> +    $ref: /schemas/types.yaml#/definitions/string-array
> +    description:
> +      Names of the thermal mitigation devices available in remote processor
> +      subsystem.
> +    minItems: 1
> +    maxItems: 5

[Severity: Medium]
The #cooling-cells description mentions that a cell count of 3 is used to
select a thermal mitigation device index. Does this mean tmd-names should be
strictly required when #cooling-cells is 3? 

If so, should we add an allOf or if-then conditional block tying these two
properties together to prevent validation of incomplete nodes?

> +
>    glink-edge:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-qmi-tmd-v3-0-291a2ff4c634@oss.qualcomm.com?part=1

  reply	other threads:[~2026-06-09 10:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-09 10:22 [PATCH v3 0/8] Add support for Qualcomm remoteproc subsystem cooling Gaurav Kohli
2026-06-09 10:22 ` [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties Gaurav Kohli
2026-06-09 10:36   ` sashiko-bot [this message]
2026-06-09 10:47   ` Dmitry Baryshkov
2026-06-09 10:22 ` [PATCH v3 2/8] soc: qcom: Add support for QMI TMD cooling devices Gaurav Kohli
2026-06-09 10:37   ` sashiko-bot
2026-06-09 11:30   ` Dmitry Baryshkov
2026-06-09 12:08     ` Daniel Lezcano
2026-06-09 10:22 ` [PATCH v3 3/8] remoteproc: qcom: pas: register TMD thermal " Gaurav Kohli
2026-06-09 10:40   ` sashiko-bot
2026-06-09 11:05   ` Dmitry Baryshkov
2026-06-09 12:03   ` Konrad Dybcio
2026-06-09 10:22 ` [PATCH v3 4/8] arm64: dts: qcom: kodiak: Enable CDSP & Modem cooling Gaurav Kohli
2026-06-09 10:57   ` Dmitry Baryshkov
2026-06-09 10:23 ` [PATCH v3 5/8] arm64: dts: qcom: lemans: Enable CDSP cooling Gaurav Kohli
2026-06-09 10:23 ` [PATCH v3 6/8] arm64: dts: qcom: talos: " Gaurav Kohli
2026-06-09 10:23 ` [PATCH v3 7/8] arm64: dts: qcom: monaco: " Gaurav Kohli
2026-06-09 10:23 ` [PATCH v3 8/8] arm64: dts: qcom: hamoa: " Gaurav Kohli

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=20260609103643.45B631F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gaurav.kohli@oss.qualcomm.com \
    --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.