[PATCH v1 1/2] Documentation: dt: reset: add mediatek,syscon-reset binding
Peter Wang (王信友)
peter.wang at mediatek.com
Thu Jul 2 02:39:47 PDT 2026
On Thu, 2026-07-02 at 10:55 +0200, AngeloGioacchino Del Regno wrote:
> I completely agree about that. Honestly, I'm not even sure why
> MediaTek needs the
> resets in the ufscfg0-ao space (because I didn't do extensive
> research, but that
> might be rightful), but this is getting a bit annoying as they keep
> pushing for
> adding something similar to the TI syscon reset at least at every new
> chip that
> comes out (or every 6-8 months if I recall correctly), and we keep
> doing the same
> review over and over.
>
> Please MediaTek, stop trying to add syscon-reset. Please!
>
> I know that you're trying to do that because in your downstream you
> never stopped
> using ti,syscon-reset: if that works better for you in your
> downstream, that's ok
> as it's purely yours but, as a matter of fact, in this form, it's not
> upstreamable.
>
> If you have to upstream a *pure* reset controller, make a reset
> controller driver
> and put it in the appropriate kernel subsystem - but I also want to
> remind you
> that I know MediaTek SoCs, and I know that up until MT8196 there
> shouldn't be any
> hardware that is purely a reset controller (as in, there's no IP that
> manages only
> resets).
>
> Thanks everyone!
> Angelo
Hi AngeloGioacchino,
Thank you for your review.
Indeed, you're right – we don't have any hardware that functions
solely as a reset controller. Our hardware only provides partial
reset capabilities, which necessitates a partial reset driver
(responsible for managing just a few set/clear bits).
We are currently planning to remove the ti,syscon-reset implementation
and utilize a MediaTek-specific syscon-reset instead. However,
if you object, I will halt this plan, and we can adopt
Philipp's proposed solution for handling the reset.
Thanks
Peter
More information about the Linux-mediatek
mailing list