[PATCH v3 2/3] scsi: ufs: qcom: dt-bindings: Document the Hawi UFS controller

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The new compatible string `qcom,hawi-ufshc` was omitted from the existing `if-then` conditional block that enforces the MCQ register constraints.
--

commit 6ca85cee3094310081f09881b4d6d6a9e987b327
Author: Palash Kambar <palash.kambar at oss.qualcomm.com>

scsi: ufs: qcom: dt-bindings: Document the Hawi UFS controller
    
Document the UFS Controller on the Hawi Platform.

> 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

[Severity: Medium]
Should qcom,hawi-ufshc also be added to the allOf conditional block that
enforces the MCQ register constraints?

If the new compatible string shares the same constraints as previous
generations, device tree configurations with only one register region could
silently pass schema validation.

Looking at the existing conditional block lower down in the file:

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

Does this if-then block need to be updated to include the new compatible
string so the validation remains complete?

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