aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-07-04Input: request threaded-only IRQs with IRQF_ONESHOTLars-Peter Clausen17-23/+34
Since commit 1c6c69525b ("genirq: Reject bogus threaded irq requests") threaded IRQs without a primary handler need to be requested with IRQF_ONESHOT, otherwise the request will fail. This patch adds the IRQF_ONESHOT to input drivers where it is missing. Not modified by this patch are those drivers where the requested IRQ will always be a nested IRQ (e.g. because it's part of an MFD), since for this special case IRQF_ONESHOT is not required to be specified when requesting the IRQ. Signed-off-by: Lars-Peter Clausen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2012-07-04ARM: fix mach-versatile/pci.c warningRussell King1-1/+0
arch/arm/mach-versatile/pci.c: In function 'versatile_map_irq': arch/arm/mach-versatile/pci.c:342: warning: unused variable 'devslot' Signed-off-by: Russell King <[email protected]>
2012-07-04regulator: arizona-micsupp: Force regulated mode until we have API supportMark Brown1-0/+4
It's almost certainly what the user would expect. Signed-off-by: Mark Brown <[email protected]>
2012-07-04ARM: OMAP2+: hwmod data: Fix wrong McBSP clock alias on OMAP4Benoit Cousson1-4/+4
The commit 503d0ea24d1d3dd3db95e5e0edd693da7a2a23eb ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks added a wrong "prcm_clk" alias for PRCM clock whereas the McBSP driver and previous OMAPs are using "prcm_fck". It thus lead to the following warning. [ 47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck Fix that by changing the opt_clk role to prcm_fck. Reported-by: Misael Lopez Cruz <[email protected]> Signed-off-by: Benoit Cousson <[email protected]> Cc: Peter Ujfalusi <[email protected]> Tested-by: Sebastien Guiriec <[email protected]> Signed-off-by: Paul Walmsley <[email protected]>
2012-07-04ARM: OMAP4: hwmod data: temporarily comment out data for the usb_host_fs and ↵Paul Walmsley1-10/+10
aess IP blocks The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special programming for them to enter idle. Without this programming, they will prevent the rest of the chip from entering full chip idle. To implement the idle programming cleanly, this will take some coordination between maintainers. This is likely to take some time, so it is probably best to leave this for 3.6 or 3.7. So, in the meantime, prevent these IP blocks from being registered. Later, once the appropriate support is available, this patch can be reverted. This second version comments out the IP block data since Benoît didn't like removing it. Signed-off-by: Paul Walmsley <[email protected]> Cc: Benoît Cousson <[email protected]>
2012-07-04Merge branch 'fixes' of git://github.com/hzhuang1/linux into fixesArnd Bergmann1-29/+0
From Haojian Zhuang <[email protected]>: * 'fixes' of git://github.com/hzhuang1/linux: ARM: mmp: remove mach/gpio-pxa.h Signed-off-by: Arnd Bergmann <[email protected]>
2012-07-04Merge tag 'v3.5-imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6 ↵Arnd Bergmann2-2/+9
into fixes From Sascha Hauer <[email protected]>: ARM i.MX fixes for v3.5-rc5 * tag 'v3.5-imx-fixes' of git://git.pengutronix.de/git/imx/linux-2.6: ARM: imx: assert SCC gate stays enabled ARM: imx27_visstrim_m10: Do not include <asm/system.h> Signed-off-by: Arnd Bergmann <[email protected]>
2012-07-04regulator: ad5398: Fix min/max current limit boundary checkingAxel Lin1-3/+6
It is ok to request current limit with min_uA < chip->min_uA and max_uA > chip->max_uA. We need to set min_uA = chip->min_uA if (min_uA < chip->min_uA), this ensures the equation to calcuate selator does not return negative number. Also set max_uA = chip->max_uA if (max_uA > chip->max_uA), as suggested by Sonic. Signed-off-by: Axel Lin <[email protected]> Acked-by: Sonic Zhang <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-04regulator: twl: Set enable enable_time in regulator_descAxel Lin1-27/+4
Signed-off-by: Axel Lin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-04regulator: gpio-regulator: Use core GPIO enable supportAxel Lin1-87/+16
Signed-off-by: Axel Lin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-04regulator: gpio-regulator: Set enable enable_time in regulator_descAxel Lin1-11/+1
Signed-off-by: Axel Lin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-04regulator: tps65910: Set enable enable_time in regulator_descAxel Lin1-11/+1
Signed-off-by: Axel Lin <[email protected]> Acked-by: Laxman Dewangan <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-04rpmsg: make sure inflight messages don't invoke just-removed callbacksOhad Ben-Cohen2-6/+22
When inbound messages arrive, rpmsg core looks up their associated endpoint (by destination address) and then invokes their callback. We've made sure that endpoints will never be de-allocated after they were found by rpmsg core, but we also need to protect against the (rare) scenario where the rpmsg driver was just removed, and its callback function isn't available anymore. This is achieved by introducing a callback mutex, which must be taken before the callback is invoked, and, obviously, before it is removed. Cc: stable <[email protected]> Reported-by: Fernando Guzman Lugo <[email protected]> Signed-off-by: Ohad Ben-Cohen <[email protected]>
2012-07-04rpmsg: avoid premature deallocation of endpointsOhad Ben-Cohen2-2/+37
When an inbound message arrives, the rpmsg core looks up its associated endpoint and invokes the registered callback. If a message arrives while its endpoint is being removed (because the rpmsg driver was removed, or a recovery of a remote processor has kicked in) we must ensure atomicity, i.e.: - Either the ept is removed before it is found or - The ept is found but will not be freed until the callback returns This is achieved by maintaining a per-ept reference count, which, when drops to zero, will trigger deallocation of the ept. With this in hand, it is now forbidden to directly deallocate epts once they have been added to the endpoints idr. Cc: stable <[email protected]> Reported-by: Fernando Guzman Lugo <[email protected]> Signed-off-by: Ohad Ben-Cohen <[email protected]>
2012-07-04ARM: Orion: Fix WDT compile for Dove and MV78xx0Andrew Lunn4-0/+5
Commit 0fa1f0609a0c1fe8b2be3c0089a2cb48f7fda521 (ARM: Orion: Fix Virtual/Physical mixup with watchdog) broke the Dove & MV78xx0 build. Although these two SoC don't use the watchdog, the shared platform code still needs to build. Add the necessary defines. Cc: [email protected] Reported-by: Nicolas Pitre <[email protected]> Signed-off-by: Andrew Lunn <[email protected]> Tested-by: Nicolas Pitre <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2012-07-04remoteproc: fix missing CONFIG_FW_LOADER configurationsOhad Ben-Cohen1-0/+1
Remoteproc requires user space firmware loading support, so let's select FW_LOADER explicitly to avoid painful misconfigurations (which only show up in runtime). Cc: stable <[email protected]> Reported-by: Mark Grosen <[email protected]> Signed-off-by: Ohad Ben-Cohen <[email protected]>
2012-07-04ARM: mmp: remove mach/gpio-pxa.hPaul Bolle1-29/+0
Commit 157d2644cb0c1e71a18baaffca56d2b1d0ebf10f ("ARM: pxa: change gpio to platform device") removed all includes of mach/gpio-pxa.h. It kept this unused header in the tree. Using it can't work, as it itself includes the non-existent header plat/gpio-pxa.h. This header can safely be removed. Signed-off-by: Paul Bolle <[email protected]> Acked-by: Eric Miao <[email protected]> Signed-off-by: Haojian Zhuang <[email protected]>
2012-07-04leds: heartbeat: fix bug on panicAlexander Holler1-1/+15
With commit 49dca5aebfdeadd4bf27b6cb4c60392147dc35a4 I introduced a bug (visible if CONFIG_PROVE_RCU is enabled) which occures when a panic has happened: [ 1526.520230] =============================== [ 1526.520230] [ INFO: suspicious RCU usage. ] [ 1526.520230] 3.5.0-rc1+ #12 Not tainted [ 1526.520230] ------------------------------- [ 1526.520230] /c/kernel-tests/mm/include/linux/rcupdate.h:436 Illegal context switch in RCU read-side critical section! [ 1526.520230] [ 1526.520230] other info that might help us debug this: [ 1526.520230] [ 1526.520230] [ 1526.520230] rcu_scheduler_active = 1, debug_locks = 0 [ 1526.520230] 3 locks held by net.agent/3279: [ 1526.520230] #0: (&mm->mmap_sem){++++++}, at: [<ffffffff82f85962>] do_page_fault+0x193/0x390 [ 1526.520230] #1: (panic_lock){+.+...}, at: [<ffffffff82ed2830>] panic+0x37/0x1d3 [ 1526.520230] #2: (rcu_read_lock){.+.+..}, at: [<ffffffff810b9b28>] rcu_lock_acquire+0x0/0x29 [ 1526.520230] [ 1526.520230] stack backtrace: [ 1526.520230] Pid: 3279, comm: net.agent Not tainted 3.5.0-rc1+ #12 [ 1526.520230] Call Trace: [ 1526.520230] [<ffffffff810e1570>] lockdep_rcu_suspicious+0x109/0x112 [ 1526.520230] [<ffffffff810bfe3a>] rcu_preempt_sleep_check+0x45/0x47 [ 1526.520230] [<ffffffff810bfe5a>] __might_sleep+0x1e/0x19a [ 1526.520230] [<ffffffff82f8010e>] down_write+0x26/0x81 [ 1526.520230] [<ffffffff8276a966>] led_trigger_unregister+0x1f/0x9c [ 1526.520230] [<ffffffff8276def5>] heartbeat_reboot_notifier+0x15/0x19 [ 1526.520230] [<ffffffff82f85bf5>] notifier_call_chain+0x96/0xcd [ 1526.520230] [<ffffffff82f85cba>] __atomic_notifier_call_chain+0x8e/0xff [ 1526.520230] [<ffffffff81094b7c>] ? kmsg_dump+0x37/0x1eb [ 1526.520230] [<ffffffff82f85d3f>] atomic_notifier_call_chain+0x14/0x16 [ 1526.520230] [<ffffffff82ed28e1>] panic+0xe8/0x1d3 [ 1526.520230] [<ffffffff811473e2>] out_of_memory+0x15d/0x1d3 So in case of a panic, now just turn of the LED. Other approaches like scheduling a work to unregister the trigger aren't working because there isn't much which still runs after a panic occured (except timers). Signed-off-by: Alexander Holler <[email protected]> Signed-off-by: Bryan Wu <[email protected]>
2012-07-04remoteproc/omap: fix randconfig unmet direct dependenciesOhad Ben-Cohen1-0/+1
OMAP_REMOTEPROC selects REMOTEPROC and RPMSG, both of which depend on EXPERIMENTAL, so let's have OMAP_REMOTEPROC depend on EXPERIMENTAL too, in order to avoid the below randconfig warnings. warning: (OMAP_REMOTEPROC) selects REMOTEPROC which has unmet direct dependencies (EXPERIMENTAL) warning: (OMAP_REMOTEPROC) selects RPMSG which has unmet direct dependencies (EXPERIMENTAL) Cc: stable <[email protected]> Reported-by: Tony Lindgren <[email protected]> Signed-off-by: Ohad Ben-Cohen <[email protected]>
2012-07-04ARM: imx: assert SCC gate stays enabledUwe Kleine-König1-1/+8
The SCC clock is needed in internal boot mode and so must keep enabled. This same issue was fixed for the pre-common-clk code in commit 3d6e614 (mx35: Fix boot ROM hang in internal boot mode) Cc: John Ogness <[email protected]> Cc: Hans J. Koch <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sascha Hauer <[email protected]>
2012-07-03ocfs2: Fix bogus error message from ocfs2_global_read_infoJan Kara1-2/+0
'status' variable in ocfs2_global_read_info() is always != 0 when leaving the function because it happens to contain number of read bytes. Thus we always log error message although everything is OK. Since all error cases properly call mlog_errno() before jumping to out_err, there's no reason to call mlog_errno() on exit at all. This is a fallout of c1e8d35e (conversion of mlog_exit() calls). Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Joel Becker <[email protected]>
2012-07-03ocfs2: for SEEK_DATA/SEEK_HOLE, return internal error unchanged if ↵Jeff Liu1-2/+0
ocfs2_get_clusters_nocache() or ocfs2_inode_lock() call failed. Hello, Since ENXIO only means "offset beyond EOF" for SEEK_DATA/SEEK_HOLE, Hence we should return the internal error unchanged if ocfs2_inode_lock() or ocfs2_get_clusters_nocache() call failed rather than ENXIO. Otherwise, it will confuse the user applications when they trying to understand the root cause. Thanks Dave for pointing this out. Thanks, -Jeff Cc: Dave Chinner <[email protected]> Signed-off-by: Jie Liu <[email protected]> Signed-off-by: Joel Becker <[email protected]>
2012-07-03ocfs2: use spinlock irqsave for downconvert lock.patchSrinivas Eeda1-12/+19
When ocfs2dc thread holds dc_task_lock spinlock and receives soft IRQ it deadlock itself trying to get same spinlock in ocfs2_wake_downconvert_thread. Below is the stack snippet. The patch disables interrupts when acquiring dc_task_lock spinlock. ocfs2_wake_downconvert_thread ocfs2_rw_unlock ocfs2_dio_end_io dio_complete ..... bio_endio req_bio_endio .... scsi_io_completion blk_done_softirq __do_softirq do_softirq irq_exit do_IRQ ocfs2_downconvert_thread [kthread] Signed-off-by: Srinivas Eeda <[email protected]> Signed-off-by: Joel Becker <[email protected]>
2012-07-03ocfs2: Misplaced parens in unlikleyroel1-1/+1
Fix misplaced parentheses Signed-off-by: Roel Kluin <[email protected]> Signed-off-by: Joel Becker <[email protected]>
2012-07-03ocfs2: clear unaligned io flag when dio failsJunxiao Bi1-1/+3
The unaligned io flag is set in the kiocb when an unaligned dio is issued, it should be cleared even when the dio fails, or it may affect the following io which are using the same kiocb. Signed-off-by: Junxiao Bi <[email protected]> Cc: [email protected] Signed-off-by: Joel Becker <[email protected]>
2012-07-03Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linuxLinus Torvalds1-15/+13
Pull fix to common clk framework from Michael Turquette: "The previous set of common clk fixes for -rc5 left an uninitialized int which could lead to bad array indexing when switching clock parents. The issue is fixed with a trivial change to the code flow in __clk_set_parent." * tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mturquette/linux: clk: fix parent validation in __clk_set_parent()
2012-07-03Merge tag 'md-3.5-fixes' of git://neil.brown.name/mdLinus Torvalds1-1/+1
Pull raid10 build failure fix from NeilBrown: "I really shouldn't do important things late in the day. It seems that I get careless." * tag 'md-3.5-fixes' of git://neil.brown.name/md: md/raid10: fix careless build error
2012-07-03Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds40-160/+196
Pull networking update from David Miller: 1) Fix RX sequence number handling in mwifiex, from Stone Piao. 2) Netfilter ipset mis-compares device names, fix from Florian Westphal. 3) Fix route leak in ipv6 IPVS, from Eric Dumazet. 4) NFS fixes. Several buffer overflows in NCI layer from Dan Rosenberg, and release sock OOPS'er fix from Eric Dumazet. 5) Fix WEP handling ath9k, we started using a bit the chip provides to indicate undecrypted packets but that bit turns out to be unreliable in certain configurations. Fix from Felix Fietkau. 6) Fix Kconfig dependency bug in wlcore, from Randy Dunlap. 7) New USB IDs for rtlwifi driver from Larry Finger. 8) Fix crashes in qmi_wwan usbnet driver when disconnecting, from Bjørn Mork. 9) Gianfar driver programs coalescing settings properly in single queue mode, but does not do so in multi-queue mode. Fix from Claudiu Manoil. 10) Missing module.h include in davinci_cpdma.c, from Daniel Mack. 11) Need dummy handler for IPSET_CMD_NONE otherwise we crash in ipset if we get this via nfnetlink, fix from Tomasz Bursztyka. 12) Missing RCU unlock in nfnetlink error path, also from Tomasz. 13) Fix divide by zero in igbvf when the user tries to set an RX coalescing value of 0 usecs, from Mitch A Williams. 14) We can process SCTP sacks for the wrong transport, oops. Fix from Neil Horman. 15) Remove hw IP payload checksumming from e1000e driver. This has zery value in our stack, and turning it on creates a very unintuitive restriction for users when using jumbo MTUs. Specifically, when IP payload checksums are on you cannot use both receive hashing offload and jumbo MTU. Fix from Bruce Allan. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits) e1000e: remove use of IP payload checksum sctp: be more restrictive in transport selection on bundled sacks igbvf: fix divide by zero netfilter: nfnetlink: fix missing rcu_read_unlock in nfnetlink_rcv_msg netfilter: ipset: fix crash if IPSET_CMD_NONE command is sent davinci_cpdma: include linux/module.h gianfar: Fix RXICr/TXICr programming for multi-queue mode net: Downgrade CAP_SYS_MODULE deprecated message from error to warning. net: qmi_wwan: fix Oops while disconnecting mwifiex: fix memory leak associated with IE manamgement ath9k: fix panic caused by returning a descriptor we have queued for reuse mac80211: correct behaviour on unrecognised action frames ath9k: enable serialize_regmode for non-PCIE AR9287 rtlwifi: rtl8192cu: New USB IDs NFC: Return from rawsock_release when sk is NULL iwlwifi: fix activating inactive stations wlcore: drop INET dependency ath9k: fix dynamic WEP related regression NFC: Prevent multiple buffer overflows in NCI netfilter: update location of my trees ...
2012-07-04md/raid10: fix careless build errorNeilBrown1-1/+1
build error introduced by commit b357f04a67c2aeee8 That function doesn't get extra args until a later patch. Bother. Reported-by: Fengguang Wu <[email protected]> Reported-by: Simon Kirby <[email protected]> Reported-by: Tobias Klausmann <[email protected]> Signed-off-by: NeilBrown <[email protected]>
2012-07-03eCryptfs: Fix lockdep warning in miscdev operationsTyler Hicks1-12/+13
Don't grab the daemon mutex while holding the message context mutex. Addresses this lockdep warning: ecryptfsd/2141 is trying to acquire lock: (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}, at: [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs] but task is already holding lock: (&(*daemon)->mux){+.+...}, at: [<ffffffffa029c2ec>] ecryptfs_miscdev_read+0x21c/0x470 [ecryptfs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&(*daemon)->mux){+.+...}: [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220 [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0 [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50 [<ffffffffa029c5d7>] ecryptfs_send_miscdev+0x97/0x120 [ecryptfs] [<ffffffffa029b744>] ecryptfs_send_message+0x134/0x1e0 [ecryptfs] [<ffffffffa029a24e>] ecryptfs_generate_key_packet_set+0x2fe/0xa80 [ecryptfs] [<ffffffffa02960f8>] ecryptfs_write_metadata+0x108/0x250 [ecryptfs] [<ffffffffa0290f80>] ecryptfs_create+0x130/0x250 [ecryptfs] [<ffffffff811963a4>] vfs_create+0xb4/0x120 [<ffffffff81197865>] do_last+0x8c5/0xa10 [<ffffffff811998f9>] path_openat+0xd9/0x460 [<ffffffff81199da2>] do_filp_open+0x42/0xa0 [<ffffffff81187998>] do_sys_open+0xf8/0x1d0 [<ffffffff81187a91>] sys_open+0x21/0x30 [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b -> #0 (&ecryptfs_msg_ctx_arr[i].mux){+.+.+.}: [<ffffffff810a3418>] __lock_acquire+0x1bf8/0x1c50 [<ffffffff810a3b8d>] lock_acquire+0x9d/0x220 [<ffffffff8151c6da>] __mutex_lock_common+0x5a/0x4b0 [<ffffffff8151cc64>] mutex_lock_nested+0x44/0x50 [<ffffffffa029c213>] ecryptfs_miscdev_read+0x143/0x470 [ecryptfs] [<ffffffff811887d3>] vfs_read+0xb3/0x180 [<ffffffff811888ed>] sys_read+0x4d/0x90 [<ffffffff81527d69>] system_call_fastpath+0x16/0x1b Signed-off-by: Tyler Hicks <[email protected]>
2012-07-03eCryptfs: Properly check for O_RDONLY flag before doing privileged openTyler Hicks1-1/+1
If the first attempt at opening the lower file read/write fails, eCryptfs will retry using a privileged kthread. However, the privileged retry should not happen if the lower file's inode is read-only because a read/write open will still be unsuccessful. The check for determining if the open should be retried was intended to be based on the access mode of the lower file's open flags being O_RDONLY, but the check was incorrectly performed. This would cause the open to be retried by the privileged kthread, resulting in a second failed open of the lower file. This patch corrects the check to determine if the open request should be handled by the privileged kthread. Signed-off-by: Tyler Hicks <[email protected]> Reported-by: Dan Carpenter <[email protected]> Acked-by: Dan Carpenter <[email protected]>
2012-07-03floppy: cancel any pending fd_timeouts before adding a new oneLinus Torvalds1-0/+1
In commit 070ad7e793dc ("floppy: convert to delayed work and single-thread wq") the 'fd_timeout' timer was converted to a delayed work. However, the "del_timer(&fd_timeout)" was lost in the process, and any previous pending timeouts would stay active when we then re-queued the timeout. This resulted in the floppy probe sequence having a (stale) 20s timeout rather than the intended 3s timeout, and thus made booting with the floppy driver (but no actual floppy controller) take much longer than it should. Of course, there's little reason for most people to compile the floppy driver into the kernel at all, which is why most people never noticed. Canceling the delayed work where we used to do the del_timer() fixes the issue, and makes the floppy probing use the proper new timeout instead. The three second timeout is still very wasteful, but better than the 20s one. Reported-and-tested-by: Andi Kleen <[email protected]> Reported-and-tested-by: Calvin Walton <[email protected]> Cc: Jiri Kosina <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2012-07-03Merge branch 'for-linus' of git://git.kernel.dk/linux-blockLinus Torvalds20-200/+338
Pull block bits from Jens Axboe: "As vacation is coming up, thought I'd better get rid of my pending changes in my for-linus branch for this iteration. It contains: - Two patches for mtip32xx. Killing a non-compliant sysfs interface and moving it to debugfs, where it belongs. - A few patches from Asias. Two legit bug fixes, and one killing an interface that is no longer in use. - A patch from Jan, making the annoying partition ioctl warning a bit less annoying, by restricting it to !CAP_SYS_RAWIO only. - Three bug fixes for drbd from Lars Ellenberg. - A fix for an old regression for umem, it hasn't really worked since the plugging scheme was changed in 3.0. - A few fixes from Tejun. - A splice fix from Eric Dumazet, fixing an issue with pipe resizing." * 'for-linus' of git://git.kernel.dk/linux-block: scsi: Silence unnecessary warnings about ioctl to partition block: Drop dead function blk_abort_queue() block: Mitigate lock unbalance caused by lock switching block: Avoid missed wakeup in request waitqueue umem: fix up unplugging splice: fix racy pipe->buffers uses drbd: fix null pointer dereference with on-congestion policy when diskless drbd: fix list corruption by failing but already aborted reads drbd: fix access of unallocated pages and kernel panic xen/blkfront: Add WARN to deal with misbehaving backends. blkcg: drop local variable @q from blkg_destroy() mtip32xx: Create debugfs entries for troubleshooting mtip32xx: Remove 'registers' and 'flags' from sysfs blkcg: fix blkg_alloc() failure path block: blkcg_policy_cfq shouldn't be used if !CONFIG_CFQ_GROUP_IOSCHED block: fix return value on cfq_init() failure mtip32xx: Remove version.h header file inclusion xen/blkback: Copy id field when doing BLKIF_DISCARD.
2012-07-03KVM: MMU: fix shrinking page from the empty mmuXiao Guangrong1-0/+3
Fix: [ 3190.059226] BUG: unable to handle kernel NULL pointer dereference at (null) [ 3190.062224] IP: [<ffffffffa02aac66>] mmu_page_zap_pte+0x10/0xa7 [kvm] [ 3190.063760] PGD 104f50067 PUD 112bea067 PMD 0 [ 3190.065309] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 3190.066860] CPU 1 [ ...... ] [ 3190.109629] Call Trace: [ 3190.111342] [<ffffffffa02aada6>] kvm_mmu_prepare_zap_page+0xa9/0x1fc [kvm] [ 3190.113091] [<ffffffffa02ab2f5>] mmu_shrink+0x11f/0x1f3 [kvm] [ 3190.114844] [<ffffffffa02ab25d>] ? mmu_shrink+0x87/0x1f3 [kvm] [ 3190.116598] [<ffffffff81150c9d>] ? prune_super+0x142/0x154 [ 3190.118333] [<ffffffff8110a4f4>] ? shrink_slab+0x39/0x31e [ 3190.120043] [<ffffffff8110a687>] shrink_slab+0x1cc/0x31e [ 3190.121718] [<ffffffff8110ca1d>] do_try_to_free_pages This is caused by shrinking page from the empty mmu, although we have checked n_used_mmu_pages, it is useless since the check is out of mmu-lock Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Marcelo Tosatti <[email protected]>
2012-07-03KVM: fix fault page leakXiao Guangrong1-0/+1
fault_page is forgot to be freed Signed-off-by: Xiao Guangrong <[email protected]> Signed-off-by: Marcelo Tosatti <[email protected]>
2012-07-03regulator: arizona-ldo1: Implement GPIO enable supportMark Brown1-0/+4
Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: wm8994: Use core GPIO enable supportMark Brown1-64/+4
Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: fixed: Use core GPIO enable supportMark Brown1-88/+18
This is essentially the code that was factored out into the core when the feature was implemented. Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: core: Add core support for GPIO controlled enable linesMark Brown2-1/+45
It is very common for regulators to support having their enable signal controlled by a GPIO. Since there are a bunch of fiddly things to get right like handling the operations when the enable signal is tied to a rail and it's just replicated code add support for this to the core. Drivers should set ena_gpio in their config if they have a GPIO control, using ena_gpio_flags to specify any flags (including GPIOF_OUT_INIT_ for the initial state) and ena_gpio_invert if the GPIO is active low. The core will then override any enable and disable operations the driver has and instead control the specified GPIO. This will in the future also allow us to further extend the core by identifying when several enable signals have been tied together and handling this properly. Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: core: Factor out enable and disable operations some moreMark Brown1-42/+68
Create new _regulator_do_enable() and _regulator_do_disable() operations which deal with the mechanics of performing the enable and disable, partly to cut down on the levels of indentation and partly to support some future work. Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: wm831x-ldo: Specify enable time for alive LDOMark Brown1-0/+1
Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: wm8994: Set enable_time in descriptorMark Brown1-9/+2
Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: fixed: Set enable enable_time in regulator_descMark Brown1-10/+2
Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: core: Allow fixed enable_time to be set in the regulator_descMark Brown2-1/+5
Many regulators have a fixed specification for their enable time. Allow this to be set in the regulator_desc as a number to save them having to implement an explicit operation. Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: Fix recursive mutex lockdep warningStephen Boyd1-5/+5
A recursive lockdep warning occurs if you call regulator_set_optimum_mode() on a regulator with a supply because there is no nesting annotation for the rdev->mutex. To avoid this warning, get the supply's load before locking the regulator's mutex to avoid grabbing the same class of lock twice. ============================================= [ INFO: possible recursive locking detected ] 3.4.0 #3257 Tainted: G W --------------------------------------------- swapper/0/1 is trying to acquire lock: (&rdev->mutex){+.+.+.}, at: [<c036e9e0>] regulator_get_voltage+0x18/0x38 but task is already holding lock: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rdev->mutex); lock(&rdev->mutex); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by swapper/0/1: #0: (&__lockdep_no_validate__){......}, at: [<c03dbb48>] __driver_attach+0x40/0x8c #1: (&__lockdep_no_validate__){......}, at: [<c03dbb58>] __driver_attach+0x50/0x8c #2: (&rdev->mutex){+.+.+.}, at: [<c036ef38>] regulator_set_optimum_mode+0x24/0x224 stack backtrace: [<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00cc4d4>] (validate_chain+0x760/0x1080) [<c00cc4d4>] (validate_chain+0x760/0x1080) from [<c00cd744>] (__lock_acquire+0x950/0xa10) [<c00cd744>] (__lock_acquire+0x950/0xa10) from [<c00cd990>] (lock_acquire+0x18c/0x1e8) [<c00cd990>] (lock_acquire+0x18c/0x1e8) from [<c080c248>] (mutex_lock_nested+0x68/0x3c4) [<c080c248>] (mutex_lock_nested+0x68/0x3c4) from [<c036e9e0>] (regulator_get_voltage+0x18/0x38) [<c036e9e0>] (regulator_get_voltage+0x18/0x38) from [<c036efb8>] (regulator_set_optimum_mode+0xa4/0x224) ... Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: dt: regulator match by regulator-compatibleLaxman Dewangan1-18/+33
Match the device's regulators with the property of "regulator-compatible" of each regulator node. Signed-off-by: Laxman Dewangan <[email protected]> Acked-by: Stephen Warren <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-03ARM: dts: db8500: add property "regulator-compatible" regulator nodeLaxman Dewangan1-0/+30
Device's regulator matches their hardware counterparts with the property "regulator-compatible" of each child regulator node in place of the child node name. Add the property "regulator-compatible" for each regulator with their hardware counterpart's name. Signed-off-by: Laxman Dewangan <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-03regulator: tps65217: Fix voltage boundary checking in tps65217_pmic_map_voltageAxel Lin1-3/+3
It is ok to request voltage with min_uV < tps->info[rid]->min_uV and max_uV > tps->info[rid]->max_uV. The equation we used in uv_to_vsel() does not allow min_uV < tps->info[rid]->min_uV, otherwise it returns negative selector. So we need to set min_uV = tps->info[rid]->min_uV if min_uV < tps->info[rid]->min_uV. Signed-off-by: Axel Lin <[email protected]> Acked-by: AnilKumar Ch <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2012-07-03clk: fix parent validation in __clk_set_parent()Rajendra Nayak1-15/+13
The below commit introduced a bug in __clk_set_parent() which could cause it to *skip* the parent validation which makes sure the parent passed to the api is a valid one. commit 7975059db572eb47f0fb272a62afeae272a4b209 Author: Rajendra Nayak <[email protected]> Date: Wed Jun 6 14:41:31 2012 +0530 clk: Allow late cache allocation for clk->parents This was identified by the following compiler warning.. drivers/clk/clk.c: In function '__clk_set_parent': drivers/clk/clk.c:1083:5: warning: 'i' may be used uninitialized in this function [-Wuninitialized] .. as reported by Marc Kleine-Budde. There were various options discussed on how to fix this, one being initing 'i' to clk->num_parents, but the below approach was found to be more appropriate as it also makes the 'parent validation' code simpler to read. Reported-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Rajendra Nayak <[email protected]> Signed-off-by: Mike Turquette <[email protected]> Cc: [email protected]
2012-07-03Merge tag 'sound-3.5' of ↵Linus Torvalds4-3/+31
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Just a few driver-specific fixes for ASoC and HD-audio." * tag 'sound-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Fix no sound from ALC662 after Windows reboot ASoC: tlv320aic3x: Fix codec pll configure bug ASoC: wm2200: Add missing BCLK rate
Powered by cgit, Gruvboxed by Blaster4385.