[PATCH v6 00/12] clk: nuvoton: ma35d1: Fix mux parenting and peripheral clock rates
From: Miquel Raynal
Date: Wed Sep 30 2026 - 13:45:29 EST
I am in possession of an MA35D1 NuMaker board. The SPI controller has
been contributed, but at this stage it does not work with the current
clock driver.
The clock controller registers its muxes with .fw_name parent data,
which requires every internal clock name to be declared in the DT. As
the DT does not declare them, all parent lookups fail: muxes end up
registered as root clocks and most peripherals read a zero rate.
This conversion exposed a first issue with the WDT/WWDT parents which
were actually missing in the clock driver. I am not using these clocks
myself but it is worth fixing.
The second round of reviews raised another problem with the
crystals. HXT and LXT are external crystal oscillators wired on the
board, while HIRC and LIRC are on-chip RC oscillators. HXT was described
whereas LXT was not. The series now also takes the two crystal inputs
from the DT: they get documented in the bindings, described in the
boards and looked up by the driver (with a fallback for backward
compatibility).
Finally, I was still unsatisfied by the clock tree because there were
too many root clocks. Many "gates" were wrongly set aside from the
downstream clocks they would gate, and SYSPLL was simply not parented at
all (?).
The clock tree now looks much more accurate.
Signed-off-by: Miquel Raynal <miquel.raynal@xxxxxxxxxxx>
---
Changes in v6:
- Drop the clock output names entirely, they are not relevant.
- Error out when the crystal providers defer probing.
- Make sure gates are correctly parented.
- Make sure SYSPLL is parented.
- Link to v5: https://lore.kernel.org/r/20260929-perso-ma35d1-upstream-clk-v5-0-68533e935ee4@xxxxxxxxxxx
Changes in v5:
- Fix the bindings wrt HXT and LXT.
- Fix the DT descriptions of HXT and LXT.
- Collect tags.
- Link to v4: https://lore.kernel.org/r/20260925-perso-ma35d1-upstream-clk-v4-0-f3697553391f@xxxxxxxxxxx
Changes in v4:
- I forgot to bump the clock counter in the driver after adding the two
new clocks in the bindings. Sashiko will keep complaining about the
incoherency though. Since binding and driver changes should be kept
separated, I cannot do both at the same time.
- Link to v3: https://lore.kernel.org/r/20260925-perso-ma35d1-upstream-clk-v3-0-ffbae7e020a8@xxxxxxxxxxx
Changes in v3:
- Drop the number of clocks from the binding, set it in the driver only
- Split the binding/driver patches completely
- Link to v2: https://lore.kernel.org/r/20260921-perso-ma35d1-upstream-clk-v2-0-209fd32a8b00@xxxxxxxxxxx
Changes in v2:
- New patch 1/3: register the missing WDT/WWDT parent clocks
- New patch 3/3: harden the code
- Link to v1: https://lore.kernel.org/r/20260813-perso-ma35d1-upstream-clk-v1-1-e78e5e6172ea@xxxxxxxxxxx
---
Miquel Raynal (12):
clk: nuvoton: ma35d1: Keep the clock count in the driver
dt-bindings: clock: ma35d1: Document the missing crystal inputs
dt-bindings: clock: ma35d1: Drop CLK_MAX_IDX define
dt-bindings: clock: ma35d1: Add missing WDT/WWDT parent clocks
clk: nuvoton: ma35d1: Add missing WDT/WWDT parent clocks
clk: nuvoton: ma35d1: Use clk_hw pointers as mux parents
clk: nuvoton: ma35d1: Avoid possible error pointer dereferencing
clk: nuvoton: ma35d1: Retrieve HXT/LXT from DT
clk: nuvoton: ma35d1: Reparent the gates correctly
clk: nuvoton: ma35d1: Reparent SYSPLL correctly
arm64: dts: nuvoton: ma35d1: Drop HXT clock output name
arm64: dts: nuvoton: ma35d1: Add LXT crystal and clock-names
.../bindings/clock/nuvoton,ma35d1-clk.yaml | 16 +-
arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts | 7 +-
arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts | 7 +-
arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 3 +-
drivers/clk/nuvoton/clk-ma35d1-divider.c | 3 +
drivers/clk/nuvoton/clk-ma35d1-pll.c | 3 +
drivers/clk/nuvoton/clk-ma35d1.c | 723 +++++++--------------
include/dt-bindings/clock/nuvoton,ma35d1-clk.h | 3 +-
8 files changed, 287 insertions(+), 478 deletions(-)
---
base-commit: c5137d373338693fc18f03824782c7d383bfd57a
change-id: 20260813-perso-ma35d1-upstream-clk-65cacfc1a86b
Best regards,
--
Miquel Raynal <miquel.raynal@xxxxxxxxxxx>