linux-toradex.git/drivers/rtc/rtc-ds1307.c, branch v4.10

rtc: ds1307: Add ACPI support

2016-12-18T23:59:07+00:00

This patch enables ACPI support for rtc-ds1307 driver.

Signed-off-by: Tin Huynh 
Signed-off-by: Alexandre Belloni

rtc: ds1307: add Intersil ISL12057 support

2016-08-31T16:21:34+00:00

Intersil ISL12057 is a drop-in replacement for DS1337. It can be supported
by the ds1307 driver.

Acked-by: Arnaud Ebalard 
Signed-off-by: Alexandre Belloni

rtc: ds1307: fix century bit support

2016-08-31T16:21:34+00:00

Add an option to properly support the century bit of ds1337 and compatibles
and ds1340.
Because the driver had a bug until now, it is not possible to switch users
to the fixed code directly as RTCs in the field will wrongly have the
century bit set.

Acked-by: Arnaud Ebalard 
Signed-off-by: Alexandre Belloni

rtc: simplify implementations of read_alarm

2016-07-09T08:24:45+00:00

Since commit d68778b80dd7 ("rtc: initialize output parameter for read
alarm to "uninitialized"") there is no need to explicitly set
unsupported members to -1. So drop the respective assignments from
drivers.

Signed-off-by: Uwe Kleine-König 
Signed-off-by: Alexandre Belloni

rtc: ds1307: Fix relying on reset value for weekday

2016-07-09T08:24:44+00:00

The reset value of weekday is 0x1. This is wrong since
the reset values of the day/month/year make up to Jan 1 2001.
When computed weekday comes out to be Monday. On a scale
of 1-7(Sunday - Saturday) it should be 0x2. So we should not
be relying on the reset value.

Hence compute the wday using the current date/month/year values.
Check if reset wday is any different from the computed wday,
If different then set the wday which we computed using
date/month/year values.

Document Referred:
http://ww1.microchip.com/downloads/en/DeviceDoc/20002266F.pdf

Fixes: 1d1945d261a2af "drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips"
Signed-off-by: Keerthy 
Signed-off-by: Alexandre Belloni

rtc: ds1307: Remove CLK_IS_ROOT

2016-05-20T10:33:51+00:00

This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.

Cc: Akinobu Mita 
Cc: Michael Tatarinov 
Signed-off-by: Stephen Boyd 
Signed-off-by: Alexandre Belloni

rtc: ds1307: ensure that any pending alarm is cleared before a new alarm is enabled

2016-05-20T10:33:51+00:00

If a previously-set alarm was disabled and then triggered, it may still
be pending when a new alarm is configured.

Then, if the alarm is enabled before the pending alarm is cleared, then
an interrupt is immediately raised.

Unfortunately, when the alarm is cleared and enabled during the same I²C
block write, the chip (at least the DS1339 I have) considers that the
alarm is enabled before it is cleared, and raises an interrupt.

This patch ensures that the pending alarm is cleared before the alarm is
enabled.

Signed-off-by: Nicolas Boullis 
Signed-off-by: Alexandre Belloni

rtc: ds1307: fix ds1307_native_smbus_read_block_data function

2016-05-20T10:33:51+00:00

The i2c_smbus_read_i2c_block_data function returns 0 on success, not the
number of bytes written.

Hence, when there are 32 bytes or less to send, the
ds1307_native_smbus_write_block_data function returns 0 on success,
while it returns the number of bytes when there are more than 32.

The ds1307_write_block_data always returns the number of bytes on
success.

Signed-off-by: Nicolas Boullis 
Signed-off-by: Alexandre Belloni

rtc: ds1307: Use irq when available for wakeup-source device

2016-04-21T21:21:00+00:00

With commit 8bc2a40730ec ("rtc: ds1307: add support for the
DT property 'wakeup-source'") we lost the ability for rtc irq
functionality for devices that are actually hooked on a real IRQ
line and have capability to wakeup as well. This is not an expected
behavior. So, instead of just not requesting IRQ, skip the IRQ
requirement only if interrupts are not defined for the device.

Fixes: 8bc2a40730ec ("rtc: ds1307: add support for the DT property 'wakeup-source'")
Reported-by: Tony Lindgren 
Cc: Michael Lange 
Cc: Alexandre Belloni 
Signed-off-by: Nishanth Menon 
Signed-off-by: Alexandre Belloni

rtc: ds1307: ds3231 temperature s16 overflow

2016-04-21T21:20:59+00:00

while retrieving temperature from ds3231, the result may be overflow
since s16 is too small for a multiplication with 250.

ie. if temp_buf[0] == 0x2d, the result (s16 temp) will be negative.

Signed-off-by: Akinobu Mita 
Tested-by: Michael Tatarinov 
Signed-off-by: Alexandre Belloni