Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Greg Ungerer
On 23/04/18 21:47, Arnd Bergmann wrote: On Mon, Apr 23, 2018 at 11:47 AM, Geert Uytterhoeven wrote: Hi Arnd, On Mon, Apr 23, 2018 at 11:28 AM, Arnd Bergmann wrote: On Mon, Apr 23, 2018 at 11:07 AM, Geert Uytterhoeven wrote: On Fri, Apr 20, 2018 at 5:22 PM, Arnd Bergmann wrote: On Thu, Ap

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Arnd Bergmann
On Mon, Apr 23, 2018 at 11:47 AM, Geert Uytterhoeven wrote: > Hi Arnd, > > On Mon, Apr 23, 2018 at 11:28 AM, Arnd Bergmann wrote: >> On Mon, Apr 23, 2018 at 11:07 AM, Geert Uytterhoeven >> wrote: >>> On Fri, Apr 20, 2018 at 5:22 PM, Arnd Bergmann wrote: On Thu, Apr 19, 2018 at 8:22 AM, Bao

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Baolin Wang
Hi Geert, On 23 April 2018 at 17:07, Geert Uytterhoeven wrote: > Hi Baolin, > > On Mon, Apr 23, 2018 at 4:08 AM, Baolin Wang wrote: >> On 20 April 2018 at 23:22, Arnd Bergmann wrote: >>> On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: The read_persistent_clock() uses a timespec, which

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Alexandre Belloni
On 23/04/2018 11:28:38+0200, Arnd Bergmann wrote: > Some extra background on this: > > read_persistent_clock64/read_persistent_clock is primarily needed when you > have a real time source that is better than the one exposed in the RTC class > driver. For platforms doing suspend/resume, the timeke

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Geert Uytterhoeven
Hi Arnd, On Mon, Apr 23, 2018 at 11:28 AM, Arnd Bergmann wrote: > On Mon, Apr 23, 2018 at 11:07 AM, Geert Uytterhoeven > wrote: >> On Fri, Apr 20, 2018 at 5:22 PM, Arnd Bergmann wrote: >>> On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: The read_persistent_clock() uses a timespec, whi

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Arnd Bergmann
On Mon, Apr 23, 2018 at 11:07 AM, Geert Uytterhoeven wrote: > Hi Arnd, > > On Fri, Apr 20, 2018 at 5:22 PM, Arnd Bergmann wrote: >> On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: >>> The read_persistent_clock() uses a timespec, which is not year 2038 safe >>> on 32bit systems. Moreover on m

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Geert Uytterhoeven
Hi Baolin, On Mon, Apr 23, 2018 at 4:08 AM, Baolin Wang wrote: > On 20 April 2018 at 23:22, Arnd Bergmann wrote: >> On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: >>> The read_persistent_clock() uses a timespec, which is not year 2038 safe >>> on 32bit systems. Moreover on m68k architectur

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-23 Thread Geert Uytterhoeven
Hi Arnd, On Fri, Apr 20, 2018 at 5:22 PM, Arnd Bergmann wrote: > On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: >> The read_persistent_clock() uses a timespec, which is not year 2038 safe >> on 32bit systems. Moreover on m68k architecture, we have implemented generic >> RTC drivers that can

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-22 Thread Baolin Wang
On 20 April 2018 at 23:22, Arnd Bergmann wrote: > On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: >> The read_persistent_clock() uses a timespec, which is not year 2038 safe >> on 32bit systems. Moreover on m68k architecture, we have implemented generic >> RTC drivers that can be used to comp

Re: [PATCH] m68k: Remove read_persistent_clock()

2018-04-20 Thread Arnd Bergmann
On Thu, Apr 19, 2018 at 8:22 AM, Baolin Wang wrote: > The read_persistent_clock() uses a timespec, which is not year 2038 safe > on 32bit systems. Moreover on m68k architecture, we have implemented generic > RTC drivers that can be used to compensate the system suspend time. So > we can remove the