OSDN Git Service

rtc: ds1307: improve weekday handling
authorHeiner Kallweit <hkallweit1@gmail.com>
Tue, 29 Aug 2017 19:52:56 +0000 (21:52 +0200)
committerAlexandre Belloni <alexandre.belloni@free-electrons.com>
Thu, 12 Oct 2017 12:16:09 +0000 (14:16 +0200)
commit584ce30c72954e5ec67aaf317d7cbffe6c2c97fa
tree1a81a3e0c0f943c7988c1c7a127261fb43328e10
parent74717b28cb32e1ad3c1042cafd76b264c8c0f68d
rtc: ds1307: improve weekday handling

The current code for checking and fixing the weekday in ds1307_probe
faces some issues:
- This check is applied to all chips even if its applicable (AFAIK)
  to mcp794xx only
- The check uses MCP794XX constants for registers and bits even though
  it's executed also on other chips (ok, this could be fixed easily)
- It relies on tm_wday being properly populated when core calls set_time
  and set_alarm. This is not guaranteed at all.

First two issue we could solve by moving the check to the
mcp794xx-specific initialization (where also VBATEN flag is set).

The proposed alternative is in the set_alarm path for mcp794xx only and
calculates the alarm weekday based on the current weekday in the RTC
timekeeping regs and the difference between alarm date and current date.
So we are fine with any weekday even if it doesn't match the date.

Still there are cases where this could fail, e.g.:
- rtc date/time + weekday have power-on-reset default values
- alarm is set to actual date/time + x
- set_time is called (may change diff between rtc weekday and actual
  weekday)

But similar issues we have with the current code too:
- rtc date/time + weekday have power-on-reset default values
- alarm is set to rtc date/time + x
- set_time is called before the alarm triggers

Using random rtc date/time with relative alarms simply can interfere
with set_time. I'm not totally convinced of either option yet.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
drivers/rtc/rtc-ds1307.c