- 04 Jul, 2015 40 commits
-
-
Ryan Underwood authored
[ Upstream commit 2fb22a80 ] Disable write buffering on the Toshiba ToPIC95 if it is enabled by somebody (it is not supposed to be a power-on default according to the datasheet). On the ToPIC95, practically no 32-bit Cardbus card will work under heavy load without locking up the whole system if this is left enabled. I tried about a dozen. It does not affect 16-bit cards. This is similar to the O2 bugs in early controller revisions it seems. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961 Cc: <stable@vger.kernel.org> Signed-off-by:
Ryan C. Underwood <nemesis@icequake.net> Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Theodore Ts'o authored
[ Upstream commit bdf96838 ] The commit cf108bca: "ext4: Invert the locking order of page_lock and transaction start" caused __ext4_journalled_writepage() to drop the page lock before the page was written back, as part of changing the locking order to jbd2_journal_start -> page_lock. However, this introduced a potential race if there was a truncate racing with the data=journalled writeback mode. Fix this by grabbing the page lock after starting the journal handle, and then checking to see if page had gotten truncated out from under us. This fixes a number of different warnings or BUG_ON's when running xfstests generic/086 in data=journalled mode, including: jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7 c0, 164), jh->b_transaction ( (null), 0), jh->b_next_transaction ( (null), 0), jlist 0 - and - kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200! ... Call Trace: [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117 [<c02b2de5>] __ext4_journalled_invalidatepage+0x10f/0x117 [<c02b2ded>] ? __ext4_journalled_invalidatepage+0x117/0x117 [<c027d883>] ? lock_buffer+0x36/0x36 [<c02b2dfa>] ext4_journalled_invalidatepage+0xd/0x22 [<c0229139>] do_invalidatepage+0x22/0x26 [<c0229198>] truncate_inode_page+0x5b/0x85 [<c022934b>] truncate_inode_pages_range+0x156/0x38c [<c0229592>] truncate_inode_pages+0x11/0x15 [<c022962d>] truncate_pagecache+0x55/0x71 [<c02b913b>] ext4_setattr+0x4a9/0x560 [<c01ca542>] ? current_kernel_time+0x10/0x44 [<c026c4d8>] notify_change+0x1c7/0x2be [<c0256a00>] do_truncate+0x65/0x85 [<c0226f31>] ? file_ra_state_init+0x12/0x29 - and - WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396 irty_metadata+0x14a/0x1ae() ... Call Trace: [<c01b879f>] ? console_unlock+0x3a1/0x3ce [<c082cbb4>] dump_stack+0x48/0x60 [<c0178b65>] warn_slowpath_common+0x89/0xa0 [<c02ef2cf>] ? jbd2_journal_dirty_metadata+0x14a/0x1ae [<c0178bef>] warn_slowpath_null+0x14/0x18 [<c02ef2cf>] jbd2_journal_dirty_metadata+0x14a/0x1ae [<c02d8615>] __ext4_handle_dirty_metadata+0xd4/0x19d [<c02b2f44>] write_end_fn+0x40/0x53 [<c02b4a16>] ext4_walk_page_buffers+0x4e/0x6a [<c02b59e7>] ext4_writepage+0x354/0x3b8 [<c02b2f04>] ? mpage_release_unused_pages+0xd4/0xd4 [<c02b1b21>] ? wait_on_buffer+0x2c/0x2c [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8 [<c02b5a5b>] __writepage+0x10/0x2e [<c0225956>] write_cache_pages+0x22d/0x32c [<c02b5a4b>] ? ext4_writepage+0x3b8/0x3b8 [<c02b6ee8>] ext4_writepages+0x102/0x607 [<c019adfe>] ? sched_clock_local+0x10/0x10e [<c01a8a7c>] ? __lock_is_held+0x2e/0x44 [<c01a8ad5>] ? lock_is_held+0x43/0x51 [<c0226dff>] do_writepages+0x1c/0x29 [<c0276bed>] __writeback_single_inode+0xc3/0x545 [<c0277c07>] writeback_sb_inodes+0x21f/0x36d ... Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by:
-
Catalin Marinas authored
[ Upstream commit 565630d5 ] After secondary CPU boot or hotplug, the active_mm of the idle thread is &init_mm. The init_mm.pgd (swapper_pg_dir) is only meant for TTBR1_EL1 and must not be set in TTBR0_EL1. Since when active_mm == &init_mm the TTBR0_EL1 is already set to the reserved value, there is no need to perform any context reset. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Zidan Wang authored
[ Upstream commit a077e81e ] the enum of "DAC Polarity" should be wm8960_enum[1]. Signed-off-by:
Zidan Wang <zidan.wang@freescale.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Lior Amsalem authored
[ Upstream commit 9136291f ] This patch fixes a bug in the XOR driver where the cleanup function can be called and free descriptors that never been processed by the engine (which result in data errors). The cleanup function will free descriptors based on the ownership bit in the descriptors. Fixes: ff7b0479 ("dmaengine: DMA engine driver for Marvell XOR engine") Signed-off-by:
Lior Amsalem <alior@marvell.com> Signed-off-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by:
Ofer Heifetz <oferh@marvell.com> Cc: stable@vger.kernel.org Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Cyrille Pitchen authored
[ Upstream commit 93563a6a ] For TX transactions, the TXCOMP bit in the Status Register is cleared when the first data is written into the Transmit Holding Register. In the lines from at91_do_twi_transfer(): at91_twi_write_data_dma(dev); at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP); the TXCOMP interrupt may be enabled before the DMA controller has actually started to write into the THR. In such a case, the TXCOMP bit is still set into the Status Register so the interrupt is triggered immediately. The driver understands that a transaction completion has occurred but this transaction hasn't started yet. Hence the TXCOMP interrupt is no longer enabled by at91_do_twi_transfer() but instead by at91_twi_write_data_dma_callback(). Also, the TXCOMP bit in the Status Register in not a clear on read flag but a snapshot of the transmission state at the time the Status Register is read. When a NACK error is dectected by the I2C controller, the TXCOMP, NACK and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP interrupt is triggered at the same time. Also setting the TXRDY to 1 triggers the DMA controller to write the next data into the THR. Such a write resets the TXCOMP bit to 0 in the SR. So depending on when the interrupt handler reads the SR, it may fail to detect the NACK error if it relies on the TXCOMP bit. The NACK bit and its interrupt should be used instead. For RX transactions, the TXCOMP bit in the Status Register is cleared when the START bit is set into the Control Register. However to unify the management of the TXCOMP bit when the DMA controller is used, the TXCOMP interrupt is now enabled by the DMA callbacks for both TX and RX transfers. Signed-off-by:
Cyrille Pitchen <cyrille.pitchen@atmel.com> Cc: stable@vger.kernel.org #3.10 and later Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit 27e7cd01 ] The pinctrl_gpio_range[] array described a first bank of 32 GPIOs and a second one of 27 GPIOs. However, since there is a total of 60 MPP pins that can be muxed as GPIOs, the second bank really has 28 GPIOs. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.15+ Fixes: ca6d9a08 ("pinctrl: mvebu: add pin-muxing driver for the Marvell Armada 380/385") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit d538990e ] There was an incorrect space in the definition of the function of one pin in the Armada 375 pinctrl driver, which this commit fixes. Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit ea78b951 ] There was a mistake in the definition of the functions for MPP48 on Marvell Armada XP. The second function is dev(clkout), and not tclk. Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit 80b3d04f ] The latest version of the Armada XP datasheet no longer documents the VDD cpu_pd functions, which might indicate they are not working and/or not supported. This commit ensures the pinctrl driver matches the datasheet. Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit bc99357f ] After updating to a more recent version of the Armada XP datasheet, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit e5447d26 ] After updating to a more recent version of the Armada 375, we realized that some of the pins documented as having a NAND-related functionality in fact did not have such functionality. This commit updates the pinctrl driver accordingly. Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit 438881df ] Due to a mistake, the CS0 and CS1 SPI0 functions were incorrectly named "spi0-1" instead of just "spi0". This commit fixes that. This DT binding change does not affect any of the in-tree users. Signed-off-by:
-
Thomas Petazzoni authored
[ Upstream commit 331642fb ] A new revision of the Marvell Armada 38x hardware datasheet unveiled that the definition of some of the PCIe functions were not correct. This commit fixes the pinctrl driver accordingly. Some PCIe functions simply do not exist, some of the PCIe functions in fact were corresponding to other functions, and some PCIe functions have been added. Note: the seemingly unrelated removal of spi(cs2) on MPP47 is related: this function is in fact implemented on MPP43, instead of a PCIe function. Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit 1dace011 ] The Foxconn K8M890-8237A has two PCI host bridges, and we can't assign resources correctly without the information from _CRS that tells us which address ranges are claimed by which bridge. In the bugs mentioned below, we incorrectly assign a sound card address (this example is from 1033299): bus: 00 index 2 [mem 0x80000000-0xfcffffffff] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f]) pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored) pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored) pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored) ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff]) pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored) pci 0000:80:01.0: [1106:3288] type 0 class 0x000403 pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit] pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff] pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit] BUG: unable to handle kernel paging request at ffffc90000378000 IP: [<ffffffffa0345f63>] azx_create+0x37c/0x822 [snd_hda_intel] We assigned 0xfd_0000_0000, but that is not in any of the host bridge windows, and the sound card doesn't work. Turn on pci=use_crs automatically for this system. Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368 Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 3d56402d ] Add missing invocation of pm_generic_complete() to acpi_subsys_complete() to allow ->complete callbacks provided by the drivers of devices using the ACPI PM domain to be executed during system resume. Fixes: f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend) Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit a7068e39 ] The buffer for condtraints debug isn't big enough to hold the output in all cases. So fix this issue by increasing the buffer. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Alex Williamson authored
[ Upstream commit a5dd4b4b ] The commit referenced below deferred waiting for command completion until the start of the next command, allowing hardware to do the latching asynchronously. Unfortunately, being ready to accept a new command is the only indication we have that the previous command is completed. In cases where we need that state change to be enabled, we must still wait for completion. For instance, pciehp_reset_slot() attempts to disable anything that might generate a surprise hotplug on slots that support presence detection. If we don't wait for those settings to latch before the secondary bus reset, we negate any value in attempting to prevent the spurious hotplug. Create a base function with optional wait and helper functions so that pcie_write_cmd() turns back into the "safe" interface which waits before and after issuing a command and add pcie_write_cmd_nowait(), which eliminates the trailing wait for asynchronous completion. The following functions are returned to their previous behavior: pciehp_power_on_slot pciehp_power_off_slot pcie_disable_notification pciehp_reset_slot The rationale is that pciehp_power_on_slot() enables the link and therefore relies on completion of power-on. pciehp_power_off_slot() and pcie_disable_notification() need a wait because data structures may be freed after these calls and continued signaling from the device would be unexpected. And, of course, pciehp_reset_slot() needs to wait for the scenario outlined above. Fixes: 3461a068 ("PCI: pciehp: Wait for hotplug command completion lazily") Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Christophe Ricard authored
[ Upstream commit 4ac82e89 ] ndlc_remove already calls st21nfcb_nci_i2c_disable and phy->powered is already set to 0. Cc: stable@vger.kernel.org Signed-off-by:
Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Christophe Ricard authored
[ Upstream commit 09f39a95 ] Once the data is sent, we need to preserve the full frame for the ndlc state machine. If the NDLC ACK is not received in time, the ndlc layer will resend the same frame. Having the header byte pulled will corrupt the frame. Cc: stable@vger.kernel.org Signed-off-by:
-
Firo Yang authored
[ Upstream commit 38bd83f0 ] Since ndev->driver_data is allocated by devm_kzalloc(), we do not need the inappropriate kfree to free it in driver's remove function. Freeing will trigger when driver unloads. Cc: stable@vger.kernel.org Acked-by:
Firo Yang <firogm@gmail.com> Signed-off-by:
-
Felix Fietkau authored
[ Upstream commit 300f77c0 ] AR93xx and newer needs to stop rx before tx to avoid getting the DMA engine or MAC into a stuck state. This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam. Cc: stable@vger.kernel.org Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Marcel Holtmann authored
[ Upstream commit ecffc804 ] The SKB returned from the Intel specific version information command is missing a kfree_skb. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Frediano Ziglio authored
[ Upstream commit 8451cc96 ] If the function fails reference counter to the object is not decremented causing leaks. This is hard to spot as it happens only on very low memory situations. Signed-off-by:
Frediano Ziglio <fziglio@redhat.com> Cc: stable@vger.kernel.org Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Frediano Ziglio authored
[ Upstream commit 2fa19535 ] If objects are moved back from system memory to VRAM (and spice id created again) memory is already initialized so we need to set flag to not clear memory. If you don't do it after a while using desktop many images turns to black or transparents. Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit 1cf0f448 ] SOC_DAPM_SINGLE("Playback AMP", ..) should not be under kcontrols. It causes kernel crash (NULL pointer) when the mixers are listed. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit 80ba2669 ] If the card is not part of any card the tas_data->codec is NULL since it is set only during snd_soc_codec_driver.probe, which is not yet called. Signed-off-by:
-
Ludovic Desroches authored
[ Upstream commit ea25525c ] Mci0 uses slot 0 not 1. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Omar Sandoval authored
[ Upstream commit 64ad6c48 ] Since commit bafc9b75 ("vfs: More precise tests in d_invalidate"), mounted subvolumes can be deleted because d_invalidate() won't fail. However, we run into problems when we attempt to delete the default subvolume while it is mounted as the root filesystem: # btrfs subvol list / ID 257 gen 306 top level 5 path rootvol ID 267 gen 334 top level 5 path snap1 # btrfs subvol get-default / ID 267 gen 334 top level 5 path snap1 # btrfs inspect-internal rootid / 267 # mount -o subvol=/ /dev/vda1 /mnt # btrfs subvol del /mnt/snap1 Delete subvolume (no-commit): '/mnt/snap1' ERROR: cannot delete '/mnt/snap1' - Operation not permitted # findmnt / findmnt: can't read /proc/mounts: No such file or directory # ls /proc # Markus reported that this same scenario simply led to a kernel oops. This happens because in btrfs_ioctl_snap_destroy(), we call d_invalidate() before we check may_destroy_subvol(), which means that we detach the submounts and drop the dentry before erroring out. Instead, we should only invalidate the dentry once the deletion has succeeded. Additionally, the shrink_dcache_sb() isn't necessary; d_invalidate() will prune the dcache for the deleted subvolume. Cc: <stable@vger.kernel.org> Fixes: bafc9b75 ("vfs: More precise tests in d_invalidate") Reported-by:
Markus Schauler <mschauler@gmail.com> Signed-off-by:
Omar Sandoval <osandov@osandov.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Brian King authored
[ Upstream commit 45c44b5f ] Increase the default init stage change timeout from 15 seconds to 30 seconds. This resolves issues we have seen with some adapters not transitioning to the first init stage within 15 seconds, which results in adapter initialization failures. Cc: <stable@vger.kernel.org> Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
James Bottomley <JBottomley@Odin.com> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 88de6af2 ] req->rq_private_buf isn't initialised when xprt_setup_backchannel calls xprt_free_allocation. Fixes: fb7a0b9a ("nfs41: New backchannel helper routines") Cc: stable@vger.kernel.org Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Aaron Lu authored
[ Upstream commit 61e749d7 ] The CrystalCove GPIO irqchip doesn't have irq_set_wake callback defined so we should set IRQCHIP_SKIP_SET_WAKE for it or it would cause an irq desc's wake_depth unbalanced warning during system resume phase from the gpio_keys driver, which is the driver for the power button of the ASUS T100 laptop. Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Anton Blanchard authored
[ Upstream commit 72e349f1 ] When we take a PMU exception or a software event we call perf_read_regs(). This overloads regs->result with a boolean that describes if we should use the sampled instruction address register (SIAR) or the regs. If the exception is in kernel, we start with the kernel regs and backtrace through the kernel stack. At this point we switch to the userspace regs and backtrace the user stack with perf_callchain_user(). Unfortunately these regs have not got the perf_read_regs() treatment, so regs->result could be anything. If it is non zero, perf_instruction_pointer() decides to use the SIAR, and we get issues like this: 0.11% qemu-system-ppc [kernel.kallsyms] [k] _raw_spin_lock_irqsave | ---_raw_spin_lock_irqsave | |--52.35%-- 0 | | | |--46.39%-- __hrtimer_start_range_ns | | kvmppc_run_core | | kvmppc_vcpu_run_hv | | kvmppc_vcpu_run | | kvm_arch_vcpu_ioctl_run | | kvm_vcpu_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call | | | | | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum | | | | | | | --100.00%-- 0x7e714 | | | 0x7e714 Notice the bogus _raw_spin_irqsave when we transition from kernel (system_call) to userspace (0x7e714). We inserted what was in the SIAR. Add a check in regs_use_siar() to check that the regs in question are from a PMU exception. With this fix the backtrace makes sense: 0.47% qemu-system-ppc [kernel.vmlinux] [k] _raw_spin_lock_irqsave | ---_raw_spin_lock_irqsave | |--53.83%-- 0 | | | |--44.73%-- hrtimer_try_to_cancel | | kvmppc_start_thread | | kvmppc_run_core | | kvmppc_vcpu_run_hv | | kvmppc_vcpu_run | | kvm_arch_vcpu_ioctl_run | | kvm_vcpu_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call | | __ioctl | | 0x7e714 | | 0x7e714 Cc: stable@vger.kernel.org Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Dmitry Tunin authored
[ Upstream commit 4fa9dabc ] Lenovo G30-50 does not have a hardware wireless switch and wireless is always blocked. BugLink: https://bugs.launchpad.net/bugs/1397021Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Philippe Coval <philippe.coval@open.eurogiciel.org> [dvhart@linux.intel.com: Reordered dmi id per Phillippe's later version] Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Olga Kornievskaia authored
[ Upstream commit e8d975e7 ] Problem: When an operation like WRITE receives a BAD_STATEID, even though recovery code clears the RECLAIM_NOGRACE recovery flag before recovering the open state, because of clearing delegation state for the associated inode, nfs_inode_find_state_and_recover() gets called and it makes the same state with RECLAIM_NOGRACE flag again. As a results, when we restart looking over the open states, we end up in the infinite loop instead of breaking out in the next test of state flags. Solution: unset the RECLAIM_NOGRACE set because of calling of nfs_inode_find_state_and_recover() after returning from calling recover_open() function. Signed-off-by:
Olga Kornievskaia <kolga@netapp.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Malcolm Priestley authored
[ Upstream commit b5eeed8c ] There is a small chance that pRD->pRDInfo->skb could go NULL while the interrupt is processing. Put NULL check on loop to break out. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Robert Schlabbach authored
[ Upstream commit fb6d1f7d ] Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset. Dissolve the function hub_port_finish_reset() completely and divide the actions to be taken into those which need to be done after each reset attempt and those which need to be done after the full procedure is complete, and place them in the appropriate places in hub_port_reset(). Also, remove an unneeded forward declaration of hub_port_reset(). Verbose Problem Description: USB 3.0 devices may be "lost for good" during a hub port reset. This makes Linux unable to boot from USB 3.0 devices in certain constellations of host controllers and devices, because the USB device is lost during initialization, preventing the rootfs from being mounted. The underlying problem is that in the affected constellations, during the processing inside hub_port_reset(), the hub link state goes from 0 to SS.inactive after the initial reset, and back to 0 again only after the following "warm" reset. However, hub_port_finish_reset() is called after each reset attempt and sets the state the connected USB device based on the "preliminary" status of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when the following warm reset is complete and hub_port_finish_reset() is called again, its call to set the device to USB_STATE_DEFAULT is blocked by usb_set_device_state() which does not allow taking USB devices out of USB_STATE_NOTATTACHED state. Thanks to Alan Stern for guiding me to the proper solution and how to submit it. Link: http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27Signed-off-by:
Robert Schlabbach <robert_s@gmx.net> Cc: stable <stable@vger.kernel.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Haggai Eran authored
[ Upstream commit cab46214 ] With an RTL8191SU USB adaptor, sometimes the hints for a fragmented packet are set, but the packet length is too large. Allocate enough space to prevent memory corruption and a resulting kernel panic [1]. [1] http://www.spinics.net/lists/linux-wireless/msg136546.html Cc: <stable@vger.kernel.org> Signed-off-by:
Haggai Eran <haggai.eran@gmail.com> ACKed-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Felipe Balbi authored
[ Upstream commit e18b7975 ] In case of non-Isochronous transfers, we don't want to clear DWC3_EP_BUSY flag until XferComplete event. That's because XferInProgress was only enabled so we can recycle TRBs and usb_requests quicker, but there are still other pending requests being transferred. In order to make sure we don't allow for another StartTransfer command while the HW is still processing other transfers, we must keep DWC3_EP_BUSY flag set and this what this patch does. Fixes: f3af3651 (usb: dwc3: gadget: always enable IOC on bulk/interrupt transfers) Cc: <stable@vger.kernel.org> # v3.15+ Reported-by:
sundeep subbaraya <sundeep.lkml@gmail.com> Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Richard Fitzgerald authored
[ Upstream commit 15575ed5 ] The Arizona codec drivers had an incorrect dB scaling for the noise generator gain that started at 0dB and went upwards. Actually the highest setting is 0dB. Signed-off-by:
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by:
-
