[PATCH v2 1/4] scsi: ufs: ufs-mediatek: Add UFS host support for MT8195 SoC

[PATCH v2 1/4] scsi: ufs: ufs-mediatek: Add UFS host support for MT8195 SoC

[Macpaul Lin]

Add "mediatek,mt8195-ufshci" to the of_device_id table to enable
support for MediaTek MT8195/MT8395 UFS host controller. This matches the
device node entry in the MT8195/MT8395 device tree and allows proper driver
binding.

Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
---
 drivers/ufs/host/ufs-mediatek.c | 1 +
 1 file changed, 1 insertion(+)

Changes vor f2:
 - No change.

diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-mediatek.c
index 182f58d0c9db..e1dbf0231c5e 100644
--- a/drivers/ufs/host/ufs-mediatek.c
+++ b/drivers/ufs/host/ufs-mediatek.c
@@ -50,6 +50,7 @@ static const struct ufs_dev_quirk ufs_mtk_dev_fixups[] = {
 
 static const struct of_device_id ufs_mtk_of_match[] = {
 	{ .compatible = "mediatek,mt8183-ufshci" },
+	{ .compatible = "mediatek,mt8195-ufshci" },
 	{},
 };
 MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);
-- 
2.45.2

[PATCH v2 2/4] dt-bindings: ufs: mediatek,ufs: add ufs-disable-mcq flag for UFS host

[Macpaul Lin]

Add the 'mediatek,ufs-disable-mcq' property to the UFS device-tree
bindings. This flag corresponds to the UFS_MTK_CAP_DISABLE_MCQ host
capability recently introduced in the UFS host driver, allowing it
to disable the Multiple Circular Queue (MCQ) feature when present.
The binding schema has also been updated to resolve DTBS check errors.

Cc: stable@vger.kernel.org
Fixes: 46bd3e31d74b ("scsi: ufs: mediatek: Add UFS_MTK_CAP_DISABLE_MCQ")
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
---
 Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml | 4 ++++
 1 file changed, 4 insertions(+)

Changes for v2:
 - Split new property from the origin patch.
 - Add dependency description. Since the code in ufs-mediatek.c
   has been backport to stable tree. The dt-bindings should be backport
   to the same stable tree as well.

diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
index 32fd535a514a..20f341d25ebc 100644
--- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
@@ -33,6 +33,10 @@ properties:
 
   vcc-supply: true
 
+  mediatek,ufs-disable-mcq:
+    $ref: /schemas/types.yaml#/definitions/flag
+    description: The mask to disable MCQ (Multi-Circular Queue) for UFS host.
+
 required:
   - compatible
   - clocks
-- 
2.45.2

Re: [PATCH v2 2/4] dt-bindings: ufs: mediatek,ufs: add ufs-disable-mcq flag for UFS host

[Rob Herring (Arm)]

On Tue, 22 Jul 2025 16:57:18 +0800, Macpaul Lin wrote:
> Add the 'mediatek,ufs-disable-mcq' property to the UFS device-tree
> bindings. This flag corresponds to the UFS_MTK_CAP_DISABLE_MCQ host
> capability recently introduced in the UFS host driver, allowing it
> to disable the Multiple Circular Queue (MCQ) feature when present.
> The binding schema has also been updated to resolve DTBS check errors.
> 
> Cc: stable@vger.kernel.org
> Fixes: 46bd3e31d74b ("scsi: ufs: mediatek: Add UFS_MTK_CAP_DISABLE_MCQ")
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> Changes for v2:
>  - Split new property from the origin patch.
>  - Add dependency description. Since the code in ufs-mediatek.c
>    has been backport to stable tree. The dt-bindings should be backport
>    to the same stable tree as well.
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Re: [PATCH v2 2/4] dt-bindings: ufs: mediatek,ufs: add ufs-disable-mcq flag for UFS host

[Peter Wang (王信友)]

