[PATCH v1 1/2] Documentation: dt: reset: add mediatek,syscon-reset binding

[Philipp Zabel]

On Mi, 2026-07-01 at 06:35 +0000, Peter Wang (王信友) wrote:
> On Fri, 2026-06-26 at 10:33 +0200, Philipp Zabel wrote
> > 
> > Where is the binding doc for mediatek,mt8183-ufs0cfg_ao? Is this
> > simple-mfd just to load the reset driver?
> > 
> 
> Hi Philipp,
> 
> Thanks for the review, and sorry for the late reply.
> Yes, "mediatek,mt8183-ufs0cfg_ao" should be removed.
> I will remove it in the next version.
> 
> > > +        reg = <0x16840000 0x1000>;
> > > +        #address-cells = <1>;
> > > +        #size-cells = <1>;
> > > +
> > > +        ufs0cfgao_rst: reset-controller {
> > > +            compatible = "mediatek,syscon-reset";
> > 
> > It looks to me like this is just two registers inside ufs0cfg_ao, not
> > a
> > separate device. Why don't you just add #reset-cells to the parent
> > node?
> > 
> > > +            #reset-cells = <1>;
> > > +            mediatek,reset-bits =
> > > +                <0x48  3  0x4c  3  100>,
> > > +                <0x148 0  0x14c 0  100>,
> > > +                <0x148 1  0x14c 1  100>,
> > > +                <0x148 2  0x14c 2  0>;
> > > +        };
> > 
> > Why is this in DT? This should be a table in the reset driver.
> > 
> > regards
> > Philipp
> 
> Regarding the child node and reset-bits in DT,
> We chose the child node approach with 'mediatek,reset-bits' defined 
> in DT to keep the reset line descriptions self-contained and reusable 
> across different SoC variants. MediaTek has many SoCs (mt8183, mt6985, 
> mt6989, ...) where the same UFS subsystem may have different register 
> offsets for reset lines. By describing them in DT, we can support new 
> SoC variants by updating the DT alone, without requiring a new driver 
> patch for every new SoC.

This makes adding new SoCs that fit the binding convenient for a while
but hurts maintainability in the long run.

These bindings seem to never be generic enough to last more than a few
SoC generations, and then something different comes along. Case in
point, your new binding is different from ti,reset-bits. So we'd just
collect more and more of them over time.

Also it would be much harder to fix things that can not be expressed by
the binding after the fact, for example when it turns out that a reset
control bit is inverted.

> This approach is also consistent with the existing 'ti,syscon-reset' 
> binding, which uses a similar per-entry table property 'ti,reset-bits' 
> to describe reset lines within a syscon block.

Note that I tried to gently pushed back against that when it was
introduced. I now think having it let through was a mistake.

The argument back then was that listing resets in arrays in the driver
would become unmaintainable, and so far I have seen no indication that
this would have become true.

Also the idea was that this was generic enough to be reused for a lot
of SoCs. That didn't happen either.

I'd prefer if you could just enumerate your resets and use the ids as
an indices into arrays in the driver.

regards
Philipp