lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63298bb6-2921-b57d-729d-21e83a945944@linux-m68k.org>
Date: Fri, 4 Oct 2024 08:31:10 +1000 (AEST)
From: Finn Thain <fthain@...ux-m68k.org>
To: Alexandre Belloni <alexandre.belloni@...tlin.com>
cc: Geert Uytterhoeven <geert@...ux-m68k.org>, Daniel Palmer <daniel@...f.com>, 
    Michael Pavone <pavone@...rodev.com>, linux-m68k@...ts.linux-m68k.org, 
    linux-rtc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] rtc: m48t59: Accommodate chips that lack a century
 bit


On Thu, 3 Oct 2024, Alexandre Belloni wrote:

> On 03/10/2024 13:23:22+1000, Finn Thain wrote:
> > The m48t59 driver is needed by both SPARC and MVME systems. Linux on
> > MVME uses 1970 as "year zero" rather than 1968 that's used on SPARC.
> > Add support for the MVME convention. Otherwise, the RTC on non-SPARC
> > systems can only read and write dates between 1900 and 1999.
> > 
> > Tested-by: Daniel Palmer <daniel@...f.com>
> > Signed-off-by: Finn Thain <fthain@...ux-m68k.org>
> > ---
> >  drivers/rtc/rtc-m48t59.c | 31 +++++++++++++++----------------
> >  1 file changed, 15 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-m48t59.c b/drivers/rtc/rtc-m48t59.c
> > index f0f6b9b6daec..e2d882ea5c2f 100644
> > --- a/drivers/rtc/rtc-m48t59.c
> > +++ b/drivers/rtc/rtc-m48t59.c
> > @@ -57,6 +57,17 @@ m48t59_mem_readb(struct device *dev, u32 ofs)
> >  	return readb(m48t59->ioaddr+ofs);
> >  }
> >  
> > +/*
> > + * Sun SPARC machines count years since 1968. MVME machines running Linux
> > + * count years since 1970.
> > + */
> > +
> > +#ifdef CONFIG_SPARC
> > +#define YEAR0 68
> > +#else
> > +#define YEAR0 70
> > +#endif
> > +
> >  /*
> >   * NOTE: M48T59 only uses BCD mode
> >   */
> > @@ -82,10 +93,7 @@ static int m48t59_rtc_read_time(struct device *dev, struct rtc_time *tm)
> >  		dev_dbg(dev, "Century bit is enabled\n");
> >  		tm->tm_year += 100;	/* one century */
> >  	}
> > -#ifdef CONFIG_SPARC
> > -	/* Sun SPARC machines count years since 1968 */
> > -	tm->tm_year += 68;
> > -#endif
> > +	tm->tm_year += YEAR0;
> >  
> 
> I'm super happy to see someone working on this, while you are it, can 
> you use m48t59->rtc->start_secs and m48t59->rtc->set_start_time in probe 
> instead of offsetting tm_year in read_time/set_time so we can later use 
> device tree or any other mechanism to extend the range?
> 

Sure, I will look into it.

> It is super funny because I was telling Geert that I wanted to get rid 
> of this #ifdef CONFIG_SPARC two weeks ago at LPC. That could indeed then 
> come from platform data.
> 

I can't test any patches on SPARC, unless there's some way to do so using 
QEMU that would satisfy maintainers. (I rely on Daniel to test my patches 
on an MVME147 system.)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