Why RTC lower-half driver calls a function from upper-half one?

[sonydevworld]

Why RTC lower-half driver calls a function from upper-half one?

[takumiando]

I(actually our team) develop two editions of the IoT devices with SPRESENSE.
The version A uses onboard RTC and the version B should use external one.

But I don't want to release two firmware binaries for each editions(for costs!).
So I want to switch RTCs in a same firmware by EEPROM, status of GPIO, etc.

Do you have any good ideas?

apache/nuttx#7089

[SPRESENSE]

@takumiando san
As the incubator-nuttx issue comment, arch_rtc.c is introduced very later, and is not used by Spresense.
Spresense is using drivers/timers/rtc.c as the upper-half driver.
And, the lower-half driver is implemented in cxd56_rtc_lowerhalf.c using the chip-internal RTC.

  graph TD;
      drivers/timers/rtc.c-->cxd56_rtc_lowerhalf.c;
      cxd56_rtc_lowerhalf.c-->cxd56_rtc.c;

If you want to switch RTC device drivers via /dev/rtc,
you can implement another external lower-half driver
and switch the lower-half driver to register with rtc_initialize().

  graph TD;
      drivers/timers/rtc.c-->cxd56_rtc_lowerhalf.c;
      cxd56_rtc_lowerhalf.c-->cxd56_rtc.c;
      drivers/timers/rtc.c-->External_lowerhalf_driver;

On the other hand, up_rtc_xxx() functions are also used from sched/clock.
I think that even in cases where an external RTC is used, sched/clock can continue to use the internal RTC.

If you want to also switch the RTC used from sched/clock, the up_rtc_xxx function will be conflicted as you know.

It may be easier to dynamically switch between RTC internal or external on the up_rtc_xxx() functions.