set_rtc_time() cleanup / normalization

[Eugene Surovegin]

At 10:58 PM 5/13/2003, Dan Malek wrote:
>Eugene Surovegin wrote:
>
>>Why PPC arch should be different in this respect from other archs (like
>>i386, alpha, mips, mips64, sparc...)?
>
>PPC is different only that it follows the i386 model.  IIRC, the others
>have some selectable (or removed) feature for keeping the rtc updated.
>When you have an inflexible and essentially memory mapped device (like
>on i386) it makes sense to not have any options.  With embedded systems,
>you have a variety of options that don't always fit this model.

Exactly, I use this feature on our systems, somebody doesn't use it at all.

So far, the only *real* issue I've seen here is that some RTC drivers weren't
written correctly.

When I wrote RTC driver for out hw, simple grep through the code revealed
the fact, that ppc_md.set_rtc_time was called from interrupt context.
It's not a rocket science.

So all this surprise about kernel setting RTC is a little strange for me.
And yes, kernel *will* crash if you write a buggy driver.

I don't understand why instead of fixing those drivers we should remove
this feature altogether.

>>Frankly, I expect my tipb to behave exactly the same as my Intel box.
>
>Why would you want such a superior architecture like tipb to work
>so poorly? :-)

Well, I just use tipb as an example of box running PPC kernel which has the
same setup as my Intel box running the same kernel version.

>The tipb isn't the issue, but if you look carefully
>at all of these systems they all use user space programs to ensure
>the rtc and system date/time/timezone are set properly.
>
>>Maybe we should raise this issue on lkml?
>
>They won't care.  One, it's not x86, two, it's architecture specific.

Well, it's not entirely arch specific.
This behavior is *documented* (see hwclock(8) man pages for example).

Eugene.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/