Re: [PATCH v3 02/10] arm: dts: renesas: r8a7740: Add clocks for FSI

Hi all,

On Tue, May 12, 2026 at 5:03 AM <[email protected]> wrote:
> Will adding the spu clock to the device tree without the corresponding driver
> support cause the common clock framework to automatically disable it during
> system initialization?
>
> If the bootloader leaves the spu clock enabled, and the kernel disables it
> because the driver hasn't claimed it yet, could this cause a regression where
> the system hangs on subsequent register accesses by the fsi driver?

Yes, that is the current issue.

The SPU clock was already present in the DT, but since it was not managed by
the FSI driver, the common clock framework could disable it after boot.

This change adds the SPU clock to the FSI clock handling so it stays enabled
while FSI is active.


> To maintain bisectability, should the driver be updated to manage the spu
> clock before or in the same commit as this device tree update? I see this
> regression was addressed in a later commit adding spu clock control in
> hw_startup/shutdown, but it may break bisectability here.

Reordering should not be necessary here, since this is a pre-existing issue
rather than a regression introduced by this patch.

The SPU clock node was already present in the DT previously, and the later
driver change simply adds the missing clock management support for it.

> > +             clock-names = "fck", "spu", "icka", "ickb", "xcka",
> > +                             "xckb";
>
> Does appending the external clocks (xcka and xckb) here without the internal
> dividers (diva and divb) violate the strict positional order defined in the
> device tree binding schema?
>
> The dt-binding schema for renesas,sh_fsi2 defines the clocks property as an
> ordered list where the 5th and 6th items are the internal dividers, and the
> 7th and 8th are the external clocks.
>
> Since dt-validate evaluates array items positionally, will it evaluate the
> external clocks against the internal divider descriptions? Should the array
> be padded with dummy elements (like <0>) to maintain the strict positional
> order?

No. These clocks are defined as optional, and the current schema does not
define fixed positional constraints for individual clock entries.

Best Regard,
Phuc