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
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
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
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
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
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
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
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
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
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
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 obsolete read_persistent_clock().
Signed-off-by: Baolin Wan
11 matches
Mail list logo