kernel/drivers/rtc/rtc-hym8563.c, branch linux-6.9.y

rtc: Switch i2c drivers back to use .probe()

2023-06-06T21:29:37Z

After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230505121136.1185653-1-u.kleine-koenig@pengutronix.de Signed-off-by: Alexandre Belloni

rtc: hym8563: use IRQ flags obtained from fwnode

2023-02-01T08:13:35Z

Allow the IRQ type to be passed from the device tree if available as there may be components changing the trigger type of the interrupt between the RTC and the IRQ controller. Link: https://lore.kernel.org/r/20230123200217.1236011-3-alexandre.belloni@bootlin.com Signed-off-by: Alexandre Belloni

rtc: use simple i2c probe

2022-06-24T19:24:02Z

All these drivers have an i2c probe function which doesn't use the "struct i2c_device_id *id" parameter, so they can trivially be converted to the "probe_new" style of probe with a single argument. This change was done using the following Coccinelle script, and fixed up for whitespace changes: @ rule1 @ identifier fn; identifier client, id; @@ - static int fn(struct i2c_client *client, const struct i2c_device_id *id) + static int fn(struct i2c_client *client) { ...when != id } @ rule2 depends on rule1 @ identifier rule1.fn; identifier driver; @@ struct i2c_driver driver = { - .probe + .probe_new = ( fn | - &fn + fn ) , }; Signed-off-by: Stephen Kitt Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220610162346.4134094-1-steve@sk2.org

rtc: hym8563: switch to RTC_FEATURE_UPDATE_INTERRUPT

2022-03-23T18:58:40Z

Stop using uie_unsupported and clear RTC_FEATURE_UPDATE_INTERRUPT instead. Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220309162301.61679-27-alexandre.belloni@bootlin.com

rtc: hym8563: let the core handle the alarm resolution

2022-03-23T18:58:40Z

Set RTC_FEATURE_ALARM_RES_MINUTE, so the core knows alarms have a resolution of a minute. Also, the core will properly round down the alarm instead of up. Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220309162301.61679-26-alexandre.belloni@bootlin.com

rtc: hym8563: switch to devm_rtc_allocate_device

2022-03-23T18:58:40Z

Switch to devm_rtc_allocate_device/devm_rtc_register_device, this allows for further improvement of the driver. Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20220309162301.61679-25-alexandre.belloni@bootlin.com

rtc: hym8563: use rtc_lock/rtc_unlock

2021-01-25T22:46:17Z

Avoid accessing directly rtc->ops_lock and use the RTC core helpers. Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210119220653.677750-7-alexandre.belloni@bootlin.com

rtc: hym8563: enable wakeup when applicable

2020-11-14T22:36:10Z

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 Signed-off-by: Guillaume Tucker Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/1ea023e2ba50a4dab6e39be93d7de3146af71a60.1604653374.git.guillaume.tucker@collabora.com

rtc: hym8563: Read the valid flag directly instead of caching it

2019-12-23T10:18:06Z

The RTC has a valid bit in the seconds register that indicates whether power was lost since the pevious time set. This bit is currently read once at probe time, cached and updated with set_time. Howeever, caching the bit may prevent detecting power loss at runtime (which can happen if the RTC's supply is distinct from the the platform's). Writing the seconds register when setting time will clear the bit, so there should be no downside in reading the bit directly instead of caching it. Signed-off-by: Paul Kocialkowski Link: https://lore.kernel.org/r/20191212153111.966923-2-paul.kocialkowski@bootlin.com Signed-off-by: Alexandre Belloni

rtc: hym8563: Return -EINVAL if the time is known to be invalid

2019-12-23T10:18:04Z

The current code returns -EPERM when the voltage loss bit is set. Since the bit indicates that the time value is not valid, return -EINVAL instead, which is the appropriate error code for this situation. Fixes: dcaf03849352 ("rtc: add hym8563 rtc-driver") Signed-off-by: Paul Kocialkowski Link: https://lore.kernel.org/r/20191212153111.966923-1-paul.kocialkowski@bootlin.com Signed-off-by: Alexandre Belloni