- 14 Apr, 2014 40 commits
-
-
Eldad Zack authored
commit 5dae5fd2 upstream. Current code mishandles the case where the device is a UAC2 and the bDescriptorSubtype is a UAC2 Effect Unit (0x07). It tries to parse it as a Processing Unit (which is similar to two other UAC1 units with overlapping subtypes), but since the structure is different (See: 4.7.2.10, 4.7.2.11 in UAC2 standard), the parsing is done incorrectly and prevents the device from initializing. For now, just ignore the unit. Signed-off-by:
Eldad Zack <eldad@fogrefinery.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Weng Meiling <wengmeiling.weng@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Aaron Plattner authored
commit d52392b1 upstream. Vendor ID 0x10de0060 is used by a yet-to-be-named GPU chip. Reviewed-by:
Andy Ritger <aritger@nvidia.com> Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Signed-off-by:
-
Aaron Plattner authored
commit 7ae48b56 upstream. Vendor ID 0x10de0051 is used by a yet-to-be-named GPU chip. Signed-off-by:
Daniel Dadap <ddadap@nvidia.com> Signed-off-by:
-
Takashi Iwai authored
commit bddee96b upstream. When a selection to a converter MUX is changed in hdmi_pcm_open(), it should be cached so that the given connection can be restored properly at PM resume. We need just to replace the corresponding snd_hda_codec_write() call with snd_hda_codec_write_cache(). 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:
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:
-
Takashi Iwai authored
commit 638298dc upstream. Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show mysterious wakeups after shutdown occasionally. After discussing with BIOS engineers, they explained that the new BIOS expects that the wakeup sources are cleared and set to D3 for all wakeup devices when the system is going to sleep or power off, but the current xhci driver doesn't do this properly (partly intentionally). This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci shutdown ops as done in xhci_stop(), and setting the device to PCI D3 at shutdown and remove ops. The PCI D3 call is based on the initial fix patch by Oliver Neukum. [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names in them. Sarah also fixed a collision with a quirk submitted around the same time, by changing the xhci->quirks bit from 17 to 18.] This patch should be backported to kernels as old as 3.0, that contain the commit 1c12443a "xhci: Add Lynx Point to list of Intel switchable hosts." Cc: Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Oliver Neukum authored
commit 455f5892 upstream. It has been reported that this chipset really cannot sleep without this extraordinary delay. This patch should be backported, in order to ensure this host functions under stable kernels. The last quirk for Fresco Logic hosts (commit bba18e33 "xhci: Extend Fresco Logic MSI quirk.") was backported to stable kernels as old as 2.6.36. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Julius Werner authored
commit e92aee33 upstream. This patch adds the Port Reset Change flag to the set of bits that are preemptively cleared on init/resume of a hub. In theory this bit should never be set unexpectedly... in practice it can still happen if BIOS, SMM or ACPI code plays around with USB devices without cleaning up correctly. This is especially dangerous for XHCI root hubs, which don't generate any more Port Status Change Events until all change bits are cleared, so this is a good precaution to have (similar to how it's already done for the Warm Port Reset Change flag). Signed-off-by:
Julius Werner <jwerner@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
James Ralston authored
commit 9f961a5f upstream. This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Sarah Sharp authored
commit f217c980 upstream. The RWE bit of the USB 2.0 PORTPMSC register is supposed to enable remote wakeup for devices in the lower power link state L1. It has nothing to do with the device suspend remote wakeup from L2. The RWE bit is designed to be set once (when USB 2.0 LPM is enabled for the port) and cleared only when USB 2.0 LPM is disabled for the port. The xHCI bus suspend method was setting the RWE bit erroneously, and the bus resume method was clearing it. The xHCI 1.0 specification with errata up to Aug 12, 2012 says in section 4.23.5.1.1.1 "Hardware Controlled LPM": "While Hardware USB2 LPM is enabled, software shall not modify the HIRDBESL or RWE fields of the USB2 PORTPMSC register..." If we have previously enabled USB 2.0 LPM for a device, that means when the USB 2.0 bus is resumed, we violate the xHCI specification by clearing RWE. It also means that after a bus resume, the host would think remote wakeup is disabled from L1 for ports with USB 2.0 Link PM enabled, which is not what we want. This patch should be backported to kernels as old as 3.2, that contain the commit 65580b43 "xHCI: set USB2 hardware LPM". That was the first kernel that supported USB 2.0 Link PM. Signed-off-by:
-
Seth Heasley authored
commit 1cfc7df3 upstream. This patch adds the AHCI-mode SATA DeviceIDs for the Intel Coleto Creek PCH. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
-
James Ralston authored
commit 151743fd upstream. This patch adds the AHCI-mode SATA Device IDs for the Intel Wellsburg PCH Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Colin Leitner authored
commit 8704211f upstream. FTDI UARTs support only 7 or 8 data bits. Until now the ftdi_sio driver would only report this limitation for CS6 to dmesg and fail to reflect this fact to tcgetattr. This patch reverts the unsupported CSIZE setting and reports the fact with less severance to dmesg for both CS5 and CS6. To test the patch it's sufficient to call stty -F /dev/ttyUSB0 cs5 which will succeed without the patch and report an error with the patch applied. As an additional fix this patch ensures that the control request will always include a data bit size. Signed-off-by:
Colin Leitner <colin.leitner@gmail.com> Signed-off-by:
Johan Hovold <jhovold@gmail.com> [bwh: Backported to 3.2: - Old code is cosmetically different - s/ddev/\&port->dev/] Signed-off-by:
-
Thomas Pugliese authored
commit f74b75e7 upstream. change WA_SEGS_MAX to a number that is legal according to the WUSB spec. Signed-off-by:
Thomas Pugliese <thomas.pugliese@gmail.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Thomas Pugliese authored
commit 7b6bc07a upstream. For isochronous endpoints, set the RPIPE wMaxPacketSize value using wOverTheAirPacketSize from the endpoint companion descriptor instead of wMaxPacketSize from the normal endpoint descriptor. Signed-off-by:
-
David Cohen authored
commit 85601f8c upstream. Add PCI id for Intel Merrifield Signed-off-by:
David Cohen <david.a.cohen@linux.intel.com> Signed-off-by:
-
Heikki Krogerus authored
commit b62cd96d upstream. Add PCI id for Intel BayTrail. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Cc: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Sarah Sharp authored
commit dcc01c08 upstream. Before the USB core resets a device, we need to disable the L1 timeout for the roothub, if USB 2.0 Link PM is enabled. Otherwise the port may transition into L1 in between descriptor fetches, before we know if the USB device descriptors changed. LPM will be re-enabled after the full device descriptors are fetched, and we can confirm the device still supports USB 2.0 LPM after the reset. We don't need to wait for the USB device to exit L1 before resetting the device, since the xHCI roothub port diagrams show a transition to the Reset state from any of the Ux states (see Figure 34 in the 2012-08-14 xHCI specification update). This patch should be backported to kernels as old as 3.2, that contain the commit 65580b43 "xHCI: set USB2 hardware LPM". That was the first commit to enable USB 2.0 hardware-driven Link Power Management. Signed-off-by:
-
Alan Stern authored
commit f875fdbf upstream. Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm field in their pci_driver structures should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. The corresponding change has already been made for ohci-hcd. Without this change, controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by:
-
Alan Stern authored
commit 9d892429 upstream. This patch fixes a build error that occurs when CONFIG_PM is enabled and CONFIG_PM_SLEEP isn't: >> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function) .pm = &usb_hcd_pci_pm_ops Since the usb_hcd_pci_pm_ops structure is defined and used when CONFIG_PM is enabled, its declaration should not be protected by CONFIG_PM_SLEEP. Signed-off-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Alan Stern authored
commit 69820e01 upstream. Since ohci-hcd supports runtime PM, the .pm field in its pci_driver structure should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. Without this change, OHCI controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by:
-
Johan Hovold authored
commit ff8a43c1 upstream. Make sure to fail properly if the device is not accepted during attach in order to avoid null-pointer derefs (of missing interface private data) at disconnect or release. Signed-off-by:
-
Johan Hovold authored
commit e877dd2f upstream. Fix endianess bugs in firmware handling introduced by commits cb7a7c6a ("ti_usb_3410_5052: add Multi-Tech modem support") and 05a3d905 ("ti_usb_3410_5052: support alternate firmware") which made the driver use the wrong firmware for certain devices on big-endian machines. Signed-off-by:
-
Johan Hovold authored
commit d482b9d5 upstream. Make sure the reported device-type on big-endian machines is the same as on little-endian ones. Signed-off-by:
-
Johan Hovold authored
commit d8a083cc upstream. Fix race in mos7840_get_reg which unconditionally manipulated the control urb (which may already be in use) by adding a control-urb busy flag. Signed-off-by:
-
Johan Hovold authored
commit 5f8a2e68 upstream. Allocated urbs and buffers were never freed on errors in open. Signed-off-by:
-
Johan Hovold authored
commit 2d8f4447 upstream. Do not use uninitialised termios data to determine when to configure the device at open. This also prevents stack data from leaking to userspace in the OOM error path. Signed-off-by:
-
Johan Hovold authored
commit 5e4211f1 upstream. Do not use uninitialised termios data to determine when to configure the device at open. Signed-off-by:
-
Richard Weinberger authored
commit 8a2f132a upstream. The Option GTM681W uses a qualcomm chip and can be served by the qcserial device driver. Signed-off-by:
Richard Weinberger <richard@nod.at> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
George Cherian authored
commit 5bf8fae3 upstream. we never allocate a TRB pool for physical endpoints 0 and 1 so trying to free it (a invalid TRB pool pointer) will lead us in a warning while removing dwc3.ko module. In order to fix the situation, all we have to do is skip dwc3_free_trb_pool() for physical endpoints 0 and 1 just as we while deleting endpoints from the endpoints list. Signed-off-by:
George Cherian <george.cherian@ti.com> Signed-off-by:
-
Adrian Thomasset authored
commit 71d9a2b9 upstream. The FT4232H used in the ST Micro Connect Lite has four hi-speed UART ports. The first two ports are reserved for the JTAG interface. We enable by default ports 2 and 3 as UARTs (where port 2 is a conventional RS-232 UART) Signed-off-by:
Adrian Thomasset <adrian.thomasset@st.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Ming Lei authored
commit eba0e3c3 upstream. Johan's 'fix use-after-free in TIOCMIWAIT' patchset[1] introduces one bug which can cause kernel hang when opening port. This patch initialized the 'port->delta_msr_wait' waitqueue head to fix the bug which is introduced in 3.9-rc4. [1], http://marc.info/?l=linux-usb&m=136368139627876&w=2Signed-off-by:
Ming Lei <tom.leiming@gmail.com> Acked-by:
-
Johan Hovold authored
commit 3668b9c1 upstream. commit fc98ab87 upstream. Use the port wait queue and make sure to check the serial disconnected flag before accessing private port data after waking up. This is is needed as the private port data (including the wait queue itself) can be gone when waking up after a disconnect. Signed-off-by:
-
Johan Hovold authored
commit 43a66b4c upstream. Use the port wait queue and make sure to check the serial disconnected flag before accessing private port data after waking up. This is is needed as the private port data (including the wait queue itself) can be gone when waking up after a disconnect. Signed-off-by:
-
Johan Hovold authored
commit d1baabc8 upstream. commit dbcea761 upstream. Use the port wait queue and make sure to check the serial disconnected flag before accessing private port data after waking up. This is is needed as the private port data (including the wait queue itself) can be gone when waking up after a disconnect. Signed-off-by:
-
Johan Hovold authored
commit 40509ca9 upstream. Use the port wait queue and make sure to check the serial disconnected flag before accessing private port data after waking up. This is is needed as the private port data (including the wait queue itself) can be gone when waking up after a disconnect. Signed-off-by:
-
Johan Hovold authored
commit 8edfdab3 upstream. Use the port wait queue and make sure to check the serial disconnected flag before accessing private port data after waking up. This is is needed as the private port data (including the wait queue itself) can be gone when waking up after a disconnect. Signed-off-by:
-
Johan Hovold authored
commit a14430db upstream. Use the port wait queue and make sure to check the serial disconnected flag before accessing private port data after waking up. This is is needed as the private port data (including the wait queue itself) can be gone when waking up after a disconnect. Signed-off-by:
-
Johan Hovold authored
commit e670c6af upstream. Make sure waiting processes are woken on modem-status changes. Currently processes are only woken on termios changes regardless of whether the modem status has changed. Signed-off-by:
-
Johan Hovold authored
commit cf1d2444 upstream. Use the port wait queue and make sure to check the serial disconnected flag before accessing private port data after waking up. This is is needed as the private port data (including the wait queue itself) can be gone when waking up after a disconnect. Signed-off-by:
-
