[PATCH] consider alrm->enable in pcf50633_rtc_set_alarm

[Werner Almesberger]

Balaji Rao wrote:
> Yes, looks perfect! About alrm->pending, we should be setting it in
> read_alarm. But we there's no way to know this from the registers, right ?

I've been trying to steer around this one because I couldn't guess
the semantics. But you're right, intellectual laziness is never a
good excuse ;-)

I now found them. The first hint is in Documentation/ia64/efirtc.txt,
which points to EFI as the design that inspired the RTC interface.
This interface is defined in the UEFI specification, "Time Services":
http://www.uefi.org/specs/
Version 2.2, section 7.3.

Pending is supposed to be set when the alarm happens. We can do this
in the interrupt handler. The interesting bit is when it's cleared.
You have to acknowledge it, which happens as a side-effect of
disabling the alarm.

This means that setting a new alarm without clearing the previous
one may leave "pending" set. This seems a little odd, but if that's
what the specification says ...

I'll send the patch in a separate mail.

A note to users of that interface: I arbitrarily picked two drivers,
rtc-rs5c372.c and rtc-ds1305.c, and their use of "pending" seems to
be a bit confused. E.g., ds1305 clears it on any access to the alarm
registers, and rs5c372 doesn't even seem to clear it at all. So I
think one has to treat "pending" as having device-specific behaviour.

By the way, we still have remnants of pcf50606 and pcf50633 in
drivers/i2c/chips/. I tried to build a GTA01 and GTA02 kernel
without them, and this worked fine. Can we delete them ?

- Werner