- 19 Jul, 2016 5 commits
-
-
Uwe Kleine-König authored
Since all time members of the alarm data is initialized to -1 the drivers are responsible to set the tm_sec member to 0. Fixes: d68778b8 ("rtc: initialize output parameter for read alarm to "uninitialized"") Signed-off-by:
Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Alim Akhtar authored
As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled and in set_freq we perform h/w registers read/write, which results in a kernel crash on exynos7 platform while probing rtc driver. Below is code flow: s3c_rtc_probe() clk_prepare_enable(info->rtc_clk) // rtc clock enabled s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit s3c_rtc_setfreq() //then this will be called with clk disabled This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq(). Fixes: 24e14554 ("drivers/rtc/rtc-s3c.c: delete duplicate clock control") Cc: <stable@vger.kernel.org> Signed-off-by:Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by:
Pankaj Dubey <pankaj.dubey@samsung.com> Tested-by:
-
Alim Akhtar authored
At the end of s3c_rtc_probe(), s3c_rtc_disable_clk() being called with rtc clock already disabled (by s3c_rtc_gettime()), which looks extra and unnecessary call. Lets clean it up. Signed-off-by:
-
Sudip Mukherjee authored
If devm_add_action() fails we are explicitly calling the cleanup to free the resources allocated. Lets use the helper devm_add_action_or_reset() and return directly in case of error, as we know that the cleanup function has been already called by the helper if there was any error. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Sudip Mukherjee authored
If devm_add_action() fails we are explicitly calling the cleanup to free the resources allocated. Lets use the helper devm_add_action_or_reset() and return directly in case of error, as we know that the cleanup function has been already called by the helper if there was any error. Signed-off-by:
-
- 11 Jul, 2016 8 commits
-
-
Uwe Kleine-König authored
Signed-off-by:
-
Uwe Kleine-König authored
Be more explicit in some comments. Signed-off-by:
-
Uwe Kleine-König authored
On some QNAP NAS devices the rtc can wake the machine. Several people noticed that once the machine was woken this way it fails to shut down. That's because the driver fails to acknowledge the interrupt and so it keeps active and restarts the machine immediatly after shutdown. See https://bugs.debian.org/794266 for a bug report. Doing this correctly requires to interpret the INT2 flag of the first read of the STATUS1 register because this bit is cleared by read. Note this is not maximally robust though because a pending irq isn't detected when the STATUS1 register was already read (and so INT2 is not set) but the irq was not disabled. But that is a hardware imposed problem that cannot easily be fixed by software. Signed-off-by:
-
Uwe Kleine-König authored
There were two deviations from the reference manual: you have to wait half a second when POC is active and you might have to repeat initialization when POC or BLD are still set after the sequence. Note however that as POC and BLD are cleared by read the driver might not be able to detect that a reset is necessary. I don't have a good idea how to fix this. Additionally report the value read from STATUS1 to the caller. This prepares the next patch. Signed-off-by:
-
Uwe Kleine-König authored
There are several issues fixed in this patch: - When alarm isn't enabled, set .enabled to zero instead of returning -EINVAL. - Ignore how IRQ1 is configured when determining if IRQ2 is on. - The three alarm registers have an enable flag which must be evaluated. - The chip always triggers when the seconds register gets 0. Note that the rtc framework however doesn't handle the result correctly because it doesn't check wday being initialized and so interprets an alarm being set for 10:00 AM in three days as 10:00 AM tomorrow (or today if that's not over yet). Signed-off-by:
-
Uwe Kleine-König authored
The rtc core doesn't give broken dates to a driver's .set_alarm callback, so there should be no need for validation. Signed-off-by:
-
Uwe Kleine-König authored
This rtc doesn't support triggering on years, so don't assign tm_year instead of claiming the alarm is to trigger in year 67435. Signed-off-by:
-
Uwe Kleine-König authored
The rtc chip doesn't support triggering on month and year. So just don't assign the respective fields in .read_alarm and let the rtc core interpret this accordingly. Signed-off-by:
-
- 09 Jul, 2016 3 commits
-
-
Uwe Kleine-König authored
Since commit d68778b8 ("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:
-
Keerthy authored
The reset value of weekday is 0x1. This is wrong since the reset values of the day/month/year make up to Jan 1 2001. When computed weekday comes out to be Monday. On a scale of 1-7(Sunday - Saturday) it should be 0x2. So we should not be relying on the reset value. Hence compute the wday using the current date/month/year values. Check if reset wday is any different from the computed wday, If different then set the wday which we computed using date/month/year values. Document Referred: http://ww1.microchip.com/downloads/en/DeviceDoc/20002266F.pdf Fixes: 1d1945d2 "drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips" Signed-off-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
-
Alexandre Belloni authored
rtc-v3020.h belongs to include/linux/platform_data/ Acked-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
- 08 Jul, 2016 1 commit
-
-
Alexandre Belloni authored
Move ds1286.h to rtc specific folder. Signed-off-by:
-
- 27 Jun, 2016 4 commits
-
-
Alexandre Belloni authored
Add missing files to the RTC entry of MAINTAINERS Signed-off-by: -
Alexandre Belloni authored
m48t86.h belongs to include/linux/platform_data/ Acked-by:
Jason Cooper <jason@lakedaemon.net> Acked-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Acked-by:
Alexander Clouter <alex@digriz.org.uk> Signed-off-by:
-
Alexandre Belloni authored
rtc-ds2404.h belongs to include/linux/platform_data/ Signed-off-by: -
Alexandre Belloni authored
ds17287rtc.h is unused since 15beb694 ("mips: ip32: add platform data hooks to use DS1685 driver"), remove it. Signed-off-by:
-
- 26 Jun, 2016 3 commits
-
-
Andrey Smirnov authored
A call to ioctl(..., RTC_IRQP_SET, ...) should never result in ENOTTY. All new style RTC drivers implement it and all of the old style drivers return EINVAL when they don't support periodic IRQs. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by:
-
Andrey Smirnov authored
A call to ioctl(..., RTC_IRQP_READ, ...) should never result in ENOTTY. All new style RTC drivers implement it and all of the old style drivers return EINVAL when they don't support periodic IRQs. Signed-off-by:
-
Andrey Smirnov authored
For old style drivers, call a call to ioctl(..., RTC_ALM_SET, ...): - char/ds1302.c will always return -EINVAL - char/genrtc.c: will always return -EINVAL - char/rtc.c will succeed regardless if IRQs are supported or not - char/efirtc.c will always return -EINVAL - input/misc/hp_sdc_rtc.c ... that ioctl code is a good lesson about ifdefing code out and punting implementation ... and it will always return -EINVAL For new style rtc drivers, a call to ioctl(..., RTC_ALM_SET, ...) never results in a call to __rtc_set_alarm, since struct rtc_wkalarm passed to rtc_set_alarm has 'enabled' field set to 0. This means that rtc->ops->set_alarm driver hook is never called in that ioctl. Since no driver code interaction happens as a part of that call, using its results to ascertain properties of the driver is not going to work. To remedy this - use the result of RTC_AIE_ON to make the judgement. This patch also changes ENOTTY to EINVAL as an error code value that would tell us that IRQs are not supported. There are three reason for this: - As mentioned above old style driver never returns ENOTTY for this ioctl - In it's code __rtc_set_alarm() returns -EINVAL if rtc->ops->set_alarm method is not provided by the driver, so one reason for change is to be consistent with that code path. - A call to ioctl(..., RTC_UIE_ON, ...) will result in a call to rtc_update_irq_enable() and then __rtc_set_alarm(), which, if IRQs are not supported by the driver, will result in a non-zero error code. Returning ENOTTY in that case would: a) Not be consistent with other codepaths of rtc_update_irq_enable, for example the check of rtc->uie_unsupported b) Would break update IRQ emulation code since that codpath expects EINVAL c) Would break test's logic for feature support detection in the case of RTC_UIE_ON ioctl Signed-off-by:
-
- 25 Jun, 2016 3 commits
-
-
Alexandre Belloni authored
The previous workaround may still fail as there are actually 4 retries to be done to ensure the communication succeed. Also, some I2C adapter drivers may return -EIO instead of -ENXIO. Signed-off-by: -
Arnd Bergmann authored
The mc146818_get_time/mc146818_set_time functions are rather large inline functions in a global header file and are used in several drivers and in x86 specific code. Here we move them into a separate .c file that is compiled whenever any of the users require it. This also lets us remove the linux/acpi.h header inclusion from mc146818rtc.h, which in turn avoids some warnings about duplicate definition of the TRUE/FALSE macros. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
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:
-
- 06 Jun, 2016 2 commits
-
-
Arnd Bergmann authored
When building random configurations, we now occasionally get a new build error: In file included from include/linux/kernel.h:13:0, from include/linux/list.h:8, from include/linux/preempt.h:10, from include/linux/spinlock.h:50, from arch/x86/kernel/nmi.c:13: arch/x86/kernel/nmi.c: In function 'nmi_max_handler': include/linux/printk.h:375:9: error: type defaults to 'int' in declaration of 'DEFINE_RATELIMIT_STATE' [-Werror=implicit-int] static DEFINE_RATELIMIT_STATE(_rs, \ ^ arch/x86/kernel/nmi.c:110:2: note: in expansion of macro 'printk_ratelimited' printk_ratelimited(KERN_INFO ^~~~~~~~~~~~~~~~~~ This was working before the rtc rework series because linux/ratelimit.h was included implictly through asm/mach_traps.h -> asm/mc146818rtc.h -> linux/mc146818rtc.h -> linux/rtc.h -> linux/device.h. We clearly shouldn't rely on this indirect inclusion, so this adds an explicit #include in the file that needs it. Signed-off-by:kbuild test robot <fengguang.wu@intel.com> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Fixes: 5ab788d7 ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h") Signed-off-by:
-
Alexander Graf authored
While the EFI spec mandates an RTC, not every implementation actually adheres to that rule (or can adhere to it - some systems just don't have an RTC). For those, we really don't want to probe the EFI RTC driver at all, because if we do we'd get a non-functional driver that does nothing useful but only spills our kernel log with warnings. Signed-off-by:
Alexander Graf <agraf@suse.de> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
- 04 Jun, 2016 5 commits
-
-
Venkat Prashanth B U authored
Add support for Maxim max6916 RTC. Signed-off-by:
Venkat Prashanth B U <venkat.prashanth2498@gmail.com> Signed-off-by:
-
Martin Kepplinger authored
Use sign_extend32() instead of open coding sign extension. Signed-off-by:
Martin Kepplinger <martink@posteo.de> Signed-off-by:
-
Heinrich Schuchardt authored
The day of month is checked in ds1685_rtc_read_alarm and ds1685_rtc_set_alarm. Multiple errors exist in the day of month check. Operator ! has a higher priority than &&. (!(mday >= 1) && (mday <= 31)) is false for mday == 32. When verifying the day of month the binary and the BCD mode have to be considered. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by:
-
Colin Ian King authored
This patch fixes a RTC wakealarm issue, namely, the event fires during hibernate and is not cleared from the list, causing hwclock to block. The current enqueuing does not trigger an alarm if any expired timers already exist on the timerqueue. This can occur when a RTC wake alarm is used to wake a machine out of hibernate and the resumed state has old expired timers that have not been removed from the timer queue. This fix skips over any expired timers and triggers an alarm if there are no pending timers on the timerqueue. Note that the skipped expired timer will get reaped later on, so there is no need to clean it up immediately. The issue can be reproduced by putting a machine into hibernate and waking it with the RTC wakealarm. Running the example RTC test program from tools/testing/selftests/timers/rtctest.c after the hibernate will block indefinitely. With the fix, it no longer blocks after the hibernate resume. BugLink: http://bugs.launchpad.net/bugs/1333569Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Arnd Bergmann authored
sparc32:allmodconfig fails to build in next-20160602 as follows. In file included from drivers/block/floppy.c:185:0: include/linux/mc146818rtc.h: In function 'mc146818_is_updating': include/linux/mc146818rtc.h:138:9: error: 'rtc_port' undeclared (first use in this function) include/linux/mc146818rtc.h:138:9: note: each undeclared identifier is reported only once for each function it appears in include/linux/mc146818rtc.h: In function 'mc146818_get_time': include/linux/mc146818rtc.h:172:17: error: 'rtc_port' undeclared (first use in this function) include/linux/mc146818rtc.h: In function 'mc146818_set_time': include/linux/mc146818rtc.h:278:8: error: 'rtc_port' undeclared (first use in this function) scripts/Makefile.build:295: recipe for target 'drivers/block/floppy.o' failed The reason is a duplicate definition of the RTC_PORT macro. The one in arch/sparc/include/asm/io_32.h was apparently used a long time ago for the drivers/char/rtc.c driver that is not available on SPARC any more, since we now select 'RTC_CLASS' unconditionally. Removing the macro fixes the build problem, and for consistency, this also removes the RTC_ALWAYS_BCD macro and the comment for both. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Fixes: fd09cc80165c ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h") Signed-off-by:
-
- 03 Jun, 2016 6 commits
-
-
Arnd Bergmann authored
No architecture uses the genrtc driver any more, so let's kill it off for good. This now also includes asm-generic/rtc.h, which is otherwise completely unused. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Arnd Bergmann authored
arch/mips/sni/time.c includes asm-generic/rtc.h for no apparent reason, and it works fine without that header, so lets remove the inclusion in preparation of deleting the file. Signed-off-by:
-
Arnd Bergmann authored
All architectures using this driver are now converted to provide their own operations, so this one can be turned into a trivial stub driver relying on its platform data. Signed-off-by:
-
Arnd Bergmann authored
PowerPC is the last architecture using the GEN_RTC driver on some machines, but we can migrate them all to using the RTC_DRV_GENERIC driver instead now. This moves over the CONFIG_GEN_RTC option from drivers/char into arch/powerpc/platforms/Kconfig and makes it just select the replacement driver instead, for the only reason of not breaking existing defconfig and .config files that users may have. Signed-off-by:
-
Arnd Bergmann authored
The rtc-generic driver provides an architecture specific wrapper on top of the generic rtc_class_ops abstraction, and powerpc has another abstraction on top, which is a bit silly. This changes the powerpc rtc-generic device to provide its rtc_class_ops directly, to reduce the number of layers by one. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Acked-by:
-
Arnd Bergmann authored
The asm/rtc.h header is only used for the old gen_rtc driver that has been replaced by rtc-generic. According to Geert Uytterhoeven, nobody has used the old driver on m68k for a long time, so we can now just remove the header file and disallow the driver in Kconfig. All files that used to include asm/rtc.h are now changed so they include the headers that were used implicitly through asm/rtc.h. Signed-off-by:
-
