Quoting Anup Patel (2025-07-25 09:16:12)
> On Fri, Jul 25, 2025 at 8:12 AM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
> >
> > Quoting Anup Patel (2025-07-04 00:03:40)
> > > Add device tree bindings for the RPMI clock service group based
> > > message proxy implemented by the SBI implementation (machine mode
> > > firmware or hypervisor).
> > >
> > > The RPMI clock service group is defined by the RISC-V platform
> > > management interface (RPMI) specification.
> > >
> > > Reviewed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> > > Signed-off-by: Anup Patel <apatel@xxxxxxxxxxxxxxxx>
> > [...]
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + clock-controller {
> >
> > Maybe the name should be 'clock-service' then? I don't understand SBI so
> > not sure why this is in DT to begin with. Is something consuming this
> > node? Or a driver is binding to it?
>
> SBI is a syscall style interface between SBI implementation (aka
> M-mode firmware or hypervisor) and supervisor software (aka
> Linux kernel).
>
> We have DT based drivers in OpenSBI (M-mode firmware). This
> binding allows Clock message proxy driver to be probed on the
> OpenSBI side. The clock message proxy driver allows Linux
> RPMI clock driver to send RPMI messages via OpenSBI as
> proxy thereby sharing the RPMI transport between OpenSBI
> and Linux kernel.
Let me try to clarify my confusion. A 'clock-controller' node without a
'#clock-cells' property is confusing.
It's not providing clks? The SBI firmware is not discoverable? Do you
have a pointer to the DTS for this node and the clock controller node in
the next patch? I'd like to understand why this is named a clock
controller when it doesn't provide clks.
