* [PATCH] rtc: pcf2127: clear the PWRMNG bits for pcf2131
From: Alessandro Di Chiara via B4 Relay @ 2025-12-10 20:19 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel, Alessandro Di Chiara
From: Alessandro Di Chiara <alessandro.dichiara@se.com>
The pcf2131 does not retain the date by default. This is because the
reset value of the PWRMNG bits is 111, which is different from the
pcf2127/pcf2129, whose reset value is 000.
To keep consistency with the other rtc handled by the driver,
clear the PWRMNG bits for pcf2131 to enable:
- Battery switch-over function in standard mode.
- Battery low detection function.
Signed-off-by: Alessandro Di Chiara <alessandro.dichiara@se.com>
---
Hi,
this patch enables battery switch-over and low detection functions for
the rtc pcf2131.
Tested only with pcf2131.
---
drivers/rtc/rtc-pcf2127.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index bb4fe81d3d62..c6ea679645f2 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -1329,8 +1329,11 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
* Clear battery interrupt flags which can block new trigger events.
* Note: This is the default chip behaviour but added to ensure
* correct tamper timestamp and interrupt function.
+ * For pcf2131, clear the PWRMNG bits[7:5] because the reset value
+ * is 111, which is different from 2127/2129.
*/
ret = regmap_update_bits(pcf2127->regmap, PCF2127_REG_CTRL3,
+ (pcf2127->cfg->type == PCF2131 ? PCF2127_CTRL3_PM : 0) |
PCF2127_BIT_CTRL3_BTSE |
PCF2127_BIT_CTRL3_BIE |
PCF2127_BIT_CTRL3_BLIE, 0);
---
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
change-id: 20251210-rtc-pcf2131-clear-pwrmng-bits-20c33af7721c
Best regards,
--
Alessandro Di Chiara <alessandro.dichiara@se.com>
^ permalink raw reply related
* Re: [PATCH 1/4] rtc: zynqmp: correct frequency value
From: Tomas Melin @ 2025-12-10 12:29 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB980479009955E816E72E6EA892A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 18:51, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 1/4] rtc: zynqmp: correct frequency value
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> Fix calibration value in case a clock reference is provided.
>> The actual calibration value written into register is
>> frequency - 1.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
>> index
>> 3baa2b481d9f2008750046005283b98a0d546c5c..856bc1678e7d31144f320ae
>> 9f75fc58c742a2a64 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -345,7 +345,10 @@ static int xlnx_rtc_probe(struct platform_device
>> *pdev)
>> &xrtcdev->freq);
>> if (ret)
>> xrtcdev->freq = RTC_CALIB_DEF;
>> + } else {
>> + xrtcdev->freq--;
> If freq > 65536, the 16-bit register silently truncates.
> Please add some checks for above mentioned scenario.
That is indeed a scenario that is not accounted for in the current
driver. I can add a separate patch for that as part of this series.
Thanks,
Tomas
>> }
>> +
>> ret = readl(xrtcdev->reg_base + RTC_CALIB_RD);
>> if (!ret)
>> writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR));
>>
>> --
>> 2.47.3
>>
> Thanks,
> Harini T
^ permalink raw reply
* Re: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
From: Tomas Melin @ 2025-12-10 12:25 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB98046A63E80D7A7FA299366E92A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 21:28, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> Maximum and minimum offsets in ppb that can be handled are dependent
>> on the rtc clock frequency and what can fit in the 16-bit register field.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 8 +++-----
>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
>> 3bc8831ba2c4c4c701a49506b67ae6174f3ade3d..0cebc99b15a6de2440a60afc
>> 2bd1769eccfa84b3 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -44,8 +44,6 @@
>> #define RTC_FR_MASK 0xF0000
>> #define RTC_FR_MAX_TICKS 16
>> #define RTC_PPB 1000000000LL
>> -#define RTC_MIN_OFFSET -32768000
>> -#define RTC_MAX_OFFSET 32767000
>>
>> struct xlnx_rtc_dev {
>> struct rtc_device *rtc;
>> @@ -215,12 +213,12 @@ static int xlnx_rtc_set_offset(struct device *dev,
>> long offset)
>>
>> /* ticks to reach RTC_PPB */
>> tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
>> - if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
>> - return -ERANGE;
>> -
>> /* Number ticks for given offset */
>> max_tick = div_s64_rem(offset, tick_mult, &fract_offset);
>>
>> + if (freq + max_tick > RTC_TICK_MASK || (freq + max_tick < 1))
> The check 'freq + max_tick < 1' should be '<2' to prevent writing 0 to the calibration register when fract_offset < 0 causes max_tick--.
> Example: freq=32767, max_tick=-32766 passes (sum=1), but after decrement becomes calibval=0.
calibval=0 is not documented as invalid calibration value. AFAIS it
would mean a frequency of 1Hz. Can You provide more info on this?
Thanks,
Tomas
>> + return -ERANGE;
>> +
>> /* Number fractional ticks for given offset */
>> if (fract_offset) {
>> /* round up here so we stay below a full tick */
>>
>> --
>> 2.47.3
>>
>
> Thanks,
> Harini T
>
^ permalink raw reply
* Re: [PATCH 3/4] rtc: zynqmp: rework set_offset
From: Tomas Melin @ 2025-12-10 12:18 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB98045BF8A85640F924BCFD4492A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 21:03, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 3/4] rtc: zynqmp: rework set_offset
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> set_offset was using remainder of do_div as tick_mult which resulted in
>> wrong offset. Calibration value also assumed builtin calibration default.
>> Update fract_offset to correctly calculate the value for negative offset and
>> replace the for loop with division.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 29 +++++++++++------------------
>> 1 file changed, 11 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
>> 7af5f6f99538f961a53ff56bfc656c907611b900..3bc8831ba2c4c4c701a49506b6
>> 7ae6174f3ade3d 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
>> long *offset) static int xlnx_rtc_set_offset(struct device *dev, long offset) {
>> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
>> - unsigned long long rtc_ppb = RTC_PPB;
>> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
>> + unsigned int calibval, tick_mult, fract_part;
> tick_mult is mentioned as int in previous patch and unsigned here. Justify the type in commit description.
>> unsigned char fract_tick = 0;
>> - unsigned int calibval;
>> - short int max_tick;
>> - int fract_offset;
>> + int freq = xrtcdev->freq;
>> + int max_tick, fract_offset;
> Please follow reverse xmas tree variable ordering.
> Also keep the frac_* variables uniform in both set and read offset functions.
Agreed, I will use same name of variables and types in next version.
>>
>> + /* ticks to reach RTC_PPB */
> The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
Answered in patch 2/4.
>> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
> We can first validate offset and then calculate tick_mult to reduce CPU instructions incase of invalid inputs
In this patch it would in theory apply, but when looking at patch 4/4
You will notice that we need to first calculate the helpers so offset is
then performed as soon as possible.
>> if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
>> return -ERANGE;
>>
>> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
>> long offset)
>>
>> /* Number fractional ticks for given offset */
>> if (fract_offset) {
>> + /* round up here so we stay below a full tick */
>> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
>> if (fract_offset < 0) {
>> - fract_offset = fract_offset + tick_mult;
>> + fract_offset += (fract_part * RTC_FR_MAX_TICKS);
> It would be better to add comment to explain on the negative offset borrowing logic
I will add comment about this.
>> max_tick--;
>> }
>> - if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
>> - for (fract_tick = 1; fract_tick < 16; fract_tick++) {
>> - if (fract_offset <=
>> - (fract_tick *
>> - (tick_mult / RTC_FR_MAX_TICKS)))
>> - break;
>> - }
>> - }
>> + fract_tick = fract_offset / fract_part;
> Its better to use DIV_ROUND_UP()
Please explain why, that would change the end result from what is is now.
Thanks,
Tomas
>> }
>>
>> /* Zynqmp RTC uses second and fractional tick
>> * counters for compensation
>> */
>> - calibval = max_tick + RTC_CALIB_DEF;
>> + calibval = max_tick + freq;
>>
>> if (fract_tick)
>> - calibval |= RTC_FR_EN;
>> -
>> - calibval |= (fract_tick << RTC_FR_DATSHIFT);
>> + calibval |= (RTC_FR_EN | (fract_tick <<
>> + RTC_FR_DATSHIFT));
>>
>> writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>>
>>
>> --
>> 2.47.3
>>
>
> Regards,
> Harini T
^ permalink raw reply
* Re: [PATCH 2/4] rtc: zynqmp: rework read_offset
From: Tomas Melin @ 2025-12-10 12:04 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB98047B0A754AFFFB01163E0992A3A@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 09/12/2025 19:28, T, Harini wrote:
> [Public]
>
> Hi,
>
>> -----Original Message-----
>> From: Tomas Melin <tomas.melin@vaisala.com>
>> Sent: Monday, December 1, 2025 6:20 PM
>> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
>> <michal.simek@amd.com>
>> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
>> Subject: [PATCH 2/4] rtc: zynqmp: rework read_offset
>>
>> Caution: This message originated from an External Source. Use proper
>> caution when opening attachments, clicking links, or responding.
>>
>>
>> read_offset() was using static frequency for determining the tick offset. It was
>> also using remainder from do_div() operation as tick_mult value which
>> caused the offset to be incorrect.
>>
>> At the same time, rework function to improve readability.
>>
>> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
>> ---
>> drivers/rtc/rtc-zynqmp.c | 25 ++++++++++++++++---------
>> 1 file changed, 16 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
>> 856bc1678e7d31144f320ae9f75fc58c742a2a64..7af5f6f99538f961a53ff56bfc6
>> 56c907611b900 100644
>> --- a/drivers/rtc/rtc-zynqmp.c
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -178,21 +178,28 @@ static void xlnx_init_rtc(struct xlnx_rtc_dev
>> *xrtcdev) static int xlnx_rtc_read_offset(struct device *dev, long *offset) {
>> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
>> - unsigned long long rtc_ppb = RTC_PPB;
>> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
>> - unsigned int calibval;
>> + unsigned int calibval, fract_data, fract_part;
> Prefer one variable assignment per line for readability.
This is after all quite common practice, and in a function like this
where several variables are needed, I would argue that this is more
readable than the alternative. Is there some convention I'm not aware of?
>> + int max_tick, tick_mult;
> It would be better to explain why tick_mult is changed to int in the commit message.
This is part of the refactoring, mixing signed and unsigned variables in
operations is more risky than having same type.
>> + int freq = xrtcdev->freq;
> Please follow reverse xmas tree variable ordering.
Ok fixing this and other occurances.
>> long offset_val;
>>
>> + /* ticks to reach RTC_PPB */
> The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
Perhaps the comment was not well formulated. I suggest changing to
/* Tick to offset multiplier */
as that it what it is primarily used for. Would that be okay for You?
Thanks,
Tomas
>> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, freq);
>> +
>> calibval = readl(xrtcdev->reg_base + RTC_CALIB_RD);
>> /* Offset with seconds ticks */
>> - offset_val = calibval & RTC_TICK_MASK;
>> - offset_val = offset_val - RTC_CALIB_DEF;
>> - offset_val = offset_val * tick_mult;
>> + max_tick = calibval & RTC_TICK_MASK;
>> + offset_val = max_tick - freq;
>> + /* Convert to ppb */
>> + offset_val *= tick_mult;
>>
>> /* Offset with fractional ticks */
>> - if (calibval & RTC_FR_EN)
>> - offset_val += ((calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT)
>> - * (tick_mult / RTC_FR_MAX_TICKS);
>> + if (calibval & RTC_FR_EN) {
>> + fract_data = (calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT;
>> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
>> + offset_val += (fract_part * fract_data);
>> + }
>> +
>> *offset = offset_val;
>>
>> return 0;
>>
>> --
>> 2.47.3
>>
> Regards,
> Harini T
>
^ permalink raw reply
* RE: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
From: T, Harini @ 2025-12-09 19:28 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-4-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Maximum and minimum offsets in ppb that can be handled are dependent
> on the rtc clock frequency and what can fit in the 16-bit register field.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 3bc8831ba2c4c4c701a49506b67ae6174f3ade3d..0cebc99b15a6de2440a60afc
> 2bd1769eccfa84b3 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -44,8 +44,6 @@
> #define RTC_FR_MASK 0xF0000
> #define RTC_FR_MAX_TICKS 16
> #define RTC_PPB 1000000000LL
> -#define RTC_MIN_OFFSET -32768000
> -#define RTC_MAX_OFFSET 32767000
>
> struct xlnx_rtc_dev {
> struct rtc_device *rtc;
> @@ -215,12 +213,12 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
> /* ticks to reach RTC_PPB */
> tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
> - if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
> - return -ERANGE;
> -
> /* Number ticks for given offset */
> max_tick = div_s64_rem(offset, tick_mult, &fract_offset);
>
> + if (freq + max_tick > RTC_TICK_MASK || (freq + max_tick < 1))
The check 'freq + max_tick < 1' should be '<2' to prevent writing 0 to the calibration register when fract_offset < 0 causes max_tick--.
Example: freq=32767, max_tick=-32766 passes (sum=1), but after decrement becomes calibval=0.
> + return -ERANGE;
> +
> /* Number fractional ticks for given offset */
> if (fract_offset) {
> /* round up here so we stay below a full tick */
>
> --
> 2.47.3
>
Thanks,
Harini T
^ permalink raw reply
* RE: [PATCH 3/4] rtc: zynqmp: rework set_offset
From: T, Harini @ 2025-12-09 19:03 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-3-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 3/4] rtc: zynqmp: rework set_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> set_offset was using remainder of do_div as tick_mult which resulted in
> wrong offset. Calibration value also assumed builtin calibration default.
> Update fract_offset to correctly calculate the value for negative offset and
> replace the for loop with division.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 29 +++++++++++------------------
> 1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 7af5f6f99538f961a53ff56bfc656c907611b900..3bc8831ba2c4c4c701a49506b6
> 7ae6174f3ade3d 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
> long *offset) static int xlnx_rtc_set_offset(struct device *dev, long offset) {
> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> - unsigned long long rtc_ppb = RTC_PPB;
> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> + unsigned int calibval, tick_mult, fract_part;
tick_mult is mentioned as int in previous patch and unsigned here. Justify the type in commit description.
> unsigned char fract_tick = 0;
> - unsigned int calibval;
> - short int max_tick;
> - int fract_offset;
> + int freq = xrtcdev->freq;
> + int max_tick, fract_offset;
Please follow reverse xmas tree variable ordering.
Also keep the frac_* variables uniform in both set and read offset functions.
>
> + /* ticks to reach RTC_PPB */
The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
We can first validate offset and then calculate tick_mult to reduce CPU instructions incase of invalid inputs
> if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
> return -ERANGE;
>
> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
> /* Number fractional ticks for given offset */
> if (fract_offset) {
> + /* round up here so we stay below a full tick */
> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> if (fract_offset < 0) {
> - fract_offset = fract_offset + tick_mult;
> + fract_offset += (fract_part * RTC_FR_MAX_TICKS);
It would be better to add comment to explain on the negative offset borrowing logic
> max_tick--;
> }
> - if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
> - for (fract_tick = 1; fract_tick < 16; fract_tick++) {
> - if (fract_offset <=
> - (fract_tick *
> - (tick_mult / RTC_FR_MAX_TICKS)))
> - break;
> - }
> - }
> + fract_tick = fract_offset / fract_part;
Its better to use DIV_ROUND_UP()
> }
>
> /* Zynqmp RTC uses second and fractional tick
> * counters for compensation
> */
> - calibval = max_tick + RTC_CALIB_DEF;
> + calibval = max_tick + freq;
>
> if (fract_tick)
> - calibval |= RTC_FR_EN;
> -
> - calibval |= (fract_tick << RTC_FR_DATSHIFT);
> + calibval |= (RTC_FR_EN | (fract_tick <<
> + RTC_FR_DATSHIFT));
>
> writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>
>
> --
> 2.47.3
>
Regards,
Harini T
^ permalink raw reply
* RE: [PATCH 2/4] rtc: zynqmp: rework read_offset
From: T, Harini @ 2025-12-09 17:28 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-2-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 2/4] rtc: zynqmp: rework read_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> read_offset() was using static frequency for determining the tick offset. It was
> also using remainder from do_div() operation as tick_mult value which
> caused the offset to be incorrect.
>
> At the same time, rework function to improve readability.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 856bc1678e7d31144f320ae9f75fc58c742a2a64..7af5f6f99538f961a53ff56bfc6
> 56c907611b900 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -178,21 +178,28 @@ static void xlnx_init_rtc(struct xlnx_rtc_dev
> *xrtcdev) static int xlnx_rtc_read_offset(struct device *dev, long *offset) {
> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> - unsigned long long rtc_ppb = RTC_PPB;
> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> - unsigned int calibval;
> + unsigned int calibval, fract_data, fract_part;
Prefer one variable assignment per line for readability.
> + int max_tick, tick_mult;
It would be better to explain why tick_mult is changed to int in the commit message.
> + int freq = xrtcdev->freq;
Please follow reverse xmas tree variable ordering.
> long offset_val;
>
> + /* ticks to reach RTC_PPB */
The comment is misleading. Its tick_mult is nanoseconds per tick, not a tick count.
> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, freq);
> +
> calibval = readl(xrtcdev->reg_base + RTC_CALIB_RD);
> /* Offset with seconds ticks */
> - offset_val = calibval & RTC_TICK_MASK;
> - offset_val = offset_val - RTC_CALIB_DEF;
> - offset_val = offset_val * tick_mult;
> + max_tick = calibval & RTC_TICK_MASK;
> + offset_val = max_tick - freq;
> + /* Convert to ppb */
> + offset_val *= tick_mult;
>
> /* Offset with fractional ticks */
> - if (calibval & RTC_FR_EN)
> - offset_val += ((calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT)
> - * (tick_mult / RTC_FR_MAX_TICKS);
> + if (calibval & RTC_FR_EN) {
> + fract_data = (calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT;
> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> + offset_val += (fract_part * fract_data);
> + }
> +
> *offset = offset_val;
>
> return 0;
>
> --
> 2.47.3
>
Regards,
Harini T
^ permalink raw reply
* RE: [PATCH 1/4] rtc: zynqmp: correct frequency value
From: T, Harini @ 2025-12-09 16:51 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20251201-zynqmp-rtc-updates-v1-1-33875c1e385b@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Monday, December 1, 2025 6:20 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH 1/4] rtc: zynqmp: correct frequency value
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Fix calibration value in case a clock reference is provided.
> The actual calibration value written into register is
> frequency - 1.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
> index
> 3baa2b481d9f2008750046005283b98a0d546c5c..856bc1678e7d31144f320ae
> 9f75fc58c742a2a64 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -345,7 +345,10 @@ static int xlnx_rtc_probe(struct platform_device
> *pdev)
> &xrtcdev->freq);
> if (ret)
> xrtcdev->freq = RTC_CALIB_DEF;
> + } else {
> + xrtcdev->freq--;
If freq > 65536, the 16-bit register silently truncates.
Please add some checks for above mentioned scenario.
> }
> +
> ret = readl(xrtcdev->reg_base + RTC_CALIB_RD);
> if (!ret)
> writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR));
>
> --
> 2.47.3
>
Thanks,
Harini T
^ permalink raw reply
* Re: [PATCH] Documentation: ABI: testing: Fix "upto" typo in rtc-cdev
From: Alexandre Belloni @ 2025-12-08 22:10 UTC (permalink / raw)
To: Akiyoshi Kurita; +Cc: linux-rtc, linux-kernel
In-Reply-To: <20251112113759.2953758-1-weibu@redadmin.org>
On Wed, 12 Nov 2025 20:37:59 +0900, Akiyoshi Kurita wrote:
> The word "upto" is a common typo for "up to". Correct this.
>
>
Applied, thanks!
[1/1] Documentation: ABI: testing: Fix "upto" typo in rtc-cdev
https://git.kernel.org/abelloni/c/22a6db422537
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2] rtc: gamecube: Check the return value of ioremap()
From: Alexandre Belloni @ 2025-12-08 22:10 UTC (permalink / raw)
To: Haotian Zhang; +Cc: linkmauve, linux-rtc, linux-kernel
In-Reply-To: <20251126080625.1752-1-vulab@iscas.ac.cn>
On Wed, 26 Nov 2025 16:06:25 +0800, Haotian Zhang wrote:
> The function ioremap() in gamecube_rtc_read_offset_from_sram() can fail
> and return NULL, which is dereferenced without checking, leading to a
> NULL pointer dereference.
>
> Add a check for the return value of ioremap() and return -ENOMEM on
> failure.
>
> [...]
Applied, thanks!
[1/1] rtc: gamecube: Check the return value of ioremap()
https://git.kernel.org/abelloni/c/d1220e47e4bd
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH v3 2/4] rtc: spacemit: MFD_SPACEMIT_P1 as dependencies
From: Alexandre Belloni @ 2025-12-08 22:10 UTC (permalink / raw)
To: Lee Jones, Yixun Lan, Alex Elder, Andi Shyti, Liam Girdwood,
Mark Brown, Troy Mitchell
Cc: linux-kernel, linux-riscv, spacemit, linux-i2c, linux-rtc
In-Reply-To: <20251118-p1-kconfig-fix-v3-2-8839c5ac5db3@linux.spacemit.com>
On Tue, 18 Nov 2025 14:08:06 +0800, Troy Mitchell wrote:
> RTC_DRV_SPACEMIT_P1 is a subdevice of P1 and should depend on
> MFD_SPACEMIT_P1 rather than selecting it directly. Using 'select'
> does not always respect the parent's dependencies, so 'depends on'
> is the safer and more correct choice.
>
> Additionally, the default value depends on MFD_SPACEMIT_P1 rather
> than ARCH_SPACEMIT.
>
> [...]
Applied, thanks!
[2/4] rtc: spacemit: MFD_SPACEMIT_P1 as dependencies
https://git.kernel.org/abelloni/c/16bd954c9336
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: s35390a: use u8 instead of char for register buffer
From: Alexandre Belloni @ 2025-12-08 22:09 UTC (permalink / raw)
To: Nick Huang; +Cc: linux-rtc, linux-kernel, kusogame68, byron.bbradley
In-Reply-To: <20250920174224.108795-1-sef1548@gmail.com>
On Sun, 21 Sep 2025 01:42:23 +0800, Nick Huang wrote:
> The register buffer in s35390a_get_reg() was previously defined as
> `char *buf`. This is not ideal since register data represents raw
> binary values rather than textual data.
>
> Switch the type to `u8 *buf` to better reflect its intended usage and
> to avoid potential issues with sign extension when handling register
> values on platforms where `char` is signed by default.
>
> [...]
Applied, thanks!
[1/1] rtc: s35390a: use u8 instead of char for register buffer
https://git.kernel.org/abelloni/c/73c4638a2864
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH v4 0/4] Add RTC support for the Renesas RZ/V2H SoC
From: Alexandre Belloni @ 2025-12-08 22:09 UTC (permalink / raw)
To: claudiu.beznea.uj, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, p.zabel, Ovidiu Panait
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20251107210706.45044-1-ovidiu.panait.rb@renesas.com>
On Fri, 07 Nov 2025 21:07:02 +0000, Ovidiu Panait wrote:
> This series adds RTC support for the Renesas RZ/V2H SoC.
>
> The Renesas RZ/V2H RTC IP is based on the same RTCA3 IP as RZ/G3S
> (r9a08g045), with the following differences:
> - it lacks the time capture functionality
> - the maximum supported periodic interrupt frequency is 128Hz instead
> of 256Hz
> - it requires two reset lines instead of one
>
> [...]
Applied, thanks!
[1/4] dt-bindings: rtc: renesas,rz-rtca3: Add RZ/V2H support
https://git.kernel.org/abelloni/c/4800046b56a5
[2/4] rtc: renesas-rtca3: Add support for multiple reset lines
https://git.kernel.org/abelloni/c/6ada8e24238d
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH RESEND] rtc: max31335: Fix ignored return value in set_alarm
From: Alexandre Belloni @ 2025-12-08 22:09 UTC (permalink / raw)
To: linux-rtc, Nuno Sá; +Cc: Guenter Roeck, Antoniu Miclaus
In-Reply-To: <20251128-max31335-handler-error-v1-1-6b6f7f78dbda@analog.com>
On Fri, 28 Nov 2025 16:36:38 +0000, Nuno Sá wrote:
> Return the result from regmap_update_bits() instead of ignoring it
> and always returning 0.
>
>
Applied, thanks!
[1/1] rtc: max31335: Fix ignored return value in set_alarm
https://git.kernel.org/abelloni/c/f07640f9fb8d
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: drop unneeded file entry in NVIDIA VRS RTC DRIVER
From: Alexandre Belloni @ 2025-12-08 22:09 UTC (permalink / raw)
To: Shubhi Garg, linux-tegra, linux-rtc, Lukas Bulwahn
Cc: Jon Hunter, kernel-janitors, linux-kernel, Lukas Bulwahn
In-Reply-To: <20251110073544.443816-1-lukas.bulwahn@redhat.com>
On Mon, 10 Nov 2025 08:35:44 +0100, Lukas Bulwahn wrote:
> Commit 9d6d6b06933c ("rtc: nvvrs: add NVIDIA VRS RTC device driver") adds
> the section NVIDIA VRS RTC DRIVER in MAINTAINERS, which refers to the
> non-existing file include/linux/rtc/rtc-nvidia-vrs10.h
>
> Note, with the changes of v6 to v7 of the patch series adding the driver,
> the content of this include file was moved into the driver file, and the
> include file was dropped from that patch. It was simply missed to adjust
> the section in MAINTAINERS that was newly added with that patch.
>
> [...]
Applied, thanks!
[1/1] MAINTAINERS: drop unneeded file entry in NVIDIA VRS RTC DRIVER
https://git.kernel.org/abelloni/c/40d8123ff749
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 1/3] rtc: tegra: Use devm_clk_get_enabled() in probe
From: Alexandre Belloni @ 2025-12-08 22:09 UTC (permalink / raw)
To: thierry.reding, jonathanh, andriy.shevchenko, linux-rtc,
linux-tegra, linux-kernel, Kartik Rajput
In-Reply-To: <20251024064952.775883-1-kkartik@nvidia.com>
On Fri, 24 Oct 2025 12:19:50 +0530, Kartik Rajput wrote:
> Simplify clock management by replacing devm_clk_get() and manual clock
> enable/disable with devm_clk_get_enabled(). This also simplifies the
> error handling logic. Also remove tegra_rtc_remove() as the clock will
> automatically be disabled when the device is unbound from the bus.
>
>
Applied, thanks!
[1/3] rtc: tegra: Use devm_clk_get_enabled() in probe
https://git.kernel.org/abelloni/c/b665c1b620e7
[2/3] rtc: tegra: Add ACPI support
https://git.kernel.org/abelloni/c/0a293451030b
[3/3] rtc: tegra: Replace deprecated SIMPLE_DEV_PM_OPS
https://git.kernel.org/abelloni/c/bf5ef3ce42da
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: (subset) [PATCH v5 00/11] mfd: macsmc: add rtc, hwmon and hid subdevices
From: Alexandre Belloni @ 2025-12-08 22:09 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, Jonathan Corbet,
James Calligeros
Cc: asahi, linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, linux-doc, Mark Kettenis, Hector Martin
In-Reply-To: <20251112-macsmc-subdevs-v5-0-728e4b91fe81@gmail.com>
On Wed, 12 Nov 2025 21:16:46 +1000, James Calligeros wrote:
> This series adds support for the remaining SMC subdevices. These are the
> RTC, hwmon, and HID devices. They are being submitted together as the RTC
> and hwmon drivers both require changes to the SMC DT schema.
>
> The RTC driver is responsible for getting and setting the system clock,
> and requires an NVMEM cell. This series replaces Sven's original RTC driver
> submission [1].
>
> [...]
Applied, thanks!
[01/11] dt-bindings: rtc: Add Apple SMC RTC
https://git.kernel.org/abelloni/c/07049187e830
[03/11] rtc: Add new rtc-macsmc driver for Apple Silicon Macs
https://git.kernel.org/abelloni/c/49a51df427db
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH next] rtc: atcrtc100: Fix signedness bug in probe()
From: Alexandre Belloni @ 2025-12-08 22:08 UTC (permalink / raw)
To: CL Wang, Dan Carpenter; +Cc: linux-rtc, linux-kernel, kernel-janitors
In-Reply-To: <aRxPGBEX8hbY6sjV@stanley.mountain>
On Tue, 18 Nov 2025 13:48:56 +0300, Dan Carpenter wrote:
> The "atcrtc_dev->alarm_irq" variable is an unsigned int but it needs to
> be signed for the error handling to work. Use the "ret" variable
> instead.
>
>
Applied, thanks!
[1/1] rtc: atcrtc100: Fix signedness bug in probe()
https://git.kernel.org/abelloni/c/159a740c768e
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: Kconfig: add MC34708 to mc13xxx help text
From: Alexandre Belloni @ 2025-12-08 22:08 UTC (permalink / raw)
To: linux-rtc, linux-kernel, Alexander Kurz
In-Reply-To: <20251011062605.13591-1-akurz@blala.de>
On Sat, 11 Oct 2025 06:26:05 +0000, Alexander Kurz wrote:
> MC34708 is one of the three mfd devices supported by DRV_MC13XXX.
> Update Kconfig accordingly.
>
>
Applied, thanks!
[1/1] rtc: Kconfig: add MC34708 to mc13xxx help text
https://git.kernel.org/abelloni/c/53e71c177cd8
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: isl12026: Add id_table
From: Alexandre Belloni @ 2025-12-08 22:07 UTC (permalink / raw)
To: ddaney, david.daney, pombredanne, Akhilesh Patil
Cc: linux-rtc, linux-kernel, akhileshpatilvnit, skhan
In-Reply-To: <2025119-54859-2010914@bhairav-test.ee.iitb.ac.in>
On Sun, 09 Nov 2025 11:18:59 +0530, Akhilesh Patil wrote:
> Add i2c id_table for isl12026 rtc.
>
>
Applied, thanks!
[1/1] rtc: isl12026: Add id_table
https://git.kernel.org/abelloni/c/e0784949c65b
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: PROBLEM: hwclock busted w/ M48T59 RTC (regression)
From: Thorsten Leemhuis @ 2025-12-08 14:35 UTC (permalink / raw)
To: Nick Bowler, linux-kernel, regressions, linux-rtc
Cc: Esben Haabendal, stable, sparclinux
In-Reply-To: <gfwdg244bcmkv7l44fknfi4osd2b23unwaos7rnlirkdy2rrrt@yovd2vewdviv>
Lo!
On 11/26/25 04:18, Nick Bowler wrote:
> Any thoughts?
Not really, just a vague idea (and reminder, this is not my area or
expertise, I'm just tracking regressions):
Two fixes were proposed for the culprit, see:
https://lore.kernel.org/all/BN0PR08MB69510928028C933749F4139383D1A@BN0PR08MB6951.namprd08.prod.outlook.com/
https://lore.kernel.org/all/BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com/
Wondering if they might help. Esben might have an idea, but in case
Esben does not reply maybe just give them a spin if you have a minute.
Ciao, Thorsten
> The problem is still present in 6.18-rc7 and reverting the commit
> indicated below still fixes it.
>
> I am also seeing the same failure on a totally different system with
> Dallas DS1286 RTC, which is also fixed by reverting this commit.
>
> Since the initial report this regression has been further backported
> to all the remaining longterm kernel series.
>
> Thanks,
> Nick
>
> On Thu, Oct 23, 2025 at 12:45:13AM -0400, Nick Bowler wrote:
>> Hi,
>>
>> After a stable kernel update, the hwclock command seems no longer
>> functional on my SPARC system with an ST M48T59Y-70PC1 RTC:
>>
>> # hwclock
>> [...long delay...]
>> hwclock: select() to /dev/rtc0 to wait for clock tick timed out
>>
>> On prior kernels, there is no problem:
>>
>> # hwclock
>> 2025-10-22 22:21:04.806992-04:00
>>
>> I reproduced the same failure on 6.18-rc2 and bisected to this commit:
>>
>> commit 795cda8338eab036013314dbc0b04aae728880ab
>> Author: Esben Haabendal <esben@geanix.com>
>> Date: Fri May 16 09:23:35 2025 +0200
>>
>> rtc: interface: Fix long-standing race when setting alarm
>>
>> This commit was backported to all current 6.x stable branches,
>> as well as 5.15.x, so they all have the same regression.
>>
>> Reverting this commit on top of 6.18-rc2 corrects the problem.
>>
>> Let me know if you need any more info!
>>
>> Thanks,
>> Nick
>
>
^ permalink raw reply
* ペット愛をもつ、経営者様へ
From: ペット保護支援セミナー @ 2025-12-08 7:39 UTC (permalink / raw)
To: linux-rtc
ペット愛の心を持つ経営者様へ
動物の尊い命を救い、働く喜びを支援する
革新的な新規事業を始めませんか？
−−−−−−−−−−−−−−−−−−−−−−−
■ フランチャイズシステム説明会 ■
社会貢献と高収益を両立！
ペット保護×就労継続支援B型事業
”ONEPET（ワンペット）”
※本部が徹底サポート！「経験や資格が無くても」
リスクを抑えて安心して始められます。
■ 開催方式
オンライン（申込後に参加方法をご案内）
■ 日程
12月09日（火）17：00〜18：30
12月13日（土）13：00〜14：30 残1枠
12月17日（水）17：00〜18：30
12月19日（金）16：00〜17：30
■ 定員
各回4名 ／ 1社2名まで
■ 視聴予約はこちら
https://onelife-lab.site/onepet/
−−−−−−−−−−−−−−−−−−−−−−−
お世話になります。
この度は、「保護犬・猫」と「就労支援」を組み合わせた、
革新的なフランチャイズ事業の説明会をご案内いたします。
私たちがご提供する ONEPET（ワンペット） は、
「殺処分を待つ命を救う」
「働きたいと願う人々の自立を支援する」
という、二つの大きな社会課題を同時に
解決するビジネスモデルです。
社会貢献事業は、収益がイマイチ。と、思わないでください。
ONEPETでは、“動物と関わる”という圧倒的な差別化コンテンツを持つことで
利用者から「やってみたい」と選ばれ、極めて高い集客力を誇ります。
（オープン2ヶ月で400件超の問合せを達成）
さらに、国の給付金によるストック型収益と
ペット事業による店舗収益の二本柱で、
景気に左右されにくい安定経営を実現しています。
事実、年商7,000万円／営業利益率40％を目指せる高収益事業として、
多くの経営者様にご注目いただいています。
ここまでこの文章を読まれたということは、
あなたも動物への深い愛情と、社会に貢献したいという
強い意志をお持ちなのではないでしょうか。
先輩FCオーナー様も福祉業界の経験がなくても、
「定員満員までWeb広告費本部負担」
「稼働率50％までロイヤリティ無料」
といった、本部の手厚いサポートのもと
事業を成功させています。
この革新的なビジネスモデルの詳細を聞き逃さないよう、
新規事業を探している経営者様は、この機会にぜひご視聴ください。
「社会課題解決」と「安定収益」を両立する、
新しい社会貢献のカタチを一緒につくっていきましょう。
■ 視聴予約はこちら
https://onelife-lab.site/onepet/
+++++++++++++++++++++++++++++++++++++++
本メールのご不要な方には大変ご迷惑をおかけいたしました。
お手数お掛けしますが、メール解除のお手続きは
下記よりお願いいたします。
<依頼フォーム>
https://onelife-lab.site/mail/
+++++++++++++++++++++++++++++++++++++++
ONEPET（ワンペット） フランチャイズ本部
群馬県前橋市広瀬町3-18-15
TEL：080-7723-6089
^ permalink raw reply
* まるなげ福祉事業
From: 福祉フランチャイズ本部 @ 2025-12-05 1:05 UTC (permalink / raw)
To: linux-rtc
新規事業をご検討中の経営者様へ
いつもお世話になっております。
「社会貢献性の高い事業で、確実な収益を上げたい」
そう考え、成長著しい福祉市場にご関心をお持ちのことと存じます。
しかし、同時にこうも考えていませんか？
「市場は魅力的だが、専門的な法規制や複雑な運営、人材採用は荷が重すぎる…」
「もし失敗したら、多額の投資が無駄になってしまうのでは…」
ご安心ください。その不安こそ、私たちが解決したい最大の課題でした。
この障壁を根本から取り除くのが、私たちtocotocoだけの
【運営本部代行プラン】です。
煩雑な運営業務は全て本部がプロフェッショナルとして代行します。
オーナー様には、「投資家」として市場の確実な成長という
最大の果実のみを受け取っていただきます。
―――――――――――
廃業率0.055％ 業態を選べる
障がい福祉フランチャイズ
<ご視聴予約はこちら>
https://fc-tocotoco.work/25/
〇オンラインで開催中
12月9日（火）10:00〜11:00
12月17日（水）15:00〜16:00
ご都合の良い日程をお選びいただけます。
―――――――――――
■ 失敗の不安を解消。本部代行プランの3大メリット
１．専門知識、一切不要
複雑な行政への請求や法改正対応、専門スタッフの採用・管理まで、全て本部が代行します。
異業種出身であることを気にする必要は一切ありません。
２．早期の投資回収を実現
煩雑な運営業務から解放され、オーナー様は事業拡大、
そして投資利回り50%以上、6ヶ月〜での投資回収実績を持つ、
確実な収益構造の構築に専念できます。
３．廃業率0.055％の安定性を最大限享受
業界トップクラスの実績とノウハウを持つ本部が現場を担うため、
「運営不安による失敗」というリスクが限りなくゼロに近づきます。
■ 市場の確実性を数字で証明
・市場規模：4兆円超え
・需要：障がい者数 毎月4万人増加
・安定性：廃業率0.055％（行政による総量規制で事業が守られています）
この巨大かつ安定した市場で、本部が代行することで、
より確実性の高い事業運営が実現します。
【運営代行プラン】は説明会でのみ詳細を公開
投資したいが運営までは荷が重い、という経営者様のために開発されたこの特別プランと、
5つの高収益業態（訪問看護、グループホームなど）の具体的な収益モデルは、
下記の説明会でのみ公開しております。
新規事業のリスクを最小化し、確実な収益源を確保したい方は、
ぜひこの機会にご参加ください。
▼ 詳細はこちら
https://fc-tocotoco.work/25/
―――
tocotoco株式会社 セミナー事務局
東京都千代田区九段南2丁目3−25
03-5256-7578
‥‥‥‥
本メールのご不要な方には大変ご迷惑をおかけいたしました。
メール停止ご希望の方は、お手数ですが下記URLにて、
お手続きをお願いいたします。
https://fc-tocotoco.work/mail/
―――
^ permalink raw reply
* 歌・ダンス等のスクール事業 FC説明会
From: 株式会社 K Village @ 2025-12-04 2:38 UTC (permalink / raw)
To: linux-rtc
お世話になります。
新たな事業展開をお考えの経営者様へ、
幼児から学生、社会人、シニアまで
幅広い世代を対象にしたボイトレ・ダンススクール事業の
フランチャイズシステム説明会をご案内申し上げます。
━━━━━━━━━━━━━━━━━━━━━━━━
12月6日（土）13:00〜14:00
12月10日（水）13:00〜14:00
12月17日（水）13:00〜14:00
◆ フランチャイズ説明会
幼児から学生、社会人、シニアまで！
ボイトレ・ダンスのマンツーマン制スクール事業
“ NAYUTAS（ナユタス） ”
※ オーナー様にボイトレや業界知識などは不要で、
未経験から開業することができます。
◆ 詳細＆申込はこちら
https://nayutas-voice.biz/2500/
━━━━━━━━━━━━━━━━━━━━━━━━
------------------------------------------------
NAYUTAS（ナユタス）はボイトレをはじめ、
楽器やダンス、プログラミング、動画編集など、
好きなこと・興味があることを本格的に学べる
完全マンツーマン制レッスンのスクール事業です。
------------------------------------------------
学習塾のように子どもや学生のみが対象になるのではなく、
社会人やシニアも含め、3歳〜80歳の方が生徒として通われています。
収益モデルは「生徒数×月額授業料」が売上になるサブスク型で、
生徒数が増えることによって、売上・利益が拡大していきます。
講師の採用や、開校後の生徒集客の確かなノウハウもあるため、オーナー様に
ボイトレや業界知識が無くとも、未経験から開業することが可能です。
フランチャイズ説明会を開催いたしますので、
ご興味がありましたらご参加くださいませ。
━━━━━━━━━━━━━━━━━━━
■ 開催日程
12月6日（土）13:00〜14:00
12月10日（水）13:00〜14:00
12月17日（水）13:00〜14:00
■ 開催方式
・オンライン開催
■ コンテンツ
・入会者数の推移
・ナユタスの特徴と選ばれる3つの理由
・フランチャイズシステム詳細
・開業費用例／収益例
■ 主催
・株式会社 K Village（ナユタス運営本部）
■ 定員
・5社／各回
■ 参加費
・不要です
■ 詳細＆申込はこちら
https://nayutas-voice.biz/2500/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本メールが不要の方には大変失礼しました。
今後ご案内が不要な際は、下記URLにて配信停止を承っています。
https://nayutas-voice.biz/mail/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
株式会社 K Village（ナユタス運営本部）
東京都新宿区西新宿2-4-1 新宿NSビル7F
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
^ 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