1. 29 2月, 2012 7 次提交
  2. 25 2月, 2012 25 次提交
  3. 22 2月, 2012 6 次提交
    • B
      USB: Added Kamstrup VID/PIDs to cp210x serial driver. · c6c1e449
      Bruno Thomsen 提交于
      Signed-off-by: NBruno Thomsen <bruno.thomsen@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6c1e449
    • A
      USB: Serial: ti_usb_3410_5052: Add Abbot Diabetes Care cable id · 7fd25702
      Andrew Lunn 提交于
      This USB-serial cable with mini stereo jack enumerates as:
      Bus 001 Device 004: ID 1a61:3410 Abbott Diabetes Care
      
      It is a TI3410 inside.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fd25702
    • A
      usb-storage: fix freezing of the scanning thread · bb94a406
      Alan Stern 提交于
      This patch (as1521b) fixes the interaction between usb-storage's
      scanning thread and the freezer.  The current implementation has a
      race: If the device is unplugged shortly after being plugged in and
      just as a system sleep begins, the scanning thread may get frozen
      before the khubd task.  Khubd won't be able to freeze until the
      disconnect processing is complete, and the disconnect processing can't
      proceed until the scanning thread finishes, so the sleep transition
      will fail.
      
      The implementation in the 3.2 kernel suffers from an additional
      problem.  There the scanning thread calls set_freezable_with_signal(),
      and the signals sent by the freezer will mess up the thread's I/O
      delays, which are all interruptible.
      
      The solution to both problems is the same: Replace the kernel thread
      used for scanning with a delayed-work routine on the system freezable
      work queue.  Freezable work queues have the nice property that you can
      cancel a work item even while the work queue is frozen, and no signals
      are needed.
      
      The 3.2 version of this patch solves the problem in Bugzilla #42730.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NSeth Forshee <seth.forshee@canonical.com>
      CC: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bb94a406
    • S
      xhci: Fix encoding for HS bulk/control NAK rate. · 340a3504
      Sarah Sharp 提交于
      The xHCI 0.96 spec says that HS bulk and control endpoint NAK rate must
      be encoded as an exponent of two number of microframes.  The endpoint
      descriptor has the NAK rate encoded in number of microframes.  We were
      just copying the value from the endpoint descriptor into the endpoint
      context interval field, which was not correct.  This lead to the VIA
      host rejecting the add of a bulk OUT endpoint from any USB 2.0 mass
      storage device.
      
      The fix is to use the correct encoding.  Refactor the code to convert
      number of frames to an exponential number of microframes, and make sure
      we convert the number of microframes in HS bulk and control endpoints to
      an exponent.
      
      This should be back ported to kernels as old as 2.6.31, that contain the
      commit dfa49c4a "USB: xhci - fix math
      in xhci_get_endpoint_interval"
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NFelipe Contreras <felipe.contreras@gmail.com>
      Suggested-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: stable@vger.kernel.org
      340a3504
    • E
      USB: Set hub depth after USB3 hub reset · a45aa3b3
      Elric Fu 提交于
      The superspeed device attached to a USB 3.0 hub(such as VIA's)
      doesn't respond the address device command after resume. The
      root cause is the superspeed hub will miss the Hub Depth value
      that is used as an offset into the route string to locate the
      bits it uses to determine the downstream port number after
      reset, and all packets can't be routed to the device attached
      to the superspeed hub.
      
      Hub driver sends a Set Hub Depth request to the superspeed hub
      except for USB 3.0 root hub when the hub is initialized and
      doesn't send the request again after reset due to the resume
      process. So moving the code that sends the Set Hub Depth request
      to the superspeed hub from hub_configure() to hub_activate()
      is to cover those situations include initialization and reset.
      
      The patch should be backported to kernels as old as 2.6.39.
      Signed-off-by: NElric Fu <elricfu1@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable@vger.kernel.org
      a45aa3b3
    • S
      USB: Fix handoff when BIOS disables host PCI device. · cab928ee
      Sarah Sharp 提交于
      On some systems with an Intel Panther Point xHCI host controller, the
      BIOS disables the xHCI PCI device during boot, and switches the xHCI
      ports over to EHCI.  This allows the BIOS to access USB devices without
      having xHCI support.
      
      The downside is that the xHCI BIOS handoff mechanism will fail because
      memory mapped I/O is not enabled for the disabled PCI device.
      Jesse Barnes says this is expected behavior.  The PCI core will enable
      BARs before quirks run, but it will leave it in an undefined state, and
      it may not have memory mapped I/O enabled.
      
      Make the generic USB quirk handler call pci_enable_device() to re-enable
      MMIO, and call pci_disable_device() once the host-specific BIOS handoff
      is finished.  This will balance the ref counts in the PCI core.  When
      the PCI probe function is called, usb_hcd_pci_probe() will call
      pci_enable_device() again.
      
      This should be back ported to kernels as old as 2.6.31.  That was the
      first kernel with xHCI support, and no one has complained about BIOS
      handoffs failing due to memory mapped I/O being disabled on other hosts
      (EHCI, UHCI, or OHCI).
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NOliver Neukum <oneukum@suse.de>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: stable@vger.kernel.org
      cab928ee
  4. 16 2月, 2012 1 次提交
    • F
      usb: host: ehci: allow ehci_* symbols to be unused · 5407a3c3
      Felipe Balbi 提交于
      not all platforms will use all of those ehci_*
      symbols on their hc_driver structure. Sometimes
      we might need to provide a modified version of
      a certain method or not provide it at all, as is
      the case with OMAPs which don't support port handoff
      feature.
      
      Whenever we compile a kernel for an OMAP board with
      EHCI enabled, we get compile warnings:
      
      drivers/usb/host/ehci-hub.c:1079: warning: 'ehci_relinquish_port' \
      	defined but not used
      drivers/usb/host/ehci-hub.c:1088: warning: 'ehci_port_handed_over' \
      	defined but not used
      
      In order to cleanup those warnings, we're adding
      __maybe_unused annotation to those functions.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5407a3c3
  5. 15 2月, 2012 1 次提交