Set .tm_sec to 0 instead of -1 to signal minute accuracy.
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Since all time members of the alarm data is initialized to -1 the drivers
are responsible to set the tm_sec member to 0.

Fixes: d68778b8 ("rtc: initialize output parameter for read alarm to "uninitialized"")
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled
and in set_freq we perform h/w registers read/write, which results in a
kernel crash on exynos7 platform while probing rtc driver.
Below is code flow:
s3c_rtc_probe()
    clk_prepare_enable(info->rtc_clk) // rtc clock enabled
    s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit
    s3c_rtc_setfreq() //then this will be called with clk disabled

This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in
s3c_rtc_setfreq().

Fixes: 24e14554 ("drivers/rtc/rtc-s3c.c: delete duplicate clock control")

Cc: <stable@vger.kernel.org>
Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Tested-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called with rtc
clock already disabled (by s3c_rtc_gettime()), which looks extra and
unnecessary call. Lets clean it up.
Signed-off-by: NAlim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Tested-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

If devm_add_action() fails we are explicitly calling the cleanup to free
the resources allocated.  Lets use the helper devm_add_action_or_reset()
and return directly in case of error, as we know that the cleanup function
has been already called by the helper if there was any error.
Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

If devm_add_action() fails we are explicitly calling the cleanup to free
the resources allocated.  Lets use the helper devm_add_action_or_reset()
and return directly in case of error, as we know that the cleanup function
has been already called by the helper if there was any error.
Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Be more explicit in some comments.
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

On some QNAP NAS devices the rtc can wake the machine. Several people
noticed that once the machine was woken this way it fails to shut down.
That's because the driver fails to acknowledge the interrupt and so it
keeps active and restarts the machine immediatly after shutdown. See
https://bugs.debian.org/794266 for a bug report.

Doing this correctly requires to interpret the INT2 flag of the first read
of the STATUS1 register because this bit is cleared by read.

Note this is not maximally robust though because a pending irq isn't
detected when the STATUS1 register was already read (and so INT2 is not
set) but the irq was not disabled. But that is a hardware imposed problem
that cannot easily be fixed by software.
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

There were two deviations from the reference manual: you have to wait
half a second when POC is active and you might have to repeat
initialization when POC or BLD are still set after the sequence.

Note however that as POC and BLD are cleared by read the driver might
not be able to detect that a reset is necessary. I don't have a good
idea how to fix this.

Additionally report the value read from STATUS1 to the caller. This
prepares the next patch.
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

There are several issues fixed in this patch:

 - When alarm isn't enabled, set .enabled to zero instead of returning
   -EINVAL.
 - Ignore how IRQ1 is configured when determining if IRQ2 is on.
 - The three alarm registers have an enable flag which must be
   evaluated.
 - The chip always triggers when the seconds register gets 0.

