The PCF850363 has an offset correction with two modes:
With mode 0, the correction is triggered once every two hours and then
correction pulses are applied once per minute until the programmed
correction values have been implemented. This gives a step of 4.34 ppm.
With mode 1, the correction is triggered once every four minutes and then
correction pulses are applied once per second up to a maximum of 60 pulses.
When correction values greater than 60 pulses are used, additional
correction pulses are made in the 59 th second. This gives a step of 4.069
ppm.
Use the correction closest to the requested value.
The Micro Crystal RV8263 has the same IC as the pcf85063 but has an on
board crystal. This means that the CAP_SEL bit has to be cleared so the
correct capacitance is selected for the crystal.
Add support for the alarms. The match on the weekday is not used as it it
not necessarily properly set.
The tested RTC shows a behaviour where setting an alarm on the second right
after an alarm that fired is not working, probably because of the circuit
that ensures an alarm only fires once. This is why uie_unsupported is set.
rtc: snvs: use devm_platform_ioremap_resource() to simplify code
Use the new helper devm_platform_ioremap_resource() which wraps the
platform_get_resource() and devm_ioremap_resource() together, to
simplify the code.
rtc: mxc: use devm_platform_ioremap_resource() to simplify code
Use the new helper devm_platform_ioremap_resource() which wraps the
platform_get_resource() and devm_ioremap_resource() together, to
simplify the code.
Anson Huang [Wed, 27 Mar 2019 06:18:20 +0000 (06:18 +0000)]
rtc: snvs: use dev_pm_set_wake_irq() to simplify code
With calling dev_pm_set_wake_irq() to set SNVS RTC as wakeup
source for suspend, generic wake irq mechanism will automatically
enable it as wakeup source when suspend, then the suspend/resume
callback which are ONLY for enabling/disabling irq wake can be
removed, it simplifies the code.
Pi-Hsun Shih [Mon, 11 Mar 2019 07:55:40 +0000 (15:55 +0800)]
rtc: mt6397: Don't call irq_dispose_mapping.
The IRQ mapping was changed to not being created in the rtc-mt6397
driver, so the irq_dispose_mapping is no longer needed.
Also the dev_id passed to free_irq should be the same as the last
argument passed to request_threaded_irq.
This prevents a "Trying to free already-free IRQ 274" warning when
unbinding the driver.
The Sun4v Hypervisor Core API Specification states:
Time is described by a single unsigned 64-bit word equivalent to a time_t
for the POSIX time(2) system call. The word contains the time since the
Epoch (00:00:00 UTC, January 1, 1970), measured in seconds.
Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
The PS3 has a 64bit second counter from 2000. While this exceeds the 64bit
UNIX timestamp, there is not doubt that non of them will still be working
by then.
The IRQ is requested before the struct rtc is allocated and registered, but
this struct is used in the IRQ handler. This may lead to a NULL pointer
dereference.
Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
struct before requesting the IRQ.
The IRQ is requested before the struct rtc is allocated and registered, but
this struct is used in the IRQ handler. This may lead to a NULL pointer
dereference.
Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
struct before requesting the IRQ.
Linus Walleij [Tue, 19 Mar 2019 07:40:14 +0000 (08:40 +0100)]
rtc: x1205: Add DT probing support
This makes it possible to probe the X1205 RTC from the
device tree. This is needed when adding device tree boot
support for the IXP4xx-based NSLU2 which has this RTC.
Linus Torvalds [Sun, 17 Mar 2019 16:10:56 +0000 (09:10 -0700)]
Merge tag '9p-for-5.1' of git://github.com/martinetd/linux
Pull 9p updates from Dominique Martinet:
"Here is a 9p update for 5.1; there honestly hasn't been much.
Two fixes (leak on invalid mount argument and possible deadlock on
i_size update on 32bit smp) and a fall-through warning cleanup"
* tag '9p-for-5.1' of git://github.com/martinetd/linux:
9p/net: fix memory leak in p9_client_create
9p: use inode->i_lock to protect i_size_write() under 32-bit
9p: mark expected switch fall-through
Masahiro Yamada [Sun, 17 Mar 2019 02:01:09 +0000 (11:01 +0900)]
kbuild: force all architectures except um to include mandatory-y
Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes
the common Kbuild.asm file. Factor out the duplicated include directives
to scripts/Makefile.asm-generic so that no architecture would opt out
of the mandatory-y mechanism.
um is not forced to include mandatory-y since it is a very exceptional
case which does not support UAPI.
The commit was fine but is no longer needed as of commit 3a2429e1faf4
("kbuild: change if_changed_rule for multi-line recipe"). Let's go
back to using ";" to be consistent.
Douglas Anderson [Thu, 14 Mar 2019 23:41:59 +0000 (16:41 -0700)]
kbuild: Make NOSTDINC_FLAGS a simply expanded variable
During a simple no-op (nothing changed) build I saw 39 invocations of
the C compiler with the argument "-print-file-name=include". We don't
need to call the C compiler 39 times for this--one time will suffice.
Let's change NOSTDINC_FLAGS to a simply expanded variable to avoid
this since there doesn't appear to be any reason it should be
recursively expanded.
On my build this shaved ~400 ms off my "no-op" build.
Note that the recursive expansion seems to date back to the (really
old) commit e8f5bdb02ce0 ("[PATCH] Makefile include path ordering").
It's a little unclear to me if the point of that patch was to switch
the variable to be recursively expanded (which it did) or to avoid
directly assigning to NOSTDINC_FLAGS (AKA to switch to +=) because
someone else (out of tree?) was setting it. I presume later since if
the only goal was to switch to recursive expansion the patch would
have just removed the ":".
Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> -b, --build directory [format-specific-parameters]
> Build a source package (--build since dpkg 1.17.14).
> <...>
>
> dpkg-source will build the source package with the first
> format found in this ordered list: the format indicated
> with the --format command line option, the format
> indicated in debian/source/format, “1.0”. The fallback
> to “1.0” is deprecated and will be removed at some point
> in the future, you should always document the desired
> source format in debian/source/format. See section
> SOURCE PACKAGE FORMATS for an extensive description of
> the various source package formats.
Thus it would be more foolproof to explicitly use 1.0 (as we always
did) than to rely on dpkg-source's defaults.
* In a similar vein, debian/rules is not made executable by mkdebian,
and dpkg-source warns about that but still silently fixes the file.
Let's be explicit once again.
Wen Yang [Fri, 15 Feb 2019 07:55:19 +0000 (15:55 +0800)]
coccinelle: semantic code search for missing put_device()
The of_find_device_by_node() takes a reference to the underlying device
structure, we should release that reference.
The implementation of this semantic code search is:
In a function, for a local variable returned by calling
of_find_device_by_node(),
a, if it is released by a function such as
put_device()/of_dev_put()/platform_device_put() after the last use,
it is considered that there is no reference leak;
b, if it is passed back to the caller via
dev_get_drvdata()/platform_get_drvdata()/get_device(), etc., the
reference will be released in other functions, and the current function
also considers that there is no reference leak;
c, for the rest of the situation, the current function should release the
reference by calling put_device, this code search will report the
corresponding error message.
By using this semantic code search, we have found some object reference leaks,
such as:
commit 11907e9d3533 ("ASoC: fsl-asoc-card: fix object reference leaks in
fsl_asoc_card_probe")
commit a12085d13997 ("mtd: rawnand: atmel: fix possible object reference leak")
commit 11493f26856a ("mtd: rawnand: jz4780: fix possible object reference leak")
There are still dozens of reference leaks in the current kernel code.
Further, for the case of b, the object returned to other functions may also
have a reference leak, we will continue to develop other cocci scripts to
further check the reference leak.
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Reviewed-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Linus Torvalds [Sat, 16 Mar 2019 20:47:14 +0000 (13:47 -0700)]
Merge tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux
Pull pidfd system call from Christian Brauner:
"This introduces the ability to use file descriptors from /proc/<pid>/
as stable handles on struct pid. Even if a pid is recycled the handle
will not change. For a start these fds can be used to send signals to
the processes they refer to.
With the ability to use /proc/<pid> fds as stable handles on struct
pid we can fix a long-standing issue where after a process has exited
its pid can be reused by another process. If a caller sends a signal
to a reused pid it will end up signaling the wrong process.
With this patchset we enable a variety of use cases. One obvious
example is that we can now safely delegate an important part of
process management - sending signals - to processes other than the
parent of a given process by sending file descriptors around via scm
rights and not fearing that the given process will have been recycled
in the meantime. It also allows for easy testing whether a given
process is still alive or not by sending signal 0 to a pidfd which is
quite handy.
There has been some interest in this feature e.g. from systems
management (systemd, glibc) and container managers. I have requested
and gotten comments from glibc to make sure that this syscall is
suitable for their needs as well. In the future I expect it to take on
most other pid-based signal syscalls. But such features are left for
the future once they are needed.
This has been sitting in linux-next for quite a while and has not
caused any issues. It comes with selftests which verify basic
functionality and also test that a recycled pid cannot be signaled via
a pidfd.
Jon has written about a prior version of this patchset. It should
cover the basic functionality since not a lot has changed since then:
https://lwn.net/Articles/773459/
The commit message for the syscall itself is extensively documenting
the syscall, including it's functionality and extensibility"
* tag 'pidfd-v5.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
selftests: add tests for pidfd_send_signal()
signal: add pidfd_send_signal() syscall