[PATCH 1/2] dt-bindings: watchdog: mediatek,mtk-wdt: add MT7988 watchdog and toprgu

[Daniel Golle]

On Fri, Nov 10, 2023 at 04:21:35PM +0100, Krzysztof Kozlowski wrote:
> On 10/11/2023 16:15, Krzysztof Kozlowski wrote:
> >>>> So adding the file to include/dt-bindings/reset/ should go into a
> >>>> seperate patch? Because including it with the driver itself gave me
> >>>> a checkpath warning telling me that dt-bindings should go seperate,
> >>>> which is why I included it with the binding docs.
> >>>
> >>> No, I said the hunk should be dropped. Removed.
> >>
> >> I guess we are somehow misunderstanding each other.
> >> Lets go with an example. I can put the header into a commit of its own,
> >> just like commit
> >> 5794dda109fc8 dt-bindings: reset: mt7986: Add reset-controller header file
> >> https://lore.kernel.org/r/20220105100456.7126-2-sam.shih@mediatek.com
> >>
> >> Would that be acceptable? And if not, why?
> > 
> > ...this question.

... which you didn't answer. Sorry, but it's not helpful to be polemic
or ironic in a code review involving non-native English speakers
trying to understand each others.

> > 
> > Again, whether this is separate patch - it is still hunk which I think
> > should be removed. I gave the reason "why" in this mail thread and in
> > multiple other discussions.
> 
> I gave you clear reasoning 7 hours ago:
> https://lore.kernel.org/all/59629ec1-cc0c-4c5a-87cc-ea30d64ec191@linaro.org/
> to which you did not respond.

Because it doesn't match anything existing regarding MediaTek reset
drivers, and I was assuming there must be some kind of misunderstanding,
which is why I replied to your later email in the same thread.

My assumption that the problem was merely having documentation and
header combined in a single commit stems from the fact that a very
similar patch for MT7986[1] was Ack'ed by Rob Herring about a year and
a half ago; hence the rule you apply here may have always existed, but
apparently then hasn't been applied in the past.

Literally *all* existing dt-binding headers for MediaTek SoCs follow a
direct 1:1 mapping of reset bit in hardware and reset number in the
header files. The driver is simple, all it cares about is the maximum
number defined in the header (and I like that, because it makes it very
easy to add new SoCs). At this point the abstraction needed to
fulfill your request doesn't exist, not for any of the SoCs using
mtk_wdt.c. It can be implemented, surely, it's a problem computers can
solve. If that's what you (and current maintainers of that driver)
would want me to implement, please say so clearly and spell it out.

Also be clear about if all the other existing headers need to be
converted, mappings for all SoCs created in the driver, ... all before
support for MT7988 can go in?
Or should the existing headers for other MediaTek SoCs remain
untouched because they are already considered stable API or something?


Thank you for your patiente!


Daniel


[1]: https://lore.kernel.org/all/Yd4uplioThv8eJJE@robh.at.kernel.org/