- 03 Apr, 2015 37 commits
-
-
Rafael J. Wysocki authored
Now that all users are converted over to explicit calls into the clockevents state machine, remove the notification chain leftovers. Original-from: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: John Stultz <john.stultz@linaro.org> Link: http://lkml.kernel.org/r/14018863.NQUzkFuafr@vostro.rjw.lanSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
clockevents_notify() is a leftover from the early design of the clockevents facility. It's really not a notification mechanism, it's a multiplex call. We are way better off to have explicit calls instead of this monstrosity. Split out the broadcast oneshot control into a separate function and provide inline helpers. Switch clockevents_notify() over. This will go away once all callers are converted. This also gets rid of the nested locking of clockevents_lock and broadcast_lock. The broadcast oneshot control functions do not require clockevents_lock. Only the managing functions (setup/shutdown/suspend/resume of the broadcast device require clockevents_lock. Signed-off-by:
-
Thomas Gleixner authored
All users converted. Remove the notify leftovers. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
Replace the clockevents_notify() call with an explicit function call. Signed-off-by:
-
Thomas Gleixner authored
clockevents_notify() is a leftover from the early design of the clockevents facility. It's really not a notification mechanism, it's a multiplex call. We are way better off to have explicit calls instead of this monstrosity. Split out the broadcast control into a separate function and provide inline helpers. Switch clockevents_notify() over. This will go away once all callers are converted. This also gets rid of the nested locking of clockevents_lock and broadcast_lock. The broadcast control functions do not require clockevents_lock. Only the managing functions (setup/shutdown/suspend/resume of the broadcast device require clockevents_lock. Signed-off-by:
-
Thomas Gleixner authored
While looking through the (ab)use of the clockevents_notify() function I stumbled over the following gem in the acpi_pad code: if (lapic_detected_unstable && !lapic_marked_unstable) { /* LAPIC could halt in idle, so notify users */ for_each_online_cpu(i) clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &i); lapic_marked_unstable = 1; } This code calls on the cpu which detects the lapic unstable condition first clockevents_notify() to tell the core code that the broadcast should be enabled on all online cpus. Brilliant stuff that as it notifies the core code a num_online_cpus() times that the broadcast should be enabled on the current cpu. This probably has never been noticed because that code got never tested with NOHZ=n and HIGHRES_TIMER=n or it just worked by chance because one of the other mechanisms told the core in the right way that the local apic timer is wreckaged. Sigh, this is: - The 4th incarnation of idle drivers which has their own mechanism to detect and deal with X86_FEATURE_ARAT. - The 2nd incarnation of fake idle mechanisms with a different set of brainmelting bugs. - Has been merged against an explicit NAK of the scheduler maintainer with the promise to improve it over time. - Another example of featuritis driven trainwreck engineering. - Another pointless waste of my time. Fix this nonsense by removing that lapic detection and notification logic and simply call into the clockevents code unconditonally. The ARAT feature is marked in the lapic clockevent already so the core code will just ignore the requests and return. Signed-off-by: -
John Stultz authored
Ingo noted that the description of clocks_calc_max_nsecs()'s 50% safety margin was somewhat circular. So this patch tries to improve the comment to better explain what we mean by the 50% safety margin and why we need it. Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-20-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
If a system does not provide a persistent_clock(), the time will be updated on resume by rtc_resume(). With the addition of the non-stop clocksources for suspend timing, those systems set the time on resume in timekeeping_resume(), but may not provide a valid persistent_clock(). This results in the rtc_resume() logic thinking no one has set the time and it then will over-write the suspend time again, which is not necessary and only increases clock error. So, fix this for rtc_resume(). This patch also improves the name of persistent_clock_exist to make it more grammatical. Signed-off-by:
Xunlei Pang <pang.xunlei@linaro.org> Signed-off-by:
-
Xunlei Pang authored
When there's no persistent clock, normally timekeeping_suspend_time should always be zero, but this can break in timekeeping_suspend(). At T1, there was a system suspend, so old_delta was assigned T1. After some time, one time adjustment happened, and xtime got the value of T1-dt(0s<dt<2s). Then, there comes another system suspend soon after this adjustment, obviously we will get a small negative delta_delta, resulting in a negative timekeeping_suspend_time. This is problematic, when doing timekeeping_resume() if there is no nonstop clocksource for example, it will hit the else leg and inject the improper sleeptime which is the wrong logic. So, we can solve this problem by only doing delta related code when the persistent clock is existent. Actually the code only makes sense for persistent clock cases. Signed-off-by:
-
Xunlei Pang authored
rtc_read_time() has already judged valid tm by rtc_valid_tm(), so just remove it. Signed-off-by:
-
Xunlei Pang authored
timekeeping_inject_sleeptime64() is only used by RTC suspend/resume, so add build dependencies on the necessary RTC related macros. Signed-off-by:
-
Xunlei Pang authored
Change alpha_rtc_set_mmss() and remote_set_mmss() to use rtc_class_ops's set_mmss64(), to be y2038 safe. Signed-off-by:
Alessandro Zummo <a.zummo@towertech.it> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Richard Henderson <rth@twiddle.net> Link: http://lkml.kernel.org/r/1427945681-29972-15-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing rtc_time_to_tm() with rtc_time64_to_tm() - Replacing rtc_tm_to_time() with rtc_tm_to_time64() - Changing mxc_rtc_set_mmss() to use rtc_class_ops's set_mmss64() After this patch, the driver should not have any remaining y2038/y2106 issues. Signed-off-by:
-
Xunlei Pang authored
We want to convert mxc_rtc_set_mmss() to use rtc_class_ops's set_mmss64(), but it uses get_alarm_or_time()/set_alarm_or_time() internal interfaces which are y2038 unsafe. So here as a separate patch, it converts these two internal interfaces of "mxc" to use safe time64_t to make some preparations. Signed-off-by:
-
Xunlei Pang authored
rtc_class_ops's set_alarm() shouldn't deal with the alarm date, as this is handled in the rtc core. See rtc_dev_ioctl()'s RTC_ALM_SET and RTC_WKALM_SET cases. Signed-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing rtc_time_to_tm() with rtc_time64_to_tm() - Changing mc13xxx_rtc_set_mmss() to use rtc_class_ops's set_mmss64() After this patch, the driver should not have any remaining y2038/y2106 issues. Signed-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing rtc_tm_to_time() with rtc_tm_to_time64() - Replacing rtc_time_to_tm() with rtc_time64_to_tm() - Changing ab3100_rtc_set_mmss() to use rtc_class_ops's set_mmss64() After this patch, the driver should not have any remaining y2038/y2106 issues. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-10-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
This driver has a number of y2038/y2106 issues. This patch resolves them by: - Replacing get_seconds() with ktime_get_real_seconds() - Replacing rtc_time_to_tm() with rtc_time64_to_tm() Also add test_rtc_set_mmss64() for testing rtc_class_ops's set_mmss64(), which can be activated by "test_mmss64" module parameter. Signed-off-by:
-
Xunlei Pang authored
Currently the rtc_class_op's set_mmss() function takes a 32-bit second value (on 32-bit systems), which is problematic for dates past y2038. This patch provides a safe version named set_mmss64() using y2038 safe time64_t. After this patch, set_mmss() is deprecated and all its users will be fixed to use set_mmss64(), it can be removed when having no users. Signed-off-by:
-
Xunlei Pang authored
As part of addressing "y2038 problem" for in-kernel uses, this patch converts read_boot_clock() to read_boot_clock64() and read_persistent_clock() to read_persistent_clock64() using timespec64 by converting clock_access_fn to use timespec64. Signed-off-by:
-
Xunlei Pang authored
As part of addressing "y2038 problem" for in-kernel uses, this patch adds the y2038-safe tegra_read_persistent_clock64() using timespec64. Because we rely on some subsequent changes to convert arm multiarch support, tegra_read_persistent_clock() will be removed then. Signed-off-by:
Thierry Reding <treding@nvidia.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-6-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
As part of addressing "y2038 problem" for in-kernel uses, this patch adds the y2038-safe omap_read_persistent_clock64() using timespec64. Because we rely on some subsequent changes to convert arm multiarch support, omap_read_persistent_clock() will be removed then. Also remove the needless spinlock, because read_persistent_clock() doesn't run simultaneously. Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1427945681-29972-5-git-send-email-john.stultz@linaro.orgSigned-off-by:
-
Xunlei Pang authored
As part of addressing in-kernel y2038 issues, this patch adds update_persistent_clock64() and replaces all the call sites of update_persistent_clock() with this function. This is a __weak implementation, which simply calls the existing y2038 unsafe update_persistent_clock(). This allows architecture specific implementations to be converted independently, and eventually y2038-unsafe update_persistent_clock() can be removed after all its architecture specific implementations have been converted to update_persistent_clock64(). Suggested-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Xunlei Pang authored
As part of addressing in-kernel y2038 issues, this patch adds read_persistent_clock64() and replaces all the call sites of read_persistent_clock() with this function. This is a __weak implementation, which simply calls the existing y2038 unsafe read_persistent_clock(). This allows architecture specific implementations to be converted independently, and eventually the y2038 unsafe read_persistent_clock() can be removed after all its architecture specific implementations have been converted to read_persistent_clock64(). Suggested-by:
-
Xunlei Pang authored
As part of addressing in-kernel y2038 issues, this patch adds read_boot_clock64() and replaces all the call sites of read_boot_clock() with this function. This is a __weak implementation, which simply calls the existing y2038 unsafe read_boot_clock(). This allows architecture specific implementations to be converted independently, and eventually the y2038 unsafe read_boot_clock() can be removed after all its architecture specific implementations have been converted to read_boot_clock64(). Suggested-by:
-
- 02 Apr, 2015 3 commits
-
-
Peter Zijlstra authored
Remove one CONFIG_HOTPLUG_CPU #ifdef in trade for introducing one CONFIG_SMP #ifdef. The CONFIG_SMP ifdef avoids declaring the per-CPU __tvec_bases storage on UP systems since they already have boot_tvec_bases. Also (re)add a runtime check on the base alignment -- for the paranoid amongst us :-) Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/fdd2d35e169bdc554ffa3fe77f77716298c75ada.1427814611.git.viresh.kumar@linaro.orgSigned-off-by:
-
Viresh Kumar authored
There is no need to call init_timers_cpu() on every CPU hotplug event, there is not much we need to reset. - Timer-lists are already empty at the end of migrate_timers(). - timer_jiffies will be refreshed while adding a new timer, after the CPU is online again. - active_timers and all_timers can be reset from migrate_timers(). Signed-off-by:
-
Peter Zijlstra authored
Memory for the 'tvec_base' array is allocated separately for the boot CPU (statically) and non-boot CPUs (dynamically). The reason is because __TIMER_INITIALIZER() needs to set ->base to a valid pointer (because we've made NULL special, hint: lock_timer_base()) and we cannot get a compile time pointer to per-cpu entries because we don't know where we'll map the section, even for the boot cpu. This can be simplified a bit by statically allocating per-cpu memory. The only disadvantage is that memory for one of the structures will stay unused, i.e. for the boot CPU, which uses boot_tvec_bases. This will also guarantee that tvec_base is cacheline aligned. Even though tvec_base has ____cacheline_aligned stuck on, kzalloc_node() does not actually respect that (but guarantees a minimum u64 alignment). Signed-off-by:
-
