- 09 Jan, 2014 40 commits
-
-
Theodore Ts'o authored
commit f5a44db5 upstream. The missing casts can cause the high 64-bits of the physical blocks to be lost. Set up new macros which allows us to make sure the right thing happen, even if at some point we end up supporting larger logical block numbers. Thanks to the Emese Revfy and the PaX security team for reporting this issue. Reported-by:
PaX Team <pageexec@freemail.hu> Reported-by:
Emese Revfy <re.emese@gmail.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jan Kara authored
commit 34cf865d upstream. Akira-san has been reporting rare deadlocks of his machine when running xfstests test 269 on ext4 filesystem. The problem turned out to be in ext4_da_reserve_metadata() and ext4_da_reserve_space() which called ext4_should_retry_alloc() while holding i_data_sem. Since ext4_should_retry_alloc() can force a transaction commit, this is a lock ordering violation and leads to deadlocks. Fix the problem by just removing the retry loops. These functions should just report ENOSPC to the caller (e.g. ext4_da_write_begin()) and that function must take care of retrying after dropping all necessary locks. Reported-and-tested-by:
Akira Fujita <a-fujita@rs.jp.nec.com> Reviewed-by:
Zheng Liu <wenqing.lz@taobao.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jan Kara authored
commit 30fac0f7 upstream. When the filesystem doesn't support extents (like in ext2/3 compatibility modes), there is no need to reserve any clusters. Space estimates for writing are exact, hole punching doesn't need new metadata, and there are no unwritten extents to convert. This fixes a problem when filesystem still having some free space when accessed with a native ext2/3 driver suddently reports ENOSPC when accessed with ext4 driver. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Tested-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
Al Viro authored
commit 9105bb14 upstream. That thing should be del_timer_sync(); consider what happens if ext4_put_super() call of del_timer() happens to come just as it's getting run on another CPU. Since that timer reschedules itself to run next day, you are pretty much guaranteed that you'll end up with kfree'd scheduled timer, with usual fun consequences. AFAICS, that's -stable fodder all way back to 2010... [the second del_timer_sync() is almost certainly not needed, but it doesn't hurt either] Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Eryu Guan authored
commit 5946d089 upstream. A corrupted ext4 may have out of order leaf extents, i.e. extent: lblk 0--1023, len 1024, pblk 9217, flags: LEAF UNINIT extent: lblk 1000--2047, len 1024, pblk 10241, flags: LEAF UNINIT ^^^^ overlap with previous extent Reading such extent could hit BUG_ON() in ext4_es_cache_extent(). BUG_ON(end < lblk); The problem is that __read_extent_tree_block() tries to cache holes as well but assumes 'lblk' is greater than 'prev' and passes underflowed length to ext4_es_cache_extent(). Fix it by checking for overlapping extents in ext4_valid_extent_entries(). I hit this when fuzz testing ext4, and am able to reproduce it by modifying the on-disk extent by hand. Also add the check for (ee_block + len - 1) in ext4_valid_extent() to make sure the value is not overflow. Ran xfstests on patched ext4 and no regression. Cc: Lukáš Czerner <lczerner@redhat.com> Signed-off-by:
Eryu Guan <guaneryu@gmail.com> Signed-off-by:
-
Junho Ryu authored
commit 4e8d2139 upstream. ext4_mb_put_pa should hold pa->pa_lock before accessing pa->pa_count. While ext4_mb_use_preallocated checks pa->pa_deleted first and then increments pa->count later, ext4_mb_put_pa decrements pa->pa_count before holding pa->pa_lock and then sets pa->pa_deleted. * Free sequence ext4_mb_put_pa (1): atomic_dec_and_test pa->pa_count ext4_mb_put_pa (2): lock pa->pa_lock ext4_mb_put_pa (3): check pa->pa_deleted ext4_mb_put_pa (4): set pa->pa_deleted=1 ext4_mb_put_pa (5): unlock pa->pa_lock ext4_mb_put_pa (6): remove pa from a list ext4_mb_pa_callback: free pa * Use sequence ext4_mb_use_preallocated (1): iterate over preallocation ext4_mb_use_preallocated (2): lock pa->pa_lock ext4_mb_use_preallocated (3): check pa->pa_deleted ext4_mb_use_preallocated (4): increase pa->pa_count ext4_mb_use_preallocated (5): unlock pa->pa_lock ext4_mb_release_context: access pa * Use-after-free sequence [initial status] <pa->pa_deleted = 0, pa_count = 1> ext4_mb_use_preallocated (1): iterate over preallocation ext4_mb_use_preallocated (2): lock pa->pa_lock ext4_mb_use_preallocated (3): check pa->pa_deleted ext4_mb_put_pa (1): atomic_dec_and_test pa->pa_count [pa_count decremented] <pa->pa_deleted = 0, pa_count = 0> ext4_mb_use_preallocated (4): increase pa->pa_count [pa_count incremented] <pa->pa_deleted = 0, pa_count = 1> ext4_mb_use_preallocated (5): unlock pa->pa_lock ext4_mb_put_pa (2): lock pa->pa_lock ext4_mb_put_pa (3): check pa->pa_deleted ext4_mb_put_pa (4): set pa->pa_deleted=1 [race condition!] <pa->pa_deleted = 1, pa_count = 1> ext4_mb_put_pa (5): unlock pa->pa_lock ext4_mb_put_pa (6): remove pa from a list ext4_mb_pa_callback: free pa ext4_mb_release_context: access pa AddressSanitizer has detected use-after-free in ext4_mb_new_blocks Bug report: http://goo.gl/rG1On3Signed-off-by:
Junho Ryu <jayr@google.com> Signed-off-by:
-
Theodore Ts'o authored
commit ae1495b1 upstream. While it's true that errors can only happen if there is a bug in jbd2_journal_dirty_metadata(), if a bug does happen, we need to halt the kernel or remount the file system read-only in order to avoid further data loss. The ext4_journal_abort_handle() function doesn't do any of this, and while it's likely that this call (since it doesn't adjust refcounts) will likely result in the file system eventually deadlocking since the current transaction will never be able to close, it's much cleaner to call let ext4's error handling system deal with this situation. There's a separate bug here which is that if certain jbd2 errors errors occur and file system is mounted errors=continue, the file system will probably eventually end grind to a halt as described above. But things have been this way in a long time, and usually when we have these sorts of errors it's pretty much a disaster --- and that's why the jbd2 layer aggressively retries memory allocations, which is the most likely cause of these jbd2 errors. Signed-off-by:
-
Paul Drews authored
commit f6308b36 upstream. This adds the new ACPI ID (INT33FC) for the BayTrail GPIO banks as seen on a BayTrail M System-On-Chip platform. This ACPI ID is used by the BayTrail GPIO (pinctrl) driver to manage the Low Power Subsystem (LPSS). Signed-off-by:
Paul Drews <paul.drews@intel.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Len Brown authored
commit 40e2d7f9 upstream. Linux 3.10 changed the timing of how thread_info->flags is touched: x86: Use generic idle loop (7d1a9417) This caused Intel NHM-EX and WSM-EX servers to experience a large number of immediate MONITOR/MWAIT break wakeups, which caused cpuidle to demote from deep C-states to shallow C-states, which caused these platforms to experience a significant increase in idle power. Note that this issue was already present before the commit above, however, it wasn't seen often enough to be noticed in power measurements. Here we extend an errata workaround from the Core2 EX "Dunnington" to extend to NHM-EX and WSM-EX, to prevent these immediate returns from MWAIT, reducing idle power on these platforms. While only acpi_idle ran on Dunnington, intel_idle may also run on these two newer systems. As of today, there are no other models that are known to need this tweak. Link: http://lkml.kernel.org/r/CAJvTdK=%2BaNN66mYpCGgbHGCHhYQAKx-vB0kJSWjVpsNb_hOAtQ@mail.gmail.comSigned-off-by:
Len Brown <len.brown@intel.com> Link: http://lkml.kernel.org/r/baff264285f6e585df757d58b17788feabc68918.1387403066.git.len.brown@intel.comSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Tony Lindgren authored
commit 7e367c18 upstream. Looks like the LCD panel on LDP has been broken quite a while, and recently got fixed by commit 0b2aa8be (gpio: twl4030: Fix regression for twl gpio output). However, there's still an issue left where the panel backlight does not come on if the LCD drivers are built into the kernel. Fix the issue by registering the DPI LCD panel only after the twl4030 GPIO has probed. Reported-by:
Russell King <rmk+kernel@arm.linux.org.uk> Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> [tony@atomide.com: updated per Tomi's comments] Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Suman Anna authored
commit 6d4c8830 upstream. Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) and commit ec2c0825 (ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ) updated the way interrupts for OMAP2/3 devices are defined in the HWMOD data structures to being an index plus a fixed offset (defined by OMAP_INTC_START). Couple of irqs in the OMAP2/3 hwmod data were misconfigured completely as they were missing this OMAP_INTC_START relative offset. Add this offset back to fix the incorrect irq data for the following modules: OMAP2 - GPMC, RNG OMAP3 - GPMC, ISP MMU & IVA MMU Signed-off-by:
Suman Anna <s-anna@ti.com> Fixes: 7d7e1eba ("ARM: OMAP2+: Prepare for irqs.h removal") Fixes: ec2c0825 ("ARM: OMAP2+: Remove hardcoded IRQs and enable SPARSE_IRQ") Cc: Tony Lindgren <tony@atomide.com> Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Rajendra Nayak authored
commit 38958c15 upstream. With commit '7dedd346: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL' we moved from parsing cmdline to identify uart used for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS. On DRA7 though, we seem to be missing this flag, and atleast on the DRA7 EVM where we use uart1 for console, boot fails with DEBUG_LL enabled. Reported-by:
Lokesh Vutla <lokeshvutla@ti.com> Tested-by: Lokesh Vutla <lokeshvutla@ti.com> # on a different base Signed-off-by:
Rajendra Nayak <rnayak@ti.com> Fixes: 7dedd346 ("ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL") Signed-off-by:
-
Ben Dooks authored
commit d721a15c upstream. The r8a7790.dtsi file has four sdhi nodes which the first two have the wrong resource size for their register block. This causes the sh_modbile_sdhi driver to fail to communicate with card at-all. Change sdhi{0,1} node size from 0x100 to 0x200 to correct these nodes as per Kuninori Morimoto's response to the original patch where all four nodes where changed. sdhi{2,3} are the correct size. This bug has been present since sdhi resources were added to the r8a7790 by 8c9b1aa4 ("ARM: shmobile: r8a7790: add MMCIF and SDHI DT templates") in v3.11-rc2. Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Tested-by:
William Towle <william.towle@codethink.co.uk> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Will Deacon authored
commit cdc27c27 upstream. Commit 8f34a1da ("arm64: ptrace: use HW_BREAKPOINT_EMPTY type for disabled breakpoints") fixed an issue with GDB trying to zero breakpoint control registers. The problem there is that the arch hw_breakpoint code will attempt to create a (disabled), execute breakpoint of length 0. This will fail validation and report unexpected failure to GDB. To avoid this, we treated disabled breakpoints as HW_BREAKPOINT_EMPTY, but that seems to have broken with recent kernels, causing watchpoints to be treated as TYPE_INST in the core code and returning ENOSPC for any further breakpoints. This patch fixes the problem by prioritising the `enable' field of the breakpoint: if it is cleared, we simply update the perf_event_attr to indicate that the thing is disabled and don't bother changing either the type or the length. This reinforces the behaviour that the breakpoint control register is essentially read-only apart from the enable bit when disabling a breakpoint. Reported-by:
Aaron Liu <liucy214@gmail.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Ming Lei authored
commit 7122c3e9 upstream. Actually CONFIG_PAGE_OFFSET isn't same with PAGE_OFFSET, so it isn't easy to figue out PAGE_OFFSET defined in header file from scripts. Because CONFIG_PAGE_OFFSET may not be defined in some ARCHs( 64bit ARCH), or defined as bogus value in !MMU case, so this patch only applys the filter on ARM when CONFIG_PAGE_OFFSET is defined as the original problem is only on ARM. Cc: Rusty Russell <rusty@rustcorp.com.au> Fixes: f6537f2fSinged-off-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Miao Xie authored
commit c4602c1c upstream. Ftrace currently initializes only the online CPUs. This implementation has two problems: - If we online a CPU after we enable the function profile, and then run the test, we will lose the trace information on that CPU. Steps to reproduce: # echo 0 > /sys/devices/system/cpu/cpu1/online # cd <debugfs>/tracing/ # echo <some function name> >> set_ftrace_filter # echo 1 > function_profile_enabled # echo 1 > /sys/devices/system/cpu/cpu1/online # run test - If we offline a CPU before we enable the function profile, we will not clear the trace information when we enable the function profile. It will trouble the users. Steps to reproduce: # cd <debugfs>/tracing/ # echo <some function name> >> set_ftrace_filter # echo 1 > function_profile_enabled # run test # cat trace_stat/function* # echo 0 > /sys/devices/system/cpu/cpu1/online # echo 0 > function_profile_enabled # echo 1 > function_profile_enabled # cat trace_stat/function* # run test # cat trace_stat/function* So it is better that we initialize the ftrace profiler for each possible cpu every time we enable the function profile instead of just the online ones. Link: http://lkml.kernel.org/r/1387178401-10619-1-git-send-email-miaox@cn.fujitsu.comSigned-off-by:
Miao Xie <miaox@cn.fujitsu.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Jie Liu authored
commit 718cc6f8 upstream. xfs_quota(8) will hang up if trying to turn group/project quota off before the user quota is off, this could be 100% reproduced by: # mount -ouquota,gquota /dev/sda7 /xfs # mkdir /xfs/test # xfs_quota -xc 'off -g' /xfs <-- hangs up # echo w > /proc/sysrq-trigger # dmesg SysRq : Show Blocked State task PC stack pid father xfs_quota D 0000000000000000 0 27574 2551 0x00000000 [snip] Call Trace: [<ffffffff81aaa21d>] schedule+0xad/0xc0 [<ffffffff81aa327e>] schedule_timeout+0x35e/0x3c0 [<ffffffff8114b506>] ? mark_held_locks+0x176/0x1c0 [<ffffffff810ad6c0>] ? call_timer_fn+0x2c0/0x2c0 [<ffffffffa0c25380>] ? xfs_qm_shrink_count+0x30/0x30 [xfs] [<ffffffff81aa3306>] schedule_timeout_uninterruptible+0x26/0x30 [<ffffffffa0c26155>] xfs_qm_dquot_walk+0x235/0x260 [xfs] [<ffffffffa0c059d8>] ? xfs_perag_get+0x1d8/0x2d0 [xfs] [<ffffffffa0c05805>] ? xfs_perag_get+0x5/0x2d0 [xfs] [<ffffffffa0b7707e>] ? xfs_inode_ag_iterator+0xae/0xf0 [xfs] [<ffffffffa0c22280>] ? xfs_trans_free_dqinfo+0x50/0x50 [xfs] [<ffffffffa0b7709f>] ? xfs_inode_ag_iterator+0xcf/0xf0 [xfs] [<ffffffffa0c261e6>] xfs_qm_dqpurge_all+0x66/0xb0 [xfs] [<ffffffffa0c2497a>] xfs_qm_scall_quotaoff+0x20a/0x5f0 [xfs] [<ffffffffa0c2b8f6>] xfs_fs_set_xstate+0x136/0x180 [xfs] [<ffffffff8136cf7a>] do_quotactl+0x53a/0x6b0 [<ffffffff812fba4b>] ? iput+0x5b/0x90 [<ffffffff8136d257>] SyS_quotactl+0x167/0x1d0 [<ffffffff814cf2ee>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81abcd19>] system_call_fastpath+0x16/0x1b It's fine if we turn user quota off at first, then turn off other kind of quotas if they are enabled since the group/project dquot refcount is decreased to zero once the user quota if off. Otherwise, those dquots refcount is non-zero due to the user dquot might refer to them as hint(s). Hence, above operation cause an infinite loop at xfs_qm_dquot_walk() while trying to purge dquot cache. This problem has been around since Linux 3.4, it was introduced by: [ b84a3a96 xfs: remove the per-filesystem list of dquots ] Originally we will release the group dquot pointers because the user dquots maybe carrying around as a hint via xfs_qm_detach_gdquots(). However, with above change, there is no such work to be done before purging group/project dquot cache. In order to solve this problem, this patch introduces a special routine xfs_qm_dqpurge_hints(), and it would release the group/project dquot pointers the user dquots maybe carrying around as a hint, and then it will proceed to purge the user dquot cache if requested. (cherry picked from commit df8052e7) Signed-off-by:
Jie Liu <jeff.liu@oracle.com> Reviewed-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
-
Nicholas Bellinger authored
commit 95cadace upstream. This patch allows FILEIO to update hw_max_sectors based on the current max_bytes_per_io. This is required because vfs_[writev,readv]() can accept a maximum of 2048 iovecs per call, so the enforced hw_max_sectors really needs to be calculated based on block_size. This addresses a >= v3.5 bug where block_size=512 was rejecting > 1M sized I/O requests, because FD_MAX_SECTORS was hardcoded to 2048 for the block_size=4096 case. (v2: Use max_bytes_per_io instead of ->update_hw_max_sectors) Reported-by:
Henrik Goldman <hg@x-formation.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit 2853c2b6 upstream. This patch moves INIT_WORK setup for cq_desc->cq_[rx,tx]_work into isert_create_device_ib_res(), instead of being done each callback invocation in isert_cq_[rx,tx]_callback(). This also fixes a 'INFO: trying to register non-static key' warning when cancel_work_sync() is called before INIT_WORK has setup the struct work_struct. Reported-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
-
Nicholas Bellinger authored
commit db6077fd upstream. When shutting down a target there is a race condition between iscsit_del_np() and __iscsi_target_login_thread(). The latter sets the thread pointer to NULL, and the former tries to issue kthread_stop() on that pointer without any synchronization. This patch moves the np->np_thread NULL assignment into iscsit_del_np(), after kthread_stop() has completed. It also removes the signal_pending() + np_state check, and only exits when kthread_should_stop() is true. Reported-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Nicholas Bellinger authored
commit 4454b66c upstream. This patch changes special case handling for ISCSI_OP_SCSI_CMD where an initiator sends a zero length Expected Data Transfer Length (EDTL), but still sets the WRITE and/or READ flag bits when no payload transfer is requested. Many, many moons ago two special cases where added for an ancient version of ESX that has long since been fixed, so instead of adding a new special case for the reported bug with a Broadcom 57800 NIC, go ahead and always strip off the incorrect WRITE + READ flag bits. Also, avoid sending a reject here, as RFC-3720 does mandate this case be handled without protocol error. Reported-by:
Witold Bazakbal <865perl@wp.pl> Tested-by:
-
Wei Yongjun authored
commit 94a71110 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Shivaram Upadhyayula authored
commit 63832aab upstream. This patch fixes two cases in qla_target.c code where the schedule_delayed_work() value was being incorrectly calculated from sess->expires - jiffies. Signed-off-by:
Shivaram U <shivaram.u@quadstor.com> Signed-off-by:
-
Benjamin LaHaise authored
commit 1881686f upstream. e34ecee2 reworked the percpu reference counting to correct a bug trinity found. Unfortunately, the change lead to kioctxes being leaked because there was no final reference count to put. Add that reference count back in to fix things. Signed-off-by:
Benjamin LaHaise <bcrl@kvack.org> Signed-off-by:
-
Oleg Nesterov authored
commit c0c14395 upstream. selinux_setprocattr() does ptrace_parent(p) under task_lock(p), but task_struct->alloc_lock doesn't pin ->parent or ->ptrace, this looks confusing and triggers the "suspicious RCU usage" warning because ptrace_parent() does rcu_dereference_check(). And in theory this is wrong, spin_lock()->preempt_disable() doesn't necessarily imply rcu_read_lock() we need to access the ->parent. Reported-by:
Evan McNabb <emcnabb@redhat.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Chad Hanson authored
commit 46d01d63 upstream. Fix a broken networking check. Return an error if peer recv fails. If secmark is active and the packet recv succeeds the peer recv error is ignored. Signed-off-by:
Chad Hanson <chanson@trustedcs.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 66fadea5 upstream. Since commit c5340bd1 ("usb: musb: cancel work on removal") the workqueue is cancelled but then if we bail out before the workqueue is setup we get this: |INFO: trying to register non-static key. |the code is fine but needs lockdep annotation. |turning off the locking correctness validator. |CPU: 0 PID: 708 Comm: modprobe Not tainted 3.12.0+ #435 |[<c00867bc>] (lock_acquire+0xf0/0x108) from [<c00529d0>] (flush_work+0x38/0x2ec) |[<c00529d0>] (flush_work+0x38/0x2ec) from [<c0052d24>] (__cancel_work_timer+0xa0/0x134) |[<c0052d24>] (__cancel_work_timer+0xa0/0x134) from [<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) |[<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) from [<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) |[<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24) |[<c0294bf0>] (platform_drv_probe+0x1c/0x24) from [<c0293970>] (driver_probe_device+0x90/0x224) |[<c0293970>] (driver_probe_device+0x90/0x224) from [<c0291ef0>] (bus_for_each_drv+0x60/0x8c) |[<c0291ef0>] (bus_for_each_drv+0x60/0x8c) from [<c02938bc>] (device_attach+0x80/0xa4) |[<c02938bc>] (device_attach+0x80/0xa4) from [<c0292b24>] (bus_probe_device+0x88/0xac) |[<c0292b24>] (bus_probe_device+0x88/0xac) from [<c0291490>] (device_add+0x388/0x6c8) |[<c0291490>] (device_add+0x388/0x6c8) from [<c02952a0>] (platform_device_add+0x188/0x22c) |[<c02952a0>] (platform_device_add+0x188/0x22c) from [<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) |[<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24) |platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral |musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517 This patch moves the init part to earlier part so it can be cleaned as part of the fail3 label because now it is surrounded by the fail4 label. Step two is to remove it from musb_free() and add it to the two cleanup paths (error path and device removal) separately. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 8d1aad74 upstream. In commit f3ce4d5b ("usb: musb: core: call dma_controller_destroy() in the err path") I erroneously assumed that the dma controller is not removed in the error patch. This was wrong because it happens later via musb_free(). That means the original commit can be reverted because it is wrong or we do this, so it is more obvious. Signed-off-by:
-
Peter Chen authored
commit 5a1e1456 upstream. If we connect Male-A-To-Male-A cable between otg-host and host pc, the ci->vbus_active is set wrongly, and cause the controller run at peripheral mode when we load gadget module (ci_udc_start will be run), but the software runs at host mode due to id = 0. The ehci_irq can't handle suspend (USBi_SLI) interrupt which is enabled for peripheral mode, it causes no one will handle irq error. This patch is needed for 3.12 stable Acked-by:
Michael Grzeschik <mgr@pengutronix.de> Reported-by:
Marc Kleine-Budde <mkl@pengutronix.de> Tested-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Fabio Estevam authored
commit cc5c9eb6 upstream. Commit 40ed51a4 (usb: chipidea: host: add vbus regulator control) introduced a smatch complaint because regulator_disable() is called without checking whether ci->platdata->reg_vbus is not NULL. Fix this by adding the check. This patch is needed for 3.12 stable Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Bjørn Mork authored
commit 4144bc86 upstream. Reported-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-by:
-
Marc Kleine-Budde authored
commit 20fb4eb9 upstream. This patch fixes a memory leak in pcan_usb_pro_init(). In patch f14e2243 net: can: peak_usb: Do not do dma on the stack the struct pcan_usb_pro_fwinfo *fi and struct pcan_usb_pro_blinfo *bi were converted from stack to dynamic allocation va kmalloc(). However the corresponding kfree() was not introduced. This patch adds the missing kfree(). Reported-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
-
Takashi Iwai authored
commit 6962d914 upstream. We've got regression reports that my previous fix for spurious wakeups after S5 on HP Haswell machines leads to the automatic reboot at shutdown on some machines. It turned out that the fix for one side triggers another BIOS bug in other side. So, it's exclusive. Since the original S5 wakeups have been confirmed only on HP machines, it'd be safer to apply it only to limited machines. As a wild guess, limiting to machines with HP PCI SSID should suffice. This patch should be backported to kernels as old as 3.12, that contain the commit 638298dc "xhci: Fix spurious wakeups after S5 on Haswell". Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: <dashing.meng@gmail.com> Reported-by:
Niklas Schnelle <niklas@komani.de> Reported-by:
Giorgos <ganastasiouGR@gmail.com> Reported-by: <art1@vhex.net> Signed-off-by:
-
Dmitry Kunilov authored
commit 52d0dc75 upstream. ZTE AC2726 EVDO modem drops ppp connection every minute when driven by zte_ev but works fine when driven by option. Move the support for AC2726 back to option driver. Signed-off-by:
Dmitry Kunilov <dmitry.kunilov@gmail.com> Signed-off-by:
-
Mika Westerberg authored
commit d24c195f upstream. Newer Intel PCHs with LPSS have the same Designware controllers than Haswell but ACPI IDs are different. Add these IDs to the driver list. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Jonathan Cameron authored
commit e39d9905 upstream. Note this also sets the endianness to big endian whereas it would previously have defaulted to the cpu endian. Hence technically this is a bug fix on LE platforms. Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Jonathan Cameron authored
commit 3425c0f7 upstream. A single channel in this driver was using the IIO_ST macro. This does not provide a parameter for setting the endianness of the channel. Thus this channel will have been reported as whatever is the native endianness of the cpu rather than big endian. This means it would be incorrect on little endian platforms. Signed-off-by:
-
Hui Wang authored
commit c29cb5eb upstream. On the Dell machines with codec whose Subsystem Id is 0x10280610, 0x10280629 or 0x1028063e, no external microphone can be detected when plugging a 3-ring headset. If we add "model=dell-headset-multi" for the snd-hda-intel.ko, the problem will disappear. The codecs on these machines belong to alc_269 family. BugLink: https://bugs.launchpad.net/bugs/1260303 Cc: David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
David Henningsson authored
commit 693e0cb0 upstream. While enabling these machines, we found we would sometimes lose an interrupt if we change hardware volume during playback, and that disabling msi fixed this issue. (Losing the interrupt caused underruns and crackling audio, as the one second timeout is usually bigger than the period size.) The machines were all machines from HP, running AMD Hudson controller, and Realtek ALC282 codec. BugLink: https://bugs.launchpad.net/bugs/1260225Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
JongHo Kim authored
commit ed697e1a upstream. When the process is sleeping at the SNDRV_PCM_STATE_PAUSED state from the wait_for_avail function, the sleep process will be woken by timeout(10 seconds). Even if the sleep process wake up by timeout, by this patch, the process will continue with sleep and wait for the other state. Signed-off-by:
JongHo Kim <furmuwon@gmail.com> Signed-off-by:
-
