Age | Commit message (Collapse) | Author |
|
The recent change to validate the RTC turned out to be overly tight.
While it cures the problem on the reporters machine it breaks machines
with Intel chipsets which use bit 0-5 of the D register. So check only
for bit 6 being 0 which is the case on these Intel machines as well.
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Reported-by: Serge Belyshev <belyshev@depni.sinp.msu.ru>
Reported-by: Dirk Gouders <dirk@gouders.net>
Reported-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dirk Gouders <dirk@gouders.net>
Tested-by: Len Brown <len.brown@intel.com>
Tested-by: Borislav Petkov <bp@suse.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/87zh0nbnha.fsf@nanos.tec.linutronix.de
|
|
The recent fix for handling the UIP bit unearthed another issue in the RTC
code. If the RTC is advertised but the readout is straight 0xFF because
it's not available, the old code just proceeded with crappy values, but the
new code hangs because it waits for the UIP bit to become low.
Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID
register (Register D) which should have bit 0-6 cleared. If that's not the
case then fail to register the CMOS.
Add the same check to mc146818_get_time(), warn once when the condition
is true and invalidate the rtc_time data.
Reported-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Mickaël Salaün <mic@linux.microsoft.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/87tur3fx7w.fsf@nanos.tec.linutronix.de
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"Subsystem:
- Remove nvram ABI. There was no complaints about the deprecation for
the last 3 years.
- Improve RTC device allocation and registration
- Now available for ARCH=um
Drivers:
- at91rm9200: correction and sam9x60 support
- ds1307: improve ACPI support
- mxc: now DT only
- pcf2127: watchdog support now needs the reset-source property
- pcf8523: set range
- rx6110: i2c support"
* tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (43 commits)
rtc: pcf2127: only use watchdog when explicitly available
dt-bindings: rtc: add reset-source property
rtc: fix RTC removal
rtc: s3c: Remove dead code related to periodic tick handling
rtc: s3c: Disable all enable (RTC, tick) bits in the probe
rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time
rtc: test: remove debug message
rtc: mxc{,_v2}: enable COMPILE_TEST
rtc: enable RTC framework on ARCH=um
rtc: pcf8523: use BIT
rtc: pcf8523: set range
rtc: pcf8523: switch to devm_rtc_allocate_device
rtc: destroy mutex when releasing the device
rtc: shrink devm_rtc_allocate_device()
rtc: rework rtc_register_device() resource management
rtc: nvmem: emit an error message when nvmem registration fails
rtc: add devm_ prefix to rtc_nvmem_register()
rtc: nvmem: remove nvram ABI
Documentation: list RTC devres helpers in devres.rst
rtc: omap: use devm_pinctrl_register()
...
|
|
Most boards using the pcf2127 chip (in my bubble) don't make use of the
watchdog functionality and the respective output is not connected. The
effect on such a board is that there is a watchdog device provided that
doesn't work.
So only register the watchdog if the device tree has a "reset-source"
property.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
[RV: s/has-watchdog/reset-source/]
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201218101054.25416-3-rasmus.villemoes@prevas.dk
|
|
Since the rtc_register_device, removing an RTC device will end with a
refcount_t: underflow; use-after-free warning since put_device is called
twice in the device tear down path.
Fixes: fdcfd854333b ("rtc: rework rtc_register_device() resource management")
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20201205231449.610980-1-alexandre.belloni@bootlin.com
|
|
The current RTC set_offset_nsec value is not really intuitive to
understand.
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
The offset is calculated from twrite based on the assumption that t2 -
twrite == 1s. That means for the MC146818 RTC the offset needs to be
negative so that the write happens 500ms before t2.
It's easier to understand when the whole calculation is based on t2. That
avoids negative offsets and the meaning is obvious:
t2 - twrite: The time defined by the chip when seconds increment
after the write.
twrite - tsched: The time for the transport to the point where the chip
is updated.
==> set_offset_nsec = t2 - tsched
ttransport = twrite - tsched
tRTCinc = t2 - twrite
==> set_offset_nsec = ttransport + tRTCinc
tRTCinc is a chip property and can be obtained from the data sheet.
ttransport depends on how the RTC is connected. It is close to 0 for
directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the
time required to send the update over the bus. This can be estimated or
even calibrated, but that's a different problem.
Adjust the implementation and update comments accordingly.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de
|
|
rtc_set_ntp_time() is not really RTC functionality as the code is just a
user of RTC. Move it into the NTP code which allows further cleanups.
Requested-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220542.166871172@linutronix.de
|
|
The offset which is used to steer the start of an RTC synchronization
update via rtc_set_ntp_time() is huge. The math behind this is:
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
twrite - tsched is the transport time for the write to hit the device.
t2 - twrite depends on the chip and is for most chips one second.
The rtc_set_ntp_time() calculation of tsched is:
tsched = t2 - 1sec - (t2 - twrite)
The default for the sync offset is 500ms which means that twrite - tsched
is 500ms assumed that t2 - twrite is one second.
This is 0.5 seconds off for RTCs which are directly accessible by IO writes
and probably for the majority of i2C/SPI based RTC off by an order of
magnitude. Set it to 5ms which should bring it closer to reality.
The default can be adjusted by drivers (rtc_cmos does so) and could be
adjusted further by a calibration method which is an orthogonal problem.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.960333166@linutronix.de
|
|
The offset for rtc_cmos must be -500ms to work correctly with the current
implementation of rtc_set_ntp_time() due to the following:
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
twrite - tsched is the transport time for the write to hit the device,
which is negligible for this chip because it's accessed directly.
t2 - twrite = 500ms according to the datasheet.
But rtc_set_ntp_time() calculation of tsched is:
tsched = t2 - 1sec - (t2 - twrite)
The default for the sync offset is 500ms which means that the write happens
at t2 - 1.5 seconds which is obviously off by a second for this device.
Make the offset -500ms so it works correct.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.830517160@linutronix.de
|
|
No need to hold the lock and disable interrupts for doing math.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.709243630@linutronix.de
|
|
The MC146818 driver is prone to read garbage from the RTC. There are
several issues all related to the update cycle of the MC146818. The chip
increments seconds obviously once per second and indicates that by a bit in
a register. The bit goes high 244us before the actual update starts. During
the update the readout of the time values is undefined.
The code just checks whether the update in progress bit (UIP) is set before
reading the clock. If it's set it waits arbitrary 20ms before retrying,
which is ample because the maximum update time is ~2ms.
But this check does not guarantee that the UIP bit goes high and the actual
update happens during the readout. So the following can happen
0.997 UIP = False
-> Interrupt/NMI/preemption
0.998 UIP -> True
0.999 Readout <- Undefined
To prevent this rework the code so it checks UIP before and after the
readout and if set after the readout try again.
But that's not enough to cover the following:
0.997 UIP = False
Readout seconds
-> NMI (or vCPU scheduled out)
0.998 UIP -> True
update completes
UIP -> False
1.000 Readout minutes,....
UIP check succeeds
That can make the readout wrong up to 59 seconds.
To prevent this, read the seconds value before the first UIP check,
validate it after checking UIP and after reading out the rest.
It's amazing that the original i386 code had this actually correct and
the generic implementation of the MC146818 driver got it wrong in 2002 and
it stayed that way until today.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.594826678@linutronix.de
|
|
Support for periodic tick interrupts has been moved from the RTC class to
the HR-timers long time ago. Then it has been removed from this driver by
commits 80d4bb515b78 ("RTC: Cleanup rtc_class_ops->irq_set_state") and
696160fec162 ("RTC: Cleanup rtc_class_ops->irq_set_freq()"). They however
did not remove all the code related to the tick handling. Do it now then.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201202111318.5353-2-m.szyprowski@samsung.com
|
|
Bootloader might use RTC hardware and leave it in the enabled state. Ensure
that the potentially enabled periodic tick interrupts are disabled before
enabling the driver, because they might cause lockup if tick interrupt
happens after disabling RTC gate clock.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20201202111318.5353-1-m.szyprowski@samsung.com
|
|
Mismatch in probe platform_set_drvdata set's and method's that call
dev_get_platdata will result in "Unable to handle kernel NULL pointer
dereference", let's use according method for getting driver data after
platform_set_drvdata.
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.10-00003-g723e101e0037-dirty #4
Hardware name: Technologic Systems TS-72xx SBC
PC is at ep93xx_rtc_read_time+0xc/0x2c
LR is at __rtc_read_time+0x4c/0x8c
[...]
[<c02b01c8>] (ep93xx_rtc_read_time) from [<c02ac38c>] (__rtc_read_time+0x4c/0x8c)
[<c02ac38c>] (__rtc_read_time) from [<c02ac3f8>] (rtc_read_time+0x2c/0x4c)
[<c02ac3f8>] (rtc_read_time) from [<c02acc54>] (__rtc_read_alarm+0x28/0x358)
[<c02acc54>] (__rtc_read_alarm) from [<c02abd80>] (__rtc_register_device+0x124/0x2ec)
[<c02abd80>] (__rtc_register_device) from [<c02b028c>] (ep93xx_rtc_probe+0xa4/0xac)
[<c02b028c>] (ep93xx_rtc_probe) from [<c026424c>] (platform_drv_probe+0x24/0x5c)
[<c026424c>] (platform_drv_probe) from [<c0262918>] (really_probe+0x218/0x374)
[<c0262918>] (really_probe) from [<c0262da0>] (device_driver_attach+0x44/0x60)
[<c0262da0>] (device_driver_attach) from [<c0262e70>] (__driver_attach+0xb4/0xc0)
[<c0262e70>] (__driver_attach) from [<c0260d44>] (bus_for_each_dev+0x68/0xac)
[<c0260d44>] (bus_for_each_dev) from [<c026223c>] (driver_attach+0x18/0x24)
[<c026223c>] (driver_attach) from [<c0261dd8>] (bus_add_driver+0x150/0x1b4)
[<c0261dd8>] (bus_add_driver) from [<c026342c>] (driver_register+0xb0/0xf4)
[<c026342c>] (driver_register) from [<c0264210>] (__platform_driver_register+0x30/0x48)
[<c0264210>] (__platform_driver_register) from [<c04cb9ac>] (ep93xx_rtc_driver_init+0x10/0x1c)
[<c04cb9ac>] (ep93xx_rtc_driver_init) from [<c000973c>] (do_one_initcall+0x7c/0x1c0)
[<c000973c>] (do_one_initcall) from [<c04b9ecc>] (kernel_init_freeable+0x168/0x1ac)
[<c04b9ecc>] (kernel_init_freeable) from [<c03b2228>] (kernel_init+0x8/0xf4)
[<c03b2228>] (kernel_init) from [<c00082c0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc441dfb0 to 0xc441dff8)
dfa0: 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: e12fff1e e92d4010 e590303c e1a02001 (e5933000)
---[ end trace c914d6030eaa95c8 ]---
Fixes: b809d192eb98 ("rtc: ep93xx: stop setting platform_data")
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201201095507.10317-1-nikita.shubin@maquefel.me
|
|
Remove leftover debug message
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201121230644.572419-1-alexandre.belloni@bootlin.com
|
|
Extend code coverage for the rtc-mxc and rtc-mxc-v2 drivers.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201121224529.568237-1-alexandre.belloni@bootlin.com
|
|
There's no real reason it should be disabled, and at least we can
use it for development & testing with the RTC test driver.
However, two devices are missing a HAS_IOMEM dependency, so add
that to avoid build failures from e.g. allyesconfig.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201120211103.6895ac740d11.Ic19a9926e8e4c70c03329e55f9e5b1d45095b904@changeid
|
|
Use the BIT macro to define register bits.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201118002747.1346504-3-alexandre.belloni@bootlin.com
|
|
Set the th RTC range, it is a classic BCD RTC, considering 00 as a leap
year. Let the core handle range checking.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201118002747.1346504-2-alexandre.belloni@bootlin.com
|
|
Switch to devm_rtc_allocate_device/devm_rtc_register_device, this allows
for further improvement of the driver.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201118002747.1346504-1-alexandre.belloni@bootlin.com
|
|
Not destroying mutexes doesn't lead to resource leak but it's the correct
thing to do for mutex debugging accounting.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201110094205.8972-1-brgl@bgdev.pl
|
|
We don't need to use devres_alloc() & devres_add() manually if all we
want to manage is a single pointer. We can shrink the code by using
devm_add_action_or_reset() instead. The number of allocations stays
the same.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-9-brgl@bgdev.pl
|
|
rtc_register_device() is a managed interface but it doesn't use devres
by itself - instead it marks an rtc_device as "registered" and the devres
callback for devm_rtc_allocate_device() takes care of resource release.
This doesn't correspond with the design behind devres where managed
structures should not be aware of being managed. The correct solution
here is to register a separate devres callback for unregistering the
device.
While at it: rename rtc_register_device() to devm_rtc_register_device()
and add it to the list of managed interfaces in devres.rst. This way we
can avoid any potential confusion of driver developers who may expect
there to exist a corresponding unregister function.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl
|
|
Some users check the return value of devm_rtc_nvmem_register() only in
order to emit an error message and then continue probing. This is fine
as an rtc can function without exposing nvmem but let's generalize it:
let's make the registration function emit the error message so that
users don't have to.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-7-brgl@bgdev.pl
|
|
rtc_nvmem_register() is a managed interface. It doesn't require any
release function to be called at driver detach. To avoid confusing
driver authors, let's rename it to devm_rtc_nvmem_register() and add it
to the list of managed interfaces in Documentation/.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-6-brgl@bgdev.pl
|
|
The nvram sysfs attributes have been deprecated at least since v4.13, more
than 3 years ago and nobody ever complained about the deprecation warning.
Remove the sysfs attributes now.
[Bartosz: remove the declaration of rtc_nvmem_unregister()]
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20201109163409.24301-5-brgl@bgdev.pl
|
|
Use a managed variant of pinctrl_register(). This way we can shorten
the remove() callback as well as drop a goto label from probe().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-2-brgl@bgdev.pl
|
|
The RTC core only reads the alarm from the hardware at boot time, to know
whether an alarm was already set before booting. It keeps track of all the
alarms after that so there is no need to ever read the auxiliary alarm.
Commit 3822d1bb0df1 ("rtc: sc27xx: Always read normal alarm when
registering RTC device") already effectively removed the capability to read
the auxiliary alarm as .read_alarm is always called with rtc->registered set
to false.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Chunyan Zhang <zhang.lyra@gmail.com>
Link: https://lore.kernel.org/r/20201117212201.1288608-1-alexandre.belloni@bootlin.com
|
|
Use of_device_get_match_data to simplify mxc_rtc_probe.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20201117203035.1280099-1-alexandre.belloni@bootlin.com
|
|
Since 5.10-rc1 i.MX is a devicetree-only platform, so simplify the code
by removing the unused non-DT support.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201116180326.5199-1-festevam@gmail.com
|
|
The RX6110 also supports I2C, so this patch adds support for it to the
driver.
This also renames the SPI specific functions and variables to include
`_spi_` in their names.
Signed-off-by: Claudius Heine <ch@denx.de>
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201117121817.953924-3-ch@denx.de
|
|
The help message in the Kconfig for the RX-6110 erronously stated
RX-6610.
Signed-off-by: Claudius Heine <ch@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201117121817.953924-2-ch@denx.de
|
|
These prevent use of this driver with ACPI via PRP0001.
Drop them to remove this restriction.
Also added mod_devicetable.h include given use of struct of_device_id.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201116142859.31257-3-andriy.shevchenko@linux.intel.com
|
|
Device property API allows to gather device resources from different sources,
such as ACPI. Convert the drivers to unleash the power of device property API.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201116142859.31257-2-andriy.shevchenko@linux.intel.com
|
|
The commit 9c19b8930d2c ("rtc: ds1307: Add ACPI support") added invalid
ACPI IDs (all of them are abusing ACPI specification). Moreover there is
not even a single evidence that vendor registered any of such devices.
Remove broken ACPI IDs from the driver. For prototyping one may use PRP0001
with device properties adhering to a DT binding. The following patches
will add support of that to the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Tin Huynh <tnhuynh@apm.com>
Link: https://uefi.org/PNP_ACPI_Registry
Link: https://lore.kernel.org/r/20201116142859.31257-1-andriy.shevchenko@linux.intel.com
|
|
Handle the sam9x60 RTC. While it can work with the at91sam9x5 fallback, it
has crystal correction support and doesn't need to shadow IMR.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20201117133920.1229679-1-alexandre.belloni@bootlin.com
|
|
The sama5d4 and sama5d2 RTCs are able to correct for imprecise crystals, up
to 1953 ppm.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20201108232001.1580128-1-alexandre.belloni@bootlin.com
|
|
The nvmem priv pointer is set to rv3032 but the rv3032_nvram_write and
rv3032_nvram_read expect the regmap pointer.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201108223710.1574331-1-alexandre.belloni@bootlin.com
|
|
Goldfish platform is covered with dust.
However the goldfish-rtc had been used as virtualized RTC
in QEMU for RISC-V virt hw and MIPS loongson3-virt hw, thus
we can drop other parts of goldfish but leave goldfish-rtc here.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201114130921.651882-2-jiaxun.yang@flygoat.com
|
|
Because clk_* already checked NULL clock parameter,
so the additional checks are unnecessary, just remove them.
Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201113080305.65961-1-vulab@iscas.ac.cn
|
|
Because clk_disable_unprepare() already checked NULL clock parameter,
so the additional check is unnecessary, just remove it.
Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20201113074538.65028-1-vulab@iscas.ac.cn
|
|
When devm_rtc_allocate_device is failed in pl031_probe, it should release
mem regions with device.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zheng Liang <zhengliang6@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20201112093139.32566-1-zhengliang6@huawei.com
|
|
Coccinelle noticed:
drivers/rtc/rtc-cpcap.c:271:7-32: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
drivers/rtc/rtc-cpcap.c:287:7-32: ERROR: Threaded IRQ with no
primary handler requested without IRQF_ONESHOT
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1605000947-32882-1-git-send-email-tiantao6@hisilicon.com
|
|
Enable wakeup in the hym8563 driver if the IRQ was successfully
requested or if wakeup-source is set in the devicetree.
As per the description of device_init_wakeup(), it should be enabled
for "devices that everyone expects to be wakeup sources". One would
expect this to be the case with a real-time clock.
Tested on rk3288-rock2-square, which has an IRQ configured for the
RTC. As a result, wakeup was enabled during driver initialisation.
Fixes: dcaf03849352 ("rtc: add hym8563 rtc-driver")
Reported-by: kernelci.org bot <bot@kernelci.org>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1ea023e2ba50a4dab6e39be93d7de3146af71a60.1604653374.git.guillaume.tucker@collabora.com
|
|
Fix the following coccicheck warning:
./drivers/rtc/rtc-da9063.c:246:5-18: WARNING: Comparison to bool
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1604649637-1014-1-git-send-email-kaixuxia@tencent.com
|
|
Here we could use the '!=' expression to fix the following coccicheck
warning:
./drivers/rtc/rtc-sc27xx.c:566:50-55: WARNING: conversion to bool not needed here
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Kaixu Xia <kaixuxia@tencent.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1604647854-876-1-git-send-email-kaixuxia@tencent.com
|
|
When clk_hw_register_fixed_rate_with_accuracy() fails,
clk_data should be freed. It's the same for the subsequent
two error paths, but we should also unregister the already
registered clocks in them.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201020061226.6572-1-dinghao.liu@zju.edu.cn
|
|
These functions should return zero on success. Non-zero returns are
treated as error. On some paths, this doesn't matter but in
nvmem_cell_read() a non-zero return would be passed to ERR_PTR() and
lead to an Oops.
Fixes: d6c3029f32f7 ("rtc: pcf2127: add support for accessing internal static RAM")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201022070451.GA2817669@mwanda
|
|
The obvious advantages are:
- The linker can drop the watchdog functions if CONFIG_WATCHDOG is off.
- All watchdog stuff grouped together with only a single function call
left in generic code.
- Watchdog register is only read when it is actually used.
- Less #ifdefery
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20200924105256.18162-2-u.kleine-koenig@pengutronix.de
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"A new driver this cycle is making the bulk of the changes and the
rx8010 driver has been rework to use the modern APIs.
Summary:
Subsystem:
- new generic DT properties: aux-voltage-chargeable,
trickle-voltage-millivolt
New driver:
- Microcrystal RV-3032
Drivers:
- ds1307: use aux-voltage-chargeable
- r9701, rx8010: modernization of the driver
- rv3028: fix clock output, trickle resistor values, RAM
configuration registers"
* tag 'rtc-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (50 commits)
rtc: r9701: set range
rtc: r9701: convert to devm_rtc_allocate_device
rtc: r9701: stop setting RWKCNT
rtc: r9701: remove useless memset
rtc: r9701: stop setting a default time
rtc: r9701: remove leftover comment
rtc: rv3032: Add a driver for Microcrystal RV-3032
dt-bindings: rtc: rv3032: add RV-3032 bindings
dt-bindings: rtc: add trickle-voltage-millivolt
rtc: rv3028: ensure ram configuration registers are saved
rtc: rv3028: factorize EERD bit handling
rtc: rv3028: fix trickle resistor values
rtc: rv3028: fix clock output support
rtc: mt6397: Remove unused member dev
rtc: rv8803: simplify the return expression of rv8803_nvram_write
rtc: meson: simplify the return expression of meson_vrtc_probe
rtc: rx8010: rename rx8010_init_client() to rx8010_init()
rtc: ds1307: enable rx8130's backup battery, make it chargeable optionally
rtc: ds1307: consider aux-voltage-chargeable
rtc: ds1307: store previous charge default per chip
...
|