On Tue, 2025-07-22 at 16:57 +0800, Macpaul Lin wrote:
> Add the 'mediatek,ufs-disable-mcq' property to the UFS device-tree
> bindings. This flag corresponds to the UFS_MTK_CAP_DISABLE_MCQ host
> capability recently introduced in the UFS host driver, allowing it
> to disable the Multiple Circular Queue (MCQ) feature when present.
> The binding schema has also been updated to resolve DTBS check
> errors.
> 
> Cc: stable@vger.kernel.org
> Fixes: 46bd3e31d74b ("scsi: ufs: mediatek: Add
> UFS_MTK_CAP_DISABLE_MCQ")
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> Changes for v2:
>  - Split new property from the origin patch.
>  - Add dependency description. Since the code in ufs-mediatek.c
>    has been backport to stable tree. The dt-bindings should be
> backport
>    to the same stable tree as well.
> 
> diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> index 32fd535a514a..20f341d25ebc 100644
> --- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> @@ -33,6 +33,10 @@ properties:
>  
>    vcc-supply: true
>  
> +  mediatek,ufs-disable-mcq:
> +    $ref: /schemas/types.yaml#/definitions/flag
> +    description: The mask to disable MCQ (Multi-Circular Queue) for
> UFS host.
> +
>  required:
>    - compatible
>    - clocks

Reviewed-by: Peter Wang <peter.wang@mediatek.com>

[PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Macpaul Lin]

Add MT8195 UFSHCI compatible string.
Relax the schema to allow between one to eight clocks/clock-names
entries for all MediaTek UFS nodes. Legacy platforms may only need
a few clocks, whereas newer devices such as the MT8195 require
additional clock-gating domains. For MT8195 specifically, enforce
exactly eight clocks and clock-names entries to satisfy its hardware
requirements.

Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
---
 .../devicetree/bindings/ufs/mediatek,ufs.yaml | 42 ++++++++++++++++---
 1 file changed, 36 insertions(+), 6 deletions(-)

Changes for v2:
 - Remove duplicate minItems and maxItems as suggested in the review.
 - Add a description of how the MT8195 hardware differs from earlier
   platforms.

diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
index 20f341d25ebc..1dec54fb00f3 100644
--- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
+++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
@@ -9,21 +9,20 @@ title: Mediatek Universal Flash Storage (UFS) Controller
 maintainers:
   - Stanley Chu <stanley.chu@mediatek.com>
 
-allOf:
-  - $ref: ufs-common.yaml
-
 properties:
   compatible:
     enum:
       - mediatek,mt8183-ufshci
       - mediatek,mt8192-ufshci
+      - mediatek,mt8195-ufshci
 
   clocks:
-    maxItems: 1
+    minItems: 1
+    maxItems: 8
 
   clock-names:
-    items:
-      - const: ufs
+    minItems: 1
+    maxItems: 8
 
   phys:
     maxItems: 1
@@ -47,6 +46,37 @@ required:
 
 unevaluatedProperties: false
 
+allOf:
+  - $ref: ufs-common.yaml
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - mediatek,mt8195-ufshci
+    then:
+      properties:
+        clocks:
+          minItems: 8
+        clock-names:
+          items:
+            - const: ufs
+            - const: ufs_aes
+            - const: ufs_tick
+            - const: unipro_sysclk
+            - const: unipro_tick
+            - const: unipro_mp_bclk
+            - const: ufs_tx_symbol
+            - const: ufs_mem_sub
+    else:
+      properties:
+        clocks:
+          maxItems: 1
+        clock-names:
+          items:
+            - const: ufs
+
 examples:
   - |
     #include <dt-bindings/clock/mt8183-clk.h>
-- 
2.45.2

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[AngeloGioacchino Del Regno]

Il 22/07/25 10:57, Macpaul Lin ha scritto:
> Add MT8195 UFSHCI compatible string.
> Relax the schema to allow between one to eight clocks/clock-names
> entries for all MediaTek UFS nodes. Legacy platforms may only need
> a few clocks, whereas newer devices such as the MT8195 require
> additional clock-gating domains. For MT8195 specifically, enforce
> exactly eight clocks and clock-names entries to satisfy its hardware
> requirements.
> 
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>   .../devicetree/bindings/ufs/mediatek,ufs.yaml | 42 ++++++++++++++++---
>   1 file changed, 36 insertions(+), 6 deletions(-)
> 
> Changes for v2:
>   - Remove duplicate minItems and maxItems as suggested in the review.
>   - Add a description of how the MT8195 hardware differs from earlier
>     platforms.
> 
> diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> index 20f341d25ebc..1dec54fb00f3 100644
> --- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> +++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> @@ -9,21 +9,20 @@ title: Mediatek Universal Flash Storage (UFS) Controller
>   maintainers:
>     - Stanley Chu <stanley.chu@mediatek.com>
>   
> -allOf:
> -  - $ref: ufs-common.yaml
> -
>   properties:
>     compatible:
>       enum:
>         - mediatek,mt8183-ufshci
>         - mediatek,mt8192-ufshci
> +      - mediatek,mt8195-ufshci
>   
>     clocks:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 8
>   
>     clock-names:
> -    items:
> -      - const: ufs
> +    minItems: 1
> +    maxItems: 8
>   
>     phys:
>       maxItems: 1
> @@ -47,6 +46,37 @@ required:
>   
>   unevaluatedProperties: false
>   
> +allOf:
> +  - $ref: ufs-common.yaml
> +
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - mediatek,mt8195-ufshci
> +    then:
> +      properties:
> +        clocks:
> +          minItems: 8
> +        clock-names:
> +          items:
> +            - const: ufs
> +            - const: ufs_aes
> +            - const: ufs_tick
> +            - const: unipro_sysclk
> +            - const: unipro_tick
> +            - const: unipro_mp_bclk

The unipro mp_bclk really is the ufs-sap clock; besides, the standard has clocks
for both TX and RX symbols - and also MT8195 (and also MT6991, MT8196, and others)
UFS controller do have both TX and RX symbol clocks.

Besides, you're also missing the crypto clocks for UFS, which brings the count to
12 total clocks for MT8195.

Please, look at my old submission, which actually fixes the compatibles other than
adding the right clocks for all UFS controllers in MediaTek platforms.

https://lore.kernel.org/all/20240612074309.50278-1-angelogioacchino.delregno@collabora.com/

I want to take the occasion to remind everyone that my fixes were discarded because
the MediaTek UFS driver maintainer wants to keep the low quality of the driver in
favor of easier downstream porting - which is *not* in any way adhering to quality
standards that the Linux community deserves.

Cheers,
Angelo

> +            - const: ufs_tx_symbol
> +            - const: ufs_mem_sub
> +    else:
> +      properties:
> +        clocks:
> +          maxItems: 1
> +        clock-names:
> +          items:
> +            - const: ufs
> +
>   examples:
>     - |
>       #include <dt-bindings/clock/mt8183-clk.h>

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Rob Herring]

