Hi Finn,
On Sun, Jul 22, 2018 at 1:56 PM Finn Thain wrote:
> On Wed, 18 Jul 2018, I wrote:
> > On Wed, 18 Jul 2018, Arnd Bergmann wrote:
> > > I'd suggest we do it like below to make it consistent with the rest
> > > again, using the 1904..2040 range of dates and no warning for invalid
> > > date
On Wed, 18 Jul 2018, I wrote:
> On Wed, 18 Jul 2018, Arnd Bergmann wrote:
>
> > I'd suggest we do it like below to make it consistent with the rest
> > again, using the 1904..2040 range of dates and no warning for invalid
> > dates.
> >
> > If you agree, I'll send that as a proper patch.
> >
On Wed, Jul 18, 2018 at 3:49 PM, Finn Thain wrote:
> On Wed, 18 Jul 2018, Arnd Bergmann wrote:
>>
>> -static long via_read_time(void)
>> +static time64_t via_read_time(void)
>> {
>> union {
>> __u8 cdata[4];
>> - long idata;
>> + __u32 idata;
>
On Wed, 18 Jul 2018, Arnd Bergmann wrote:
> Hmm, apparently I forgot to update via_read_time(), that one
> is indeed bogus and now inconsistent with the other functions.
>
> The change in via_write_time() seems at least consistent wtih what we do
> elsewhere, and using __u32 makes this code more
On Wed, Jul 18, 2018 at 2:02 PM, Finn Thain wrote:
> On Wed, 18 Jul 2018, Geert Uytterhoeven wrote:
>
>>
>> Thanks for your patch!
>>
>> Applied and queued for v4.19, with the WARN_ON() dropped.
>>
>
> The patch you've committed to your for-v4.19 branch has this hunk:
>
> @@ -269,8 +275,12 @@ stat
On Wed, 18 Jul 2018, Geert Uytterhoeven wrote:
>
> Thanks for your patch!
>
> Applied and queued for v4.19, with the WARN_ON() dropped.
>
The patch you've committed to your for-v4.19 branch has this hunk:
@@ -269,8 +275,12 @@ static long via_read_time(void)
via_pram_command(0x
On Tue, Jun 19, 2018 at 4:04 PM Arnd Bergmann wrote:
> The real-time clock on m68k (and powerpc) mac systems uses an unsigned
> 32-bit value starting in 1904, which overflows in 2040, about two years
> later than everyone else, but this gets wrapped around in the Linux
> code in 2038 already becau
On Sun, 8 Jul 2018, Geert Uytterhoeven wrote:
> On Fri, Jun 22, 2018 at 10:55 AM Arnd Bergmann wrote:
> > I don't think anyone so far had a strong preference here, so I went
> > with what Mathieu suggested and kept the original Mac behavior, but
> > added the WARN_ON().
>
> So, is this safe t
Hi Arnd, Finn,
On Fri, Jun 22, 2018 at 10:55 AM Arnd Bergmann wrote:
> On Fri, Jun 22, 2018 at 7:26 AM, Finn Thain
> wrote:
> > On Tue, 19 Jun 2018, Arnd Bergmann wrote:
> >
> >> The real-time clock on m68k (and powerpc) mac systems uses an unsigned
> >> 32-bit value starting in 1904, which ove
On Fri, Jun 22, 2018 at 7:26 AM, Finn Thain wrote:
> On Tue, 19 Jun 2018, Arnd Bergmann wrote:
>
>> The real-time clock on m68k (and powerpc) mac systems uses an unsigned
>> 32-bit value starting in 1904, which overflows in 2040, about two years
>> later than everyone else, but this gets wrapped a
On Tue, 19 Jun 2018, Arnd Bergmann wrote:
> The real-time clock on m68k (and powerpc) mac systems uses an unsigned
> 32-bit value starting in 1904, which overflows in 2040, about two years
> later than everyone else, but this gets wrapped around in the Linux code
> in 2038 already because of th
The real-time clock on m68k (and powerpc) mac systems uses an unsigned
32-bit value starting in 1904, which overflows in 2040, about two years
later than everyone else, but this gets wrapped around in the Linux
code in 2038 already because of the deprecated usage of time_t and/or
long in the conver
12 matches
Mail list logo
