* Re: [PATCH] rtc: interface: Add rtc time jump debug in rtc_timer_do_work()
From: Jinjie Ruan @ 2026-06-16 8:12 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel
In-Reply-To: <202606160657465eab6e41@mail.local>
On 6/16/2026 2:57 PM, Alexandre Belloni wrote:
> Hi,
>
> On 16/06/2026 10:10:19+0800, Jinjie Ruan wrote:
>>
>>
>> On 6/15/2026 11:22 PM, Alexandre Belloni wrote:
>>> Hello,
>>>
>>> On 25/05/2026 21:08:25+0800, Jinjie Ruan wrote:
>>>> In virtualization environments like QEMU [1], or during hardware
>>>> clocksource anomalies, an extreme time-warp event can occur. When
>>>> the system time abruptly jumps forward, the rtc_timer_do_work() handler
>>>> falls into a prolonged processing loop to clear accumulated historical
>>>> timers via timerqueue_getnext(). Running this loop indefinitely under
>>>> the rtc->ops_lock mutex triggers a kernel softlockup, stalling
>>>> the system.
>>>>
>>>> Introduce an adaptive telemetry and loop guard mechanism to enhance debug
>>>> visibility and prevent softlockups:
>>>>
>>>> 1. Record `start_jiffies` upon entry and leverage `time_after()` to
>>>> check if the loop has monopolized the CPU for more than 1s (HZ). If so,
>>>> the handler prints a telemetry warning, triggers a WARN stack dump, and
>>>> breaks the loop to safely yield the CPU.
>>>>
>>>> 2. Track the execution via a `loop_count` metric. Printing this counter
>>>> in the warning log provides vital diagnostics to distinguish
>>>> an aggressive time-warp storm (high count) from a bogged-down callback
>>>> bug (low count).
>>>>
>>>> 3. Utilize the kernel format specifier `%ptR` to convert the raw ktime
>>>> into a human-readable timestamp (YYYY-MM-DD HH:MM:SS), allowing
>>>> developers to instantly pinpoint the exact boundary of the time
>>>> jump in dmesg.
>>>>
>>>> This non-destructive telemetry guard provides precise hardware/emulator
>>>> diagnostic visibility while ensuring core kernel availability.
>>>>
>>>> [1]: https://lore.kernel.org/all/20260114013257.3500578-1-ruanjinjie@huawei.com/
>>>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>>>> ---
>>>> drivers/rtc/interface.c | 15 +++++++++++++--
>>>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
>>>> index 1906f4884a83..f6c5fd16cc4e 100644
>>>> --- a/drivers/rtc/interface.c
>>>> +++ b/drivers/rtc/interface.c
>>>> @@ -927,10 +927,12 @@ static void rtc_timer_remove(struct rtc_device *rtc, struct rtc_timer *timer)
>>>> */
>>>> void rtc_timer_do_work(struct work_struct *work)
>>>> {
>>>> - struct rtc_timer *timer;
>>>> + unsigned long start_jiffies = jiffies;
>>>> struct timerqueue_node *next;
>>>> - ktime_t now;
>>>> + struct rtc_timer *timer;
>>>> struct rtc_time tm;
>>>> + int loop_count = 0;
>>>> + ktime_t now;
>>>> int err;
>>>>
>>>> struct rtc_device *rtc =
>>>> @@ -945,6 +947,15 @@ void rtc_timer_do_work(struct work_struct *work)
>>>> }
>>>> now = rtc_tm_to_ktime(tm);
>>>> while ((next = timerqueue_getnext(&rtc->timerqueue))) {
>>>> + loop_count++;
>>>> +
>>>> + if (unlikely(time_after(jiffies, start_jiffies + HZ))) {
>>>> + dev_warn(&rtc->dev, "RTC time jump (loop: %d) to %ptR.\n",
>>>> + loop_count, &tm);
>>>> + WARN_ON_ONCE(1);
>>>
>>> So, your issue is that it is too slow so you make it even slower? There
>>> are already plenty of tracepoints that allow proper debugging in this
>>> loop, I'm pretty sure we don't want to bloat the kernel with more
>>> messages.
>>
>> Hi, Alexandre,
>>
>> The point here is not about the performance of the rtc_timer_do_work()
>> loop — it’s about making the problem debuggable when things go wrong.
>> And we can put it under a debug Kconfig option, so production kernels
>> see no extra overhead at all.
>
>
> But then aren't the tracepoint enough? There are 3 tracepoints in the
> loop that are exactly for debugging your issue.
Hi, Alexandre,
Regarding the `trace_rtc_timer_dequeue` and `trace_rtc_timer_enqueue`
tracepoints, they are unfortunately insufficient to pinpoint this issue
for three reasons:
1. Ring Buffer Overwrite during Softlockup:
When the loop iterates tens of millions of times continuously on a
locked-up CPU, it floods the ftrace ring buffer in milliseconds. The
earliest trace logs—which contain the exact moment the time jumped—will
be completely overwritten and lost before anyone can read them.
2. Lack of Causality Context:
These tracepoints only log the timer's expiration and queue state.They
show the symptom (infinite re-enqueuing). But these are not the primary
scene, the time jump is the primary scene. They do not capture why are
there so many UIE timers being re-enqueued?
>
>>
>> The patch is installed in the following scenarios:
>>
>> If the RTC hardware fails, or if the QEMU-emulated RTC device code in a
>> KVM virtual machine has a problem (for example, the x86 RTC emulation
>> hardware mc146818 has an overflow issue[1]), the time may jump as shown
>> in the log below, which can cause a soft lockup.
>
> This is not clear, you are not explaining the issue. You seem to mix
> system time and RTC time. What I understand is that there was a periodic
> timer enqueued and then for some reason, the system time jumped forward
> by a large amount and now rtc_timer_do_work is firing events for each of
> the missed timers. You are not explaining the relationship with the RTC
> hardware (I see none).
The time here all means the RTC time got by __rtc_read_time(), not the
system time.
And the RTC time jump is caused by RTC hardware failure or
`QEMU-emulated RTC device` code bug, which means the rtc hardware
returns an unstable rtc time or is not completely linear growth..
The original issue is as follows：
On kvm qemu with cmos rtc and mc146818 chip, after set the UIE timer
expire with a normal RTC time （for example 2026 year）, In
rtc_timer_do_work(), the rtc time jump to a future time (for example
2033 year), it will loop for a while util softlockup because all
subsequent enqueued UIE timers expires, as below:
RTC_UIE_ON:
read now: 2019:04:08:12:32:27, add timer0 (expire: 2019:04:08:12:32:28)
^^^^^^^^^^^^^^^^^^^^
...
rtc_timer_do_work() iterate the list in a loop:
read now: 2033:12:02:07:27:15
^^^^^^^^^^^^^^^^^^^
handle timer0, add timer1 to the list (expire: 2019:04:08:12:32:29)
handle timer1, add timer2 to the list (expire: 2019:04:08:12:32:30)
handle timer2, add timer3: 2019:04:08:12:32:31
...
-> softlockup
>
>>
>> However, when the issue occurs, it is only possible to know that too
>> many pending timers have accumulated in the timerqueue (for example, the
>> log shows that tens of millions of timer nodes have been processed) by
>> temporarily adding diagnostic code in rtc_timer_do_work().
>>
>
> This is not true, there are 3 tracepoints to know what is happening with
> the timers. Also, there are always exactly zero, one or two timers in
> the queue, never tens of millions.
Timer Queue Size vs. Loop Iteration Count:
You are completely correct that there are only ever 0, 1, or 2 timer
nodes linked in the timerqueue. My previous phrasing was inaccurate, I
mean the loop Iteration.
>
>> To determine whether the root cause is hardware, kernel RTC code, an RTC
>> driver issue, or an RTC hardware problem, more debugging is needed. But
>> if the problem is indeed caused by RTC hardware, adding a diagnostic
>> print of the current RTC time when the loop takes too long (as this
>> diagnostic patch does) would make it easy to tell whether QEMU or the
>> hardware is faulty.
>>
>> [1]: https://lore.kernel.org/all/20260613195116.1807273-21-mjt@tls.msk.ru/
>>
>> kworker/0:1-37 [000] .N.. 489.159634: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281423
>> kworker/0:1-37 [000] .N.. 489.159635: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281424
>> kworker/0:1-37 [000] .N.. 489.159635: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281425
>> kworker/0:1-37 [000] .N.. 489.159636: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281426
>> kworker/0:1-37 [000] .N.. 489.159637: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281427
>> kworker/0:1-37 [000] .N.. 489.159638: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281428
>> kworker/0:1-37 [000] .N.. 489.159638: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281429
>> kworker/0:1-37 [000] .N.. 489.159639: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281430
>> kworker/0:1-37 [000] .N.. 489.159640: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281431
>> kworker/0:1-37 [000] .N.. 489.159641: rtc_timer_do_work:
>> timerqueue_getnext handle timer node count: 13281432
>>
>>
>> swapper/0-1 [001] .N.. 11.579334: __rtc_read_time: rtc:
>> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
>> swapper/0-1 [001] .N.. 11.579421: __rtc_read_time: rtc:
>> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
>> swapper/0-1 [001] .N.. 11.579469: __rtc_read_time: rtc:
>> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
>> swapper/0-1 [001] .N.. 11.580816: __rtc_read_time: rtc:
>> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
>> syz-executor.5-7492 [003] .... 129.807406: __rtc_read_time: rtc:
>> 0xff11000109896800, ops->read_time:2033:05:04:07:03:51
>> syz-executor.5-7492 [003] .... 129.807419:
>> __rtc_update_irq_enable.part.8: rtc uie on: 0xff11000109896800, now:
>> 2033:05:04:07:03:51, expire: 2033:05:04:07:03:52
>>
>>
>> Best regards,
>> Jinjie
>>
>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH] rtc: interface: Add rtc time jump debug in rtc_timer_do_work()
From: Alexandre Belloni @ 2026-06-16 6:57 UTC (permalink / raw)
To: Jinjie Ruan; +Cc: linux-rtc, linux-kernel
In-Reply-To: <06cdb8b3-8a5d-4f1d-b686-6122fa6f7af9@huawei.com>
Hi,
On 16/06/2026 10:10:19+0800, Jinjie Ruan wrote:
>
>
> On 6/15/2026 11:22 PM, Alexandre Belloni wrote:
> > Hello,
> >
> > On 25/05/2026 21:08:25+0800, Jinjie Ruan wrote:
> >> In virtualization environments like QEMU [1], or during hardware
> >> clocksource anomalies, an extreme time-warp event can occur. When
> >> the system time abruptly jumps forward, the rtc_timer_do_work() handler
> >> falls into a prolonged processing loop to clear accumulated historical
> >> timers via timerqueue_getnext(). Running this loop indefinitely under
> >> the rtc->ops_lock mutex triggers a kernel softlockup, stalling
> >> the system.
> >>
> >> Introduce an adaptive telemetry and loop guard mechanism to enhance debug
> >> visibility and prevent softlockups:
> >>
> >> 1. Record `start_jiffies` upon entry and leverage `time_after()` to
> >> check if the loop has monopolized the CPU for more than 1s (HZ). If so,
> >> the handler prints a telemetry warning, triggers a WARN stack dump, and
> >> breaks the loop to safely yield the CPU.
> >>
> >> 2. Track the execution via a `loop_count` metric. Printing this counter
> >> in the warning log provides vital diagnostics to distinguish
> >> an aggressive time-warp storm (high count) from a bogged-down callback
> >> bug (low count).
> >>
> >> 3. Utilize the kernel format specifier `%ptR` to convert the raw ktime
> >> into a human-readable timestamp (YYYY-MM-DD HH:MM:SS), allowing
> >> developers to instantly pinpoint the exact boundary of the time
> >> jump in dmesg.
> >>
> >> This non-destructive telemetry guard provides precise hardware/emulator
> >> diagnostic visibility while ensuring core kernel availability.
> >>
> >> [1]: https://lore.kernel.org/all/20260114013257.3500578-1-ruanjinjie@huawei.com/
> >> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> >> ---
> >> drivers/rtc/interface.c | 15 +++++++++++++--
> >> 1 file changed, 13 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> >> index 1906f4884a83..f6c5fd16cc4e 100644
> >> --- a/drivers/rtc/interface.c
> >> +++ b/drivers/rtc/interface.c
> >> @@ -927,10 +927,12 @@ static void rtc_timer_remove(struct rtc_device *rtc, struct rtc_timer *timer)
> >> */
> >> void rtc_timer_do_work(struct work_struct *work)
> >> {
> >> - struct rtc_timer *timer;
> >> + unsigned long start_jiffies = jiffies;
> >> struct timerqueue_node *next;
> >> - ktime_t now;
> >> + struct rtc_timer *timer;
> >> struct rtc_time tm;
> >> + int loop_count = 0;
> >> + ktime_t now;
> >> int err;
> >>
> >> struct rtc_device *rtc =
> >> @@ -945,6 +947,15 @@ void rtc_timer_do_work(struct work_struct *work)
> >> }
> >> now = rtc_tm_to_ktime(tm);
> >> while ((next = timerqueue_getnext(&rtc->timerqueue))) {
> >> + loop_count++;
> >> +
> >> + if (unlikely(time_after(jiffies, start_jiffies + HZ))) {
> >> + dev_warn(&rtc->dev, "RTC time jump (loop: %d) to %ptR.\n",
> >> + loop_count, &tm);
> >> + WARN_ON_ONCE(1);
> >
> > So, your issue is that it is too slow so you make it even slower? There
> > are already plenty of tracepoints that allow proper debugging in this
> > loop, I'm pretty sure we don't want to bloat the kernel with more
> > messages.
>
> Hi, Alexandre,
>
> The point here is not about the performance of the rtc_timer_do_work()
> loop — it’s about making the problem debuggable when things go wrong.
> And we can put it under a debug Kconfig option, so production kernels
> see no extra overhead at all.
But then aren't the tracepoint enough? There are 3 tracepoints in the
loop that are exactly for debugging your issue.
>
> The patch is installed in the following scenarios:
>
> If the RTC hardware fails, or if the QEMU-emulated RTC device code in a
> KVM virtual machine has a problem (for example, the x86 RTC emulation
> hardware mc146818 has an overflow issue[1]), the time may jump as shown
> in the log below, which can cause a soft lockup.
This is not clear, you are not explaining the issue. You seem to mix
system time and RTC time. What I understand is that there was a periodic
timer enqueued and then for some reason, the system time jumped forward
by a large amount and now rtc_timer_do_work is firing events for each of
the missed timers. You are not explaining the relationship with the RTC
hardware (I see none).
>
> However, when the issue occurs, it is only possible to know that too
> many pending timers have accumulated in the timerqueue (for example, the
> log shows that tens of millions of timer nodes have been processed) by
> temporarily adding diagnostic code in rtc_timer_do_work().
>
This is not true, there are 3 tracepoints to know what is happening with
the timers. Also, there are always exactly zero, one or two timers in
the queue, never tens of millions.
> To determine whether the root cause is hardware, kernel RTC code, an RTC
> driver issue, or an RTC hardware problem, more debugging is needed. But
> if the problem is indeed caused by RTC hardware, adding a diagnostic
> print of the current RTC time when the loop takes too long (as this
> diagnostic patch does) would make it easy to tell whether QEMU or the
> hardware is faulty.
>
> [1]: https://lore.kernel.org/all/20260613195116.1807273-21-mjt@tls.msk.ru/
>
> kworker/0:1-37 [000] .N.. 489.159634: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281423
> kworker/0:1-37 [000] .N.. 489.159635: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281424
> kworker/0:1-37 [000] .N.. 489.159635: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281425
> kworker/0:1-37 [000] .N.. 489.159636: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281426
> kworker/0:1-37 [000] .N.. 489.159637: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281427
> kworker/0:1-37 [000] .N.. 489.159638: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281428
> kworker/0:1-37 [000] .N.. 489.159638: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281429
> kworker/0:1-37 [000] .N.. 489.159639: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281430
> kworker/0:1-37 [000] .N.. 489.159640: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281431
> kworker/0:1-37 [000] .N.. 489.159641: rtc_timer_do_work:
> timerqueue_getnext handle timer node count: 13281432
>
>
> swapper/0-1 [001] .N.. 11.579334: __rtc_read_time: rtc:
> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
> swapper/0-1 [001] .N.. 11.579421: __rtc_read_time: rtc:
> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
> swapper/0-1 [001] .N.. 11.579469: __rtc_read_time: rtc:
> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
> swapper/0-1 [001] .N.. 11.580816: __rtc_read_time: rtc:
> 0xff11000109896800, ops->read_time:2026:01:05:09:36:21
> syz-executor.5-7492 [003] .... 129.807406: __rtc_read_time: rtc:
> 0xff11000109896800, ops->read_time:2033:05:04:07:03:51
> syz-executor.5-7492 [003] .... 129.807419:
> __rtc_update_irq_enable.part.8: rtc uie on: 0xff11000109896800, now:
> 2033:05:04:07:03:51, expire: 2033:05:04:07:03:52
>
>
> Best regards,
> Jinjie
>
> >
> >
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: interface: Add rtc time jump debug in rtc_timer_do_work()
From: Jinjie Ruan @ 2026-06-16 2:10 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel
In-Reply-To: <2026061515223171f111f5@mail.local>
On 6/15/2026 11:22 PM, Alexandre Belloni wrote:
> Hello,
>
> On 25/05/2026 21:08:25+0800, Jinjie Ruan wrote:
>> In virtualization environments like QEMU [1], or during hardware
>> clocksource anomalies, an extreme time-warp event can occur. When
>> the system time abruptly jumps forward, the rtc_timer_do_work() handler
>> falls into a prolonged processing loop to clear accumulated historical
>> timers via timerqueue_getnext(). Running this loop indefinitely under
>> the rtc->ops_lock mutex triggers a kernel softlockup, stalling
>> the system.
>>
>> Introduce an adaptive telemetry and loop guard mechanism to enhance debug
>> visibility and prevent softlockups:
>>
>> 1. Record `start_jiffies` upon entry and leverage `time_after()` to
>> check if the loop has monopolized the CPU for more than 1s (HZ). If so,
>> the handler prints a telemetry warning, triggers a WARN stack dump, and
>> breaks the loop to safely yield the CPU.
>>
>> 2. Track the execution via a `loop_count` metric. Printing this counter
>> in the warning log provides vital diagnostics to distinguish
>> an aggressive time-warp storm (high count) from a bogged-down callback
>> bug (low count).
>>
>> 3. Utilize the kernel format specifier `%ptR` to convert the raw ktime
>> into a human-readable timestamp (YYYY-MM-DD HH:MM:SS), allowing
>> developers to instantly pinpoint the exact boundary of the time
>> jump in dmesg.
>>
>> This non-destructive telemetry guard provides precise hardware/emulator
>> diagnostic visibility while ensuring core kernel availability.
>>
>> [1]: https://lore.kernel.org/all/20260114013257.3500578-1-ruanjinjie@huawei.com/
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> drivers/rtc/interface.c | 15 +++++++++++++--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
>> index 1906f4884a83..f6c5fd16cc4e 100644
>> --- a/drivers/rtc/interface.c
>> +++ b/drivers/rtc/interface.c
>> @@ -927,10 +927,12 @@ static void rtc_timer_remove(struct rtc_device *rtc, struct rtc_timer *timer)
>> */
>> void rtc_timer_do_work(struct work_struct *work)
>> {
>> - struct rtc_timer *timer;
>> + unsigned long start_jiffies = jiffies;
>> struct timerqueue_node *next;
>> - ktime_t now;
>> + struct rtc_timer *timer;
>> struct rtc_time tm;
>> + int loop_count = 0;
>> + ktime_t now;
>> int err;
>>
>> struct rtc_device *rtc =
>> @@ -945,6 +947,15 @@ void rtc_timer_do_work(struct work_struct *work)
>> }
>> now = rtc_tm_to_ktime(tm);
>> while ((next = timerqueue_getnext(&rtc->timerqueue))) {
>> + loop_count++;
>> +
>> + if (unlikely(time_after(jiffies, start_jiffies + HZ))) {
>> + dev_warn(&rtc->dev, "RTC time jump (loop: %d) to %ptR.\n",
>> + loop_count, &tm);
>> + WARN_ON_ONCE(1);
>
> So, your issue is that it is too slow so you make it even slower? There
> are already plenty of tracepoints that allow proper debugging in this
> loop, I'm pretty sure we don't want to bloat the kernel with more
> messages.
Hi, Alexandre,
The point here is not about the performance of the rtc_timer_do_work()
loop — it’s about making the problem debuggable when things go wrong.
And we can put it under a debug Kconfig option, so production kernels
see no extra overhead at all.
The patch is installed in the following scenarios:
If the RTC hardware fails, or if the QEMU-emulated RTC device code in a
KVM virtual machine has a problem (for example, the x86 RTC emulation
hardware mc146818 has an overflow issue[1]), the time may jump as shown
in the log below, which can cause a soft lockup.
However, when the issue occurs, it is only possible to know that too
many pending timers have accumulated in the timerqueue (for example, the
log shows that tens of millions of timer nodes have been processed) by
temporarily adding diagnostic code in rtc_timer_do_work().
To determine whether the root cause is hardware, kernel RTC code, an RTC
driver issue, or an RTC hardware problem, more debugging is needed. But
if the problem is indeed caused by RTC hardware, adding a diagnostic
print of the current RTC time when the loop takes too long (as this
diagnostic patch does) would make it easy to tell whether QEMU or the
hardware is faulty.
[1]: https://lore.kernel.org/all/20260613195116.1807273-21-mjt@tls.msk.ru/
kworker/0:1-37 [000] .N.. 489.159634: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281423
kworker/0:1-37 [000] .N.. 489.159635: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281424
kworker/0:1-37 [000] .N.. 489.159635: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281425
kworker/0:1-37 [000] .N.. 489.159636: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281426
kworker/0:1-37 [000] .N.. 489.159637: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281427
kworker/0:1-37 [000] .N.. 489.159638: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281428
kworker/0:1-37 [000] .N.. 489.159638: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281429
kworker/0:1-37 [000] .N.. 489.159639: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281430
kworker/0:1-37 [000] .N.. 489.159640: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281431
kworker/0:1-37 [000] .N.. 489.159641: rtc_timer_do_work:
timerqueue_getnext handle timer node count: 13281432
swapper/0-1 [001] .N.. 11.579334: __rtc_read_time: rtc:
0xff11000109896800, ops->read_time:2026:01:05:09:36:21
swapper/0-1 [001] .N.. 11.579421: __rtc_read_time: rtc:
0xff11000109896800, ops->read_time:2026:01:05:09:36:21
swapper/0-1 [001] .N.. 11.579469: __rtc_read_time: rtc:
0xff11000109896800, ops->read_time:2026:01:05:09:36:21
swapper/0-1 [001] .N.. 11.580816: __rtc_read_time: rtc:
0xff11000109896800, ops->read_time:2026:01:05:09:36:21
syz-executor.5-7492 [003] .... 129.807406: __rtc_read_time: rtc:
0xff11000109896800, ops->read_time:2033:05:04:07:03:51
syz-executor.5-7492 [003] .... 129.807419:
__rtc_update_irq_enable.part.8: rtc uie on: 0xff11000109896800, now:
2033:05:04:07:03:51, expire: 2033:05:04:07:03:52
Best regards,
Jinjie
>
>
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Jerome Brunet @ 2026-06-15 17:56 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, André Przywara
In-Reply-To: <CAGb2v64euL+QNXiJdTn0JygYLXg0WoguPSprKT4sKGZGVZbwug@mail.gmail.com>
On sam. 28 mars 2026 at 22:41, Chen-Yu Tsai <wens@kernel.org> wrote:
> On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> Add support for the internal CCU found in the RTC module of the Allwinner
>> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
>> with older SoCs like the sun6i, the A733 introduces several new features.
>>
>> The A733 RTC CCU supports choosing one of three external crystal
>> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
>> logic to automatically identify the frequency used on the board and
>> exports this DCXO signal as the "hosc" clock.
>>
>> Furthermore, the driver implements logic to derive a 32kHz reference
>> from the HOSC. This is achieved through a muxed clock path using fixed
>> pre-dividers to normalize the different crystal frequencies to ~32kHz.
>
> Have you tested whether the actually normalizes the frequency, i.e.
> selects a different divider based on the DCXO frequency? Otherwise
> we're just lying about the frequency.
>
>> This path reuses the same hardware mux registers as the HOSC clock.
>>
>> Additionally, this CCU provides several gate clocks for specific
>> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
>> as an auxiliary driver to be bound to the sun6i-rtc driver.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
[...]
>> +};
>> +
>> +static const struct clk_parent_data hosc_parents[] = {
>> + { .fw_name = "osc24M" },
>> + { .fw_name = "osc19M" },
>> + { .fw_name = "osc26M" },
>> + { .fw_name = "osc24M" },
>> +};
>
> As mentioned in my reply to the binding, this is wrong. There is only
> one input.
>
> The most you can do is check the rate of the parent clock against the
> detected one, and _scream_ that the DT is wrong. And maybe override
> the reported frequency.
>
> If you want to do the latter, you could add a new fixed rate gated
> clock type to our library. You would fill in the rate before the
> clocks get registered. I probably wouldn't go that far. We want people
> to have correct hardware descriptions.
>
> Funnily enough Allwinner's BSP actually implements a fixed rate gate
> for the next 24M-to-32k divider clock.
What about implementing the register bellow as a read-only (and
non-cached) divider using the factors provided by Junhui ? That would be
an accurate description of the HW I think.
The oscillator gets set in DT and if the output reported past the
divider is not 32728Hz, you know you've got a problem (bad DT or HW gone
bad)
With a fixed-rate gate, you may actually end up lying about what
actually happen, if the HW does not behave as expected.
Do you prefer a fixed-rate gate still or should I try the RO divider
approach ?
>
>> +
>> +struct ccu_mux hosc_clk = {
>> + .enable = DCXO_CTRL_DCXO_EN,
>> + .mux = _SUNXI_CCU_MUX(14, 2),
>> + .common = {
>> + .reg = DCXO_CTRL_REG,
>> + .hw.init = CLK_HW_INIT_PARENTS_DATA("hosc",
>> + hosc_parents,
>> + &ccu_mux_ro_ops,
>> + 0),
>> + },
>> +};
>
> So this is wrong.
>
>> +
>> +static const struct ccu_mux_fixed_prediv hosc_32k_predivs[] = {
>> + { .index = 0, .div = 732 },
>
> Why is it 732 instead of 750?
>
>> + { .index = 1, .div = 586 },
>> + { .index = 2, .div = 793 },
>> + { .index = 3, .div = 732 },
>> +};
>> +
>> +static struct ccu_mux hosc_32k_mux_clk = {
>> + .enable = DCXO_CTRL_DCXO_EN,
>
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Jerome Brunet @ 2026-06-15 17:46 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree
In-Reply-To: <CAGb2v67844OPwE6VJ0PAs5LsmCa2h0FvXOBUomZ50dM5tZ0Zow@mail.gmail.com>
On sam. 28 mars 2026 at 20:37, Chen-Yu Tsai <wens@kernel.org> wrote:
> On Wed, Jan 21, 2026 at 7:03 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> The RTC module in the Allwinner A733 SoC is functionally compatible with
>> the sun6i RTC, but its internal Clock Control Unit (CCU) has significant
>> changes.
>>
>> The A733 supports selecting the oscillator between three frequencies:
>> 19.2MHz, 24MHz, and 26MHz. The RTC CCU relies on hardware to detect
>> which frequency is actually used on the board. By defining all three
>> frequencies as fixed-clocks in the device tree, the driver can identify
>> the hardware-detected frequency and expose it to the rest of the system.
>
> No. The board device tree shall have the exact and correct frequency
> defined in the external crystal device node. The operating system can
> use the hardware-detected frequency to "fix" the in-system representation
> if it is off.
>
>> Additionally, the A733 RTC CCU provides several new DCXO gate clocks for
>> specific modules, including SerDes, HDMI, and UFS.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
>> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 ++++++++++++++++++++--
>> include/dt-bindings/clock/sun60i-a733-rtc.h | 16 +++++++++
>> 2 files changed, 52 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>> index 9df5cdb6f63f..b18431955783 100644
>> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
>> @@ -26,6 +26,7 @@ properties:
>> - allwinner,sun50i-h6-rtc
>> - allwinner,sun50i-h616-rtc
>> - allwinner,sun50i-r329-rtc
>> + - allwinner,sun60i-a733-rtc
>> - items:
>> - const: allwinner,sun50i-a64-rtc
>> - const: allwinner,sun8i-h3-rtc
>> @@ -46,11 +47,11 @@ properties:
>>
>> clocks:
>> minItems: 1
>> - maxItems: 4
>> + maxItems: 6
>>
>> clock-names:
>> minItems: 1
>> - maxItems: 4
>> + maxItems: 6
>>
>> clock-output-names:
>> minItems: 1
>> @@ -156,6 +157,38 @@ allOf:
>> - clocks
>> - clock-names
>>
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: allwinner,sun60i-a733-rtc
>> +
>> + then:
>> + properties:
>> + clocks:
>> + minItems: 5
>> + items:
>> + - description: Bus clock for register access
>
>> + - description: 19.2 MHz oscillator
>> + - description: 24 MHz oscillator
>> + - description: 26 MHz oscillator
>
> No. There is only one input. As in there is only one set of pins for the
> DCXO. The inputs are the same as on R329 / A523. Just use that list.
>
>> + - description: AHB parent for internal SPI clock
>> + - description: External 32768 Hz oscillator
>> +
>> + clock-names:
>> + minItems: 5
>> + items:
>> + - const: bus
>> + - const: osc19M
>> + - const: osc24M
>> + - const: osc26M
>> + - const: ahb
>> + - const: ext-osc32k
>> +
>> + required:
>> + - clocks
>> + - clock-names
>> +
>> - if:
>> properties:
>> compatible:
>> @@ -164,6 +197,7 @@ allOf:
>> - allwinner,sun8i-r40-rtc
>> - allwinner,sun50i-h616-rtc
>> - allwinner,sun50i-r329-rtc
>> + - allwinner,sun60i-a733-rtc
>>
>> then:
>> properties:
>> diff --git a/include/dt-bindings/clock/sun60i-a733-rtc.h b/include/dt-bindings/clock/sun60i-a733-rtc.h
>> new file mode 100644
>> index 000000000000..8a2b5facad73
>> --- /dev/null
>> +++ b/include/dt-bindings/clock/sun60i-a733-rtc.h
>> @@ -0,0 +1,16 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
>> +
>> +#ifndef _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
>> +#define _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
>> +
>> +#define CLK_IOSC 0
>> +#define CLK_OSC32K 1
>> +#define CLK_HOSC 2
>
> The DCXO enable control has been present since at least the H6. We just
> never added it, as we would never disable it anyway.
>
> If you compare the RTC clock trees of the A733 and A523, the only addition
> besides the new gates seems to be the LOSC auto selection. But even that
> is just an illusion, as the A523 has the same registers for that.
>
> One could say the A733 RTC is almost backward compatible to the A523, if
> not for the two fastboot registers the A523 has at 0x120 and 0x124.
>
> So I ask that you try to integrate the differences into the existing
> driver and bindings. You can tweak and export internal clks if you
> need.
I'd like to help with that. I think it is doable but I have a question
regarding the binding of the existing driver, more precisely their usage
here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c?h=v7.1#n370
Clock indexes are supposed to be stable in DT (AFAIK) but with the code
linked the external 32k is at:
* "ext-32k" - so index 3 - if "clock-names" is present
* index 0 if clock names is not present
... but index 0 is supposed to be the bus clock according the binding
doc, whether "clock-names" is there or not :/
So what are those old r329 bindings ? is there a documentation defining
them somewhere ?
Cleaning that part would help with A733 addition in the existing driver
I think
>
>> +#define CLK_RTC_32K 3
>
> AFAICT besides being an internal clock, this is also fed to GPIO for
> debounce? We probably need to expose this on the A523 as well.
>
>
> Thanks
> ChenYu
>
>
>> +#define CLK_OSC32K_FANOUT 4
>> +#define CLK_HOSC_SERDES1 5
>> +#define CLK_HOSC_SERDES0 6
>> +#define CLK_HOSC_HDMI 7
>> +#define CLK_HOSC_UFS 8
>> +
>> +#endif /* _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_ */
>>
>> --
>> 2.52.0
>>
>>
--
Jerome
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
From: Conor Dooley @ 2026-06-15 16:22 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang, linux-rtc, linux-renesas-soc,
devicetree, linux-kernel, Biju Das, Fabrizio Castro,
Lad Prabhakar
In-Reply-To: <20260615154805.1619693-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add a new compatible string "renesas,r9a09g077-rtc" to the OF match table
to support the RTC IP variant found on the RZ/T2H and RZ/N2H SoCs.
These newer SoCs integrate a closely related variant of the RZ/N1 RTC IP.
The RZ/T2H and RZ/N2H variants lack the RTCA0SUBU and RTCA0TCR registers,
those registers are not accessed or used when operating under the
rzn1_rtc_ops_scmp configurations, making the current infrastructure
compatible.
The RZ/T2H RTC variant also supports a 1 Hz output signal on the
RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
distinct RTC variant despite its overall compatibility with the RZ/N1
implementation.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 9f9cf9882fc4..dfff8dc8c321 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -597,6 +597,7 @@ static int rzn1_rtc_resume(struct device *dev)
static DEFINE_SIMPLE_DEV_PM_OPS(rzn1_rtc_pm_ops, rzn1_rtc_suspend, rzn1_rtc_resume);
static const struct of_device_id rzn1_rtc_of_match[] = {
+ { .compatible = "renesas,r9a09g077-rtc" },
{ .compatible = "renesas,rzn1-rtc" },
{},
};
--
2.54.0
^ permalink raw reply related
* [PATCH 11/12] rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Replace open-coded shift and mask operations with the bitfield API.
Note that the weekday field is changed from an explicit 0x0f mask to
an 8-bit field definition, matching the hardware manual. This does not
change behaviour, as valid weekday values cannot exceed 7.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 46 ++++++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index c7ef3c81180f..9f9cf9882fc4 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -12,6 +12,8 @@
*/
#include <linux/bcd.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
#include <linux/clk.h>
#include <linux/init.h>
#include <linux/iopoll.h>
@@ -40,14 +42,18 @@
#define RZN1_RTC_CTL2_STOPPED (RZN1_RTC_CTL2_WAIT | RZN1_RTC_CTL2_WST)
#define RZN1_RTC_TIME 0x30
-#define RZN1_RTC_TIME_MIN_SHIFT 8
-#define RZN1_RTC_TIME_HOUR_SHIFT 16
+#define RZN1_RTC_TIME_SEC GENMASK(7, 0)
+#define RZN1_RTC_TIME_MIN GENMASK(15, 8)
+#define RZN1_RTC_TIME_HOUR GENMASK(23, 16)
+
#define RZN1_RTC_CAL 0x34
-#define RZN1_RTC_CAL_DAY_SHIFT 8
-#define RZN1_RTC_CAL_MON_SHIFT 16
-#define RZN1_RTC_CAL_YEAR_SHIFT 24
+#define RZN1_RTC_CAL_WDAY GENMASK(7, 0)
+#define RZN1_RTC_CAL_DAY GENMASK(15, 8)
+#define RZN1_RTC_CAL_MON GENMASK(23, 16)
+#define RZN1_RTC_CAL_YEAR GENMASK(31, 24)
#define RZN1_RTC_SUBU 0x38
+#define RZN1_RTC_SUBU_RTCA0FX GENMASK(5, 0)
#define RZN1_RTC_SUBU_DEV BIT(7)
#define RZN1_RTC_SUBU_DECR BIT(6)
@@ -82,15 +88,15 @@ static void rzn1_rtc_get_time_snapshot(struct rzn1_rtc *rtc, struct rtc_time *tm
u32 val;
val = readl(rtc->base + RZN1_RTC_TIMEC);
- tm->tm_sec = bcd2bin(val);
- tm->tm_min = bcd2bin(val >> RZN1_RTC_TIME_MIN_SHIFT);
- tm->tm_hour = bcd2bin(val >> RZN1_RTC_TIME_HOUR_SHIFT);
+ tm->tm_sec = bcd2bin(FIELD_GET(RZN1_RTC_TIME_SEC, val));
+ tm->tm_min = bcd2bin(FIELD_GET(RZN1_RTC_TIME_MIN, val));
+ tm->tm_hour = bcd2bin(FIELD_GET(RZN1_RTC_TIME_HOUR, val));
val = readl(rtc->base + RZN1_RTC_CALC);
- tm->tm_wday = val & 0x0f;
- tm->tm_mday = bcd2bin(val >> RZN1_RTC_CAL_DAY_SHIFT);
- tm->tm_mon = bcd2bin(val >> RZN1_RTC_CAL_MON_SHIFT) - 1;
- tm->tm_year = bcd2bin(val >> RZN1_RTC_CAL_YEAR_SHIFT) + 100;
+ tm->tm_wday = FIELD_GET(RZN1_RTC_CAL_WDAY, val);
+ tm->tm_mday = bcd2bin(FIELD_GET(RZN1_RTC_CAL_DAY, val));
+ tm->tm_mon = bcd2bin(FIELD_GET(RZN1_RTC_CAL_MON, val)) - 1;
+ tm->tm_year = bcd2bin(FIELD_GET(RZN1_RTC_CAL_YEAR, val)) + 100;
}
static int rzn1_rtc_read_time(struct device *dev, struct rtc_time *tm)
@@ -133,15 +139,15 @@ static int rzn1_rtc_set_time(struct device *dev, struct rtc_time *tm)
return ret;
}
- val = bin2bcd(tm->tm_sec);
- val |= bin2bcd(tm->tm_min) << RZN1_RTC_TIME_MIN_SHIFT;
- val |= bin2bcd(tm->tm_hour) << RZN1_RTC_TIME_HOUR_SHIFT;
+ val = FIELD_PREP(RZN1_RTC_TIME_SEC, bin2bcd(tm->tm_sec)) |
+ FIELD_PREP(RZN1_RTC_TIME_MIN, bin2bcd(tm->tm_min)) |
+ FIELD_PREP(RZN1_RTC_TIME_HOUR, bin2bcd(tm->tm_hour));
writel(val, rtc->base + RZN1_RTC_TIME);
- val = tm->tm_wday;
- val |= bin2bcd(tm->tm_mday) << RZN1_RTC_CAL_DAY_SHIFT;
- val |= bin2bcd(tm->tm_mon + 1) << RZN1_RTC_CAL_MON_SHIFT;
- val |= bin2bcd(tm->tm_year - 100) << RZN1_RTC_CAL_YEAR_SHIFT;
+ val = FIELD_PREP(RZN1_RTC_CAL_WDAY, tm->tm_wday) |
+ FIELD_PREP(RZN1_RTC_CAL_DAY, bin2bcd(tm->tm_mday)) |
+ FIELD_PREP(RZN1_RTC_CAL_MON, bin2bcd(tm->tm_mon + 1)) |
+ FIELD_PREP(RZN1_RTC_CAL_YEAR, bin2bcd(tm->tm_year - 100));
writel(val, rtc->base + RZN1_RTC_CAL);
writel(0, rtc->base + RZN1_RTC_CTL2);
@@ -306,7 +312,7 @@ static int rzn1_rtc_read_offset(struct device *dev, long *offset)
val = readl(rtc->base + RZN1_RTC_SUBU);
ppb_per_step = val & RZN1_RTC_SUBU_DEV ? 1017 : 3051;
subtract = val & RZN1_RTC_SUBU_DECR;
- val &= 0x3F;
+ val = FIELD_GET(RZN1_RTC_SUBU_RTCA0FX, val);
if (!val)
*offset = 0;
--
2.54.0
^ permalink raw reply related
* [PATCH 10/12] rtc: rzn1: Consistently use dev_err_probe()
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Use dev_err_probe() in the IRQ request error path to make error handling
consistent with the rest of rzn1_rtc_probe().
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 25cad9213147..c7ef3c81180f 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -477,7 +477,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
ret = devm_request_irq(dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
if (ret) {
- dev_err(dev, "RTC alarm interrupt not available\n");
+ dev_err_probe(dev, ret, "RTC alarm interrupt not available\n");
goto dis_runtime_pm;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 09/12] rtc: rzn1: Use temporary variable for struct device
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Use a temporary variable for the struct device pointers to avoid
dereferencing.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index bc6af59744e4..25cad9213147 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -386,13 +386,14 @@ static const struct rtc_class_ops rzn1_rtc_ops_scmp = {
static int rzn1_rtc_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct rzn1_rtc *rtc;
u32 val, scmp_val = 0;
struct clk *xtal;
unsigned long rate;
int irq, ret;
- rtc = devm_kzalloc(&pdev->dev, sizeof(*rtc), GFP_KERNEL);
+ rtc = devm_kzalloc(dev, sizeof(*rtc), GFP_KERNEL);
if (!rtc)
return -ENOMEM;
@@ -400,14 +401,14 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
rtc->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(rtc->base))
- return dev_err_probe(&pdev->dev, PTR_ERR(rtc->base), "Missing reg\n");
+ return dev_err_probe(dev, PTR_ERR(rtc->base), "Missing reg\n");
irq = platform_get_irq_byname(pdev, "alarm");
if (irq < 0)
return irq;
rtc->alarm_irq = irq;
- rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
+ rtc->rtcdev = devm_rtc_allocate_device(dev);
if (IS_ERR(rtc->rtcdev))
return PTR_ERR(rtc->rtcdev);
@@ -415,15 +416,15 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
rtc->rtcdev->range_max = RTC_TIMESTAMP_END_2099;
rtc->rtcdev->alarm_offset_max = 7 * 86400;
- ret = devm_pm_runtime_enable(&pdev->dev);
+ ret = devm_pm_runtime_enable(dev);
if (ret < 0)
return ret;
- ret = pm_runtime_resume_and_get(&pdev->dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0)
return ret;
/* Only switch to scmp if we have an xtal clock with a valid rate and != 32768 */
- xtal = devm_clk_get_optional(&pdev->dev, "xtal");
+ xtal = devm_clk_get_optional(dev, "xtal");
if (IS_ERR(xtal)) {
ret = PTR_ERR(xtal);
goto dis_runtime_pm;
@@ -474,9 +475,9 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
spin_lock_init(&rtc->ctl1_access_lock);
- ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
+ ret = devm_request_irq(dev, irq, rzn1_rtc_alarm_irq, 0, "RZN1 RTC Alarm", rtc);
if (ret) {
- dev_err(&pdev->dev, "RTC alarm interrupt not available\n");
+ dev_err(dev, "RTC alarm interrupt not available\n");
goto dis_runtime_pm;
}
@@ -486,18 +487,18 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
goto dis_runtime_pm;
}
if (irq >= 0)
- ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
+ ret = devm_request_irq(dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
if (irq < 0 || ret) {
set_bit(RTC_FEATURE_ALARM_RES_MINUTE, rtc->rtcdev->features);
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->rtcdev->features);
- dev_warn(&pdev->dev, "RTC pps interrupt not available. Alarm has only minute accuracy\n");
+ dev_warn(dev, "RTC pps interrupt not available. Alarm has only minute accuracy\n");
rtc->sec_irq = -ENXIO;
} else {
rtc->sec_irq = irq;
}
- device_init_wakeup(&pdev->dev, true);
+ device_init_wakeup(dev, true);
ret = devm_rtc_register_device(rtc->rtcdev);
if (ret)
@@ -506,7 +507,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
return 0;
dis_runtime_pm:
- pm_runtime_put(&pdev->dev);
+ pm_runtime_put(dev);
return ret;
}
--
2.54.0
^ permalink raw reply related
* [PATCH 08/12] rtc: rzn1: Dynamically calculate synchronization delay based on clock rate
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Replace the hardcoded hardware synchronization delays with a calculated
time window derived from the operating sub-clock frequency.
The driver currently hardcodes microsecond ranges assuming a fixed
sub-clock frequency of 32.768 kHz. Newer SoC variants, such as the
RZ/T2H, drive this hardware block using a much faster clock rate
(~195.3 kHz). Hardcoding these wait windows forces faster blocks to
over-sleep, introducing unnecessary delays during clock initialization
and register configuration.
Calculate the duration of the required clock cycles in microseconds based
on the runtime clock rate, and store this value in the driver private
structure to adjust the usleep_range() and readl_poll_timeout() boundaries
dynamically.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 06339adae71f..bc6af59744e4 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -71,6 +71,7 @@ struct rzn1_rtc {
*/
spinlock_t ctl1_access_lock;
struct rtc_time tm_alarm;
+ unsigned long sync_time;
int alarm_irq;
int sec_irq;
bool alarm_enabled;
@@ -124,8 +125,8 @@ static int rzn1_rtc_set_time(struct device *dev, struct rtc_time *tm)
/* Hold the counter if it was counting up */
writel(RZN1_RTC_CTL2_WAIT, rtc->base + RZN1_RTC_CTL2);
- /* Wait for the counter to stop: two 32k clock cycles */
- usleep_range(61, 100);
+ /* Wait for the counter to stop: two RTC_PCLK clock cycles */
+ usleep_range(rtc->sync_time, rtc->sync_time + 100);
ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL2, val,
val & RZN1_RTC_CTL2_WST, 0, 100);
if (ret)
@@ -433,17 +434,25 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
ret = -EOPNOTSUPP;
goto dis_runtime_pm;
}
-
if (rate != 32768)
scmp_val = RZN1_RTC_CTL0_SLSB_SCMP;
+
+ /*
+ * The internal clock counter operates in synchronization with the
+ * RTC_PCLK clock. Calculate the duration of two RTC_PCLK clock
+ * cycles in microseconds required for operations to complete.
+ */
+ rtc->sync_time = DIV_ROUND_UP(2 * NSEC_PER_MSEC, rate);
+
}
/* Disable controller during SUBU/SCMP setup */
val = readl(rtc->base + RZN1_RTC_CTL0) & ~RZN1_RTC_CTL0_CE;
writel(val, rtc->base + RZN1_RTC_CTL0);
- /* Wait 2-4 32k clock cycles for the disabled controller */
+ /* Wait 2-4 RTC_PCLK clock cycles for the disabled controller to stop */
ret = readl_poll_timeout(rtc->base + RZN1_RTC_CTL0, val,
- !(val & RZN1_RTC_CTL0_CEST), 62, 123);
+ !(val & RZN1_RTC_CTL0_CEST), rtc->sync_time,
+ rtc->sync_time * 2);
if (ret)
goto dis_runtime_pm;
--
2.54.0
^ permalink raw reply related
* [PATCH 06/12] rtc: rzn1: Sort headers alphabetically
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Sorting headers alphabetically helps locating duplicates, and make it
easier to figure out where to insert new headers.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 12a319e9112c..fe21fa624288 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -15,8 +15,8 @@
#include <linux/clk.h>
#include <linux/init.h>
#include <linux/iopoll.h>
-#include <linux/module.h>
#include <linux/mod_devicetable.h>
+#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/rtc.h>
--
2.54.0
^ permalink raw reply related
* [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Prabhakar @ 2026-06-15 15:48 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
alarm and farest were declared as unsigned long, but
rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
unsigned long is 32 bits, the assignment silently truncates the upper
32 bits of the timestamp.
Fix by declaring alarm and farest as time64_t and replacing
time_after() with a direct signed comparison, which is correct for
time64_t values that will never realistically overflow.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index fe21fa624288..06339adae71f 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -21,6 +21,7 @@
#include <linux/pm_runtime.h>
#include <linux/rtc.h>
#include <linux/spinlock.h>
+#include <linux/time64.h>
#define RZN1_RTC_CTL0 0x00
#define RZN1_RTC_CTL0_SLSB_SCMP BIT(4)
@@ -265,8 +266,8 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
{
struct rzn1_rtc *rtc = dev_get_drvdata(dev);
struct rtc_time *tm = &alrm->time, tm_now;
- unsigned long alarm, farest;
unsigned int days_ahead, wday;
+ time64_t alarm, farest;
int ret;
ret = rzn1_rtc_read_time(dev, &tm_now);
@@ -276,7 +277,7 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
/* We cannot set alarms more than one week ahead */
farest = rtc_tm_to_time64(&tm_now) + rtc->rtcdev->alarm_offset_max;
alarm = rtc_tm_to_time64(tm);
- if (time_after(alarm, farest))
+ if (alarm > farest)
return -ERANGE;
/* Convert alarm day into week day */
--
2.54.0
^ permalink raw reply related
* [PATCH 05/12] rtc: rzn1: Add system suspend/resume support and wakeup capability
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add system-wide power management support along with wakeup capability to
the rtc-rzn1 driver.
The hardware alarm module inside this RTC variant lacks a dedicated seconds
match register, meaning native hardware alarms can only be programmed with
minute-level granularity. For awake states, the driver bridges sub-minute
gaps by switching from a standard alarm interrupt (ALME) to a 1-second
periodic broadcast loop (1SE).
To support device wakeup from low-power states, initialize the device as a
system wakeup source during probe and configure both the hardware alarm IRQ
and the 1-second periodic IRQ as wakeup sources via enable_irq_wake() in the
suspend path. Because of hardware tracking design constraints across the
internal timer blocks, precise point-in-time wakeup alignment cannot be
guaranteed. Emit an explicit warning message during system suspend to notify
the user of this architectural layout limitation.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 80 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 866ff595188d..12a319e9112c 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -70,6 +70,9 @@ struct rzn1_rtc {
*/
spinlock_t ctl1_access_lock;
struct rtc_time tm_alarm;
+ int alarm_irq;
+ int sec_irq;
+ bool alarm_enabled;
};
static void rzn1_rtc_get_time_snapshot(struct rzn1_rtc *rtc, struct rtc_time *tm)
@@ -219,6 +222,8 @@ static int rzn1_rtc_alarm_irq_enable(struct device *dev, unsigned int enable)
writel(ctl1, rtc->base + RZN1_RTC_CTL1);
}
+ rtc->alarm_enabled = enable;
+
return 0;
}
@@ -398,6 +403,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
irq = platform_get_irq_byname(pdev, "alarm");
if (irq < 0)
return irq;
+ rtc->alarm_irq = irq;
rtc->rtcdev = devm_rtc_allocate_device(&pdev->dev);
if (IS_ERR(rtc->rtcdev))
@@ -476,8 +482,13 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
set_bit(RTC_FEATURE_ALARM_RES_MINUTE, rtc->rtcdev->features);
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->rtcdev->features);
dev_warn(&pdev->dev, "RTC pps interrupt not available. Alarm has only minute accuracy\n");
+ rtc->sec_irq = -ENXIO;
+ } else {
+ rtc->sec_irq = irq;
}
+ device_init_wakeup(&pdev->dev, true);
+
ret = devm_rtc_register_device(rtc->rtcdev);
if (ret)
goto dis_runtime_pm;
@@ -500,6 +511,74 @@ static void rzn1_rtc_remove(struct platform_device *pdev)
pm_runtime_put(&pdev->dev);
}
+static int rzn1_rtc_suspend(struct device *dev)
+{
+ struct rzn1_rtc *rtc = dev_get_drvdata(dev);
+ int ret;
+
+ if (!device_may_wakeup(dev))
+ return 0;
+
+ /*
+ * Note on HW Wakeup Granularity Limitations:
+ * True second-level accuracy cannot be guaranteed for device wakeups due
+ * to hardware design tracking limitations across the three available blocks:
+ * - Alarm Interrupt (RTC_ALM): Only matches on day-of-week, hour, and minute.
+ * It completely lacks a seconds comparator field.
+ * - 1-Second Interrupt (RTC_1S): A free-running broadcast that fires every
+ * second. Activating it as a wakeup source triggers an immediate resume
+ * on the very next 1-second boundary, bypassing target accuracy.
+ * - Fixed Interval Interrupt (RTC_PRD): Periodic broadcast options (0.25s,
+ * 0.5s, 1s, 1min, 1hr, 1day, or 1month) lack point-in-time matching,
+ * offering no targeted relief.
+ *
+ * Consequently, due to the absence of a seconds comparator, if a wakeup is
+ * requested within the current minute, the system will resume on the very next
+ * 1-second tick regardless of the actual target alarm time. When the alarm
+ * target is scheduled for a future minute, the system will resume early at the
+ * start of that target minute boundary (00 seconds), failing to guarantee
+ * second-level accuracy for the initial hardware wakeup event.
+ */
+ if (rtc->alarm_enabled)
+ dev_crit(dev, "second/minute-level wakeup accuracy cannot be guaranteed by HW\n");
+ ret = enable_irq_wake(rtc->alarm_irq);
+ if (ret)
+ return ret;
+ if (rtc->sec_irq >= 0) {
+ ret = enable_irq_wake(rtc->sec_irq);
+ if (ret) {
+ disable_irq_wake(rtc->alarm_irq);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static int rzn1_rtc_resume(struct device *dev)
+{
+ struct rzn1_rtc *rtc = dev_get_drvdata(dev);
+ int ret;
+
+ if (!device_may_wakeup(dev))
+ return 0;
+
+ ret = disable_irq_wake(rtc->alarm_irq);
+ if (ret)
+ return ret;
+ if (rtc->sec_irq >= 0) {
+ ret = disable_irq_wake(rtc->sec_irq);
+ if (ret) {
+ enable_irq_wake(rtc->alarm_irq);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(rzn1_rtc_pm_ops, rzn1_rtc_suspend, rzn1_rtc_resume);
+
static const struct of_device_id rzn1_rtc_of_match[] = {
{ .compatible = "renesas,rzn1-rtc" },
{},
@@ -512,6 +591,7 @@ static struct platform_driver rzn1_rtc_driver = {
.driver = {
.name = "rzn1-rtc",
.of_match_table = rzn1_rtc_of_match,
+ .pm = pm_ptr(&rzn1_rtc_pm_ops),
},
};
module_platform_driver(rzn1_rtc_driver);
--
2.54.0
^ permalink raw reply related
* [PATCH 04/12] rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Replace the ARCH_RZN1 dependency with ARCH_RENESAS for the RTC_DRV_RZN1
config option to make the driver available across both ARM32 and ARM64
Renesas architectures.
The newer RZ/T2H and RZ/N2H ARM64 SoCs integrate a closely related variant
of the RTC IP block found on the RZ/N1 SoCs. Update the build dependency
and expand the Kconfig help text to allow this driver to be selected for
these additional platforms.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 364afc73f8ab..764f8b9ff742 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1635,10 +1635,11 @@ config RTC_DRV_RS5C313
config RTC_DRV_RZN1
tristate "Renesas RZ/N1 RTC"
- depends on ARCH_RZN1 || COMPILE_TEST
+ depends on ARCH_RENESAS || COMPILE_TEST
depends on OF && HAS_IOMEM
help
- If you say yes here you get support for the Renesas RZ/N1 RTC.
+ If you say yes here you get support for the RTC found on Renesas RZ/N1,
+ RZ/N2H, and RZ/T2H SoCs.
config RTC_DRV_GENERIC
tristate "Generic RTC support"
--
2.54.0
^ permalink raw reply related
* [PATCH 03/12] rtc: rzn1: Fix malformed MODULE_AUTHOR string
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Fix a malformed MODULE_AUTHOR macro in the rtc-rzn1 driver where a missing
closing angle bracket on the second author entry creates an invalid format.
Correct it to the standard "Name <email>" format.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index f81d691c8b9a..866ff595188d 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -517,6 +517,6 @@ static struct platform_driver rzn1_rtc_driver = {
module_platform_driver(rzn1_rtc_driver);
MODULE_AUTHOR("Michel Pollet <buserror@gmail.com>");
-MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com");
+MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
MODULE_DESCRIPTION("RZ/N1 RTC driver");
MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH 02/12] rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar, stable
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Check for -EPROBE_DEFER from platform_get_irq_byname_optional() and handle
the deferred probe request properly.
Although the "pps" interrupt is optional, an error code of -EPROBE_DEFER
indicates that the interrupt subsystem is not yet ready. Intercept this
specific error condition, assign it to the return value, and jump to the
dis_runtime_pm label to avoid ignoring a valid probe deferral.
Fixes: eea7791e00f33 ("rtc: rzn1: implement one-second accuracy for alarms")
Cc: stable@vger.kernel.org
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
drivers/rtc/rtc-rzn1.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index c4ed43735457..f81d691c8b9a 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -465,6 +465,10 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
}
irq = platform_get_irq_byname_optional(pdev, "pps");
+ if (irq == -EPROBE_DEFER) {
+ ret = irq;
+ goto dis_runtime_pm;
+ }
if (irq >= 0)
ret = devm_request_irq(&pdev->dev, irq, rzn1_rtc_1s_irq, 0, "RZN1 RTC 1s", rtc);
--
2.54.0
^ permalink raw reply related
* [PATCH 01/12] dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add compatible strings for the RTC block found on the Renesas RZ/T2H
(R9A09G077) and RZ/N2H (R9A09G087) SoCs.
These SoCs integrate a closely related variant of the RZ/N1 RTC IP.
Unlike RZ/N1, they do not implement the RTCA0SUBU and RTCA0TCR
registers. This is not a limitation for Linux support, as these
registers are not used when the RTC operates in "scmp" clock mode, which
is required on RZ/T2H and RZ/N2H due to their 195.3 kHz input clock.
The RZ/T2H RTC variant also supports a 1Hz output signal on the
RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
marked as reserved in the RZ/N1 hardware manual.
Update the binding schema to require the additional clock inputs used by
these SoCs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
.../bindings/rtc/renesas,rzn1-rtc.yaml | 35 +++++++++++++++----
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
index 1860f0e4c31a..ea7b039a91e7 100644
--- a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml
@@ -9,15 +9,19 @@ title: Renesas RZ/N1 SoCs Real-Time Clock
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
-allOf:
- - $ref: rtc.yaml#
-
properties:
compatible:
- items:
- - enum:
- - renesas,r9a06g032-rtc
- - const: renesas,rzn1-rtc
+ oneOf:
+ - items:
+ - enum:
+ - renesas,r9a06g032-rtc
+ - const: renesas,rzn1-rtc
+
+ - const: renesas,r9a09g077-rtc
+
+ - items:
+ - const: renesas,r9a09g087-rtc
+ - const: renesas,r9a09g077-rtc
reg:
maxItems: 1
@@ -54,6 +58,23 @@ required:
- clock-names
- power-domains
+allOf:
+ - $ref: rtc.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,r9a09g077-rtc
+ - renesas,r9a09g087-rtc
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
unevaluatedProperties: false
examples:
--
2.54.0
^ permalink raw reply related
* [PATCH 00/12] Add RTC support for Renesas RZ/T2H and RZ/N2H SoCs
From: Prabhakar @ 2026-06-15 15:47 UTC (permalink / raw)
To: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang
Cc: linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Prabhakar,
Biju Das, Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi all,
This series adds support for the RTC IP found on the Renesas RZ/T2H and
RZ/N2H SoCs.
The RTC block is closely related to the RZ/N1 implementation and can
reuse the existing driver infrastructure when operating in SCMP mode,
which is required on these SoCs due to their 195.3 kHz RTC input clock.
While the RZ/T2H and RZ/N2H variants do not implement the RTCA0SUBU and
RTCA0TCR registers present on RZ/N1, those registers are not accessed by
the driver in SCMP mode, allowing support to be added with minimal
changes.
The RZ/T2H RTC variant also supports a 1 Hz output signal on the
RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
distinct RTC variant despite its overall compatibility with the RZ/N1
implementation.
The series consists of:
dt-bindings updates to describe the RZ/T2H and RZ/N2H RTC variants,
driver updates to recognize the new compatible string and enable
support for these SoCs.
Cheers,
Prabhakar
Lad Prabhakar (12):
dt-bindings: rtc: renesas,rzn1-rtc: Add RZ/T2H and RZ/N2H support
rtc: rzn1: Handle EPROBE_DEFER for optional pps interrupt
rtc: rzn1: Fix malformed MODULE_AUTHOR string
rtc: Kconfig: Broaden RTC_DRV_RZN1 dependency to ARCH_RENESAS
rtc: rzn1: Add system suspend/resume support and wakeup capability
rtc: rzn1: Sort headers alphabetically
rtc: rzn1: fix alarm range check truncation on 32-bit systems
rtc: rzn1: Dynamically calculate synchronization delay based on clock
rate
rtc: rzn1: Use temporary variable for struct device
rtc: rzn1: Consistently use dev_err_probe()
rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
.../bindings/rtc/renesas,rzn1-rtc.yaml | 35 +++-
drivers/rtc/Kconfig | 5 +-
drivers/rtc/rtc-rzn1.c | 182 ++++++++++++++----
3 files changed, 173 insertions(+), 49 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH] rtc: interface: Add rtc time jump debug in rtc_timer_do_work()
From: Alexandre Belloni @ 2026-06-15 15:22 UTC (permalink / raw)
To: Jinjie Ruan; +Cc: linux-rtc, linux-kernel
In-Reply-To: <20260525130825.954214-1-ruanjinjie@huawei.com>
Hello,
On 25/05/2026 21:08:25+0800, Jinjie Ruan wrote:
> In virtualization environments like QEMU [1], or during hardware
> clocksource anomalies, an extreme time-warp event can occur. When
> the system time abruptly jumps forward, the rtc_timer_do_work() handler
> falls into a prolonged processing loop to clear accumulated historical
> timers via timerqueue_getnext(). Running this loop indefinitely under
> the rtc->ops_lock mutex triggers a kernel softlockup, stalling
> the system.
>
> Introduce an adaptive telemetry and loop guard mechanism to enhance debug
> visibility and prevent softlockups:
>
> 1. Record `start_jiffies` upon entry and leverage `time_after()` to
> check if the loop has monopolized the CPU for more than 1s (HZ). If so,
> the handler prints a telemetry warning, triggers a WARN stack dump, and
> breaks the loop to safely yield the CPU.
>
> 2. Track the execution via a `loop_count` metric. Printing this counter
> in the warning log provides vital diagnostics to distinguish
> an aggressive time-warp storm (high count) from a bogged-down callback
> bug (low count).
>
> 3. Utilize the kernel format specifier `%ptR` to convert the raw ktime
> into a human-readable timestamp (YYYY-MM-DD HH:MM:SS), allowing
> developers to instantly pinpoint the exact boundary of the time
> jump in dmesg.
>
> This non-destructive telemetry guard provides precise hardware/emulator
> diagnostic visibility while ensuring core kernel availability.
>
> [1]: https://lore.kernel.org/all/20260114013257.3500578-1-ruanjinjie@huawei.com/
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> drivers/rtc/interface.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index 1906f4884a83..f6c5fd16cc4e 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -927,10 +927,12 @@ static void rtc_timer_remove(struct rtc_device *rtc, struct rtc_timer *timer)
> */
> void rtc_timer_do_work(struct work_struct *work)
> {
> - struct rtc_timer *timer;
> + unsigned long start_jiffies = jiffies;
> struct timerqueue_node *next;
> - ktime_t now;
> + struct rtc_timer *timer;
> struct rtc_time tm;
> + int loop_count = 0;
> + ktime_t now;
> int err;
>
> struct rtc_device *rtc =
> @@ -945,6 +947,15 @@ void rtc_timer_do_work(struct work_struct *work)
> }
> now = rtc_tm_to_ktime(tm);
> while ((next = timerqueue_getnext(&rtc->timerqueue))) {
> + loop_count++;
> +
> + if (unlikely(time_after(jiffies, start_jiffies + HZ))) {
> + dev_warn(&rtc->dev, "RTC time jump (loop: %d) to %ptR.\n",
> + loop_count, &tm);
> + WARN_ON_ONCE(1);
So, your issue is that it is too slow so you make it even slower? There
are already plenty of tracepoints that allow proper debugging in this
loop, I'm pretty sure we don't want to bloat the kernel with more
messages.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] selftests: rtc: fix flaky date_read_loop test
From: Alexandre Belloni @ 2026-06-15 15:01 UTC (permalink / raw)
To: Wake Liu; +Cc: Shuah Khan, linux-rtc, linux-kselftest, linux-kernel
In-Reply-To: <20260430120313.4078185-1-wakel@google.com>
On 30/04/2026 20:03:13+0800, Wake Liu wrote:
> The test case rtc.date_read_loop in rtctest.c fails intermittently because
> it checks that the RTC time does not advance by more than 1 second per loop
> iteration. However, the loop sleeps for 11ms via nanosleep(), and if the
> test thread is descheduled by the OS scheduler (e.g., under heavy system
> load in a VM), more than 1 second can elapse between consecutive RTC reads.
> This causes the next RTC time read to be 2 or more seconds ahead of the
> previous read, triggering a test assertion failure.
>
> To make the test more resilient against OS scheduling delays, measure the
> real elapsed time between iterations using a monotonic clock
> (clock_gettime(CLOCK_MONOTONIC)), and compute the actual number of seconds
> elapsed (delta_s) between consecutive RTC reads. Then dynamically adjust
> the assertion to:
> ASSERT_GE(prev_rtc_read + delta_s + 1, rtc_read);
>
> Signed-off-by: Wake Liu <wakel@google.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> tools/testing/selftests/rtc/rtctest.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/rtc/rtctest.c b/tools/testing/selftests/rtc/rtctest.c
> index 8047d9879039..54eb5c255a45 100644
> --- a/tools/testing/selftests/rtc/rtctest.c
> +++ b/tools/testing/selftests/rtc/rtctest.c
> @@ -116,6 +116,7 @@ TEST_F_TIMEOUT(rtc, date_read_loop, READ_LOOP_DURATION_SEC + 2) {
> long iter_count = 0;
> struct rtc_time rtc_tm;
> time_t start_rtc_read, prev_rtc_read;
> + struct timespec prev_mono, cur_mono;
>
> if (self->fd == -1 && errno == ENOENT)
> SKIP(return, "Skipping test since %s does not exist", rtc_file);
> @@ -126,25 +127,31 @@ TEST_F_TIMEOUT(rtc, date_read_loop, READ_LOOP_DURATION_SEC + 2) {
>
> rc = ioctl(self->fd, RTC_RD_TIME, &rtc_tm);
> ASSERT_NE(-1, rc);
> + clock_gettime(CLOCK_MONOTONIC, &prev_mono);
> start_rtc_read = rtc_time_to_timestamp(&rtc_tm);
> prev_rtc_read = start_rtc_read;
>
> do {
> time_t rtc_read;
> + time_t delta_s = 0;
>
> rc = ioctl(self->fd, RTC_RD_TIME, &rtc_tm);
> ASSERT_NE(-1, rc);
> + clock_gettime(CLOCK_MONOTONIC, &cur_mono);
>
> rtc_read = rtc_time_to_timestamp(&rtc_tm);
> + delta_s = cur_mono.tv_sec - prev_mono.tv_sec;
> +
> /* Time should not go backwards */
> ASSERT_LE(prev_rtc_read, rtc_read);
> - /* Time should not increase more then 1s at a time */
> - ASSERT_GE(prev_rtc_read + 1, rtc_read);
> + /* Time should not increase more then elapsed time + 1s */
> + ASSERT_GE(prev_rtc_read + delta_s + 1, rtc_read);
>
> /* Sleep 11ms to avoid killing / overheating the RTC */
> nanosleep_with_retries(READ_LOOP_SLEEP_MS * 1000000);
>
> prev_rtc_read = rtc_read;
> + prev_mono = cur_mono;
> iter_count++;
> } while (prev_rtc_read <= start_rtc_read + READ_LOOP_DURATION_SEC);
>
> --
> 2.54.0.545.g6539524ca2-goog
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-15 11:53 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 SPI controller devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v1:
- Rename schema file to microchip,pic32mzda-spi.yaml
- Update subject prefix to match SPI DT binding conventions
Link to v1: https://lore.kernel.org/all/20260614175005.435826-1-challauday369@gmail.com/
---
.../bindings/spi/microchip,pic32mzda-spi.yaml | 78 +++++++++++++++++++
.../bindings/spi/microchip,spi-pic32.txt | 34 --------
2 files changed, 78 insertions(+), 34 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
diff --git a/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
new file mode 100644
index 000000000000..a0a182cdccbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/microchip,pic32mzda-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA SPI Controller
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: Fault interrupt
+ - description: Receive interrupt
+ - description: Transmit interrupt
+
+ interrupt-names:
+ items:
+ - const: fault
+ - const: rx
+ - const: tx
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: mck0
+
+ dmas:
+ items:
+ - description: RX DMA channel
+ - description: TX DMA channel
+
+ dma-names:
+ items:
+ - const: spi-rx
+ - const: spi-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi@1f821000 {
+ compatible = "microchip,pic32mzda-spi";
+ reg = <0x1f821000 0x200>;
+ interrupts = <109 IRQ_TYPE_LEVEL_HIGH>,
+ <110 IRQ_TYPE_LEVEL_HIGH>,
+ <111 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "fault", "rx", "tx";
+ clocks = <&PBCLK2>;
+ clock-names = "mck0";
+ cs-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
+ dmas = <&dma 134>, <&dma 135>;
+ dma-names = "spi-rx", "spi-tx";
+ };
diff --git a/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt b/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
deleted file mode 100644
index 79de379f4dc0..000000000000
--- a/Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Microchip PIC32 SPI Master controller
-
-Required properties:
-- compatible: Should be "microchip,pic32mzda-spi".
-- reg: Address and length of register space for the device.
-- interrupts: Should contain all three spi interrupts in sequence
- of <fault-irq>, <receive-irq>, <transmit-irq>.
-- interrupt-names: Should be "fault", "rx", "tx" in order.
-- clocks: Phandle of the clock generating SPI clock on the bus.
-- clock-names: Should be "mck0".
-- cs-gpios: Specifies the gpio pins to be used for chipselects.
- See: Documentation/devicetree/bindings/spi/spi-bus.txt
-
-Optional properties:
-- dmas: Two or more DMA channel specifiers following the convention outlined
- in Documentation/devicetree/bindings/dma/dma.txt
-- dma-names: Names for the dma channels. There must be at least one channel
- named "spi-tx" for transmit and named "spi-rx" for receive.
-
-Example:
-
-spi1: spi@1f821000 {
- compatible = "microchip,pic32mzda-spi";
- reg = <0x1f821000 0x200>;
- interrupts = <109 IRQ_TYPE_LEVEL_HIGH>,
- <110 IRQ_TYPE_LEVEL_HIGH>,
- <111 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "fault", "rx", "tx";
- clocks = <&PBCLK2>;
- clock-names = "mck0";
- cs-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
- dmas = <&dma 134>, <&dma 135>;
- dma-names = "spi-rx", "spi-tx";
-};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: spi: microchip,pic32: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-15 6:53 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260614175005.435826-1-challauday369@gmail.com>
On Sun, Jun 14, 2026 at 11:20:05PM +0530, Udaya Kiran Challa wrote:
> Convert Microchip PIC32 SPI controller devicetree binding
> from legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
Please use subject prefixes matching the subsystem. You can get them for
example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
spi: dt-bindings:
> .../bindings/spi/microchip,pic32-spi.yaml | 78 +++++++++++++++++++
> .../bindings/spi/microchip,spi-pic32.txt | 34 --------
> 2 files changed, 78 insertions(+), 34 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/spi/microchip,pic32-spi.yaml
Use compatible as filename (and don't forget to test binding after
renaming).
Rest looks good, so with these two changed:
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 5/5] rtc: pcf85363: add watchdog support with configurable step size
From: Lakshay Piplani @ 2026-06-15 6:25 UTC (permalink / raw)
To: Lakshay Piplani, alexandre.belloni@bootlin.com,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <20251121121137.3043764-5-lakshay.piplani@nxp.com>
> /*
> * Reads 6 bytes of timestamp data starting at the given base register,
> * converts them from BCD to binary, and formats the result into a @@ -685,6
> +833,10 @@ static int pcf85363_probe(struct i2c_client *client)
> PIN_IO_TSPM | PIN_IO_TSIM,
> PIN_IO_TSPM | PIN_IO_TSIM);
>
> + ret = pcf85363_watchdog_init(dev, pcf85363->regmap);
> + if (ret)
> + dev_err_probe(dev, ret, "Watchdog init failed\n");
> +
> if (irq_a > 0 || wakeup_source)
> device_init_wakeup(dev, true);
>
> --
> 2.25.1
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ permalink raw reply
* RE: [PATCH v4 4/5] rtc: pcf85363: add oscillator offset calibration support
From: Lakshay Piplani @ 2026-06-15 6:23 UTC (permalink / raw)
To: Lakshay Piplani, alexandre.belloni@bootlin.com,
linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org, wim@linux-watchdog.org,
linux@roeck-us.net, linux-watchdog@vger.kernel.org
Cc: Vikash Bansal, Priyanka Jain
In-Reply-To: <20251121121137.3043764-4-lakshay.piplani@nxp.com>
> -----Original Message-----
> From: Lakshay Piplani <lakshay.piplani@nxp.com>
> Sent: Friday, November 21, 2025 5:42 PM
> To: alexandre.belloni@bootlin.com; linux-rtc@vger.kernel.org; linux-
> kernel@vger.kernel.org; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org; devicetree@vger.kernel.org; wim@linux-watchdog.org;
> linux@roeck-us.net; linux-watchdog@vger.kernel.org
> Cc: Vikash Bansal <vikash.bansal@nxp.com>; Priyanka Jain
> <priyanka.jain@nxp.com>; Shashank Rebbapragada
> <shashank.rebbapragada@nxp.com>; Lakshay Piplani
> <lakshay.piplani@nxp.com>
> Subject: [PATCH v4 4/5] rtc: pcf85363: add oscillator offset calibration support
>
> Expose the oscillator offset register of PCF85263/PCF85363 through the
> rtc_class_ops read_offset and set_offset callbacks, allowing userspace to apply
> frequency correction for drift compensation.
>
> The correction mode defaults to normal mode (OFFM = 0), where each step
> introduces an offset of approximately 2.170 ppm and corrections occur every 4
> hours.
>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
> ---
> V3 -> V4:
> - No changes in v4.
> V2 -> V3:
> - Split into separate patches as suggested:
> - Battery switch-over detection.
> - Timestamp recording for TS pin and battery switch-over events.
> - Offset calibration.
> - Watchdog timer (to be reviewed by watchdog maintainers).
> - Dropped Alarm2 support
> - Switched to rtc_add_group() for sysfs attributes
> V1 -> V2:
> - Watchdog related changes due to removal of vendor specific properties
> from device tree
> * remove vendor DT knobs (enable/timeout/stepsize/repeat)
> * use watchdog_init_timeout (with 10s default)
> * derive clock_sel from final timeout
> * default, repeat=true (repeat mode)
> - Fixed uninitalised warning on 'ret' (reported by kernel test robot)
> - Use dev_dbg instead of dev_info for debug related print messages
> - Minor cleanup and comments.
>
> drivers/rtc/rtc-pcf85363.c | 46
> ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c index
> e10e58f69012..665bbbb169b0 100644
> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
> @@ -123,6 +123,11 @@
> #define TSR2_SHIFT 2
> #define TSR3_SHIFT 6
>
> +#define OFFSET_SIGN_BIT 7
> +#define OFFSET_MINIMUM -128
> +#define OFFSET_MAXIMUM 127
> +#define OFFSET_MASK 0xFF
> +
> struct pcf85363 {
> struct rtc_device *rtc;
> struct regmap *regmap;
> @@ -359,6 +364,45 @@ static irqreturn_t pcf85363_rtc_handle_irq(int irq,
> void *dev_id)
> return handled ? IRQ_HANDLED : IRQ_NONE; }
>
> +/*
> + * Read the current RTC offset from the CTRL_OFFSET
> + * register. This value is an 8-bit signed 2's complement
> + * value that corrects osciallator drift.
> + */
> +static int pcf85363_read_offset(struct device *dev, long *offset) {
> + struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(pcf85363->regmap, CTRL_OFFSET, &val);
> +
> + if (ret)
> + return ret;
> +
> + *offset = sign_extend32(val & OFFSET_MASK, OFFSET_SIGN_BIT);
> +
> + return 0;
> +}
> +
> +/*
> + * Write an oscillator offset correction value to
> + * the CTRL_OFFSET register. The valid range is
> + * -128 to 127 (8-bit signed), typically used to fine
> + * tune accuracy.
> + */
> +static int pcf85363_set_offset(struct device *dev, long offset) {
> + struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
> +
> + if (offset < OFFSET_MINIMUM || offset > OFFSET_MAXIMUM) {
> + dev_warn(dev, "Offset out of range: %ld\n", offset);
> + return -ERANGE;
> + }
> +
> + return regmap_write(pcf85363->regmap, CTRL_OFFSET, offset &
> +OFFSET_MASK); }
> +
> static int pcf85363_rtc_ioctl(struct device *dev,
> unsigned int cmd, unsigned long arg) { @@ -396,6
> +440,8 @@ static const struct rtc_class_ops rtc_ops = {
> .read_alarm = pcf85363_rtc_read_alarm,
> .set_alarm = pcf85363_rtc_set_alarm,
> .alarm_irq_enable = pcf85363_rtc_alarm_irq_enable,
> + .read_offset = pcf85363_read_offset,
> + .set_offset = pcf85363_set_offset,
> };
>
> static int pcf85363_nvram_read(void *priv, unsigned int offset, void *val,
> --
> 2.25.1
Hi,
I hope you're doing well.
This is a gentle follow-up regarding the v4 patch series for the PCF85363 RTC driver that I submitted in November 2025.
I understand things can get busy, but I haven't seen any feedback on the series yet, so I wanted to check if you've had a chance to review it.
I'd be happy to make any updates if needed. Please let me know if there's anything required from my side to move this forward.
Thanks in advance for your time and feedback.
Best regards,
Lakshay Piplani
^ 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