On Tue, Jul 22, 2025 at 11:39:54AM +0200, AngeloGioacchino Del Regno wrote:
> Il 22/07/25 10:57, Macpaul Lin ha scritto:
> > Add MT8195 UFSHCI compatible string.
> > Relax the schema to allow between one to eight clocks/clock-names
> > entries for all MediaTek UFS nodes. Legacy platforms may only need
> > a few clocks, whereas newer devices such as the MT8195 require
> > additional clock-gating domains. For MT8195 specifically, enforce
> > exactly eight clocks and clock-names entries to satisfy its hardware
> > requirements.
> > 
> > Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> > ---
> >   .../devicetree/bindings/ufs/mediatek,ufs.yaml | 42 ++++++++++++++++---
> >   1 file changed, 36 insertions(+), 6 deletions(-)
> > 
> > Changes for v2:
> >   - Remove duplicate minItems and maxItems as suggested in the review.
> >   - Add a description of how the MT8195 hardware differs from earlier
> >     platforms.
> > 
> > diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> > index 20f341d25ebc..1dec54fb00f3 100644
> > --- a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> > +++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml
> > @@ -9,21 +9,20 @@ title: Mediatek Universal Flash Storage (UFS) Controller
> >   maintainers:
> >     - Stanley Chu <stanley.chu@mediatek.com>
> > -allOf:
> > -  - $ref: ufs-common.yaml
> > -
> >   properties:
> >     compatible:
> >       enum:
> >         - mediatek,mt8183-ufshci
> >         - mediatek,mt8192-ufshci
> > +      - mediatek,mt8195-ufshci
> >     clocks:
> > -    maxItems: 1
> > +    minItems: 1
> > +    maxItems: 8
> >     clock-names:
> > -    items:
> > -      - const: ufs
> > +    minItems: 1
> > +    maxItems: 8
> >     phys:
> >       maxItems: 1
> > @@ -47,6 +46,37 @@ required:
> >   unevaluatedProperties: false
> > +allOf:
> > +  - $ref: ufs-common.yaml
> > +
> > +  - if:
> > +      properties:
> > +        compatible:
> > +          contains:
> > +            enum:
> > +              - mediatek,mt8195-ufshci
> > +    then:
> > +      properties:
> > +        clocks:
> > +          minItems: 8
> > +        clock-names:
> > +          items:
> > +            - const: ufs
> > +            - const: ufs_aes
> > +            - const: ufs_tick
> > +            - const: unipro_sysclk
> > +            - const: unipro_tick
> > +            - const: unipro_mp_bclk
> 
> The unipro mp_bclk really is the ufs-sap clock; besides, the standard has clocks
> for both TX and RX symbols - and also MT8195 (and also MT6991, MT8196, and others)
> UFS controller do have both TX and RX symbol clocks.
> 
> Besides, you're also missing the crypto clocks for UFS, which brings the count to
> 12 total clocks for MT8195.
> 
> Please, look at my old submission, which actually fixes the compatibles other than
> adding the right clocks for all UFS controllers in MediaTek platforms.
> 
> https://lore.kernel.org/all/20240612074309.50278-1-angelogioacchino.delregno@collabora.com/
> 
> I want to take the occasion to remind everyone that my fixes were discarded because
> the MediaTek UFS driver maintainer wants to keep the low quality of the driver in
> favor of easier downstream porting - which is *not* in any way adhering to quality
> standards that the Linux community deserves.

Sounds like we need a new maintainer then. They clearly don't understand 
that downstream doesn't exist.

Rob

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Macpaul Lin (林智斌)]

On Tue, 2025-07-22 at 11:39 +0200, AngeloGioacchino Del Regno wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 

[snip...]

> The unipro mp_bclk really is the ufs-sap clock; besides, the standard
> has clocks
> for both TX and RX symbols - and also MT8195 (and also MT6991,
> MT8196, and others)
> UFS controller do have both TX and RX symbol clocks.
> 
> Besides, you're also missing the crypto clocks for UFS, which brings
> the count to
> 12 total clocks for MT8195.
> 
> Please, look at my old submission, which actually fixes the
> compatibles other than
> adding the right clocks for all UFS controllers in MediaTek
> platforms.
> 
> https://lore.kernel.org/all/20240612074309.50278-1-angelogioacchino.delregno@collabora.com/
> 
> I want to take the occasion to remind everyone that my fixes were
> discarded because
> the MediaTek UFS driver maintainer wants to keep the low quality of
> the driver in
> favor of easier downstream porting - which is *not* in any way
> adhering to quality
> standards that the Linux community deserves.
> 

Oops, it is sad to hear that.
MediaTek will raise an internal discussion and hope
we could get the more specific requirements back to you soon.

> Cheers,
> Angelo

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[AngeloGioacchino Del Regno]

Il 23/07/25 09:33, Macpaul Lin (林智斌) ha scritto:
> On Tue, 2025-07-22 at 11:39 +0200, AngeloGioacchino Del Regno wrote:
>>
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>>
> 
> [snip...]
> 
>> The unipro mp_bclk really is the ufs-sap clock; besides, the standard
>> has clocks
>> for both TX and RX symbols - and also MT8195 (and also MT6991,
>> MT8196, and others)
>> UFS controller do have both TX and RX symbol clocks.
>>
>> Besides, you're also missing the crypto clocks for UFS, which brings
>> the count to
>> 12 total clocks for MT8195.
>>
>> Please, look at my old submission, which actually fixes the
>> compatibles other than
>> adding the right clocks for all UFS controllers in MediaTek
>> platforms.
>>
>> https://lore.kernel.org/all/20240612074309.50278-1-angelogioacchino.delregno@collabora.com/
>>
>> I want to take the occasion to remind everyone that my fixes were
>> discarded because
>> the MediaTek UFS driver maintainer wants to keep the low quality of
>> the driver in
>> favor of easier downstream porting - which is *not* in any way
>> adhering to quality
>> standards that the Linux community deserves.
>>
> 
> Oops, it is sad to hear that.
> MediaTek will raise an internal discussion and hope
> we could get the more specific requirements back to you soon.
> 

Thanks for that.

Cheers,
Angelo

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Peter Wang (王信友)]

On Tue, 2025-07-22 at 11:39 +0200, AngeloGioacchino Del Regno wrote:
> 
> The unipro mp_bclk really is the ufs-sap clock; besides, the standard
> has clocks
> for both TX and RX symbols - and also MT8195 (and also MT6991,
> MT8196, and others)
> UFS controller do have both TX and RX symbol clocks.
> 
> Besides, you're also missing the crypto clocks for UFS, which brings
> the count to
> 12 total clocks for MT8195.

> Please, look at my old submission, which actually fixes the
> compatibles other than
> adding the right clocks for all UFS controllers in MediaTek
> platforms.
> 
> https://lore.kernel.org/all/20240612074309.50278-1-angelogioacchino.delregno@collabora.com/
> 

Hi Angelo,

The clock architecture may vary depending on the platform.
These clock patch look good to me.


