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 7be2c7c96a ("[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
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: 211e5db19d ("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
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEycoQi/giopmpPgB12wIijOdRNOUFAl/eeIQACgkQ2wIijOdR
NOU06g//Xf2697Zc59SziSwhbEFCEyfhY4P+Qm24ymuOb2wkApmaWGifdCRclcvR
VncDLhyW9u5SpJiQY0ZMryTOmuE2KtbGfJX/tY9AGgQZioCxUIxELREwnqkQ2/8c
cOu0C8nrBCAnDNi3jTryPCyFJN1oLCztcbMGWXGG7Irkehq7ywQ1TCxxWzF+w3su
z38UzB1664ULfYYj3M2m/+2MV2rkf81P/4BTokKkZ2RLL1Q19wM0rFE0aXcKedel
pZy/DXGwBWK4fDR/Q2YYxRnpEf8UzYzgCQWAiaJGdRane9Tx6H8wy9TcHc5OQfjn
gtDtXje9Xwb+UJ27Mz19hNMts96n2G9S1Y0Pq5n0DD4AO0pDchYL41V5Z4hEDgMW
Fm/ZQG+khVJCllMUPbwPU2H7iDrH6IVsi2pjfdw1EeLW5Zx2/0jPfuAeQ1KdDKQt
UZ1SNxLZy2O7QL5Y+00pHlVFizTyGITz1H2IBG1Fn62abh7H9G5wfsB4AEldR+tr
9Di/o7Q1Oo5goBtVdmqn3xfOr1QWlfU+/7qSwiz2uqXMR/UWVMlLSp7k2Hav1m5H
6osjgRI6oQYHIbBwAQ3Hf98y/jOiddK6Wov6+gZGauO6M1//Q5NouQOXTe7RHwuG
R5JP6lgCoZJPky0156qApAH8I6r6xV1A7W7CEnNKOK1JITqj5Hw=
=n8V2
-----END PGP SIGNATURE-----
Merge tag 'rtc-5.11' of 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
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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEycoQi/giopmpPgB12wIijOdRNOUFAl6IgdAACgkQ2wIijOdR
NOVH9Q//evfZmRDQb9Lm8YuSOt+U6lBaCuvRP8H4s7i02jsw0tt1oT6+rGo+1N+k
pi64+iwPqDj7h+eds06jVur7yWZDNNfCSywlMU8ODGLQcc/hXMTvaIeJtdXG+I+7
dpIVTs9Artiey2Qb3qZalSMYzrE2rQG6Yuyb/tHx7Pohvje1wKnAE3T64W6sfvir
zjAwAr/+s9n82mjGtGLapz0onao7dSN4p6b3UIkph9KxPdeHjItd7cRiJuzioysj
LE8WRUek++uha32PzghK9MoUpRKf8PJtGbsAIRhdwvmwub1Pqs6Uvk5IHQvdiFZx
af1Qnw/4qUH03HVUuq8VdEkwa8mdthcZ72b8uzUWOqP+uPkeTTlQOGOd1dRECijK
Qic+SKlEznwgKC9WuDufUQg5i2WjFBnBlA+dCE12/t91SbSlZdYjb53nQLHve1b9
e4VfyKnS5Ghn/dfizzzSPdcWuPW1rqq2dHTiOvFVqlLn1Fkt1AKaJzGAeCe6PWp4
AJVqPu+D1eQ/qmvEPXI7dQpCxdI+p6FNJgQvQLMssaq7mpf2fiRoLx23ikFG0v0k
BeNkNWpLz2ACwHpsOa/RWLwa/FC2+KBHaRWf+As7te63byeDQC8hUEi7F5K78lSS
yhfZ8SJR04SIIGKjuwAzPmaaIJ0hJT+eaxkFAJU7P5hD7KElsuM=
=6Veu
-----END PGP SIGNATURE-----
Merge tag 'rtc-5.7' of 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>
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 079062b28f
("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: 079062b28f ("rtc: cmos: prevent kernel warning on IRQ flags mismatch")
Depends-on: a1e23a42f1 ("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 311ee9c151 ("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: 311ee9c151 ("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 311ee9c151 ("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: 311ee9c151 ("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>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEXx9Viay1+e7J/aM4AyWl4gNJNJIFAlrL3s4ACgkQAyWl4gNJ
NJI+MxAAgc56UEXi5chqKpHE6GHL2aPWan9duHB6FmGrKWt/FJmpJ8UGylLFlvaW
dpRGvW0Dynz45UztegcrbHMU6+B2O0hboL4/GVZpYAkcNAcu7Lf0ULho2rsQSDmW
WJpemmdRxyQY1IkWmw7z7KAkMzhAfYZiVmWmVwMRZfMcKJ3DLEldfgRtkN+g0UdB
tayWQY3mS02ki16e2figsgwZRmUUhQslDfpKlesInXOzUMmLgVWhf1QxJSEUcfs0
AMp75vD2YvVJ/RHy/6BilQbqP9EVnaG4NHqJGFSOddazA7u+3HGubEFboI8NuPXb
2fCvfrNux7pgtQsBF9dnpCqWlukE7sF5aDyIUvjYnr0vUm2D/CwdXglGvQSQVWea
5GxPTWBdaCL0V7GD5OSZcfUGyz1TN/7NSUItdLSr9YK13dL+tqhcYYm5ytXJLzvO
Z4GyUEoCOMprMJ9j5KU/TXSjauDmPDl8YZ5B93lPcNOh7y+b/2r3umBaInyZrFzX
1WJ6FWtuhbRfEwuQtgQHBsobt9eTwZfo8C2y22HBo/fdWfBv45feiiHNXt3OVrA+
aws6pwfVf1H0UsvpQkXtlPthAx3sbOTndDKAUhntb/U/zA9c7fTrfUyVOQ1bArJy
p6tl/cmlpq68AjZB+0d3zUXQkQH4Syu+EqZrWItkE6XxZm+khDE=
=l9i8
-----END PGP SIGNATURE-----
Merge tag 'rtc-4.17' of 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()
...
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>
Commit eed4d47efe (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: eed4d47efe (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>
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEl0I5XWmUIrwBfFMm2KKDO9oT4sIFAlhXIxkACgkQ2KKDO9oT
4sKJIQ/+MxwjMs0CZ8744orSTkX5AJTOwGcwg+SEmp23Ht0nV0SCrAkkndC3HamM
9MwT0qVmL2rgiqyeSRAjdVVIt+UFJeGXMuBhc5UBqSomjXIqfN9nA0DXuddKx/at
ZwWtPIN4HyWS5Uetn/FTXC9scBa5+2bJEYdB3ocC/QNgcCErINzPBJZEsduaxajK
AUIOhHPWn9D2cDzIxPMplPyVSWXUI3WXiF2mvgi/VAB21StQoKY6KkJV+u6Q+56t
IdJeKaAP+bF535T66wl/yY1KNhkRwF6M0qFs+qR5htoxzS6zx6hW+aRibvrIAP3/
YiAQj2L7hOjW1ky0H1rEUpjTYFxWmOx2AWZJ3ubxzveF6pz0Qn1TTrzOHVkelaHB
iuuYrxXMmC84qmHrxIdrkZdH2eu2Fm12/D1VME6bjdD4BApkEHjKebGVS4F9XaMi
Pdbb4olEslZL+XEZXkuqmopl7g1/Wf34IrCskNDoUx7t+JsCjrA+hXMVeqwl3e8m
Edcv103l1Wkivv9kHZEgx8IwOeti5d77z+QUvQzHYKK28o8zQii/3zlvQzJ/6gnE
M20vRv7cptVL4GmZd4ebFB2GOUteSfnOJJAwKZ3ipbZaGtNSs1nhAqTpg9uw4OEr
rPlRJJw5Cov1ctV+dBuVhLmzStBg3PJj2fkZ4qjdYgeiu2wZAV0=
=z4SX
-----END PGP SIGNATURE-----
Merge tag 'rtc-4.10' of 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
...
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 a4f8f6667f ("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>
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>
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: 983bf1256e ("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>
Since commit d68778b80d ("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>
