1. 03 Oct, 2014 1 commit
  2. 01 Aug, 2014 10 commits
  3. 23 Jul, 2014 1 commit
  4. 22 Jul, 2014 5 commits
    • Wei Yongjun's avatar
      usb: chipidea: debug: fix sparse non static symbol warnings · df40f8d3
      Wei Yongjun authored
      Fixes the following sparse warnings:
      drivers/usb/chipidea/debug.c:211:5: warning:
       symbol 'ci_otg_show' was not declared. Should it be static?
      drivers/usb/chipidea/debug.c:334:5: warning:
       symbol 'ci_registers_show' was not declared. Should it be static?
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Markus Pargmann's avatar
      usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY · 16853d7b
      Markus Pargmann authored
      -ENODEV is interpreted by the generic driver probing function as a
      non-matching driver. This leads to a missing probe failure message.
      Also a missing USB PHY is more of an invalid configuration of the usb
      driver because it is necessary.
      This patch returns -EINVAL if devm_usb_get_phy_by_phandle() returned -ENODEV.
      Signed-off-by: default avatarMarkus Pargmann <mpa@pengutronix.de>
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Amit Virdi's avatar
      usb: core: allow zero packet flag for interrupt urbs · 9672f0fe
      Amit Virdi authored
      Section "Interrupt Transfer Bandwidth Requirements" of the USB3.0 spec
      	A zero-length data payload is a valid transfer and may be useful for
      	some implementations.
      So, extend the logic of allowing URB_ZERO_PACKET to interrupt urbs too.
      Otherwise, the kernel throws warning of BOGUS transfer flags.
      Signed-off-by: default avatarAmit Virdi <amit.virdi@st.com>
      Acked-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Pratyush Anand's avatar
      usb: lvstest: Fix sparse warnings generated by kbuild test bot · b1bd3f1a
      Pratyush Anand authored
      Following sparse warnings were reported by kbuild test bot
      drivers/usb/misc/lvstest.c:314:28: sparse: incorrect type in assignment (different base types)
         drivers/usb/misc/lvstest.c:314:28:    expected unsigned short [unsigned] [usertype] portchange
         drivers/usb/misc/lvstest.c:314:28:    got restricted __le16 [usertype] wPortChange
      drivers/usb/misc/lvstest.c:332:40: sparse: restricted __le16 degrades to integer
      This patch fixes above warnings.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jiang Liu's avatar
      USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down · c5946f9d
      Jiang Liu authored
      The assigned IRQ should be freed before calling pci_disable_device()
      when shutting down system, otherwise it will cause following warning.
      [  568.879482] ------------[ cut here ]------------
      [  568.884236] WARNING: CPU: 1 PID: 3300 at /home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521 remove_proc_entry+0x165/0x170()
      [  568.897846] remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'ohci_hcd:usb4'
      [  568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge r8169 libata mii scsi_mod wmi acpi_cpufreq
      [  568.938539] CPU: 1 PID: 3300 Comm: init Tainted: G        W     3.16.0-rc5upstream-01651-g03b9189 #1
      [  568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015  04/01/2010
      [  568.956008]  00000209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f c1754084 ed0f1d2c
      [  568.964068]  00000ce4 c175403c 00000209 c11f22a5 c11f22a5 f755e8c0 ed0f1d78 f755e90d
      [  568.972128]  ed0f1d18 c1090cde 00000009 ed0f1d10 c1754084 ed0f1d2c ed0f1d60 c11f22a5
      [  568.980194] Call Trace:
      [  568.982715]  [<c1617946>] dump_stack+0x48/0x60
      [  568.987294]  [<c1090c3f>] warn_slowpath_common+0x7f/0xa0
      [  569.003887]  [<c1090cde>] warn_slowpath_fmt+0x2e/0x30
      [  569.009092]  [<c11f22a5>] remove_proc_entry+0x165/0x170
      [  569.014476]  [<c10da6ca>] unregister_irq_proc+0xaa/0xc0
      [  569.019858]  [<c10d582f>] free_desc+0x1f/0x60
      [  569.024346]  [<c10d58aa>] irq_free_descs+0x3a/0x80
      [  569.029283]  [<c10d9e9d>] irq_dispose_mapping+0x2d/0x50
      [  569.034666]  [<c1078fd3>] mp_unmap_irq+0x73/0xa0
      [  569.039423]  [<c107196b>] acpi_unregister_gsi_ioapic+0x2b/0x40
      [  569.045431]  [<c107180f>] acpi_unregister_gsi+0xf/0x20
      [  569.050725]  [<c1339cad>] acpi_pci_irq_disable+0x4b/0x50
      [  569.056196]  [<c14daa38>] pcibios_disable_device+0x18/0x20
      [  569.061848]  [<c130123d>] do_pci_disable_device+0x4d/0x60
      [  569.067410]  [<c13012b7>] pci_disable_device+0x47/0xb0
      [  569.077814]  [<c14800b1>] usb_hcd_pci_shutdown+0x31/0x40
      [  569.083285]  [<c1304b19>] pci_device_shutdown+0x19/0x50
      [  569.088667]  [<c13fda64>] device_shutdown+0x14/0x120
      [  569.093777]  [<c10ac29d>] kernel_restart_prepare+0x2d/0x30
      [  569.099429]  [<c10ac41e>] kernel_restart+0xe/0x60
      [  569.109028]  [<c10ac611>] SYSC_reboot+0x191/0x220
      [  569.159269]  [<c10ac6ba>] SyS_reboot+0x1a/0x20
      [  569.163843]  [<c161c718>] sysenter_do_call+0x12/0x16
      [  569.168951] ---[ end trace ccc1ec4471c289c9 ]---
      Tested-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Reviewed-by: default avatarHuang Rui <ray.huang@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 18 Jul, 2014 9 commits
    • Alan Stern's avatar
      USB: OHCI: add check for stopped frame counter · 499b3803
      Alan Stern authored
      This patch adds an extra check to ohci-hcd's I/O watchdog routine.  If
      the controller stops updating the frame counter, we will assume it is
      dead.  But there has to be an exception: Some controllers stop the
      frame counter when no ports are connected.  Check to make sure there
      is at least one active port before deciding the controller is dead.
      (This test may appear racy, but it isn't.  Enabling a newly connected
      port takes several milliseconds, during which time the frame counter
      must advance.)
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarDennis New <dennisn@dennisn.linuxd.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: add I/O watchdog for orphan TDs · 81e38333
      Alan Stern authored
      Some OHCI controllers have a bug: They fail to add completed TDs to
      the done queue.  Examining this queue is the only method ohci-hcd has
      for telling when a transfer is complete; failure to add a TD can
      result in an URB that never completes and cannot be unlinked.
      This patch adds a watchdog routine to ohci-hcd.  The routine
      periodically scans the active ED and TD lists, looking for TDs which
      are finished but not on the done queue.  When one is found, and it is
      certain that the controller hardware will never add the TD to the done
      queue, the watchdog routine manually puts the TD on the done list so
      that it can be handled normally.
      The watchdog routine also checks for a condition indicating the
      controller has died.  If the done queue is non-empty but the
      HccaDoneHead pointer hasn't been updated for a few hundred
      milliseconds, we assume the controller will never update it and
      therefore is dead.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: make URB completions single-threaded · cdb4dd15
      Alan Stern authored
      URBs for a particular endpoint should complete sequentially.  That is,
      we shouldn't call the completion handler for one URB until the handler
      for the previous URB has returned.
      When the OHCI watchdog routine is added, there will be two paths for
      completing URBs: interrupt handler and watchdog routine.  Their
      activities have to be synchronized so that completions don't occur in
      multiple threads concurrently.
      For that purpose, this patch creates an ohci_work() routine which will
      be responsible for calling process_done_list() and finish_unlinks(),
      the two routines that detect when an URB is complete.  Everything will
      funnel through ohci_work(), and it will be careful not to run in more
      than one thread at a time.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: redesign the TD done list · c6fcb85e
      Alan Stern authored
      This patch changes the way ohci-hcd handles the TD done list.  In
      addition to relying on the TD pointers stored by the controller
      hardware, we need to handle TDs that the hardware has forgotten about.
      This means the list has to exist even while the dl_done_list() routine
      isn't running.  That function essentially gets split in two:
      update_done_list() reads the TD pointers stored by the hardware and
      adds the TDs to the done list, and process_done_list() scans through
      the list to handle URB completions.  When we detect a TD that the
      hardware forgot about, we will be able to add it to the done list
      manually and then process it normally.
      Since the list is really a queue, and because there can be a lot of
      TDs, keep the existing singly linked implementation.  To insure that
      URBs are given back in order of submission, whenever a TD is added to
      the done list, all the preceding TDs for the same endpoint must be
      added as well (going back to the first one that isn't already on the
      done list).
      The done list manipulations must all be protected by the private
      lock.  The scope of the lock is expanded in preparation for the
      watchdog routine to be added in a later patch.
      We have to be more careful about giving back unlinked URBs.  Since TDs
      may be added to the done list by the watchdog routine and not in
      response to a controller interrupt, we have to check explicitly to
      make sure all the URB's TDs that were added to the done list have been
      processed before giving back the URB.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: no shortcut for unlinking URBS from a dead controller · 8b3ab0ed
      Alan Stern authored
      When an URB is unlinked from a dead controller, ohci-hcd gives back
      the URB with no regard for cleaning up the internal data structures.
      This won't play nicely with the upcoming changes to the TD done
      Therefore make ohci_urb_dequeue() call finish_unlinks(), which uses
      td_done() to do a proper cleanup, rather than calling finish_urb()
      directly.  Also, remove the checks that urb_priv is non-NULL; the
      driver guarantees that urb_priv will never be NULL for a valid URB.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: revert the ZF Micro orphan-TD quirk · 95d9a01d
      Alan Stern authored
      This patch reverts the important parts of commit 89a0fd18
      OHCI handles more ZFMicro quirks), namely, the parts related to
      handling orphan TDs for interrupt endpoints.  A later patch in this
      series will introduce a more general mechanism that applies to all
      endpoint types and all controllers.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Pratyush Anand's avatar
      USB: Fix persist resume of some SS USB devices · a40178b2
      Pratyush Anand authored
      Problem Summary: Problem has been observed generally with PM states
      where VBUS goes off during suspend. There are some SS USB devices which
      take longer time for link training compared to many others.  Such
      devices fail to reconnect with same old address which was associated
      with it before suspend.
      When system resumes, at some point of time (dpm_run_callback->
      usb_port_resume) SW reads hub status. If device is present,
      then it finishes port resume and re-enumerates device with same
      address. If device is not present then, SW thinks that device was
      removed during suspend and therefore does logical disconnection
      and removes all the resource allocated for this device.
      Now, if I put sufficient delay just before root hub status read in
      usb_resume_device then, SW sees always that device is present. In normal
      course(without any delay) SW sees that no device is present and then SW
      removes all resource associated with the device at this port.  In the
      latter case, after sometime, device says that hey I am here, now host
      enumerates it, but with new address.
      Problem had been reproduced when I connect verbatim USB3.0 hard disc
      with my STiH407 XHCI host running with 3.10 kernel.
      I see that similar problem has been reported here.
      Reading above it seems that bug was not in 3.6.6 and was present in 3.8
      and again it was not present for some in 3.12.6, while it was present
      for few others. I tested with 3.13-FC19 running at i686 desktop, problem
      was still there. However, I was failed to reproduce it with 3.16-RC4
      running at same i686 machine. I would say it is just a random
      observation. Problem for few devices is always there, as I am unable to
      find a proper fix for the issue.
      So, now question is what should be the amount of delay so that host is
      always able to recognize suspended device after resume.
      XHCI specs 4.19.4 says that when Link training is successful, port sets
      CSC bit to 1. So if SW reads port status before successful link
      training, then it will not find device to be present.  USB Analyzer log
      with such buggy devices show that in some cases device switch on the
      RX termination after long delay of host enabling the VBUS. In few other
      cases it has been seen that device fails to negotiate link training in
      first attempt. It has been reported till now that few devices take as
      long as 2000 ms to train the link after host enabling its VBUS and
      RX termination. This patch implements a 2000 ms timeout for CSC bit to set
      ie for link training. If in a case link trains before timeout, loop will
      exit earlier.
      This patch implements above delay, but only for SS device and when
      persist is enabled.
      So, for the good device overhead is almost none. While for the bad
      devices penalty could be the time which it take for link training.
      But, If a device was connected before suspend, and was removed
      while system was asleep, then the penalty would be the timeout ie
      2000 ms.
      Verbatim USB SS hard disk connected with STiH407 USB host running 3.10
      Kernel resumes in 461 msecs without this patch, but hard disk is
      assigned a new device address. Same system resumes in 790 msecs with
      this patch, but with old device address.
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarPratyush Anand <pratyush.anand@st.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nicholas Krause's avatar
      usb-core: Remove Fix mes in file hcd.c · 1c094728
      Nicholas Krause authored
      I am removing two fix mes in this file as after dicussing then it  seems
      there is no reason to check against Null for usb_device as it can never
      be NULL and this is check is therefore not needed.
      Signed-off-by: default avatarNicholas Krause <xerofoify@gmail.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Oliver Neukum's avatar
      usbcore: don't log on consecutive debounce failures of the same port · 5ee0f803
      Oliver Neukum authored
      Some laptops have an internal port for a BT device which picks
      up noise when the kill switch is used, but not enough to trigger
      printk_rlimit(). So we shouldn't log consecutive faults of this kind.
      Signed-off-by: default avatarOliver Neukum <oneukum@suse.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 17 Jul, 2014 11 commits
    • Gavin Guo's avatar
      usb: Check if port status is equal to RxDetect · bb86cf56
      Gavin Guo authored
      When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller
      [1022:7814], the second hotplugging will experience the USB 3.0 pen
      drive is recognized as high-speed device. After bisecting the kernel,
      I found the commit number 41e7e056
      (USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing
      some experiments, the bug can be fixed by avoiding executing the function
      hub_usb3_port_disable(). Because the port status with [AMD] FCH USB
      XHCI Controlleris [1022:7814] is already in RxDetect
      (I tried printing out the port status before setting to Disabled state),
      it's reasonable to check the port status before really executing
      Fixes: 41e7e056
       (USB: Allow USB 3.0 ports to be disabled.)
      Signed-off-by: default avatarGavin Guo <gavin.guo@canonical.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Preston Fick's avatar
      USB: serial: cp210x: Removing unncessary `usb_reset_device` on startup · 934ef5ac
      Preston Fick authored
      This `usb_reset_device` command has been around since the driver was
      originally reverse engineered. It doesn't cause much issue on single
      interface CP210x devices, but on the CP2105 and CP2108 with 2 and 4
      interfaces respectively it will cause instability on enumeration and
      delays enumeration noticably. There should be no reason to reset a device
      at startup, per the CP210x AN571 spec.
      Signed-off-by: default avatarPreston Fick <preston.fick@silabs.com>
      Cc: Johan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Pratyush Anand's avatar
      USB: Add LVS Test device driver · ce21bfe6
      Pratyush Anand authored
      OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
      system (SS-OVS) which consists of an excersizer and analyzer.
      USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
      Link Layer Validation (LVS).
      Some modifications are needed for an embedded Linux USB host to pass all
      these tests.  Most of these tests require just Link to be in U0. They do
      not work with default Linux USB stack since, default stack does port
      reset and then starts sending setup packet, which is not expected by
      Link Layer Validation (LVS) device of Lecroy Compliance Suit.  Then,
      There are many Link Layer Tests which need host to generate specific
      This patch supports specific traffic generation cases. As of now all the
      host Lecroy Link Layer-USBIF tests (except TD7.26) passes
      with this patch for single run using  Lecroy USB Compliance Suite
      Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
      Build 1603. Therefore patch seems to be a good candidate for inclusion.
      Further modification can be done on top of it.
      lvstest driver will not bind to any device by default. It can bind
      manually to a super speed USB host controller root hub. Therefore, regular
      hub driver must be unbound before this driver is bound. For example, if
      2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.
       echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind
      Then write Linux Foundation's vendor ID which is used by root hubs and
      SS root hub's device ID into new_id file. Writing IDs into new_id file
      will also bind the lvs driver with any available SS root hub interfaces.
       echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id
      Now connect LVS device with root hub port.
      Test case specific traffic can be generated as follows whenever needed:
      1. To issue "Get Device descriptor" command for TD.7.06:
       echo  > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc
      2. To set U1 timeout to 127 for TD.7.18
       echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout
      3. To set U2 timeout to 0 for TD.7.18
       echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout
      4. To issue "Hot Reset" for TD.7.29
       echo  > /sys/bus/usb/devices/2-0\:1.0/hot_reset
      5. To issue "U3 Entry" for TD.7.35
       echo  > /sys/bus/usb/devices/2-0\:1.0/u3_entry
      6. To issue "U3 Exit" for TD.7.36
       echo  > /sys/bus/usb/devices/2-0\:1.0/u3_exit
      Signed-off-by: default avatarPratyush Anand <pratyush.anand@st.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Pratyush Anand's avatar
      USB: Add EXPORT_SYMBOL for usb_alloc_dev · caa67a5e
      Pratyush Anand authored
      usb_alloc_dev is used by lvstest driver now which can be built as
      module. Therefore export usb_alloc_dev symbol.
      Signed-off-by: default avatarPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: don't lose track of EDs when a controller dies · 977dcfdc
      Alan Stern authored
      This patch fixes a bug in ohci-hcd.  When an URB is unlinked, the
      corresponding Endpoint Descriptor is added to the ed_rm_list and taken
      off the hardware schedule.  Once the ED is no longer visible to the
      hardware, finish_unlinks() handles the URBs that were unlinked or have
      completed.  If any URBs remain attached to the ED, the ED is added
      back to the hardware schedule -- but only if the controller is
      This fails when a controller dies.  A non-empty ED does not get added
      back to the hardware schedule and does not remain on the ed_rm_list;
      ohci-hcd loses track of it.  The remaining URBs cannot be unlinked,
      which causes the USB stack to hang.
      The patch changes finish_unlinks() so that non-empty EDs remain on
      the ed_rm_list if the controller isn't running.  This requires moving
      some of the existing code around, to avoid modifying the ED's hardware
      fields more than once.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: fix bugs in debug routines · 256dbcd8
      Alan Stern authored
      The debug routine fill_async_buffer() in ohci-hcd is buggy: It never
      produces any output because it forgets to initialize the output buffer
      size.  Also, the debug routine ohci_dump() has an unused argument.
      This patch adds the correct initialization and removes the unused
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: OHCI: add SG support · 6f65126c
      Alan Stern authored
      Apparently nobody ever remembered to add Scatter-Gather support to
      ohci-hcd.  This patch adds it.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Alan Stern's avatar
      USB: shutdown all URBs after controller death · 1299cff9
      Alan Stern authored
      When a host controller dies, we don't need to wait for a driver to
      time out.  We can shut down its URBs immediately.  Without this
      change, we can end up waiting 30 seconds for a mass-storage transfer
      to time out.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Abbas Raza's avatar
      usb: chipidea: udc: Disable auto ZLP generation on ep0 · 953c6646
      Abbas Raza authored
      There are 2 methods for ZLP (zero-length packet) generation:
      1) In software
      2) Automatic generation by device controller
      1) is implemented in UDC driver and it attaches ZLP to IN packet if
         descriptor->size < wLength
      2) can be enabled/disabled by setting ZLT bit in the QH
      When gadget ffs is connected to ubuntu host, the host sends
      get descriptor request and wLength in setup packet is 255 while the
      size of descriptor which will be sent by gadget in IN packet is
      64 byte. So the composite driver sets req->zero = 1.
      In UDC driver following code will be executed then
              if (hwreq->req.zero && hwreq->req.length
                  && (hwreq->req.length % hwep->ep.maxpacket == 0))
                      add_td_to_list(hwep, hwreq, 0);
      So in case of ubuntu host, UDC driver will attach a ZLP to the IN packet.
      ubuntu host will request 255 byte in IN request, gadget will send 64 byte
      with ZLP and host will come to know that there is no more data.
      But hold on, by default ZLT=0 for endpoint 0 so hardware also tries to
      automatically generate the ZLP which blocks enumeration for ~6 seconds due
      to endpoint 0 STALL, NAKs are sent to host for any requests (OUT/PING)
      In case when gadget ffs is connected to Apple device, Apple device sends
      setup packet with wLength=64. So descriptor->size = 64 and wLength=64
      therefore req->zero = 0 and UDC driver will not attach any ZLP to the
      IN packet. Apple device requests 64 bytes, gets 64 bytes and doesn't
      further request for IN data. But ZLT=0 by default for endpoint 0 so
      hardware tries to automatically generate the ZLP which blocks enumeration
      for ~6 seconds due to endpoint 0 STALL, NAKs are sent to host for any
      requests (OUT/PING)
      According to USB2.0 specs:
 Variable-length Data Stage
          A control pipe may have a variable-length data phase in which the
          host requests more data than is contained in the specified data
          structure. When all of the data structure is returned to the host,
          the function should indicate that the Data stage is ended by
          returning a packet that is shorter than the MaxPacketSize for the
          pipe. If the data structure is an exact multiple of wMaxPacketSize
          for the pipe, the function will return a zero-length packet to indicate
          the end of the Data stage.
      In Case-A mentioned above:
      If we disable software ZLP generation & ZLT=0 for endpoint 0 OR if software
      ZLP generation is not disabled but we set ZLT=1 for endpoint 0 then
      enumeration doesn't block for 6 seconds.
      In Case-B mentioned above:
      If we disable software ZLP generation & ZLT=0 for endpoint then enumeration
      still blocks due to ZLP automatically generated by hardware and host not needing
      it. But if we keep software ZLP generation enabled but we set ZLT=1 for
      endpoint 0 then enumeration doesn't block for 6 seconds.
      So the proper solution for this issue seems to disable automatic ZLP generation
      by hardware (i.e by setting ZLT=1 for endpoint 0) and let software (UDC driver)
      handle the ZLP generation based on req->zero field.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAbbas Raza <Abbas_Raza@mentor.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@freescale.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Hannes Reinecke's avatar
      scsi: use 64-bit LUNs · 9cb78c16
      Hannes Reinecke authored
      The SCSI standard defines 64-bit values for LUNs, and large arrays
      employing large or hierarchical LUN numbers become more and more
      So update the linux SCSI stack to use 64-bit LUN numbers.
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@infradead.org>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
    • Hannes Reinecke's avatar
      scsi: Remove CONFIG_SCSI_MULTI_LUN · c309b351
      Hannes Reinecke authored
      Obsolete; either use 'max_lun' if the host supports only a
      limited number of LUNs or BLIST_NOLUN if the target has
      problems addressing more than one LUN.
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Reviewed-by: default avatarEwan Milne <emilne@redhat.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
  7. 16 Jul, 2014 3 commits