> I want to take the occasion to remind everyone that my fixes were
> discarded because
> the MediaTek UFS driver maintainer wants to keep the low quality of
> the driver in
> favor of easier downstream porting - which is *not* in any way
> adhering to quality
> standards that the Linux community deserves.
> 
> Cheers,
> Angelo

I want to clarify that I am not opposing this in order to keep the 
low quality of the driver for the sake of easier downstream porting.
My objection is purely due to the quality of this patch:
https://lore.kernel.org/all/eb47587159484abca8e6d65dddcf0844822ce99f.camel@mediatek.com/
Originally, this could have been a simple matter handled by a single
DTS setting,
but this patch requires checking a bunch of DTS voltage settings.
This increases the complexity of the boot process, and I don't see any
benefit from it.

Even though I think the other patches look good to me, I haven't seen
any new ones uploaded.
I would like to reiterate that I welcome any upstream contributions
related to Linux UFS on MediaTek platforms.

Thanks
Peter

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Krzysztof Kozlowski]

On 23/07/2025 11:41, Peter Wang (王信友) wrote:
>> Please, look at my old submission, which actually fixes the
>> compatibles other than
>> adding the right clocks for all UFS controllers in MediaTek
>> platforms.
>>
>> https://lore.kernel.org/all/20240612074309.50278-1-angelogioacchino.delregno@collabora.com/
>>
> 
> Hi Angelo,
> 
> The clock architecture may vary depending on the platform.
> These clock patch look good to me.
> 
> 
>> I want to take the occasion to remind everyone that my fixes were
>> discarded because
>> the MediaTek UFS driver maintainer wants to keep the low quality of
>> the driver in
>> favor of easier downstream porting - which is *not* in any way
>> adhering to quality
>> standards that the Linux community deserves.
>>
>> Cheers,
>> Angelo
> 
> I want to clarify that I am not opposing this in order to keep the 
> low quality of the driver for the sake of easier downstream porting.

You did.

You wrote very clearly here:
https://lore.kernel.org/all/eb47587159484abca8e6d65dddcf0844822ce99f.camel@mediatek.com/

"In addition, it will require MediaTek to put in extra
effort to migrate the kernel. "


Also you wrote:
"The role of MediaTek UFS maintainer is not suitable to be handed over
to someone outside of MediaTek."

https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/

Holy molly, you really wrote this!

That's completely unacceptable. You don't understand how upstream
development works and you push your downstream narrative which for us
does not matter. You also object community led efforts, because you
apparently want to control the upstream process.

That is red flag.

I think you should step down from maintainer position and find more
suitable person, who is willing to work with the community, or rethink
how upstream process works and understand that your downstream goals do
not matter completely.

I will be watching closely this and if situation does not improve, I
believe we should mark the driver orphaned until we find maintainer
caring about community, not about corporate goals.

Best regards,
Krzysztof

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Peter Wang (王信友)]

On Sun, 2025-10-19 at 12:19 +0200, Krzysztof Kozlowski wrote:
> 
> You did.
> 
> You wrote very clearly here:
> https://lore.kernel.org/all/eb47587159484abca8e6d65dddcf0844822ce99f.camel@mediatek.com/
> 
> "In addition, it will require MediaTek to put in extra
> effort to migrate the kernel. "
> 

Hi Krzysztof Kozlowski,

The main reason for my objection was also clearly stated:
"removing these DTS settings will make what was originally
a simple task more complicated."
I’m not sure if you are quoting only the "In addition"
part to take it out of context?



> 
> Also you wrote:
> "The role of MediaTek UFS maintainer is not suitable to be handed
> over
> to someone outside of MediaTek."
> 
> https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/
> 
> Holy molly, you really wrote this!
> 

"The role of MediaTek UFS maintainer is not suitable to be handed
over to someone outside of MediaTek."
My main point is that MediaTek’s internal personnel certainly 
have a better understanding of the SoC architecture than external
parties.
Wouldn’t it be more appropriate for maintainers to be internal staff?



> That's completely unacceptable. You don't understand how upstream
> development works and you push your downstream narrative which for us
> does not matter. You also object community led efforts, because you
> apparently want to control the upstream process.
> 

I don’t see how this relates to upstream/downstream?
Aren’t you reading too much into this? My objection is purely
because I don’t want to complicate a simple matter, not 
because I object to community-led efforts.
Please don’t misunderstand my intention.



> That is red flag.
> 
> I think you should step down from maintainer position and find more
> suitable person, who is willing to work with the community, or
> rethink
> how upstream process works and understand that your downstream goals
> do
> not matter completely.
> 
> I will be watching closely this and if situation does not improve, I
> believe we should mark the driver orphaned until we find maintainer
> caring about community, not about corporate goals.
> 
> Best regards,
> Krzysztof


Mediatek will add a few more maintainers internally,

Thanks
Peter

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Krzysztof Kozlowski]

On 20/10/2025 10:13, Peter Wang (王信友) wrote:
> On Sun, 2025-10-19 at 12:19 +0200, Krzysztof Kozlowski wrote:
>>
>> You did.
>>
>> You wrote very clearly here:
>> https://lore.kernel.org/all/eb47587159484abca8e6d65dddcf0844822ce99f.camel@mediatek.com/
>>
>> "In addition, it will require MediaTek to put in extra
>> effort to migrate the kernel. "
>>
> 
> Hi Krzysztof Kozlowski,
> 
> The main reason for my objection was also clearly stated:
> "removing these DTS settings will make what was originally
> a simple task more complicated."
> I’m not sure if you are quoting only the "In addition"
> part to take it out of context?

It is not out of context. It was the statement on its own.

> 
> 
> 
>>
>> Also you wrote:
>> "The role of MediaTek UFS maintainer is not suitable to be handed
>> over
>> to someone outside of MediaTek."
>>
>> https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/
>>
>> Holy molly, you really wrote this!
>>
> 
> "The role of MediaTek UFS maintainer is not suitable to be handed
> over to someone outside of MediaTek."
> My main point is that MediaTek’s internal personnel certainly 
> have a better understanding of the SoC architecture than external
> parties.
> Wouldn’t it be more appropriate for maintainers to be internal staff?


