On Wed, Jul 8, 2026 at 8:45 AM Louis-Alexis Eyraud
[off-list ref] wrote:

Hello Rob,

On Wed, 2026-07-01 at 14:33 -0500, Rob Herring wrote:

quoted

On Wed, Jul 01, 2026 at 03:11:07PM +0200, Louis-Alexis Eyraud wrote:

quoted

Regroup the MT8188 clock and system clock dt-bindings into MT8186
ones
to ease maintainability and have common files for several currently
supported SoC or new future ones, that have the same kind of clock
controller design.

Note:
The `#clock-cells` property is a required property for all
compatibles
declared in MT8188 clock and system clock dt-bindings but not in
MT8186
ones.
To avoid ABI breakage, conditional blocks to check this requirement
for MT8188 compatibles are added, rather than enforcing it for
MT8186
compatibles.

If the existing DTs are just wrong, then I would just make #clock-
cells
required. But please update the .dts files so the warnings don't
grow.

I've tested to make the #clock-cells required for the MT8186, MT8192
and MT8195 system and functional clock controllers.
I did not see new warnings, so no extra dts patches would be needed.

I'll add new patches (one per SoC) in the next revision of the series
for this, as it simplifies the grouping patches (no more if/then to
require #clock-cells for the MT8188/MT8189 clock controllers) and the
note in commit message could be removed.

quoted

The grouping I would do here is:

- clock controller only
- reset controller only
- both clock and reset controller

That should avoid any if/then schemas.

By this grouping, I understand you suggest having separate dt-bindings
files, that could look like:
- mediatek,mt8186-clock.yaml: clock controllers
- <name to be found>: reset controllers
- <name to be found>: clock controllers with reset controller
- mediatek,mt8186-sys-clock.yaml: system clock controllers.
- <name to be found>: system clock controllers with reset controller

Is that what you meant?

I think so, but not sure I understand the distinction with clock
controllers and system clock controllers.

There is no pure reset controllers for those SoC so no dedicated file
would needed at the moment.
The system clock controllers all have reset-controllers, even they may
currently be not all implemented, so no separate files for system clock
controllers would needed as well.

Also, from what I see the current dt-bindings, the system clocks
controllers for the MT8186/MT8188/MT8192/MT8195 SoC have the #reset-
cells property but it is not required for them (examples:
mediatek,mt8188-infracfg-ao or mediatek,mt8195-infracfg_ao).

With the patches to make the #clock-cells property required, I already
removed the biggest if/else block in mediatek,mt8186-clock.yaml, so
only the one regarding #reset-cells property remains.

So, should I create separate files, following the grouping suggestion,
for the v2 of this patch?

Shrug. There's no hard rule here, it's a judgment call. With one
if/then block dropped, it's a bit more tolerable to keep it as-is. If
the if/then schemas are as long as the rest of the schema (minus any
example), then I would say to split the schemas.

Rob