[PATCH 4/4] rtc: zynqmp: use dynamic max and min offset ranges

[T, Harini]

[Public]

Hi,

> -----Original Message-----
> From: Tomas Melin <tomas.melin at vaisala.com>
> Sent: Wednesday, December 10, 2025 5:55 PM
> To: T, Harini <Harini.T at amd.com>; Alexandre Belloni
> <alexandre.belloni at bootlin.com>; Simek, Michal <michal.simek at amd.com>
> Cc: linux-rtc at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [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.
>
>
> Hi,
>
> On 09/12/2025 21:28, T, Harini wrote:
> > [Public]
> >
> > Hi,
> >
> >> -----Original Message-----
> >> From: Tomas Melin <tomas.melin at vaisala.com>
> >> Sent: Monday, December 1, 2025 6:20 PM
> >> To: Alexandre Belloni <alexandre.belloni at bootlin.com>; Simek, Michal
> >> <michal.simek at amd.com>
> >> Cc: linux-rtc at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> >> linux- kernel at vger.kernel.org; Tomas Melin <tomas.melin at 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 at 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..0cebc99b15a6de2440a6
> 0afc
> >> 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?
>
You're right - calibval=0 is hardware-spec compliant and produces 1Hz
operation. The patch is correct as-is with '< 1'.
There's no issue with allowing calibval=0 from a hardware perspective.
> 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
> >
Regards,
Harini T