Re: [PATCH RFC v2 0/9] Add System Controller support for RZ/T2H and RZ/N2H SoCs

Hi Geert,

On Wed, Jul 15, 2026 at 9:56 AM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Prabhakar,
>
> On Tue, 14 Jul 2026 at 18:51, Lad, Prabhakar <[email protected]> wrote:
> > On Tue, Jul 14, 2026 at 2:27 PM Lad, Prabhakar
> > <[email protected]> wrote:
> > > On Mon, Jul 13, 2026 at 5:00 PM Geert Uytterhoeven <[email protected]> wrote:
> > > > On Thu, 2 Jul 2026 at 14:31, Prabhakar <[email protected]> wrote:
> > > > > From: Lad Prabhakar <[email protected]>
> > > > > This series adds support for the System Controller (SYSC) blocks found on
> > > > > the Renesas RZ/T2H and RZ/N2H SoCs. These blocks handle critical low-power
> > > > > management and access control functions.
> > > > >
> > > > > Hardware Architecture & Dependency Challenges:
> > > > > ----------------------------------------------
> > > > > The SYSC in these SoCs is a multi-functional block responsible for:
> > > > >     - Clock & Reset Control
> > > > >     - Low Power Management
> > > > >     - Clock Monitor (CLMA)
> > > > >     - Access Control
> > > > >
> > > > > A key architectural detail is that these SYSC blocks are physically located
> > > > > within the CPG/MSSR (Clock Pulse Generator / Module Standby Software Reset)
> > > > > address space. While the CPG/MSSR driver is already implemented and
> > > > > functional for these SoCs, the integration of SYSC adds a layer of
> > > > > complexity due to a cyclic dependency:
> > > > >     - SYSC requires CPG: The system controller needs a clock to operate.
> > > > >     - CPG requires SYSC: Access control registers within the SYSC contain
> > > > >       bits necessary to control the PLLs managed by the CPG.
> > > > >
> > > > > If implemented as a completely separate top-level system controller node, we
> > > > > would face a cyclic dependency between the CPG and SYSC drivers during the
> > > > > boot process.
> > > > >
> > > > > Proposed Implementation
> > > > > ----------------------------
> > > > > To resolve this, the SYSC blocks are represented as child nodes of the
> > > > > CPG/MSSR controller in the device tree. The SYSC regmap is registered
> > > > > directly against the CPG device node. This hierarchy correctly models the
> > > > > hardware address space while allowing the drivers to share resources
> > > > > without deadlock.
> > > > >
> > > > > I am sending this as an RFC specifically to get feedback on the
> > > > > implementation of the SYSC as child nodes of the CPG to resolve the
> > > > > dependency cycle.
> > > >
> > > > Personally, I am not a big fan of subnodes.  I assume you are using
> > > > subnodes because you can register only a single regmap per syscon node?
> > > Yes so that the consumers don't have to specify it by indexing.
> > >
> > > > Would it be possible to just extend the existing clock-controller
> > > > node with two more reg entries, and expose them through a single
> > > > combined regmap?
> > > >
> > > That should be possible. Or would you prefer just to extend the sizes
> > > and create a single regmap for it?
> > >
> > >                cpg: clock-controller@80280000 {
> > I wonder wether we rename this to `sysc: system-controller` but the
> > compatiable string has "*cpg-mssr" postfix.
>
> I think the current name is fine, as clock control is the main function.
>
Ok I will keep it as is.

Cheers,
Prabhakar

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds