* [PATCH 07/11] rtc: rv8803: stop setting max_user_freq
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
In-Reply-To: <20251101-max_user_freq-v1-0-c9a274fd6883@bootlin.com>
max_user_freq has not been related to the hardware RTC since commit
6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop
setting it from individual driver to avoid confusing new contributors.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-rv8803.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-rv8803.c b/drivers/rtc/rtc-rv8803.c
index 1327251e527c..4e9e04cbec89 100644
--- a/drivers/rtc/rtc-rv8803.c
+++ b/drivers/rtc/rtc-rv8803.c
@@ -738,8 +738,6 @@ static int rv8803_probe(struct i2c_client *client)
devm_rtc_nvmem_register(rv8803->rtc, &nvmem_cfg);
- rv8803->rtc->max_user_freq = 1;
-
return 0;
}
--
2.51.1
^ permalink raw reply related
* [PATCH 06/11] rtc: rv3032: stop setting max_user_freq
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
In-Reply-To: <20251101-max_user_freq-v1-0-c9a274fd6883@bootlin.com>
max_user_freq has not been related to the hardware RTC since commit
6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop
setting it from individual driver to avoid confusing new contributors.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-rv3032.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-rv3032.c b/drivers/rtc/rtc-rv3032.c
index b8376bd1d905..6c09da7738e1 100644
--- a/drivers/rtc/rtc-rv3032.c
+++ b/drivers/rtc/rtc-rv3032.c
@@ -968,8 +968,6 @@ static int rv3032_probe(struct i2c_client *client)
eeprom_cfg.priv = rv3032;
devm_rtc_nvmem_register(rv3032->rtc, &eeprom_cfg);
- rv3032->rtc->max_user_freq = 1;
-
#ifdef CONFIG_COMMON_CLK
rv3032_clkout_register_clk(rv3032, client);
#endif
--
2.51.1
^ permalink raw reply related
* [PATCH 05/11] rtc: rv3028: stop setting max_user_freq
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
In-Reply-To: <20251101-max_user_freq-v1-0-c9a274fd6883@bootlin.com>
max_user_freq has not been related to the hardware RTC since commit
6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop
setting it from individual driver to avoid confusing new contributors.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-rv3028.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-rv3028.c b/drivers/rtc/rtc-rv3028.c
index c2a531f0e125..d96f6bb68850 100644
--- a/drivers/rtc/rtc-rv3028.c
+++ b/drivers/rtc/rtc-rv3028.c
@@ -1023,8 +1023,6 @@ static int rv3028_probe(struct i2c_client *client)
eeprom_cfg.priv = rv3028;
devm_rtc_nvmem_register(rv3028->rtc, &eeprom_cfg);
- rv3028->rtc->max_user_freq = 1;
-
#ifdef CONFIG_COMMON_CLK
rv3028_clkout_register_clk(rv3028, client);
#endif
--
2.51.1
^ permalink raw reply related
* [PATCH 04/11] rtc: renesas-rtca3: stop setting max_user_freq
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
In-Reply-To: <20251101-max_user_freq-v1-0-c9a274fd6883@bootlin.com>
max_user_freq has not been related to the hardware RTC since commit
6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop
setting it from individual driver to avoid confusing new contributors.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-renesas-rtca3.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/rtc/rtc-renesas-rtca3.c b/drivers/rtc/rtc-renesas-rtca3.c
index ab816bdf0d77..a238ead6cf1a 100644
--- a/drivers/rtc/rtc-renesas-rtca3.c
+++ b/drivers/rtc/rtc-renesas-rtca3.c
@@ -772,7 +772,6 @@ static int rtca3_probe(struct platform_device *pdev)
return PTR_ERR(priv->rtc_dev);
priv->rtc_dev->ops = &rtca3_ops;
- priv->rtc_dev->max_user_freq = 256;
priv->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_2000;
priv->rtc_dev->range_max = RTC_TIMESTAMP_END_2099;
--
2.51.1
^ permalink raw reply related
* [PATCH 03/11] rtc: pic32: stop setting max_user_freq
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
In-Reply-To: <20251101-max_user_freq-v1-0-c9a274fd6883@bootlin.com>
max_user_freq has not been related to the hardware RTC since commit
6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop
setting it from individual driver to avoid confusing new contributors.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-pic32.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-pic32.c b/drivers/rtc/rtc-pic32.c
index 2812da2c50c5..52c11532bc3a 100644
--- a/drivers/rtc/rtc-pic32.c
+++ b/drivers/rtc/rtc-pic32.c
@@ -340,8 +340,6 @@ static int pic32_rtc_probe(struct platform_device *pdev)
if (ret)
goto err_nortc;
- pdata->rtc->max_user_freq = 128;
-
pic32_rtc_setfreq(&pdev->dev, 1);
ret = devm_request_irq(&pdev->dev, pdata->alarm_irq,
pic32_rtc_alarmirq, 0,
--
2.51.1
^ permalink raw reply related
* [PATCH 02/11] rtc: ds1685: stop setting max_user_freq
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
In-Reply-To: <20251101-max_user_freq-v1-0-c9a274fd6883@bootlin.com>
max_user_freq has not been related to the hardware RTC since commit
6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop
setting it from individual driver to avoid confusing new contributors.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-ds1685.c | 3 ---
include/linux/rtc/ds1685.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/drivers/rtc/rtc-ds1685.c b/drivers/rtc/rtc-ds1685.c
index 97423f1d0361..5fc8e36b1abf 100644
--- a/drivers/rtc/rtc-ds1685.c
+++ b/drivers/rtc/rtc-ds1685.c
@@ -1268,9 +1268,6 @@ ds1685_rtc_probe(struct platform_device *pdev)
rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_2000;
rtc_dev->range_max = RTC_TIMESTAMP_END_2099;
- /* Maximum periodic rate is 8192Hz (0.122070ms). */
- rtc_dev->max_user_freq = RTC_MAX_USER_FREQ;
-
/* See if the platform doesn't support UIE. */
if (pdata->uie_unsupported)
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc_dev->features);
diff --git a/include/linux/rtc/ds1685.h b/include/linux/rtc/ds1685.h
index 01da4582db6d..8ec0ebfaef04 100644
--- a/include/linux/rtc/ds1685.h
+++ b/include/linux/rtc/ds1685.h
@@ -324,7 +324,6 @@ struct ds1685_rtc_platform_data {
#define RTC_SQW_2HZ 0x0f /* 0 1 1 1 1 */
#define RTC_SQW_0HZ 0x00 /* 0 0 0 0 0 */
#define RTC_SQW_32768HZ 32768 /* 1 - - - - */
-#define RTC_MAX_USER_FREQ 8192
/*
--
2.51.1
^ permalink raw reply related
* [PATCH 01/11] rtc: sa1100: stop setting max_user_freq
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
In-Reply-To: <20251101-max_user_freq-v1-0-c9a274fd6883@bootlin.com>
max_user_freq has not been related to the hardware RTC since commit
6610e0893b8b ("RTC: Rework RTC code to use timerqueue for events"). Stop
setting it from individual driver to avoid confusing new contributors.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-sa1100.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
index 1ad93648d69c..26b2f4184ecc 100644
--- a/drivers/rtc/rtc-sa1100.c
+++ b/drivers/rtc/rtc-sa1100.c
@@ -40,8 +40,6 @@
#define RTC_DEF_DIVIDER (32768 - 1)
#define RTC_DEF_TRIM 0
-#define RTC_FREQ 1024
-
static irqreturn_t sa1100_rtc_interrupt(int irq, void *dev_id)
{
@@ -202,7 +200,6 @@ int sa1100_rtc_init(struct platform_device *pdev, struct sa1100_rtc *info)
}
info->rtc->ops = &sa1100_rtc_ops;
- info->rtc->max_user_freq = RTC_FREQ;
info->rtc->range_max = U32_MAX;
ret = devm_rtc_register_device(info->rtc);
--
2.51.1
^ permalink raw reply related
* [PATCH 00/11] Stop setting max_user_freq in rtc drivers
From: Alexandre Belloni @ 2025-11-01 0:45 UTC (permalink / raw)
To: Joshua Kinard, Claudiu Beznea, Ovidiu Panait
Cc: linux-rtc, linux-kernel, linux-renesas-soc, Alexandre Belloni
max_user_freq has not been related to the hardware RTC since 6610e0893b8b
("RTC: Rework RTC code to use timerqueue for events"). It is not limited by
the hardware capabilities and so it is not necessary to set it from the RTC
drivers as a user with sufficient rights will be able to change the value.
Also, max_user_freq is always clamped to 5000, there is not point in
setting an higher value.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
Alexandre Belloni (11):
rtc: sa1100: stop setting max_user_freq
rtc: ds1685: stop setting max_user_freq
rtc: pic32: stop setting max_user_freq
rtc: renesas-rtca3: stop setting max_user_freq
rtc: rv3028: stop setting max_user_freq
rtc: rv3032: stop setting max_user_freq
rtc: rv8803: stop setting max_user_freq
rtc: rx6110: stop setting max_user_freq
rtc: rx8010: stop setting max_user_freq
rtc: rx8025: stop setting max_user_freq
rtc: sh: stop setting max_user_freq
drivers/rtc/rtc-ds1685.c | 3 ---
drivers/rtc/rtc-pic32.c | 2 --
drivers/rtc/rtc-renesas-rtca3.c | 1 -
drivers/rtc/rtc-rv3028.c | 2 --
drivers/rtc/rtc-rv3032.c | 2 --
drivers/rtc/rtc-rv8803.c | 2 --
drivers/rtc/rtc-rx6110.c | 2 --
drivers/rtc/rtc-rx8010.c | 1 -
drivers/rtc/rtc-rx8025.c | 2 --
drivers/rtc/rtc-sa1100.c | 3 ---
drivers/rtc/rtc-sh.c | 1 -
include/linux/rtc/ds1685.h | 1 -
12 files changed, 22 deletions(-)
---
base-commit: 384150d7a5b60c1086790a8ee07b0629f906cca2
change-id: 20251031-max_user_freq-53e362de297e
Best regards,
--
Alexandre Belloni <alexandre.belloni@bootlin.com>
^ permalink raw reply
* Re: [PATCH v2] rtc: amlogic-a4: fix double free caused by devm
From: Alexandre Belloni @ 2025-10-31 23:02 UTC (permalink / raw)
To: yiting.deng, xianwei.zhao, Haotian Zhang
Cc: linux-amlogic, linux-rtc, linux-kernel
In-Reply-To: <20251021103559.1903-1-vulab@iscas.ac.cn>
On Tue, 21 Oct 2025 18:35:59 +0800, Haotian Zhang wrote:
> The clock obtained via devm_clk_get_enabled() is automatically managed
> by devres and will be disabled and freed on driver detach. Manually
> calling clk_disable_unprepare() in error path and remove function
> causes double free.
>
> Remove the redundant clk_disable_unprepare() calls from the probe
> error path and aml_rtc_remove(), allowing the devm framework to
> automatically manage the clock lifecycle.
>
> [...]
Applied, thanks!
[1/1] rtc: amlogic-a4: fix double free caused by devm
https://git.kernel.org/abelloni/c/384150d7a5b6
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] rtc: amlogic-a4: simplify probe
From: alexandre.belloni @ 2025-10-31 20:47 UTC (permalink / raw)
To: Yiting Deng, Xianwei Zhao, Alexandre Belloni
Cc: linux-amlogic, linux-rtc, linux-kernel
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Use devm_device_init_wakeup to simplify probe and remove .remove as it is now
empty.
Also remove the unnecessary error string as there are no error path without an
error message in devm_rtc_register_device.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-amlogic-a4.c | 28 +++++-----------------------
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/rtc/rtc-amlogic-a4.c b/drivers/rtc/rtc-amlogic-a4.c
index a993d35e1d6b..123fb372fc9f 100644
--- a/drivers/rtc/rtc-amlogic-a4.c
+++ b/drivers/rtc/rtc-amlogic-a4.c
@@ -361,38 +361,26 @@ static int aml_rtc_probe(struct platform_device *pdev)
"failed to get_enable rtc sys clk\n");
aml_rtc_init(rtc);
- device_init_wakeup(dev, true);
+ devm_device_init_wakeup(dev);
platform_set_drvdata(pdev, rtc);
rtc->rtc_dev = devm_rtc_allocate_device(dev);
- if (IS_ERR(rtc->rtc_dev)) {
- ret = PTR_ERR(rtc->rtc_dev);
- goto err_clk;
- }
+ if (IS_ERR(rtc->rtc_dev))
+ return PTR_ERR(rtc->rtc_dev);
ret = devm_request_irq(dev, rtc->irq, aml_rtc_handler,
IRQF_ONESHOT, "aml-rtc alarm", rtc);
if (ret) {
dev_err_probe(dev, ret, "IRQ%d request failed, ret = %d\n",
rtc->irq, ret);
- goto err_clk;
+ return ret;
}
rtc->rtc_dev->ops = &aml_rtc_ops;
rtc->rtc_dev->range_min = 0;
rtc->rtc_dev->range_max = U32_MAX;
- ret = devm_rtc_register_device(rtc->rtc_dev);
- if (ret) {
- dev_err_probe(&pdev->dev, ret, "Failed to register RTC device: %d\n", ret);
- goto err_clk;
- }
-
- return 0;
-err_clk:
- device_init_wakeup(dev, false);
-
- return ret;
+ return devm_rtc_register_device(rtc->rtc_dev);
}
#ifdef CONFIG_PM_SLEEP
@@ -420,11 +408,6 @@ static int aml_rtc_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(aml_rtc_pm_ops,
aml_rtc_suspend, aml_rtc_resume);
-static void aml_rtc_remove(struct platform_device *pdev)
-{
- device_init_wakeup(&pdev->dev, false);
-}
-
static const struct aml_rtc_config a5_rtc_config = {
};
@@ -447,7 +430,6 @@ MODULE_DEVICE_TABLE(of, aml_rtc_device_id);
static struct platform_driver aml_rtc_driver = {
.probe = aml_rtc_probe,
- .remove = aml_rtc_remove,
.driver = {
.name = "aml-rtc",
.pm = &aml_rtc_pm_ops,
--
2.51.1
^ permalink raw reply related
* Re: [PATCH v2 3/6] rtc: renesas-rtca3: Use OF data for configuration
From: Alexandre Belloni @ 2025-10-31 14:08 UTC (permalink / raw)
To: Ovidiu Panait
Cc: claudiu.beznea.uj, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, mturquette, sboyd, p.zabel, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, linux-clk
In-Reply-To: <20251021080705.18116-4-ovidiu.panait.rb@renesas.com>
Hello,
Since the RTC will never be used for PIE (we are using hrtimer), I guess
this patch is not necessary, instead, you could simply stop setting
max_user_freq.
On 21/10/2025 08:07:02+0000, Ovidiu Panait wrote:
> Prepare for adding support for the Renesas RZ/V2H SoC RTC IP by making the
> driver configuration selectable via OF match data.
>
> For RZ/V2H RTC, the maximum periodic interrupt frequency is 128Hz instead
> of 256Hz, so add this info to a SoC-specific struct and retrieve it
> during probe.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> ---
> v2 changes: none
>
> drivers/rtc/rtc-renesas-rtca3.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-renesas-rtca3.c b/drivers/rtc/rtc-renesas-rtca3.c
> index ab816bdf0d77..90dda04fad33 100644
> --- a/drivers/rtc/rtc-renesas-rtca3.c
> +++ b/drivers/rtc/rtc-renesas-rtca3.c
> @@ -101,6 +101,15 @@ enum rtca3_alrm_set_step {
> RTCA3_ALRM_SSTEP_INIT = 3,
> };
>
> +/**
> + * struct rtca3_of_data - OF data for RTCA3
> + *
> + * @max_periodic_irq_freq: maximum periodic interrupt frequency
> + */
> +struct rtca3_of_data {
> + int max_periodic_irq_freq;
> +};
> +
> /**
> * struct rtca3_ppb_per_cycle - PPB per cycle
> * @ten_sec: PPB per cycle in 10 seconds adjutment mode
> @@ -709,6 +718,7 @@ static void rtca3_action(void *data)
>
> static int rtca3_probe(struct platform_device *pdev)
> {
> + const struct rtca3_of_data *of_data;
> struct device *dev = &pdev->dev;
> struct rtca3_priv *priv;
> struct clk *clk;
> @@ -718,6 +728,8 @@ static int rtca3_probe(struct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> + of_data = of_device_get_match_data(dev);
> +
> priv->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
> @@ -772,7 +784,7 @@ static int rtca3_probe(struct platform_device *pdev)
> return PTR_ERR(priv->rtc_dev);
>
> priv->rtc_dev->ops = &rtca3_ops;
> - priv->rtc_dev->max_user_freq = 256;
> + priv->rtc_dev->max_user_freq = of_data->max_periodic_irq_freq;
> priv->rtc_dev->range_min = RTC_TIMESTAMP_BEGIN_2000;
> priv->rtc_dev->range_max = RTC_TIMESTAMP_END_2099;
>
> @@ -875,8 +887,12 @@ static int rtca3_resume(struct device *dev)
>
> static DEFINE_SIMPLE_DEV_PM_OPS(rtca3_pm_ops, rtca3_suspend, rtca3_resume);
>
> +static const struct rtca3_of_data rtca3_of_data = {
> + .max_periodic_irq_freq = 256,
> +};
> +
> static const struct of_device_id rtca3_of_match[] = {
> - { .compatible = "renesas,rz-rtca3", },
> + { .compatible = "renesas,rz-rtca3", .data = &rtca3_of_data },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, rtca3_of_match);
> --
> 2.51.0
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/2] Revert "rtc: tps6586x: Fix initial enable_irq/disable_irq balance"
From: Alexandre Belloni @ 2025-10-31 13:20 UTC (permalink / raw)
To: Esben Haabendal, Jon Hunter; +Cc: linux-rtc, linux-kernel, linux-tegra
In-Reply-To: <20251031103741.945460-1-jonathanh@nvidia.com>
On Fri, 31 Oct 2025 10:37:40 +0000, Jon Hunter wrote:
> Commit 1502fe0e97be ("rtc: tps6586x: Fix initial enable_irq/disable_irq
> balance") breaks the wake-up alarm for the tps6586x. After this commit
> was added RTC wake ups from suspend stopped working on the Tegra20
> Ventana platform.
>
> The problem is that this change set the 'irq_en' variable to true prior
> to calling devm_request_threaded_irq() to indicate that the IRQ is
> enabled, however, it was over looked that the flag IRQ_NOAUTOEN is
> already set meaning that the IRQ is not enabled by default. This
> prevents the IRQ from being enabled as expected. Revert this change to
> fix this.
>
> [...]
Applied, thanks!
[1/2] Revert "rtc: tps6586x: Fix initial enable_irq/disable_irq balance"
https://git.kernel.org/abelloni/c/b1c9390f0a44
[2/2] Revert "rtc: cpcap: Fix initial enable_irq/disable_irq balance"
https://git.kernel.org/abelloni/c/0d510778c2f4
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 1/2] Revert "rtc: tps6586x: Fix initial enable_irq/disable_irq balance"
From: Jon Hunter @ 2025-10-31 10:37 UTC (permalink / raw)
To: Alexandre Belloni, Esben Haabendal
Cc: linux-rtc, linux-kernel, linux-tegra, Jon Hunter
Commit 1502fe0e97be ("rtc: tps6586x: Fix initial enable_irq/disable_irq
balance") breaks the wake-up alarm for the tps6586x. After this commit
was added RTC wake ups from suspend stopped working on the Tegra20
Ventana platform.
The problem is that this change set the 'irq_en' variable to true prior
to calling devm_request_threaded_irq() to indicate that the IRQ is
enabled, however, it was over looked that the flag IRQ_NOAUTOEN is
already set meaning that the IRQ is not enabled by default. This
prevents the IRQ from being enabled as expected. Revert this change to
fix this.
Fixes: 1502fe0e97be ("rtc: tps6586x: Fix initial enable_irq/disable_irq balance")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
drivers/rtc/rtc-tps6586x.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/rtc/rtc-tps6586x.c b/drivers/rtc/rtc-tps6586x.c
index 76ecf7b798f0..54c8429b16bf 100644
--- a/drivers/rtc/rtc-tps6586x.c
+++ b/drivers/rtc/rtc-tps6586x.c
@@ -258,7 +258,6 @@ static int tps6586x_rtc_probe(struct platform_device *pdev)
irq_set_status_flags(rtc->irq, IRQ_NOAUTOEN);
- rtc->irq_en = true;
ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
tps6586x_rtc_irq,
IRQF_ONESHOT,
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] Revert "rtc: cpcap: Fix initial enable_irq/disable_irq balance"
From: Jon Hunter @ 2025-10-31 10:37 UTC (permalink / raw)
To: Alexandre Belloni, Esben Haabendal
Cc: linux-rtc, linux-kernel, linux-tegra, Jon Hunter
In-Reply-To: <20251031103741.945460-1-jonathanh@nvidia.com>
Commit e0762fd26ad6 ("rtc: cpcap: Fix initial enable_irq/disable_irq
balance") set 'alarm_enabled' prior to calling the function
devm_request_threaded_irq() because this enables the IRQ. However, right
after calling devm_request_threaded_irq(), the driver calls
disable_irq() to disable the IRQ and so now 'alarm_enabled' will be true
but the IRQ is actually disabled. Revert this commit to fix the
'alarm_enabled' state.
Fixes: e0762fd26ad6 ("rtc: cpcap: Fix initial enable_irq/disable_irq balance")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
I don't have a board with this device, but from reviewing the code this
does look correct.
drivers/rtc/rtc-cpcap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
index 8b6b35716f53..c170345ac076 100644
--- a/drivers/rtc/rtc-cpcap.c
+++ b/drivers/rtc/rtc-cpcap.c
@@ -268,7 +268,6 @@ static int cpcap_rtc_probe(struct platform_device *pdev)
return err;
rtc->alarm_irq = platform_get_irq(pdev, 0);
- rtc->alarm_enabled = true;
err = devm_request_threaded_irq(dev, rtc->alarm_irq, NULL,
cpcap_rtc_alarm_irq,
IRQF_TRIGGER_NONE | IRQF_ONESHOT,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v1 2/2] rtc: Add support for MT6685 Clock IC's RTC over SPMI
From: Alexandre Belloni @ 2025-10-30 17:27 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: robh, krzk+dt, conor+dt, matthias.bgg, linux-rtc, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, kernel
In-Reply-To: <20251024083318.25890-3-angelogioacchino.delregno@collabora.com>
On 24/10/2025 10:33:18+0200, AngeloGioacchino Del Regno wrote:
> +static irqreturn_t rtc_mt6685_irq_handler_thread(int irq, void *data)
> +{
> + u16 irqsta, irqen = 0, bbpu = RTC_BBPU_WR_UNLOCK_KEY | RTC_BBPU_PWREN;
> + struct mt6685_rtc *rtc = data;
> + struct device *dev = &rtc->rdev->dev;
> + int ret;
> +
> + ret = clk_prepare_enable(rtc->mclk);
> + if (ret)
> + return IRQ_NONE;
> +
> + ret = regmap_bulk_read(rtc->regmap, RTC_REG_IRQ_STA, &irqsta, sizeof(irqsta));
> + if (ret)
> + goto end;
> +
> + /* Only alarm interrupts are supported for now */
> + if (!(irqsta & RTC_IRQ_AL)) {
> + ret = -EINVAL;
> + goto end;
> + }
> +
> + rtc_lock(rtc->rdev);
> +
> + /* Enable BBPU power and clear the interrupt */
> + ret = regmap_bulk_write(rtc->regmap, RTC_REG_BBPU, &bbpu, sizeof(bbpu));
> + if (ret)
> + goto end;
> +
> + ret = regmap_bulk_write(rtc->regmap, RTC_REG_IRQ_EN, &irqen, sizeof(irqen));
> + if (ret)
> + goto end;
> +
> + /* Trigger reset of the RTC BBPU Alarm */
> + bbpu |= RTC_BBPU_RESET_AL;
> + ret = regmap_bulk_write(rtc->regmap, RTC_REG_BBPU, &bbpu, sizeof(bbpu));
> + if (ret) {
> + dev_err(dev, "Cannot reset alarm: %d\n", ret);
> + goto end;
> + }
> +
> + /* Trigger write synchronization */
> + ret = rtc_mt6685_write_trigger(rtc);
> + if (ret) {
> + dev_err(dev, "Cannot synchronize write to RTC: %d\n", ret);
I'm not sure those two dev_err are necessary.
> + goto end;
> + }
> + rtc_update_irq(rtc->rdev, 1, RTC_IRQF | RTC_AF);
> +end:
> + rtc_unlock(rtc->rdev);
> + clk_disable_unprepare(rtc->mclk);
> + return ret ? IRQ_NONE : IRQ_HANDLED;
> +}
> +
> +static int rtc_mt6685_read_time_regs(struct mt6685_rtc *rtc, struct rtc_time *tm, u16 reg)
> +{
> + u16 data[RTC_AL_TC_REGIDX_MAX];
> + int ret;
> +
> + ret = regmap_bulk_read(rtc->regmap, reg, &data,
> + RTC_AL_TC_REGIDX_MAX * sizeof(data[0]));
> + if (ret) {
> + dev_err(&rtc->rdev->dev, "Cannot read time regs\n");
Same here, there is not much the user can do and your are already
returning an error.
> + return ret;
> + }
> +
> + tm->tm_sec = FIELD_GET(RTC_AL_TC_SEC_MIN, data[RTC_AL_TC_REGIDX_SEC]);
> + tm->tm_min = FIELD_GET(RTC_AL_TC_SEC_MIN, data[RTC_AL_TC_REGIDX_MIN]);
> + tm->tm_hour = FIELD_GET(RTC_AL_TC_HOUR_DOM, data[RTC_AL_TC_REGIDX_HOUR]);
> + tm->tm_mday = FIELD_GET(RTC_AL_TC_HOUR_DOM, data[RTC_AL_TC_REGIDX_DOM]);
> + tm->tm_wday = FIELD_GET(RTC_AL_TC_DOW, data[RTC_AL_TC_REGIDX_DOW]);
> + tm->tm_mon = FIELD_GET(RTC_AL_TC_MON, data[RTC_AL_TC_REGIDX_MON]);
> + tm->tm_year = FIELD_GET(RTC_AL_TC_YEAR, data[RTC_AL_TC_REGIDX_YEAR]);
> +
> + /* HW register start mon/wday from one, but tm_mon/tm_wday start from zero. */
> + tm->tm_mon--;
> + tm->tm_wday--;
> +
> + return 0;
> +}
> +
> +static int rtc_mt6685_probe(struct platform_device *pdev)
> +{
> + struct regmap_config mt6685_rtc_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 8,
> + .max_register = 0x60,
> + .fast_io = true,
> + .use_single_read = true,
> + .use_single_write = true,
> + };
> + struct device *dev = &pdev->dev;
> + struct spmi_subdevice *sub_sdev;
> + struct spmi_device *sparent;
> + struct mt6685_rtc *rtc;
> + int ret;
> +
> + rtc = devm_kzalloc(dev, sizeof(struct mt6685_rtc), GFP_KERNEL);
> + if (!rtc)
> + return -ENOMEM;
> +
> + sparent = to_spmi_device(dev->parent);
> + sub_sdev = devm_spmi_subdevice_alloc_and_add(dev, sparent);
> + if (IS_ERR(sub_sdev))
> + return PTR_ERR(sub_sdev);
> +
> + ret = of_property_read_u32(pdev->dev.of_node, "reg",
> + &mt6685_rtc_regmap_config.reg_base);
> + if (ret)
> + return ret;
> +
> + rtc->irq = platform_get_irq(pdev, 0);
> + if (rtc->irq < 0)
> + return rtc->irq;
> +
> + rtc->mclk = devm_clk_get(dev, 0);
> + if (IS_ERR(rtc->mclk))
> + return PTR_ERR(rtc->mclk);
> +
> + rtc->regmap = devm_regmap_init_spmi_ext(&sub_sdev->sdev, &mt6685_rtc_regmap_config);
> + if (IS_ERR(rtc->regmap))
> + return PTR_ERR(rtc->regmap);
> +
> + rtc->rdev = devm_rtc_allocate_device(dev);
> + if (IS_ERR(rtc->rdev))
> + return PTR_ERR(rtc->rdev);
> +
> + platform_set_drvdata(pdev, rtc);
> +
> + /* Clock is required to auto-synchronize IRQ enable to RTC */
> + ret = clk_prepare_enable(rtc->mclk);
> + if (ret)
> + return ret;
> +
> + ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> + rtc_mt6685_irq_handler_thread,
> + IRQF_ONESHOT | IRQF_TRIGGER_HIGH,
> + "mt6685-rtc", rtc);
> + clk_disable_unprepare(rtc->mclk);
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret, "Cannot request alarm IRQ");
> +
> + device_init_wakeup(&pdev->dev, true);
devm_device_init_wakeup ?
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 4/5] rtc: tps6586x: Fix initial enable_irq/disable_irq balance
From: Jon Hunter @ 2025-10-30 9:07 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Esben Haabendal, linux-rtc, linux-kernel, linux-arm-kernel,
linux-tegra@vger.kernel.org
In-Reply-To: <2025102910393819d18ad0@mail.local>
On 29/10/2025 10:39, Alexandre Belloni wrote:
> On 29/10/2025 09:20:17+0000, Jon Hunter wrote:
>> Hi Esben,
>>
>> On 16/05/2025 08:23, Esben Haabendal wrote:
>>> Interrupts are automatically enabled when requested, so we need to
>>> initialize irq_en accordingly to avoid causing an unbalanced enable
>>> warning.
>>>
>>> Signed-off-by: Esben Haabendal <esben@geanix.com>
>>> ---
>>> drivers/rtc/rtc-tps6586x.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/rtc/rtc-tps6586x.c b/drivers/rtc/rtc-tps6586x.c
>>> index 54c8429b16bfcc692b1f4d5404f0c42f720e93b4..76ecf7b798f0de22aa89a552a263b473ab3065ef 100644
>>> --- a/drivers/rtc/rtc-tps6586x.c
>>> +++ b/drivers/rtc/rtc-tps6586x.c
>>> @@ -258,6 +258,7 @@ static int tps6586x_rtc_probe(struct platform_device *pdev)
>>> irq_set_status_flags(rtc->irq, IRQ_NOAUTOEN);
>>> + rtc->irq_en = true;
>>> ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
>>> tps6586x_rtc_irq,
>>> IRQF_ONESHOT,
>>>
>>
>> I have bisected a suspend regression on one of our Tegra20 boards (that uses
>> this driver) and bisect is pointing to this commit. Reverting this commit
>> fixes the problem.
>>
>> Looking at the above I see that the flag IRQ_NOAUTOEN is being set and so
>> now with your change we never enable the interrupt. Hence, the wake-ups are
>> now broken and suspend testing fails. So it would seem best to revert this.
>>
>> BTW, I looked at the change to the CPCAP driver and that driver actively
>> disables the IRQ after requesting it and so I am wondering if that will also
>> have alarm issues? I don't have a board with CPCAP to test.
>>
>
> That's right, I guess you can send reverts.
You guessed right! I certainly can. I am happy to send a revert for this
because I can clearly test and verify this. I am not sure if you and
Esben want to review the rest of the series.
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] rtc: max31335: Fix ignored return value in set_alarm
From: Nuno Sá via B4 Relay @ 2025-10-29 17:43 UTC (permalink / raw)
To: linux-rtc; +Cc: Alexandre Belloni, Guenter Roeck, Antoniu Miclaus
From: Nuno Sá <nuno.sa@analog.com>
Return the result from regmap_update_bits() instead of ignoring it
and always returning 0.
Fixes: dedaf03b99d6 ("rtc: max31335: add driver support")
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
---
drivers/rtc/rtc-max31335.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-max31335.c b/drivers/rtc/rtc-max31335.c
index dfb5bad3a369..23b7bf16b4cd 100644
--- a/drivers/rtc/rtc-max31335.c
+++ b/drivers/rtc/rtc-max31335.c
@@ -391,10 +391,8 @@ static int max31335_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
if (ret)
return ret;
- ret = regmap_update_bits(max31335->regmap, max31335->chip->int_status_reg,
- MAX31335_STATUS1_A1F, 0);
-
- return 0;
+ return regmap_update_bits(max31335->regmap, max31335->chip->int_status_reg,
+ MAX31335_STATUS1_A1F, 0);
}
static int max31335_alarm_irq_enable(struct device *dev, unsigned int enabled)
---
base-commit: 9db26d5855d0374d4652487bfb5aacf40821c469
change-id: 20251029-max31335-handler-error-65a286c74289
--
Thanks!
- Nuno Sá
^ permalink raw reply related
* Re: [PATCH v2 02/15] dt-bindings: Add trickle-charge upper limit
From: Krzysztof Kozlowski @ 2025-10-29 13:33 UTC (permalink / raw)
To: Linus Walleij, Matti Vaittinen
Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
linux-gpio, linux-rtc
In-Reply-To: <CACRpkdZcszMZEU2Wzx8kaoR46ytziqtedmCrsjEL3QOrDtDgzg@mail.gmail.com>
On 29/10/2025 14:26, Linus Walleij wrote:
> On Wed, Oct 29, 2025 at 7:22 AM Matti Vaittinen
> <mazziesaccount@gmail.com> wrote:
>
>>> But I believe this is wrong. Trickle charging does not switch to
>>> anything more, there is no fast charging after trickle. You have some
>>> sort of pre-pre-charging, which is just pre-charging.
>>
>> There is trickle, pre and fast-charge phases. Furthermore, the
>> fast-charge is further divided to CC and CV. Finally, if my memory
>> serves me well, Linus W did explain me that some chargers use
>> 'trickle-charging' as a _last_ charging phase for a full battery. Thus
>> the term 'trickle-charging' is slightly confusing - but it is already
>> used by the existing bindings...
>>
>> https://lore.kernel.org/all/20211116001755.2132036-1-linus.walleij@linaro.org/
>
> I think we need to refer to a textbook or IEEE articles to get this
> terminology right.
>
> As you say it appears "trickle-charging" is ambiguous.
>
> Maybe what Krzysztof suggest to use: "pre-pre-charging" or
> "empty-battery-charging" or something like this is needed.
>
> But we really need a trustworthy academic source here.
Trickle charging is accurate for both cases - pre-pre and top-off -
because it just describes very small current. That's why I found it in
many TI datasheets - mostly for Li-Ion batteries describing Matti's
case, but also in at least one case for Ni-Mh describing top-off (or
maintenance).
I am fine with the naming, but I want to be clear that this property
will describe trickle only in case of pre-pre charging. Termination
voltage simply does not fit the top-off/maintenance mode.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 02/15] dt-bindings: Add trickle-charge upper limit
From: Linus Walleij @ 2025-10-29 13:26 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Krzysztof Kozlowski, Matti Vaittinen, Lee Jones, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
linux-gpio, linux-rtc
In-Reply-To: <a81fba66-adf0-440f-96e1-bf3a83d504d8@gmail.com>
On Wed, Oct 29, 2025 at 7:22 AM Matti Vaittinen
<mazziesaccount@gmail.com> wrote:
> > But I believe this is wrong. Trickle charging does not switch to
> > anything more, there is no fast charging after trickle. You have some
> > sort of pre-pre-charging, which is just pre-charging.
>
> There is trickle, pre and fast-charge phases. Furthermore, the
> fast-charge is further divided to CC and CV. Finally, if my memory
> serves me well, Linus W did explain me that some chargers use
> 'trickle-charging' as a _last_ charging phase for a full battery. Thus
> the term 'trickle-charging' is slightly confusing - but it is already
> used by the existing bindings...
>
> https://lore.kernel.org/all/20211116001755.2132036-1-linus.walleij@linaro.org/
I think we need to refer to a textbook or IEEE articles to get this
terminology right.
As you say it appears "trickle-charging" is ambiguous.
Maybe what Krzysztof suggest to use: "pre-pre-charging" or
"empty-battery-charging" or something like this is needed.
But we really need a trustworthy academic source here.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
From: Linus Walleij @ 2025-10-29 13:08 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
linux-gpio, linux-rtc
In-Reply-To: <8b5dbbf6-bbde-4015-b0d1-12d6ec770ceb@gmail.com>
On Wed, Oct 29, 2025 at 1:30 PM Matti Vaittinen
<mazziesaccount@gmail.com> wrote:
> On 28/10/2025 00:42, Linus Walleij wrote:
> > Hi Matti,
> >
> > thanks for your patch!
> >
> > On Mon, Oct 27, 2025 at 12:45 PM Matti Vaittinen
> > <mazziesaccount@gmail.com> wrote:
> >
> >> + rohm,clkout-open-drain:
> >> + description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
> >> + $ref: /schemas/types.yaml#/definitions/uint32
> >> + minimum: 0
> >> + maximum: 1
> >
> > I think CMOS is the same as "push-pull" ( I could be wrong, but I think I've
> > seen that before) so I would probably try to use the pin config standard
> > names as strings here but I'm not sure.
> >
> > rohm,clkout-bias-open-drain;
> > rohm,clkout-bias-push-pull;
> >
> > Mutually exclusive.
> >
> > Or maybe use the pattern from rohm,pin-dvs0
> > with string enumerators?
> >
> > rohm,clkout-bias = "open-drain";
> > rohm,clkout-bias = "push-pull";
> >
>
> Hmm. I kind of agree with you. Still, the way it was done in this patch
> is used by the other existing ROHM PMICs (bd71815, bd71828, bd71879). I
> am kind of reluctant to support another way in the same driver - and I
> am also reluctant to change the existing bindings as that sounds a bit
> like asking for a nose-bleed :) (I've in the past worked with some
> devices which didn't update the device-trees when kernel was updated...)
>
> Do you think you could live with using this existing convention? :)
Yeah if there are precedents, either we can reuse that or we need to
change them all, and that invariably involves deprecation and re-implementing
the parsing in several drivers in that case, which is annoying and
takes time.
It's fine with me to keep like this.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 0/4] Add NVIDIA VRS RTC support
From: Jon Hunter @ 2025-10-29 12:49 UTC (permalink / raw)
To: Shubhi Garg, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Catalin Marinas, Will Deacon, Alexandre Belloni
Cc: devicetree, linux-arm-kernel, linux-rtc, linux-tegra
In-Reply-To: <20251007135738.487694-1-shgarg@nvidia.com>
On 07/10/2025 14:57, Shubhi Garg wrote:
> This patch series adds support for NVIDIA's Voltage Regulator Specification
> (VRS) RTC device. It provides following features:
> - read/set system time
> - 32kHz clock support with backup battery input to retain system time
> across boot
> - alarm functionality to wake system from suspend and shutdown state
>
> The series includes:
> - Device tree bindings for the VRS RTC
> - VRS device tree nodes for NVIDIA platforms
> - VRS RTC device driver
> - Configuration updates to enable the driver
For the series ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
From: Matti Vaittinen @ 2025-10-29 12:30 UTC (permalink / raw)
To: Linus Walleij
Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
linux-gpio, linux-rtc
In-Reply-To: <CACRpkdYEUdJRvNPKhxx7orYHH3OE6BXXjrG9JVJo5MDHGKE88A@mail.gmail.com>
On 28/10/2025 00:42, Linus Walleij wrote:
> Hi Matti,
>
> thanks for your patch!
>
> On Mon, Oct 27, 2025 at 12:45 PM Matti Vaittinen
> <mazziesaccount@gmail.com> wrote:
>
>> + rohm,clkout-open-drain:
>> + description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0
>> + maximum: 1
>
> I think CMOS is the same as "push-pull" ( I could be wrong, but I think I've
> seen that before) so I would probably try to use the pin config standard
> names as strings here but I'm not sure.
>
> rohm,clkout-bias-open-drain;
> rohm,clkout-bias-push-pull;
>
> Mutually exclusive.
>
> Or maybe use the pattern from rohm,pin-dvs0
> with string enumerators?
>
> rohm,clkout-bias = "open-drain";
> rohm,clkout-bias = "push-pull";
>
Hmm. I kind of agree with you. Still, the way it was done in this patch
is used by the other existing ROHM PMICs (bd71815, bd71828, bd71879). I
am kind of reluctant to support another way in the same driver - and I
am also reluctant to change the existing bindings as that sounds a bit
like asking for a nose-bleed :) (I've in the past worked with some
devices which didn't update the device-trees when kernel was updated...)
Do you think you could live with using this existing convention? :)
Yours,
-- Matti
^ permalink raw reply
* Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
From: Matti Vaittinen @ 2025-10-29 12:23 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel,
Liam Girdwood, Mark Brown, Michael Turquette, Stephen Boyd,
Linus Walleij, Bartosz Golaszewski, Alexandre Belloni, linux-leds,
devicetree, linux-kernel, linux-pm, linux-clk, linux-gpio,
linux-rtc
In-Reply-To: <20251027222030.560def67@kemnade.info>
On 27/10/2025 23:20, Andreas Kemnade wrote:
> On Mon, 27 Oct 2025 13:45:46 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>
>> The ROHM BD72720 is a power management IC integrating regulators, GPIOs,
>> charger, LEDs, RTC and a clock gate.
>>
>> Add dt-binding doc for ROHM BD72720.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
> [...]
>> +
>> + rohm,charger-sense-resistor-milli-ohms:
>> + minimum: 10
>> + maximum: 50
>> + description: |
>> + BD72720 has a SAR ADC for measuring charging currents. External sense
>> + resistor (RSENSE in data sheet) should be used. If some other but
>> + 30 mOhm resistor is used the resistance value should be given here in
>> + milli Ohms.
>> +
> rohm,bd71828.yaml has rohm,charger-sense-resistor-micro-ohms, lets
> keep that unified.
Absolutely! Good catch, thanks!
Yours,
-- Matti
^ permalink raw reply
* Re: [PATCH v2 04/15] dt-bindings: mfd: ROHM BD72720
From: Matti Vaittinen @ 2025-10-29 12:22 UTC (permalink / raw)
To: Rob Herring
Cc: Matti Vaittinen, Lee Jones, Pavel Machek, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Linus Walleij,
Bartosz Golaszewski, Andreas Kemnade, Alexandre Belloni,
linux-leds, devicetree, linux-kernel, linux-pm, linux-clk,
linux-gpio, linux-rtc
In-Reply-To: <20251027211351.GC1565353-robh@kernel.org>
On 27/10/2025 23:13, Rob Herring wrote:
> On Mon, Oct 27, 2025 at 01:45:46PM +0200, Matti Vaittinen wrote:
>> The ROHM BD72720 is a power management IC integrating regulators, GPIOs,
>> charger, LEDs, RTC and a clock gate.
>>
>> Add dt-binding doc for ROHM BD72720.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ---
>> Revision history:
>> RFCv1 => v2:
>> - Typofixes
>> ---
>> .../bindings/mfd/rohm,bd72720-pmic.yaml | 269 ++++++++++++++++++
>> 1 file changed, 269 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
>> new file mode 100644
>> index 000000000000..b0d4bc01d199
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
>> @@ -0,0 +1,269 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/mfd/rohm,bd72720-pmic.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: ROHM BD72720 Power Management Integrated Circuit
>> +
>> +maintainers:
>> + - Matti Vaittinen <mazziesaccount@gmail.com>
>> +
>> +description: |
>> + BD72720 is a single-chip power management IC for battery-powered portable
>> + devices. The BD72720 integrates 10 bucks and 11 LDOs, and a 3000 mA
>> + switching charger. The IC also includes a Coulomb counter, a real-time
>> + clock (RTC), GPIOs and a 32.768 kHz clock gate.
>> +
>> +# In addition to the properties found from the charger node, the ROHM BD72720
>> +# uses properties from a static battery node. Please see the:
>> +# Documentation/devicetree/bindings/power/supply/rohm,vdr-battery.yaml
>
> Why is all of this a comment?
Hi Rob,
Thanks for (all the) reviews! Much appreciated.
I added these as comments because they aren't meant to be in the BD72720
charger-node (which is described by this driver), but in a static
battery node. The battery node does not belong in the charger node.
My idea was still to document (for integrator) the battery properties
this charger uses from a static battery node when present. Only thing we
include directly to this node is the:
monitored-battery = <&battery>; - reference.
>
>> +#
>> +# Following properties are used
>> +# when present:
>> +#
>> +# charge-full-design-microamp-hours: Battry capacity in mAh
>> +# voltage-max-design-microvolt: Maximum voltage
>> +# voltage-min-design-microvolt: Minimum voltage system is still operating.
>> +# degrade-cycle-microamp-hours: Capacity lost due to aging at each full
>> +# charge cycle.
>> +# ocv-capacity-celsius: Array of OCV table temperatures. 1/table.
>> +# ocv-capacity-table-<N>: Table of OCV voltage/SOC pairs. Corresponds
>> +# N.th temperature in ocv-capacity-celsius
>> +#
>> +# ROHM specific properties:
>> +# rohm,voltage-vdr-thresh-microvolt: Threshold for starting the VDR correction
>> +# rohm,volt-drop-soc: Table of capacity values matching the
>> +# values in VDR tables.
>> +# rohm,volt-drop-high-temp-microvolt: VDR table for high temperature
>> +# rohm,volt-drop-normal-temp-microvolt: VDR table for normal temperature
>> +# rohm,volt-drop-low-temp-microvolt: VDR table for low temperature
>> +# rohm,volt-drop-very-low-temp-microvolt: VDR table for very low temperature
>> +#
>> +# VDR tables are (usually) determined for a specific battery by ROHM.
>> +# The battery node would then be referred from the charger node:
>> +#
>> +# monitored-battery = <&battery>;
>> +
>> +properties:
>> + compatible:
>> + const: rohm,bd72720
>> +
>> + reg:
>> + description:
>> + I2C slave address.
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + gpio-controller: true
>> +
>> + "#gpio-cells":
>> + const: 2
>> + description: |
// snip
>> +
>> + rohm,pin-dvs0:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description:
>> + BD72720 has 4 different OTP options to determine the use of dvs0-pin.
>> + OTP0 - regulator RUN state control.
>> + OTP1 - GPI.
>> + OTP2 - GPO.
>> + OTP3 - Power sequencer output.
>> + This property specifies the use of the pin.
>> + enum:
>> + - dvs-input
>> + - gpi
>> + - gpo
>> +
>> + rohm,pin-dvs1:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description:
>> + see rohm,pin-dvs0
>> + enum:
>> + - dvs-input
>> + - gpi
>> + - gpo
>
> These 2 could be combined into a single entry in patternProperties.
>
>> +
>> + rohm,pin-exten0:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description: BD72720 has an OTP option to use exten0-pin for different
>> + purposes. Set this property accordingly.
>> + const: gpo
>> +
>> + rohm,pin-exten1:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description: BD72720 has an OTP option to use exten1-pin for different
>> + purposes. Set this property accordingly.
>> + const: gpo
>
> And these 2 also.
>
>> +
>> + rohm,pin-fault_b:
>> + $ref: /schemas/types.yaml#/definitions/string
>> + description: BD72720 has an OTP option to use fault_b-pin for different
>> + purposes. Set this property accordingly.
>> + const: gpo
>
> Seems like different purposes would have more than 1 option.
They do. I only omitted them because I don't think knowing those
use-cases is relevant for the software. OTOH, maybe they some day can be
so I will revise the other uses and make more complete list. Thanks.
>
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> + - clocks
>> + - "#clock-cells"
>> + - regulators
>> + - gpio-controller
>> + - "#gpio-cells"
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/irq.h>
>> + #include <dt-bindings/leds/common.h>
>> + i2c {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + pmic: pmic@4b {
>> + compatible = "rohm,bd71828";
>> + reg = <0x4b>;
>
> Just 1 complete example in the mfd schema and drop this example.
Hmm? This is the MFD schema, right? :)
Yours,
-- Matti
^ permalink raw reply
* Re: [PATCH v2 4/5] rtc: tps6586x: Fix initial enable_irq/disable_irq balance
From: Alexandre Belloni @ 2025-10-29 10:39 UTC (permalink / raw)
To: Jon Hunter
Cc: Esben Haabendal, linux-rtc, linux-kernel, linux-arm-kernel,
linux-tegra@vger.kernel.org
In-Reply-To: <0aae5643-9276-4280-8b1e-27b8fe73fe99@nvidia.com>
On 29/10/2025 09:20:17+0000, Jon Hunter wrote:
> Hi Esben,
>
> On 16/05/2025 08:23, Esben Haabendal wrote:
> > Interrupts are automatically enabled when requested, so we need to
> > initialize irq_en accordingly to avoid causing an unbalanced enable
> > warning.
> >
> > Signed-off-by: Esben Haabendal <esben@geanix.com>
> > ---
> > drivers/rtc/rtc-tps6586x.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/rtc/rtc-tps6586x.c b/drivers/rtc/rtc-tps6586x.c
> > index 54c8429b16bfcc692b1f4d5404f0c42f720e93b4..76ecf7b798f0de22aa89a552a263b473ab3065ef 100644
> > --- a/drivers/rtc/rtc-tps6586x.c
> > +++ b/drivers/rtc/rtc-tps6586x.c
> > @@ -258,6 +258,7 @@ static int tps6586x_rtc_probe(struct platform_device *pdev)
> > irq_set_status_flags(rtc->irq, IRQ_NOAUTOEN);
> > + rtc->irq_en = true;
> > ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> > tps6586x_rtc_irq,
> > IRQF_ONESHOT,
> >
>
> I have bisected a suspend regression on one of our Tegra20 boards (that uses
> this driver) and bisect is pointing to this commit. Reverting this commit
> fixes the problem.
>
> Looking at the above I see that the flag IRQ_NOAUTOEN is being set and so
> now with your change we never enable the interrupt. Hence, the wake-ups are
> now broken and suspend testing fails. So it would seem best to revert this.
>
> BTW, I looked at the change to the CPCAP driver and that driver actively
> disables the IRQ after requesting it and so I am wondering if that will also
> have alarm issues? I don't have a board with CPCAP to test.
>
That's right, I guess you can send reverts.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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