- 10 Jun, 2016 40 commits
-
-
Johan Hovold authored
commit c5c0c555 upstream. Private data, URBs and buffers allocated for Epic devices during attach were never released on errors (e.g. missing endpoints). Fixes: 6e8cf775 ("USB: add EPIC support to the io_edgeport driver") Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Roger Quadros authored
commit b49b927f upstream. We shouldn't be calling clk_prepare_enable()/clk_prepare_disable() in an atomic context. Fixes the following issue: [ 5.830970] ehci-omap: OMAP-EHCI Host Controller driver [ 5.830974] driver_register 'ehci-omap' [ 5.895849] driver_register 'wl1271_sdio' [ 5.896870] BUG: scheduling while atomic: udevd/994/0x00000002 [ 5.896876] 4 locks held by udevd/994: [ 5.896904] #0: (&dev->mutex){......}, at: [<c049597c>] __driver_attach+0x60/0xac [ 5.896923] #1: (&dev->mutex){......}, at: [<c049598c>] __driver_attach+0x70/0xac [ 5.896946] #2: (tll_lock){+.+...}, at: [<c04c2630>] omap_tll_enable+0x2c/0xd0 [ 5.896966] #3: (prepare_lock){+.+...}, at: [<c05ce9c8>] clk_prepare_lock+0x48/0xe0 [ 5.897042] Modules linked in: wlcore_sdio(+) ehci_omap(+) dwc3_omap snd_soc_ts3a225e leds_is31fl319x bq27xxx_battery_i2c tsc2007 bq27xxx_battery bq2429x_charger ina2xx tca8418_keypad as5013 leds_tca6507 twl6040_vibra gpio_twl6040 bmp085_i2c(+) palmas_gpadc usb3503 palmas_pwrbutton bmg160_i2c(+) bmp085 bma150(+) bmg160_core bmp280 input_polldev snd_soc_omap_mcbsp snd_soc_omap_mcpdm snd_soc_omap snd_pcm_dmaengine [ 5.897048] Preemption disabled at:[< (null)>] (null) [ 5.897051] [ 5.897059] CPU: 0 PID: 994 Comm: udevd Not tainted 4.6.0-rc5-letux+ #233 [ 5.897062] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 5.897076] [<c010e714>] (unwind_backtrace) from [<c010af34>] (show_stack+0x10/0x14) [ 5.897087] [<c010af34>] (show_stack) from [<c040aa7c>] (dump_stack+0x88/0xc0) [ 5.897099] [<c040aa7c>] (dump_stack) from [<c020c558>] (__schedule_bug+0xac/0xd0) [ 5.897111] [<c020c558>] (__schedule_bug) from [<c06f3d44>] (__schedule+0x88/0x7e4) [ 5.897120] [<c06f3d44>] (__schedule) from [<c06f46d8>] (schedule+0x9c/0xc0) [ 5.897129] [<c06f46d8>] (schedule) from [<c06f4904>] (schedule_preempt_disabled+0x14/0x20) [ 5.897140] [<c06f4904>] (schedule_preempt_disabled) from [<c06f64e4>] (mutex_lock_nested+0x258/0x43c) [ 5.897150] [<c06f64e4>] (mutex_lock_nested) from [<c05ce9c8>] (clk_prepare_lock+0x48/0xe0) [ 5.897160] [<c05ce9c8>] (clk_prepare_lock) from [<c05d0e7c>] (clk_prepare+0x10/0x28) [ 5.897169] [<c05d0e7c>] (clk_prepare) from [<c04c2668>] (omap_tll_enable+0x64/0xd0) [ 5.897180] [<c04c2668>] (omap_tll_enable) from [<c04c1728>] (usbhs_runtime_resume+0x18/0x17c) [ 5.897192] [<c04c1728>] (usbhs_runtime_resume) from [<c049d404>] (pm_generic_runtime_resume+0x2c/0x40) [ 5.897202] [<c049d404>] (pm_generic_runtime_resume) from [<c049f180>] (__rpm_callback+0x38/0x68) [ 5.897210] [<c049f180>] (__rpm_callback) from [<c049f220>] (rpm_callback+0x70/0x88) [ 5.897218] [<c049f220>] (rpm_callback) from [<c04a0a00>] (rpm_resume+0x4ec/0x7ec) [ 5.897227] [<c04a0a00>] (rpm_resume) from [<c04a0f48>] (__pm_runtime_resume+0x4c/0x64) [ 5.897236] [<c04a0f48>] (__pm_runtime_resume) from [<c04958dc>] (driver_probe_device+0x30/0x70) [ 5.897246] [<c04958dc>] (driver_probe_device) from [<c04959a4>] (__driver_attach+0x88/0xac) [ 5.897256] [<c04959a4>] (__driver_attach) from [<c04940f8>] (bus_for_each_dev+0x50/0x84) [ 5.897267] [<c04940f8>] (bus_for_each_dev) from [<c0494e40>] (bus_add_driver+0xcc/0x1e4) [ 5.897276] [<c0494e40>] (bus_add_driver) from [<c0496914>] (driver_register+0xac/0xf4) [ 5.897286] [<c0496914>] (driver_register) from [<c01018e0>] (do_one_initcall+0x100/0x1b8) [ 5.897296] [<c01018e0>] (do_one_initcall) from [<c01c7a54>] (do_init_module+0x58/0x1c0) [ 5.897304] [<c01c7a54>] (do_init_module) from [<c01c8a3c>] (SyS_finit_module+0x88/0x90) [ 5.897313] [<c01c8a3c>] (SyS_finit_module) from [<c0107120>] (ret_fast_syscall+0x0/0x1c) [ 5.912697] ------------[ cut here ]------------ [ 5.912711] WARNING: CPU: 0 PID: 994 at kernel/sched/core.c:2996 _raw_spin_unlock+0x28/0x58 [ 5.912717] DEBUG_LOCKS_WARN_ON(val > preempt_count()) Reported-by:
H. Nikolaus Schaller <hns@goldelico.com> Tested-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Yoshihiro Shimoda authored
commit f879fc32 upstream. The firmware of R-Car USB 3.0 host controller will control the reset. So, if the xhci driver doesn't do firmware downloading (e.g. kernel configuration is CONFIG_USB_XHCI_PLATFORM=y and CONFIG_USB_XHCI_RCAR is not set), the reset of USB 3.0 host controller doesn't work correctly. Then, the host controller will cause long wait in xhci_reset() because the CMD_RESET bit of op_regs->command is not cleared for 10 seconds. So, this patch modifies the Kconfig to enable both CONFIG_USB_XHCI_PLATFORM and CONFIG_USB_XHCI_RCAR. Fixes: 4ac8918f (usb: host: xhci-plat: add support for the R-Car H2 and M2 xHCI controllers) Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Leonid Yegoshin authored
commit 41fa29e4 upstream. Error recovery pointers for fixups was improperly set as ".word" which is unsuitable for MIPS64. Replaced by STR(PTR) [ralf@linux-mips.org: Apply changes as requested in the review process.] Signed-off-by:
Leonid Yegoshin <Leonid.Yegoshin@imgtec.com> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Reviewed-by:
Markos Chandras <markos.chandras@imgtec.com> Fixes: b0a668fb ("MIPS: kernel: mips-r2-to-r6-emul: Add R2 emulator for MIPS R6") Cc: macro@linux-mips.org Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9911/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Huacai Chen authored
commit 3484de7b upstream. Due to datasheet, reserving 0xff800000~0xffffffff (8MB below 4GB) is not enough for RS780E integrated GPU's TOM (top of memory) registers and MSI/MSI-x memory region, so we reserve 0xfe000000~0xffffffff (32MB below 4GB). Signed-off-by:
Huacai Chen <chenhc@lemote.com> Cc: Aurelien Jarno <aurelien@aurel32.net> Cc: Steven J . Hill <sjhill@realitydiluted.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12889/Signed-off-by:
-
Huacai Chen authored
commit a95d0692 upstream. After commit 92923ca3 ("mm: meminit: only set page reserved in the memblock region"), the MIPS hibernation is broken. Because pages in nosave data section should be "reserved", but currently they aren't set to "reserved" at initialization. This patch makes hibernation work again. Signed-off-by:
-
James Hogan authored
commit 81a76d71 upstream. When showing backtraces in response to traps, for example crashes and address errors (usually unaligned accesses) when they are set in debugfs to be reported, unwind_stack will be used if the PC was in the kernel text address range. However since EVA it is possible for user and kernel address ranges to overlap, and even without EVA userland can still trigger an address error by jumping to a KSeg0 address. Adjust the check to also ensure that it was running in kernel mode. I don't believe any harm can come of this problem, since unwind_stack() is sufficiently defensive, however it is only meant for unwinding kernel code, so to be correct it should use the raw backtracing instead. Signed-off-by:
-
James Hogan authored
commit a816b306 upstream. When unwinding through IRQs and exceptions, the unwinding only continues if the PC is a kernel text address, however since EVA it is possible for user and kernel address ranges to overlap, potentially allowing unwinding to continue to user mode if the user PC happens to be in the kernel text address range. Adjust the check to also ensure that the register state from before the exception is actually running in kernel mode, i.e. !user_mode(regs). I don't believe any harm can come of this problem, since the PC is only output, the stack pointer is checked to ensure it resides within the task's stack page before it is dereferenced in search of the return address, and the return address register is similarly only output (if the PC is in a leaf function or the beginning of a non-leaf function). However unwind_stack() is only meant for unwinding kernel code, so to be correct the unwind should stop there. Signed-off-by:
-
James Hogan authored
commit 5daebc47 upstream. Commit 85efde6f ("make exported headers use strict posix types") changed the asm-generic siginfo.h to use the __kernel_* types, and commit 3a471cbc ("remove __KERNEL_STRICT_NAMES") make the internal types accessible only to the kernel, but the MIPS implementation hasn't been updated to match. Switch to proper types now so that the exported asm/siginfo.h won't produce quite so many compiler errors when included alone by a user program. Signed-off-by:
-
Oliver Hartkopp authored
commit bb208f14 upstream. As described in 'can: m_can: tag current CAN FD controllers as non-ISO' (6cfda7fb) it is possible to define fixed configuration options by setting the according bit in 'ctrlmode' and clear it in 'ctrlmode_supported'. This leads to the incovenience that the fixed configuration bits can not be passed by netlink even when they have the correct values (e.g. non-ISO, FD). This patch fixes that issue and not only allows fixed set bit values to be set again but now requires(!) to provide these fixed values at configuration time. A valid CAN FD configuration consists of a nominal/arbitration bittiming, a data bittiming and a control mode with CAN_CTRLMODE_FD set - which is now enforced by a new can_validate() function. This fix additionally removed the inconsistency that was prohibiting the support of 'CANFD-only' controller drivers, like the RCar CAN FD. For this reason a new helper can_set_static_ctrlmode() has been introduced to provide a proper interface to handle static enabled CAN controller options. Reported-by:
Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com> Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Reviewed-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Anilkumar Kolli authored
commit 4ad24a9d upstream. It is observed that while loading and unloading ath10k modules in an infinite loop, before ath10k_core_start() completion HTT rx frames are received, while processing these frames, dereferencing the arvifs list code is getting hit before initilizing the arvifs list, causing a kernel panic. This patch initilizes the arvifs list before initilizing htt. Fixes the below issue: [<bf88b058>] (ath10k_htt_rx_pktlog_completion_handler+0x278/0xd08 [ath10k_core]) [<bf88b058>] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core]) [<bf88c0dc>] (ath10k_htt_txrx_compl_task+0x5f4/0xeb0 [ath10k_core]) [<bf88c0dc>] (ath10k_htt_txrx_compl_task [ath10k_core]) [<c0234100>] (tasklet_action+0x8c/0xec) [<c0234100>] (tasklet_action) [<c02337c0>] (__do_softirq+0xf8/0x228) [<c02337c0>] (__do_softirq) [<c0233920>] (run_ksoftirqd+0x30/0x90) Code: e5954ad8 e2899008 e1540009 0a00000d (e5943008) ---[ end trace 71de5c2e011dbf56 ]--- Kernel panic - not syncing: Fatal exception in interrupt Fixes: 500ff9f9 ("ath10k: implement chanctx API") Signed-off-by:
Anilkumar Kolli <akolli@qti.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Marek Szyprowski authored
commit 330d1276 upstream. MAX8997 PMIC requires interrupt and fails probing without it. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Fixes: d105f0b1 ("ARM: dts: Add basic dts file for Samsung Trats board") [k.kozlowski: Write commit message, add CC-stable] Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Catalin Marinas authored
commit 5bb1cc0f upstream. Currently, pmd_present() only checks for a non-zero value, returning true even after pmd_mknotpresent() (which only clears the type bits). This patch converts pmd_present() to using pte_present(), similar to the other pmd_*() checks. As a side effect, it will return true for PROT_NONE mappings, though they are not yet used by the kernel with transparent huge pages. For consistency, also change pmd_mknotpresent() to only clear the PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block mappings (no functional change). The unused PMD_SECT_PROT_NONE definition is removed as transparent huge pages use the pte page prot values. Fixes: 9c7e535f ("arm64: mm: Route pmd thp functions through pte equivalents") Reviewed-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Nicolai Stange authored
commit 935244cd upstream. Currently, in ext4_mb_init(), there's a loop like the following: do { ... offset += 1 << (sb->s_blocksize_bits - i); i++; } while (i <= sb->s_blocksize_bits + 1); Note that the updated offset is used in the loop's next iteration only. However, at the last iteration, that is at i == sb->s_blocksize_bits + 1, the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15 shift exponent 4294967295 is too large for 32-bit type 'int' [...] Call Trace: [<ffffffff818c4d25>] dump_stack+0xbc/0x117 [<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169 [<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e [<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158 [<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390 [<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0 [<ffffffff814293c7>] ? create_cache+0x57/0x1f0 [<ffffffff8142948a>] ? create_cache+0x11a/0x1f0 [<ffffffff821c2168>] ? mutex_lock+0x38/0x60 [<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50 [<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0 [<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0 [<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0 [...] Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1. Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of offset is never used again. Silence UBSAN by introducing another variable, offset_incr, holding the next increment to apply to offset and adjust that one by right shifting it by one position per loop iteration. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161Signed-off-by:
Nicolai Stange <nicstange@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Nicolai Stange authored
commit b5cb316c upstream. Currently, in mb_find_order_for_block(), there's a loop like the following: while (order <= e4b->bd_blkbits + 1) { ... bb += 1 << (e4b->bd_blkbits - order); } Note that the updated bb is used in the loop's next iteration only. However, at the last iteration, that is at order == e4b->bd_blkbits + 1, the shift count becomes negative (c.f. C99 6.5.7(3)) and UBSAN reports UBSAN: Undefined behaviour in fs/ext4/mballoc.c:1281:11 shift exponent -1 is negative [...] Call Trace: [<ffffffff818c4d35>] dump_stack+0xbc/0x117 [<ffffffff818c4c79>] ? _atomic_dec_and_lock+0x169/0x169 [<ffffffff819411bb>] ubsan_epilogue+0xd/0x4e [<ffffffff81941cbc>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254 [<ffffffff81941ac1>] ? __ubsan_handle_load_invalid_value+0x158/0x158 [<ffffffff816e93a0>] ? ext4_mb_generate_from_pa+0x590/0x590 [<ffffffff816502c8>] ? ext4_read_block_bitmap_nowait+0x598/0xe80 [<ffffffff816e7b7e>] mb_find_order_for_block+0x1ce/0x240 [...] Unless compilers start to do some fancy transformations (which at least GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the such calculated value of bb is never used again. Silence UBSAN by introducing another variable, bb_incr, holding the next increment to apply to bb and adjust that one by right shifting it by one position per loop iteration. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161Signed-off-by:
-
Jan Kara authored
commit 74177f55 upstream. When filesystem is corrupted in the right way, it can happen ext4_mark_iloc_dirty() in ext4_orphan_add() returns error and we subsequently remove inode from the in-memory orphan list. However this deletion is done with list_del(&EXT4_I(inode)->i_orphan) and thus we leave i_orphan list_head with a stale content. Later we can look at this content causing list corruption, oops, or other issues. The reported trace looked like: WARNING: CPU: 0 PID: 46 at lib/list_debug.c:53 __list_del_entry+0x6b/0x100() list_del corruption, 0000000061c1d6e0->next is LIST_POISON1 0000000000100100) CPU: 0 PID: 46 Comm: ext4.exe Not tainted 4.1.0-rc4+ #250 Stack: 60462947 62219960 602ede24 62219960 602ede24 603ca293 622198f0 602f02eb 62219950 6002c12c 62219900 601b4d6b Call Trace: [<6005769c>] ? vprintk_emit+0x2dc/0x5c0 [<602ede24>] ? printk+0x0/0x94 [<600190bc>] show_stack+0xdc/0x1a0 [<602ede24>] ? printk+0x0/0x94 [<602ede24>] ? printk+0x0/0x94 [<602f02eb>] dump_stack+0x2a/0x2c [<6002c12c>] warn_slowpath_common+0x9c/0xf0 [<601b4d6b>] ? __list_del_entry+0x6b/0x100 [<6002c254>] warn_slowpath_fmt+0x94/0xa0 [<602f4d09>] ? __mutex_lock_slowpath+0x239/0x3a0 [<6002c1c0>] ? warn_slowpath_fmt+0x0/0xa0 [<60023ebf>] ? set_signals+0x3f/0x50 [<600a205a>] ? kmem_cache_free+0x10a/0x180 [<602f4e88>] ? mutex_lock+0x18/0x30 [<601b4d6b>] __list_del_entry+0x6b/0x100 [<601177ec>] ext4_orphan_del+0x22c/0x2f0 [<6012f27c>] ? __ext4_journal_start_sb+0x2c/0xa0 [<6010b973>] ? ext4_truncate+0x383/0x390 [<6010bc8b>] ext4_write_begin+0x30b/0x4b0 [<6001bb50>] ? copy_from_user+0x0/0xb0 [<601aa840>] ? iov_iter_fault_in_readable+0xa0/0xc0 [<60072c4f>] generic_perform_write+0xaf/0x1e0 [<600c4166>] ? file_update_time+0x46/0x110 [<60072f0f>] __generic_file_write_iter+0x18f/0x1b0 [<6010030f>] ext4_file_write_iter+0x15f/0x470 [<60094e10>] ? unlink_file_vma+0x0/0x70 [<6009b180>] ? unlink_anon_vmas+0x0/0x260 [<6008f169>] ? free_pgtables+0xb9/0x100 [<600a6030>] __vfs_write+0xb0/0x130 [<600a61d5>] vfs_write+0xa5/0x170 [<600a63d6>] SyS_write+0x56/0xe0 [<6029fcb0>] ? __libc_waitpid+0x0/0xa0 [<6001b698>] handle_syscall+0x68/0x90 [<6002633d>] userspace+0x4fd/0x600 [<6002274f>] ? save_registers+0x1f/0x40 [<60028bd7>] ? arch_prctl+0x177/0x1b0 [<60017bd5>] fork_handler+0x85/0x90 Fix the problem by using list_del_init() as we always should with i_orphan list. Reported-by:
Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Konstantin Shkolnyy authored
commit a377f9e9 upstream. A bug in the CRTSCTS handling caused RTS to alternate between CRTSCTS=0 => "RTS is transmit active signal" and CRTSCTS=1 => "RTS is used for receive flow control" instead of CRTSCTS=0 => "RTS is statically active" and CRTSCTS=1 => "RTS is used for receive flow control" This only happened after first having enabled CRTSCTS. Signed-off-by:
Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com> Fixes: 39a66b8d ("[PATCH] USB: CP2101 Add support for flow control") [johan: reword commit message ] Signed-off-by:
-
Alex Deucher authored
commit 6b8812eb upstream. This is a port of radeon commit: 3d2d98ee drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh to amdgpu. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Lv Zheng authored
commit 30c9bb0d upstream. The order of the _OSI related functionalities is as follows: acpi_blacklisted() acpi_dmi_osi_linux() acpi_osi_setup() acpi_osi_setup() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< parse_args() __setup("acpi_osi=") acpi_osi_setup_linux() acpi_update_interfaces() if "!*" <<<<<<<<<<<<<<<<<<<<<<<< acpi_early_init() acpi_initialize_subsystem() acpi_ut_initialize_interfaces() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ acpi_bus_init() acpi_os_initialize1() acpi_install_interface_handler(acpi_osi_handler) acpi_osi_setup_late() acpi_update_interfaces() for "!" >>>>>>>>>>>>>>>>>>>>>>>> acpi_osi_handler() Since acpi_osi_setup_linux() can override acpi_dmi_osi_linux(), the command line setting can override the DMI detection. That's why acpi_blacklisted() is put before __setup("acpi_osi="). Then we can notice the following wrong invocation order. There are acpi_update_interfaces() (marked by <<<<) calls invoked before acpi_ut_initialize_interfaces() (marked by ^^^^). This makes it impossible to use acpi_osi=!* correctly from OSI DMI table or from the command line. The use of acpi_osi=!* is meant to disable both ACPICA (acpi_gbl_supported_interfaces) and Linux specific strings (osi_setup_entries) while the ACPICA part should have stopped working because of the order issue. This patch fixes this issue by moving acpi_update_interfaces() to where it is invoked for acpi_osi=! (marked by >>>>) as this is ensured to be invoked after acpi_ut_initialize_interfaces() (marked by ^^^^). Linux specific strings are still handled in the original place in order to make the following command line working: acpi_osi=!* acpi_osi="Module Device". Note that since acpi_osi=!* is meant to further disable linux specific string comparing to the acpi_osi=!, there is no such use case in our bug fixing work and hence there is no one using acpi_osi=!* either from the command line or from the DMI quirks, this issue is just a theoretical issue. Fixes: 741d8128 (ACPI: Add facility to remove all _OSI strings) Tested-by:
Lukas Wunner <lukas@wunner.de> Tested-by:
Chen Yu <yu.c.chen@intel.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Lei Liu authored
commit 74d2a91a upstream. Add even more ZTE device ids. Signed-off-by:
lei liu <liu.lei78@zte.com.cn> [johan: rebase and replace commit message ] Signed-off-by:
-
lei liu authored
commit f0d09463 upstream. More ZTE device ids. Signed-off-by:
-
Andreas Werner authored
commit f75564d3 upstream. The bar number is found in reg2 within the gdd. Therefore we need to change the assigment from reg1 to reg2 which is the correct location. Signed-off-by:
Andreas Werner <andreas.werner@men.de> Fixes: '3764e82e' drivers: Introduce MEN Chameleon Bus Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Mathias Nyman authored
commit cdc77c82 upstream. The current implemenentation restart the sent pattern for each entry in the sg list. The receiving end expects a continuous pattern, and test will fail unless scatterilst entries happen to be aligned with the pattern Fix this by calculating the pattern byte based on total sent size instead of just the current sg entry. Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Fixes: 8b524901 ("[PATCH] USB: usbtest: scatterlist OUT data pattern testing") Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Alan Stern authored
commit b9a6e8e1 upstream. With this change, the host and gadget doesn't need to agree with transfer length for comparing the data, since they doesn't know each other's transfer size, but know max packet size. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Acked-by:
Michal Nazarewicz <mina86@mina86.com> (Fixed the 'line over 80 characters warning' by Peter Chen) Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Alan Stern authored
commit 6fb650d4 upstream. When a USB driver is bound to an interface (either through probing or by claiming it) or is unbound from an interface, the USB core always disables Link Power Management during the transition and then re-enables it afterward. The reason is because the driver might want to prevent hub-initiated link power transitions, in which case the HCD would have to recalculate the various LPM parameters. This recalculation takes place when LPM is re-enabled and the new parameters are sent to the device and its parent hub. However, if the driver does not want to prevent hub-initiated link power transitions then none of this work is necessary. The parameters don't need to be recalculated, and LPM doesn't need to be disabled and re-enabled. It turns out that disabling and enabling LPM can be time-consuming, enough so that it interferes with user programs that want to claim and release interfaces rapidly via usbfs. Since the usbfs kernel driver doesn't set the disable_hub_initiated_lpm flag, we can speed things up and get the user programs to work by leaving LPM alone whenever the flag isn't set. And while we're improving the way disable_hub_initiated_lpm gets used, let's also fix its kerneldoc. Signed-off-by:
Matthew Giassa <matthew@giassa.net> CC: Mathias Nyman <mathias.nyman@intel.com> Signed-off-by:
-
Schemmel Hans-Christoph authored
commit 444f94e9 upstream. Added support for Gemalto's Cinterion PH8 and AHxx products with 2 RmNet Interfaces and products with 1 RmNet + 1 USB Audio interface. In addition some minor renaming and formatting. Signed-off-by:
Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com> [johan: sort current entries and trim trailing whitespace ] Signed-off-by:
-
Andreas Noever authored
commit 2ffa9a5d upstream. If tb_drom_read() fails, sw->drom is freed but not set to NULL. sw->drom is then freed again in the error path of tb_switch_alloc(). The bug can be triggered by unplugging a thunderbolt device shortly after it is detected by the thunderbolt driver. Clear sw->drom if tb_drom_read() fails. [bhelgaas: add Fixes:, stable versions of interest] Fixes: 343fcb8c ("thunderbolt: Fix nontrivial endpoint devices.") Signed-off-by:
Andreas Noever <andreas.noever@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Zhao Qiang authored
commit 11ca2b7a upstream. New bindings use "fsl,t1040-ucc-uart" as the compatible for qe-uart. So add it. Signed-off-by:
Zhao Qiang <qiang.zhao@nxp.com> Signed-off-by:
-
Brian Bloniarz authored
commit 0f40fbbc upstream. OpenSSH expects the (non-blocking) read() of pty master to return EAGAIN only if it has received all of the slave-side output after it has received SIGCHLD. This used to work on pre-3.12 kernels. This fix effectively forces non-blocking read() and poll() to block for parallel i/o to complete for all ttys. It also unwinds these changes: 1) f8747d4a tty: Fix pty master read() after slave closes 2) 52bce7f8 pty, n_tty: Simplify input processing on final close 3) 1a48632f pty: Fix input race when closing Inspired by analysis and patch from Marc Aurele La France <tsi@tuyoix.net> Reported-by:
Volth <openssh@volth.com> Reported-by:
Marc Aurele La France <tsi@tuyoix.net> BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52 BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492Signed-off-by:
Brian Bloniarz <brian.bloniarz@gmail.com> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Peter Hurley authored
commit e176058f upstream. Introduce API functions to restart and cancel tty buffer work, rather than manipulate buffer work directly. Signed-off-by:
-
Alexander Usyskin authored
commit 9d04ee11 upstream. When a message is received and amthif client is not in reading state the message is ignored and left dangling in the queue. This may happen after one of the amthif host connections is closed w/o completing the reading. Another client will pick up a wrong message on next read attempt which will lead to link reset. To prevent this the driver has to properly discard the message when amthif client is not in reading state. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Alexander Usyskin authored
commit 6a8d648c upstream. In the case when disconnection is initiated from the FW the driver is flushing items from the write control list while iterating over it: mei_irq_write_handler() list_for_each_entry_safe(ctrl_wr_list) <-- outer loop mei_cl_irq_disconnect_rsp() mei_cl_set_disconnected() mei_io_list_flush(ctrl_wr_list) <-- destorying list We move the list flushing to the completion routine. Signed-off-by:
-
K. Y. Srinivasan authored
commit a389fcfd upstream. On the consumer side, we have interrupt driven flow management of the producer. It is sufficient to base the signaling decision on the amount of space that is available to write after the read is complete. The current code samples the previous available space and uses this in making the signaling decision. This state can be stale and is unnecessary. Since the state can be stale, we end up not signaling the host (when we should) and this can result in a hang. Fix this problem by removing the unnecessary check. I would like to thank Arseney Romanenko <arseneyr@microsoft.com> for pointing out this issue. Also, issue a full memory barrier before making the signaling descision to correctly deal with potential reordering of the write (read index) followed by the read of pending_sz. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Tested-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
-
Vitaly Kuznetsov authored
commit 822f18d4 upstream. Convert 6+-string comments repeating function names to normal kernel-style comments and fix a couple of other comment style issues. No textual or functional changes intended. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
-
Christopher Oo authored
commit a5cca686 upstream. Fixes a bug where previously hv_ringbuffer_read would pass in the old number of bytes available to read instead of the expected old read index when calculating when to signal to the host that the ringbuffer is empty. Since the previous write size is already saved, also changes the hv_need_to_signal_on_read to use the previously read value rather than recalculating it. Signed-off-by:
Christopher Oo <t-chriso@microsoft.com> Signed-off-by:
-
Matthias Schiffer authored
commit f5b556c9 upstream. This makes the ath79 bootconsole behave the same way as the generic 8250 bootconsole. Also waiting for TEMT (transmit buffer is empty) instead of just THRE (transmit buffer is not full) ensures that all characters have been transmitted before the real serial driver starts reconfiguring the serial controller (which would sometimes result in garbage being transmitted.) This change does not cause a visible performance loss. In addition, this seems to fix a hang observed in certain configurations on many AR7xxx/AR9xxx SoCs during autoconfig of the real serial driver. A more complete follow-up patch will disable 8250 autoconfig for ath79 altogether (the serial controller is detected as a 16550A, which is not fully compatible with the ath79 serial, and the autoconfig may lead to undefined behavior on ath79.) Signed-off-by:
Matthias Schiffer <mschiffer@universe-factory.net> Signed-off-by:
-
Theodore Ts'o authored
commit c9eb13a9 upstream. If the orphaned inode list contains inode #5, ext4_iget() returns a bad inode (since the bootloader inode should never be referenced directly). Because of the bad inode, we end up processing the inode repeatedly and this hangs the machine. This can be reproduced via: mke2fs -t ext4 /tmp/foo.img 100 debugfs -w -R "ssv last_orphan 5" /tmp/foo.img mount -o loop /tmp/foo.img /mnt (But don't do this if you are using an unpatched kernel if you care about the system staying functional. :-) This bug was found by the port of American Fuzzy Lop into the kernel to find file system problems[1]. (Since it *only* happens if inode #5 shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not surprising that AFL needed two hours before it found it.) [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf Reported by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by:
-
Raghava Aditya Renukunta authored
commit 78cbccd3 upstream. When KDUMP is triggered the driver first talks to the firmware in INTX mode, but the adapter firmware is still in MSIX mode. Therefore the first driver command hangs since the driver is waiting for an INTX response and firmware gives a MSIX response. If when the OS is installed on a RAID drive created by the adapter KDUMP will hang since the driver does not receive a response in sync mode. Fixed by: Change the firmware to INTX mode if it is in MSIX mode before sending the first sync command. Signed-off-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Raghava Aditya Renukunta authored
commit fc4bf75e upstream. Typically under error conditions, it is possible for aac_command_thread() to miss the wakeup from kthread_stop() and go back to sleep, causing it to hang aac_shutdown. In the observed scenario, the adapter is not functioning correctly and so aac_fib_send() never completes (or time-outs depending on how it was called). Shortly after aac_command_thread() starts it performs aac_fib_send(SendHostTime) which hangs. When aac_probe_one /aac_get_adapter_info send time outs, kthread_stop is called which breaks the command thread out of it's hang. The code will still go back to sleep in schedule_timeout() without checking kthread_should_stop() so it causes aac_probe_one to hang until the schedule_timeout() which is 30 minutes. Fixed by: Adding another kthread_should_stop() before schedule_timeout() Signed-off-by:
-
Raghava Aditya Renukunta authored
commit 07beca2b upstream. aac_fib_send has a special function case for initial commands during driver initialization using wait < 0(pseudo sync mode). In this case, the command does not sleep but rather spins checking for timeout.This loop is calls cpu_relax() in an attempt to allow other processes/threads to use the CPU, but this function does not relinquish the CPU and so the command will hog the processor. This was observed in a KDUMP "crashkernel" and that prevented the "command thread" (which is responsible for completing the command from being timed out) from starting because it could not get the CPU. Fixed by replacing "cpu_relax()" call with "schedule()" Signed-off-by:
-