You denied community to participate and now you twist the argument like
you want Mediatek people to be involved. No one denied Mediatek to be
maintainer.

It is you who denied community to join the maintainers.

This is not acceptable and you still do not understand why.

> 
> 
> 
>> That's completely unacceptable. You don't understand how upstream
>> development works and you push your downstream narrative which for us
>> does not matter. You also object community led efforts, because you
>> apparently want to control the upstream process.
>>
> 
> I don’t see how this relates to upstream/downstream?
> Aren’t you reading too much into this? My objection is purely
> because I don’t want to complicate a simple matter, not 
> because I object to community-led efforts.
> Please don’t misunderstand my intention.


You could apologize and explain your mistakes, but instead you push same
narrative.

Still a red flag. I will not accept such vendor-like behaviors, because
they significantly harm the community.

I am very surprised that UFS maintainers did not object to it. This
should be clearly ostracized.


> 
> 
> 
>> That is red flag.
>>
>> I think you should step down from maintainer position and find more
>> suitable person, who is willing to work with the community, or
>> rethink
>> how upstream process works and understand that your downstream goals
>> do
>> not matter completely.
>>
>> I will be watching closely this and if situation does not improve, I
>> believe we should mark the driver orphaned until we find maintainer
>> caring about community, not about corporate goals.
>>
>> Best regards,
>> Krzysztof
> 
> 
> Mediatek will add a few more maintainers internally,


Consider stepping down and choosing them if they better understand how
upstream works.

As Rob wrote earlier:

"Sounds like we need a new maintainer then. They clearly don't
understand that downstream doesn't exist."


Best regards,
Krzysztof

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Peter Wang (王信友)]

On Mon, 2025-10-20 at 10:28 +0200, Krzysztof Kozlowski wrote:
> > 
> > 
> > Hi Krzysztof Kozlowski,
> > 
> > The main reason for my objection was also clearly stated:
> > "removing these DTS settings will make what was originally
> > a simple task more complicated."
> > I’m not sure if you are quoting only the "In addition"
> > part to take it out of context?
> 
> It is not out of context. It was the statement on its own.

Hi Krzysztof Kozlowski,

However, you haven’t addressed the main reason for my objection.
"removing these DTS settings will make what was originally
a simple task more complicated."

> 
> 
> 
> You denied community to participate and now you twist the argument
> like
> you want Mediatek people to be involved. No one denied Mediatek to be
> maintainer.
> 
> It is you who denied community to join the maintainers.
> 
> This is not acceptable and you still do not understand why.

I think I understand your point now, you believe that opposing
this patch means opposing community participation and support, right?
But it’s clear that you haven’t carefully considered the main 
reason for my objection?



> 
> 
> You could apologize and explain your mistakes, but instead you push
> same
> narrative.
> 
> Still a red flag. I will not accept such vendor-like behaviors,
> because
> they significantly harm the community.
> 
> I am very surprised that UFS maintainers did not object to it. This
> should be clearly ostracized.
> 
> 

Sorry, I still don’t quite understand why having people who
know the SoC better maintain the SoC driver would be considered
harmful to the community?
Also, I still don’t see the relation between opposing the
unnecessary complication patch and the downstream?
Can you tell me why I should accept code that I feel is 
unreasonable to be merged? Instead of repeatedly telling me 
that my objection is about downstream or something like that.


> 
> 
> Consider stepping down and choosing them if they better understand
> how
> upstream works.
> 
> As Rob wrote earlier:
> 
> "Sounds like we need a new maintainer then. They clearly don't
> understand that downstream doesn't exist."
> 
> 
> Best regards,
> Krzysztof

I must reiterate that I do not oppose patches that are 
beneficial to the community; I only object to patches that are 
not helpful.

Thanks
Peter

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Krzysztof Kozlowski]

On 20/10/2025 11:44, Peter Wang (王信友) wrote:
> On Mon, 2025-10-20 at 10:28 +0200, Krzysztof Kozlowski wrote:
>>>
>>>
>>> Hi Krzysztof Kozlowski,
>>>
>>> The main reason for my objection was also clearly stated:
>>> "removing these DTS settings will make what was originally
>>> a simple task more complicated."
>>> I’m not sure if you are quoting only the "In addition"
>>> part to take it out of context?
>>
>> It is not out of context. It was the statement on its own.
> 
> Hi Krzysztof Kozlowski,
> 
> However, you haven’t addressed the main reason for my objection.
> "removing these DTS settings will make what was originally
> a simple task more complicated."


You did not object in technical matter at all here:
https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/

Look at this patch.

You said nothing about actual change, except blocking the community
maintainer. You did not raise any other concerns so what are you
speaking about "other main concerns"?

Even if such existed, they did not matter, because YOU WROTE ONLY:

"The role of MediaTek UFS maintainer is not suitable to be handed over
to someone outside of MediaTek."

This is what we discuss here.

> 
>>
>>
>>
>> You denied community to participate and now you twist the argument
>> like
>> you want Mediatek people to be involved. No one denied Mediatek to be
>> maintainer.
>>
>> It is you who denied community to join the maintainers.
>>
>> This is not acceptable and you still do not understand why.
> 
> I think I understand your point now, you believe that opposing
> this patch means opposing community participation and support, right?

Do you even read your own comments and where did you place them? Do you
understand that we discuss emails, not some unsaid or other threads?

Look at this:

https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/

	
> But it’s clear that you haven’t carefully considered the main 
> reason for my objection?

Main reason for objection? What?

> 
> 
> 
>>
>>
>> You could apologize and explain your mistakes, but instead you push
>> same
>> narrative.
>>
>> Still a red flag. I will not accept such vendor-like behaviors,
>> because
>> they significantly harm the community.
>>
>> I am very surprised that UFS maintainers did not object to it. This
>> should be clearly ostracized.
>>
>>
> 
> Sorry, I still don’t quite understand why having people who
> know the SoC better maintain the SoC driver would be considered
> harmful to the community?

