Commit eed4d47e (ACPI / sleep: Ignore spurious SCI wakeups from
suspend-to-idle) modified the core suspend-to-idle code to filter
out spurious SCI interrupts received while suspended, which requires
ACPI event source handlers to report wakeup events in a way that
will trigger a wakeup from suspend to idle (or abort system suspends
in progress, which is equivalent).

That needs to be done in the rtc-cmos driver too, which was overlooked
by the above commit, so do that now.

Fixes: eed4d47e (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle)
Reported-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Function devm_ioremap() will return a NULL pointer if it fails to remap
IO address, and its return value should be validated before it is used.
However, in function gemini_rtc_probe(), its return value is not
checked. This may result in bad memory access bugs on future access,
e.g. calling the function gemini_rtc_read_time().
Signed-off-by: NPan Bian <bianpan2016@163.com>
Acked-by: NHans Ulli Kroll <ulli.kroll@googlemail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Function devm_regmap_init_mmio() returns an ERR_PTR on error. However,
in function snvs_rtc_probe() its return value is checked against NULL.
This patch fixes it by checking the return value with IS_ERR().
Signed-off-by: NPan Bian <bianpan2016@163.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.

Fixes: 920f91e5 ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: NMoritz Fischer <mdf@kernel.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.

Fixes: 920f91e5 ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: NMoritz Fischer <mdf@kernel.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The sh_rtc_set_irq_wake() function is only called from the suspend/resume handlers
that may be hidden, causing a harmless warning:

drivers/rtc/rtc-sh.c:724:13: error: 'sh_rtc_set_irq_wake' defined but not used [-Werror=unused-function]
 static void sh_rtc_set_irq_wake(struct device *dev, int enabled)

The most reliable way to avoid the warning is to remove the existing #ifdef
and mark the two functions as __maybe_unused so the compiler can silently
drop all three when there is no reference.

Fixes: dab5aec6 ("rtc: sh: add support for rza series")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

devm_rtc_device_register() doesn't ever return NULL so there is no need
to check.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The correct compatible for the rv4162 (microcrystal,rv4162) was not used
upstream and so was not added by eb235c56.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

m41t0 was added to the I2C device ID table but not the OF table. Fix that.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The m41t0 variant is very similar to the already supported m41t00
variant, with the notable exception of the oscillator fail bit.
The data sheet notes:

  If the oscillator fail (OF) bit is internally set to a '1,' this
  indicates that the oscillator has either stopped, or was stopped
  for some period of time and can be used to judge the validity of
  the clock and date data.

The bit will get cleared with a regular write of the system time,
so no changes are needed to clear it.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

There's a funny typo where IRQ_NONE is used instead of IRQF_TRIGGER_NONE
for request_threaded_irq(). Let's fix it before it gets copied elsewhere.

Fixes: dd3bf50b ("rtc: cpcap: new rtc driver")
Signed-off-by: NTony Lindgren <tony@atomide.com>
Reviewed-By: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

On some systems (e.g. Intel Bay Trail systems) the legacy PIC is not
used, in this case virq 8 will be a random irq, rather then hw_irq 8
from the PIC.

Requesting virq 8 in this case will not help us to get alarm irqs and
may cause problems for other drivers which actually do need virq 8,
for example on an Asus Transformer T100TA this leads to:

[ 28.745155] genirq: Flags mismatch irq 8. 00000088 (mmc0) vs. 00000080 (rtc0)
<snip oops>
[ 28.753700] mmc0: Failed to request IRQ 8: -16
[ 28.975934] sdhci-acpi: probe of 80860F14:01 failed with error -16

This commit fixes this by making the rtc-cmos driver continue
without using an irq rather then claiming irq 8 when no irq is
specified in the pnp-info and there are no legacy-irqs.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

This same RTC is used in RZ/A series MPUs, therefore with some slight
changes, this driver can be reused. Additionally, since ARM architectures
require Device Tree configurations, device tree support has been added.
Signed-off-by: NChris Brandt <chris.brandt@renesas.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Mostly straightforward, but we had to remove the rtc_dev_add/del_device
functions as they split up the cdev_add and the device_add.

Doing this also revealed that there was likely another subtle bug:
seeing cdev_add was done after device_register, the cdev probably
was not ready before device_add when the uevent occurs. This would
race with userspace, if it tried to use the device directly after
the uevent. This is fixed just by using the new helper function.

Another weird thing is this driver would, in some error cases, call
cdev_add() without calling cdev_init. This patchset corrects this
by avoiding calling cdev_add if the devt is not set.
Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
Acked-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We shouldn't kfree(rtc) because is devm_ managed memory.  It leads to a
double free.

Fixes: dd3bf50b ("rtc: cpcap: new rtc driver")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-By: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The to_wm8350_from_rtc_dev macro is not used by anything in the
rtc-wm8350 driver.
Signed-off-by: NNobuhiro Iwamatsu <iwamatsu@nigauri.org>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

This driver supports the Motorola CPCAP PMIC found on
some of Motorola's mobile phones, such as the Droid 4.
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Instead of using #ifdef guards around PM methods, let's annotate
them as __maybe_unused, as it provides better compile coverage.

Also drop empty stub for omap_rtc_runtime_resume().
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Even if bus is not hot-pluggable, devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods. The only exception is drivers registered with
platform_driver_probe(), which specifically disables sysfs bind/unbind
attributes.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-By: NSebastian Reichel <sre@kernel.org>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver has a OF device ID table but the struct i2c_driver
.of_match_table field is not set.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>

Fix up affected files that include this signal functionality via sched.h.
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

The wakealarm attribute is currently not exposed in the sysfs interface
as the device has not been set as doing wakealarm when device_register
is called. Changing the order of the calls fixes that problem. Interrupts
are cleared in check_rtc_status prior to requesting the interrupt.

This is only set if an irq is defined. If irq registration fails then
set wakeup_capable to false. With this change the sysfs wakealarm
attribute will be left visible but it is non functional. rtcwake
still returns that the device is not enabled for wakeup.
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Read control registers one by one and bulk read time registers.
This fixes when the clock is read, the watchdog counter register is zeroed.
Signed-off-by: NSean Nyekjaer <sean.nyekjaer@prevas.dk>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

The Armada 7K/8K use the same RTC IP than the Armada 38x. However the SOC
integration differs in 2 points:
 - MBUS bridge timing initialization
 - IRQ configuration at SoC level

Moreover the Armada 7K/8K have an issue preventing to get the interrupt
from alarm 1. This commit allows to use alarm 2 for these A7K/8K but to
still use alarm 1 for the Armada 38x.
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

In order to prepare the introduction of the A7K/A8K version of the RTC,
this commit introduces a new data structure. This structure allows to
handle the differences between the integration of the RTC IP in the
SoCs. It will be:
 - MBUS bridge timing initialization
 - IRQ configuration at SoC level
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Add the max_register  to the regmap_config definition. This allows
dumping of the device's registers via the regmap debugfs interface.
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

Whitespace was a combination of spaces and tabs.
Use spaces and align register / bit definitions.
Signed-off-by: NPhil Reid <preid@electromag.com.au>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

All users of this driver have been updated to allow the driver to
manage it's own resources and do the read/write operations internally.
The m48t86_ops are no longer used.

Remove the platform_data header and the support code in the driver.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>