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

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

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