You are twisting the problem, like anyone denied you being the maintainer.

YOU DENIED OTHER PEOPLE!

I finish the discussion here, I am considering your explanations
intentionally twisting the point thus I find it still harmful behavior.

Best regards,
Krzysztof

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Peter Wang (王信友)]

On Mon, 2025-10-20 at 11:56 +0200, Krzysztof Kozlowski wrote:
> 
> On 20/10/2025 11:44, Peter Wang (王信友) wrote:
> > On Mon, 2025-10-20 at 10:28 +0200, Krzysztof Kozlowski wrote:
> > > > 
> > > > 
> > > > Hi Krzysztof Kozlowski,
> > > > 
> > > > The main reason for my objection was also clearly stated:
> > > > "removing these DTS settings will make what was originally
> > > > a simple task more complicated."
> > > > I’m not sure if you are quoting only the "In addition"
> > > > part to take it out of context?
> > > 
> > > It is not out of context. It was the statement on its own.
> > 
> > Hi Krzysztof Kozlowski,
> > 
> > However, you haven’t addressed the main reason for my objection.
> > "removing these DTS settings will make what was originally
> > a simple task more complicated."
> 
> 
> You did not object in technical matter at all here:
> https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/
> 
> Look at this patch.
> 
> You said nothing about actual change, except blocking the community
> maintainer. You did not raise any other concerns so what are you
> speaking about "other main concerns"?
> 
> Even if such existed, they did not matter, because YOU WROTE ONLY:
> 
> "The role of MediaTek UFS maintainer is not suitable to be handed
> over
> to someone outside of MediaTek."
> 
> This is what we discuss here.
> 
> Do you even read your own comments and where did you place them? Do
> you
> understand that we discuss emails, not some unsaid or other threads?
> 
> Look at this:
> 
> https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/
> 
> 
> > But it’s clear that you haven’t carefully considered the main
> > reason for my objection?
> 
> Main reason for objection? What?
> 

Hi Krzysztof Kozlowski,

I think you misunderstood—these are different patches. 
This one only changes the maintainer. What I was referring to 
is another patch that removes parts of the DTS setting.
https://lore.kernel.org/all/eb47587159484abca8e6d65dddcf0844822ce99f.camel@mediatek.com/


I don’t know who AngeloGioacchino is, so isn’t it reasonable for
me to oppose directly changing the maintainer?
Or do you think everyone should know who AngeloGioacchino is 
and just accept this change?


Let’s put it this way: if a strager you don’t know suddenly comes 
to your home and says they’re now the maintainer of your house, 
would you be comfortable with that?



> 
> 
> You are twisting the problem, like anyone denied you being the
> maintainer.
> 
> YOU DENIED OTHER PEOPLE!
> 
> I finish the discussion here, I am considering your explanations
> intentionally twisting the point thus I find it still harmful
> behavior.
> 
> Best regards,
> Krzysztof

I think you’re the one twisting my words.
What I said was that I oppose people OUTSIDE of MediaTek becoming 
maintainers, not that I oppose other people in GENERAL.
In fact, I also mentioned that other MediaTek maintainers
would be joining.


Thanks
Peter

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[AngeloGioacchino Del Regno]

Il 20/10/25 12:46, Peter Wang (王信友) ha scritto:
> On Mon, 2025-10-20 at 11:56 +0200, Krzysztof Kozlowski wrote:
>>
>> On 20/10/2025 11:44, Peter Wang (王信友) wrote:
>>> On Mon, 2025-10-20 at 10:28 +0200, Krzysztof Kozlowski wrote:
>>>>>
>>>>>
>>>>> Hi Krzysztof Kozlowski,
>>>>>
>>>>> The main reason for my objection was also clearly stated:
>>>>> "removing these DTS settings will make what was originally
>>>>> a simple task more complicated."
>>>>> I’m not sure if you are quoting only the "In addition"
>>>>> part to take it out of context?
>>>>
>>>> It is not out of context. It was the statement on its own.
>>>
>>> Hi Krzysztof Kozlowski,
>>>
>>> However, you haven’t addressed the main reason for my objection.
>>> "removing these DTS settings will make what was originally
>>> a simple task more complicated."
>>
>>
>> You did not object in technical matter at all here:
>> https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/
>>
>> Look at this patch.
>>
>> You said nothing about actual change, except blocking the community
>> maintainer. You did not raise any other concerns so what are you
>> speaking about "other main concerns"?
>>
>> Even if such existed, they did not matter, because YOU WROTE ONLY:
>>
>> "The role of MediaTek UFS maintainer is not suitable to be handed
>> over
>> to someone outside of MediaTek."
>>
>> This is what we discuss here.
>>
>> Do you even read your own comments and where did you place them? Do
>> you
>> understand that we discuss emails, not some unsaid or other threads?
>>
>> Look at this:
>>
>> https://lore.kernel.org/all/ce0f9785f8f488010cd81adbbdb5ac07742fc988.camel@mediatek.com/
>>
>>
>>> But it’s clear that you haven’t carefully considered the main
>>> reason for my objection?
>>
>> Main reason for objection? What?
>>
> 
> Hi Krzysztof Kozlowski,
> 
> I think you misunderstood—these are different patches.
> This one only changes the maintainer. What I was referring to
> is another patch that removes parts of the DTS setting.
> https://lore.kernel.org/all/eb47587159484abca8e6d65dddcf0844822ce99f.camel@mediatek.com/
> 
> 
> I don’t know who AngeloGioacchino is,

Sorry Peter, but a 10 seconds research on your side would have made you aware of
who I am.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS?h=v6.6#n2346

...then a 60 seconds research would reveal way more than just that about me,
and also your colleagues know me quite a bit :-)

Besides, you don't really need to know who somebody is to make an upstream review:
this is a community, and a good patch may come from old and recognized contributors
as much as from new ones sending their first patch upstream.

