The I²C NACK issue of the RV-8803 may occur after any I²C START
condition, depending on the timings. Consequently, the workaround must
be applied for all the I²C transfers.

This commit abstracts the I²C transfer code into register access
functions. This avoids duplicating the I²C workaround everywhere. This
also avoids the duplication of the code handling the return value of
i2c_smbus_read_i2c_block_data(). Error messages are issued in case of
definitive register access failures (if the workaround fails). This
change also makes the I²C transfer return value checks consistent.
Signed-off-by: NBenoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The Weekday register is encoded as 2^tm_wday, with tm_wday in 0..6, so
using tm_wday = ffs(reg) to fill tm_wday from the register value is
wrong because this gives the expected value + 1. This could be fixed as
tm_wday = ffs(reg) - 1, but tm_wday = ilog2(reg) works as well and is
more direct.
Signed-off-by: NBenoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The RTC core always calls rtc_valid_tm() after ->read_time() in case of
success (in __rtc_read_time()), so do not call it twice.
Signed-off-by: NBenoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

This driver supports the Epson RX8900, but this was not indicated in
Kconfig.
Signed-off-by: NBenoît Thébaudeau <benoit@wsystem.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Remove .owner field if calls are used which set it automatically.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: NWei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver allocates the spinlock but not initialize it.
Use spin_lock_init() on it to initialize it correctly.

This is detected by Coccinelle semantic patch.
Signed-off-by: NWei Yongjun <weiyj.lk@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Allow the alarm IRQ of RTC to be used as a wakeup source for the system
suspend.
Signed-off-by: NStefan Christ <s.christ@phytec.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

It should be a real error message, when the driver cannot enable the IRQ
of the device.
Signed-off-by: NStefan Christ <s.christ@phytec.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The current rtc-pcf85063 driver only supports the PCF85063TP device.
Using the existing driver on a PCF85063A will result in the time being
set correctly into the RTC, but the RTC is held in the stopped state.
Therefore, the time will no longer advance and no error is indicated.

The PCF85063A device has a bigger memory map than the PCF85063TP.
The existing driver make use of an address rollover condition,
but the rollover point is different in the two devices.
Signed-off-by: NChris DeBruin <cdeb5783@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The year range is not validated properly

As the driver has been mainlined in 2014, it is not an issue to stop
handling dates between 1970 and 2000 with the benefit of handling dates up
to 2100.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

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>