Note that the rtc framework however doesn't handle the result correctly
because it doesn't check wday being initialized and so interprets an
alarm being set for 10:00 AM in three days as 10:00 AM tomorrow (or
today if that's not over yet).
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The rtc core doesn't give broken dates to a driver's .set_alarm
callback, so there should be no need for validation.
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

This rtc doesn't support triggering on years, so don't assign tm_year
instead of claiming the alarm is to trigger in year 67435.
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The rtc chip doesn't support triggering on month and year. So just don't
assign the respective fields in .read_alarm and let the rtc core
interpret this accordingly.
Signed-off-by: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Since commit d68778b8 ("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: NUwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

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: 1d1945d2 "drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips"
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

rtc-v3020.h belongs to include/linux/platform_data/
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Move ds1286.h to rtc specific folder.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Add missing files to the RTC entry of MAINTAINERS
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

m48t86.h belongs to include/linux/platform_data/
Acked-by: NJason Cooper <jason@lakedaemon.net>
Acked-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NAlexander Clouter <alex@digriz.org.uk>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

rtc-ds2404.h belongs to include/linux/platform_data/
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

ds17287rtc.h is unused since 15beb694 ("mips: ip32: add platform data
hooks to use DS1685 driver"), remove it.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

A call to ioctl(..., RTC_IRQP_SET, ...) should never result in
ENOTTY. All new style RTC drivers implement it and all of the old style
drivers return EINVAL when they don't support periodic IRQs.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

A call to ioctl(..., RTC_IRQP_READ, ...) should never result in
ENOTTY. All new style RTC drivers implement it and all of the old style
drivers return EINVAL when they don't support periodic IRQs.
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

For old style drivers, call a call to ioctl(..., RTC_ALM_SET, ...):

    - char/ds1302.c will always return -EINVAL
    - char/genrtc.c: will always return -EINVAL
    - char/rtc.c will succeed regardless if IRQs are supported or not
    - char/efirtc.c will always return -EINVAL
    - input/misc/hp_sdc_rtc.c ... that ioctl code is a good lesson about
      ifdefing code out and punting implementation ... and it will
      always return -EINVAL

For new style rtc drivers, a call to ioctl(..., RTC_ALM_SET, ...) never
results in a call to __rtc_set_alarm, since struct rtc_wkalarm passed to
rtc_set_alarm has 'enabled' field set to 0. This means that
rtc->ops->set_alarm driver hook is never called in that ioctl. Since no
driver code interaction happens as a part of that call, using its
results to ascertain properties of the driver is not going to work. To
remedy this - use the result of RTC_AIE_ON to make the judgement.

This patch also changes ENOTTY to EINVAL as an error code value that
would tell us that IRQs are not supported. There are three reason for
this:

 - As mentioned above old style driver never returns ENOTTY for this
   ioctl

 - In it's code __rtc_set_alarm() returns -EINVAL if rtc->ops->set_alarm
   method is not provided by the driver, so one reason for change is to
   be consistent with that code path.

 - A call to ioctl(..., RTC_UIE_ON, ...) will result in a call to
   rtc_update_irq_enable() and then __rtc_set_alarm(), which, if IRQs
   are not supported by the driver, will result in a non-zero error
   code. Returning ENOTTY in that case would:

   	 a) Not be consistent with other codepaths of
   	 rtc_update_irq_enable, for example the check of
   	 rtc->uie_unsupported

	 b) Would break update IRQ emulation code since that codpath
	 expects EINVAL

	 c) Would break test's logic for feature support detection in
	 the case of RTC_UIE_ON ioctl
Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The previous workaround may still fail as there are actually 4 retries to
be done to ensure the communication succeed. Also, some I2C adapter drivers
may return -EIO instead of -ENXIO.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The mc146818_get_time/mc146818_set_time functions are rather large
inline functions in a global header file and are used in several
drivers and in x86 specific code.

Here we move them into a separate .c file that is compiled whenever
any of the users require it. This also lets us remove the linux/acpi.h
header inclusion from mc146818rtc.h, which in turn avoids some
warnings about duplicate definition of the TRUE/FALSE macros.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

nn10300 has a dependency on mc146818_get_time/mc146818_set_time,
which we want to move from the mc146818rtc.h header into the
rtc subsystem, which in turn is not usable on mn10300.

This changes mn10300 to use the modern rtc-cmos driver instead
of the old RTC driver, and that in turn lets us completely
remove the read_persistent_clock/update_persistent_clock callbacks.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

