On 12/02/2025 10:43:24+0000, Sudeep Holla wrote:

On Wed, Feb 12, 2025 at 02:35:32PM +0800, Peng Fan wrote:

quoted

On Tue, Feb 11, 2025 at 04:59:53PM +0000, Sudeep Holla wrote:

quoted

On Tue, Jan 21, 2025 at 02:31:55PM +0000, Peng Fan wrote:

quoted

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.

quoted

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