clk_enable() can fail so handle such case.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
clk_prepare_enable() can fail so handle such case.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
All instances of struct s3c_rtc_data are in fact static const thus
put in rodata so we should not drop the const while getting the pointer
to them.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
There is no need for casting to void pointer for of_device_id data.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Minor cleanups to make the code easier to read. No functional changes.
1. Remove one space before labels as this is nowadays mostly preferred.
2. Fix indentation of arguments in function calls.
3. Split structure member declaration.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
In other error paths in probe, centralized exit point was used so make
this consistent.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This variable was never used. With GCC 6.2, we get the following warning:
drivers/rtc/rtc-mxc.c:44:18: warning: ‘PIE_BIT_DEF’ defined but not used [-Wunused-const-variable=]
static const u32 PIE_BIT_DEF[MAX_PIE_NUM][2] = {
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Provide an implementation of the callback
rtc_class_ops.alarm_irq_enable for rtc-opal driver. This callback is
called when the wake alarm is disabled via the command:
'echo 0 > /sys/class/rtc/rtc0/wakealarm'
Without this the Timed-Power-On(TPO) config remains set even when its
disabled by the above command and FSP will still force machine
boot at previously configured alarm time.
The callback is implemented as function opal_tpo_alarm_irq_enable()
which calls opal_set_tpo_time() with alarm.enabled == 0. A branch is
added to opal_set_tpo_time() to handle this case by passing y_m_d ==
h_m_s_ms == 0 to opal as arguments for opal_tpo_write() call.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
rtc->name is only used in messages were it is superfluous. Remove it
completely from the structure.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
rtc->name is superfluous here because the rtc is already registered at that
point and its name has already been printed.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The name sysfs attribute is not useful in its current form because of all
the drivers:
- 3 are using the feature correctly
- 2 are clearly misusing it
- 60 are using driver.name, either directly or indirectly
- 46 are using pdev->name
- 8 are using client->name
- 31 are using a variation of driver.name (addition or removal of rtc-,
-rtc, _rtc, rtc_)
Make it uniform and use the driver name and the device name.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
In function __rtc_read_alarm() its possible for an alarm time-stamp to
be invalid even after replacing missing components with current
time-stamp. The condition 'alarm->time.tm_year < 70' will trigger this
case and will cause the call to 'rtc_tm_to_time64(&alarm->time)'
return a negative value for variable t_alm.
While handling alarm rollover this negative t_alm (assumed to seconds
offset from '1970-01-01 00:00:00') is converted back to rtc_time via
rtc_time64_to_tm() which results in this error log with seemingly
garbage values:
"rtc rtc0: invalid alarm value: -2-1--1041528741
2005511117:71582844:32"
This error was generated when the rtc driver (rtc-opal in this case)
returned an alarm time-stamp of '00-00-00 00:00:00' to indicate that
the alarm is disabled. Though I have submitted a separate fix for the
rtc-opal driver, this issue may potentially impact other
existing/future rtc drivers.
To fix this issue the patch validates the alarm time-stamp just after
filling up the missing datetime components and if rtc_valid_tm() still
reports it to be invalid then bails out of the function without
handling the rollover.
Reported-by: Steve Best <sbest@redhat.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
On PowerNV platform when Timed-Power-On(TPO) is disabled, read of
stored TPO yields value with all date components set to '0' inside
opal_get_tpo_time(). The function opal_to_tm() then converts it to an
offset from year 1900 yielding alarm-time == "1900-00-01
00:00:00". This causes problems with __rtc_read_alarm() that
expecting an offset from "1970-00-01 00:00:00" and returned alarm-time
results in a -ve value for time64_t. Which ultimately results in this
error reported in kernel logs with a seemingly garbage value:
"rtc rtc0: invalid alarm value: -2-1--1041528741
2005511117:71582844:32"
We fix this by explicitly handling the case of all alarm date-time
components being '0' inside opal_get_tpo_time() and returning -ENOENT
in such a case. This signals generic rtc that no alarm is set and it
bails out from the alarm initialization flow without reporting the
above error.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Reported-by: Steve Best <sbest@redhat.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Some devices supported by the m41t80 driver have a programmable
square-wave output signal (see M41T80_FEATURE_SQ).
This enables to use this feature as a clock provider of common
clock framework.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
In order to use the proper clock framework to control this feature.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This patch is only relevant for RTC with the SQ_ALT feature which
means the clock output frequency divider is stored in the weekday
register.
Current implementation discards the previous dividers value and clear
them as soon as the time is set.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Currently setting an alarm clears the SQWE bit which means that the
clock output is disabled no matter its previous state.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This patch extends the fixes for ds1337, ds1339, ds3231 in commit
8bc2a40730 ("rtc: ds1307: add support for the DT property
'wakeup-source'") to mcp794xx devices, so that those parts can similarly be
used as a wakeup source without an IRQ to the processor.
Tested on Raspberry Pi ZeroW with MCP79400.
Signed-off-by: David Lowe <dave-lowe@ntlworld.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
This patch converts the ds1307 driver to using regmap. It's a rather
big patch and I can test with DS3231 only. With this chip it's
working fine.
I'd appreciate if people with other supported hardware could test as
well.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Subsystem:
- Add OF device ID table for i2c drivers
New driver:
- Motorola CPCAP PMIC RTC
Drivers:
- cmos: fix IRQ selection
- ds1307: Add ST m41t0 support
- ds1374: fix watchdog configuration
- sh: Add rza series support
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEXx9Viay1+e7J/aM4AyWl4gNJNJIFAlkTf2sACgkQAyWl4gNJ
NJLPvw//dGzo6oD3C96QIurfrgFx9512ZurEiJpGPIO15obTVLF0SNuswaMj7knm
ezqQ23qX9VBEmu3si7LvkQVbE60giB3XnlJ/wpFi/LhtlM7SQ4o2Z8Go3rkL8tCw
iPcj5l3ShbHgSF+TBK+jK5C/8ahR7RE32l2rtSi9xwzxOmKRySmSWg2iGmGJMNUU
7UHR4DRHVPS/h1ffM/rOWV+d3GVK9laNmeoIORhsWCa+iYwGRZr3XL3GXQzhehBO
H5uFYewMVBHREADiqMNQ/ogHZI+ghXt1OSK7vhUFkYxosqU56P0YtU6SPH6UuFsH
ryoiUmCgQQjjhptlvVv71D7Wj1txSCT6rByQU1YyVZ0yw9XpVuGTYBjFBY+D7nxb
e3sR+Poe3diVLWDwFTXStrY0TtVlCTTCjs5T2kwUdYOJ188expQGHgj6wVl7PPTs
gpeSIunekbop13KCPWV01TzmRLB8ne9ZiomsuiNnuAKhXP7KRf6AfuQd6kpyvpmH
vhGcEIe7O0i4TwUIuB/dmdhLHmlOqCpLJpGQihNc+f0jJAxHv+akXEQ06H84FkJD
kPkBYSVDp/2pEBdf7ig2mlpPEqANgoQY8GCu9SbEg976g0v8k6m+i9IlbR0m7hwE
0XF+8W45iNsaEIzoXcyHuB/lrUy1/0eNoG4KX8vyWIjITo5HQWg=
=40TA
-----END PGP SIGNATURE-----
Merge tag 'rtc-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"RTC subsystem update:
- Add OF device ID table for i2c drivers
New RTC driver:
- Motorola CPCAP PMIC RTC
RTC driver updates:
- cmos: fix IRQ selection
- ds1307: Add ST m41t0 support
- ds1374: fix watchdog configuration
- sh: Add rza series support"
* tag 'rtc-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (33 commits)
rtc: gemini: add return value validation
rtc: snvs: fix an incorrect check of return value
rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL
rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks
rtc: sh: mark PM functions as unused
rtc: hid-sensor-time: remove some dead code
rtc: m41t80: Add proper compatible for rv4162
rtc: ds1307: Add m41t0 to OF device ID table
rtc: ds1307: support m41t0 variant
rtc: cpcap: fix improper use of IRQ_NONE for request_threaded_irq
rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs
x86: i8259: export legacy_pic symbol
dt-bindings: rtc: document the rtc-sh bindings
rtc: sh: add support for rza series
rtc: cpcap: kfreeing devm allocated memory
rtc: wm8350: Remove unused to_wm8350_from_rtc_dev
rtc: cpcap: new rtc driver
dt-bindings: Add vendor prefix for Motorola
rtc: omap: mark PM methods as __maybe_unused
rtc: omap: remove incorrect __exit markups
...
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: Pan Bian <bianpan2016@163.com>
Acked-by: Hans Ulli Kroll <ulli.kroll@googlemail.com>
Signed-off-by: Alexandre 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: Pan Bian <bianpan2016@163.com>
Signed-off-by: Alexandre 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: 920f91e50c ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Alexandre 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: 920f91e50c ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Alexandre 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: dab5aec64b ("rtc: sh: add support for rza series")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre 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: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
The correct compatible for the rv4162 (microcrystal,rv4162) was not used
upstream and so was not added by eb235c561d.
Signed-off-by: Alexandre 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: Stefan Agner <stefan@agner.ch>
Signed-off-by: Alexandre 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: dd3bf50b35 ("rtc: cpcap: new rtc driver")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Reviewed-By: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Alexandre 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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Alexandre 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: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Alexandre 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: Logan Gunthorpe <logang@deltatee.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We shouldn't kfree(rtc) because is devm_ managed memory. It leads to a
double free.
Fixes: dd3bf50b35 ("rtc: cpcap: new rtc driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-By: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Alexandre 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: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Alexandre 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: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Alexandre 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: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Alexandre 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: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-By: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre 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: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
