* [PATCH v2 0/2] Fix S0i3 wakeup with alarmtimer
From: Mario Limonciello @ 2026-05-21 4:37 UTC (permalink / raw)
To: Shyam Sundar S K, Alexandre Belloni
Cc: Hans de Goede, Ilpo Järvinen, platform-driver-x86,
linux-kernel, linux-rtc, Thomas Gleixner, Mario Limonciello
It was reported that suspend-then-hibernate stopped working with modern
systemd versions on AMD Cezanne systems. The reason for this breakage
was because systemd switched to using alarmtimer instead of the wakealarm
sysfs file.
But really it uncovered deeper problems with how these timers work. Adjust
the code accordingly.
Mario Limonciello (2):
rtc: Add rtc_read_next_alarm() to read next expiring timer
platform/x86: amd-pmc: Fix S0i3 wakeup with alarmtimer
drivers/platform/x86/amd/pmc/pmc.c | 9 ++++---
drivers/rtc/interface.c | 40 ++++++++++++++++++++++++++++++
include/linux/rtc.h | 2 ++
3 files changed, 48 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] rtc: Add rtc_read_next_alarm() to read next expiring timer
From: Mario Limonciello @ 2026-05-21 4:37 UTC (permalink / raw)
To: Shyam Sundar S K, Alexandre Belloni
Cc: Hans de Goede, Ilpo Järvinen, platform-driver-x86,
linux-kernel, linux-rtc, Thomas Gleixner, Mario Limonciello
In-Reply-To: <20260521043714.1022930-1-mario.limonciello@amd.com>
Add a new function rtc_read_next_alarm() that reads the next expiring
alarm from the RTC timerqueue. This is different from rtc_read_alarm(),
which only reads the aie_timer.
The wakealarm sysfs file programs the rtc->aie_timer, whereas the
alarmtimer suspend routine programs its own timer into the RTC timerqueue.
Both timers end up in the RTC's timerqueue, and the first expiring timer
is what gets armed in the hardware.
This new function allows code to query which alarm will actually fire
next, regardless of which subsystem programmed it. This is needed by
platform code that needs to program secondary timers based on the
actual next wakeup time.
Link: https://lore.kernel.org/all/87ed50z0le.ffs@tglx
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
v2:
* Drop pointless variable assignments
* Add missing ":" in kdoc for returns
---
drivers/rtc/interface.c | 40 ++++++++++++++++++++++++++++++++++++++++
include/linux/rtc.h | 2 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 1906f4884a834..7859be8f2a923 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -384,6 +384,46 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
return err;
}
+/**
+ * rtc_read_next_alarm - read the next expiring alarm
+ * @rtc: RTC device
+ * @alarm: storage for the alarm information
+ *
+ * Read the next expiring alarm from the RTC timerqueue. This returns
+ * the alarm that will actually fire next, which may be different from
+ * rtc_read_alarm() if multiple timers are queued (e.g., alarmtimer
+ * and wakealarm sysfs both active).
+ *
+ * Returns: 0 on success, -ENOENT if no alarm is pending, or other error.
+ */
+int rtc_read_next_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
+{
+ struct timerqueue_node *next;
+ int err;
+
+ if (!rtc || !alarm)
+ return -EINVAL;
+
+ err = mutex_lock_interruptible(&rtc->ops_lock);
+ if (err)
+ return err;
+
+ next = timerqueue_getnext(&rtc->timerqueue);
+ if (!next) {
+ err = -ENOENT;
+ goto unlock;
+ }
+
+ memset(alarm, 0, sizeof(struct rtc_wkalrm));
+ alarm->time = rtc_ktime_to_tm(next->expires);
+ alarm->enabled = 1;
+
+unlock:
+ mutex_unlock(&rtc->ops_lock);
+ return err;
+}
+EXPORT_SYMBOL_GPL(rtc_read_next_alarm);
+
int rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
{
int err;
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 95da051fb155d..c09fc22819d0c 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -190,6 +190,8 @@ extern int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm);
int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm);
extern int rtc_read_alarm(struct rtc_device *rtc,
struct rtc_wkalrm *alrm);
+extern int rtc_read_next_alarm(struct rtc_device *rtc,
+ struct rtc_wkalrm *alrm);
extern int rtc_set_alarm(struct rtc_device *rtc,
struct rtc_wkalrm *alrm);
extern int rtc_initialize_alarm(struct rtc_device *rtc,
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/3] rtc: ds1307: Add driver for Epson RX8901CE
From: Fredrik M Olsson @ 2026-05-20 14:48 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nobuhiro Iwamatsu
Cc: linux-rtc, devicetree, linux-kernel, Fredrik M Olsson, kernel
In-Reply-To: <20260520-ds1307-rx8901-add-v2-0-e069ea32e1db@axis.com>
Adds support for:
- Reading and writing time to/from the RTC.
- Changing Backup Switch Mode (BSM) to DISABLED/DIRECT/LEVEL using the
RTC_PARAM_SET ioctl.
- Optionally enabling battery charging.
- Reading the battery voltage low status using the RTC_VL_READ ioctl
(only supported in LEVEL BSM), which also reports invalid time
information if the VLF flag is set.
Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
---
drivers/rtc/rtc-ds1307.c | 216 +++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 207 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index bf42c250ea7d..23dd104aa2be 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -9,6 +9,7 @@
*/
#include <linux/bcd.h>
+#include <linux/bitfield.h>
#include <linux/i2c.h>
#include <linux/init.h>
#include <linux/kstrtox.h>
@@ -48,6 +49,7 @@ enum ds_type {
mcp794xx,
rx_8025,
rx_8130,
+ rx_8901,
last_ds_type /* always last */
/* rs5c372 too? different address... */
};
@@ -129,6 +131,18 @@ enum ds_type {
#define RX8130_REG_CONTROL1_INIEN BIT(4)
#define RX8130_REG_CONTROL1_CHGEN BIT(5)
+#define RX8901_REG_INTF 0x0e
+#define RX8901_REG_INTF_VLF BIT(1)
+#define RX8901_REG_PWSW_CFG 0x37
+#define RX8901_REG_PWSW_CFG_SWSEL GENMASK(3, 2)
+#define RX8901_REG_PWSW_CFG_VBATLDETEN BIT(4)
+#define RX8901_REG_PWSW_CFG_INIEN BIT(6)
+#define RX8901_REG_PWSW_CFG_CHGEN BIT(7)
+#define RX8901_REG_BUF_INTF 0x46
+#define RX8901_REG_BUF_INTF_VBATLF BIT(3)
+#define RX8901_SWSEL_PRIMARY_BACKUP 0x1
+#define RX8901_SWSEL_PRIMARY 0x2
+
#define MCP794XX_REG_CONTROL 0x07
# define MCP794XX_BIT_ALM0_EN 0x10
# define MCP794XX_BIT_ALM1_EN 0x20
@@ -192,8 +206,8 @@ struct chip_desc {
irq_handler_t irq_handler;
const struct rtc_class_ops *rtc_ops;
u16 trickle_charger_reg;
- u8 (*do_trickle_setup)(struct ds1307 *, u32,
- bool);
+ int (*do_trickle_setup)(struct ds1307 *ds1307, u32 ohms,
+ bool diode);
/* Does the RTC require trickle-resistor-ohms to select the value of
* the resistor between Vcc and Vbackup?
*/
@@ -216,6 +230,7 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
if (ds1307->type == rx_8130) {
unsigned int regflag;
+
ret = regmap_read(ds1307->regmap, RX8130_REG_FLAG, ®flag);
if (ret) {
dev_err(dev, "%s error %d\n", "read", ret);
@@ -226,6 +241,19 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
dev_warn_once(dev, "oscillator failed, set time!\n");
return -EINVAL;
}
+ } else if (ds1307->type == rx_8901) {
+ unsigned int regflag;
+
+ ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
+ if (ret) {
+ dev_dbg(dev, "%s error %d\n", "read", ret);
+ return ret;
+ }
+
+ if (regflag & RX8901_REG_INTF_VLF) {
+ dev_warn_once(dev, "oscillator failed, set time!\n");
+ return -EINVAL;
+ }
}
/* read the RTC date and time registers all at once */
@@ -307,7 +335,7 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
tmp = regs[DS1307_REG_HOUR] & 0x3f;
t->tm_hour = bcd2bin(tmp);
/* rx8130 is bit position, not BCD */
- if (ds1307->type == rx_8130)
+ if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
t->tm_wday = fls(regs[DS1307_REG_WDAY] & 0x7f) - 1;
else
t->tm_wday = bcd2bin(regs[DS1307_REG_WDAY] & 0x07) - 1;
@@ -358,7 +386,7 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
regs[DS1307_REG_MIN] = bin2bcd(t->tm_min);
regs[DS1307_REG_HOUR] = bin2bcd(t->tm_hour);
/* rx8130 is bit position, not BCD */
- if (ds1307->type == rx_8130)
+ if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
regs[DS1307_REG_WDAY] = 1 << t->tm_wday;
else
regs[DS1307_REG_WDAY] = bin2bcd(t->tm_wday + 1);
@@ -422,11 +450,132 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
dev_err(dev, "%s error %d\n", "write", result);
return result;
}
+ } else if (ds1307->type == rx_8901) {
+ /*
+ * clear Voltage Loss Flag as data is available now (writing 1
+ * to the other bits in the INTF register has no effect)
+ */
+ result = regmap_write(ds1307->regmap, RX8901_REG_INTF,
+ 0xff ^ RX8901_REG_INTF_VLF);
+ if (result) {
+ dev_dbg(dev, "%s error %d\n", "write", result);
+ return result;
+ }
}
return 0;
}
+#ifdef CONFIG_RTC_INTF_DEV
+static int rx8901_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)
+{
+ struct ds1307 *ds1307 = dev_get_drvdata(dev);
+ unsigned int regflag, tmp = 0;
+ int ret = 0;
+
+ switch (cmd) {
+ case RTC_VL_READ:
+ ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
+ if (ret)
+ return ret;
+
+ if (regflag & RX8901_REG_INTF_VLF)
+ tmp |= RTC_VL_DATA_INVALID;
+
+ ret = regmap_read(ds1307->regmap, RX8901_REG_BUF_INTF, ®flag);
+ if (ret)
+ return ret;
+
+ if (regflag & RX8901_REG_BUF_INTF_VBATLF)
+ tmp |= RTC_VL_BACKUP_LOW;
+
+ return put_user(tmp, (unsigned int __user *)arg);
+ default:
+ return -ENOIOCTLCMD;
+ }
+ return ret;
+}
+
+static int rx8901_param_get(struct device *dev, struct rtc_param *param)
+{
+ struct ds1307 *ds1307 = dev_get_drvdata(dev);
+ unsigned int regflag;
+ int ret;
+
+ switch (param->param) {
+ case RTC_PARAM_BACKUP_SWITCH_MODE:
+ ret = regmap_read(ds1307->regmap, RX8901_REG_PWSW_CFG, ®flag);
+ if (ret)
+ return ret;
+
+ if (regflag & RX8901_REG_PWSW_CFG_INIEN) {
+ param->uvalue = RTC_BSM_LEVEL;
+ } else {
+ unsigned int swsel = FIELD_GET(RX8901_REG_PWSW_CFG_SWSEL, regflag);
+
+ if (swsel == RX8901_SWSEL_PRIMARY_BACKUP)
+ param->uvalue = RTC_BSM_DIRECT;
+ else
+ param->uvalue = RTC_BSM_DISABLED;
+ }
+
+ break;
+
+ default:
+ return -EINVAL;
+ }
+ return ret;
+}
+
+static int rx8901_param_set(struct device *dev, struct rtc_param *param)
+{
+ struct ds1307 *ds1307 = dev_get_drvdata(dev);
+ unsigned int regmask;
+ unsigned int regval;
+ int ret;
+
+ switch (param->param) {
+ case RTC_PARAM_BACKUP_SWITCH_MODE:
+
+ switch (param->uvalue) {
+ case RTC_BSM_DISABLED:
+ /* Only main power supply is used */
+ regmask = RX8901_REG_PWSW_CFG_INIEN |
+ RX8901_REG_PWSW_CFG_SWSEL;
+ regval = FIELD_PREP(RX8901_REG_PWSW_CFG_SWSEL,
+ RX8901_SWSEL_PRIMARY) |
+ FIELD_PREP(RX8901_REG_PWSW_CFG_INIEN, 0);
+ break;
+ case RTC_BSM_DIRECT:
+ /* Main and battery power supply is put in parallel (default) */
+ regmask = RX8901_REG_PWSW_CFG_INIEN |
+ RX8901_REG_PWSW_CFG_SWSEL;
+ regval = FIELD_PREP(RX8901_REG_PWSW_CFG_SWSEL,
+ RX8901_SWSEL_PRIMARY_BACKUP) |
+ FIELD_PREP(RX8901_REG_PWSW_CFG_INIEN, 0);
+ break;
+ case RTC_BSM_LEVEL:
+ /* Enable auto power switching between main and backup power supply */
+ regmask = RX8901_REG_PWSW_CFG_INIEN;
+ regval = FIELD_PREP(RX8901_REG_PWSW_CFG_INIEN, 1);
+ break;
+ default:
+ return -EINVAL;
+ }
+ ret = regmap_update_bits(ds1307->regmap, RX8901_REG_PWSW_CFG, regmask, regval);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+#else
+#define rx8901_ioctl NULL
+#define rx8901_param_get NULL
+#define rx8901_param_set NULL
+#endif
+
static int ds1337_read_alarm(struct device *dev, struct rtc_wkalrm *t)
{
struct ds1307 *ds1307 = dev_get_drvdata(dev);
@@ -533,7 +682,7 @@ static int ds1307_alarm_irq_enable(struct device *dev, unsigned int enabled)
enabled ? DS1337_BIT_A1IE : 0);
}
-static u8 do_trickle_setup_ds1339(struct ds1307 *ds1307, u32 ohms, bool diode)
+static int do_trickle_setup_ds1339(struct ds1307 *ds1307, u32 ohms, bool diode)
{
u8 setup = (diode) ? DS1307_TRICKLE_CHARGER_DIODE :
DS1307_TRICKLE_CHARGER_NO_DIODE;
@@ -558,7 +707,7 @@ static u8 do_trickle_setup_ds1339(struct ds1307 *ds1307, u32 ohms, bool diode)
return setup;
}
-static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
+static int do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
{
/* make sure that the backup battery is enabled */
u8 setup = RX8130_REG_CONTROL1_INIEN;
@@ -568,6 +717,26 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
return setup;
}
+static int do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms __always_unused, bool diode)
+{
+ int ret;
+ unsigned int setup;
+
+ ret = regmap_read(ds1307->regmap, RX8901_REG_PWSW_CFG, &setup);
+ if (ret) {
+ dev_err(ds1307->dev, "Failed to read PWSW_CFG register\n");
+ return ret;
+ }
+
+ /* Enable low battery voltage detection */
+ setup |= RX8901_REG_PWSW_CFG_VBATLDETEN;
+
+ if (diode)
+ setup |= RX8901_REG_PWSW_CFG_CHGEN;
+
+ return setup;
+}
+
static irqreturn_t rx8130_irq(int irq, void *dev_id)
{
struct ds1307 *ds1307 = dev_id;
@@ -960,6 +1129,14 @@ static const struct rtc_class_ops rx8130_rtc_ops = {
.alarm_irq_enable = rx8130_alarm_irq_enable,
};
+static const struct rtc_class_ops rx8901_rtc_ops = {
+ .read_time = ds1307_get_time,
+ .set_time = ds1307_set_time,
+ .ioctl = rx8901_ioctl,
+ .param_get = rx8901_param_get,
+ .param_set = rx8901_param_set,
+};
+
static const struct rtc_class_ops mcp794xx_rtc_ops = {
.read_time = ds1307_get_time,
.set_time = ds1307_set_time,
@@ -1040,6 +1217,12 @@ static const struct chip_desc chips[last_ds_type] = {
.trickle_charger_reg = RX8130_REG_CONTROL1,
.do_trickle_setup = &do_trickle_setup_rx8130,
},
+ [rx_8901] = {
+ .offset = 0x0,
+ .rtc_ops = &rx8901_rtc_ops,
+ .trickle_charger_reg = RX8901_REG_PWSW_CFG,
+ .do_trickle_setup = &do_trickle_setup_rx8901,
+ },
[m41t0] = {
.rtc_ops = &m41txx_rtc_ops,
},
@@ -1081,6 +1264,7 @@ static const struct i2c_device_id ds1307_id[] = {
{ "rx8025", rx_8025 },
{ "isl12057", ds_1337 },
{ "rx8130", rx_8130 },
+ { "rx8901", rx_8901 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ds1307_id);
@@ -1158,6 +1342,10 @@ static const struct of_device_id ds1307_of_match[] = {
.compatible = "epson,rx8130",
.data = (void *)rx_8130
},
+ {
+ .compatible = "epson,rx8901",
+ .data = (void *)rx_8901
+ },
{ }
};
MODULE_DEVICE_TABLE(of, ds1307_of_match);
@@ -1292,7 +1480,7 @@ static int ds1307_nvram_write(void *priv, unsigned int offset, void *val,
/*----------------------------------------------------------------------*/
-static u8 ds1307_trickle_init(struct ds1307 *ds1307,
+static int ds1307_trickle_init(struct ds1307 *ds1307,
const struct chip_desc *chip)
{
u32 ohms, chargeable;
@@ -1745,7 +1933,7 @@ static int ds1307_probe(struct i2c_client *client)
bool ds1307_can_wakeup_device = false;
unsigned char regs[8];
struct ds1307_platform_data *pdata = dev_get_platdata(&client->dev);
- u8 trickle_charger_setup = 0;
+ int trickle_charger_setup = 0;
ds1307 = devm_kzalloc(&client->dev, sizeof(struct ds1307), GFP_KERNEL);
if (!ds1307)
@@ -1781,12 +1969,15 @@ static int ds1307_probe(struct i2c_client *client)
else if (pdata->trickle_charger_setup)
trickle_charger_setup = pdata->trickle_charger_setup;
+ if (trickle_charger_setup < 0)
+ return trickle_charger_setup;
+
if (trickle_charger_setup && chip->trickle_charger_reg) {
dev_dbg(ds1307->dev,
"writing trickle charger info 0x%x to 0x%x\n",
trickle_charger_setup, chip->trickle_charger_reg);
regmap_write(ds1307->regmap, chip->trickle_charger_reg,
- trickle_charger_setup);
+ (u8)trickle_charger_setup);
}
/*
@@ -1990,6 +2181,13 @@ static int ds1307_probe(struct i2c_client *client)
}
}
+ switch (ds1307->type) {
+ case rx_8901:
+ set_bit(RTC_FEATURE_BACKUP_SWITCH_MODE, ds1307->rtc->features);
+ break;
+ default:
+ }
+
ds1307->rtc->ops = chip->rtc_ops ?: &ds13xx_rtc_ops;
err = ds1307_add_frequency_test(ds1307);
if (err)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: rtc: ds1307: Add epson,rx8901
From: Fredrik M Olsson @ 2026-05-20 14:48 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nobuhiro Iwamatsu
Cc: linux-rtc, devicetree, linux-kernel, Fredrik M Olsson, kernel,
Krzysztof Kozlowski, Nobuhiro Iwamatsu
In-Reply-To: <20260520-ds1307-rx8901-add-v2-0-e069ea32e1db@axis.com>
Add compatible string epson,rx8901 for the Epson RX8901CE RTC.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@mail.toshiba>
Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
---
Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml b/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml
index 98d10e680144..9b2796804f07 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml
+++ b/Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml
@@ -31,6 +31,7 @@ properties:
- epson,rx8025
- isil,isl12057
- epson,rx8130
+ - epson,rx8901
- items:
- enum:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] rtc: ds1307: Add support for Epson RX8901CE
From: Fredrik M Olsson @ 2026-05-20 14:48 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nobuhiro Iwamatsu
Cc: linux-rtc, devicetree, linux-kernel, Fredrik M Olsson, kernel,
Krzysztof Kozlowski, Nobuhiro Iwamatsu
Add basic support for the Epson RX8901CE RTC.
Datasheet: https://download.epsondevice.com/td/pdf/app/RX8901CE_en.pdf
Also includes a bug fix for an issue with reading the weekday from the
RTC which affects both the existing rx8130 and this rx8901 driver.
Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
---
Changes in v2:
- Squashed the Voltage Low status patch into the driver patch
- Switch from dev_err to dev_dbg
- Implement Backup Switch Mode (BSM) ioctl instead of hard coding
switching mode.
- Change the prototype for the do_trickle_setup function pointer in
order to make it possible to propagate error codes from the added
PWSW_CFG register read operation. This read operation is added so not
to override previously set register fields.
- Link to v1: https://lore.kernel.org/r/20251219-ds1307-rx8901-add-v1-0-b13f346ebe93@axis.com
---
Fredrik M Olsson (3):
dt-bindings: rtc: ds1307: Add epson,rx8901
rtc: ds1307: Fix off-by-one issue with wday for rx8130
rtc: ds1307: Add driver for Epson RX8901CE
.../devicetree/bindings/rtc/rtc-ds1307.yaml | 1 +
drivers/rtc/rtc-ds1307.c | 218 ++++++++++++++++++++-
2 files changed, 209 insertions(+), 10 deletions(-)
---
base-commit: 27fa82620cbaa89a7fc11ac3057701d598813e87
change-id: 20251126-ds1307-rx8901-add-a0fe173093e3
Best regards,
--
Fredrik M Olsson <fredrik.m.olsson@axis.com>
^ permalink raw reply
* [PATCH v2 2/3] rtc: ds1307: Fix off-by-one issue with wday for rx8130
From: Fredrik M Olsson @ 2026-05-20 14:48 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nobuhiro Iwamatsu
Cc: linux-rtc, devicetree, linux-kernel, Fredrik M Olsson, kernel
In-Reply-To: <20260520-ds1307-rx8901-add-v2-0-e069ea32e1db@axis.com>
The RTC represent each weekday with a individual bit set in the WDAY
register, where the 0th bit represent the first day of the week and the
6th bit represents the last day of the week. For each passed day the
chip performs a rotary-left-shift by one to advance the weekday by one.
The tm_wday field represent weekdays by a value in the range of 0-6.
The fls() function return the bit index of the last bit set. To handle
when there are no bits set it will return 0, and if the 0th bit is set
it will return 1, and if the 1st bit is set it will return 2, and so on.
In order to make the result of the fls() function fall into the expected
range of 0-6 (instead of 1-7) this patch subtracts one from the result
(which matches how the value is written in ds1307_set_time()).
Fixes: 204756f016726 ("rtc: ds1307: Fix wday settings for rx8130")
Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.x90@mail.toshiba>
Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
---
drivers/rtc/rtc-ds1307.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index 7205c59ff729..bf42c250ea7d 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -308,7 +308,7 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
t->tm_hour = bcd2bin(tmp);
/* rx8130 is bit position, not BCD */
if (ds1307->type == rx_8130)
- t->tm_wday = fls(regs[DS1307_REG_WDAY] & 0x7f);
+ t->tm_wday = fls(regs[DS1307_REG_WDAY] & 0x7f) - 1;
else
t->tm_wday = bcd2bin(regs[DS1307_REG_WDAY] & 0x07) - 1;
t->tm_mday = bcd2bin(regs[DS1307_REG_MDAY] & 0x3f);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: clock: via,vt8500: Convert to DT Schema
From: Rob Herring (Arm) @ 2026-05-20 3:41 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: devicetree, sboyd, linux-kernel, linux-rtc, me, krzk+dt, skhan,
mturquette, conor+dt
In-Reply-To: <20260520025131.17772-1-challauday369@gmail.com>
On Wed, 20 May 2026 08:18:53 +0530, Udaya Kiran Challa wrote:
> Convert the VIA/Wondermedia VT8500 and Wondermedia WM8xxx series SoCs clock
> controller binding from the legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
> .../bindings/clock/via,vt8500-clock.yaml | 122 ++++++++++++++++++
> .../devicetree/bindings/clock/vt8500.txt | 74 -----------
> 2 files changed, 122 insertions(+), 74 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/vt8500.txt
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/via,vt8500-clock.example.dtb: /: clock@200:reg:0: [512] is too short
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/via,vt8500-clock.example.dtb: /: #size-cells: 0 is not one of [1, 2]
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/via,vt8500-clock.example.dtb: /: 'compatible' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/clock/via,vt8500-clock.example.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260520025131.17772-1-challauday369@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH] dt-bindings: clock: via,vt8500: Convert to DT Schema
From: Udaya Kiran Challa @ 2026-05-20 2:48 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert the VIA/Wondermedia VT8500 and Wondermedia WM8xxx series SoCs clock
controller binding from the legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
.../bindings/clock/via,vt8500-clock.yaml | 122 ++++++++++++++++++
.../devicetree/bindings/clock/vt8500.txt | 74 -----------
2 files changed, 122 insertions(+), 74 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/vt8500.txt
diff --git a/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
new file mode 100644
index 000000000000..9c312d11a6a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/via,vt8500-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA/Wondermedia VT8500 Clock Controller
+
+maintainers:
+ - Michael Turquette <mturquette@baylibre.com>
+ - Stephen Boyd <sboyd@kernel.org>
+
+description: |
+ Clock controller bindings for VIA/Wondermedia VT8500 and Wondermedia WM8xxx
+ series SoCs.
+
+properties:
+ compatible:
+ enum:
+ - via,vt8500-pll-clock
+ - wm,wm8650-pll-clock
+ - wm,wm8750-pll-clock
+ - wm,wm8850-pll-clock
+ - via,vt8500-device-clock
+
+ reg:
+ maxItems: 1
+ description:
+ Offset of the PLL register within the PMC register space.
+
+ clocks:
+ maxItems: 1
+ description:
+ Parent reference clock.
+
+ "#clock-cells":
+ const: 0
+
+ enable-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset of the clock enable register within the PMC register space.
+
+ enable-bit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 31
+ description:
+ Bit index controlling clock enable.
+
+ divisor-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset of the clock divisor register within the PMC register space.
+
+ divisor-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Bitmask describing the divisor field inside divisor-reg.
+
+required:
+ - compatible
+ - "#clock-cells"
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - via,vt8500-pll-clock
+ - wm,wm8650-pll-clock
+ - wm,wm8750-pll-clock
+ - wm,wm8850-pll-clock
+ then:
+ required:
+ - reg
+ - clocks
+
+ - if:
+ properties:
+ compatible:
+ const: via,vt8500-device-clock
+ then:
+ required:
+ - clocks
+ anyOf:
+ - required:
+ - enable-reg
+ - enable-bit
+ - required:
+ - divisor-reg
+
+additionalProperties: false
+
+examples:
+ - |
+ / {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ref25: ref25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ plla: clock@200 {
+ compatible = "wm,wm8650-pll-clock";
+ reg = <0x200>;
+ clocks = <&ref25>;
+ #clock-cells = <0>;
+ };
+
+ clksdhc: clock {
+ compatible = "via,vt8500-device-clock";
+ clocks = <&plla>;
+ divisor-reg = <0x328>;
+ divisor-mask = <0x3f>;
+ enable-reg = <0x254>;
+ enable-bit = <18>;
+ #clock-cells = <0>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/vt8500.txt b/Documentation/devicetree/bindings/clock/vt8500.txt
deleted file mode 100644
index 91d71cc0314a..000000000000
--- a/Documentation/devicetree/bindings/clock/vt8500.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Device Tree Clock bindings for arch-vt8500
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be one of the following:
- "via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
- "wm,wm8650-pll-clock" - for a WM8650 PLL clock
- "wm,wm8750-pll-clock" - for a WM8750 PLL clock
- "wm,wm8850-pll-clock" - for a WM8850 PLL clock
- "via,vt8500-device-clock" - for a VT/WM device clock
-
-Required properties for PLL clocks:
-- reg : shall be the control register offset from PMC base for the pll clock.
-- clocks : shall be the input parent clock phandle for the clock. This should
- be the reference clock.
-- #clock-cells : from common clock binding; shall be set to 0.
-
-Required properties for device clocks:
-- clocks : shall be the input parent clock phandle for the clock. This should
- be a pll output.
-- #clock-cells : from common clock binding; shall be set to 0.
-
-
-Device Clocks
-
-Device clocks are required to have one or both of the following sets of
-properties:
-
-
-Gated device clocks:
-
-Required properties:
-- enable-reg : shall be the register offset from PMC base for the enable
- register.
-- enable-bit : shall be the bit within enable-reg to enable/disable the clock.
-
-
-Divisor device clocks:
-
-Required property:
-- divisor-reg : shall be the register offset from PMC base for the divisor
- register.
-Optional property:
-- divisor-mask : shall be the mask for the divisor register. Defaults to 0x1f
- if not specified.
-
-
-For example:
-
-ref25: ref25M {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <25000000>;
-};
-
-plla: plla {
- #clock-cells = <0>;
- compatible = "wm,wm8650-pll-clock";
- clocks = <&ref25>;
- reg = <0x200>;
-};
-
-sdhc: sdhc {
- #clock-cells = <0>;
- compatible = "via,vt8500-device-clock";
- clocks = <&pllb>;
- divisor-reg = <0x328>;
- divisor-mask = <0x3f>;
- enable-reg = <0x254>;
- enable-bit = <18>;
-};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: rtc: Convert rtc-cmos binding to YAML
From: Conor Dooley @ 2026-05-19 16:37 UTC (permalink / raw)
To: Teja Sai Charan B
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rtc, devicetree, linux-kernel
In-Reply-To: <20260519095929.76011-1-tejaasaye@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3761 bytes --]
On Tue, May 19, 2026 at 03:29:29PM +0530, Teja Sai Charan B wrote:
> From: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
>
> Convert the rtc-cmos devicetree bindings to dt schema.
>
> Signed-off-by: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
> ---
> .../devicetree/bindings/rtc/rtc-cmos.txt | 27 ---------
> .../devicetree/bindings/rtc/rtc-cmos.yaml | 55 +++++++++++++++++++
> 2 files changed, 55 insertions(+), 27 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.txt
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
> deleted file mode 100644
> index 7d7b5f6bda65..000000000000
> --- a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
> +++ /dev/null
> @@ -1,27 +0,0 @@
> - Motorola mc146818 compatible RTC
> -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> -
> -Required properties:
> - - compatible : "motorola,mc146818"
> - - reg : should contain registers location and length.
> -
> -Optional properties:
> - - interrupts : should contain interrupt.
> - - ctrl-reg : Contains the initial value of the control register also
> - called "Register B".
> - - freq-reg : Contains the initial value of the frequency register also
> - called "Register A".
> -
> -"Register A" and "B" are usually initialized by the firmware (BIOS for
> -instance). If this is not done, it can be performed by the driver.
> -
> -ISA Example:
> -
> - rtc@70 {
> - compatible = "motorola,mc146818";
> - interrupts = <8 3>;
> - interrupt-parent = <&ioapic1>;
> - ctrl-reg = <2>;
> - freq-reg = <0x26>;
> - reg = <1 0x70 2>;
> - };
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
> new file mode 100644
> index 000000000000..e368264ac483
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/rtc-cmos.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola mc146818 compatible RTC
> +
> +maintainers:
> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
> +
> +properties:
> + compatible:
> + const: motorola,mc146818
It's not a problem with the conversion per se, but as sashiko pointed out,
there's an intel device with a soc-specific compatible.
Could you document that here, with a fallback to this motorola one
please?
pw-bot: changes-requested
Thanks,
Conor.
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + ctrl-reg:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Initial value of the control register
> + (also known as Register B).
> +
> + freq-reg:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Initial value of the frequency register
> + (also known as Register A).
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + rtc@70 {
> + compatible = "motorola,mc146818";
> + reg = <1 0x70 2>;
Please be consistent here about using only hex, even if the text file
didn't do that.
> +
> + interrupts = <8 3>;
> +
> + ctrl-reg = <2>;
> + freq-reg = <0x26>;
> + };
> + };
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Krzysztof Kozlowski @ 2026-05-19 13:31 UTC (permalink / raw)
To: Kaustabh Chakraborty, Conor Dooley
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <DIMN3D9E8YCT.3T2PGAYYB2IOO@disroot.org>
On 19/05/2026 14:07, Kaustabh Chakraborty wrote:
>>>>
>>>> I don't think the compatible should be here, but I also don't want to
>>>> stall that patchset. I understand that it is inconsistent review from my
>>>> side, because other similar patchsets receive comment to drop the
>>>> compatible. But I don't think we will be fair asking to drop the
>>>> compatible now, when we did not ask for that in the early versions at all.
>>>
>>>
>>> I think you misunderstood, we were talking about the ordering of the
>>> properties in the binding file being alphanumerical, rather than the
>>> more typical approach of approximately following the order of
>>> dts-coding-style.
>>
>>
>> Ah, then I misunderstood and, even though it is a nit, I do care because
>> old code is then used for new patches. Bindings follow DTS rules, thus
>> should be:
>> 1. compatible
>> 2. reg
>> 3. core properties
>> 4. vendor properties
>>
>> Kaustabh, can you change it please?
>
> Ack, will do that in v8 then.
>
> While at it, do you also want me to drop the multi-led compatible string?
> So it would be:
Yes
>
> multi-led:
> $ref: /schemas/leds/leds-class-multicolor.yaml#
with "unevaluatedProperties: false"
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Kaustabh Chakraborty @ 2026-05-19 12:07 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <0240eb13-6c56-4879-8db7-b990a220a78f@kernel.org>
On 2026-05-18 12:23 +02:00, Krzysztof Kozlowski wrote:
> On 18/05/2026 11:45, Conor Dooley wrote:
>> On Mon, May 18, 2026 at 09:15:11AM +0200, Krzysztof Kozlowski wrote:
>>> On 17/05/2026 22:52, Conor Dooley wrote:
>>>> On Sun, May 17, 2026 at 06:39:37PM +0530, Kaustabh Chakraborty wrote:
>>>>>>>>>> +
>>>>>>>>> + properties:
>>>>>>>>> + compatible:
>>>>>>>>> + const: samsung,s2mu005-rgb
>>>>>>>>> +
>>>>>>>>> + required:
>>>>>>>>> + - compatible
>>>>>>>>> +
>>>>>>>>> + unevaluatedProperties: false
>>>>>>>>> +
>>>>>>>>> + reg:
>>>>>>>>> + maxItems: 1
>>>>>>>>
>>>>>>>> Move this above the child nodes please.
>>>>>>>
>>>>>>> But properties are sorted in lex order?
>>>>>>
>>>>>> Typically the binding is sorted in the same order as properties go in
>>>>>> nodes. Common stuff like reg/clocks/interrupts therefore send up above
>>>>>> child nodes.
>>>>>
>>>>> So, do I change this? For one, I don't see the same being followed in
>>>>> other schemas of samsung in the same dir (not that I'm trying to pose it
>>>>> as an argument against your suggestion), and this was reviewed by
>>>>> Krzysztof and is adderssed in v7.
>>>>
>>>> If Krzysztof doesn't care, then I won't ask you to change it.
>>>
>>> This builds on top of bindings for previous Samsung PMIC devices, so
>>> that's why it keeps the compatibles for children, I guess. No one
>>> complained about this at v1-v2 reviews, so when I joined reviewing in v3
>>> I did not, either.
>>>
>>> I don't think the compatible should be here, but I also don't want to
>>> stall that patchset. I understand that it is inconsistent review from my
>>> side, because other similar patchsets receive comment to drop the
>>> compatible. But I don't think we will be fair asking to drop the
>>> compatible now, when we did not ask for that in the early versions at all.
>>
>>
>> I think you misunderstood, we were talking about the ordering of the
>> properties in the binding file being alphanumerical, rather than the
>> more typical approach of approximately following the order of
>> dts-coding-style.
>
>
> Ah, then I misunderstood and, even though it is a nit, I do care because
> old code is then used for new patches. Bindings follow DTS rules, thus
> should be:
> 1. compatible
> 2. reg
> 3. core properties
> 4. vendor properties
>
> Kaustabh, can you change it please?
Ack, will do that in v8 then.
While at it, do you also want me to drop the multi-led compatible string?
So it would be:
multi-led:
$ref: /schemas/leds/leds-class-multicolor.yaml#
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: rtc: Convert rtc-cmos binding to YAML
From: Teja Sai Charan B @ 2026-05-19 9:59 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-rtc, devicetree, linux-kernel, Teja Sai Charan Bellamkonda
From: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
Convert the rtc-cmos devicetree bindings to dt schema.
Signed-off-by: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
---
.../devicetree/bindings/rtc/rtc-cmos.txt | 27 ---------
.../devicetree/bindings/rtc/rtc-cmos.yaml | 55 +++++++++++++++++++
2 files changed, 55 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.txt
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
deleted file mode 100644
index 7d7b5f6bda65..000000000000
--- a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt
+++ /dev/null
@@ -1,27 +0,0 @@
- Motorola mc146818 compatible RTC
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Required properties:
- - compatible : "motorola,mc146818"
- - reg : should contain registers location and length.
-
-Optional properties:
- - interrupts : should contain interrupt.
- - ctrl-reg : Contains the initial value of the control register also
- called "Register B".
- - freq-reg : Contains the initial value of the frequency register also
- called "Register A".
-
-"Register A" and "B" are usually initialized by the firmware (BIOS for
-instance). If this is not done, it can be performed by the driver.
-
-ISA Example:
-
- rtc@70 {
- compatible = "motorola,mc146818";
- interrupts = <8 3>;
- interrupt-parent = <&ioapic1>;
- ctrl-reg = <2>;
- freq-reg = <0x26>;
- reg = <1 0x70 2>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
new file mode 100644
index 000000000000..e368264ac483
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/rtc-cmos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Motorola mc146818 compatible RTC
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+properties:
+ compatible:
+ const: motorola,mc146818
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ ctrl-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Initial value of the control register
+ (also known as Register B).
+
+ freq-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Initial value of the frequency register
+ (also known as Register A).
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ rtc@70 {
+ compatible = "motorola,mc146818";
+ reg = <1 0x70 2>;
+
+ interrupts = <8 3>;
+
+ ctrl-reg = <2>;
+ freq-reg = <0x26>;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] rtc: Add rtc_read_next_alarm() to read next expiring timer
From: Ilpo Järvinen @ 2026-05-18 17:35 UTC (permalink / raw)
To: Mario Limonciello
Cc: Shyam Sundar S K, Alexandre Belloni, Hans de Goede,
platform-driver-x86, LKML, linux-rtc, Thomas Gleixner
In-Reply-To: <340a79fc-864a-498c-bdfc-3c4929b5e9ae@amd.com>
[-- Attachment #1: Type: text/plain, Size: 4277 bytes --]
On Mon, 18 May 2026, Mario Limonciello wrote:
> On 5/18/26 11:48, Ilpo Järvinen wrote:
> > On Mon, 18 May 2026, Mario Limonciello wrote:
> >
> > > Add a new function rtc_read_next_alarm() that reads the next expiring
> > > alarm from the RTC timerqueue. This is different from rtc_read_alarm(),
> > > which only reads the aie_timer.
> > >
> > > The wakealarm sysfs file programs the rtc->aie_timer, whereas the
> > > alarmtimer suspend routine programs its own timer into the RTC timerqueue.
> > > Both timers end up in the RTC's timerqueue, and the first expiring timer
> > > is what gets armed in the hardware.
> > >
> > > This new function allows code to query which alarm will actually fire
> > > next, regardless of which subsystem programmed it. This is needed by
> > > platform code that needs to program secondary timers based on the
> > > actual next wakeup time.
> > >
> > > Link: https://lore.kernel.org/all/87ed50z0le.ffs@tglx
> > > Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> > > Assisted-by: Claude:claude-opus-4-6
> > > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > > ---
> > > drivers/rtc/interface.c | 42 +++++++++++++++++++++++++++++++++++++++++
> > > include/linux/rtc.h | 2 ++
> > > 2 files changed, 44 insertions(+)
> > >
> > > diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> > > index 1906f4884a834..dfcb32e272eb9 100644
> > > --- a/drivers/rtc/interface.c
> > > +++ b/drivers/rtc/interface.c
> > > @@ -384,6 +384,48 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct
> > > rtc_wkalrm *alarm)
> > > return err;
> > > }
> > > +/**
> > > + * rtc_read_next_alarm - read the next expiring alarm
> > > + * @rtc: RTC device
> > > + * @alarm: storage for the alarm information
> > > + *
> > > + * Read the next expiring alarm from the RTC timerqueue. This returns
> > > + * the alarm that will actually fire next, which may be different from
> > > + * rtc_read_alarm() if multiple timers are queued (e.g., alarmtimer
> > > + * and wakealarm sysfs both active).
> > > + *
> > > + * Returns 0 on success, -ENOENT if no alarm is pending, or other error.
> >
> > Missing :
>
> Like this you mean, right?
>
> Returns: 0 on success,..
Yes.
> > > + */
> > > +int rtc_read_next_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
> > > +{
> > > + struct timerqueue_node *next;
> > > + int err;
> > > +
> > > + if (!rtc || !alarm)
> > > + return -EINVAL;
> > > +
> > > + err = mutex_lock_interruptible(&rtc->ops_lock);
> > > + if (err)
> > > + return err;
> > > +
> > > + next = timerqueue_getnext(&rtc->timerqueue);
> > > + if (!next) {
> > > + err = -ENOENT;
> > > + goto unlock;
> > > + }
> > > +
> > > + memset(alarm, 0, sizeof(struct rtc_wkalrm));
> > > + alarm->time = rtc_ktime_to_tm(next->expires);
> > > + alarm->enabled = 1;
> > > + alarm->pending = 0;
> >
> > Doesn't the preceeding memset() already clear everything?
>
> Yeah; good point.
>
> >
> > > + err = 0;
> >
> > Why is this needed?
>
> Oh I guess your point is that err was set to zero by
> mutex_lock_interruptible() already, so this is unecessary.
>
> Good catch, will drop it, thx.
>
> >
> > > +
> > > +unlock:
> > > + mutex_unlock(&rtc->ops_lock);
> > > + return err;
> > > +}
> > > +EXPORT_SYMBOL_GPL(rtc_read_next_alarm);
> > > +
> > > int rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
> > > {
> > > int err;
> > > diff --git a/include/linux/rtc.h b/include/linux/rtc.h
> > > index 95da051fb155d..c09fc22819d0c 100644
> > > --- a/include/linux/rtc.h
> > > +++ b/include/linux/rtc.h
> > > @@ -190,6 +190,8 @@ extern int rtc_set_time(struct rtc_device *rtc, struct
> > > rtc_time *tm);
> > > int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm);
> > > extern int rtc_read_alarm(struct rtc_device *rtc,
> > > struct rtc_wkalrm *alrm);
> > > +extern int rtc_read_next_alarm(struct rtc_device *rtc,
> > > + struct rtc_wkalrm *alrm);
> > > extern int rtc_set_alarm(struct rtc_device *rtc,
> > > struct rtc_wkalrm *alrm);
> > > extern int rtc_initialize_alarm(struct rtc_device *rtc,
> > >
> >
>
>
--
i.
^ permalink raw reply
* Re: [PATCH 1/2] rtc: Add rtc_read_next_alarm() to read next expiring timer
From: Mario Limonciello @ 2026-05-18 17:30 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Shyam Sundar S K, Alexandre Belloni, Hans de Goede,
platform-driver-x86, LKML, linux-rtc, Thomas Gleixner
In-Reply-To: <6be68c57-929b-ccf0-84a5-6f40c4c0c330@linux.intel.com>
On 5/18/26 11:48, Ilpo Järvinen wrote:
> On Mon, 18 May 2026, Mario Limonciello wrote:
>
>> Add a new function rtc_read_next_alarm() that reads the next expiring
>> alarm from the RTC timerqueue. This is different from rtc_read_alarm(),
>> which only reads the aie_timer.
>>
>> The wakealarm sysfs file programs the rtc->aie_timer, whereas the
>> alarmtimer suspend routine programs its own timer into the RTC timerqueue.
>> Both timers end up in the RTC's timerqueue, and the first expiring timer
>> is what gets armed in the hardware.
>>
>> This new function allows code to query which alarm will actually fire
>> next, regardless of which subsystem programmed it. This is needed by
>> platform code that needs to program secondary timers based on the
>> actual next wakeup time.
>>
>> Link: https://lore.kernel.org/all/87ed50z0le.ffs@tglx
>> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
>> Assisted-by: Claude:claude-opus-4-6
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>> drivers/rtc/interface.c | 42 +++++++++++++++++++++++++++++++++++++++++
>> include/linux/rtc.h | 2 ++
>> 2 files changed, 44 insertions(+)
>>
>> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
>> index 1906f4884a834..dfcb32e272eb9 100644
>> --- a/drivers/rtc/interface.c
>> +++ b/drivers/rtc/interface.c
>> @@ -384,6 +384,48 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
>> return err;
>> }
>>
>> +/**
>> + * rtc_read_next_alarm - read the next expiring alarm
>> + * @rtc: RTC device
>> + * @alarm: storage for the alarm information
>> + *
>> + * Read the next expiring alarm from the RTC timerqueue. This returns
>> + * the alarm that will actually fire next, which may be different from
>> + * rtc_read_alarm() if multiple timers are queued (e.g., alarmtimer
>> + * and wakealarm sysfs both active).
>> + *
>> + * Returns 0 on success, -ENOENT if no alarm is pending, or other error.
>
> Missing :
Like this you mean, right?
Returns: 0 on success,..
>
>> + */
>> +int rtc_read_next_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
>> +{
>> + struct timerqueue_node *next;
>> + int err;
>> +
>> + if (!rtc || !alarm)
>> + return -EINVAL;
>> +
>> + err = mutex_lock_interruptible(&rtc->ops_lock);
>> + if (err)
>> + return err;
>> +
>> + next = timerqueue_getnext(&rtc->timerqueue);
>> + if (!next) {
>> + err = -ENOENT;
>> + goto unlock;
>> + }
>> +
>> + memset(alarm, 0, sizeof(struct rtc_wkalrm));
>> + alarm->time = rtc_ktime_to_tm(next->expires);
>> + alarm->enabled = 1;
>> + alarm->pending = 0;
>
> Doesn't the preceeding memset() already clear everything?
Yeah; good point.
>
>> + err = 0;
>
> Why is this needed?
Oh I guess your point is that err was set to zero by
mutex_lock_interruptible() already, so this is unecessary.
Good catch, will drop it, thx.
>
>> +
>> +unlock:
>> + mutex_unlock(&rtc->ops_lock);
>> + return err;
>> +}
>> +EXPORT_SYMBOL_GPL(rtc_read_next_alarm);
>> +
>> int rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
>> {
>> int err;
>> diff --git a/include/linux/rtc.h b/include/linux/rtc.h
>> index 95da051fb155d..c09fc22819d0c 100644
>> --- a/include/linux/rtc.h
>> +++ b/include/linux/rtc.h
>> @@ -190,6 +190,8 @@ extern int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm);
>> int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm);
>> extern int rtc_read_alarm(struct rtc_device *rtc,
>> struct rtc_wkalrm *alrm);
>> +extern int rtc_read_next_alarm(struct rtc_device *rtc,
>> + struct rtc_wkalrm *alrm);
>> extern int rtc_set_alarm(struct rtc_device *rtc,
>> struct rtc_wkalrm *alrm);
>> extern int rtc_initialize_alarm(struct rtc_device *rtc,
>>
>
^ permalink raw reply
* Re: [PATCH 1/2] rtc: Add rtc_read_next_alarm() to read next expiring timer
From: Ilpo Järvinen @ 2026-05-18 16:48 UTC (permalink / raw)
To: Mario Limonciello
Cc: Shyam Sundar S K, Alexandre Belloni, Hans de Goede,
platform-driver-x86, LKML, linux-rtc, Thomas Gleixner
In-Reply-To: <20260518133853.851027-2-mario.limonciello@amd.com>
On Mon, 18 May 2026, Mario Limonciello wrote:
> Add a new function rtc_read_next_alarm() that reads the next expiring
> alarm from the RTC timerqueue. This is different from rtc_read_alarm(),
> which only reads the aie_timer.
>
> The wakealarm sysfs file programs the rtc->aie_timer, whereas the
> alarmtimer suspend routine programs its own timer into the RTC timerqueue.
> Both timers end up in the RTC's timerqueue, and the first expiring timer
> is what gets armed in the hardware.
>
> This new function allows code to query which alarm will actually fire
> next, regardless of which subsystem programmed it. This is needed by
> platform code that needs to program secondary timers based on the
> actual next wakeup time.
>
> Link: https://lore.kernel.org/all/87ed50z0le.ffs@tglx
> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
> drivers/rtc/interface.c | 42 +++++++++++++++++++++++++++++++++++++++++
> include/linux/rtc.h | 2 ++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index 1906f4884a834..dfcb32e272eb9 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -384,6 +384,48 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
> return err;
> }
>
> +/**
> + * rtc_read_next_alarm - read the next expiring alarm
> + * @rtc: RTC device
> + * @alarm: storage for the alarm information
> + *
> + * Read the next expiring alarm from the RTC timerqueue. This returns
> + * the alarm that will actually fire next, which may be different from
> + * rtc_read_alarm() if multiple timers are queued (e.g., alarmtimer
> + * and wakealarm sysfs both active).
> + *
> + * Returns 0 on success, -ENOENT if no alarm is pending, or other error.
Missing :
> + */
> +int rtc_read_next_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
> +{
> + struct timerqueue_node *next;
> + int err;
> +
> + if (!rtc || !alarm)
> + return -EINVAL;
> +
> + err = mutex_lock_interruptible(&rtc->ops_lock);
> + if (err)
> + return err;
> +
> + next = timerqueue_getnext(&rtc->timerqueue);
> + if (!next) {
> + err = -ENOENT;
> + goto unlock;
> + }
> +
> + memset(alarm, 0, sizeof(struct rtc_wkalrm));
> + alarm->time = rtc_ktime_to_tm(next->expires);
> + alarm->enabled = 1;
> + alarm->pending = 0;
Doesn't the preceeding memset() already clear everything?
> + err = 0;
Why is this needed?
> +
> +unlock:
> + mutex_unlock(&rtc->ops_lock);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(rtc_read_next_alarm);
> +
> int rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
> {
> int err;
> diff --git a/include/linux/rtc.h b/include/linux/rtc.h
> index 95da051fb155d..c09fc22819d0c 100644
> --- a/include/linux/rtc.h
> +++ b/include/linux/rtc.h
> @@ -190,6 +190,8 @@ extern int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm);
> int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm);
> extern int rtc_read_alarm(struct rtc_device *rtc,
> struct rtc_wkalrm *alrm);
> +extern int rtc_read_next_alarm(struct rtc_device *rtc,
> + struct rtc_wkalrm *alrm);
> extern int rtc_set_alarm(struct rtc_device *rtc,
> struct rtc_wkalrm *alrm);
> extern int rtc_initialize_alarm(struct rtc_device *rtc,
>
--
i.
^ permalink raw reply
* [PATCH 2/2] platform/x86: amd-pmc: Fix S0i3 wakeup with alarmtimer
From: Mario Limonciello @ 2026-05-18 13:38 UTC (permalink / raw)
To: Shyam Sundar S K, Alexandre Belloni
Cc: Hans de Goede, Ilpo Järvinen, platform-driver-x86,
linux-kernel, linux-rtc, Thomas Gleixner, Mario Limonciello
In-Reply-To: <20260518133853.851027-1-mario.limonciello@amd.com>
It was reported that suspend-then-hibernate stopped working with modern
systemd versions on AMD Cezanne systems. The reason for this breakage
was because systemd switched to using alarmtimer instead of the wakealarm
sysfs file.
On AMD Cezanne systems, amd_pmc_verify_czn_rtc() programs a secondary
timer with the alarm time. This was introduced by
commit 59348401ebed ("platform/x86: amd-pmc: Add special handling for
timer based S0i3 wakeup"). However, this function uses rtc_read_alarm(),
which only reads the aie_timer, not the next expiring timer from the
timerqueue.
When both alarmtimer and wakealarm are active, the first expiring timer
might be the alarmtimer, but amd_pmc_verify_czn_rtc() would only see
the aie_timer, potentially missing the earlier alarm.
Switch to rtc_read_next_alarm() to read whichever timer will fire next.
Also handle -ENOENT (no alarm pending) explicitly as a non-error case.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3591
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/platform/x86/amd/pmc/pmc.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/amd/pmc/pmc.c b/drivers/platform/x86/amd/pmc/pmc.c
index 50f5784f2aa2e..8cd2db0ccaacd 100644
--- a/drivers/platform/x86/amd/pmc/pmc.c
+++ b/drivers/platform/x86/amd/pmc/pmc.c
@@ -595,9 +595,12 @@ static int amd_pmc_verify_czn_rtc(struct amd_pmc_dev *pdev, u32 *arg)
rtc_device = rtc_class_open("rtc0");
if (!rtc_device)
return 0;
- rc = rtc_read_alarm(rtc_device, &alarm);
- if (rc)
- return rc;
+ rc = rtc_read_next_alarm(rtc_device, &alarm);
+ if (rc) {
+ if (rc == -ENOENT)
+ dev_dbg(pdev->dev, "no alarm pending\n");
+ return rc == -ENOENT ? 0 : rc;
+ }
if (!alarm.enabled) {
dev_dbg(pdev->dev, "alarm not enabled\n");
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] rtc: Add rtc_read_next_alarm() to read next expiring timer
From: Mario Limonciello @ 2026-05-18 13:38 UTC (permalink / raw)
To: Shyam Sundar S K, Alexandre Belloni
Cc: Hans de Goede, Ilpo Järvinen, platform-driver-x86,
linux-kernel, linux-rtc, Thomas Gleixner, Mario Limonciello
In-Reply-To: <20260518133853.851027-1-mario.limonciello@amd.com>
Add a new function rtc_read_next_alarm() that reads the next expiring
alarm from the RTC timerqueue. This is different from rtc_read_alarm(),
which only reads the aie_timer.
The wakealarm sysfs file programs the rtc->aie_timer, whereas the
alarmtimer suspend routine programs its own timer into the RTC timerqueue.
Both timers end up in the RTC's timerqueue, and the first expiring timer
is what gets armed in the hardware.
This new function allows code to query which alarm will actually fire
next, regardless of which subsystem programmed it. This is needed by
platform code that needs to program secondary timers based on the
actual next wakeup time.
Link: https://lore.kernel.org/all/87ed50z0le.ffs@tglx
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
drivers/rtc/interface.c | 42 +++++++++++++++++++++++++++++++++++++++++
include/linux/rtc.h | 2 ++
2 files changed, 44 insertions(+)
diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 1906f4884a834..dfcb32e272eb9 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -384,6 +384,48 @@ int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
return err;
}
+/**
+ * rtc_read_next_alarm - read the next expiring alarm
+ * @rtc: RTC device
+ * @alarm: storage for the alarm information
+ *
+ * Read the next expiring alarm from the RTC timerqueue. This returns
+ * the alarm that will actually fire next, which may be different from
+ * rtc_read_alarm() if multiple timers are queued (e.g., alarmtimer
+ * and wakealarm sysfs both active).
+ *
+ * Returns 0 on success, -ENOENT if no alarm is pending, or other error.
+ */
+int rtc_read_next_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
+{
+ struct timerqueue_node *next;
+ int err;
+
+ if (!rtc || !alarm)
+ return -EINVAL;
+
+ err = mutex_lock_interruptible(&rtc->ops_lock);
+ if (err)
+ return err;
+
+ next = timerqueue_getnext(&rtc->timerqueue);
+ if (!next) {
+ err = -ENOENT;
+ goto unlock;
+ }
+
+ memset(alarm, 0, sizeof(struct rtc_wkalrm));
+ alarm->time = rtc_ktime_to_tm(next->expires);
+ alarm->enabled = 1;
+ alarm->pending = 0;
+ err = 0;
+
+unlock:
+ mutex_unlock(&rtc->ops_lock);
+ return err;
+}
+EXPORT_SYMBOL_GPL(rtc_read_next_alarm);
+
int rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm)
{
int err;
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 95da051fb155d..c09fc22819d0c 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -190,6 +190,8 @@ extern int rtc_set_time(struct rtc_device *rtc, struct rtc_time *tm);
int __rtc_read_alarm(struct rtc_device *rtc, struct rtc_wkalrm *alarm);
extern int rtc_read_alarm(struct rtc_device *rtc,
struct rtc_wkalrm *alrm);
+extern int rtc_read_next_alarm(struct rtc_device *rtc,
+ struct rtc_wkalrm *alrm);
extern int rtc_set_alarm(struct rtc_device *rtc,
struct rtc_wkalrm *alrm);
extern int rtc_initialize_alarm(struct rtc_device *rtc,
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] Fix S0i3 wakeup with alarmtimer
From: Mario Limonciello @ 2026-05-18 13:38 UTC (permalink / raw)
To: Shyam Sundar S K, Alexandre Belloni
Cc: Hans de Goede, Ilpo Järvinen, platform-driver-x86,
linux-kernel, linux-rtc, Thomas Gleixner, Mario Limonciello
It was reported that suspend-then-hibernate stopped working with modern
systemd versions on AMD Cezanne systems. The reason for this breakage
was because systemd switched to using alarmtimer instead of the wakealarm
sysfs file.
But really it uncovered deeper problems with how these timers work. Adjust
the code accordingly.
Mario Limonciello (2):
rtc: Add rtc_read_next_alarm() to read next expiring timer
platform/x86: amd-pmc: Fix S0i3 wakeup with alarmtimer
drivers/platform/x86/amd/pmc/pmc.c | 9 ++++---
drivers/rtc/interface.c | 42 ++++++++++++++++++++++++++++++
include/linux/rtc.h | 2 ++
3 files changed, 50 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Krzysztof Kozlowski @ 2026-05-18 10:23 UTC (permalink / raw)
To: Conor Dooley, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260518-succulent-plethora-2dba60fad426@spud>
On 18/05/2026 11:45, Conor Dooley wrote:
> On Mon, May 18, 2026 at 09:15:11AM +0200, Krzysztof Kozlowski wrote:
>> On 17/05/2026 22:52, Conor Dooley wrote:
>>> On Sun, May 17, 2026 at 06:39:37PM +0530, Kaustabh Chakraborty wrote:
>>>>>>>>> +
>>>>>>>> + properties:
>>>>>>>> + compatible:
>>>>>>>> + const: samsung,s2mu005-rgb
>>>>>>>> +
>>>>>>>> + required:
>>>>>>>> + - compatible
>>>>>>>> +
>>>>>>>> + unevaluatedProperties: false
>>>>>>>> +
>>>>>>>> + reg:
>>>>>>>> + maxItems: 1
>>>>>>>
>>>>>>> Move this above the child nodes please.
>>>>>>
>>>>>> But properties are sorted in lex order?
>>>>>
>>>>> Typically the binding is sorted in the same order as properties go in
>>>>> nodes. Common stuff like reg/clocks/interrupts therefore send up above
>>>>> child nodes.
>>>>
>>>> So, do I change this? For one, I don't see the same being followed in
>>>> other schemas of samsung in the same dir (not that I'm trying to pose it
>>>> as an argument against your suggestion), and this was reviewed by
>>>> Krzysztof and is adderssed in v7.
>>>
>>> If Krzysztof doesn't care, then I won't ask you to change it.
>>
>> This builds on top of bindings for previous Samsung PMIC devices, so
>> that's why it keeps the compatibles for children, I guess. No one
>> complained about this at v1-v2 reviews, so when I joined reviewing in v3
>> I did not, either.
>>
>> I don't think the compatible should be here, but I also don't want to
>> stall that patchset. I understand that it is inconsistent review from my
>> side, because other similar patchsets receive comment to drop the
>> compatible. But I don't think we will be fair asking to drop the
>> compatible now, when we did not ask for that in the early versions at all.
>
>
> I think you misunderstood, we were talking about the ordering of the
> properties in the binding file being alphanumerical, rather than the
> more typical approach of approximately following the order of
> dts-coding-style.
Ah, then I misunderstood and, even though it is a nit, I do care because
old code is then used for new patches. Bindings follow DTS rules, thus
should be:
1. compatible
2. reg
3. core properties
4. vendor properties
Kaustabh, can you change it please?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Conor Dooley @ 2026-05-18 9:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <d2f4cb7d-5c3e-4b9a-86ca-04262cbb9775@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
On Mon, May 18, 2026 at 09:15:11AM +0200, Krzysztof Kozlowski wrote:
> On 17/05/2026 22:52, Conor Dooley wrote:
> > On Sun, May 17, 2026 at 06:39:37PM +0530, Kaustabh Chakraborty wrote:
> >>>>>>> +
> >>>>>> + properties:
> >>>>>> + compatible:
> >>>>>> + const: samsung,s2mu005-rgb
> >>>>>> +
> >>>>>> + required:
> >>>>>> + - compatible
> >>>>>> +
> >>>>>> + unevaluatedProperties: false
> >>>>>> +
> >>>>>> + reg:
> >>>>>> + maxItems: 1
> >>>>>
> >>>>> Move this above the child nodes please.
> >>>>
> >>>> But properties are sorted in lex order?
> >>>
> >>> Typically the binding is sorted in the same order as properties go in
> >>> nodes. Common stuff like reg/clocks/interrupts therefore send up above
> >>> child nodes.
> >>
> >> So, do I change this? For one, I don't see the same being followed in
> >> other schemas of samsung in the same dir (not that I'm trying to pose it
> >> as an argument against your suggestion), and this was reviewed by
> >> Krzysztof and is adderssed in v7.
> >
> > If Krzysztof doesn't care, then I won't ask you to change it.
>
> This builds on top of bindings for previous Samsung PMIC devices, so
> that's why it keeps the compatibles for children, I guess. No one
> complained about this at v1-v2 reviews, so when I joined reviewing in v3
> I did not, either.
>
> I don't think the compatible should be here, but I also don't want to
> stall that patchset. I understand that it is inconsistent review from my
> side, because other similar patchsets receive comment to drop the
> compatible. But I don't think we will be fair asking to drop the
> compatible now, when we did not ask for that in the early versions at all.
I think you misunderstood, we were talking about the ordering of the
properties in the binding file being alphanumerical, rather than the
more typical approach of approximately following the order of
dts-coding-style.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5] dt-bindings: rtc: epson,rx6110: Convert to DT Schema
From: Krzysztof Kozlowski @ 2026-05-18 7:24 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: alexandre.belloni, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260514173851.25088-1-challauday369@gmail.com>
On Thu, May 14, 2026 at 11:03:32PM +0530, Udaya Kiran Challa wrote:
> Convert the Epson RX6110 Real Time Clock devicetree binding
> from the legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Krzysztof Kozlowski @ 2026-05-18 7:15 UTC (permalink / raw)
To: Conor Dooley, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260517-corrode-tuesday-a598ca734b38@spud>
On 17/05/2026 22:52, Conor Dooley wrote:
> On Sun, May 17, 2026 at 06:39:37PM +0530, Kaustabh Chakraborty wrote:
>>>>>>> +
>>>>>> + properties:
>>>>>> + compatible:
>>>>>> + const: samsung,s2mu005-rgb
>>>>>> +
>>>>>> + required:
>>>>>> + - compatible
>>>>>> +
>>>>>> + unevaluatedProperties: false
>>>>>> +
>>>>>> + reg:
>>>>>> + maxItems: 1
>>>>>
>>>>> Move this above the child nodes please.
>>>>
>>>> But properties are sorted in lex order?
>>>
>>> Typically the binding is sorted in the same order as properties go in
>>> nodes. Common stuff like reg/clocks/interrupts therefore send up above
>>> child nodes.
>>
>> So, do I change this? For one, I don't see the same being followed in
>> other schemas of samsung in the same dir (not that I'm trying to pose it
>> as an argument against your suggestion), and this was reviewed by
>> Krzysztof and is adderssed in v7.
>
> If Krzysztof doesn't care, then I won't ask you to change it.
This builds on top of bindings for previous Samsung PMIC devices, so
that's why it keeps the compatibles for children, I guess. No one
complained about this at v1-v2 reviews, so when I joined reviewing in v3
I did not, either.
I don't think the compatible should be here, but I also don't want to
stall that patchset. I understand that it is inconsistent review from my
side, because other similar patchsets receive comment to drop the
compatible. But I don't think we will be fair asking to drop the
compatible now, when we did not ask for that in the early versions at all.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Conor Dooley @ 2026-05-17 20:52 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <DIKZ5L2HC2CV.YL3MZUJQ2EV6@disroot.org>
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]
On Sun, May 17, 2026 at 06:39:37PM +0530, Kaustabh Chakraborty wrote:
>> >> >> +
> >> >> + properties:
> >> >> + compatible:
> >> >> + const: samsung,s2mu005-rgb
> >> >> +
> >> >> + required:
> >> >> + - compatible
> >> >> +
> >> >> + unevaluatedProperties: false
> >> >> +
> >> >> + reg:
> >> >> + maxItems: 1
> >> >
> >> > Move this above the child nodes please.
> >>
> >> But properties are sorted in lex order?
> >
> > Typically the binding is sorted in the same order as properties go in
> > nodes. Common stuff like reg/clocks/interrupts therefore send up above
> > child nodes.
>
> So, do I change this? For one, I don't see the same being followed in
> other schemas of samsung in the same dir (not that I'm trying to pose it
> as an argument against your suggestion), and this was reviewed by
> Krzysztof and is adderssed in v7.
If Krzysztof doesn't care, then I won't ask you to change it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Kaustabh Chakraborty @ 2026-05-17 13:09 UTC (permalink / raw)
To: Conor Dooley, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260516-esquire-chitchat-0fffa597e2f3@spud>
On 2026-05-16 23:25 +01:00, Conor Dooley wrote:
> On Sat, May 16, 2026 at 02:41:29AM +0530, Kaustabh Chakraborty wrote:
>> On 2026-05-15 18:14 +01:00, Conor Dooley wrote:
>> > On Fri, May 15, 2026 at 04:08:59PM +0530, Kaustabh Chakraborty wrote:
>> >> Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
>> >> USB Interface Controller), and flash and RGB LED controllers.
>> >>
>> >> Add the compatible and documentation for the S2MU005 PMIC. Also, add an
>> >> example for nodes for supported sub-devices, i.e. MUIC, flash LEDs, and
>> >> RGB LEDs. Charger sub-device uses the node of the parent.
>> >>
>> >> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> >> ---
>> >> .../bindings/mfd/samsung,s2mu005-pmic.yaml | 120 +++++++++++++++++++++
>> >> 1 file changed, 120 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
>> >> new file mode 100644
>> >> index 0000000000000..0e6afb7d2017b
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
>> >> @@ -0,0 +1,120 @@
>> >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> >> +%YAML 1.2
>> >> +---
>> >> +$id: http://devicetree.org/schemas/mfd/samsung,s2mu005-pmic.yaml#
>> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> >> +
>> >> +title: Samsung S2MU005 Power Management IC
>> >> +
>> >> +maintainers:
>> >> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>> >> +
>> >> +description: |
>> >> + The S2MU005 is a companion power management IC which includes subdevices for
>> >> + a charger controller, an MUIC (Micro USB Interface Controller), and flash and
>> >> + RGB LED controllers.
>> >> +
>> >> +allOf:
>> >> + - $ref: /schemas/power/supply/power-supply.yaml#
>> >> +
>> >> +properties:
>> >> + compatible:
>> >> + const: samsung,s2mu005-pmic
>> >> +
>> >> + flash:
>> >> + $ref: /schemas/leds/samsung,s2mu005-flash.yaml
>> >> + description:
>> >> + Child node describing flash LEDs.
>> >> +
>> >> + interrupts:
>> >> + maxItems: 1
>> >> +
>> >> + muic:
>> >> + $ref: /schemas/extcon/samsung,s2mu005-muic.yaml#
>> >> + description:
>> >> + Child node describing MUIC device.
>> >> +
>> >> + multi-led:
>> >> + type: object
>> >> +
>> >> + allOf:
>> >> + - $ref: /schemas/leds/leds-class-multicolor.yaml#
>> >
>> > Does this need to be an allOf when the other refs are not?
>>
>> It has it's own properties, that's the reason. This used to be it's own
>> thing in dt-bindings/leds, but I was asked to move it here in prior
>> reviews.
>
> What do you mean by "its own properties"?
I mean, the other schemas (muic, flash) are in their own file, with
compatible, and other properties too.
This one, inherits properties from leds-class-multicolor, AND has a
"compatible" property with it, which is not defined in
leds-class-multicolor. Now if you ask why does the compatible exist,
that's something Krzysztof suggested in previous revisions.
And, Krzysztof had also reviewed this patch, and (similar to the prev
patch) I've missed the trailers, which have been addressed in v7 now.
>>
>> >> +
>> >> + properties:
>> >> + compatible:
>> >> + const: samsung,s2mu005-rgb
>> >> +
>> >> + required:
>> >> + - compatible
>> >> +
>> >> + unevaluatedProperties: false
>> >> +
>> >> + reg:
>> >> + maxItems: 1
>> >
>> > Move this above the child nodes please.
>>
>> But properties are sorted in lex order?
>
> Typically the binding is sorted in the same order as properties go in
> nodes. Common stuff like reg/clocks/interrupts therefore send up above
> child nodes.
So, do I change this? For one, I don't see the same being followed in
other schemas of samsung in the same dir (not that I'm trying to pose it
as an argument against your suggestion), and this was reviewed by
Krzysztof and is adderssed in v7.
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Conor Dooley @ 2026-05-16 22:25 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran,
Łukasz Lebiedziński, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <DIJK5FTQ5KWG.HOKZAOXHTGU7@disroot.org>
[-- Attachment #1: Type: text/plain, Size: 3180 bytes --]
On Sat, May 16, 2026 at 02:41:29AM +0530, Kaustabh Chakraborty wrote:
> On 2026-05-15 18:14 +01:00, Conor Dooley wrote:
> > On Fri, May 15, 2026 at 04:08:59PM +0530, Kaustabh Chakraborty wrote:
> >> Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
> >> USB Interface Controller), and flash and RGB LED controllers.
> >>
> >> Add the compatible and documentation for the S2MU005 PMIC. Also, add an
> >> example for nodes for supported sub-devices, i.e. MUIC, flash LEDs, and
> >> RGB LEDs. Charger sub-device uses the node of the parent.
> >>
> >> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> >> ---
> >> .../bindings/mfd/samsung,s2mu005-pmic.yaml | 120 +++++++++++++++++++++
> >> 1 file changed, 120 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
> >> new file mode 100644
> >> index 0000000000000..0e6afb7d2017b
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
> >> @@ -0,0 +1,120 @@
> >> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/mfd/samsung,s2mu005-pmic.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Samsung S2MU005 Power Management IC
> >> +
> >> +maintainers:
> >> + - Kaustabh Chakraborty <kauschluss@disroot.org>
> >> +
> >> +description: |
> >> + The S2MU005 is a companion power management IC which includes subdevices for
> >> + a charger controller, an MUIC (Micro USB Interface Controller), and flash and
> >> + RGB LED controllers.
> >> +
> >> +allOf:
> >> + - $ref: /schemas/power/supply/power-supply.yaml#
> >> +
> >> +properties:
> >> + compatible:
> >> + const: samsung,s2mu005-pmic
> >> +
> >> + flash:
> >> + $ref: /schemas/leds/samsung,s2mu005-flash.yaml
> >> + description:
> >> + Child node describing flash LEDs.
> >> +
> >> + interrupts:
> >> + maxItems: 1
> >> +
> >> + muic:
> >> + $ref: /schemas/extcon/samsung,s2mu005-muic.yaml#
> >> + description:
> >> + Child node describing MUIC device.
> >> +
> >> + multi-led:
> >> + type: object
> >> +
> >> + allOf:
> >> + - $ref: /schemas/leds/leds-class-multicolor.yaml#
> >
> > Does this need to be an allOf when the other refs are not?
>
> It has it's own properties, that's the reason. This used to be it's own
> thing in dt-bindings/leds, but I was asked to move it here in prior
> reviews.
What do you mean by "its own properties"?
>
> >> +
> >> + properties:
> >> + compatible:
> >> + const: samsung,s2mu005-rgb
> >> +
> >> + required:
> >> + - compatible
> >> +
> >> + unevaluatedProperties: false
> >> +
> >> + reg:
> >> + maxItems: 1
> >
> > Move this above the child nodes please.
>
> But properties are sorted in lex order?
Typically the binding is sorted in the same order as properties go in
nodes. Common stuff like reg/clocks/interrupts therefore send up above
child nodes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox