Re: [PATCH v4 1/6] dt-bindings: i2c: qcom,i2c-cci: Add Hawi compatible

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] dt-bindings: i2c: qcom,hawi-cci falls back to
  qcom,msm8996-cci
--

commit eeb66a38f27dd112905efa0a186dff7682ef33dd
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>

dt-bindings: i2c: qcom,i2c-cci: Add Hawi compatible

This commit documents the qcom,hawi-cci compatible string and its
two-clock requirement in the Qualcomm CCI I2C binding.

> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
> index 1e8def25ec0ec..b2b4d4bcf7807 100644
> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml
> @@ -27,6 +27,7 @@ properties:
>        - items:
>            - enum:
>                - qcom,glymur-cci
> +              - qcom,hawi-cci
>                - qcom,kaanapali-cci
>                - qcom,milos-cci
>                - qcom,qcm2290-cci

[Severity: Medium]
As reported by Loic Poulain on RFC [1], should qcom,hawi-cci stop falling
back to qcom,msm8996-cci and use a dedicated variant entry instead?

Placing qcom,hawi-cci in the qcom,msm8996-cci fallback list without a
dedicated entry in cci_dt_match[] causes cci_probe() to bind Hawi CCI
controllers to the legacy cci_v2_data configuration (queue_size = { 64, 16 }
and max_write_len = 11) rather than matching the newer IP revision's FIFO
and queue sizes.

[1] https://lore.kernel.org/r/CAFEp6-1Zvt0hhBd7LNx2hsyi9J+bxCT8EWN3jZ4B30SO58SCow@mail.gmail.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-hawi-maili-camss-v4-0-d528c7a797b4@oss.qualcomm.com?part=1