[lkml]   [2011]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectMinimal requirements for RTC drivers
Hello John,

I have been working on a new RTC driver for some custom RTC device
lately. It has the usual features like AIE, UIE and PIE.

I cloned the rtc-test.c driver as Documentation/rtc.txt suggested and
noticed that my driver would work with the test application even though
some of the driver functions were not implemented at all...

So I found out about your recent changes with regard to "RTC
virtualisation" and I understood the steps you have taken. It's not
necessary to provide all functionality through the RTC driver directly
any more, because some of the stuff is emulated via hrtimers.

One problem is that the documentation and the code have gotten out of
sync. People like me, who dive into the RTC subsystem for the first
time, can be easily fooled now.

So the main question now is what the minimal required functionality for
a RTC driver now actually is. Can you give me some hints?

I think it would be best if the rtc-test.c driver could be updated to
have a template new drivers can be cloned from.

Another thing that catched my eye is the current use of the read_alarm()
member in struct rtc_class_ops in rtc_read_alarm() in
drivers/rtc/interface.c. This is the only place where the member is used
and it's only used as a boolean there. The driver specific read_alarm()
op is never actually called, so I think that op can be transformed into
a boolean and all the read_alarm() functions from all the rtc drivers
can be removed - that's quite a lot of a code.

Best regards

 \ /
  Last update: 2011-04-04 09:19    [W:0.052 / U:0.492 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site