On 30/04/2019 14:36:24+0300, Baruch Siach wrote: > Hi Alexandre, > > On Tue, Apr 30 2019, Alexandre Belloni wrote: > > > While the range of REFERENCE + TIME is actually 33 bits, the counter > > itself (TIME) is a 32-bits seconds counter. > > > > Signed-off-by: Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> > > --- > > drivers/rtc/rtc-digicolor.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/rtc/rtc-digicolor.c b/drivers/rtc/rtc-digicolor.c > > index 5bb14c56bc9a..e6e16aaac254 100644 > > --- a/drivers/rtc/rtc-digicolor.c > > +++ b/drivers/rtc/rtc-digicolor.c > > @@ -206,6 +206,7 @@ static int __init dc_rtc_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, rtc); > > > > rtc->rtc_dev->ops = &dc_rtc_ops; > > + rtc->rtc_dev->range_max = U32_MAX; > > Where can I find documentation on the meaning and usage of the range_max > value? I could not find anything in the kernel source. > It should be set to the maximum UNIX timestamp the RTC can be set to while keeping range_min to range_max contiguous. In the digicolor case, you could go up to 8589934590 (Wed Mar 16 12:56:30 UTC 2242) but the driver only writes DC_RTC_REFERENCE and I'm not sure it can also update DC_RTC_TIME safely. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
