- 09 Nov, 2017 2 commits
-
-
Philipp Zabel authored
The pcf8563_clkout_recalc_rate function erroneously ignores the frequency index read from the CLKO register and always returns 32768 Hz. Fixes: a39a6405 ("rtc: pcf8563: add CLKOUT to common clock framework") Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Akshay Bhat authored
The err variable is not being reset after a successful read. Explicitly return 0 at the end of function call to account for all return paths. Reported-by:
Jens-Peter Oswald <oswald@lre.de> Signed-off-by:
Akshay Bhat <akshay.bhat@timesys.com> Signed-off-by:
-
- 08 Nov, 2017 9 commits
-
-
Akshay Bhat authored
Define for reserved register 31 had the incorrect address. Specify the correct address. Reported-by:
-
Akshay Bhat authored
Remove duplicate define for RX8010_YEAR Signed-off-by:
-
Troy Kisky authored
m41t80_sqw_set_rate will be called with the result from m41t80_sqw_round_rate, so might as well make m41t80_sqw_set_rate(n) same as m41t80_sqw_set_rate(m41t80_sqw_round_rate(n)) As Russell King wrote[1], "clk_round_rate() is supposed to tell you what you end up with if you ask clk_set_rate() to set the exact same value you passed in - but clk_round_rate() won't modify the hardware." [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080175.htmlSigned-off-by:
Troy Kisky <troy.kisky@boundarydevices.com> Signed-off-by:
-
Troy Kisky authored
This is a little more efficient and avoids the warning WARNING: possible circular locking dependency detected 4.14.0-rc7-00010 #16 Not tainted ------------------------------------------------------ kworker/2:1/70 is trying to acquire lock: (prepare_lock){+.+.}, at: [<c049300c>] clk_prepare_lock+0x80/0xf4 but task is already holding lock: (i2c_register_adapter){+.+.}, at: [<c0690b04>] i2c_adapter_lock_bus+0x14/0x18 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (i2c_register_adapter){+.+.}: rt_mutex_lock+0x44/0x5c i2c_adapter_lock_bus+0x14/0x18 i2c_transfer+0xa8/0xbc i2c_smbus_xfer+0x20c/0x5d8 i2c_smbus_read_byte_data+0x38/0x48 m41t80_sqw_is_prepared+0x18/0x28 Signed-off-by: -
Troy Kisky authored
This is a little more efficient, and avoids the warning WARNING: possible circular locking dependency detected 4.14.0-rc7-00007 #14 Not tainted ------------------------------------------------------ alsactl/330 is trying to acquire lock: (prepare_lock){+.+.}, at: [<c049300c>] clk_prepare_lock+0x80/0xf4 but task is already holding lock: (i2c_register_adapter){+.+.}, at: [<c0690ae0>] i2c_adapter_lock_bus+0x14/0x18 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (i2c_register_adapter){+.+.}: rt_mutex_lock+0x44/0x5c i2c_adapter_lock_bus+0x14/0x18 i2c_transfer+0xa8/0xbc i2c_smbus_xfer+0x20c/0x5d8 i2c_smbus_read_byte_data+0x38/0x48 m41t80_sqw_recalc_rate+0x24/0x58 Signed-off-by: -
Troy Kisky authored
Previously it was returning the best of 32768, 8192, 1024, 64, 2, 0 Now, best of 32768, 8192, 4096, 2048, 1024, 512, 256, 128, 64, 32, 16, 8, 4, 2, 1, 0 Signed-off-by:
-
Troy Kisky authored
Previously it was returning -EINVAL upon success. Signed-off-by:
-
Eric Nelson authored
Note that alarms are not currently implemented. 64 bytes of nvmem is supported and exposed in sysfs (# is the instance number, starting with 0): /sys/bus/nvmem/devices/pcf85363-#/nvmem Signed-off-by:
Eric Nelson <eric@nelint.com> Reviewed-by:
Fabio Estevam <fabio.estevam@nxp.com> Tested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Alexandre Belloni authored
Register an nvmem device to expose the 3 scratch registers (total of 12 bytes) to both userspace and kernel space. Reviewed-by:
Sekhar Nori <nsekhar@ti.com> Tested-by:
Keerthy <j-keerthy@ti.com> Reviewed-by:
-
- 31 Oct, 2017 2 commits
-
-
Alexandre Belloni authored
This removes a possible race condition and crash and allows for further improvement of the driver. Signed-off-by: -
Alexandre Belloni authored
If pinctrl_register() fails probe will return with an error without locking the RTC and disabling pm_runtime. Set ret and jump to err instead. Fixes: 97ea1906 ("rtc: omap: Support ext_wakeup configuration") Signed-off-by:
-
- 27 Oct, 2017 1 commit
-
-
Alexandre Belloni authored
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. Worse, the compatible is documented but doesn't currently match the driver. Add the proper compatible to the driver. Signed-off-by:
-
- 26 Oct, 2017 4 commits
-
-
Bastian Stender authored
Make Epson RX8130 device tree and ACPI aware. Fixes: ee0981be ("rtc: ds1307: Add support for Epson RX8130CE") Signed-off-by:
Bastian Stender <bst@pengutronix.de> Signed-off-by:
-
Sean Wang authored
I work for MediaTek on maintaining the MediaTek SoC based RTC driver for the existing SoCs and keep adding support for the following SoCs in the future. Cc: Eddie Huang <eddie.huang@mediatek.com> Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sean Wang authored
Give a better description for original MediaTek RTC driver as PMIC based RTC in order to distinguish SoC based RTC. Also turning all words with Mediatek to MediaTek here. Cc: Eddie Huang <eddie.huang@mediatek.com> Signed-off-by:
Eddie Huang <eddie.huang@mediatek.com> Signed-off-by:
-
Sean Wang authored
This patch introduces the driver for the RTC on MT7622 SoC. Signed-off-by:
Yingjoe Chen <yingjoe.chen@mediatek.com> Signed-off-by:
-
- 25 Oct, 2017 4 commits
-
-
Sean Wang authored
Add device-tree binding for MediaTek SoC based RTC Cc: devicetree@vger.kernel.org Signed-off-by:
-
Russell King authored
Add support for reading and writing the RTC offset register, converting it to the corresponding parts-per-billion value. When setting the drift, the PCF8523 has two modes: one applies the adjustment every two hours, the other applies the adjustment every minute. We select between these two modes according to which ever gives the closest PPB value to the one requested. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King authored
Add support for trimming the RTC using the offset mechanism. This RTC supports two modes: low update mode and high update mode. Low update mode has finer precision than high update mode, so we use the low mode where possible. Signed-off-by:
-
Russell King authored
The RTC offset correction documentation is not very clear about the exact relationship between "offset" and the effect it has on the RTC. Supplement the documentation with an equation giving the relationship. Signed-off-by:
-
- 12 Oct, 2017 17 commits
-
-
Alexandre Belloni authored
Instead of adding a binary sysfs attribute from the driver (which suffers from a race condition as the attribute appears after the device), use the core to register an nvmem device. Signed-off-by: -
Alexandre Belloni authored
Disabling interrupts when removing the driver is bad practice as this will prevent some platform from waking up when using that RTC. Signed-off-by: -
Alexandre Belloni authored
This allows for future improvement of the driver. Signed-off-by: -
Alexandre Belloni authored
There is a race condition that can happen if abx80x_probe() fails after the rtc registration succeeded. Solve that by moving the registration at the end of the probe function. Signed-off-by: -
Alexandre Belloni authored
This allows for future improvement of the driver. Signed-off-by: -
Alexandre Belloni authored
Instead of adding a binary sysfs attribute from the driver (which suffers from a race condition as the attribute appears after the device), use the core to register an nvmem device. Signed-off-by: -
Alexandre Belloni authored
This allows for future improvement of the driver. Signed-off-by: -
Alexandre Belloni authored
Instead of adding a binary sysfs attribute from the driver (which suffers from a race condition as the attribute appears after the device), use the core to register an nvmem device. Signed-off-by: -
Alexandre Belloni authored
This allows for future improvement of the driver. Signed-off-by: -
Russell King authored
On some platforms, the interrupt for the PL031 is optional. Avoid trying to claim the interrupt if it's not specified. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Russell King authored
If the RTC has no interrupt, there is little point in exposing the RTC alarm capabilities, as it can't be used as a wakeup source nor can it deliver an event to userspace. Signed-off-by:
-
Russell King authored
Use the devm_* APIs for allocating memory and mapping the memory in the probe function to relieve the driver from having to deal with this in the cleanup paths. Signed-off-by:
-
Russell King authored
The AMBA device IDs should be marked const. Make that so. Reviewed-by:
-
Dan Carpenter authored
We don't need both "ret" and "err" when they do the same thing. All the functions called here return zero on success or negative error codes. It's more clear to return a literal zero at the end instead of "return ret;" Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Mathieu Malaterre authored
The current timeout for waiting for WRDY is not always sufficient. Always increase it to 10000 even on JZ4740. This is technically only required on JZ4780, where the current symptoms seen after a hard reboot are: jz4740-rtc 10003000.rtc: rtc core: registered 10003000.rtc as rtc0 jz4740-rtc 10003000.rtc: Could not write to RTC registers jz4740-rtc: probe of 10003000.rtc failed with error -5 Suggested-by:
Alex Smith <alex.smith@imgtec.com> Cc: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by:
Mathieu Malaterre <malat@debian.org> Signed-off-by:
-
Mathieu Malaterre authored
Trivial fix in error message with duplicate 'write' Signed-off-by:
-
Heiner Kallweit authored
The current code for checking and fixing the weekday in ds1307_probe faces some issues: - This check is applied to all chips even if its applicable (AFAIK) to mcp794xx only - The check uses MCP794XX constants for registers and bits even though it's executed also on other chips (ok, this could be fixed easily) - It relies on tm_wday being properly populated when core calls set_time and set_alarm. This is not guaranteed at all. First two issue we could solve by moving the check to the mcp794xx-specific initialization (where also VBATEN flag is set). The proposed alternative is in the set_alarm path for mcp794xx only and calculates the alarm weekday based on the current weekday in the RTC timekeeping regs and the difference between alarm date and current date. So we are fine with any weekday even if it doesn't match the date. Still there are cases where this could fail, e.g.: - rtc date/time + weekday have power-on-reset default values - alarm is set to actual date/time + x - set_time is called (may change diff between rtc weekday and actual weekday) But similar issues we have with the current code too: - rtc date/time + weekday have power-on-reset default values - alarm is set to rtc date/time + x - set_time is called before the alarm triggers Using random rtc date/time with relative alarms simply can interfere with set_time. I'm not totally convinced of either option yet. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
- 28 Sep, 2017 1 commit
-
-
Alexandre Belloni authored
If there is any non expired timer in the queue, the RTC alarm is never set. This is an issue when adding a timer that expires before the next non expired timer. Ensure the RTC alarm is set in that case. Fixes: 2b2f5ff0 ("rtc: interface: ignore expired timers when enqueuing new timers") Signed-off-by:
-
