- 21 Jul, 2016 1 commit
-
-
Stefan Christ authored
It should be a real error message, when the driver cannot enable the IRQ of the device. Signed-off-by: Stefan Christ <s.christ@phytec.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 19 Jul, 2016 8 commits
-
-
Chris DeBruin authored
The current rtc-pcf85063 driver only supports the PCF85063TP device. Using the existing driver on a PCF85063A will result in the time being set correctly into the RTC, but the RTC is held in the stopped state. Therefore, the time will no longer advance and no error is indicated. The PCF85063A device has a bigger memory map than the PCF85063TP. The existing driver make use of an address rollover condition, but the rollover point is different in the two devices. Signed-off-by: Chris DeBruin <cdeb5783@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Alexandre Belloni authored
The year range is not validated properly As the driver has been mainlined in 2014, it is not an issue to stop handling dates between 1970 and 2000 with the benefit of handling dates up to 2100. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Uwe Kleine-König authored
Set .tm_sec to 0 instead of -1 to signal minute accuracy. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Pankaj Dubey <pankaj.dubey@samsung.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com> Tested-by: Pankaj Dubey <pankaj.dubey@samsung.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 11 Jul, 2016 8 commits
-
-
Uwe Kleine-König authored
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Uwe Kleine-König authored
Be more explicit in some comments. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 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: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <alexandre.belloni@free-electrons.com>
-
Alexandre Belloni authored
rtc-v3020.h belongs to include/linux/platform_data/ Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 08 Jul, 2016 1 commit
-
-
Alexandre Belloni authored
Move ds1286.h to rtc specific folder. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 27 Jun, 2016 4 commits
-
-
Alexandre Belloni authored
Add missing files to the RTC entry of MAINTAINERS Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <alexandre.belloni@free-electrons.com>
-
Alexandre Belloni authored
rtc-ds2404.h belongs to include/linux/platform_data/ Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Alexandre Belloni authored
ds17287rtc.h is unused since 15beb694 ("mips: ip32: add platform data hooks to use DS1685 driver"), remove it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <andrew.smirnov@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 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: Arnd Bergmann <arnd@arndb.de> Reported-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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
Martin Kepplinger authored
Use sign_extend32() instead of open coding sign extension. Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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: Arnd Bergmann <arnd@arndb.de> Reported-by: Guenter Roeck <linux@roeck-us.net> Fixes: fd09cc80165c ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h") Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
- 03 Jun, 2016 2 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: Arnd Bergmann <arnd@arndb.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-
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 <arnd@arndb.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
-