All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-m68k <linux-m68k@vger.kernel.org>,
	Stan Johnson <userm57@yahoo.com>,
	Finn Thain <fthain@telegraphics.com.au>,
	Sam Creasey <sammy@sammy.net>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Baolin Wang <baolin.wang@linaro.org>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] m68k: use read_persistent_clock64 consistently
Date: Tue, 24 Apr 2018 12:25:17 +0200	[thread overview]
Message-ID: <CAMuHMdXtGx3SUxehRRN=uarw8H7Za-zjNkTigibnTxXxEbMW2w@mail.gmail.com> (raw)
In-Reply-To: <20180423085242.3140416-1-arnd@arndb.de>

On Mon, Apr 23, 2018 at 10:52 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> We have two ways of getting the current time from a platform at boot
> or during suspend: either using read_persistent_clock() or the rtc
> class operation. We never need both, so I'm hiding the
> read_persistent_clock variant when the generic RTC is enabled.
>
> Since read_persistent_clock() and mktime() are deprecated because of
> the y2038 overflow of time_t, we should use the time64_t based
> replacements here.
>
> Finally, the dependency on CONFIG_ARCH_USES_GETTIMEOFFSET looks
> completely bogus in this case, so let's remove that. It was
> added in commit b13b3f51ff7b ("m68k: fix inclusion of
> arch_gettimeoffset for non-MMU 68k classic CPU types") to deal
> with arch_gettimeoffset(), which has since been removed from
> this file and is unrelated to the RTC functions.
>
> The rtc accessors are only used by classic machines, while
> coldfire uses proper RTC drivers, so we can put the old
> ifdef back around both functions.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Thanks, applied and queued for v4.18 with Baolin's Rb.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

      parent reply	other threads:[~2018-04-24 10:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-23  8:52 [PATCH] m68k: use read_persistent_clock64 consistently Arnd Bergmann
2018-04-23 10:33 ` Baolin Wang
2018-04-24 10:25 ` Geert Uytterhoeven [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMuHMdXtGx3SUxehRRN=uarw8H7Za-zjNkTigibnTxXxEbMW2w@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=baolin.wang@linaro.org \
    --cc=fthain@telegraphics.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=sammy@sammy.net \
    --cc=userm57@yahoo.com \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.