| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Specs don't say anything about UIP being cleared within 10ms. They
only say that UIP won't occur for another 244uS. If a long NMI occurs
while UIP is still updating it might not be possible to get valid
data in 10ms.
This has been observed in the wild that around s2idle some calls can
take up to 480ms before UIP is clear.
Adjust callers from outside an interrupt context to wait for up to a
1s instead of 10ms.
Cc: <stable@vger.kernel.org> # 6.1.y
Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
Reported-by: Carsten Hatger <xmb8dsv4@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217626
Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231128053653.101798-5-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The UIP timeout is hardcoded to 10ms for all RTC reads, but in some
contexts this might not be enough time. Add a timeout parameter to
mc146818_get_time() and mc146818_get_time_callback().
If UIP timeout is configured by caller to be >=100 ms and a call
takes this long, log a warning.
Make all callers use 10ms to ensure no functional changes.
Cc: <stable@vger.kernel.org> # 6.1.y
Fixes: ec5895c0f2d8 ("rtc: mc146818-lib: extract mc146818_avoid_UIP")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Link: https://lore.kernel.org/r/20231128053653.101798-4-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
When mc146818_avoid_UIP() fails to return a valid value, this is because
UIP didn't clear in the timeout period. Adjust the return code in this
case to -ETIMEDOUT.
Tested-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Reviewed-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: <stable@vger.kernel.org>
Fixes: cdedc45c579f ("rtc: cmos: avoid UIP when reading alarm time")
Fixes: cd17420ebea5 ("rtc: cmos: avoid UIP when writing alarm time")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231128053653.101798-3-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Intel systems > 2015 have been configured to use ACPI alarm instead
of HPET to avoid s2idle issues.
Having HPET programmed for wakeup causes problems on AMD systems with
s2idle as well.
One particular case is that the systemd "SuspendThenHibernate" feature
doesn't work properly on the Framework 13" AMD model. Switching to
using ACPI alarm fixes the issue.
Adjust the quirk to apply to AMD/Hygon systems from 2021 onwards.
This matches what has been tested and is specifically to avoid potential
risk to older systems.
Cc: <stable@vger.kernel.org> # 6.1+
Reported-by: <alvin.zhuge@gmail.com>
Reported-by: <renzhamin@gmail.com>
Closes: https://github.com/systemd/systemd/issues/24279
Reported-by: Kelvie Wong <kelvie@kelvie.ca>
Closes: https://community.frame.work/t/systemd-suspend-then-hibernate-wakes-up-after-5-minutes/39392
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20231106162310.85711-1-mario.limonciello@amd.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The alarm window supported by the cmos RTC depends on the chip
and its configuration. Report the limit to the RTC core.
Cc: Brian Norris <briannorris@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230817225537.4053865-5-linux@roeck-us.net
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230304133028.2135435-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Make cmos_do_remove() drop the ACPI RTC fixed event handler so as to
prevent it from operating on stale data in case the event triggers
after driver removal.
Fixes: 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/2224609.iZASKD2KPV@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The names of rtc_wake_setup() and cmos_wake_setup() don't indicate
that these functions are ACPI-related, which is the case, and the
former doesn't really reflect the role of the function.
Rename them to acpi_rtc_event_setup() and acpi_cmos_wake_setup(),
respectively, to address this shortcoming.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/3225614.44csPzL39Z@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Reorder the ACPI-related code before cmos_do_probe() so as to eliminate
excessive forward declarations of some functions.
While at it, for consistency, add the inline modifier to the
definitions of empty stub static funtions and remove it from the
corresponding definitions of functions with non-empty bodies.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/13157911.uLZWGnKmhe@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
To reduce code duplication, move the invocation of rtc_wake_setup()
into cmos_do_probe() and simplify the callers of the latter.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/2143522.irdbgypaU6@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Notice that cmos_wake_setup() is the only user of acpi_rtc_info and it
can operate on the cmos_rtc variable directly, so it need not set the
platform_data pointer before cmos_do_probe() is called. Instead, it
can be called by cmos_do_probe() in the case when the platform_data
pointer is not set to implement the default behavior (which is to use
the FADT information as long as ACPI support is enabled).
Modify the code accordingly.
While at it, drop a comment that doesn't really match the code it is
supposed to be describing.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/4803444.31r3eYUQgx@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Now that rtc_wake_setup is called outside of cmos_wake_setup, it also need
to be defined on non-ACPI platforms.
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20221018203512.2532407-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Commit 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration
ordering issue") overlooked the fact that cmos_do_probe() depended
on the preparations carried out by cmos_wake_setup() and the wake
alarm stopped working after the ordering of them had been changed.
Address this by partially reverting commit 4919d3eb2ec0 so that
cmos_wake_setup() is called before cmos_do_probe() again and moving
the rtc_wake_setup() invocation from cmos_wake_setup() directly to the
callers of cmos_do_probe() where it will happen after a successful
completion of the latter.
Fixes: 4919d3eb2ec0 ("rtc: cmos: Fix event handler registration ordering issue")
Reported-by: Zhang Rui <rui.zhang@intel.com>
Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/5887691.lOV4Wx5bFT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Because acpi_install_fixed_event_handler() enables the event
automatically on success, it is incorrect to call it before the
handler routine passed to it is ready to handle events.
Unfortunately, the rtc-cmos driver does exactly the incorrect thing
by calling cmos_wake_setup(), which passes rtc_handler() to
acpi_install_fixed_event_handler(), before cmos_do_probe(), because
rtc_handler() uses dev_get_drvdata() to get to the cmos object
pointer and the driver data pointer is only populated in
cmos_do_probe().
This leads to a NULL pointer dereference in rtc_handler() on boot
if the RTC fixed event happens to be active at the init time.
To address this issue, change the initialization ordering of the
driver so that cmos_wake_setup() is always called after a successful
cmos_do_probe() call.
While at it, change cmos_pnp_probe() to call cmos_do_probe() after
the initial if () statement used for computing the IRQ argument to
be passed to cmos_do_probe() which is cleaner than calling it in
each branch of that if () (local variable "irq" can be of type int,
because it is passed to that function as an argument of type int).
Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check
ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number
of systems, because previously it only affected systems with
ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that
commit.
Fixes: 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0")
Fixes: a474aaedac99 ("rtc-cmos: move wake setup from ACPI glue into RTC driver")
Link: https://lore.kernel.org/linux-acpi/20221010141630.zfzi7mk7zvnmclzy@techsingularity.net/
Reported-by: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Mel Gorman <mgorman@techsingularity.net>
Link: https://lore.kernel.org/r/5629262.DvuYhMxLoT@kreacher
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to
use low-power S0 idle on the given platform than S3 (provided that
the latter is supported) and it doesn't preclude using either of
them (which of them will be used depends on the choices made by user
space).
For this reason, there is no benefit from checking that flag in
use_acpi_alarm_quirks().
First off, it cannot be a bug to do S3 with use_acpi_alarm set,
because S3 can be used on systems with ACPI_FADT_LOW_POWER_S0 and it
must work if really supported, so the ACPI_FADT_LOW_POWER_S0 check is
not needed to protect the S3-capable systems from failing.
Second, suspend-to-idle can be carried out on a system with
ACPI_FADT_LOW_POWER_S0 unset and it is expected to work, so if setting
use_acpi_alarm is needed to handle that case correctly, it should be
set regardless of the ACPI_FADT_LOW_POWER_S0 value.
Accordingly, drop the ACPI_FADT_LOW_POWER_S0 check from
use_acpi_alarm_quirks().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/12054246.O9o76ZdvQC@kreacher
|
|
Some Intel chipsets disconnect the time and date RTC registers when the
clock update is in progress: during this time reads may return bogus
values and writes fail silently. This includes the RTC alarm registers.
[1]
cmos_set_alarm() did not take account for that, fix it.
[1] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...]
Datasheet, Volume 1 of 2 (Intel's Document Number: 334658-006)
Page 208
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf
"If a RAM read from the ten time and date bytes is attempted
during an update cycle, the value read do not necessarily
represent the true contents of those locations. Any RAM writes
under the same conditions are ignored."
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-10-mat.jonczyk@o2.pl
|
|
Some Intel chipsets disconnect the time and date RTC registers when the
clock update is in progress: during this time reads may return bogus
values and writes fail silently. This includes the RTC alarm registers.
[1]
cmos_read_alarm() did not take account for that, which caused alarm time
reads to sometimes return bogus values. This can be shown with a test
patch that I am attaching to this patch series.
Fix this, by using mc146818_avoid_UIP().
[1] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...]
Datasheet, Volume 1 of 2 (Intel's Document Number: 334658-006)
Page 208
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf
"If a RAM read from the ten time and date bytes is attempted
during an update cycle, the value read do not necessarily
represent the true contents of those locations. Any RAM writes
under the same conditions are ignored."
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-9-mat.jonczyk@o2.pl
|
|
To prevent an infinite loop in mc146818_get_time(),
commit 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
added a check for RTC availability. Together with a later fix, it
checked if bit 6 in register 0x0d is cleared.
This, however, caused a false negative on a motherboard with an AMD
SB710 southbridge; according to the specification [1], bit 6 of register
0x0d of this chipset is a scratchbit. This caused a regression in Linux
5.11 - the RTC was determined broken by the kernel and not used by
rtc-cmos.c [3]. This problem was also reported in Fedora [4].
As a better alternative, check whether the UIP ("Update-in-progress")
bit is set for longer then 10ms. If that is the case, then apparently
the RTC is either absent (and all register reads return 0xff) or broken.
Also limit the number of loop iterations in mc146818_get_time() to 10 to
prevent an infinite loop there.
The functions mc146818_get_time() and mc146818_does_rtc_work() will be
refactored later in this patch series, in order to fix a separate
problem with reading / setting the RTC alarm time. This is done so to
avoid a confusion about what is being fixed when.
In a previous approach to this problem, I implemented a check whether
the RTC_HOURS register contains a value <= 24. This, however, sometimes
did not work correctly on my Intel Kaby Lake laptop. According to
Intel's documentation [2], "the time and date RAM locations (0-9) are
disconnected from the external bus" during the update cycle so reading
this register without checking the UIP bit is incorrect.
[1] AMD SB700/710/750 Register Reference Guide, page 308,
https://developer.amd.com/wordpress/media/2012/10/43009_sb7xx_rrg_pub_1.00.pdf
[2] 7th Generation Intel ® Processor Family I/O for U/Y Platforms [...] Datasheet
Volume 1 of 2, page 209
Intel's Document Number: 334658-006,
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-and-8th-gen-core-family-mobile-u-y-processor-lines-i-o-datasheet-vol-1.pdf
[3] Functions in arch/x86/kernel/rtc.c apparently were using it.
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1936688
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Fixes: ebb22a059436 ("rtc: mc146818: Dont test for bit 0-5 in Register D")
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-5-mat.jonczyk@o2.pl
|
|
There are 4 users of mc146818_get_time() and none of them was checking
the return value from this function. Change this.
Print the appropriate warnings in callers of mc146818_get_time() instead
of in the function mc146818_get_time() itself, in order not to add
strings to rtc-mc146818-lib.c, which is kind of a library.
The callers of alpha_rtc_read_time() and cmos_read_time() may use the
contents of (struct rtc_time *) even when the functions return a failure
code. Therefore, set the contents of (struct rtc_time *) to 0x00,
which looks more sensible then 0xff and aligns with the (possibly
stale?) comment in cmos_read_time:
/*
* If pm_trace abused the RTC for storage, set the timespec to 0,
* which tells the caller that this RTC value is unusable.
*/
For consistency, do this in mc146818_get_time().
Note: hpet_rtc_interrupt() may call mc146818_get_time() many times a
second. It is very unlikely, though, that the RTC suddenly stops
working and mc146818_get_time() would consistently fail.
Only compile-tested on alpha.
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-alpha@vger.kernel.org
Cc: x86@kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-4-mat.jonczyk@o2.pl
|
|
Reading from the CMOS involves writing to the index register and then
reading from the data register. Therefore access to the CMOS has to be
serialized with rtc_lock. This invocation of CMOS_READ was not
serialized, which could cause trouble when other code is accessing CMOS
at the same time.
Use spin_lock_irq() like the rest of the function.
Nothing in kernel modifies the RTC_DM_BINARY bit, so there could be a
separate pair of spin_lock_irq() / spin_unlock_irq() before doing the
math.
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Reviewed-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20211210200131.153887-2-mat.jonczyk@o2.pl
|
|
As previously noted in commit 66e4f4a9cc38 ("rtc: cmos: Use
spin_lock_irqsave() in cmos_interrupt()"):
<4>[ 254.192378] WARNING: inconsistent lock state
<4>[ 254.192384] 5.12.0-rc1-CI-CI_DRM_9834+ #1 Not tainted
<4>[ 254.192396] --------------------------------
<4>[ 254.192400] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
<4>[ 254.192409] rtcwake/5309 [HC0[0]:SC0[0]:HE1:SE1] takes:
<4>[ 254.192429] ffffffff8263c5f8 (rtc_lock){?...}-{2:2}, at: cmos_interrupt+0x18/0x100
<4>[ 254.192481] {IN-HARDIRQ-W} state was registered at:
<4>[ 254.192488] lock_acquire+0xd1/0x3d0
<4>[ 254.192504] _raw_spin_lock+0x2a/0x40
<4>[ 254.192519] cmos_interrupt+0x18/0x100
<4>[ 254.192536] rtc_handler+0x1f/0xc0
<4>[ 254.192553] acpi_ev_fixed_event_detect+0x109/0x13c
<4>[ 254.192574] acpi_ev_sci_xrupt_handler+0xb/0x28
<4>[ 254.192596] acpi_irq+0x13/0x30
<4>[ 254.192620] __handle_irq_event_percpu+0x43/0x2c0
<4>[ 254.192641] handle_irq_event_percpu+0x2b/0x70
<4>[ 254.192661] handle_irq_event+0x2f/0x50
<4>[ 254.192680] handle_fasteoi_irq+0x9e/0x150
<4>[ 254.192693] __common_interrupt+0x76/0x140
<4>[ 254.192715] common_interrupt+0x96/0xc0
<4>[ 254.192732] asm_common_interrupt+0x1e/0x40
<4>[ 254.192750] _raw_spin_unlock_irqrestore+0x38/0x60
<4>[ 254.192767] resume_irqs+0xba/0xf0
<4>[ 254.192786] dpm_resume_noirq+0x245/0x3d0
<4>[ 254.192811] suspend_devices_and_enter+0x230/0xaa0
<4>[ 254.192835] pm_suspend.cold.8+0x301/0x34a
<4>[ 254.192859] state_store+0x7b/0xe0
<4>[ 254.192879] kernfs_fop_write_iter+0x11d/0x1c0
<4>[ 254.192899] new_sync_write+0x11d/0x1b0
<4>[ 254.192916] vfs_write+0x265/0x390
<4>[ 254.192933] ksys_write+0x5a/0xd0
<4>[ 254.192949] do_syscall_64+0x33/0x80
<4>[ 254.192965] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[ 254.192986] irq event stamp: 43775
<4>[ 254.192994] hardirqs last enabled at (43775): [<ffffffff81c00c42>] asm_sysvec_apic_timer_interrupt+0x12/0x20
<4>[ 254.193023] hardirqs last disabled at (43774): [<ffffffff81aa691a>] sysvec_apic_timer_interrupt+0xa/0xb0
<4>[ 254.193049] softirqs last enabled at (42548): [<ffffffff81e00342>] __do_softirq+0x342/0x48e
<4>[ 254.193074] softirqs last disabled at (42543): [<ffffffff810b45fd>] irq_exit_rcu+0xad/0xd0
<4>[ 254.193101]
other info that might help us debug this:
<4>[ 254.193107] Possible unsafe locking scenario:
<4>[ 254.193112] CPU0
<4>[ 254.193117] ----
<4>[ 254.193121] lock(rtc_lock);
<4>[ 254.193137] <Interrupt>
<4>[ 254.193142] lock(rtc_lock);
<4>[ 254.193156]
*** DEADLOCK ***
<4>[ 254.193161] 6 locks held by rtcwake/5309:
<4>[ 254.193174] #0: ffff888104861430 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x5a/0xd0
<4>[ 254.193232] #1: ffff88810f823288 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xe7/0x1c0
<4>[ 254.193282] #2: ffff888100cef3c0 (kn->active#285
<7>[ 254.192706] i915 0000:00:02.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:51:pipe A] hw state readout: disabled
<4>[ 254.193307] ){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xf0/0x1c0
<4>[ 254.193333] #3: ffffffff82649fa8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend.cold.8+0xce/0x34a
<4>[ 254.193387] #4: ffffffff827a2108 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x47/0x70
<4>[ 254.193433] #5: ffff8881019ea178 (&dev->mutex){....}-{3:3}, at: device_resume+0x68/0x1e0
<4>[ 254.193485]
stack backtrace:
<4>[ 254.193492] CPU: 1 PID: 5309 Comm: rtcwake Not tainted 5.12.0-rc1-CI-CI_DRM_9834+ #1
<4>[ 254.193514] Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019
<4>[ 254.193524] Call Trace:
<4>[ 254.193536] dump_stack+0x7f/0xad
<4>[ 254.193567] mark_lock.part.47+0x8ca/0xce0
<4>[ 254.193604] __lock_acquire+0x39b/0x2590
<4>[ 254.193626] ? asm_sysvec_apic_timer_interrupt+0x12/0x20
<4>[ 254.193660] lock_acquire+0xd1/0x3d0
<4>[ 254.193677] ? cmos_interrupt+0x18/0x100
<4>[ 254.193716] _raw_spin_lock+0x2a/0x40
<4>[ 254.193735] ? cmos_interrupt+0x18/0x100
<4>[ 254.193758] cmos_interrupt+0x18/0x100
<4>[ 254.193785] cmos_resume+0x2ac/0x2d0
<4>[ 254.193813] ? acpi_pm_set_device_wakeup+0x1f/0x110
<4>[ 254.193842] ? pnp_bus_suspend+0x10/0x10
<4>[ 254.193864] pnp_bus_resume+0x5e/0x90
<4>[ 254.193885] dpm_run_callback+0x5f/0x240
<4>[ 254.193914] device_resume+0xb2/0x1e0
<4>[ 254.193942] ? pm_dev_err+0x25/0x25
<4>[ 254.193974] dpm_resume+0xea/0x3f0
<4>[ 254.194005] dpm_resume_end+0x8/0x10
<4>[ 254.194030] suspend_devices_and_enter+0x29b/0xaa0
<4>[ 254.194066] pm_suspend.cold.8+0x301/0x34a
<4>[ 254.194094] state_store+0x7b/0xe0
<4>[ 254.194124] kernfs_fop_write_iter+0x11d/0x1c0
<4>[ 254.194151] new_sync_write+0x11d/0x1b0
<4>[ 254.194183] vfs_write+0x265/0x390
<4>[ 254.194207] ksys_write+0x5a/0xd0
<4>[ 254.194232] do_syscall_64+0x33/0x80
<4>[ 254.194251] entry_SYSCALL_64_after_hwframe+0x44/0xae
<4>[ 254.194274] RIP: 0033:0x7f07d79691e7
<4>[ 254.194293] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
<4>[ 254.194312] RSP: 002b:00007ffd9cc2c768 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
<4>[ 254.194337] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f07d79691e7
<4>[ 254.194352] RDX: 0000000000000004 RSI: 0000556ebfc63590 RDI: 000000000000000b
<4>[ 254.194366] RBP: 0000556ebfc63590 R08: 0000000000000000 R09: 0000000000000004
<4>[ 254.194379] R10: 0000556ebf0ec2a6 R11: 0000000000000246 R12: 0000000000000004
which breaks S3-resume on fi-kbl-soraka presumably as that's slow enough
to trigger the alarm during the suspend.
Fixes: 6950d046eb6e ("rtc: cmos: Replace spin_lock_irqsave with spin_lock in hard IRQ")
References: 66e4f4a9cc38 ("rtc: cmos: Use spin_lock_irqsave() in cmos_interrupt()"):
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Xiaofei Tan <tanxiaofei@huawei.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210305122140.28774-1-chris@chris-wilson.co.uk
|
|
It appears mc146818_get_time() and mc146818_set_time() now correctly
use the century register as specified in the ACPI FADT table. It is not
clear what else could be done here.
These comments were introduced by
commit 7be2c7c96aff ("[PATCH] RTC framework driver for CMOS RTCs")
in 2007, which originally referenced function get_rtc_time() in
include/asm-generic/rtc.h .
Signed-off-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210716210437.29622-1-mat.jonczyk@o2.pl
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"Many cleanups and a few drivers removal this cycle.
Subsystem:
- Introduce features bitfield and the first feature: RTC_FEATURE_ALARM
Removed drivers:
- ab3100
- coh901331
- tx4939
- sirfsoc
Drivers:
- use rtc_lock and rtc_unlock instead of opencoding
- constify all struct rtc_class_ops
- quiet maybe-unused variable warning
- replace spin_lock_irqsave with spin_lock in hard IRQ
- pcf2127: disable Power-On Reset Override and run OTP refresh"
* tag 'rtc-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (81 commits)
rtc: abx80x: Add utility function for writing configuration key
rtc: pcf2127: properly set flag WD_CD for rtc chips(pcf2129, pca2129)
rtc: pcf8563: Add NXP PCA8565 compatible
rtc: s3c: quiet maybe-unused variable warning
rtc: s3c: stop setting bogus time
rtc: sd3078: quiet maybe-unused variable warning
rtc: s35390a: quiet maybe-unused variable warning
rtc: rx8581: quiet maybe-unused variable warning
rtc: rx8010: quiet maybe-unused variable warning
rtc: rv8803: quiet maybe-unused variable warning
rtc: rv3032: quiet maybe-unused variable warning
rtc: rv3029: quiet maybe-unused variable warning
rtc: rv3028: quiet maybe-unused variable warning
rtc: rs5c372: quiet maybe-unused variable warning
rtc: pcf85363: quiet maybe-unused variable warning
rtc: pcf85063: quiet maybe-unused variable warnings
rtc: meson: quiet maybe-unused variable warning
rtc: m41t80: quiet maybe-unused variable warning
rtc: isl1208: quiet maybe-unused variable warning
rtc: ds3232: quiet maybe-unused variable warning
...
|
|
It is redundant to do irqsave and irqrestore in hardIRQ context, where
it has been in a irq-disabled context.
Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/1612355981-6764-2-git-send-email-tanxiaofei@huawei.com
|
|
The recent change to validate the RTC turned out to be overly tight.
While it cures the problem on the reporters machine it breaks machines
with Intel chipsets which use bit 0-5 of the D register. So check only
for bit 6 being 0 which is the case on these Intel machines as well.
Fixes: 211e5db19d15 ("rtc: mc146818: Detect and handle broken RTCs")
Reported-by: Serge Belyshev <belyshev@depni.sinp.msu.ru>
Reported-by: Dirk Gouders <dirk@gouders.net>
Reported-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dirk Gouders <dirk@gouders.net>
Tested-by: Len Brown <len.brown@intel.com>
Tested-by: Borislav Petkov <bp@suse.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/87zh0nbnha.fsf@nanos.tec.linutronix.de
|
|
The recent fix for handling the UIP bit unearthed another issue in the RTC
code. If the RTC is advertised but the readout is straight 0xFF because
it's not available, the old code just proceeded with crappy values, but the
new code hangs because it waits for the UIP bit to become low.
Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID
register (Register D) which should have bit 0-6 cleared. If that's not the
case then fail to register the CMOS.
Add the same check to mc146818_get_time(), warn once when the condition
is true and invalidate the rtc_time data.
Reported-by: Mickaël Salaün <mic@digikod.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Mickaël Salaün <mic@linux.microsoft.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/87tur3fx7w.fsf@nanos.tec.linutronix.de
|
|
Clear RTC_FEATURE_ALARM to signal that alarms are not available instead of
having a supplementary struct rtc_class_ops with a NULL .set_alarm.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210110231752.1418816-5-alexandre.belloni@bootlin.com
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"Subsystem:
- Remove nvram ABI. There was no complaints about the deprecation for
the last 3 years.
- Improve RTC device allocation and registration
- Now available for ARCH=um
Drivers:
- at91rm9200: correction and sam9x60 support
- ds1307: improve ACPI support
- mxc: now DT only
- pcf2127: watchdog support now needs the reset-source property
- pcf8523: set range
- rx6110: i2c support"
* tag 'rtc-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (43 commits)
rtc: pcf2127: only use watchdog when explicitly available
dt-bindings: rtc: add reset-source property
rtc: fix RTC removal
rtc: s3c: Remove dead code related to periodic tick handling
rtc: s3c: Disable all enable (RTC, tick) bits in the probe
rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time
rtc: test: remove debug message
rtc: mxc{,_v2}: enable COMPILE_TEST
rtc: enable RTC framework on ARCH=um
rtc: pcf8523: use BIT
rtc: pcf8523: set range
rtc: pcf8523: switch to devm_rtc_allocate_device
rtc: destroy mutex when releasing the device
rtc: shrink devm_rtc_allocate_device()
rtc: rework rtc_register_device() resource management
rtc: nvmem: emit an error message when nvmem registration fails
rtc: add devm_ prefix to rtc_nvmem_register()
rtc: nvmem: remove nvram ABI
Documentation: list RTC devres helpers in devres.rst
rtc: omap: use devm_pinctrl_register()
...
|
|
The current RTC set_offset_nsec value is not really intuitive to
understand.
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
The offset is calculated from twrite based on the assumption that t2 -
twrite == 1s. That means for the MC146818 RTC the offset needs to be
negative so that the write happens 500ms before t2.
It's easier to understand when the whole calculation is based on t2. That
avoids negative offsets and the meaning is obvious:
t2 - twrite: The time defined by the chip when seconds increment
after the write.
twrite - tsched: The time for the transport to the point where the chip
is updated.
==> set_offset_nsec = t2 - tsched
ttransport = twrite - tsched
tRTCinc = t2 - twrite
==> set_offset_nsec = ttransport + tRTCinc
tRTCinc is a chip property and can be obtained from the data sheet.
ttransport depends on how the RTC is connected. It is close to 0 for
directly accessible RTCs. For RTCs behind a slow bus, e.g. i2c, it's the
time required to send the update over the bus. This can be estimated or
even calibrated, but that's a different problem.
Adjust the implementation and update comments accordingly.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220542.263204937@linutronix.de
|
|
The offset for rtc_cmos must be -500ms to work correctly with the current
implementation of rtc_set_ntp_time() due to the following:
tsched twrite(t2.tv_sec - 1) t2 (seconds increment)
twrite - tsched is the transport time for the write to hit the device,
which is negligible for this chip because it's accessed directly.
t2 - twrite = 500ms according to the datasheet.
But rtc_set_ntp_time() calculation of tsched is:
tsched = t2 - 1sec - (t2 - twrite)
The default for the sync offset is 500ms which means that the write happens
at t2 - 1.5 seconds which is obviously off by a second for this device.
Make the offset -500ms so it works correct.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201206220541.830517160@linutronix.de
|
|
rtc_register_device() is a managed interface but it doesn't use devres
by itself - instead it marks an rtc_device as "registered" and the devres
callback for devm_rtc_allocate_device() takes care of resource release.
This doesn't correspond with the design behind devres where managed
structures should not be aware of being managed. The correct solution
here is to register a separate devres callback for unregistering the
device.
While at it: rename rtc_register_device() to devm_rtc_register_device()
and add it to the list of managed interfaces in devres.rst. This way we
can avoid any potential confusion of driver developers who may expect
there to exist a corresponding unregister function.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-8-brgl@bgdev.pl
|
|
Some users check the return value of devm_rtc_nvmem_register() only in
order to emit an error message and then continue probing. This is fine
as an rtc can function without exposing nvmem but let's generalize it:
let's make the registration function emit the error message so that
users don't have to.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-7-brgl@bgdev.pl
|
|
rtc_nvmem_register() is a managed interface. It doesn't require any
release function to be called at driver detach. To avoid confusing
driver authors, let's rename it to devm_rtc_nvmem_register() and add it
to the list of managed interfaces in Documentation/.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20201109163409.24301-6-brgl@bgdev.pl
|
|
The nvram sysfs attributes have been deprecated at least since v4.13, more
than 3 years ago and nobody ever complained about the deprecation warning.
Remove the sysfs attributes now.
[Bartosz: remove the declaration of rtc_nvmem_unregister()]
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20201109163409.24301-5-brgl@bgdev.pl
|
|
cmos_read_alarm() may leave certain fields of a struct rtc_wkalrm
untouched; therefore, these fields contain garbage if not properly
initialized, leading to inconsistent values when converting into
time64_t. This patch to zero initialize the struct before calling
cmos_read_alarm().
Note that this patch is not intended to produce a correct time64_t, it
is only to produce a consistent value. In the case of suspend/resume, a
correct time64_t is not necessary; a consistent value is sufficient to
correctly perform an equality test for t_current_expires and
t_saved_expires. Logic to deduce a correct time64_t is expensive and
hence should be avoided.
Signed-off-by: Victor Ding <victording@google.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20200814191654.v2.1.Iaf7638a2f2a87ff68d85fcb8dec615e41340c97f@changeid
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"More cleanup this cycle, with the final goal of removing the
rtc_time_to_tm and rtc_tm_to_time wrappers. All the drivers that have
been modified for this now are ready for the end of times (whether it
happens in 2033, 2038, 2106, 2127 or even 4052). There is also a
single new driver and the usual fixes and features.
Summary:
Subsystem:
- The rtc_time_to_tm and rtc_tm_to_time wrappers have finally been
removed and only the 64bit version remain.
- hctosys now works with drivers compiled as modules
New driver:
- MediaTek MT2712 SoC based RTC
Drivers:
- set range for 88pm860x, au1xxx, cpcap, da9052, davinci, ds1305,
ds1374, mcp5121, pl030, pl031, pm8xxx, puv3, sa1100, sirfsoc,
starfire, sun6i
- ds1307: DS1388 oscillator failure detection and watchdog support
- jz4740: JZ4760 support
- pcf85063: clock out pin support
- sun6i: external 32k oscillator is now optional, the range is now
handled by the core, providing a solution for 2034"
* tag 'rtc-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (87 commits)
rtc: ds1307: check for failed memory allocation on wdt
rtc: class: remove redundant assignment to variable err
rtc: remove rtc_time_to_tm and rtc_tm_to_time
rtc: sun6i: let the core handle rtc range
rtc: sun6i: switch to rtc_time64_to_tm/rtc_tm_to_time64
rtc: ds1307: add support for watchdog timer on ds1388
rtc: da9052: switch to rtc_time64_to_tm/rtc_tm_to_time64
rtc: da9052: set range
rtc: da9052: convert to devm_rtc_allocate_device
rtc: imx-sc: Align imx sc msg structs to 4
rtc: fsl-ftm-alarm: report alarm to core
rtc: pcf85063: Add pcf85063 clkout control to common clock framework
rtc: make definitions in include/uapi/linux/rtc.h actually useful for user space
rtc: class: avoid unnecessary lookup in hctosys
dt-bindings: rtc: Convert and update jz4740-rtc doc to YAML
rtc: jz4740: Rename vendor-specific DT properties
rtc: jz4740: Add support for JZ4760 SoC
rtc: class: support hctosys from modular RTC drivers
rtc: pm8xxx: clear alarm register when alarm is not enabled
rtc: omap: drop unused dt-bindings header
...
|
|
Now the pnp_driver name is "const char *", there are no need to cast
driver_name.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
cmos_interrupt() isn't always called from hardirq context, so
we must use spin_lock_irqsave() & co.
================================
WARNING: inconsistent lock state
5.6.0-rc2-CI-CI_DRM_7981+ #1 Tainted: G U
--------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
rtcwake/4315 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffffffff82635198 (rtc_lock){?...}, at: cmos_interrupt+0x18/0x100
{IN-HARDIRQ-W} state was registered at:
lock_acquire+0xa7/0x1c0
_raw_spin_lock+0x2a/0x40
cmos_interrupt+0x18/0x100
rtc_handler+0x75/0xc0
acpi_ev_fixed_event_detect+0xf9/0x132
acpi_ev_sci_xrupt_handler+0xb/0x28
acpi_irq+0x13/0x30
__handle_irq_event_percpu+0x41/0x2c0
handle_irq_event_percpu+0x2b/0x70
handle_irq_event+0x2f/0x50
handle_fasteoi_irq+0x8e/0x150
do_IRQ+0x7e/0x160
ret_from_intr+0x0/0x35
mwait_idle+0x7e/0x200
do_idle+0x1bb/0x260
cpu_startup_entry+0x14/0x20
start_secondary+0x15f/0x1b0
secondary_startup_64+0xa4/0xb0
irq event stamp: 42003
hardirqs last enabled at (42003): [<ffffffff81a36567>] _raw_spin_unlock_irqrestore+0x47/0x60
hardirqs last disabled at (42002): [<ffffffff81a362ed>] _raw_spin_lock_irqsave+0xd/0x50
softirqs last enabled at (41848): [<ffffffff81e00385>] __do_softirq+0x385/0x47f
softirqs last disabled at (41841): [<ffffffff810bab3a>] irq_exit+0xba/0xc0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(rtc_lock);
<Interrupt>
lock(rtc_lock);
*** DEADLOCK ***
6 locks held by rtcwake/4315:
#0: ffff888175dc9408 (sb_writers#5){.+.+}, at: vfs_write+0x1a4/0x1d0
#1: ffff88817406ca80 (&of->mutex){+.+.}, at: kernfs_fop_write+0xdd/0x1b0
#2: ffff888179be85e0 (kn->count#236){.+.+}, at: kernfs_fop_write+0xe6/0x1b0
#3: ffffffff82641e00 (system_transition_mutex){+.+.}, at: pm_suspend+0xb3/0x3b0
#4: ffffffff826b3ee0 (acpi_scan_lock){+.+.}, at: acpi_suspend_begin+0x47/0x80
#5: ffff888178fc3960 (&dev->mutex){....}, at: device_resume+0x92/0x1c0
stack backtrace:
CPU: 3 PID: 4315 Comm: rtcwake Tainted: G U 5.6.0-rc2-CI-CI_DRM_7981+ #1
Hardware name: Google Soraka/Soraka, BIOS MrChromebox-4.10 08/25/2019
Call Trace:
dump_stack+0x71/0x9b
mark_lock+0x49a/0x500
? print_shortest_lock_dependencies+0x200/0x200
__lock_acquire+0x6d4/0x15d0
? __lock_acquire+0x460/0x15d0
lock_acquire+0xa7/0x1c0
? cmos_interrupt+0x18/0x100
_raw_spin_lock+0x2a/0x40
? cmos_interrupt+0x18/0x100
cmos_interrupt+0x18/0x100
cmos_resume+0x1fd/0x290
? __acpi_pm_set_device_wakeup+0x24/0x100
pnp_bus_resume+0x5e/0x90
? pnp_bus_suspend+0x10/0x10
dpm_run_callback+0x64/0x280
device_resume+0xd4/0x1c0
? dpm_watchdog_set+0x60/0x60
dpm_resume+0x106/0x410
? dpm_resume_early+0x38c/0x3e0
dpm_resume_end+0x8/0x10
suspend_devices_and_enter+0x16f/0xbe0
? rcu_read_lock_sched_held+0x4d/0x80
pm_suspend+0x344/0x3b0
state_store+0x78/0xe0
kernfs_fop_write+0x112/0x1b0
vfs_write+0xb9/0x1d0
ksys_write+0x9f/0xe0
do_syscall_64+0x4f/0x220
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7ff934307154
Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 b1 07 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
RSP: 002b:00007ffe2647c168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007ff934307154
RDX: 0000000000000004 RSI: 000055de3ec4e5a0 RDI: 000000000000000a
RBP: 000055de3ec4e5a0 R08: 000055de3ec4c5e0 R09: 00007ff9349f3740
R10: 000055de3ec4a010 R11: 0000000000000246 R12: 000055de3ec4c500
R13: 0000000000000004 R14: 00007ff9345df2a0 R15: 00007ff9345de760
Fixes: c6d3a278cc12 ("rtc: cmos: acknowledge ACPI driven wake alarms upon resume")
Fixes: 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20200221144739.11746-1-ville.syrjala@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Refactor code by using the new dmi_get_bios_year() helper instead of
open coding its functionality. This also makes logic slightly clearer.
No changes intended.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200123131437.28157-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
When legacy devices are present on x86 machine, the RTC IRQ has
a dedicated pre-defined value. Use it instead of hard coded number.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200123131437.28157-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
As reported by Guilherme G. Piccoli:
---8<---8<---8<---
The rtc-cmos interrupt setting was changed in the commit 079062b28fb4
("rtc: cmos: prevent kernel warning on IRQ flags mismatch") in order
to allow shared interrupts; according to that commit's description,
some machine got kernel warnings due to the interrupt line being shared
between rtc-cmos and other hardware, and rtc-cmos didn't allow IRQ sharing
that time.
After the aforementioned commit though it was observed a huge increase
in lost HPET interrupts in some systems, observed through the following
kernel message:
[...] hpet1: lost 35 rtc interrupts
After investigation, it was narrowed down to the shared interrupts
usage when having the kernel option "irqpoll" enabled. In this case,
all IRQ handlers are called for non-timer interrupts, if such handlers
are setup in shared IRQ lines. The rtc-cmos IRQ handler could be set to
hpet_rtc_interrupt(), which will produce the kernel "lost interrupts"
message after doing work - lots of readl/writel to HPET registers, which
are known to be slow.
Although "irqpoll" is not a default kernel option, it's used in some contexts,
one being the kdump kernel (which is an already "impaired" kernel usually
running with 1 CPU available), so the performance burden could be considerable.
Also, the same issue would happen (in a shorter extent though) when using
"irqfixup" kernel option.
In a quick experiment, a virtual machine with uptime of 2 minutes produced
>300 calls to hpet_rtc_interrupt() when "irqpoll" was set, whereas without
sharing interrupts this number reduced to 1 interrupt. Machines with more
hardware than a VM should generate even more unnecessary HPET interrupts
in this scenario.
---8<---8<---8<---
After looking into the rtc-cmos driver history and DSDT table from
the Microsoft Surface 3, we may notice that Hans de Goede submitted
a correct fix (see dependency below). Thus, we simply revert
the culprit commit.
Fixes: 079062b28fb4 ("rtc: cmos: prevent kernel warning on IRQ flags mismatch")
Depends-on: a1e23a42f1bd ("rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs")
Reported-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200123131437.28157-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When there is no IRQ configured for the RTC, the rtc-cmos code does not
support alarms, all alarm rtc_ops fail with -EIO / -EINVAL.
The rtc-core expects a rtc driver which does not support rtc alarms to
not have alarm ops at all. Otherwise the wakealarm sysfs attr will read
as empty rather then returning an error, making it impossible for
userspace to find out beforehand if alarms are supported.
A system without an IRQ for the RTC before this patch:
[root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm
[root@localhost ~]#
After this patch:
[root@localhost ~]# cat /sys/class/rtc/rtc0/wakealarm
cat: /sys/class/rtc/rtc0/wakealarm: No such file or directory
[root@localhost ~]#
This fixes gnome-session + systemd trying to use suspend-then-hibernate,
which causes systemd to abort the suspend when writing the RTC alarm fails.
BugLink: https://github.com/systemd/systemd/issues/9988
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Fix a problem with commit 311ee9c151ad ("rtc: cmos: allow using ACPI for
RTC alarm instead of HPET") defining `use_acpi_alarm' module parameter
even for non-ACPI platforms, which ignore it. Wrap the definition into
#ifdef CONFIG_ACPI and use a static inline wrapper function, hardcoded
to return 0 and consequently optimized away for !ACPI, following the
existing pattern with HPET handling functions.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Fixes: 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Cc: stable@vger.kernel.org # 4.18+
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Fix a commit 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm
instead of HPET") `rtc-cmos' regression causing a link error:
drivers/rtc/rtc-cmos.o: In function `cmos_platform_probe':
rtc-cmos.c:(.init.text+0x33c): undefined reference to `hpet_rtc_interrupt'
rtc-cmos.c:(.init.text+0x3f4): undefined reference to `hpet_rtc_interrupt'
with non-ACPI platforms using this driver. The cause is the change of
the condition guarding the use of `hpet_rtc_interrupt'.
Previously it was a call to `is_hpet_enabled'. That function is static
inline and has a hardcoded 0 result for non-ACPI platforms, which imply
!HPET_EMULATE_RTC. Consequently the compiler optimized the whole block
away including the reference to `hpet_rtc_interrupt', which never made
it to the link stage.
Now the guarding condition is a call to `use_hpet_alarm', which is not
static inline and therefore the compiler may not be able to prove that
it actually always returns 0 for non-ACPI platforms. Consequently the
build breaks with an unsatisfied reference, because `hpet_rtc_interrupt'
is nowhere defined at link time.
Fix the problem by marking `use_hpet_alarm' inline. As the `inline'
keyword serves as an optimization hint rather than a requirement the
compiler is still free to choose whether inlining will be beneficial or
not for ACPI platforms.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Fixes: 311ee9c151ad ("rtc: cmos: allow using ACPI for RTC alarm instead of HPET")
Cc: stable@vger.kernel.org # 4.18+
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Use ACPI for RTC Alarm only for Intel platforms
1. with Low Power S0 support
2. with HPET RTC emulation enabled
3. no earlier than 2015
Note that, during the test, it is found that this patch
1. works in 4.15-rc kernel
2. hangs the platform after suspend-to-idle for 2 or 3 times, in 4.15.0
3. works again in 4.16-rc3 kernel.
4. works in the latest 4.15.12 stable kernel.
Thus although this patch breaks 4.15.0 kernel for some unknown reason,
still, it is safe for both upstream and backport.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Previously, the RTC alarm is acknowledged either by the cmos rtc irq
handler, or by the hpet rtc irq handler.
When using ACPI RTC Fixed event as the RTC alarm, the RTC alarm is
acknowledged by the ACPI RTC event handler, as addressed in the previous
patch.
But, when resume from suspend-to-ram (ACPI S3), the ACPI SCI is cleared
right after resume, thus the ACPI RTC event handler is not invoked at all,
results in the RTC Alarm unacknowledged.
Handle this by comparing the current time and the RTC Alarm time in the
rtc_cmos driver .resume() callback
1. Assume the wakeup event has already been fired if the RTC Alarm time
is earlier than/equal to the current time, and ACK the RTC Alarm.
2. Assume the wakeup event has not been fired if the RTC Alarm time
is later than current time, and re-arm it if needed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
It's found that the HPET timer prevents the platform from entering
Low Power S0 on some new Intel platforms.
This means that
1. users can still use RTC wake Alarm for suspend-to-idle, but the system
never enters Low Power S0, which is a waste of power.
or
2. if users want to put the system into Low Power S0, they can not use
RTC as the wakeup source.
To fix this, we need to stop using the HPET timer for wake alarm.
But disabling CONFIG_HPET_EMULATE_RTC is not an option because HPET
emulates PIT at the same time, and this is needed on some of these
platforms.
Thus, introduce a new mode (use_acpi_alarm) to the rtc_cmos driver,
so that, even with CONFIG_HPET_EMULATE_RTC enabled, it's still possible to
use ACPI SCI for RTC Alarm, including UIE/AIE/wkalrm, instead of HPET.
Only necessary changes are made for the new "use_acpi_alarm" mode, including
1. drop all the calls to HPET emulation code, including the HPET irq
handler for rtc interrupt.
2. enabling/disabling ACPI RTC Fixed event upon RTC UIE/AIE request.
3. acknowledge the RTC Alarm in ACPI RTC Fixed event handler.
There is no functional change made in this patch if the new mode is not
enabled.
Note: this "use_acpi_alarm" mode is made based on the assumption that
ACPI RTC Fixed event is reliable both at runtime and during system wakeup.
And this has been verified on a couple of platforms I have, including
a MS Surface Pro 4 (SKL), a Lenovo Yoga 900 (SKL), and a HP 9360 (KBL).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"This contains a few series that have been in preparation for a while
and that will help systems with RTCs that will fail in 2038, 2069 or
2100.
Subsystem:
- Add tracepoints
- Rework of the RTC/nvmem API to allow drivers to discard struct
nvmem_config after registration
- New range API, drivers can now expose the useful range of the RTC
- New offset API the core is now able to add an offset to the RTC
time, modifying the supported range.
- Multiple rtc_time64_to_tm fixes
- Handle time_t overflow on 32 bit platforms in the core instead of
letting drivers do crazy things.
- remove rtc_control API
New driver:
- Intersil ISL12026
Drivers:
- Drivers exposing the RTC non volatile memory have been converted to
use nvmem
- Removed useless time and date validation
- Removed an indirection pattern that was a cargo cult from ancient
drivers
- Removed VLA usage
- Fixed a possible race condition in probe functions
- AB8540 support is dropped from ab8500
- pcf85363 now has alarm support"
* tag 'rtc-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (128 commits)
rtc: snvs: Fix usage of snvs_rtc_enable
rtc: mt7622: fix module autoloading for OF platform drivers
rtc: isl12022: use true and false for boolean values
rtc: ab8500: Drop AB8540 support
rtc: remove a warning during scripts/kernel-doc step
rtc: 88pm860x: remove artificial limitation
rtc: 88pm80x: remove artificial limitation
rtc: st-lpc: remove artificial limitation
rtc: mrst: remove artificial limitation
rtc: mv: remove artificial limitation
rtc: hctosys: Ensure system time doesn't overflow time_t
parisc: time: stop validating rtc_time in .read_time
rtc: pcf85063: fix clearing bits in pcf85063_start_clock
rtc: at91sam9: Set name of regmap_config
rtc: s5m: Remove VLA usage
rtc: s5m: Move enum from rtc.h to rtc-s5m.c
rtc: remove VLA usage
rtc: Add useful timestamp definitions
rtc: Add one offset seconds to expand RTC range
rtc: Factor out the RTC range validation into rtc_valid_range()
...
|
|
Remove the MN10300 arch as the hardware is defunct.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Masahiro Yamada <yamada.masahiro@socionext.com>
cc: linux-am33-list@redhat.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Setting the rtc to a valid time when the time is invalid is a bad practice,
because then userspace doesn't know it shouldn't trust the RTC.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Instead of adding a binary sysfs attribute from the driver, use the
core to register an nvmem device. This allows to use the in-kernel
interface to access the nvram.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The probe function is not allowed to fail after registering the RTC because
the following may happen:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc
as late as possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
* pm-sleep:
PM / hibernate: Declare variables as static
RTC: rtc-cmos: Fix wakeup from suspend-to-idle
PM / wakeup: Fix up wakeup_source_report_event()
* powercap:
PowerCap: Fix an error code in powercap_register_zone()
|
|
Commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from
suspend-to-idle) modified the core suspend-to-idle code to filter
out spurious SCI interrupts received while suspended, which requires
ACPI event source handlers to report wakeup events in a way that
will trigger a wakeup from suspend to idle (or abort system suspends
in progress, which is equivalent).
That needs to be done in the rtc-cmos driver too, which was overlooked
by the above commit, so do that now.
Fixes: eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle)
Reported-by: David E. Box <david.e.box@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
On some systems (e.g. Intel Bay Trail systems) the legacy PIC is not
used, in this case virq 8 will be a random irq, rather then hw_irq 8
from the PIC.
Requesting virq 8 in this case will not help us to get alarm irqs and
may cause problems for other drivers which actually do need virq 8,
for example on an Asus Transformer T100TA this leads to:
[ 28.745155] genirq: Flags mismatch irq 8. 00000088 (mmc0) vs. 00000080 (rtc0)
<snip oops>
[ 28.753700] mmc0: Failed to request IRQ 8: -16
[ 28.975934] sdhci-acpi: probe of 80860F14:01 failed with error -16
This commit fixes this by making the rtc-cmos driver continue
without using an irq rather then claiming irq 8 when no irq is
specified in the pnp-info and there are no legacy-irqs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux
Pull RTC updates from Alexandre Belloni:
"Subsystem:
- non-modular drivers are now explicitly non-modular
New driver:
- Epson Toyocom rtc-7301sf/dg
Drivers:
- cmos: reject unsupported alarm values wrt the RTC capabilities
- ds1307: ACPI support
- jz4740: DT support, jz4780 handling, can now be used as a system
power controller
- mcp795: many fixes, in particular proper month handling
- twl: driver is now DT only"
* tag 'rtc-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: (31 commits)
rtc: mcp795: Fix whitespace and indentation.
rtc: mcp795: Prefer using the BIT() macro.
rtc: mcp795: fix month write resetting date to 1.
rtc: mcp795: fix time range difference between linux and RTC chip.
rtc: mcp795: fix bitmask value for leap year (LP).
rtc: mcp795: use bcd2bin/bin2bcd.
rtc: add support for EPSON TOYOCOM RTC-7301SF/DG
rtc: ds1307: Add ACPI support
rtc: imxdi: (trivial) fix a typo
rtc: ds1374: Merge conditional + WARN_ON()
rtc: twl: make driver DT only
rtc: twl: kill static variables
rtc: fix typos in Kconfig
rtc: jz4740: make the driver builtin only
rtc: jz4740: remove unused EXPORT_SYMBOL
Documentation: bindings: fix twl-rtc documentation
rtc: Enable compile testing for Maxim and Samsung drivers
MIPS: jz4740: Remove obsolete code
MIPS: qi_lb60: Probe RTC driver from DT and use it as power controller
MIPS: jz4740: DTS: Probe the jz4740-rtc driver from devicetree
...
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer updates from Thomas Gleixner:
"The time/timekeeping/timer folks deliver with this update:
- Fix a reintroduced signed/unsigned issue and cleanup the whole
signed/unsigned mess in the timekeeping core so this wont happen
accidentaly again.
- Add a new trace clock based on boot time
- Prevent injection of random sleep times when PM tracing abuses the
RTC for storage
- Make posix timers configurable for real tiny systems
- Add tracepoints for the alarm timer subsystem so timer based
suspend wakeups can be instrumented
- The usual pile of fixes and updates to core and drivers"
* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits)
timekeeping: Use mul_u64_u32_shr() instead of open coding it
timekeeping: Get rid of pointless typecasts
timekeeping: Make the conversion call chain consistently unsigned
timekeeping_Force_unsigned_clocksource_to_nanoseconds_conversion
alarmtimer: Add tracepoints for alarm timers
trace: Update documentation for mono, mono_raw and boot clock
trace: Add an option for boot clock as trace clock
timekeeping: Add a fast and NMI safe boot clock
timekeeping/clocksource_cyc2ns: Document intended range limitation
timekeeping: Ignore the bogus sleep time if pm_trace is enabled
selftests/timers: Fix spelling mistake "Asyncrhonous" -> "Asynchronous"
clocksource/drivers/bcm2835_timer: Unmap region obtained by of_iomap
clocksource/drivers/arm_arch_timer: Map frame with of_io_request_and_map()
arm64: dts: rockchip: Arch counter doesn't tick in system suspend
clocksource/drivers/arm_arch_timer: Don't assume clock runs in suspend
posix-timers: Make them configurable
posix_cpu_timers: Move the add_device_randomness() call to a proper place
timer: Move sys_alarm from timer.c to itimer.c
ptp_clock: Allow for it to be optional
Kconfig: Regenerate *.c_shipped files after previous changes
...
|
|
Power management suspend/resume tracing (ab)uses the RTC to store
suspend/resume information persistently. As a consequence the RTC value is
clobbered when timekeeping is resumed and tries to inject the sleep time.
Commit a4f8f6667f09 ("timekeeping: Cap array access in timekeeping_debug")
plugged a out of bounds array access in the timekeeping debug code which
was caused by the clobbered RTC value, but we still use the clobbered RTC
value for sleep time injection into kernel timekeeping, which will result
in random adjustments depending on the stored "hash" value.
To prevent this keep track of the RTC clobbering and ignore the invalid RTC
timestamp at resume. If the system resumed successfully clear the flag,
which marks the RTC as unusable, warn the user about the RTC clobber and
recommend to adjust the RTC with 'ntpdate' or 'rdate'.
[jstultz: Fixed up pr_warn formating, and implemented suggestions from Ingo]
[ tglx: Rewrote changelog ]
Originally-from: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Xunlei Pang <xlpang@redhat.com>
Cc: Len Brown <lenb@kernel.org>
Link: http://lkml.kernel.org/r/1480372524-15181-3-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
handler is a no-no. Let's save/restore the flags to avoid turning on
interrupts prematurely.
We hit this in a bunch of our CI systems, but for whatever reason I
wasn't able to reproduce on my own machine, so this fix is just
based on the backtrace.
[ 202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 trace_hardirqs_on_caller+0x113/0x1b0
[ 202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[ 202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid [last unloaded: i915]
[ 202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U 4.9.0-rc1-CI-CI_DRM_1734+ #1
[ 202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 12/10/2014
[ 202.634933] ffff88011ea03d68 ffffffff8142dce5 ffff88011ea03db8 0000000000000000
[ 202.634934] ffff88011ea03da8 ffffffff8107e496 00000aa900000002 ffffffff81e249a0
[ 202.634935] ffffffff81815637 ffffffff82e7c280 0000000000000000 0000000000000004
[ 202.634936] Call Trace:
[ 202.634939] <IRQ>
[ 202.634939] [<ffffffff8142dce5>] dump_stack+0x67/0x92
[ 202.634941] [<ffffffff8107e496>] __warn+0xc6/0xe0
[ 202.634944] [<ffffffff81815637>] ? _raw_spin_unlock_irq+0x27/0x50
[ 202.634945] [<ffffffff8107e4fa>] warn_slowpath_fmt+0x4a/0x50
[ 202.634946] [<ffffffff810d6d83>] trace_hardirqs_on_caller+0x113/0x1b0
[ 202.634948] [<ffffffff810d6e2d>] trace_hardirqs_on+0xd/0x10
[ 202.634949] [<ffffffff81815637>] _raw_spin_unlock_irq+0x27/0x50
[ 202.634951] [<ffffffff81672042>] rtc_handler+0x32/0xa0
[ 202.634954] [<ffffffff814c08a3>] acpi_ev_fixed_event_detect+0xd4/0xfb
[ 202.634956] [<ffffffff814c2ccb>] acpi_ev_sci_xrupt_handler+0xf/0x2d
[ 202.634957] [<ffffffff814ab3ee>] acpi_irq+0x11/0x2c
[ 202.634960] [<ffffffff810e5288>] __handle_irq_event_percpu+0x58/0x370
[ 202.634961] [<ffffffff810e55be>] handle_irq_event_percpu+0x1e/0x50
[ 202.634962] [<ffffffff810e5624>] handle_irq_event+0x34/0x60
[ 202.634963] [<ffffffff810e8906>] handle_fasteoi_irq+0xa6/0x170
[ 202.634966] [<ffffffff8101eef5>] handle_irq+0x15/0x20
[ 202.634967] [<ffffffff8101e548>] do_IRQ+0x68/0x130
[ 202.634968] [<ffffffff81816789>] common_interrupt+0x89/0x89
[ 202.634970] <EOI>
[ 202.634970] [<ffffffff81814c73>] ? mwait_idle+0x93/0x210
[ 202.634971] [<ffffffff81814c6a>] ? mwait_idle+0x8a/0x210
[ 202.634972] [<ffffffff81026b0a>] arch_cpu_idle+0xa/0x10
[ 202.634973] [<ffffffff8181509e>] default_idle_call+0x1e/0x30
[ 202.634974] [<ffffffff810cbf6c>] cpu_startup_entry+0x17c/0x1f0
[ 202.634976] [<ffffffff8180ca87>] rest_init+0x127/0x130
[ 202.634978] [<ffffffff81f77f08>] start_kernel+0x3f6/0x403
[ 202.634980] [<ffffffff81f7728f>] x86_64_start_reservations+0x2a/0x2c
[ 202.634981] [<ffffffff81f77404>] x86_64_start_kernel+0x173/0x186
[ 202.634982] ---[ end trace 293c99618fa08d34 ]---
Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
That header has been gone for a while. I've fixed up the Kconfig
comment, but the one in rtc-cmos.c doesn't make any sense to me
even looking at its history.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Some platforms allows to specify the month and day of the month in
which an alarm should go off, some others the day of the month and
some others just the time.
Currently any given value is accepted by the driver and only the
supported fields are used to program the hardware. As consequence,
alarms are potentially programmed to go off in the wrong moment.
Fix this by rejecting any unsupported value.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
I got the following stack trace under qemu:
[ 7.575243] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 7.596098] IP: [<ffffffff814f5b08>] cmos_set_alarm+0x38/0x280
[ 7.615699] PGD 3ccbe067
[ 7.615923] PUD 3daf2067
[ 7.635156] PMD 0
[ 7.654358] Oops: 0000 [#1] SMP
[ 7.673869] Modules linked in:
[ 7.693235] CPU: 0 PID: 1701 Comm: hwclock Tainted: G W 4.9.0-rc1+ #24
[ 7.712455] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
[ 7.753569] task: ffff88003d88dc40 task.stack: ffffc90000224000
[ 7.773743] RIP: 0010:[<ffffffff814f5b08>] [<ffffffff814f5b08>] cmos_set_alarm+0x38/0x280
[ 7.794893] RSP: 0018:ffffc90000227c10 EFLAGS: 00010296
[ 7.815890] RAX: 000000000000001d RBX: ffffc90000227d28 RCX: ffffffff8182be78
[ 7.836057] RDX: 0000000000000001 RSI: 0000000000000202 RDI: 0000000000000202
[ 7.856612] RBP: ffffc90000227c48 R08: 0000000000000000 R09: 0000000000000001
[ 7.877561] R10: 00000000000001c0 R11: 00000000000001c0 R12: 0000000000000000
[ 7.897072] R13: ffff88003d96f400 R14: ffff88003dac6410 R15: ffff88003dac6420
[ 7.917403] FS: 00007f77f42d9700(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 7.938293] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7.958364] CR2: 0000000000000010 CR3: 000000003ccbb000 CR4: 00000000000006f0
[ 7.978028] Stack:
[ 7.997120] ffff88003dac6000 ffff88003dac6410 0000000058049d01 ffffc90000227d28
[ 8.016993] ffff88003dac6000 ffff88003dac6410 ffff88003dac6420 ffffc90000227c98
[ 8.039505] ffffffff814f225d 0000001800227c98 000000090000002a 0000000900000011
[ 8.059985] Call Trace:
[ 8.080110] [<ffffffff814f225d>] __rtc_set_alarm+0x8d/0xa0
[ 8.099421] [<ffffffff814f2389>] rtc_timer_enqueue+0x119/0x190
[ 8.119925] [<ffffffff814f2e6e>] rtc_update_irq_enable+0xbe/0x100
[ 8.140583] [<ffffffff814f3bb0>] rtc_dev_ioctl+0x3c0/0x480
[ 8.161162] [<ffffffff81146b6a>] ? user_path_at_empty+0x3a/0x50
[ 8.182717] [<ffffffff8114aa36>] do_vfs_ioctl+0x96/0x5c0
[ 8.204624] [<ffffffff8113e066>] ? vfs_stat+0x16/0x20
[ 8.225994] [<ffffffff8113e135>] ? SyS_newstat+0x15/0x30
[ 8.247043] [<ffffffff8114afa7>] SyS_ioctl+0x47/0x80
[ 8.267191] [<ffffffff815f5c77>] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 8.288719] Code: 6a 81 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 89 f3 48 c7 c6 20 c4 78 81 48 83 ec 10 e8 8f 00 ef ff 4d 8b a5 a0 00 00 00 <41> 8b 44 24 10 85 c0 0f 8e 2b 02 00 00 4c 89 ef 31 c0 b9 53 01
[ 8.335233] RIP [<ffffffff814f5b08>] cmos_set_alarm+0x38/0x280
[ 8.357096] RSP <ffffc90000227c10>
[ 8.379051] CR2: 0000000000000010
[ 8.401736] ---[ end trace 5cbcd83a1f225ed3 ]---
This occur only when CONFIG_DEBUG_TEST_DRIVER_REMOVE is enabled and
CONFIG_RTC_DRV_CMOS builtin.
When cmos_set_alarm() is called dev is NULL and so trigger the deref via
cmos->irq
The problem comes from that the device is removed but no remove function
are called due to _exit_p().
This patch remove all _exit_p() annotation.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
A bug fix for the ACPI side of this driver caused a harmless
build warning:
drivers/rtc/rtc-cmos.c:1115:13: error: 'cmos_check_acpi_rtc_status' defined but not used [-Werror=unused-function]
static void cmos_check_acpi_rtc_status(struct device *dev,
We can avoid the warning and simplify the driver at the same time
by removing the #ifdef for CONFIG_PM and rely on the SIMPLE_DEV_PM_OPS()
to set everything up correctly. cmos_resume() has to get marked
as __maybe_unused so we don't introduce another warning, and
the two variants of cmos_poweroff() can get merged into one using
an IS_ENABLED() check.
Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Some platform firmware may interfere with the RTC alarm over suspend,
resulting in the kernel and hardware having different ideas about system
state but also potentially causing problems with firmware that assumes the
OS will clean this case up. This patch restores the RTC alarm on resume
to ensure that kernel and hardware are in sync.
The case we've seen is Intel Rapid Start, which is a firmware-mediated
feature that automatically transitions systems from suspend-to-RAM to
suspend-to-disk without OS involvement. It does this by setting the RTC
alarm and a flag that indicates that on wake it should perform the
transition rather than re-starting the OS. However, if the OS has set a
wakeup alarm that would wake the machine earlier, it refuses to overwrite
it and allows the system to wake instead.
This fails in the following situation:
1) User configures Intel Rapid Start to transition after (say) 15
minutes
2) User suspends to RAM. Firmware sets the wakeup alarm for 15 minutes
in the future
3) User resumes after 5 minutes. Firmware does not reset the alarm, and
as such it is still set for 10 minutes in the future
4) User suspends after 5 minutes. Firmware notices that the alarm is set
for 5 minutes in the future, which is less than the 15 minute transition
threshold. It therefore assumes that the user wants the machine to wake
in 5 minutes
5) System resumes after 5 minutes
The worst case scenario here is that the user may have put the system in a
bag between (4) and (5), resulting in it running in a confined space and
potentially overheating. This seems reasonably important. The Rapid
Start support code got added in 3.11, but it can be configured in the
firmware regardless of kernel support.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Currently ACPI-driven alarms are not cleared when they wake the
system. As consequence, expired alarms must be manually cleared to
program a new alarm. Fix this by correctly handling ACPI-driven
alarms.
More specifically, the ACPI specification [1] provides for two
alternative implementations of the RTC. Depending on the
implementation, the driver either clear the alarm from the resume
callback or from ACPI interrupt handler:
- The platform has the RTC wakeup status fixed in hardware
(ACPI_FADT_FIXED_RTC is 0). In this case the driver can determine
if the RTC was the reason of the wakeup from the resume callback
by reading the RTC status register.
- The platform has no fixed hardware feature event bits. In this
case a GPE is used to wake the system and the driver clears the
alarm from its handler.
[1] http://www.acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
We have observed on few x86 machines with rtc-cmos device that
hpet_rtc_interrupt() is called just after irq registration and before
cmos_do_probe() could call hpet_rtc_timer_init().
So, neither hpet_default_delta nor hpet_t1_cmp is initialized by the time
interrupt is raised in the given situation, and this results in NMI
watchdog LOCKUP.
It has only been observed sporadically on kdump secondary kernels.
See the call trace:
---<-snip->---
[ 27.913194] Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 0
[ 27.915371] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-342.el7.x86_64 #1
[ 27.917503] Hardware name: HP ProLiant DL160 Gen8, BIOS J03 02/10/2014
[ 27.919455] ffffffff8186a728 0000000059c82488 ffff880034e05af0 ffffffff81637bd4
[ 27.921870] ffff880034e05b70 ffffffff8163144a 0000000000000010 ffff880034e05b80
[ 27.924257] ffff880034e05b20 0000000059c82488 0000000000000000 0000000000000000
[ 27.926599] Call Trace:
[ 27.927352] <NMI> [<ffffffff81637bd4>] dump_stack+0x19/0x1b
[ 27.929080] [<ffffffff8163144a>] panic+0xd8/0x1e7
[ 27.930588] [<ffffffff8111d3e0>] ? restart_watchdog_hrtimer+0x50/0x50
[ 27.932502] [<ffffffff8111d4a2>] watchdog_overflow_callback+0xc2/0xd0
[ 27.934427] [<ffffffff811612c1>] __perf_event_overflow+0xa1/0x250
[ 27.936232] [<ffffffff81161d94>] perf_event_overflow+0x14/0x20
[ 27.937957] [<ffffffff81032ae8>] intel_pmu_handle_irq+0x1e8/0x470
[ 27.939799] [<ffffffff8164164b>] perf_event_nmi_handler+0x2b/0x50
[ 27.941649] [<ffffffff81640d99>] nmi_handle.isra.0+0x69/0xb0
[ 27.943348] [<ffffffff81640f49>] do_nmi+0x169/0x340
[ 27.944802] [<ffffffff816401d3>] end_repeat_nmi+0x1e/0x2e
[ 27.946424] [<ffffffff81056ee5>] ? hpet_rtc_interrupt+0x85/0x380
[ 27.948197] [<ffffffff81056ee5>] ? hpet_rtc_interrupt+0x85/0x380
[ 27.949992] [<ffffffff81056ee5>] ? hpet_rtc_interrupt+0x85/0x380
[ 27.951816] <<EOE>> <IRQ> [<ffffffff8108f5a3>] ? run_timer_softirq+0x43/0x340
[ 27.954114] [<ffffffff8111e24e>] handle_irq_event_percpu+0x3e/0x1e0
[ 27.955962] [<ffffffff8111e42d>] handle_irq_event+0x3d/0x60
[ 27.957635] [<ffffffff811210c7>] handle_edge_irq+0x77/0x130
[ 27.959332] [<ffffffff8101704f>] handle_irq+0xbf/0x150
[ 27.960949] [<ffffffff8164a86f>] do_IRQ+0x4f/0xf0
[ 27.962434] [<ffffffff8163faed>] common_interrupt+0x6d/0x6d
[ 27.964101] <EOI> [<ffffffff8163f43b>] ? _raw_spin_unlock_irqrestore+0x1b/0x40
[ 27.966308] [<fffff8111ff07>] __setup_irq+0x2a7/0x570
[ 28.067859] [<ffffffff81056e60>] ? hpet_cpuhp_notify+0x140/0x140
[ 28.069709] [<ffffffff8112032c>] request_threaded_irq+0xcc/0x170
[ 28.071585] [<ffffffff814b24a6>] cmos_do_probe+0x1e6/0x450
[ 28.073240] [<ffffffff814b2710>] ? cmos_do_probe+0x450/0x450
[ 28.074911] [<ffffffff814b27cb>] cmos_pnp_probe+0xbb/0xc0
[ 28.076533] [<ffffffff8139b245>] pnp_device_probe+0x65/0xd0
[ 28.078198] [<ffffffff813f8ca7>] driver_probe_device+0x87/0x390
[ 28.079971] [<ffffffff813f9083>] __driver_attach+0x93/0xa0
[ 28.081660] [<ffffffff813f8ff0>] ? __device_attach+0x40/0x40
[ 28.083662] [<ffffffff813f6a13>] bus_for_each_dev+0x73/0xc0
[ 28.085370] [<ffffffff813f86fe>] driver_attach+0x1e/0x20
[ 28.086974] [<ffffffff813f8250>] bus_add_driver+0x200/0x2d0
[ 28.088634] [<ffffffff81ade49a>] ? rtc_sysfs_init+0xe/0xe
[ 28.090349] [<ffffffff813f9704>] driver_register+0x64/0xf0
[ 28.091989] [<ffffffff8139b070>] pnp_register_driver+0x20/0x30
[ 28.093707] [<ffffffff81ade4ab>] cmos_init+0x11/0x71
---<-snip->---
This patch moves hpet_rtc_timer_init() before IRQ registration, so that we
can gracefully handle such spurious interrupts. It also masks HPET RTC
interrupts, in case IRQ registration fails.
We were able to reproduce the problem in maximum 15 trials of kdump
secondary kernel boot on an hp-dl160gen8 FCoE host machine without this
patch. However, more than 35 trials went fine after applying this patch.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Since commit d68778b80dd7 ("rtc: initialize output parameter for read
alarm to "uninitialized"") there is no need to explicitly set
unsupported members to -1. So drop the respective assignments from
drivers.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
nn10300 has a dependency on mc146818_get_time/mc146818_set_time,
which we want to move from the mc146818rtc.h header into the
rtc subsystem, which in turn is not usable on mn10300.
This changes mn10300 to use the modern rtc-cmos driver instead
of the old RTC driver, and that in turn lets us completely
remove the read_persistent_clock/update_persistent_clock callbacks.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Drivers should not really include stuff from asm-generic directly,
and the PC-style cmos rtc driver does this in order to reuse the
mc146818 implementation of get_rtc_time/set_rtc_time rather than
the architecture specific one for the architecture it gets built for.
To make it more obvious what is going on, this moves and renames the
two functions into include/linux/mc146818rtc.h, which holds the
other mc146818 specific code. Ideally it would be in a .c file,
but that would require extra infrastructure as the functions are
called by multiple drivers with conflicting dependencies.
With this change, the asm-generic/rtc.h header also becomes much
more generic, so it can be reused more easily across any architecture
that still relies on the genrtc driver.
The only caller of the internal __get_rtc_time/__set_rtc_time
functions is in arch/alpha/kernel/rtc.c, and we just change those
over to the new naming.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
built-in or as a module, use that macro instead of open coding the same.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
The Microsoft Surface 3 tablet shares interrupt line between RTC and one of SPI
controllers. However, the rtc_cmos driver doesn't allow shared interrupts and
user sees the following warning
genirq: Flags mismatch irq 8. 00000080 (8086228E:02) vs. 00000000 (rtc0)
...
[<ffffffffa004eb01>] pxa2xx_spi_probe+0x151/0x600 [spi_pxa2xx_platform]
Allow RTC driver to use shared interrupts.
Seems we are on the safe side to do just this simple change since
cmos_interrupt() handler checks for the actual hardware status anyway.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
The change removes redundant sysfs binary file boundary checks, since
this task is already done on caller side in fs/sysfs/file.c
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Commit d5a1c7e3fc38 ("rtc-cmos: Add an alarm disable quirk") that
added a special quirk is not needed because [PATCH 1/2] of this
patchset makes the kernel more robust:
rtc-cmos: Cancel alarm timer if alarm time is equal to now+1 seconds
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
Tested-by: Egbert Eich <eich@suse.de>
Tested-by: Diego Ercolani <diego.ercolani@gmail.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Steps to reproduce the problem:
1) Enable RTC wake-up option in BIOS Setup
2) Issue one of these commands in the OS: "poweroff"
or "shutdown -h now"
3) System will shut down and then reboot automatically
Root-cause of the issue:
1) During the shutdown process, the hwclock utility is used
to save the system clock to hardware clock (RTC).
2) The hwclock utility invokes ioctl() with RTC_UIE_ON. The
kernel configures the RTC alarm for the periodic interrupt
(every 1 second).
3) The hwclock uitlity closes the /dev/rtc0 device, and the
kernel disables the RTC alarm irq (AIE bit of Register B)
via ioctl() with RTC_UIE_OFF. But, the configured alarm
time is the current_time + 1.
4) After the next 1 second is elapsed, the AF (alarm
interrupt flag) of Register C is set.
5) The S5 handler in BIOS is invoked to configure alarm
registers (enable AIE bit and configure alarm date/time).
But, BIOS does not clear the previous interrupt status
during alarm configuration. Therefore, "AF=AIE=1" causes
the rtc device to trigger an interrupt.
6) So, the machine reboots automatically right after shutdown.
This patch cancels the alarm timer if the following condictions are
met (suggested by Alexandre):
1) The configured alarm time is equal to current_time + 1
seconds.
2) The AIE timer is not in use.
The member 'alarm_expires' is introduced in struct cmos_rtc because
of the following reasons:
1) The configured alarm time can be retrieved from
cmos_read_alarm(), but we need to take the 'wrapped
timestamp' and 'time rollover' into consideration. The
function __rtc_read_alarm() eliminates the concerns. To
avoid the duplicated code in the lower level RTC driver,
invoking __rtc_read_alarm from the lower level RTC driver
is not encouraged. Moreover, the compilation error 'the
undefined __rtc_read_alarm" is observed if the lower level
RTC driver is compiled as a kernel module.
2) The uie_rtctimer.node.expires and aie_timer.node.expires can
be retrieved for the configured alarm time. But, the problem
is that either of them might configure the CMOS alarm time.
We cannot make sure UIE timer or AIE tiemr configured the
CMOS alarm time before. (uie_rtctimer or aie_timer is enabled
and then is disabled).
3) The patch introduces the member 'alarm_expires' to keep the
newly configured alarm time, so the above-mentioned concerns
can be eliminated.
The issue goes away after 20-time shutdown tests.
Signed-off-by: Adrian Huang <ahuang12@lenovo.com>
Tested-by: Egbert Eich <eich@suse.de>
Tested-by: Diego Ercolani <diego.ercolani@gmail.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
|
|
Neaten the logging a bit by adding #define pr_fmt
Miscellanea:
o Remove __FILE__/__func__ uses
o Coalesce formats adding missing spaces
o Align arguments
o (rtc-cmos) Integrated 2 consecutive messages
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Joshua Kinard <kumba@gentoo.org>
Cc: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The seq_printf return value, because it's frequently misused,
will eventually be converted to void.
See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to
seq_has_overflowed() and make public")
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Commit b5ada4600dfd ("drivers/rtc/rtc-cmos.c: fix compilation warning
when !CONFIG_PM_SLEEP") broke wakeup from S5 by making cmos_poweroff a
nop unless CONFIG_PM_SLEEP was defined.
Fix this by restricting the #ifdef to cmos_resume and restoring the old
dependency on CONFIG_PM for cmos_suspend and cmos_poweroff.
Signed-off-by: Daniel Glöckner <daniel-gl@gmx.net>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This brings in drivers/char/rtc.c functionality required for DECstation
and, should the maintainers decide to switch, Alpha systems to use
rtc-cmos.
Specifically these features are made available:
* RTC iomem rather than x86/PCI port I/O mapping, controlled with the
RTC_IOMAPPED macro as with the original driver. The DS1287A chip in all
DECstation systems is mapped in the host bus address space as a
contiguous block of 64 32-bit words of which the least significant byte
accesses the RTC chip for both reads and writes. All the address and
data window register accesses are made transparently by the chipset glue
logic so that the device appears directly mapped on the host bus.
* A way to set the size of the address space explicitly with the
newly-added `address_space' member of the platform part of the RTC
device structure. This avoids the unreliable heuristics that does not
work in a setup where the RTC is not explicitly accessed with the usual
address and data window register pair.
* The ability to use the RTC periodic interrupt as a system clock
device, which is implemented by arch/mips/kernel/cevt-ds1287.c for
DECstation systems and takes the RTC interrupt away from the RTC driver.
Eventually hooking back to the clock device's interrupt handler should
be possible for the purpose of the alarm clock and possibly also
update-in-progress interrupt, but this is not done by this change.
o To avoid interfering with the clock interrupt all the places where
the RTC interrupt mask is fiddled with are only executed if and IRQ
has been assigned to the RTC driver.
o To avoid changing the clock setup Register A is not fiddled with
if CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of
the platform part of the RTC device structure. Originally, in
drivers/char/rtc.c, this was keyed with the absence of the RTC
interrupt, just like the interrupt mask, but there only the periodic
interrupt frequency is set, whereas rtc-cmos also sets the divider
bits. Therefore a new flag is introduced so that systems where the
RTC interrupt is not usable rather than used as a system clock device
can fully initialise the RTC.
* A small clean-up is made to the IRQ assignment code that makes the IRQ
number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error
happens to be returned by platform_get_irq) where no IRQ has been
assigned to the RTC driver (NO_IRQ might be another candidate, but it
looks like this macro has inconsistent or missing definitions and
limited use and might therefore be unsafe).
Verified to work correctly with a DECstation 5000/240 system.
[akpm@linux-foundation.org: fix weird code layout]
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
CONFIG_PM will be set also if only CONFIG_PM_RUNTIME is set which causes
the compiler to emit following warning:
drivers/rtc/rtc-cmos.c:845:12: warning: =E2=80=98cmos_resume=E2=80=99 defined but not used [-Wunused-function]
Fix this by using CONFIG_PM_SLEEP instead of CONFIG_PM and removing it
from the driver pm ops as this has been taken care by
SIMPLE_DEV_PM_OPS() already.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
If hpet_register_irq_handler() fails, cmos_do_probe() will incorrectly
return 0.
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
device_driver.name is "const char *"
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
functionality to disable the RTC wake alarm when shutting down the box.
However, there are at least two b0rked BIOSes we know about:
https://bugzilla.novell.com/show_bug.cgi?id=812592
https://bugzilla.novell.com/show_bug.cgi?id=805740
where, when wakeup alarm is enabled in the BIOS, the machine reboots
automatically right after shutdown, regardless of what wakeup time is
programmed.
Bisecting the issue lead to this patch so disable its functionality with
a DMI quirk only for those boxes.
Cc: Brecht Machiels <brecht@mos6581.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Rabin Vincent <rabin.vincent@stericsson.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
[jstultz: Changed variable name for clarity, added extra dmi entry]
Tested-by: Brecht Machiels <brecht@mos6581.org>
Tested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
|
Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly. This is a cosmetic change to make
the code simpler and enhance the readability.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Driver core sets the driver data to NULL upon device_release or on probe
failure.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Convert drivers/rtc/rtc-cmos to use dev_pm_ops instead of legacy pm_ops.
This patch depends on pnp driver bus ops change to invoke pnp_driver
dev_pm_ops.
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Cc: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Leonidas Da Silva Barbosa <leosilva@linux.vnet.ibm.com>
Cc: Ashley Lai <ashley@ashleylai.com>
Cc: Rajiv Andrade <mail@srajiv.net>
Cc: Marcel Selhorst <tpmdd@selhorst.net>
Cc: Sirrix AG <tpmdd@sirrix.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Peter Hüwe <PeterHuewe@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The bios may clear the rtc control register when resuming the system. Since the
cmos interrupt handler may now be run before the rtc_cmos is resumed, this can
cause the interrupt handler to ignore an alarm since the alarm bit is not set in
the rtc control register. To work around this, check if the rtc_cmos is
suspended and use the stored value for the rtc control register.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Fixes the following types of issues:
ERROR: space required after that ',' (ctx:VxV)
WARNING: please, no spaces at the start of a line
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
During resume, we call hpet_rtc_timer_init after masking an irq bit in
hpet. This will cause the call to hpet_disable_rtc_channel to be undone
if RTC_AIE is the only bit not masked.
Allowing the cmos interrupt handler to run before resuming caused some
issues where the timer for the alarm was not removed. This would cause
other, later timers to not be cleared, so utilities such as hwclock
would time out when waiting for the update interrupt.
[akpm@linux-foundation.org: coding-style tweak]
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
There's a bug where rtc alarms are ignored after the rtc cmos suspends
but before the system finishes suspend. Since hpet emulation is
disabled and it still handles the interrupts, a wake event is never
registered which is done from the rtc layer.
This patch reverts commit d1b2efa83fbf ("rtc: disable hpet emulation on
suspend") which disabled hpet emulation. To fix the problem mentioned
in that commit, hpet_rtc_timer_init() is called directly on resume.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Fix the checkpatch warning as below:
WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This eliminates having an #ifdef returning NULL for the case when OF is
disabled. Maintains consistency in cases where OF is always selected.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
CONFIG_HOTPLUG is going away as an option. As a result, the __dev*
markings need to be removed.
This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.
Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.
Cc: Bill Pemberton <wfp5p@virginia.edu>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mike Frysinger <vapier.adi@gmail.com>
Cc: Wan ZongShun <mcuos.com@gmail.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If an RTC alarm fires just as suspend is happening, it is possible for
suspend to complete and the alarm to be missed.
To avoid the race, we must register the event with the PM core.
As the event is made visible to userspace through a thread which is
only scheduled by the interrupt, we need a pm_stay_awake/pm_relax
pair preventing suspend from the interrupt until the thread completes
its work.
This makes the pm_wakeup_event() call in cmos_interrupt unnecessary as
it provides suspend protection for all RTCs that use rtc_update_irq.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
When suspending the system with an important RTC wake alarm active,
it is possible that the RTC alarm will expire before the system has
gone to sleep (e.g. short alarm timer, or an unusually long suspend
routine).
If this happens, the RTC alarm should trigger a wakeup event, possibly
aborting system suspend. This condition can be detected in the form
of an RTC alarm interrupt.
Signed-off-by: Paul Fox <pgf@laptop.org>
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
When the ACPI-driven RTC alarm wakes the system, report it as a wakeup
event. This allows userspace to determine that the reason for system
wakeup was RTC alarm.
Signed-off-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
|
|
Since commit e58aa3d2d0cc ("genirq: run irq handlers with interrupts
disabled") we run all interrupt handlers with interrupts disabled and we
even check and yell when an interrupt handler returns with interrupts
enabled - see commit b738a50a2026 ("genirq: warn when handler enables
interrupts").
So now this flag is a NOOP and can be removed.
Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Fix writing to NVRAM bank 2 in rtc-cmos driver. It never worked since its
introduction in 2.6.28 because of a typo.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Several fixes as well where the +1 was missing.
Done via coccinelle scripts like:
@@
struct resource *ptr;
@@
- ptr->end - ptr->start + 1
+ resource_size(ptr)
and some grep and typing.
Mostly uncompiled, no cross-compilers.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'x86-platform-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (27 commits)
x86: Clean up apic.c and apic.h
x86: Remove superflous goal definition of tsc_sync
x86: dt: Correct local apic documentation in device tree bindings
x86: dt: Cleanup local apic setup
x86: dt: Fix OLPC=y/INTEL_CE=n build
rtc: cmos: Add OF bindings
x86: ce4100: Use OF to setup devices
x86: ioapic: Add OF bindings for IO_APIC
x86: dtb: Add generic bus probe
x86: dtb: Add support for PCI devices backed by dtb nodes
x86: dtb: Add device tree support for HPET
x86: dtb: Add early parsing of IO_APIC
x86: dtb: Add irq domain abstraction
x86: dtb: Add a device tree for CE4100
x86: Add device tree support
x86: e820: Remove conditional early mapping in parse_e820_ext
x86: OLPC: Make OLPC=n build again
x86: OLPC: Remove extra OLPC_OPENFIRMWARE_DT indirection
x86: OLPC: Cleanup config maze completely
x86: OLPC: Hide OLPC_OPENFIRMWARE config switch
...
Fix up conflicts in arch/x86/platform/ce4100/ce4100.c
|
|
Now that the generic code handles UIE mode irqs via periodic
alarm interrupts, no one calls the
rtc_class_ops->update_irq_enable() method anymore.
This patch removes the driver hooks and implementations of
update_irq_enable if no one else is calling it.
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
CC: rtc-linux@googlegroups.com
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
|
With the generic rtc code now emulating PIE mode irqs via an
hrtimer, no one calls the rtc_class_ops->irq_set_freq call.
This patch removes the hook and deletes the driver functions
if no one else calls them.
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
CC: rtc-linux@googlegroups.com
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
|
With PIE mode interrupts now emulated in generic code via an hrtimer,
no one calls rtc_class_ops->irq_set_state(), so this patch removes it
along with driver implementations.
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Alessandro Zummo <a.zummo@towertech.it>
CC: Marcelo Roberto Jimenez <mroberto@cpti.cetuc.puc-rio.br>
CC: rtc-linux@googlegroups.com
Signed-off-by: John Stultz <john.stultz@linaro.org>
|
|
This allows to load the OF driver based informations from the device
tree. Systems without BIOS may need to perform some initialization.
PowerPC creates a PNP device from the OF information and performs this
kind of initialization in their private PCI quirk. This looks more
generic.
This patch also avoids registering the platform RTC driver on X86 if
we have a device tree blob. Otherwise we would setup the device based
on the hardcoded information in arch/x86 rather than the device tree
based one.
[ tglx: Changed "int of_have_populated_dt()" to bool as recommended by
Grant ]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Cc: sodaville@linutronix.de
Cc: devicetree-discuss@lists.ozlabs.org
Cc: rtc-linux@googlegroups.com
Cc: Alessandro Zummo <a.zummo@towertech.it>
LKML-Reference: <1298405266-1624-12-git-send-email-bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
rtc-cmos was setting suspend/resume hooks at the device_driver level.
However, the platform bus code (drivers/base/platform.c) only looks for
resume hooks at the dev_pm_ops level, or within the platform_driver.
Switch rtc_cmos to use dev_pm_ops so that suspend/resume code is executed
again.
Paul said:
: The user visible symptom in our (XO laptop) case was that rtcwake would
: fail to wake the laptop. The RTC alarm would expire, but the wakeup
: wasn't unmasked.
:
: As for severity, the impact may have been reduced because if I recall
: correctly, the bug only affected platforms with CONFIG_PNP disabled.
Signed-off-by: Paul Fox <pgf@laptop.org>
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: <stable@kernel.org> [2.6.37.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The following warning is seen while compilation of PowerPC kernel:
CC drivers/rtc/rtc-cmos.o
drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes
of RTC+NVRAM address space, not 64 bytes.
Fix it by adding defined(__powerpc__).
Signed-off-by: Srikanth Krishnakar <skrishna@mvista.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
|
Because CONFIG_PM is a precondition to CONFIG_ACPI, the ifdef CONFIG_PM
within ifdef CONFIG_ACPI is redundant.
Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
Acked-by: Wan ZongShun <mcuos.com@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The bug is an oops when dev_get_drvdata() returned null in
cmos_update_irq_enable(). The call tree looks like this:
rtc_dev_ioctl()
=> rtc_update_irq_enable()
=> cmos_update_irq_enable()
It's caused by a race condition in the module initialization. It is
rtc_device_register() which makes the ioctl operations live so I moved
the call to dev_set_drvdata() before the call to rtc_device_register().
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=15963
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Tested-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Malte Schroder <maltesch@gmx.de>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
As a follow-up to the thread about RTC support for some Loongson 2E/2F
boards, this patch tries to address the "REVISIT"/"FIXME" comments about
rtc binary mode handling and allow rtc to work with rtc in binary mode.
I've also raised the message about 24-h mode not supported to warning
otherwise, one may end up with no rtc without any message in the kernel
log.
Signed-off-by: Arnaud Patard <apatard@mandriva.com>
To: linux-mips@linux-mips.org
To: rtc-linux@googlegroups.com
Cc: david-b@pacbell.net
Cc: a.zummo@towertech.it
Cc: akpm@linux-foundation.org
Patchwork: http://patchwork.linux-mips.org/patch/1158/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
This allows bin_attr->read,write,mmap callbacks to check file specific data
(such as inode owner) as part of any privilege validation.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit abd6633c67925f90775bb74755f9c547e30f1f20 ("pnp: add a shutdown
method to pnp drivers") adds shutdown method to bus driver blindly. With
it, driver->shutdown is no longer valid.
Use pnp_driver->shutdown instead.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14889
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Reported-by: Malte Schröder <maltesch@gmx.de>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: David Hardeman <david@hardeman.nu>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: <stable@kernel.org> [2.6.32.x]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This patch fixes the following warning with RTC_LIB on MIPS:
drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes of
RTC+NVRAM address space, not 64 bytes.
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: Arnaud Patard <apatard@mandriva.com>
Cc: linux-mips@linux-mips.org
Cc: rtc-linux@googlegroups.com
Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Patchwork: http://patchwork.linux-mips.org/patch/570/
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
Drop ioctl function that handles RTC_AIE/RTC_UIE, and use instead the
rtc subsystem API (alarm_irq_enable/update_irq_enable callbacks).
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
I noticed that rtc wont generate interrupts after a resume from disk.
Here hpet rtc emulation is used.
Problem is that rtc hpet comparator, isn't reinitialized after resume.
Easiest way to solve this, is always mask all hpet interrupts on suspend
This is triggered, when suspending with alarm set.
Otherwise, hpet driver will think it doesn't need to reinitialize
the rtc comparator, thus rtc interrupts won't work.
This emulation isn't need for wakealarm.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
rtc-cmos has two drivers, one PNP and one platform. When PNP has not
succeeded probing, platform is registered. However, it tries to
unregister both drivers unconditionally, instead of only unregistering
those that were successfully registered. This causes runtime warnings to
be emitted from the driver core code.
Fix this with a boolean variable for each driver indicating whether
registering was successful.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Greg KH <greg@kroah.com>
Cc: Ozan Caglayan <ozan@pardus.org.tr>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
With no IRQ available/defined, RTC-CMOS driver prints something like:
rtc0: alarms up to one no, y3k, 114 bytes nvram
^^^^
I guess the following is a bit easier to understand:
rtc0: no alarms, y3k, 114 bytes nvram
Signed-off-by: Krzysztof Halasa <khc@pm.waw.pl>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Move the power of 2 check on frequencies down into individual rtc drivers
This is to allow for non power of 2 real time clock periodic interrupts
such as those on the pxa27x to be found in the new pxa27x-rtc driver
Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This patch fixes a bunch of irq checking misuses. Most drivers were
getting irq via platform_get_irq(), which returns -ENXIO or r->start.
rtc-cmos.c is special. It is using PNP and platform bindings. Hopefully
nobody is using PNP IRQ 0 for RTC. So the changes should be safe.
rtc-sh.c is using platform_get_irq, but was storing a result into an
unsigned type, then was checking for < 0. This is fixed now.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Acked-By: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
-rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
+rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
Signed-off-by: Frans Pop <elendil@planet.nl>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Tejun's commit 7b595756ec1f49e0049a9e01a1298d53a7faaa15 made sysfs
attribute->owner unnecessary. But the field was left in the structure to
ease the merge. It's been over a year since that change and it is now
time to start killing attribute->owner along with its users - one arch at
a time!
This patch is attempt #1 to get rid of attribute->owner only for
CONFIG_X86_64 or CONFIG_X86_32 . We will deal with other arches later on
as and when possible - avr32 will be the next since that is something I
can test. Compile (make allyesconfig / make allmodconfig / custom config)
and boot tested.
akpm: the idea is that we put the declaration of sttribute.owner inside
`#ifndef CONFIG_X86'. But that proved to be too ambitious for now because
new usages kept on turning up in subsystem trees.
[akpm: remove the ifdef for now]
Signed-off-by: Parag Warudkar <parag.lkml@gmail.com>
Cc: Greg KH <greg@kroah.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Tejun Heo <htejun@gmail.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Roland Dreier <rolandd@cisco.com>
Cc: David Brownell <david-b@pacbell.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Change drivers/rtc/ to use the new bcd2bin/bin2bcd functions instead of
the obsolete BCD_TO_BIN/BIN_TO_BCD/BCD2BIN/BIN2BCD macros.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Teach rtc-cmos about the second bank of registers found on most modern x86
systems, giving access to 128 bytes more NVRAM.
This version only sees that extra NVRAM when both register banks are
provided as part of *one* PNP resource. Since BIOS on some systems
presents them using two IO resources, and nothing merges them, this can't
always show all the NVRAM. (We're supposed to be able to use PNP id
PNP0b01 too, but BIOS tables doesn't often seem to use that particular
option.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
We shouldn't rely on "pnp_platform_devices" to tell us whether there
is a PNP RTC device.
I introduced "pnp_platform_devices", but I think it was a mistake.
All it tells us is whether we found any PNPBIOS or PNPACPI devices.
Many machines have some PNP devices, but do not describe the RTC
via PNP. On those machines, we need to do the platform driver probe
to find the RTC.
We should just register the PNP driver and see whether it claims anything.
If we don't find a PNP RTC, fall back to the platform driver probe.
This (in conjunction with the arch/x86/kernel/rtc.c patch to add
a platform RTC device when PNP doesn't have one) should resolve
these issues:
http://bugzilla.kernel.org/show_bug.cgi?id=11580
https://bugzilla.redhat.com/show_bug.cgi?id=451188
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Reported-by: Rik Theys <rik.theys@esat.kuleuven.be>
Reported-by: shr_msn@yahoo.com.tw
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Move rtc_wake_setup() from drivers/acpi/glue.c into the RTC driver
in drivers/rtc/rtc-cmos.c.
This removes the ordering constraint between the module_init(acpi_rtc_init)
and the cmos_do_probe() code that depends on it.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
Conflicts:
arch/sparc64/kernel/pci_psycho.c
|
|
Update rtc-cmos shutdown handling to leave RTC alarms active, resolving
http://bugzilla.kernel.org/show_bug.cgi?id=11411 on several boards. There
are still some systems where the ACPI event handling doesn't cooperate.
(Possibly related to bugid 11312, reporting the spontaneous disabling of
RTC events.)
Bug 11411 reported that changes to work around some ACPI event issues
broke wake-from-S5 handling, as used for DVR applications. (They like to
power off, then wake later to record programs.)
[yakui.zhao@intel.com: add shutdown for PNP devices]
[dbrownell@users.sourceforge.net: update comments]
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Stefan Bauer <stefan.bauer@cs.tu-chemnitz.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Add Sparc to the Kconfig depends list.
Add __sparc___ to address_sparc = 128 ifdef.
Finally, don't be concerned about 24-hour BCD mode support if the RTC
doesn't have a valid IRQ. We won't even use the alarm code in this
case and the Sparc RTCs have this limitation.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This fixes kernel http://bugzilla.kernel.org/show_bug.cgi?id=11112 (bogus
RTC update IRQs reported) for rtc-cmos, in two ways:
- When HPET is stealing the IRQs, use the first IRQ to grab
the seconds counter which will be monitored (instead of
using whatever was previously in that memory);
- In sane IRQ handling modes, scrub out old IRQ status before
enabling IRQs.
That latter is done by tightening up IRQ handling for rtc-cmos everywhere,
also ensuring that when HPET is used it's the only thing triggering IRQ
reports to userspace; net object shrink.
Also fix a bogus HPET message related to its RTC emulation.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Report-by: W Unruh <unruh@physics.ubc.ca>
Cc: Andrew Victor <avictor.za@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Resolve http://bugzilla.kernel.org/show_bug.cgi?id=11051 and other bugs
related to the way the HPET glue code in rtc-cmos was incomplete and
inconsistent:
* Switch the approach so that the basic driver code flow isn't
changed by having HPET ... instead, just have HPET shadow the
RTC_CONTROL irq enables and RTC_FREQ_SELECT data. It's only
coping with IRQ thievery, after all.
* Do that consistently (!!) to avoid problems when the HPET code
is out of sync with the real RTC intent. Examples include:
- cmos_procfs(), which now reports correct data
- cmos_irq_set_state() ... also removing the previous PIE_{ON,OFF}
ioctl support so only one code path manages "periodic" IRQs
- cmos_do_shutdown() ... currently a "just in case" change.
- cmos_suspend() and cmos_resume() ... also handling a bug that
was specific to HPET's IRQ thievery, where the alarm wasn't
disabled after waking the system
* Always call that HPET code under the RTC spinlock (it doesn't do
its own locking)
Also clean up the HPET glue:
* Add some comments explaining what's going on.
* Switch to having just one #ifdef for the HPET glue, and inline
functions (not #defines) to avoid some compiler warnings.
* Have the probe message also report when HPET IRQs are involved
This still leaves various holes in the HPET glue, like the emulated update
IRQs being out of sync with the RTC, alarms never using day or month
matches, and many extra IRQs (at 64 Hz).
[akpm@linux-foundation.org: fix build]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Tomas Janousek <tomi@nomi.cz>
Cc: Bernhard Walle <bwalle@suse.de>
Cc: Carlos R. Mafra <crmafra@ift.unesp.br>
Acked-by: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When CONFIG_HPET_EMULATE_RTC is defined the external declaration of
hpet_rtc_interrupt is redundant due to the inclusion of hpet.h.
When !CONFIG_HPET_EMULATE_RTC we make it clear that hpet_rtc_interrupt is
not used by defining it to return zero.
Signed-off-by: Carlos R. Mafra <crmafra@ift.unesp.br>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Recently (around 2.6.25) I've noticed that RTC no longer works for me. It
turned out this is because I use pnpacpi=off kernel option to work around
the parport_pc bugs. I always did so, but RTC used to work fine in the
past, and now it have regressed.
The patch fixes the problem by creating the platform device for the RTC
when PNP is disabled. This may also help running the PNP-enabled kernel
on an older PCs.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
Cc: David Brownell <david-b@pacbell.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
pnp_resource_table is going away soon, so use the more
generic public interfaces instead.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Acked-By: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
There is a bug in the function of cmos_set_alarm. RTC alarm time for October
can't be set correctly.
For October: 0x0A will be written into the RTC region (MONTH_ALARM) in current
kernel. But in fact 0x10 should be written. Wildcards are also not handled
correctly.
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Since 43cc71eed1250755986da4c0f9898f9a635cb3bf, the platform modalias is
prefixed with "platform:". Add MODULE_ALIAS() to the hotpluggable RTC
platform drivers, to re-enable module auto loading.
[dbrownell@users.sourceforge.net: more drivers, minor fix]
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Greg KH <greg@kroah.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
For the "cmos" RTC, have /proc/driver/rtc say whether HPET based IRQ
emulation is in effect. Given the problems we've had with this particular
hardware maldesign (and the fact that most BIOS code seems not to provide
the IRQ routing needed to use the saner HPET modes), this should help
troubleshooting.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
That patch adds the RTC emulation of the HPET timer to the new RTC_DRV_CMOS.
The old drivers/char/rtc.ko driver had that functionality and it's important
on new systems.
[akpm@linux-foundation.org: unbreak alpha build]
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@suse.de>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Robert Picco <Robert.Picco@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Start making the rtc-cmos alarm act more like a oneshot alarm by disabling
that alarm after its IRQ fires. (ACPI hooks are also needed.)
The Linux RTC framework has previously been a bit vague in this area, but
any other behavior is problematic and not very portable. RTCs with full
YYYY-MM-DD HH:MM[:SS] alarms won't have a problem here. Only ones with
partial match criteria, with the most visible example being the PC RTC, get
confused. (Because the criteria will match repeatedly.)
Update comments relating to that oneshot behavior and timezone handling.
(Timezones are another issue that's mostly visible with rtc-cmos. That's
because PCs often dual-boot MS-Windows, which likes its RTC to match local
wall-clock time instead of UTC.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This makes rtc-cmos export its NVRAM, like several other RTC drivers.
It still works within the limits of the current CMOS_READ/CMOS_WRITE calls,
which don't understand how to access multiple register banks. The primary
impact of that limitation is that Linux can't access the uppermost 128
bytes of NVRAM on many systems.
Note that this isn't aiming to be a drop-in replacement for the legacy
/dev/nvram support. (Presumably that has real users, and isn't just
getting carried forward automatically?) Userspace handles more work:
- When userspace code updates NVRAM, that will need to include
updating any platform-specific checksums that may apply.
- No /proc/driver/nvram file will parse and display NVRAM data
according to whichever boot firmware your board expects.
Also minor pnp-related updates: update a comment, remove dead code.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
I have a system here that actively relies upon RTC wake alarms, and it
has been failing (again) for a few days when attempting to use the
/sys/class/rtc/rtc?/wakealarm interface.
The old (fixed by Linus) /proc/ interface still works, but I'd like to
get it using the new one.
This patch fixes rtc-cmos to ignore the two upper bits when reading the
BCD mday (day of month) register from CMOS. Some systems (eg. mine)
seem to have the top bit set to "1" for some reason.
The older /proc/ interface ignores the upper bits, and so we should too.
Signed-off-by: Mark Lord <mlord@pobox.com>
Acked-by: David Brownell <david-b@pacbell.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Some cleanups for the rtc-cmos probe logic:
- Claim i/o ports with request_region() not request_resource(),
for better coexistence betwen platform and pnp bus glues.
- Claim those ports earlier, to help work around procfs bugs
(it allows duplicate names, like /proc/driver/rtc).
- Fix some glitches in cleanup code, notably a cut'n'paste-o
where the i/o port region might not get released during
cleanup after a probe fault.
And some comment clarifications, including noting that this code
must work with PNPBIOS not just PNPACPI..
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
RTC periodic IRQs are only defined to work for 2^N Hz values. This patch
moves that validity check into the infrastructure, so drivers don't need to
check it; and adds kerneldoc for the two interface functions related to
periodic IRQs. (One of which was quite mysterious until its first use was
recently checked in!)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Adds support for periodic irq enabling in rtc-cmos. This could be used by
the ALSA driver and is already being tested with the zaptel ztdummy module.
Signed-off-by: Alessandro Zummo <a.zummo@towertech.it>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Intel Macs (and possibly other machines) provide a PNP entry for the RTC,
but provide no IRQ. As a result the rtc-cmos driver doesn't allow wakeup
alarms. If the RTC is located at the legacy ioport range, assume that it's
on IRQ 8 unless the tables say otherwise.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Matthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Replace CONFIG_PNPACPI with CONFIG_PNP, so it loads on ACPI-less PNPBIOS
systems.
Signed-off-by: Marko Vrh <mvrh@freeshells.ch>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
I finally got around to testing the updated wakeup event hooks for rtc-cmos,
and they follow in two patches:
- Interface update ... when a simple enable_irq_wake() doesn't suffice,
the platform data can hold suspend/resume callback hooks.
- ACPI implementation ... provides callback hooks to do ACPI magic, and
eliminate the legacy /proc/acpi/alarm file.
The interface update could go into 2.6.21, but that's not essential; they
will be NOPs on most PCs, without the ACPI stuff.
I suspect the ACPI folk may have opinions about how to merge that second
patch, and how to obsolete that legacy procfs file. I'd like to see that
merge into 2.6.22 if possible...
As for how to kick it in ... two ways:
- The appended "rtcwake" program; updated since the last time it was
posted, it deals much better with timezones and DST.
- Write the /sys/class/rtc/.../wakealarm file, then go to sleep.
For some reason RTC wake from "swsusp" stopped working on a system where
it previously worked; the alarm setting appears to get clobbered. But
on the bright side, RTC wake from "standby" worked on a system that had
never been able to resume from that state before ... IDEACPI is my guess
as to why it finally started to work. It's the old "two steps forward,
one step back" dance, I guess.
- Dave
/* gcc -Wall -Os -o rtcwake rtcwake.c */
#include <stdio.h>
#include <getopt.h>
#include <fcntl.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <errno.h>
#include <time.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <linux/rtc.h>
/* constants from legacy PC/AT hardware */
#define RTC_PF 0x40
#define RTC_AF 0x20
#define RTC_UF 0x10
/*
* rtcwake -- enter a system sleep state until specified wakeup time.
*
* This uses cross-platform Linux interfaces to enter a system sleep state,
* and leave it no later than a specified time. It uses any RTC framework
* driver that supports standard driver model wakeup flags.
*
* This is normally used like the old "apmsleep" utility, to wake from a
* suspend state like ACPI S1 (standby) or S3 (suspend-to-RAM). Most
* platforms can implement those without analogues of BIOS, APM, or ACPI.
*
* On some systems, this can also be used like "nvram-wakeup", waking
* from states like ACPI S4 (suspend to disk). Not all systems have
* persistent media that are appropriate for such suspend modes.
*
* The best way to set the system's RTC is so that it holds the current
* time in UTC. Use the "-l" flag to tell this program that the system
* RTC uses a local timezone instead (maybe you dual-boot MS-Windows).
*/
static char *progname;
#ifdef DEBUG
#define VERSION "1.0 dev (" __DATE__ " " __TIME__ ")"
#else
#define VERSION "0.9"
#endif
static unsigned verbose;
static int rtc_is_utc = -1;
static int may_wakeup(const char *devname)
{
char buf[128], *s;
FILE *f;
snprintf(buf, sizeof buf, "/sys/class/rtc/%s/device/power/wakeup",
devname);
f = fopen(buf, "r");
if (!f) {
perror(buf);
return 0;
}
fgets(buf, sizeof buf, f);
fclose(f);
s = strchr(buf, '\n');
if (!s)
return 0;
*s = 0;
/* wakeup events could be disabled or not supported */
return strcmp(buf, "enabled") == 0;
}
/* all times should be in UTC */
static time_t sys_time;
static time_t rtc_time;
static int get_basetimes(int fd)
{
struct tm tm;
struct rtc_time rtc;
/* this process works in RTC time, except when working
* with the system clock (which always uses UTC).
*/
if (rtc_is_utc)
setenv("TZ", "UTC", 1);
tzset();
/* read rtc and system clocks "at the same time", or as
* precisely (+/- a second) as we can read them.
*/
if (ioctl(fd, RTC_RD_TIME, &rtc) < 0) {
perror("read rtc time");
return 0;
}
sys_time = time(0);
if (sys_time == (time_t)-1) {
perror("read system time");
return 0;
}
/* convert rtc_time to normal arithmetic-friendly form,
* updating tm.tm_wday as used by asctime().
*/
memset(&tm, 0, sizeof tm);
tm.tm_sec = rtc.tm_sec;
tm.tm_min = rtc.tm_min;
tm.tm_hour = rtc.tm_hour;
tm.tm_mday = rtc.tm_mday;
tm.tm_mon = rtc.tm_mon;
tm.tm_year = rtc.tm_year;
tm.tm_isdst = rtc.tm_isdst; /* stays unspecified? */
rtc_time = mktime(&tm);
if (rtc_time == (time_t)-1) {
perror("convert rtc time");
return 0;
}
if (verbose) {
if (!rtc_is_utc) {
printf("\ttzone = %ld\n", timezone);
printf("\ttzname = %s\n", tzname[daylight]);
gmtime_r(&rtc_time, &tm);
}
printf("\tsystime = %ld, (UTC) %s",
(long) sys_time, asctime(gmtime(&sys_time)));
printf("\trtctime = %ld, (UTC) %s",
(long) rtc_time, asctime(&tm));
}
return 1;
}
static int setup_alarm(int fd, time_t *wakeup)
{
struct tm *tm;
struct rtc_wkalrm wake;
tm = gmtime(wakeup);
wake.time.tm_sec = tm->tm_sec;
wake.time.tm_min = tm->tm_min;
wake.time.tm_hour = tm->tm_hour;
wake.time.tm_mday = tm->tm_mday;
wake.time.tm_mon = tm->tm_mon;
wake.time.tm_year = tm->tm_year;
wake.time.tm_wday = tm->tm_wday;
wake.time.tm_yday = tm->tm_yday;
wake.time.tm_isdst = tm->tm_isdst;
/* many rtc alarms only support up to 24 hours from 'now' ... */
if ((rtc_time + (24 * 60 * 60)) > *wakeup) {
if (ioctl(fd, RTC_ALM_SET, &wake.time) < 0) {
perror("set rtc alarm");
return 0;
}
if (ioctl(fd, RTC_AIE_ON, 0) < 0) {
perror("enable rtc alarm");
return 0;
}
/* ... so use the "more than 24 hours" request only if we must */
} else {
/* avoid an extra AIE_ON call */
wake.enabled = 1;
if (ioctl(fd, RTC_WKALM_SET, &wake) < 0) {
perror("set rtc wake alarm");
return 0;
}
}
return 1;
}
static void suspend_system(const char *suspend)
{
FILE *f = fopen("/sys/power/state", "w");
if (!f) {
perror("/sys/power/state");
return;
}
fprintf(f, "%s\n", suspend);
fflush(f);
/* this executes after wake from suspend */
fclose(f);
}
int main(int argc, char **argv)
{
static char *devname = "rtc0";
static unsigned seconds = 0;
static char *suspend = "standby";
int t;
int fd;
time_t alarm = 0;
progname = strrchr(argv[0], '/');
if (progname)
progname++;
else
progname = argv[0];
if (chdir("/dev/") < 0) {
perror("chdir /dev");
return 1;
}
while ((t = getopt(argc, argv, "d:lm:s:t:uVv")) != EOF) {
switch (t) {
case 'd':
devname = optarg;
break;
case 'l':
rtc_is_utc = 0;
break;
/* what system power mode to use? for now handle only
* standardized mode names; eventually when systems define
* their own state names, parse /sys/power/state.
*
* "on" is used just to test the RTC alarm mechanism,
* bypassing all the wakeup-from-sleep infrastructure.
*/
case 'm':
if (strcmp(optarg, "standby") == 0
|| strcmp(optarg, "mem") == 0
|| strcmp(optarg, "disk") == 0
|| strcmp(optarg, "on") == 0
) {
suspend = optarg;
break;
}
printf("%s: unrecognized suspend state '%s'\n",
progname, optarg);
goto usage;
/* alarm time, seconds-to-sleep (relative) */
case 's':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal interval %s seconds\n",
progname, optarg);
goto usage;
}
seconds = t;
break;
/* alarm time, time_t (absolute, seconds since 1/1 1970 UTC) */
case 't':
t = atoi(optarg);
if (t < 0) {
printf("%s: illegal time_t value %s\n",
progname, optarg);
goto usage;
}
alarm = t;
break;
case 'u':
rtc_is_utc = 1;
break;
case 'v':
verbose++;
break;
case 'V':
printf("%s: version %s\n", progname, VERSION);
break;
default:
usage:
printf("usage: %s [options]"
"\n\t"
"-d rtc0|rtc1|...\t(select rtc)"
"\n\t"
"-l\t\t\t(RTC uses local timezone)"
"\n\t"
"-m standby|mem|...\t(sleep mode)"
"\n\t"
"-s seconds\t\t(seconds to sleep)"
"\n\t"
"-t time_t\t\t(time to wake)"
"\n\t"
"-u\t\t\t(RTC uses UTC)"
"\n\t"
"-v\t\t\t(verbose messages)"
"\n\t"
"-V\t\t\t(show version)"
"\n",
progname);
return 1;
}
}
if (!alarm && !seconds) {
printf("%s: must provide wake time\n", progname);
goto usage;
}
/* REVISIT: if /etc/adjtime exists, read it to see what
* the util-linux version of hwclock assumes.
*/
if (rtc_is_utc == -1) {
printf("%s: assuming RTC uses UTC ...\n", progname);
rtc_is_utc = 1;
}
/* this RTC must exist and (if we'll sleep) be wakeup-enabled */
fd = open(devname, O_RDONLY);
if (fd < 0) {
perror(devname);
return 1;
}
if (strcmp(suspend, "on") != 0 && !may_wakeup(devname)) {
printf("%s: %s not enabled for wakeup events\n",
progname, devname);
return 1;
}
/* relative or absolute alarm time, normalized to time_t */
if (!get_basetimes(fd))
return 1;
if (verbose)
printf("alarm %ld, sys_time %ld, rtc_time %ld, seconds %u\n",
alarm, sys_time, rtc_time, seconds);
if (alarm) {
if (alarm < sys_time) {
printf("%s: time doesn't go backward to %s",
progname, ctime(&alarm));
return 1;
}
alarm += sys_time - rtc_time;
} else
alarm = rtc_time + seconds + 1;
if (setup_alarm(fd, &alarm) < 0)
return 1;
sync();
printf("%s: wakeup from \"%s\" using %s at %s",
progname, suspend, devname,
ctime(&alarm));
fflush(stdout);
usleep(10 * 1000);
if (strcmp(suspend, "on") != 0)
suspend_system(suspend);
else {
unsigned long data;
do {
t = read(fd, &data, sizeof data);
if (t < 0) {
perror("rtc read");
break;
}
if (verbose)
printf("... %s: %03lx\n", devname, data);
} while (!(data & RTC_AF));
}
if (ioctl(fd, RTC_AIE_OFF, 0) < 0)
perror("disable rtc alarm interrupt");
close(fd);
return 0;
}
This patch:
Make rtc-cmos do the relevant magic so this RTC can wake the system from a
sleep state. That magic comes in two basic flavors:
- Straightforward: enable_irq_wake(), the way it'd work on most SOC chips;
or generally with system sleep states which don't disable core IRQ logic.
- Roundabout, using non-IRQ platform hooks. This is needed with ACPI and
one almost-clone chip which uses a special wakeup-only alarm. (That's
the RTC used on Footbridge boards, FWIW, which don't do PM in Linux.)
A separate patch implements those hooks for ACPI platforms, so that rtc_cmos
can issue system wakeup events (and its sysfs "wakealarm" attribute works on
at least some systems).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Finish converting the RTC framework so it no longer uses class_device.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-By: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This patch removes class_device from the programming interface that the RTC
framework exposes to the rest of the kernel. Now an rtc_device is passed,
which is more type-safe and streamlines all the relevant code.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-By: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Lockdep reported cmos_suspend() and cmos_resume() calling rtc_update_irq()
with IRQs enabled; not allowed.
Also fix problems seen on some hardware, whereby false alarm IRQs could be
reported (primarily to userspace); and update two comments to match changes
in ACPI. Those make up most of this patch, by volume.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This is an "RTC framework" driver for the "CMOS" RTCs which are standard on
PCs and some other platforms. That's MC146818 compatible silicon.
Advantages of this vs. drivers/char/rtc.c (use one _or_ the other, only
one will be able to claim the RTC irq) include:
- This leverages both the new RTC framework and the driver model; both
PNPACPI and platform device modes are supported. (A separate patch
creates a platform device on PCs where PNPACPI isn't configured.)
- It supports common extensions like longer alarms. (A separate patch
exports that information from ACPI through platform_data.)
- Likewise, system wakeup events use "real driver model support", with
policy control via sysfs "wakeup" attributes and and using normal rtc
ioctls to manage wakeup. (Patch in the works. The ACPI hooks are
known; /proc/acpi/alarm can vanish. Making it work with EFI will
be a minor challenge to someone with e.g. a MiniMac.)
It's not yet been tested on non-x86 systems, without ACPI, or with HPET.
And the RTC framework will surely have teething pains on "mainstream"
PC-based systems (though must embedded Linux systems use it heavily), not
limited to sorting out the "/dev/rtc0" issue (udev easily tweaked). Also,
the ALSA rtctimer code doesn't use the new RTC API.
Otherwise, this should be a no-known-regressions replacement for the old
drivers/char/rtc.c driver, and should help the non-embedded distros (and
the new timekeeping code) start to switch to the framework.
Note also that any systems using "rtc-m48t86" are candidates to switch over
to this more functional driver; the platform data is different, and the way
bytes are read is different, but otherwise those chips should be compatible.
[akpm@osdl.org: sparc32 fix]
[akpm@osdl.org: sparc64 fix]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Woody Suwalski <woodys@xandros.com>
Cc: Alessandro Zummo <alessandro.zummo@towertech.it>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
