Re: [PATCH 0/4] rtc/scmi: Support multiple RTCs

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 12/02/2025 10:43:24+0000, Sudeep Holla wrote:
> On Wed, Feb 12, 2025 at 02:35:32PM +0800, Peng Fan wrote:
> > On Tue, Feb 11, 2025 at 04:59:53PM +0000, Sudeep Holla wrote:
> > >On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote:
> > >> 
> > >> It is the i.MX SCMI Protocol exports two RTCs using one protocol.
> > >> 
> > >> Two RTC devices are created, but share one parent device.
> > >> 
> > >> Do you mean each RTC device should have a unique parent device?
> > >>
> > >
> > >Can you point where is this check for unique parent ? I am not so familiar
> > >with RTC but I couldn't find myself with quick search.
> > 
> > The RTC ops takes the rtc parent as input parameter
> > https://elixir.bootlin.com/linux/v6.13.2/source/drivers/rtc/interface.c#L94
> > "err = rtc->ops->read_time(rtc->dev.parent, tm);"
> > 
> > So in the rtc device driver, there is no way to know which rtc it is just
> > from the parent device.
> >
> 
> If that is the expectation, you could create a platform or normal device
> per instance of RTC on your platform and slap them as parent device.

This would seem like the proper solution, why not using an MFD or
auxiliary bus ?

> 
> IIUC on any pure DT based system, a device node exists per RTC and hence
> platform device associated with it. And the RTC devices are created with
> parent pointing to unique platform device.
> 
> > However i.MX SCMI BBM exports two RTCs(id: 0, id: 1), so to make it work for
> > current RTC framework, we could only pick one RTC and pass the id to BBM
> > server side.
> >
> > I am not sure whether Alexandre wanna me to update the code following each
> > parent could only support one RTC or else.
> >

I want you to keep your changes local to your driver. I already stated
back in 2018 that you were on your own with the imx-sc driver and that I
don't like seeing multiple abstractions for existing RTCs. What is the
actual use case behind needing to access both RTCs using Linux?
Shouldn't this be handled on your firmware side?


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com