Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: Alim Akhtar <alim.akhtar@samsung.com>,
	Avri Altman <avri.altman@wdc.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Chunfeng Yun <chunfeng.yun@mediatek.com>,
	Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	Peter Wang <peter.wang@mediatek.com>,
	Stanley Jhu <chu.stanley@gmail.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>,
	kernel@collabora.com, linux-scsi@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	linux-phy@lists.infradead.org
Subject: Re: [PATCH 1/5] dt-bindings: ufs: mediatek,ufs: Add mt8196-ufshci variant
Date: Thu, 16 Oct 2025 17:53:01 +0100	[thread overview]
Message-ID: <20251016-kettle-clobber-2558d9c709de@spud> (raw)
In-Reply-To: <20251014-mt8196-ufs-v1-1-195dceb83bc8@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 8204 bytes --]

Hey,

On Tue, Oct 14, 2025 at 05:10:05PM +0200, Nicolas Frattaroli wrote:
> The MediaTek MT8196 SoC contains the same UFS host controller interface
> hardware as the MT8195 SoC. Add it as a variant of MT8195, and extend
> its list of allowed clocks, as well as give it the previously absent
> resets property.
> 
> Also add examples for both MT8195 and the new MT8196, so that the
> binding can be verified against examples for these two variants.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  .../devicetree/bindings/ufs/mediatek,ufs.yaml      | 134 +++++++++++++++++++--
>  1 file changed, 123 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> index 1dec54fb00f3..070ae0982591 100644
> --- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> @@ -11,18 +11,30 @@ maintainers:
>  
>  properties:
>    compatible:
> -    enum:
> -      - mediatek,mt8183-ufshci
> -      - mediatek,mt8192-ufshci
> -      - mediatek,mt8195-ufshci
> +    oneOf:
> +      - enum:
> +          - mediatek,mt8183-ufshci
> +          - mediatek,mt8195-ufshci
> +      - items:
> +          - enum:
> +              - mediatek,mt8192-ufshci
> +          - const: mediatek,mt8183-ufshci

It's hard to follow what's going on in this commit.
Firstly, this seems to be some sort of unrelated change that isn't
mentioned in the commit message.

> +      - items:
> +          - enum:
> +              - mediatek,mt8196-ufshci
> +          - const: mediatek,mt8195-ufshci
>  
>    clocks:
>      minItems: 1
> -    maxItems: 8
> +    maxItems: 16
>  
>    clock-names:
>      minItems: 1
> -    maxItems: 8
> +    maxItems: 16

Then all devices grow 8 more permitted clocks, despite the wording in
the commit message being 8195 specific. (Hint: you missed maxItems: 8 in
the else)

> +
> +  freq-table-hz: true

Then you add this deprecated property, which isn't mentioned in the
commit message and I don't see why a deprecated property is needed.

> +
> +  interrupts: true
>  
>    phys:
>      maxItems: 1
> @@ -30,7 +42,15 @@ properties:
>    reg:
>      maxItems: 1
>  
> +  resets:
> +    maxItems: 3
> +
> +  reset-names:
> +    maxItems: 3

You cannot use reset-names if you don't define what the names are.
Please provide a items list with descriptions in resets and some
names in reset-names.

>    vcc-supply: true
> +  vccq-supply: true
> +  vccq2-supply: true

And then two new supplies that are not mentioned in the commit message,
and again are allowed for all variants. The commit message talks about
extended 8195 features, so this is starting to look like there was some
sort of squashing accident.

>  
>    mediatek,ufs-disable-mcq:
>      $ref: /schemas/types.yaml#/definitions/flag
> @@ -44,22 +64,19 @@ required:
>    - reg
>    - vcc-supply
>  
> -unevaluatedProperties: false
> -
>  allOf:
>    - $ref: ufs-common.yaml
> -
>    - if:
>        properties:
>          compatible:
>            contains:
> -            enum:
> -              - mediatek,mt8195-ufshci
> +            const: mediatek,mt8195-ufshci

The commit message says:
| hardware as the MT8195 SoC. Add it as a variant of MT8195, and extend
| its list of allowed clocks, as well as give it the previously absent
| resets property.

I don't know if that's meant to mean that only the new device has 16 and
the 8195 only has 8, or if the 8195 should have had 16 possible clocks
too.