> so isn’t it reasonable for
> me to oppose directly changing the maintainer?
> Or do you think everyone should know who AngeloGioacchino is
> and just accept this change?
> 
> 
> Let’s put it this way: if a strager you don’t know suddenly comes
> to your home and says they’re now the maintainer of your house,
> would you be comfortable with that?
> 
> 
> 
>>
>>
>> You are twisting the problem, like anyone denied you being the
>> maintainer.
>>
>> YOU DENIED OTHER PEOPLE!
>>
>> I finish the discussion here, I am considering your explanations
>> intentionally twisting the point thus I find it still harmful
>> behavior.

Krzysztof, many thanks for taking time to defend the community.

Regards,
Angelo

>>
>> Best regards,
>> Krzysztof
> 
> I think you’re the one twisting my words.
> What I said was that I oppose people OUTSIDE of MediaTek becoming
> maintainers, not that I oppose other people in GENERAL.
> In fact, I also mentioned that other MediaTek maintainers
> would be joining.
> 
> 
> Thanks
> Peter
> 
> 

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Peter Wang (王信友)]

On Mon, 2025-10-20 at 13:04 +0200, AngeloGioacchino Del Regno wrote:
> 
> 
> Sorry Peter, but a 10 seconds research on your side would have made
> you aware of
> who I am.
> 
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/MAINTAINERS?h=v6.6*n2346__;Iw!!CTRNKA9wMg0ARbw!j46OdEicZdlCQk4DoUc9bC32inkXJnyn4mTFypGGCK_bH1CJlW4Et75egmmKPBOgf3SHcPJTdX_vt7w_hp82-lkypdUcP32s$
> 
> ...then a 60 seconds research would reveal way more than just that
> about me,
> and also your colleagues know me quite a bit :-)

Hi AngeloGioacchino,

Yes, however, I was not aware of this when I responded last year.
There have been internal discussions since then, and we have 
decided that new MediaTek maintainers will be added.
This position is still not appropriate for someone external
to MediaTek. I hope for your understanding.


> 
> Besides, you don't really need to know who somebody is to make an
> upstream review:
> this is a community, and a good patch may come from old and
> recognized contributors
> as much as from new ones sending their first patch upstream.
> 
> 
> 

I agree with your point, perhaps we simply have different 
viewpoints, but our goal is the same—to make this community better.
If there are any shortcomings in our ideas, we can discuss 
them and focus on the patch itself, rather than resorting to 
blanket criticisms such as labeling downstream as low quality 
or upstream as inherently superior.
Such remarks do not contribute to the improvement of the community.

Thanks
Peter

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Krzysztof Kozlowski]

On 20/10/2025 11:44, Peter Wang (王信友) wrote:
>>
>> Consider stepping down and choosing them if they better understand
>> how
>> upstream works.
>>
>> As Rob wrote earlier:
>>
>> "Sounds like we need a new maintainer then. They clearly don't
>> understand that downstream doesn't exist."
>>
>>
>> Best regards,
>> Krzysztof
> 
> I must reiterate that I do not oppose patches that are 
> beneficial to the community; I only object to patches that are 
> not helpful.


Let's quote you again:

"*In addition*, it will require MediaTek to put in extra
effort to migrate the kernel. "

This is ADDITIONAL argument you used. This is what you wrote, this is
what you claimed to be ADDITIONAL argument.

In your opinion ADDITIONAL argument is downstream and you still do not
understand why such argument is instant NAK for you as reviewer.


Best regards,
Krzysztof