When building random configurations, we now occasionally get a new
build error:

   In file included from include/linux/kernel.h:13:0,
                    from include/linux/list.h:8,
                    from include/linux/preempt.h:10,
                    from include/linux/spinlock.h:50,
                    from arch/x86/kernel/nmi.c:13:
   arch/x86/kernel/nmi.c: In function 'nmi_max_handler':
   include/linux/printk.h:375:9: error: type defaults to 'int' in declaration of 'DEFINE_RATELIMIT_STATE' [-Werror=implicit-int]
     static DEFINE_RATELIMIT_STATE(_rs,    \
            ^
   arch/x86/kernel/nmi.c:110:2: note: in expansion of macro 'printk_ratelimited'
     printk_ratelimited(KERN_INFO
     ^~~~~~~~~~~~~~~~~~

This was working before the rtc rework series because linux/ratelimit.h
was included implictly through asm/mach_traps.h -> asm/mc146818rtc.h
-> linux/mc146818rtc.h -> linux/rtc.h -> linux/device.h.

We clearly shouldn't rely on this indirect inclusion, so this adds
an explicit #include in the file that needs it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Fixes: 5ab788d7 ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

While the EFI spec mandates an RTC, not every implementation actually adheres
to that rule (or can adhere to it - some systems just don't have an RTC).

For those, we really don't want to probe the EFI RTC driver at all, because if
we do we'd get a non-functional driver that does nothing useful but only spills
our kernel log with warnings.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Add support for Maxim max6916 RTC.
Signed-off-by: NVenkat Prashanth B U <venkat.prashanth2498@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Use sign_extend32() instead of open coding sign extension.
Signed-off-by: NMartin Kepplinger <martink@posteo.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The day of month is checked in ds1685_rtc_read_alarm
and ds1685_rtc_set_alarm.

Multiple errors exist in the day of month check.

Operator ! has a higher priority than &&.
(!(mday >= 1) && (mday <= 31)) is false for mday == 32.

When verifying the day of month the binary and the BCD mode
have to be considered.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

This patch fixes a RTC wakealarm issue, namely, the event fires during
hibernate and is not cleared from the list, causing hwclock to block.

The current enqueuing does not trigger an alarm if any expired timers
already exist on the timerqueue. This can occur when a RTC wake alarm
is used to wake a machine out of hibernate and the resumed state has
old expired timers that have not been removed from the timer queue.
This fix skips over any expired timers and triggers an alarm if there
are no pending timers on the timerqueue. Note that the skipped expired
timer will get reaped later on, so there is no need to clean it up
immediately.

The issue can be reproduced by putting a machine into hibernate and
waking it with the RTC wakealarm.  Running the example RTC test program
from tools/testing/selftests/timers/rtctest.c after the hibernate will
block indefinitely.  With the fix, it no longer blocks after the
hibernate resume.

BugLink: http://bugs.launchpad.net/bugs/1333569Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

sparc32:allmodconfig fails to build in next-20160602 as follows.

In file included from drivers/block/floppy.c:185:0:
include/linux/mc146818rtc.h: In function 'mc146818_is_updating':
include/linux/mc146818rtc.h:138:9: error: 'rtc_port' undeclared (first use in this function)
include/linux/mc146818rtc.h:138:9: note: each undeclared identifier is reported only once for each function it appears in
include/linux/mc146818rtc.h: In function 'mc146818_get_time':
include/linux/mc146818rtc.h:172:17: error: 'rtc_port' undeclared (first use in this function)
include/linux/mc146818rtc.h: In function 'mc146818_set_time':
include/linux/mc146818rtc.h:278:8: error: 'rtc_port' undeclared (first use in this function)
scripts/Makefile.build:295: recipe for target 'drivers/block/floppy.o' failed

The reason is a duplicate definition of the RTC_PORT macro. The
one in arch/sparc/include/asm/io_32.h was apparently used a long time
ago for the drivers/char/rtc.c driver that is not available on SPARC
any more, since we now select 'RTC_CLASS' unconditionally.

Removing the macro fixes the build problem, and for consistency,
this also removes the RTC_ALWAYS_BCD macro and the comment for both.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Fixes: fd09cc80165c ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

No architecture uses the genrtc driver any more, so let's kill it off
for good. This now also includes asm-generic/rtc.h, which is otherwise
completely unused.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason,
and it works fine without that header, so lets remove the inclusion
in preparation of deleting the file.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

All architectures using this driver are now converted to
provide their own operations, so this one can be turned
into a trivial stub driver relying on its platform data.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

PowerPC is the last architecture using the GEN_RTC driver on some
machines, but we can migrate them all to using the RTC_DRV_GENERIC
driver instead now.

This moves over the CONFIG_GEN_RTC option from drivers/char into
arch/powerpc/platforms/Kconfig and makes it just select the
replacement driver instead, for the only reason of not breaking
existing defconfig and .config files that users may have.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and powerpc has another abstraction on top, which is a bit
silly.

This changes the powerpc rtc-generic device to provide its
rtc_class_ops directly, to reduce the number of layers
by one.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>