user/sven/linux.git/arch/m68k/kernel/time.c, branch v5.2.2

treewide: Add SPDX license identifier for missed files

2019-05-21T08:50:45Z

Add SPDX license identifiers to all files which: - Have no license information of any form - Have EXPORT_.*_SYMBOL_GPL inside which was used in the initial scan/conversion to ignore the file These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman

m68k: Use read_persistent_clock64() consistently

2018-05-22T08:31:51Z

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 Reviewed-by: Baolin Wang Signed-off-by: Geert Uytterhoeven

m68k: Fix off-by-one calendar month

2018-05-22T08:31:50Z

This fixes a bug in read_persistent_clock() which causes the system clock to lag the Real Time Clock by one month. The problem was noticed on a Mac, but theoretically it must also affect Atari, BVME6000 and Q40. The tm_mon value in the struct rtc_time passed to mach_hwclk() is zero-based, and atari_mste_hwclk(), atari_tt_hwclk(), bvme6000_hwclk(), mac_hwclk() and q40_hwclk() all make this adjustment. Unfortunately, dn_dummy_hwclk(), mvme147_hwclk(), mvme16x_hwclk(), sun3_hwclk() and sun3x_hwclk() fail to decrement tm_mon. Also m68328_hwclk() assumes a one-based tm_mon. Bring these platforms into line and fix read_persistent_clock() so it works correctly on all m68k platforms. The datasheets for the RTC devices found on the affected platforms all confirm that the year is stored as a value in the range 0-99 and the month is stored as a value in the range 1-12. Please refer to the datasheets for MC146818 (Apollo), DS1643 (MVME), ICM7170 (Sun 3) and M48T02 (Sun 3x). Reported-by: Stan Johnson Signed-off-by: Finn Thain Reviewed-by: Arnd Bergmann Signed-off-by: Geert Uytterhoeven

m68k/time: Stop validating rtc_time in .read_time

2018-03-19T09:26:45Z

The RTC core is always calling rtc_valid_tm after the read_time callback. It is not necessary to call it just before returning from the callback. Signed-off-by: Alexandre Belloni Signed-off-by: Geert Uytterhoeven

sched/headers: Prepare for new header dependencies before moving code to

2017-03-02T07:42:27Z

We are going to split out of , which will have to be picked up from a couple of .c files. Create a trivial placeholder file that just maps to to make this patch obviously correct and bisectable. Include the new header in the files that are going to need it. Acked-by: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar

rtc: m68k: provide ioctl for q40

2016-06-03T22:23:22Z

The q40 platform is the only machine in the kernel that provides RTC_PLL_GET/RTC_PLL_SET ioctl commands in its rtc through the mach_get_rtc_pll/mach_set_rtc_pll callbacks. However, this currenctly works only in the old-style genrtc driver, not the (somewhat) modern rtc-generic driver replacing it. This adds an ioctl implementation to the m68k generic_rtc_ops in order to let both drivers provide the same API. After this, we should be able to remove support for genrtc from the m68k architecture. Signed-off-by: Arnd Bergmann Acked-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Alexandre Belloni

rtc: m68k: provide rtc_class_ops directly

2016-06-03T22:23:05Z

The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and m68k has another abstraction on top, which is a bit silly. This changes the m68k rtc-generic device to provide its rtc_class_ops directly, to reduce the number of layers by one. Signed-off-by: Arnd Bergmann Acked-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Signed-off-by: Alexandre Belloni

m68k: Export mach_random_get_entropy to modules

2014-07-11T08:37:53Z

When a module calls random_get_entropy(): ERROR: "mach_random_get_entropy" [crypto/drbg.ko] undefined! make[1]: *** [__modpost] Error 1 Signed-off-by: Geert Uytterhoeven

m68k: Add infrastructure for machine-specific random_get_entropy()

2013-11-26T10:09:24Z

On m68k, get_cycles() (the default implementation for random_get_entropy()) always returns zero, providing no entropy for the random driver. Add a hook where platforms can provide their own implementation, and wire it up in the infrastructure provided by commit 61875f30daf60305712e25b209ef41ced2635bad ("random: allow architectures to optionally define random_get_entropy()"). Signed-off-by: Geert Uytterhoeven

PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.

2013-07-15T01:55:01Z

Sweep of the simple cases. Cc: netdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: Julia Lawall Signed-off-by: Rusty Russell Acked-by: David S. Miller Acked-by: Benjamin Herrenschmidt