Re: [PATCH v5] dt-bindings: clock: via,vt8500: Convert to DT Schema

[Alexey Charkov]

On Sun, May 31, 2026 at 9:11 PM Udaya Kiran Challa
<challauday369@xxxxxxxxx> wrote:
>
> Convert the VIA/Wondermedia VT8500 and Wondermedia WM8xxx series SoCs clock
> controller binding from the legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@xxxxxxxxx>
> ---

Hi,

I'm not sure that this separation of the clock controller binding vs.
PMC is the right way to go (yes, I know it's been that way in the .txt
document, but still).

The clock controller is not a standalone device on these SoCs - it's
one of the functions of the PMC (weirdly enough), with its MMIO space
interweaved between clock statuses and enable controls,
reset/hibernation control, system timer and watchdog, then again clock
control. You can't run the clock controller separately from the
resources provided in its parent PMC node, because all those *reg
nodes are just offsets into the PMC controller's MMIO space. So the
way it's done currently doesn't look like idiomatic DT to me.

If I were to implement support for all that beauty today, I would have
made a top-level MFD node owning the whole MMIO range of the PMC, put
clock IDs into a dt-bindings header file and just implement all clock
operations in code without putting those offsets and bits into the
device tree. They are not configurable, they are not board specific,
they just constitute the interface of a particular SoC revision which
follows directly from a SoC versioned PMC compatible string.

The only thing that would have showed up in the DT then would have
been the PMC node with a register range and a bunch of named
interrupts (not for clocks, but for other functions), a
clock-controller attribute and a single clock cell to pass arbitrarily
assigned clock IDs from a new per-SoC dt-bindings header.

I'm pretty sure there are no users of these DTs outside of mainline
Linux, because vendor kernels used board files, and no DT-enabled
firmware has ever been created, thus the only way to boot these boards
with a device tree has only ever been via an appended-DTB uImage (i.e.
the DTB always comes from the currently used Linux kernel source).
>From this perspective I believe redoing the DT in a more
hardware-aligned fashion (and breaking DT ABI) could be better than
making the current suboptimal approach more "official" by encoding it
in DT schema. Krzysztof will likely disagree though :)

Best regards,
Alexey