Tejun Heo [Wed, 20 Feb 2013 02:16:03 +0000 (13:16 +1100)]
idr: make idr_destroy() imply idr_remove_all()
idr is silly in quite a few ways, one of which is how it's supposed to
be destroyed - idr_destroy() doesn't release IDs and doesn't even
whine if the idr isn't empty. If the caller forgets idr_remove_all(),
it simply leaks memory.
Even ida gets this wrong and leaks memory on destruction. There is
absoltely no reason not to call idr_remove_all() from idr_destroy().
Nobody is abusing idr_destroy() for shrinking free layer buffer and
continues to use idr after idr_destroy(), so it's safe to do
remove_all from destroy.
In the whole kernel, there is only one place where idr_remove_all() is
legitimiately used without following idr_destroy() while there are
quite a few places where the caller forgets either idr_remove_all() or
idr_destroy() leaking memory.
This patch makes idr_destroy() call idr_destroy_all() and updates the
function description accordingly.
Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tejun Heo [Wed, 20 Feb 2013 02:16:03 +0000 (13:16 +1100)]
idr: fix a subtle bug in idr_get_next()
The iteration logic of idr_get_next() is borrowed mostly verbatim from
idr_for_each(). It walks down the tree looking for the slot matching
the current ID. If the matching slot is not found, the ID is
incremented by the distance of single slot at the given level and
repeats.
The implementation assumes that during the whole iteration id is
aligned to the layer boundaries of the level closest to the leaf,
which is true for all iterations starting from zero or an existing
element and thus is fine for idr_for_each().
However, idr_get_next() may be given any point and if the starting id
hits in the middle of a non-existent layer, increment to the next
layer will end up skipping the same offset into it. For example, an
IDR with IDs filled between [64, 127] would look like the following.
[ 0 64 ... ]
/----/ |
| |
NULL [ 64 ... 127 ]
If idr_get_next() is called with 63 as the starting point, it will try
to follow down the pointer from 0. As it is NULL, it will then try to
proceed to the next slot in the same level by adding the slot distance
at that level which is 64 - making the next try 127. It goes around
the loop and finds and returns 127 skipping [64, 126].
Note that this bug also triggers in idr_for_each_entry() loop which
deletes during iteration as deletions can make layers go away leaving
the iteration with unaligned ID into missing layers.
Fix it by ensuring proceeding to the next slot doesn't carry over the
unaligned offset - ie. use round_up(id + 1, slot_distance) instead of
id += slot_distance.
Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: David Teigland <teigland@redhat.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This most likely happens because dev_t is freed while the number is still
used and idr_get_new() is not protected on every use. The fix adds a
mutex where it wasn't before and moves the dev_t free function so it is
called after device del.
Signed-off-by: Tomas Henzl <thenzl@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Mitsuhiro Tanino [Wed, 20 Feb 2013 02:16:02 +0000 (13:16 +1100)]
kexec: export PG_hwpoison flag into vmcoreinfo
This patch exports a PG_hwpoison into vmcoreinfo when
CONFIG_MEMORY_FAILURE is defined. "makedumpfile" needs to read
information of memory, such as 'mem_section', 'zone', 'pageflags' from
vmcore.
We introduce a function into "makedumpfile" to exclude hwpoison page from
vmcore dump. In order to introduce this function, PG_hwpoison flag have
to export into vmcoreinfo.
Atsushi Kumagai [Wed, 20 Feb 2013 02:16:01 +0000 (13:16 +1100)]
kexec: add the values related to buddy system for filtering free pages.
tAdd adds the values related to buddy system to vmcoreinfo data so that
makedumpfile (dump filtering command) can filter out all free pages with
the new logic.
It's faster than the current logic because it can distinguish free page by
analyzing page structure at the same time as filtering for other
unnecessary pages (e.g. anonymous page).
OTOH, the current logic has to trace free_list to distinguish free pages
while analyzing page structure to filter out other unnecessary pages.
The new logic uses the fact that buddy page is marked by _mapcount ==
PAGE_BUDDY_MAPCOUNT_VALUE. But, _mapcount shares its memory with other
fields for SLAB/SLUB when PG_slab is set, so we need to check if PG_slab
is set or not before looking up _mapcount value. And we can get the order
of buddy system from private field. To sum it up, the values below are
required for this logic.
Changelog from v1 to v2:
1. remove SIZE(pageflags)
The new logic was changed after I sent v1 patch.
Accordingly, SIZE(pageflags) has been unnecessary for makedumpfile.
What's makedumpfile:
makedumpfile creates a small dumpfile by excluding unnecessary pages
for the analysis. To distinguish unnecessary pages, makedumpfile gets
the vmcoreinfo data which has the minimum debugging information only
for dump filtering.
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Alan Cox [Wed, 20 Feb 2013 02:16:01 +0000 (13:16 +1100)]
fork: unshare: remove dead code
If new_nsproxy is set we will always call switch_task_namespaces and then
set new_nsproxy back to NULL so the reassignment and fall through check
are redundant
Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Ben Chan [Wed, 20 Feb 2013 02:15:59 +0000 (13:15 +1100)]
coredump: abort core dump piping only due to a fatal signal
Make wait_for_dump_helpers() not abort piping the core dump data when the
crashing process has received a non-fatal signal. The abort still occurs
in the case of SIGKILL.
The rationale is that a crashing process may still receive uninteresting
signals such as SIGCHLD when its core dump data is being redirected to a
helper application. While it's necessary to allow terminating the core
dump piping via SIGKILL, it's practically more useful for the purpose of
debugging and crash reporting if the core dump piping is not aborted due
to other non-fatal signals.
Signed-off-by: Ben Chan <benchan@chromium.org> Signed-off-by: Mandeep Singh Baines <msb@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Tejun Heo <tj@kernel.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
We shouldn't try_to_freeze if locks are held. Verified that I get no
lockdep warnings after applying this patch and "vfork: don't
freezer_count() for in-kernel users of CLONE_VFORK".
Signed-off-by: Mandeep Singh Baines <msb@chromium.org> Cc: Ben Chan <benchan@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Tejun Heo <tj@kernel.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
vfork: don't freezer_count() for in-kernel users of CLONE_VFORK
We don't need to call freezer_do_not_count() for in-kernel users of
CLONE_VFORK since exec will get called in bounded time.
We don't want to call freezer_count() for in-kernel users because they may
be holding locks. freezer_count() calls try_to_freeze(). We don't want
to freeze an in-kernel user because it may be holding locks.
In a follow-up patch, I call debug_check_no_locks_held() from
try_to_freeze(). After applying this patch, I get no lockdep warnings
with that patch.
Signed-off-by: Mandeep Singh Baines <msb@chromium.org> Cc: Ben Chan <benchan@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Tejun Heo <tj@kernel.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Zhang Yanfei [Wed, 20 Feb 2013 02:15:57 +0000 (13:15 +1100)]
fs/proc/vmcore.c: put if tests in the top of the while loop to reduce duplication
In read_vmcore() two `if' tests are duplicated. Change the position of
them could reduce the duplication. This change does not affect the
behaviour of the function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Kees Cook [Wed, 20 Feb 2013 02:15:56 +0000 (13:15 +1100)]
coredump: remove redundant defines for dumpable states
The existing SUID_DUMP_* defines duplicate the newer SUID_DUMPABLE_*
defines introduced in 54b501992dd ("coredump: warn about unsafe
suid_dumpable / core_pattern combo"). Remove the new ones, and use the
prior values instead.
Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Chen Gang <gang.chen@asianux.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Alan Cox <alan@linux.intel.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Serge Hallyn <serge.hallyn@canonical.com> Cc: James Morris <james.l.morris@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Valdis Kletnieks [Wed, 20 Feb 2013 02:15:55 +0000 (13:15 +1100)]
kernel/signal.c - fix suboptimal printk usage
Several printk's were missing KERN_INFO and KERN_CONT flags.
In addition, a printk that was outside a #if/#endif should have
been inside, which would result in stray blank line on non-x86 boxes.
Andrey Vagin [Wed, 20 Feb 2013 02:15:55 +0000 (13:15 +1100)]
signal: allow to send any siginfo to itself
The idea is simple. We need to get the siginfo for each signal on
checkpointing dump, and then return it back on restore.
The first problem is that the kernel doesn't report complete siginfos to
userspace. In a signal handler the kernel strips SI_CODE from siginfo.
When a siginfo is received from signalfd, it has a different format with
fixed sizes of fields. The interface of signalfd was extended. If a
signalfd is created with the flag SFD_RAW, it returns siginfo in a raw
format.
rt_sigqueueinfo looks suitable for restoring signals, but it can't
send siginfo with a positive si_code, because these codes are reserved for
the kernel. In the real world each person has right to do anything with
himself, so I think a process should able to send any siginfo to itself.
This patch:
The kernel prevents sending of siginfo with positive si_code, because
these codes are reserved for kernel. I think we can allow a task to send
such a siginfo to itself. This operation should not be dangerous.
This functionality is required for restoring signals in
checkpoint/restart.
Signed-off-by: Andrey Vagin <avagin@openvz.org> Cc: Serge Hallyn <serge.hallyn@canonical.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Pavel Emelyanov <xemul@parallels.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Oleksij Rempel [Wed, 20 Feb 2013 02:15:54 +0000 (13:15 +1100)]
fat: mark fs as dirty on mount and clean on umount
There is no documented methods to mark FAT as dirty. Unofficially MS
started to use reserved Byte in boot sector for this purpose, at least
since Win 2000. With Win 7 user is warned if fs is dirty and asked to
clean it.
Different versions of Win, handle it in different ways, but always have
same meaning:
- Win 2000 and XP, set it on write operations and
remove it after operation was finnished
- Win 7, set dirty flag on first write and remove it on umount.
We will do it as follows:
- set dirty flag on mount. If fs was initially dirty, warn user,
remember it and do not do any changes to boot sector.
- clean it on umount. If fs was initially dirty, leave it dirty.
- do not do any thing if fs mounted read-only.
- TODO: leave fs dirty if we found some error after mount.
hfsplus: fix issue with unzeroed unused b-tree nodes
The fsck_hfs (under MacOS X) complains about unzeroed unused b-tree nodes
after deletion of folders' tree under Linux.
SYMPTOMS:
Running Disk Utiltiy's "Verify Disk" on "test" gives the following:
Verifying volume “Test”
Checking file systemChecking Journaled HFS Plus volume.
Checking extents overflow file.
Checking catalog file.
Unused node is not erased (node = 3111)
Checking multi-linked files.
Checking catalog hierarchy.
Checking extended attributes file.
Checking volume bitmap.
Checking volume information.
The volume Test was found corrupt and needs to be repaired.
Error: This disk needs to be repaired. Click Repair Disk.
REPRODUCING PATH:
1. Prepare HFS+ (non-case sensitive) partition (for example, 5GB)
under MacOS X.
2. Copy linux kernel source tree (for example, 3.7-rc6 version) on
this partition under MacOS X.
3. Then switch to Linux and mount this prepared partition.
4. Execute `sudo rm -r` under prepared directory with linux kernel
source tree.
5. Unmount and boot back into OS X.
6. Open up Disk Utility and verify partition.
REPRODUCIBILITY: 100%
FIX:
It is added code of node clearing in hfs_bnode_put() method for the case
when node has flag HFS_BNODE_DELETED.
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com> Reported-by: Kyle Laracey <kalaracey@gmail.com> Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
hfsplus: add support of manipulation by attributes file
Add support of manipulation by attributes file.
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com> Reported-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
hfsplus: rework functionality of getting, setting and deleting of extended attributes
Rework functionality of getting, setting and deleting of extended attributes.
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com> Reported-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
hfsplus: add functionality of manipulating by records in attributes tree
Add functionality of manipulating by records in attributes tree.
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com> Reported-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
hfsplus: add on-disk layout declarations related to attributes tree
Add all necessary on-disk layout declarations related to attributes file.
Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com> Reported-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
hfsplus: add osx.* prefix for handling namespace of Mac OS X extended attributes
hfsplus: reworked support of extended attributes.
Current mainline implementation of hfsplus file system driver treats as
extended attributes only two fields (fdType and fdCreator) of user_info
field in file description record (struct hfsplus_cat_file). It is
possible to get or set only these two fields as extended attributes. But
HFS+ treats as com.apple.FinderInfo extended attribute an union of
user_info and finder_info fields as for file (struct hfsplus_cat_file) as
for folder (struct hfsplus_cat_folder). Moreover, current mainline
implementation of hfsplus file system driver doesn't support special
metadata file - attributes tree.
Mac OS X 10.4 and later support extended attributes by making use of the
HFS+ filesystem Attributes file B*-tree feature which allows for named
forks. Mac OS X supports only inline extended attributes, limiting their
size to 3802 bytes. Any regular file may have a list of extended
attributes. HFS+ supports an arbitrary number of named forks. Each
attribute is denoted by a name and the associated data. The name is a
null-terminated Unicode string. It is possible to list, to get, to set,
and to remove extended attributes from files or directories.
It exists some peculiarity during getting of extended attributes list by
means of getfattr utility. The getfattr utility expects prefix "user."
before any extended attribute's name. So, it ignores any names that don't
contained such prefix. Such behavior of getfattr utility results in
unexpected empty output of extended attributes list even in the case when
file (or folder) contains extended attributes. It needs to use empty
string as regular expression pattern for names matching (getfattr
--match="").
For support of extended attributes in HFS+:
1. It was added necessary on-disk layout declarations related to Attributes
tree into hfsplus_raw.h file.
2. It was added attributes.c file with implementation of functionality of
manipulation by records in Attributes tree.
3. It was reworked hfsplus_listxattr, hfsplus_getxattr, hfsplus_setxattr
functions in ioctl.c. Moreover, it was added hfsplus_removexattr method.
This patch:
Add osx.* prefix for handling namespace of Mac OS X extended attributes.
[akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: Vyacheslav Dubeyko <slava@dubeyko.com> Reported-by: Hin-Tak Leung <htl10@users.sourceforge.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Chao Xie [Wed, 20 Feb 2013 02:15:48 +0000 (13:15 +1100)]
drivers/rtc/rtc-sa1100.c: move clock enable/disable to probe/remove
The original sa1100_rtc_open/sa1100_rtc_release will be called when the
/dev/rtc0 is opened or closed. In fact, these two functions will
enable/disable the clock. Disabling clock will make rtc not work. So
only enable/disable clock when probe/remove the device.
Signed-off-by: Chao Xie <chao.xie@marvell.com> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> Cc: Leo Song <liangs@marvell.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jonghwa Lee [Wed, 20 Feb 2013 02:15:47 +0000 (13:15 +1100)]
rtc: max8997: add driver for max8997 rtc
Add an rtc driver for Maxim 8997 multifunction chip. Max8997 has rtc
module in it. and it can be used for timekeeping clock and system alarm.
It provide various operational mode those are BCD/binary, 24/12hour,
am/pm. Driver sets binary/24/ for default. Maxim 8997 also supports
SMPL(Sudden Momentary Power Loss), WTSR (Watchdog Timeout and Software
Reset).
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com> Cc: Devendra Naga <devendra.aaru@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Gregory CLEMENT [Wed, 20 Feb 2013 02:15:47 +0000 (13:15 +1100)]
arm: mvebu: add RTC support for Armada 370 and Armada XP
The Armada 370 and Armada XP Socs have the same controller that the one
used in the orion platforms. This patch updates the device tree for these
SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Cc: Russell King <linux@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
WARNING: Using __devinit is unnecessary
#310: FILE: drivers/rtc/rtc-rx4581.c:265:
+static int __devinit rx4581_probe(struct spi_device *spi)
WARNING: Using __devexit is unnecessary
#329: FILE: drivers/rtc/rtc-rx4581.c:284:
+static int __devexit rx4581_remove(struct spi_device *spi)
WARNING: space prohibited between function name and open parenthesis '('
#355: FILE: drivers/rtc/rtc-rx4581.c:310:
+MODULE_DESCRIPTION ("rx4581 spi RTC driver");
WARNING: space prohibited between function name and open parenthesis '('
#356: FILE: drivers/rtc/rtc-rx4581.c:311:
+MODULE_AUTHOR ("Torben Hohn");
WARNING: space prohibited between function name and open parenthesis '('
#357: FILE: drivers/rtc/rtc-rx4581.c:312:
+MODULE_LICENSE ("GPL");
total: 0 errors, 8 warnings, 334 lines checked
./patches/rtc-add-support-for-spi-rtc-rx4581.patch has style problems, please review.
If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Torben Hohn <torbenh@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Feb 2013 02:15:45 +0000 (13:15 +1100)]
drivers/rtc/rtc-tps65910.c: set irq flag to IRQF_EARLY_RESUME during irq request
All interrupt get disabled during system suspend and enabled during system
resume. The enabling/disabling of interrupt happen in sequence of
interrupt registration with framework.
Therefore, in resume, the parent interrupt of this device enabled before
the RTC irq interrupt enabled. If RTC is enabled for alarm wake and if
system wake by alarm then there is interrupt pending for RTC. In resume,
the parent interrupt get enabled before the rtc interrupt and hence ISR
get served. In ISR, it founds that rtc interrupt is disabled and so it
does not call the rtc isr handler and hence it misses the interrupt.
Setting flag for early resume so that rtc interrupt get enabled before
parent interrupt and so rtc interrupt get enabled when parent interrupt
handler check for interrupt of device and call the rtc handler if it is
there. This way it will not miss the interrupt.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Feb 2013 02:15:45 +0000 (13:15 +1100)]
drivers/rtc/rtc-tps65910.c: use sleep_pm_ops macro for initialising suspend/resume callbacks
Use SET_SYSTEM_SLEEP_PM_OPS for setting suspend/resume callbacks for
dev_pm_ops.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Feb 2013 02:15:44 +0000 (13:15 +1100)]
drivers/rtc/rtc-tps65910.c: remove unnecessary irq stat save and restore
The driver stores the interrupt enable register before going to suspend
and restore in resume. Also it enables alarm before going to suspend.
The driver only write the Interrupt enable register for enabling ALARM and
does not enable any other bits. So it is not require to save complete
register and enable ALARM interrupt before suspend and restore in resume.
Also ALARM interrupt already enable if alarm is enabled before going to
suspend and hence it is not require to enable explictly in suspend.
Removing such above code.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Feb 2013 02:15:44 +0000 (13:15 +1100)]
drivers/rtc/rtc-tps65910.c: enable/disable wake in suspend/resume
Making the rtc driver as wakeup capabale and leaving the wake
enable/disable decision to user space through a sysfs attribute.
In suspend, enable wake if device wakeup enabled. In resume disable wake
again.
This change is inline with the Documentation/power/devices.txt#
/sys/devices/.../power/wakeup files
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Laxman Dewangan [Wed, 20 Feb 2013 02:15:43 +0000 (13:15 +1100)]
rtc-add-rtc-driver-for-tps80031-tps80032-v2
Changes from V1:
- remvoe the checks for alarm time whether this is past or not in set_alarm.
- add error prints if rtc registration failed.
- add include of pm.h
Laxman Dewangan [Wed, 20 Feb 2013 02:15:43 +0000 (13:15 +1100)]
rtc: add RTC driver for TPS80031/TPS80032
Add an RTC driver for TPS80031/TPS80032 chips by TI.
This driver supports:
- Setting and getting time and date.
- Setting and reading alarm time.
- Alarm and interrupt functionlity.
Cc: Chiwoong Byun <woong.byun@samsung.com> Cc: Jingoo Han <jg1.han@samsung.com> Cc: Jonghwa Lee <jonghwa3.lee@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Myugnjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
drivers/rtc/rtc-max77686.c: In function 'max77686_rtc_update':
drivers/rtc/rtc-max77686.c:147:6: warning: 'data' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Chiwoong Byun <woong.byun@samsung.com> Cc: Jonghwa Lee <jonghwa3.lee@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Myugnjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Andrew Morton [Wed, 20 Feb 2013 02:15:40 +0000 (13:15 +1100)]
rtc-max77686-add-maxim-77686-driver-fix
remove inline, __devinit annotations
Cc: Chiwoong Byun <woong.byun@samsung.com> Cc: Jonghwa Lee <jonghwa3.lee@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Myugnjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jonghwa Lee [Wed, 20 Feb 2013 02:15:39 +0000 (13:15 +1100)]
rtc: max77686: add Maxim 77686 driver
Add a driver to support max77686 rtc. MAX77686 rtc support smpl and wtsr
mode. It has two alarm register which can be used for alarming to wake
system up. This drvier uses regmap to access its register.
Signed-off-by: Chiwoong Byun <woong.byun@samsung.com> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com> Signed-off-by: Myugnjoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bertrand Achard [Wed, 20 Feb 2013 02:15:39 +0000 (13:15 +1100)]
drivers/rtc/rtc-ds1307.c: long block operations bugfix
The rtc-ds1307 driver does not properly handle block operations bigger
than 32 bytes in either of the two modes supported (SMbus native, or
emulated if not supported by the SMbus platform driver).
It also does not properly handle userland-supplied input (block operation
length) through sysfs and may suffer a type of buffer overrun.
The driver has been modified with proper input validation, buffer sizes,
and now splits block transfers bigger than 32 bytes into separate
transfers.
Explanation : Buffer size allocated is I2C_SMBUS_BLOCK_MAX which equals to
32 as per the SMbus spec. Reads and write may be up to 56 bytes (to the
NVRAM). This patch allocated a 255 byte buffer, the maximum allowable
(address is an u8). It's not only a buffer problem, SMbus only supports
up to 32 bytes transfer at once, so it's needed to split bigger transfers.
Patch successfully tested on 3.2.27; cleanly applies on 3.7-rc4.
Signed-off-by: Bertrand Achard <ba@cykian.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The "fix set time sync time issue" adds calls to udelay(), but
doesn't add the include file. End result is build breakage:
drivers/rtc/rtc-pxa.c: In function 'pxa_rtc_set_time':
drivers/rtc/rtc-pxa.c:267:2: error: implicit declaration of function 'udelay' [-Werror=implicit-function-declaration]
Signed-off-by: Olof Johansson <olof@lixom.net> Cc: Leo Song <liangs@marvell.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
We observed this problem has been occurring since 2.6.30 with
fs/binfmt_elf.c: create_elf_tables()->get_random_bytes(), introduced by f06295b44c296c8f ("ELF: implement AT_RANDOM for glibc PRNG seeding").
/*
* Generate 16 random bytes for userspace PRNG seeding.
*/
get_random_bytes(k_rand_bytes, sizeof(k_rand_bytes));
The patch introduces a wrapper around get_random_int() which has lower
overhead than calling get_random_bytes() directly.
With this patch applied:
$ cat /proc/sys/kernel/random/entropy_avail
2731
$ cat /proc/sys/kernel/random/entropy_avail
2802
$ cat /proc/sys/kernel/random/entropy_avail
2878
Analyzed by John Sobecki.
Signed-off-by: Jie Liu <jeff.liu@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andreas Dilger <aedilger@gmail.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Arnd Bergmann <arnn@arndb.de> Cc: John Sobecki <john.sobecki@oracle.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Jakub Jelinek <jakub@redhat.com> Cc: Ted Ts'o <tytso@mit.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Kees Cook <keescook@chromium.org> Cc: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Paton J. Lewis [Wed, 20 Feb 2013 02:15:36 +0000 (13:15 +1100)]
epoll: support for disabling items, and a self-test app
It is not currently possible to reliably delete epoll items when using the
same epoll set from multiple threads. After calling epoll_ctl with
EPOLL_CTL_DEL, another thread might still be executing code related to an
event for that epoll item (in response to epoll_wait). Therefore the
deleting thread does not know when it is safe to delete resources
pertaining to the associated epoll item because another thread might be
using those resources.
The deleting thread could wait an arbitrary amount of time after calling
epoll_ctl with EPOLL_CTL_DEL and before deleting the item, but this is
inefficient and could result in the destruction of resources before
another thread is done handling an event returned by epoll_wait.
This patch enhances epoll_ctl to support EPOLL_CTL_DISABLE, which disables
an epoll item. If epoll_ctl returns -EBUSY in this case, then another
thread may handling a return from epoll_wait for this item. Otherwise if
epoll_ctl returns 0, then it is safe to delete the epoll item. This
allows multiple threads to use a mutex to determine when it is safe to
delete an epoll item and its associated resources, which allows epoll
items to be deleted both efficiently and without error in a multi-threaded
environment. Note that EPOLL_CTL_DISABLE is only useful in conjunction
with EPOLLONESHOT, and using EPOLL_CTL_DISABLE on an epoll item without
EPOLLONESHOT returns -EINVAL.
This patch also adds a new test_epoll self-test program to both
demonstrate the need for this feature and test it.
Signed-off-by: Paton J. Lewis <palewis@adobe.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jason Baron <jbaron@redhat.com> Cc: Paul Holland <pholland@adobe.com> Cc: Davide Libenzi <davidel@xmailserver.org> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Bruce Allan [Wed, 20 Feb 2013 02:15:35 +0000 (13:15 +1100)]
checkpatch: fix USLEEP_RANGE test
Do not test udelay() for a value less than 10usec when passed a variable
instead of a hard-coded number; there is no way for checkpatch to know the
value of the variable. As it is today, it will complain about variables
with alphanumeric characters plus '_', e.g. foo_bar, but not variables
with other characters, eg. foo->bar.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Imre Deak [Wed, 20 Feb 2013 02:15:33 +0000 (13:15 +1100)]
lib/scatterlist: use page iterator in the mapping iterator
For better code reuse use the newly added page iterator to iterate through
the pages. The offset, length within the page is still calculated by the
mapping iterator as well as the actual mapping. Idea from Tejun Heo.
Signed-off-by: Imre Deak <imre.deak@intel.com> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Tejun Heo <tj@kernel.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Imre Deak [Wed, 20 Feb 2013 02:15:33 +0000 (13:15 +1100)]
lib/scatterlist: add simple page iterator
Add an iterator to walk through a scatter list a page at a time starting
at a specific page offset. As opposed to the mapping iterator this is
meant to be small, performing well even in simple loops like collecting
all pages on the scatterlist into an array or setting up an iommu table
based on the pages' DMA address.
Signed-off-by: Imre Deak <imre.deak@intel.com> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Tejun Heo <tj@kernel.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Florian Fainelli [Wed, 20 Feb 2013 02:15:33 +0000 (13:15 +1100)]
decompressors: make the default XZ_DEC_* config match the selected architecture
Change the defautl XZ_DEC_* config symbol to match the configured
architecture. It is perfectly legitimate to support multiple XZ BCJ
filters for different architectures (e.g.: to mount foreign squashfs/xz
compressed filesystems), it is however more natural not to select them all
by default, but only the one matching the configured architecture.
Signed-off-by: Florian Fainelli <florian@openwrt.org> Acked-by: Lasse Collin <lasse.collin@tukaani.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Namjae Jeon [Wed, 20 Feb 2013 02:15:32 +0000 (13:15 +1100)]
lib/parser.c: fix up comments for valid return values from match_number
match_number() has return values of -ENOMEM, -EINVAL and -ERANGE. So, for
all the functions calling match_number, the return value should include
these values. Fix up the comments to reflect the correct values.
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com> Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
drivers/leds/leds-ot200.c: fix error caused by shifted mask
During the development of this driver an in-house register documentation
was used. The last week some integration tests were done and this problem
was found. It turned out that the released register documentation is
wrong.
The fix is very simple: shift all masks by one.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Bryan Wu <cooloney@gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
projects / karo-tx-linux.git / log