[PATCH v3 03/24] dt-bindings: ufs: mediatek,ufs: Add mt8196 variant

Conor Dooley conor at kernel.org
Sun Oct 26 15:25:44 PDT 2025


On Fri, Oct 24, 2025 at 07:51:11PM +0200, Nicolas Frattaroli wrote:
> On Friday, 24 October 2025 19:13:36 Central European Summer Time Conor Dooley wrote:
> > On Thu, Oct 23, 2025 at 09:49:21PM +0200, Nicolas Frattaroli wrote:
> > 
> > >      };
> > > +  - |
> > > +    #include <dt-bindings/reset/mediatek,mt8196-resets.h>
> > > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > +
> > > +    ufshci at 16810000 {
> > > +        compatible = "mediatek,mt8196-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>,
> > > +                 <&ufs_ao_clk 1>,
> > > +                 <&ufs_ao_clk 2>,
> > > +                 <&topckgen 42>,
> > > +                 <&topckgen 84>,
> > > +                 <&topckgen 102>;
> > 
> > This is absolutely a nitpick thing, but if you end up resubmitting, can
> > you pick a consistent format between the two examples your series adds
> > for the clocks/clock names?
> 
> No problem, will do. IIRC I kept them as a list like this so I could
> easily reorder things, but now that I'm fairly sure this order is the
> correct one, it's probably best to make this more compact.
> 
> Also sorry for the numbers as clock IDs, but MediaTek clock headers
> have conflicting symbols and the dt schema example extractor dumps
> all examples into one dts file. :(

Numbers is fine, dw about that.

> Since this has bugged me in the past, and many schemas may rely on
> the concat behaviour now: would a patch in the distant future that
> prefixes all MediaTek clock binding headers with the SoC name be
> acceptable if it keeps the old names intact as aliases to them with
> a #ifndef guard?

Honestly, I don't think it's that big of a deal to use the numbers,
they're only examples after all (even if for soc-peripherals they're
almost always exactly what is used in reality).

What you do with aliases is really up to the mediatek platform
maintainers, but I think if it were my platform I would just not bother.

> I should also think about some way we can avoid similar bindings
> symbol naming mishaps in the future.
> 
> Thank you for pointing me in the right direction with regards to
> the binding!
> 
> Kind regards,
> Nicolas Frattaroli
> 
> > Reviewed-by: Conor Dooley <conor.dooley at microchip.com>
> > pw-bot: not-applicable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20251026/4ef65bee/attachment.sig>


More information about the linux-arm-kernel mailing list