Re: [PATCH v2 3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes

[Peter Wang (王信友)]

On Mon, 2025-10-20 at 12:02 +0200, Krzysztof Kozlowski wrote:
> 
> Let's quote you again:
> 
> "*In addition*, it will require MediaTek to put in extra
> effort to migrate the kernel. "
> 
> This is ADDITIONAL argument you used. This is what you wrote, this is
> what you claimed to be ADDITIONAL argument.
> 
> In your opinion ADDITIONAL argument is downstream and you still do
> not
> understand why such argument is instant NAK for you as reviewer.
> 
> 
> Best regards,
> Krzysztof

Hi Krzysztof Kozlowski,

I acknowledge that this was indeed a lack of consideration 
on my part, and I must apologize for making such statements.
Nevertheless, I have also clarified that this was not the main
reason for my objection, the actual reason is
"removing these DTS settings will make what was originally
a simple task more complicated."
And then, when I asked you about the main reason and its 
relation to downstream, you just kept repeating “ADDITIONAL.”
Why not address the issue directly and tell me what the 
benefit is of making the code more complicated?

Thanks
Peter

[PATCH v2 4/4] arm64: dts: mediatek: mt8195: add UFSHCI node

[Macpaul Lin]

From: Rice Lee <ot_riceyj.lee@mediatek.com>

Add a UFS host controller interface (UFSHCI) node to mt8195.dtsi.
Introduce the 'mediatek,ufs-disable-mcq' property to allow disabling
Multiple Circular Queue (MCQ) support.

Signed-off-by: Rice Lee <ot_riceyj.lee@mediatek.com>
Signed-off-by: Eric Lin <ht.lin@mediatek.com>
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt8195.dtsi | 25 ++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

Changes for v2:
 - No change.

diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index dd065b1bf94a..8877953ce292 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
@@ -1430,6 +1430,31 @@ mmc2: mmc@11250000 {
 			status = "disabled";
 		};
 
+		ufshci: ufshci@11270000 {
+			compatible = "mediatek,mt8195-ufshci";
+			reg = <0 0x11270000 0 0x2300>;
+			interrupts = <GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH 0>;
+			phys = <&ufsphy>;
+			clocks = <&infracfg_ao CLK_INFRA_AO_AES_UFSFDE>,
+				 <&infracfg_ao CLK_INFRA_AO_AES>,
+				 <&infracfg_ao CLK_INFRA_AO_UFS_TICK>,
+				 <&infracfg_ao CLK_INFRA_AO_UNIPRO_SYS>,
+				 <&infracfg_ao CLK_INFRA_AO_UNIPRO_TICK>,
+				 <&infracfg_ao CLK_INFRA_AO_UFS_MP_SAP_B>,
+				 <&infracfg_ao CLK_INFRA_AO_UFS_TX_SYMBOL>,
+				 <&infracfg_ao CLK_INFRA_AO_PERI_UFS_MEM_SUB>;
+			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>;
+
+			mediatek,ufs-disable-mcq;
+			status = "disabled";
+		};
+
 		lvts_mcu: thermal-sensor@11278000 {
 			compatible = "mediatek,mt8195-lvts-mcu";
 			reg = <0 0x11278000 0 0x1000>;
-- 
2.45.2

Re: [PATCH v2 4/4] arm64: dts: mediatek: mt8195: add UFSHCI node

[Peter Wang (王信友)]

On Tue, 2025-07-22 at 16:57 +0800, Macpaul Lin wrote:
> From: Rice Lee <ot_riceyj.lee@mediatek.com>
> 
> Add a UFS host controller interface (UFSHCI) node to mt8195.dtsi.
> Introduce the 'mediatek,ufs-disable-mcq' property to allow disabling
> Multiple Circular Queue (MCQ) support.
> 
> Signed-off-by: Rice Lee <ot_riceyj.lee@mediatek.com>
> Signed-off-by: Eric Lin <ht.lin@mediatek.com>
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8195.dtsi | 25
> ++++++++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> Changes for v2:
>  - No change.
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> index dd065b1bf94a..8877953ce292 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
> @@ -1430,6 +1430,31 @@ mmc2: mmc@11250000 {
>  			status = "disabled";
>  		};
>  
> +		ufshci: ufshci@11270000 {
> +			compatible = "mediatek,mt8195-ufshci";
> +			reg = <0 0x11270000 0 0x2300>;
> +			interrupts = <GIC_SPI 137
> IRQ_TYPE_LEVEL_HIGH 0>;
> +			phys = <&ufsphy>;
> +			clocks = <&infracfg_ao
> CLK_INFRA_AO_AES_UFSFDE>,
> +				 <&infracfg_ao CLK_INFRA_AO_AES>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_UFS_TICK>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_UNIPRO_SYS>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_UNIPRO_TICK>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_UFS_MP_SAP_B>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_UFS_TX_SYMBOL>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_PERI_UFS_MEM_SUB>;
> +			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>;
> +
> +			mediatek,ufs-disable-mcq;
> +			status = "disabled";
> +		};
> +
>  		lvts_mcu: thermal-sensor@11278000 {
>  			compatible = "mediatek,mt8195-lvts-mcu";
>  			reg = <0 0x11278000 0 0x1000>;


Reviewed-by: Peter Wang <peter.wang@mediatek.com>

Re: [PATCH v2 1/4] scsi: ufs: ufs-mediatek: Add UFS host support for MT8195 SoC

[Peter Wang (王信友)]

On Tue, 2025-07-22 at 16:57 +0800, Macpaul Lin wrote:
> Add "mediatek,mt8195-ufshci" to the of_device_id table to enable
> support for MediaTek MT8195/MT8395 UFS host controller. This matches
> the
> device node entry in the MT8195/MT8395 device tree and allows proper
> driver
> binding.
> 
> Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
> ---
>  drivers/ufs/host/ufs-mediatek.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> Changes vor f2:
>  - No change.
> 
> diff --git a/drivers/ufs/host/ufs-mediatek.c b/drivers/ufs/host/ufs-
> mediatek.c
> index 182f58d0c9db..e1dbf0231c5e 100644
> --- a/drivers/ufs/host/ufs-mediatek.c
> +++ b/drivers/ufs/host/ufs-mediatek.c
> @@ -50,6 +50,7 @@ static const struct ufs_dev_quirk
> ufs_mtk_dev_fixups[] = {
>  
>  static const struct of_device_id ufs_mtk_of_match[] = {
>  	{ .compatible = "mediatek,mt8183-ufshci" },
> +	{ .compatible = "mediatek,mt8195-ufshci" },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);

Reviewed-by: Peter Wang <peter.wang@mediatek.com>

Re: [PATCH v2 1/4] scsi: ufs: ufs-mediatek: Add UFS host support for MT8195 SoC

[Martin K. Petersen]

On Tue, 22 Jul 2025 16:57:17 +0800, Macpaul Lin wrote:

> Add "mediatek,mt8195-ufshci" to the of_device_id table to enable
> support for MediaTek MT8195/MT8395 UFS host controller. This matches the
> device node entry in the MT8195/MT8395 device tree and allows proper driver
> binding.
> 
> 

Applied to 6.17/scsi-queue, thanks!

[1/4] scsi: ufs: ufs-mediatek: Add UFS host support for MT8195 SoC
      https://git.kernel.org/mkp/scsi/c/6f1fd3e0279f
[2/4] dt-bindings: ufs: mediatek,ufs: add ufs-disable-mcq flag for UFS host
      https://git.kernel.org/mkp/scsi/c/794ff7a0a6e7
[3/4] dt-bindings: ufs: mediatek,ufs: add MT8195 compatible and update clock nodes
      https://git.kernel.org/mkp/scsi/c/d01cfeac89e9
[4/4] arm64: dts: mediatek: mt8195: add UFSHCI node
      https://git.kernel.org/mkp/scsi/c/a28f98103890

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [PATCH v2 1/4] scsi: ufs: ufs-mediatek: Add UFS host support for MT8195 SoC

[Bart Van Assche]

On 7/22/25 1:57 AM, Macpaul Lin wrote:
> Add "mediatek,mt8195-ufshci" to the of_device_id table to enable
> support for MediaTek MT8195/MT8395 UFS host controller. This matches the
> device node entry in the MT8195/MT8395 device tree and allows proper driver
> binding.
Please always include a cover letter when posting a patch series. The
cover letter generated by git includes helpful information like a diffstat.

Thanks,

Bart.