Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: palash.kambar@oss.qualcomm.com
Cc: conor+dt@kernel.org, neil.armstrong@linaro.org,
	olteanv@gmail.com, devicetree@vger.kernel.org, robh@kernel.org,
	vkoul@kernel.org, linux-phy@lists.infradead.org
Subject: Re: [PATCH V1 2/3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document the Hawi UFS controller
Date: Mon, 18 May 2026 17:09:34 +0000	[thread overview]
Message-ID: <20260518170934.BBBA4C2BCB7@smtp.kernel.org> (raw)
In-Reply-To: <20260518165346.1732548-3-palash.kambar@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The commit title specifies the wrong subsystem and filename relative to the actual diff.
- [Medium] The new compatible string 'qcom,hawi-ufshc' is omitted from the `if-then` conditional block that enforces the MCQ register range constraints.
--

commit 1742ce0580b168eb19f1dc60a097e13ccbf8098d
Author: Palash Kambar <palash.kambar@oss.qualcomm.com>

dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document the Hawi UFS controller
    
Document the UFS Controller on the Hawi Platform.

> dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document the Hawi UFS controller

This isn't a bug, but the commit title specifies the wrong subsystem and
filename. It claims to modify the PHY binding qcom,sc8280xp-qmp-ufs-phy,
but the patch actually modifies the UFS host controller binding
Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml.

> diff --git a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
> index f28641c6e68fe..3de00affa4c64 100644
> --- a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
> +++ b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
[ ... ]
> @@ -27,6 +28,7 @@ properties:
>      items:
>        - enum:
>            - qcom,eliza-ufshc
> +          - qcom,hawi-ufshc
>            - qcom,kaanapali-ufshc
>            - qcom,sm8650-ufshc
>            - qcom,sm8750-ufshc

Does this code omit qcom,hawi-ufshc from the conditional block further down in
the file that enforces the MCQ register range constraints?

Looking at the allOf block in this file:

allOf:
  - $ref: qcom,ufs-common.yaml
  - if:
      properties:
        compatible:
          contains:
            enum:
              - qcom,eliza-ufshc
    then:
      properties:
        reg:
          minItems: 2
        reg-names:
          minItems: 2

If the Hawi platform shares the same hardware constraints and requires the MCQ
registers, could this regression allow incomplete device trees missing the MCQ
registers to silently pass schema validation by being omitted from this block?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260518165346.1732548-1-palash.kambar@oss.qualcomm.com?part=2

  reply	other threads:[~2026-05-18 17:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 16:53 [PATCH V1 0/3] Add Hawi UFS PHY and Controller support palash.kambar
2026-05-18 16:53 ` [PATCH V1 1/3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Add Hawi UFS PHY compatible palash.kambar
2026-05-18 17:01   ` sashiko-bot
2026-05-19  6:05   ` Manivannan Sadhasivam
2026-05-18 16:53 ` [PATCH V1 2/3] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Document the Hawi UFS controller palash.kambar
2026-05-18 17:09   ` sashiko-bot [this message]
2026-05-19  5:54   ` Manivannan Sadhasivam
2026-05-18 16:53 ` [PATCH V1 3/3] phy: qcom-qmp-ufs: Add UFS PHY support on Hawi palash.kambar
2026-05-18 17:09   ` Dmitry Baryshkov
2026-05-19  4:18     ` Palash Kambar
2026-05-18 17:29   ` sashiko-bot

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=20260518170934.BBBA4C2BCB7@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=olteanv@gmail.com \
    --cc=palash.kambar@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vkoul@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox