aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-04-17fork_init: update max_threads commentJean Delvare1-2/+2
The comment explaining what value max_threads is set to is outdated. The maximum memory consumption ratio for thread structures was 1/2 until February 2002, then it was briefly changed to 1/16 before being set to 1/8 which we still use today. The comment was never updated to reflect that change, it's about time. Signed-off-by: Jean Delvare <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fork: report pid reservation failure properlyMichal Hocko2-9/+11
copy_process will report any failure in alloc_pid as ENOMEM currently which is misleading because the pid allocation might fail not only when the memory is short but also when the pid space is consumed already. The current man page even mentions this case: : EAGAIN : : A system-imposed limit on the number of threads was encountered. : There are a number of limits that may trigger this error: the : RLIMIT_NPROC soft resource limit (set via setrlimit(2)), which : limits the number of processes and threads for a real user ID, was : reached; the kernel's system-wide limit on the number of processes : and threads, /proc/sys/kernel/threads-max, was reached (see : proc(5)); or the maximum number of PIDs, /proc/sys/kernel/pid_max, : was reached (see proc(5)). so the current behavior is also incorrect wrt. documentation. POSIX man page also suggest returing EAGAIN when the process count limit is reached. This patch simply propagates error code from alloc_pid and makes sure we return -EAGAIN due to reservation failure. This will make behavior of fork closer to both our documentation and POSIX. alloc_pid might alsoo fail when the reaper in the pid namespace is dead (the namespace basically disallows all new processes) and there is no good error code which would match documented ones. We have traditionally returned ENOMEM for this case which is misleading as well but as per Eric W. Biederman this behavior is documented in man pid_namespaces(7) : If the "init" process of a PID namespace terminates, the kernel : terminates all of the processes in the namespace via a SIGKILL signal. : This behavior reflects the fact that the "init" process is essential for : the correct operation of a PID namespace. In this case, a subsequent : fork(2) into this PID namespace will fail with the error ENOMEM; it is : not possible to create a new processes in a PID namespace whose "init" : process has terminated. and introducing a new error code would be too risky so let's stick to ENOMEM for this case. Signed-off-by: Michal Hocko <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: "Eric W. Biederman" <[email protected]> Cc: Michael Kerrisk <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17signal: remove warning about using SI_TKILL in rt_[tg]sigqueueinfoVladimir Davydov1-9/+5
Sending SI_TKILL from rt_[tg]sigqueueinfo was deprecated, so now we issue a warning on the first attempt of doing it. We use WARN_ON_ONCE, which is not informative and, what is worse, taints the kernel, making the trinity syscall fuzzer complain false-positively from time to time. It does not look like we need this warning at all, because the behaviour changed quite a long time ago (2.6.39), and if an application relies on the old API, it gets EPERM anyway and can issue a warning by itself. So let us zap the warning in kernel. Signed-off-by: Vladimir Davydov <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17ptrace: ptrace_detach() can no longer race with SIGKILLOleg Nesterov1-10/+9
ptrace_detach() re-checks ->ptrace under tasklist lock and calls release_task() if __ptrace_detach() returns true. This was needed because the __TASK_TRACED tracee could be killed/untraced, and it could even pass exit_notify() before we take tasklist_lock. But this is no longer possible after 9899d11f6544 "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL". We can turn these checks into WARN_ON() and remove release_task(). While at it, document the setting of child->exit_code. Signed-off-by: Oleg Nesterov <[email protected]> Cc: Pavel Labath <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17ptrace: fix race between ptrace_resume() and wait_task_stopped()Oleg Nesterov1-0/+20
ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee. This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal. Test-case: #include <stdio.h> #include <unistd.h> #include <sys/wait.h> #include <sys/ptrace.h> #include <pthread.h> #include <assert.h> int pid; void *waiter(void *arg) { int stat; for (;;) { assert(pid == wait(&stat)); assert(WIFSTOPPED(stat)); if (WSTOPSIG(stat) == SIGHUP) continue; assert(WSTOPSIG(stat) == SIGCONT); printf("ERR! extra/wrong report:%x\n", stat); } } int main(void) { pthread_t thread; pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); for (;;) kill(getpid(), SIGHUP); } assert(pthread_create(&thread, NULL, waiter, NULL) == 0); for (;;) ptrace(PTRACE_CONT, pid, 0, SIGCONT); return 0; } Note for stable: the bug is very old, but without 9899d11f6544 "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child). Signed-off-by: Oleg Nesterov <[email protected]> Reported-by: Pavel Labath <[email protected]> Tested-by: Pavel Labath <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/fat: comment fix, fat_bits can be also 32Alexander Kuleshov1-1/+1
Signed-off-by: Alexander Kuleshov <[email protected]> Acked-by: OGAWA Hirofumi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/fat: remove unnecessary includesAlexander Kuleshov9-33/+1
'fat.h' includes <linux/buffer_head.h> which includes <linux/fs.h> which includes all the header files required for all *.c files fat filesystem. [[email protected]: fs/fat/iode.c needs seq_file.h] [[email protected]: put one actually necessary include file back] Signed-off-by: Alexander Kuleshov <[email protected]> Acked-by: OGAWA Hirofumi <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/fat: remove unnecessary defintionAlexander Kuleshov1-2/+1
'*sb' never used, so let's remote it and pass inode->i_sb directly to the MSDOS_SB. Signed-off-by: Alexander Kuleshov <[email protected]> Acked-by: OGAWA Hirofumi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17hfsplus: don't store special "osx" xattr prefix on-diskThomas Hebb1-5/+14
On Mac OS X, HFS+ extended attributes are not namespaced. Since we want to be compatible with OS X filesystems and yet still support the Linux namespacing system, the hfsplus driver implements a special "osx" namespace that is reported for any attribute that is not namespaced on-disk. However, the current code for getting and setting these unprefixed attributes is broken. hfsplus_osx_setattr() and hfsplus_osx_getattr() are passed names that have already had their "osx." prefixes stripped by the generic functions. The functions first, quite correctly, check those names to make sure that they aren't prefixed with a known namespace, which would allow namespace access restrictions to be bypassed. However, the functions then prepend "osx." to the name they're given before passing it on to hfsplus_getattr() and hfsplus_setattr(). Not only does this cause the "osx." prefix to be stored on-disk, defeating its purpose, it also breaks the check for the special "com.apple.FinderInfo" attribute, which is reported for all files, and as a consequence makes some userspace applications (e.g. GNU patch) fail even when extended attributes are not otherwise in use. There are five commits which have touched this particular code: 127e5f5ae51e ("hfsplus: rework functionality of getting, setting and deleting of extended attributes") b168fff72109 ("hfsplus: use xattr handlers for removexattr") bf29e886b242 ("hfsplus: correct usage of HFSPLUS_ATTR_MAX_STRLEN for non-English attributes") fcacbd95e121 ("fs/hfsplus: move xattr_name allocation in hfsplus_getxattr()") ec1bbd346f18 ("fs/hfsplus: move xattr_name allocation in hfsplus_setxattr()") The first commit creates the functions to begin with. The namespace is prepended by the original code, which I believe was correct at the time, since hfsplus_?etattr() stripped the prefix if found. The second commit removes this behavior from hfsplus_?etattr() and appears to have been intended to also remove the prefixing from hfsplus_osx_?etattr(). However, what it actually does is remove a necessary strncpy() call completely, breaking the osx namespace entirely. The third commit re-adds the strncpy() call as it was originally, but doesn't mention it in its commit message. The final two commits refactor the code and don't affect its functionality. This commit does what b168fff attempted to do (prevent the prefix from being added), but does it properly, instead of passing in an empty buffer (which is what b168fff actually did). Fixes: b168fff72109 ("hfsplus: use xattr handlers for removexattr") Signed-off-by: Thomas Hebb <[email protected]> Cc: Hin-Tak Leung <[email protected]> Cc: Sergei Antonov <[email protected]> Cc: Anton Altaparmakov <[email protected]> Cc: Fabian Frederick <[email protected]> Cc: Christian Kujau <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Al Viro <[email protected]> Cc: Viacheslav Dubeyko <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17hfsplus: fix expand when not enough available spaceSergei Antonov1-0/+6
Fix a bug which is reproduced as follows. Create a file: echo abc > test_file Try to expand the file beyond available space: truncate --size=<size exceeding available space> test_file Since HFS+ does not support file size > allocated size, truncate should fail. However, it ends successfully. The driver returns success despite having been unable to allocate the requested space for the file. Also filesystem check finds an error: Checking catalog file. Incorrect size for file test_file (It should be 469094400 instead of 1000000000) Add a piece of code analogous to code in the fat driver. Now a proper error is returned and filesystem remains consistent. Signed-off-by: Sergei Antonov <[email protected]> Cc: Vyacheslav Dubeyko <[email protected]> Cc: Hin-Tak Leung <[email protected]> Reviewed-by: Anton Altaparmakov <[email protected]> Cc: Al Viro <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Sougata Santra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17hfsplus: incorrect return valueChengyu Song1-2/+2
In case of memory allocation error, the return should be -ENOMEM, instead of -ENOSPC. Signed-off-by: Chengyu Song <[email protected]> Reviewed-by: Sergei Antonov <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/hfsplus: replace if/BUG by BUG_ONFabian Frederick1-3/+1
Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/hfsplus: use bool instead of int for is_known_namespace() return valueFabian Frederick1-1/+1
is_known_namespace() only returns true/false. Also remove inline and let compiler decide what to do with static functions. Signed-off-by: Fabian Frederick <[email protected]> Cc: "David S. Miller" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/hfsplus: atomically set inode->i_flagsFabian Frederick1-7/+5
According to commit 5f16f3225b06 ("ext4: atomically set inode->i_flags in ext4_set_inode_flags()"). Signed-off-by: Fabian Frederick <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Al Viro <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/hfsplus: move xattr_name allocation in hfsplus_setxattr()Fabian Frederick5-65/+35
security/trusted/user/osx setxattr did the same xattr_name initialization. Move that operation in hfsplus_setxattr(). Tested with security/trusted/user getfattr/setfattr Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17fs/hfsplus: move xattr_name allocation in hfsplus_getxattr()Fabian Frederick5-67/+38
security/trusted/user/osx getxattr did the same xattr_name initialization. Move that operation in hfsplus_getxattr(). Tested with security/trusted/user getfattr/setfattr Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17hfsplus: add missing curly braces in hfsplus_delete_cat()Dan Carpenter1-1/+2
This doesn't change how the code works, but clearly the curly braces were intended. Signed-off-by: Dan Carpenter <[email protected]> Cc: Vyacheslav Dubeyko <[email protected]> Cc: Sougata Santra <[email protected]> Cc: Christoph Hellwig <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17hfs: incorrect return valuesChengyu Song1-2/+2
In case of memory allocation error, the return should be -ENOMEM, instead of -ENOSPC. Signed-off-by: Chengyu Song <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: use inode_set_flags() in nilfs_set_inode_flags()Ryusuke Konishi1-7/+8
Use inode_set_flags() to atomically set i_flags instead of clearing out the S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the FS_IMMUTABLE_FL, FS_APPEND_FL flags to avoid a race where an immutable file has the immutable flag cleared for a brief window of time. This is a similar fix to commit 5f16f3225b06 ("ext4: atomically set inode->i_flags in ext4_set_inode_flags()"). Signed-off-by: Ryusuke Konishi <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: put out gfp mask manipulation from nilfs_set_inode_flags()Ryusuke Konishi1-2/+2
nilfs_set_inode_flags() function adjusts gfp-mask of inode->i_mapping as well as i_flags, however, this coupling of operations is not appropriate. For instance, nilfs_ioctl_setflags(), one of three callers of nilfs_set_inode_flags(), doesn't need to reinitialize the gfp-mask at all. In addition, nilfs_new_inode(), another caller of nilfs_set_inode_flags(), doesn't either because it has already initialized the gfp-mask. Only __nilfs_read_inode(), the remaining caller, needs it. So, this moves the gfp mask manipulation to __nilfs_read_inode() from nilfs_set_inode_flags(). Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: fix gcc warning at nilfs_checkpoint_is_mounted()Ryusuke Konishi1-1/+1
Fix the following build warning: fs/nilfs2/super.c: In function 'nilfs_checkpoint_is_mounted': fs/nilfs2/super.c:1023:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if (cno < 0 || cno > nilfs->ns_cno) ^ This warning indicates that the comparision "cno < 0" is useless because variable "cno" has an unsigned integer type "__u64". Signed-off-by: Ryusuke Konishi <[email protected]> Reported-by: David Binderman <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: improve execution time of NILFS_IOCTL_GET_CPINFO ioctlRyusuke Konishi1-6/+52
The older a filesystem gets, the slower lscp command becomes. This is because nilfs_cpfile_do_get_cpinfo() function meets more hole blocks as the start offset of valid checkpoint numbers gets bigger. This reduces the overhead by skipping hole blocks efficiently with nilfs_mdt_find_block() helper. A measurement result of this patch is as follows: Before: $ time lscp CNO DATE TIME MODE FLG BLKCNT ICNT 5769303 2015-02-22 19:31:33 cp - 108 1 5769304 2015-02-22 19:38:54 cp - 108 1 real 0m0.182s user 0m0.003s sys 0m0.180s After: $ time lscp CNO DATE TIME MODE FLG BLKCNT ICNT 5769303 2015-02-22 19:31:33 cp - 108 1 5769304 2015-02-22 19:38:54 cp - 108 1 real 0m0.003s user 0m0.001s sys 0m0.002s Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: add helper to find existent block on metadata fileRyusuke Konishi2-0/+57
Add a new metadata file function, nilfs_mdt_find_block(), which finds an existent block on a metadata file in a given range of blocks. This function skips continuous hole blocks efficiently by using nilfs_bmap_seek_key(). Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: add bmap function to seek a valid keyRyusuke Konishi4-1/+115
Add a new bmap function, nilfs_bmap_seek_key(), which seeks a valid entry and returns its key starting from a given key. This function can be used to skip hole blocks efficiently. Signed-off-by: Ryusuke Konishi <[email protected]> Cc: Dan Carpenter <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: unify type of key arguments in bmap interfaceRyusuke Konishi4-20/+16
The type of key arguments in block mapping interface varies depending on function. For instance, nilfs_bmap_lookup_at_level() takes "__u64" for its key argument whereas nilfs_bmap_lookup() takes "unsigned long". This fits them to "__u64" to eliminate the variation. Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: use bgl_lock_ptr()Ryusuke Konishi1-2/+5
Simplify nilfs_mdt_bgl_lock() by utilizing bgl_lock_ptr() helper in <linux/blockgroup_lock.h>. Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: use set_mask_bits() for operations on buffer state bitmapRyusuke Konishi2-20/+18
nilfs_forget_buffer(), nilfs_clear_dirty_page(), and nilfs_segctor_complete_write() are using a bunch of atomic bit operations against buffer state bitmap. This reduces the number of them by utilizing set_mask_bits() macro. Signed-off-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17nilfs2: do not use async write flag for segment summary buffersRyusuke Konishi1-3/+0
The async write flag is introduced to nilfs2 in the commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks"), but the flag only makes sense for data buffers and btree node buffers. It is not needed for segment summary buffers. This gets rid of the latter uses as part of refactoring of atomic bit operations on buffer state bitmap. Signed-off-by: Ryusuke Konishi <[email protected]> Cc: Vyacheslav Dubeyko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17befs: replace typedef befs_inode_info by structureFabian Frederick2-7/+7
See Documentation/CodingStyle Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17befs: replace typedef befs_sb_info by structureFabian Frederick5-13/+11
See Documenation/CodingStyle Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17befs: replace typedef befs_mount_options by structureFabian Frederick2-5/+5
See Documentation/CodingStyle Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17rtc: use more standard kernel logging stylesJoe Perches13-24/+49
Neaten the logging a bit by adding #define pr_fmt Miscellanea: o Remove __FILE__/__func__ uses o Coalesce formats adding missing spaces o Align arguments o (rtc-cmos) Integrated 2 consecutive messages Signed-off-by: Joe Perches <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: Joshua Kinard <[email protected]> Cc: Chanwoo Choi <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Tested-by: Krzysztof Kozlowski <[email protected]> Cc: Aaro Koskinen <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-hym8563.c: fix swapped enable/disable of clockout control bitHeiko Stübner1-5/+5
The hym8563 datasheet describes the clock output control-bit as "when set to logic 0, the square wave output is enable, when set to logic 1, the CLKOUT output is inhibited". But in reality the setting is exactly opposite. Before now, the clock output was not really used, but on the rk3288 soc this generated clock is used to supply the temperature sensor block and the swapped bit value prevented it from working. With the corrected value, the tsadc now reports correct values. Signed-off-by: Heiko Stuebner <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-s3c.c: remove one superfluous rtc_valid_tm() checkKrzysztof Kozlowski1-3/+1
s3c_rtc_gettime() already returns the result of rtc_valid_tm() on the obtained time so get rid of another call to rtc_valid_tm(). Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Chanwoo Choi <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: Marek Szyprowski <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-omap.c: use module_platform_driverLokesh Vutla1-2/+3
module_platform_driver_probe() prevents driver from requesting probe deferral. So using module_platform_drive() to support probe deferral. Signed-off-by: Lokesh Vutla <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Tero Kristo <[email protected]> Cc: Sekhar Nori <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/Kconfig: update Kconfig for OMAP RTCLokesh Vutla1-3/+3
RTC is present in AM43xx and DRA7xx also. Updating the Kconfig to depend on ARCH_OMAP or ARCH_DAVINCI Signed-off-by: Lokesh Vutla <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Tero Kristo <[email protected]> Cc: Sekhar Nori <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-omap.c: unlock and lock rtc registers before and after ↵Lokesh Vutla1-11/+52
register writes RTC module contains a kicker mechanism to prevent any spurious writes from changing the register values. This mechanism requires two MMR writes to the KICK0 and KICK1 registers with exact data values before the kicker lock mechanism is released. Currently the driver release the lock in the probe and leaves it enabled until the rtc driver removal. This eliminates the idea of preventing spurious writes when RTC driver is loaded. So implement rtc lock and unlock functions before and after register writes. This is as advised by Paul to implement lock and unlock functions in the driver and not to unlock and leave it in probe. The same discussion can be seen here: http://www.mail-archive.com/linux-omap%40vger.kernel.org/msg111588.html Signed-off-by: Lokesh Vutla <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: Paul Walmsley <[email protected]> Cc: Tero Kristo <[email protected]> Cc: Sekhar Nori <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-s3c.c: fix failed first read of RTC timeKrzysztof Kozlowski1-16/+16
Initialize the device time (if it is wrong) before registering RTC device to fix following error message during rtc-s3c probe: [ 2.215414] rtc (null): read_time: fail to read [ 2.216322] s3c-rtc 10070000.rtc: rtc core: registered s3c as rtc1 Signed-off-by: Krzysztof Kozlowski <[email protected]> Cc: Alessandro Zummo <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Marek Szyprowski <[email protected]> Reviewed-by: Chanwoo Choi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17rtc: hctosys: use function name in the error logAaro Koskinen1-1/+1
Use function name in the error log instead of __FILE__. Signed-off-by: Aaro Koskinen <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/interface.c: __rtc_read_time: reduce log levelAaro Koskinen1-2/+3
__rtc_read_time logs should be debug logs instead of error logs. For example, when the RTC clock is not set, it's not really useful to print a kernel error log every time someone tries to read the clock: ~ # hwclock -r [ 604.508263] rtc rtc0: read_time: fail to read hwclock: RTC_RD_TIME: Invalid argument If there's a real error, it's likely that lower level or higher level code will tell it anyway. Make these logs debug logs, and also print the error code for the read failure. Signed-off-by: Aaro Koskinen <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/class.c: initialize rtc name earlyAaro Koskinen1-3/+3
In some error cases RTC name is used before it is initialized: rtc-rs5c372 0-0032: clock needs to be set rtc-rs5c372 0-0032: rs5c372b found, 24hr, driver version 0.6 rtc (null): read_time: fail to read rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0 Fix by initializing the name early. Signed-off-by: Aaro Koskinen <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-s5m.c: add support for S2MPS13 RTCKrzysztof Kozlowski2-1/+21
The S2MPS13 RTC is almost the same as S2MPS14. The differences when updating alarm are: 1. Set WUDR+AUDR field instead of WUDR+RUDR. 2. Clear the AUDR field later (it is not auto-cleared). Signed-off-by: Krzysztof Kozlowski <[email protected]> Cc: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17MAINTAINERS: Add Alexandre Belloni as an RTC maintainerAlexandre Belloni1-0/+1
I've noticed that most of the patches for the RTC subsystem are currently either taken directly by Andrew or going through another maintainer's tree, quite often without an Acked-by or Reviewed-by tag. I'd like to propose myself as the RTC subsystem co-maintainer, to mainly help Alessandro reviewing incoming patches and maintain a subsystem tree to avoid having the RTC patches going through trees when they have no particular dependencies. Signed-off-by: Alexandre Belloni <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17rtc: driver for Conexant Digicolor CX92755 on-chip RTCBaruch Siach3-0/+238
Add driver for the RTC hardware block on the Conexant CX92755 SoC, from the Digicolor series of SoCs. Tested on the Equinox evaluation board for the CX92755 chip. [[email protected]: build command arrays at compile-time] Signed-off-by: Baruch Siach <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17rtc: digicolor: document device tree bindingBaruch Siach1-0/+17
Add a device tree binding documentation to the Real Time Clock hardware block on the Conexant CX92755 SoC. The CX92755 is from the Digicolor SoCs series. Other SoCs in that series may share the same hardware block. Signed-off-by: Baruch Siach <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-hym8563.c: return clock rate even when clock is disabledHeiko Stuebner1-1/+1
When the clock is disabled, do not return a rate of 0 but instead return the rate the clock will be running at after it gets enabled. This prevents problems when the core clock code is trying to determine a suitable rate, while the clock is still off. Signed-off-by: Heiko Stuebner <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-da9052.c: register ability of alarm to wake device from suspendAdam Ward1-0/+2
Signed-off-by: Adam Ward <[email protected]> Tested-by: Adam Ward <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-da9052.c: add constraints to set valid yearAdam Ward1-0/+8
Signed-off-by: Adam Ward <[email protected]> Tested-by: Adam Ward <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-da9052.c: add extra reads with timeouts to avoid returning ↵Adam Ward1-21/+66
partially updated values The RTC is in a different clock domain so a quick read after write can retrieve a mangled value of the old/new values Signed-off-by: Adam Ward <[email protected]> Tested-by: Adam Ward <[email protected]> Cc: Alessandro Zummo <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-04-17drivers/rtc/rtc-ds1685.c: fix sparse warningsJoshua Kinard1-2/+2
Fix two minor sparse warnings: CHECK drivers/rtc/rtc-ds1685.c drivers/rtc/rtc-ds1685.c:2178:1: warning: function 'ds1685_rtc_poweroff' with external linkage has definition drivers/rtc/rtc-ds1685.c:802:23: warning: Using plain integer as NULL pointer Fixes: aaaf5fbf56f1 ("rtc: add driver for DS1685 family of real time clocks") Signed-off-by: Joshua Kinard <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.