>      then:
>        properties:
>          clocks:
>            minItems: 8
>          clock-names:
> +          minItems: 8
>            items:
>              - const: ufs
>              - const: ufs_aes
> @@ -69,6 +86,19 @@ allOf:
>              - const: unipro_mp_bclk
>              - const: ufs_tx_symbol
>              - const: ufs_mem_sub
> +            - const: crypt_mux
> +            - const: crypt_lp
> +            - const: crypt_perf
> +            - const: ufs_sel
> +            - const: ufs_sel_min_src
> +            - const: ufs_sel_max_src
> +            - const: ufs_rx_symbol0
> +            - const: ufs_rx_symbol1
> +        reset-names:
> +          items:
> +            - const: unipro_rst
> +            - const: crypto_rst
> +            - const: hci_rst
>      else:
>        properties:
>          clocks:
> @@ -76,6 +106,10 @@ allOf:
>          clock-names:
>            items:
>              - const: ufs
> +        resets: false
> +        reset-names: false
> +
> +unevaluatedProperties: false
>  
>  examples:
>    - |
> @@ -99,3 +133,81 @@ examples:
>              vcc-supply = <&mt_pmic_vemc_ldo_reg>;
>          };
>      };
> +  - |
> +    ufshci@11270000 {
> +        compatible = "mediatek,mt8195-ufshci";
> +        reg = <0x11270000 0x2300>;
> +        interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
> +        phys = <&ufsphy>;
> +        clocks = <&infracfg_ao 63>, <&infracfg_ao 64>, <&infracfg_ao 65>,
> +                 <&infracfg_ao 54>, <&infracfg_ao 55>,
> +                 <&infracfg_ao 56>, <&infracfg_ao 90>,
> +                 <&infracfg_ao 93>;
> +        clock-names = "ufs", "ufs_aes", "ufs_tick",
> +                      "unipro_sysclk", "unipro_tick",
> +                      "unipro_mp_bclk", "ufs_tx_symbol",
> +                      "ufs_mem_sub";
> +        freq-table-hz = <0 0>, <0 0>, <0 0>,
> +                        <0 0>, <0 0>, <0 0>,
> +                        <0 0>, <0 0>;
> +        vcc-supply = <&mt6359_vemc_1_ldo_reg>;
> +        mediatek,ufs-disable-mcq;
> +    };
> +  - |
> +    #include <dt-bindings/reset/mediatek,mt8196-resets.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    ufshci@16810000 {
> +        compatible = "mediatek,mt8196-ufshci", "mediatek,mt8195-ufshci";
> +        reg = <0x16810000 0x2a00>;
> +        interrupts = <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>;
> +
> +        clocks = <&ufs_ao_clk 6>,
> +                 <&ufs_ao_clk 7>,
> +                 <&clk26m>,
> +                 <&ufs_ao_clk 3>,
> +                 <&clk26m>,
> +                 <&ufs_ao_clk 4>,
> +                 <&ufs_ao_clk 0>,
> +                 <&topckgen 7>,
> +                 <&topckgen 41>,
> +                 <&topckgen 105>,
> +                 <&topckgen 83>,
> +                 <&topckgen 42>,
> +                 <&topckgen 84>,
> +                 <&topckgen 102>,
> +                 <&ufs_ao_clk 1>,
> +                 <&ufs_ao_clk 2>;
> +        clock-names = "ufs",
> +                      "ufs_aes",
> +                      "ufs_tick",
> +                      "unipro_sysclk",
> +                      "unipro_tick",
> +                      "unipro_mp_bclk",
> +                      "ufs_tx_symbol",
> +                      "ufs_mem_sub",
> +                      "crypt_mux",
> +                      "crypt_lp",
> +                      "crypt_perf",
> +                      "ufs_sel",
> +                      "ufs_sel_min_src",
> +                      "ufs_sel_max_src",
> +                      "ufs_rx_symbol0",
> +                      "ufs_rx_symbol1";
> +
> +        freq-table-hz = <273000000 499200000>, <0 0>, <0 0>, <0 0>, <0 0>,
> +                        <0 0>, <0 0>, <0 0>, <0 0>, <0 0>, <0 0>, <0 0>, <0 0>,
> +                        <0 0>;
> +
> +        phys = <&ufsphy>;
> +
> +        vcc-supply = <&mt6363_vemc>;
> +        vccq-supply = <&mt6363_vufs12>;
> +        vccq2-supply = <&mt6363_vufs18>;
> +
> +        resets = <&ufs_ao_clk MT8196_UFSAO_RST1_UFS_UNIPRO>,
> +                 <&ufs_ao_clk MT8196_UFSAO_RST1_UFS_CRYPTO>,
> +                 <&ufs_ao_clk MT8196_UFSAO_RST1_UFSHCI>;
> +        reset-names = "unipro_rst", "crypto_rst", "hci_rst";

Putting _rst in the name of a reset is redundant.

pw-bot: changes-requested

Thanks,
Conor.
> +        mediatek,ufs-disable-mcq;
> +    };
> 
> -- 
> 2.51.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2025-10-16 16:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14 15:10 [PATCH 0/5] MediaTek UFS Cleanup and MT8196 Enablement Nicolas Frattaroli
2025-10-14 15:10 ` [PATCH 1/5] dt-bindings: ufs: mediatek,ufs: Add mt8196-ufshci variant Nicolas Frattaroli
2025-10-16  2:59   ` Peter Wang (王信友)
2025-10-16  3:15     ` Peter Wang (王信友)
2025-10-16 16:53   ` Conor Dooley [this message]
2025-10-16 16:54     ` Conor Dooley
2025-10-14 15:10 ` [PATCH 2/5] dt-bindings: phy: Add mediatek,mt8196-ufsphy variant Nicolas Frattaroli
2025-10-17  6:51   ` Peter Wang (王信友)
2025-10-14 15:10 ` [PATCH 3/5] scsi: ufs: mediatek: Move MTK_SIP_UFS_CONTROL to mtk_sip_svc.h Nicolas Frattaroli
2025-10-16  3:42   ` Peter Wang (王信友)
2025-10-14 15:10 ` [PATCH 4/5] phy: mediatek: ufs: Add support for resets Nicolas Frattaroli
2025-10-15 10:07   ` Philipp Zabel
2025-10-14 15:10 ` [PATCH 5/5] scsi: ufs: mediatek: Rework resets Nicolas Frattaroli
2025-10-15 10:07   ` Philipp Zabel
2025-10-15  8:25 ` [PATCH 0/5] MediaTek UFS Cleanup and MT8196 Enablement AngeloGioacchino Del Regno

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=20251016-kettle-clobber-2558d9c709de@spud \
    --to=conor@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=alim.akhtar@samsung.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=chu.stanley@gmail.com \
    --cc=chunfeng.yun@mediatek.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@collabora.com \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=louisalexis.eyraud@collabora.com \
    --cc=martin.petersen@oracle.com \
    --cc=matthias.bgg@gmail.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=p.zabel@pengutronix.de \
    --cc=peter.wang@mediatek.com \
    --cc=robh@kernel.org \
    --cc=stanley.chu@mediatek.com \
    --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