09 Jul, 2016
3 commits
-
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
Signed-off-by: Alexandre Belloni -
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.pdfFixes: 1d1945d261a2af "drivers/rtc/rtc-ds1307.c: add alarm support for mcp7941x chips"
Signed-off-by: Keerthy
Signed-off-by: Alexandre Belloni -
rtc-v3020.h belongs to include/linux/platform_data/
Acked-by: Robert Jarzmik
Signed-off-by: Alexandre Belloni
08 Jul, 2016
1 commit
-
Move ds1286.h to rtc specific folder.
Signed-off-by: Alexandre Belloni
28 Jun, 2016
2 commits
-
Add missing files to the RTC entry of MAINTAINERS
Signed-off-by: Alexandre Belloni
-
m48t86.h belongs to include/linux/platform_data/
Acked-by: Jason Cooper
Acked-by: H Hartley Sweeten
Acked-by: Alexander Clouter
Signed-off-by: Alexandre Belloni
27 Jun, 2016
5 commits
-
rtc-ds2404.h belongs to include/linux/platform_data/
Signed-off-by: Alexandre Belloni
-
ds17287rtc.h is unused since 15beb694c661 ("mips: ip32: add platform data
hooks to use DS1685 driver"), remove it.Signed-off-by: Alexandre Belloni
-
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
Signed-off-by: Alexandre Belloni -
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
Signed-off-by: Alexandre Belloni -
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 -EINVALFor 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_unsupportedb) Would break update IRQ emulation code since that codpath
expects EINVALc) Would break test's logic for feature support detection in
the case of RTC_UIE_ON ioctlSigned-off-by: Andrey Smirnov
Signed-off-by: Alexandre Belloni
26 Jun, 2016
3 commits
-
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
-
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
Signed-off-by: Alexandre Belloni -
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
Signed-off-by: Alexandre Belloni
06 Jun, 2016
2 commits
-
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
Reported-by: kbuild test robot
Acked-by: Thomas Gleixner
Fixes: 5ab788d73832 ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")
Signed-off-by: Alexandre Belloni -
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
Acked-by: Ard Biesheuvel
Signed-off-by: Alexandre Belloni
04 Jun, 2016
21 commits
-
Add support for Maxim max6916 RTC.
Signed-off-by: Venkat Prashanth B U
Signed-off-by: Alexandre Belloni -
Use sign_extend32() instead of open coding sign extension.
Signed-off-by: Martin Kepplinger
Signed-off-by: Alexandre Belloni -
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
Signed-off-by: Alexandre Belloni -
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/1333569
Signed-off-by: Colin Ian King
Signed-off-by: Alexandre Belloni -
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' failedThe 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
Reported-by: Guenter Roeck
Fixes: fd09cc80165c ("rtc: cmos: move mc146818rtc code out of asm-generic/rtc.h")
Signed-off-by: Alexandre Belloni -
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
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
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
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
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
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
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
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
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: Arnd Bergmann
Acked-by: Michael Ellerman
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
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: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
The q40 platform is the only machine in the kernel that provides
RTC_PLL_GET/RTC_PLL_SET ioctl commands in its rtc through the
mach_get_rtc_pll/mach_set_rtc_pll callbacks.However, this currenctly works only in the old-style genrtc
driver, not the (somewhat) modern rtc-generic driver replacing
it. This adds an ioctl implementation to the m68k generic_rtc_ops
in order to let both drivers provide the same API.After this, we should be able to remove support for genrtc
from the m68k architecture.Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and m68k has another abstraction on top, which is a bit
silly.This changes the m68k rtc-generic device to provide its
rtc_class_ops directly, to reduce the number of layers
by one.Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Tested-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
This architecture selects RTC_CLASS unconditionally, so the GEN_RTC
has not worked here for a long time.Now we can remove both the asm/rtc.h header and the Kconfig dependency
for CONFIG_GEN_RTC.Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and on pa-risc, that is implemented using an open-coded
version of rtc_time_to_tm/rtc_tm_to_time.This changes the parisc rtc-generic device to provide its
rtc_class_ops directly, using the normal helper functions,
which makes this y2038 safe (on 32-bit) and simplifies
the implementation.Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
The genrtc driver serves no purpose on mn10300 because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.I assume it was initially only added for completeness when the
mn10300 port was done, but the older rtc.c driver was always used
instead.We can also stop include asm-generic/rtc.h now, because we
just call mc146818_set_time() directly.It would be nice to change the architecture to use the rtc-cmos driver
next, and remove support for the old rtc driver as well.[linux@roeck-us.net: Add missing include file to proc-init.c]
Signed-off-by: Arnd Bergmann
Signed-off-by: Guenter Roeck
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
The genrtc driver serves no purpose on Alpha because it drives the
same hardware as the original rtc.c driver, and the newer rtc-generic.c
or rtc-cmos.c drivers on architectures that use the asm-generic/rtc.h
header.The defconfig uses CONFIG_RTC=y, so this driver is not used by default.
At one point it was used to abstract a quirk for the "Marvel" platform,
but it does not do this any more after the code was moved into yet
another driver in arch/alpha/kernel/rtc.c.Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
The rtc-generic driver provides an architecture specific
wrapper on top of the generic rtc_class_ops abstraction,
and on sh, that goes through another indirection using
the rtc_sh_get_time/rtc_sh_set_time functions.This changes the sh rtc-generic device to provide its
rtc_class_ops directly, skipping one of the abstraction
levels.Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Acked-by: Rich Felker
Signed-off-by: Alexandre Belloni -
Commit 3195ef59cb42 ("x86: Do full rtc synchronization with ntp") had
the side-effect of unconditionally enabling the RTC_LIB symbol on x86,
which in turn disables the selection of the CONFIG_RTC and
CONFIG_GEN_RTC drivers that contain a two older implementations of
the CONFIG_RTC_DRV_CMOS driver.This removes x86 from the list for genrtc, and changes all references
to the asm/rtc.h header to instead point to the interfaces
from linux/mc146818rtc.h.Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
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
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni -
Nothing on these architectures ever includes the asm/mc146818rtc.h
file, the drivers that used to do this have been fixed long ago,
and the remaining users are all PC-specific.This removes the files for good.
Signed-off-by: Arnd Bergmann
Acked-by: Geert Uytterhoeven
Signed-off-by: Alexandre Belloni
30 May, 2016
3 commits
-
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.Signed-off-by: Geert Uytterhoeven
Cc: Alessandro Zummo
Cc: Alexandre Belloni
Cc: rtc-linux@googlegroups.com
Signed-off-by: Alexandre Belloni -
rtc drivers are supposed to set values they don't support to -1. To
simplify this for drivers and also make it harder for them to get it
wrong initialize the values to -1.Signed-off-by: Uwe Kleine-König
Signed-off-by: Alexandre Belloni
