Tell the RTC core UIE are not supported because the resolution of the alarm
is a minute.
Note that this is in fact also fixing how the resolution is reported as the
previous test was simply ensuring the alarm was more than a minute in the
future while the register has a minute resolution.
This would be ok if the alarm was a countdown but ab8500_rtc_read_alarm
suggests otherwise and the AB8500 datasheet states that the RTC
documentation is not public.
Finally, the comment is wrong and what makes the UIE emulation work is
uie_unsupported being set.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211107225458.111068-6-alexandre.belloni@bootlin.com
Handle alarms with a minute resolution in the core. Until now drivers have
been open coding the seconds part removal and have been doing that wrongly.
Most of them are rounding up which means the allow the system to miss
deadlines. So, round down and let __rtc_set_alarm return immediately if the
time has already passed.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211107225458.111068-1-alexandre.belloni@bootlin.com
Samsung SoC drivers changes for v5.16
1. Convert Exynos ChipID and ASV driver to a module and make it a
default, instead of selected. The driver is not essential, so it
could be disabled, if needed.
2. Add support for Exynos850 and Exynos Auto v9 to Exynos ChipID and ASV
driver.
3. Get rid of HAVE_S3C_RTC because it was adding just another layer
instead of direct dependencies.
4. Minor cleanups.
* tag 'samsung-drivers-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
soc: samsung: exynos-chipid: add exynosautov9 SoC support
rtc: s3c: remove HAVE_S3C_RTC in favor of direct dependencies
soc: samsung: exynos-chipid: Add Exynos850 support
dt-bindings: samsung: exynos-chipid: Document Exynos850 compatible
soc: samsung: exynos-chipid: Pass revision reg offsets
soc: samsung: pm_domains: drop unused is_off field
arm64: exynos: don't have ARCH_EXYNOS select EXYNOS_CHIPID
soc: samsung: exynos-chipid: do not enforce built-in
soc: samsung: exynos-chipid: convert to a module
soc: samsung: exynos-chipid: avoid soc_device_to_device()
soc: samsung: exynos-pmu: Fix compilation when nothing selects CONFIG_MFD_CORE
Link: https://lore.kernel.org/r/20211026094709.75692-2-krzysztof.kozlowski@canonical.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This RTC driver starts counting from 2000 to avoid Y2K problem. Also it
only supports 100 years range for all RTCs. Provide that info to RTC
framework. Also remove check for 100 years range in s3c_rtc_settime(),
as RTC core won't pass any invalid values to the driver, now that
correct range is set.
Here is the rationale on 100 years range limitation. Info on different
Samsung RTCs (credit goes to Krzysztof Kozlowski):
- All S3C chips have only 8-bit wide year register (can store 100
years range in BCD format)
- S5Pv210 and Exynos chips have 12-bit year register (can store 1000
years range in BCD format)
But in reality we usually can't make use of those 12 bits either:
- RTCs might think that both 2000 and 2100 years are leap years. So
when the YEAR register is 0, RTC goes from 28 Feb to 29 Feb, and
when the YEAR register is 100, RTC also goes from 28 Feb to 29 Feb.
This is of course incorrect: RTC breaks leap year criteria, which
breaks the time contiguity, which leads to inability to use the RTC
after year of 2099. It was found for example on Exynos850 SoC.
- Despite having 12 bits for holding the year value, RTC might
overflow the year value internally much earlier. For example, on
Exynos850 the RTC overflows when YEAR=159, making the next YEAR=0.
This way RTC actually has range of 160 years, not 1000 as one may
think.
All that said, there is no sense in trying to increase the time range
for more than 100 years on RTCs that seem capable of that. It also
doesn't have too much practical value -- current hardware will be
probably obsolete by 2100.
Tested manually on Exynos850 RTC:
$ date -s "1999-12-31 23:59:50"
$ hwclock -w -f /dev/rtc0
$ date -s "2100-01-01 00:00:00"
$ hwclock -w -f /dev/rtc0
$ date -s "2000-01-01 00:00:00"
$ hwclock -w -f /dev/rtc0
$ hwclock -r -f /dev/rtc0
$ date -s "2099-12-31 23:59:50"
$ hwclock -w -f /dev/rtc0
$ hwclock -r -f /dev/rtc0
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211021202256.28517-4-semen.protsenko@linaro.org
Some SoCs have an RTC supported by this RTC driver, but do not have an
early clock provider declared here. Currently, this prevents the RTC
driver from probing, because it expects a global struct to already be
allocated. Fix probing the driver by copying the missing pieces from the
clock provider setup function, replacing them with the devm variants.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210928080335.36706-7-samuel@sholland.org
BSM or Backup Switch Mode is a common feature on RTCs, allowing to select
how the RTC will decide when to switch from its primary power supply to the
backup power supply. It is necessary to be able to set it from userspace as
there are uses cases where it has to be done dynamically.
Supported values are:
RTC_BSM_DISABLED: disabled
RTC_BSM_DIRECT: switching will happen as soon as Vbackup > Vdd
RTC_BSM_LEVEL: switching will happen around a threshold, usually with an
hysteresis
RTC_BSM_STANDBY: switching will not happen until Vdd > Vbackup, this is
useful to ensure the RTC doesn't draw any power until the device is first
powered on.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211018151933.76865-6-alexandre.belloni@bootlin.com
Power-on reset after the insertion of a battery does not always complete
successfully, leading to corrupted register content. The EXT_TEST bit
will stop the clock from running, but currently the driver will never
recover.
Safely handle the erroneous state by clearing EXT_TEST as part of the
usual set_time method.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211015111208.1757110-1-phil@raspberrypi.com
TQ-Systems' TQMa8Mx module (SoM) uses a pcf85063 as RTC. The default output
is 32768Hz. This is to provide the i.MX8M CKIL clock. Once the RTC driver
is probed, the clock is disabled and all i.MX8M functionality depending on
the 32 KHz clock will halt. In our case the whole system halts and a power
cycle is required.
Referencing the pcf85063 directly results in a deadlock. The kernel
will see, that i.MX8M system clock needs the RTC clock and do probe
deferral. But the i.MX8M I2C module never becomes usable without the
i.MX8M CKIL clock and thus the RTC's clock will not be probed. So
from the kernel's perspective this is a chicken-and-egg problem.
Technically everything is fine by not touching anything, since
the RTC clock correctly enables the clock on reset (i.e. on
battery backup power loss).
A workaround for this issue is describing the square wave pin
as fixed-clock, which is registered early and basically how
this pin is used on the i.MX8M.
This addresses the exact same issue as in commit f765e349c3 ("rtc:
m41t80: add support for fixed clock").
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
[Fixed return value 0 -> NULL]
Link: https://lore.kernel.org/r/20211013074954.997445-1-alexander.stein@ew.tq-group.com
I got a null-ptr-deref report when doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:strcmp+0xc/0x20
Call Trace:
__devm_rtc_register_device.cold.7+0x16a/0x2df
rv3029_probe+0x4b1/0x770 [rtc_rv3029c2]
rv3029_i2c_probe+0x141/0x180 [rtc_rv3029c2]
i2c_device_probe+0xa07/0xbb0
really_probe+0x285/0xc30
If dev_set_name() fails, dev_name() is null, it causes null-ptr-deref,
we need check the return value of dev_set_name().
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211012041629.2504158-1-yangyingliang@huawei.com
I got a null-ptr-deref report when doing fault injection test:
general protection fault, probably for non-canonical address 0xdffffc0000000022: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000110-0x0000000000000117]
RIP: 0010:device_del+0x132/0xdc0
Call Trace:
cdev_device_del+0x1a/0x80
devm_rtc_unregister_device+0x37/0x80
release_nodes+0xc3/0x3b0
If cdev_device_add() fails, 'dev->p' is not set, it causes
null-ptr-deref when calling cdev_device_del(). Registering
character device is optional, we don't return error code
here, so introduce a new flag 'RTC_NO_CDEV' to indicate
if it has character device, cdev_device_del() is called
when this bit is not set.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211011132114.3663509-1-yangyingliang@huawei.com
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e21 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210927130240.33693-1-broonie@kernel.org
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e21 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210923194922.53386-4-broonie@kernel.org
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e21 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210923194922.53386-3-broonie@kernel.org
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding an id_table listing the
SPI IDs for everything.
Fixes: 96c8395e21 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210923194922.53386-2-broonie@kernel.org
