- 09 Nov, 2021 13 commits
-
-
Alexandre Belloni authored
Remove open coded sysfs registration by using rtc_add_group. Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20211107225458.111068-11-alexandre.belloni@bootlin.com
-
Alexandre Belloni authored
Clear RTC_FEATURE_ALARM to signal alarms are not supported to the core instead of checking client->irq. Signed-off-by:
-
Alexandre Belloni authored
Set the RTC range, it is a classic BCD RTC, with 00 being a leap year. Let the core handle range checking. Signed-off-by:
-
Alexandre Belloni authored
Tell the RTC core UIE are not supported because the resolution of the alarm is a minute. Signed-off-by:
-
Alexandre Belloni authored
Switch to devm_rtc_allocate_device/devm_rtc_register_device, this allows for further improvement of the driver. Signed-off-by:
-
Alexandre Belloni authored
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:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211107225458.111068-6-alexandre.belloni@bootlin.com
-
Alexandre Belloni authored
The RTC actually supports UIE when an interrupt is available. Signed-off-by:
-
Alexandre Belloni authored
Switch from uie_unsupported to RTC_FEATURE_UPDATE_INTERRUPT Signed-off-by:
-
Alexandre Belloni authored
Let the RTC core know the resolution of the alarm is a minute. Signed-off-by:
-
Alexandre Belloni authored
Tell the RTC core UIE are not supported because the resolution of the alarm is a minute. Signed-off-by:
-
Alexandre Belloni authored
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 authored
cppcheck warnings: (new ones prefixed by >>) >> drivers/rtc/rtc-pcf85063.c:292:40: warning: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] status = status & PCF85063_REG_SC_OS ? RTC_VL_DATA_INVALID : 0; Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
-
Dominique Martinet authored
ctrl is set from read_regs(..FLAG, 2, ctrl), so ctrl[0] is FLAG and ctrl[1] is the CTRL register. Use ctrl[0] to write back to the FLAG register as appropriate. Signed-off-by:
Dominique Martinet <dominique.martinet@atmark-techno.com> Signed-off-by:
-
- 23 Oct, 2021 5 commits
-
-
Sam Protsenko authored
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:
-
Sam Protsenko authored
Create dedicated functions for I/O operations and BCD conversion. It can be useful to separate those from representation conversion and other stuff found in RTC callbacks. This patch does not introduce any functional changes, it's merely refactoring change. Signed-off-by:
-
Sam Protsenko authored
devm_rtc_device_register() is deprecated. Use devm_rtc_allocate_device() and devm_rtc_register_device() API instead. This change doesn't change the behavior, but allows for further improvements. Signed-off-by:
-
Dmitry Osipenko authored
Driver was upstreamed in 2013 and never got a user, remove it. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Samuel Holland authored
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:
-
- 18 Oct, 2021 14 commits
-
-
Alexandre Belloni authored
Backup Switch Mode allows to select the strategy to use to switch from the main power supply to the backup power supply. As before, the driver will switch from standby mode to level mode but now only when it has never been set. Signed-off-by:
-
Alexandre Belloni authored
Always provide an OF table to ensure ACPI platforms can also use this driver. Signed-off-by:
-
Alexandre Belloni authored
If CONFIG_OF is not defined, of_property_read_bool will return false which is our default value Signed-off-by:
-
Alexandre Belloni authored
Compiling out pcf8523_rtc_ioctl saves about 5% of the generated machine code. However, it certainly never happens as the RTC character device interface is the most useful one and is probably always compiled in. Signed-off-by:
-
Alexandre Belloni authored
Use regmap to access the RTC registers, this is a huge reduction in code lines and generated code. Values on ARMv7: text data bss dec hex 5180 132 0 5312 14c0 before 3900 132 0 4032 fc0 after Signed-off-by:
-
Alexandre Belloni authored
Set RTC_FEATURE_UPDATE_INTERRUPT by default and clear it when it is not supported. Signed-off-by:
-
Alexandre Belloni authored
BLF, battery low doesn't mean the time is imprecise or invalid, it simply mean the backup battery has to be replaced. This information can be read using the VL_READ ioctl. Signed-off-by:
-
Alexandre Belloni authored
Backup Switch Mode is currently set properly when the trickle charger is enabled. However, in the case of a non-rechargeable battery, it is necessary to be able to enable it, only allow that when the trickle charger is disabled. Signed-off-by:
-
Alexandre Belloni authored
Backup Switch Mode controls how the RTC decides when to switch to the backup power supply. As it is disabled by default, provide a way to enable and configure it. Signed-off-by:
-
Alexandre Belloni authored
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 authored
Add a new parameter allowing the get and set the correction using ioctls instead of just sysfs. Signed-off-by:
-
Alexandre Belloni authored
Add a new feature for RTCs able to correct the oscillator imprecision. This is also called offset or trimming. Such drivers have a .set_offset callback, use that to set the feature bit from the core. Signed-off-by:
-
Alexandre Belloni authored
Add an ioctl allowing to get and set extra parameters for an RTC. For now, only handle getting available features. Signed-off-by:
-
Alexandre Belloni authored
Add more alarm related features to be declared by drivers. Signed-off-by:
-
- 15 Oct, 2021 5 commits
-
-
Phil Elwell authored
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:
-
Alexander Stein authored
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 f765e349 ("rtc: m41t80: add support for fixed clock"). Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reported-by:
-
Dan Carpenter authored
Do not call rv3032_exit_eerd() if the enter function fails but don't forget to call the exit when the enter succeeds. Fixes: 2eeaa532 ("rtc: rv3032: Add a driver for Microcrystal RV-3032") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Yang Yingliang authored
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:
-
Yang Yingliang authored
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:
-
- 01 Oct, 2021 3 commits
-
-
Colin Ian King authored
Function m41t80_sqw_register_clk returns a pointer to struct clk, so returning a plain 0 integer isn't good practice. Fix this by returning a NULL instead. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
Shifting the u16 value returned by readw by 16 bits to the left will be promoted to a 32 bit signed int and then sign-extended to an unsigned long. If the top bit of the readw is set then the shifted value will be sign extended and the top 32 bits of the result will be set. Fixes: be7d9c91 ("rtc: Add support for the MSTAR MSC313 RTC") Signed-off-by:
Romain Perier <romain.perier@gmail.com> Signed-off-by:
-
Mark Brown authored
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: 96c8395e ("spi: Revert modalias changes") Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
