1. 01 5月, 2014 10 次提交
  2. 22 4月, 2014 4 次提交
  3. 28 3月, 2014 1 次提交
    • O
      usbnet: include wait queue head in device structure · 14a0d635
      Oliver Neukum 提交于
      This fixes a race which happens by freeing an object on the stack.
      Quoting Julius:
      > The issue is
      > that it calls usbnet_terminate_urbs() before that, which temporarily
      > installs a waitqueue in dev->wait in order to be able to wait on the
      > tasklet to run and finish up some queues. The waiting itself looks
      > okay, but the access to 'dev->wait' is totally unprotected and can
      > race arbitrarily. I think in this case usbnet_bh() managed to succeed
      > it's dev->wait check just before usbnet_terminate_urbs() sets it back
      > to NULL. The latter then finishes and the waitqueue_t structure on its
      > stack gets overwritten by other functions halfway through the
      > wake_up() call in usbnet_bh().
      
      The fix is to just not allocate the data structure on the stack.
      As dev->wait is abused as a flag it also takes a runtime PM change
      to fix this bug.
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Reported-by: NGrant Grundler <grundler@google.com>
      Tested-by: NGrant Grundler <grundler@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14a0d635
  4. 21 3月, 2014 1 次提交
    • B
      net: cdc_ncm: respect operator preferred MTU reported by MBIM · 259fef03
      Ben Chan 提交于
      According to "Universal Serial Bus Communications Class Subclass
      Specification for Mobile Broadband Interface Model, Revision 1.0,
      Errata-1" published by USB-IF, the wMTU field of the MBIM extended
      functional descriptor indicates the operator preferred MTU for IP data
      streams.
      
      This patch modifies cdc_ncm_setup to ensure that the MTU value set on
      the usbnet device does not exceed the operator preferred MTU indicated
      by wMTU if the MBIM device exposes a MBIM extended functional
      descriptor.
      Signed-off-by: NBen Chan <benchan@chromium.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      259fef03
  5. 19 3月, 2014 1 次提交
  6. 13 3月, 2014 1 次提交
  7. 09 3月, 2014 1 次提交
  8. 08 3月, 2014 1 次提交
  9. 06 3月, 2014 1 次提交
  10. 05 3月, 2014 4 次提交
    • O
      storage: accept some UAS devices if streams are unavailable · 14aec589
      Oliver Neukum 提交于
      On some older XHCIs streams are not supported and the UAS driver
      will fail at probe time. For those devices storage should try
      to bind to UAS devices.
      This patch adds a flag for stream support to HCDs and evaluates
      it.
      
      [Note: Sarah fixed a bug where the USB 2.0 root hub, not USB 3.0 root
      hub would get marked as being able to support streams.]
      Signed-off-by: NOliver Neukum <oliver@neukum.org>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      14aec589
    • H
      uas: Pack iu struct definitions · d24354bb
      Hans de Goede 提交于
      The iu struct definitions are usb packet definitions, so no alignment should
      happen. Notice that assuming 32 bit alignment this does not make any
      difference at all.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d24354bb
    • H
      uas: Fix response iu struct definition · 00d202cc
      Hans de Goede 提交于
      The response iu struct before this patch has a size of 7 bytes (discounting
      padding), which is weird since all other iu-s are explictly padded to
      a multiple of 4 bytes.
      
      More over submitting a 7 byte bulk transfer to the status endpoint when
      expecting a response iu results in an USB babble error, as the device
      actually sends 8 bytes.
      
      Up on closer reading of the UAS spec:
      http://www.t10.org/cgi-bin/ac.pl?t=f&f=uas2r00.pdf
      
      The reason for this becomes clear, the 2 entries in "Table 17 — RESPONSE IU"
      are numbered 4 and 6, looking at other iu definitions in the spec, esp.
      multi-byte fields, this indicates that the ADDITIONAL RESPONSE INFORMATION
      field is not a 2 byte field as one might assume at a first look, but is
      a multi-byte field containing 3 bytes.
      
      This also aligns with the SCSI Architecture Model 4 spec, which UAS is based
      on which states in paragraph "7.1 Task management function procedure calls"
      that the "Additional Response Information" output argument for a Task
      management function procedure call is 3 bytes.
      
      Last but not least I've verified this by sending a logical unit reset task
      management call with an invalid lun to an actual uasp device, and received
      back a response-iu with byte 6 being 0, and byte 7 being 9, which is the
      responce code for an invalid iu, which confirms that the response code is
      being reported in byte 7 of the response iu rather then in byte 6.
      
      Things were working before despite this error in the response iu struct
      definition because the additional response info field is normally filled
      with zeros, and 0 is the response code value for success.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      00d202cc
    • H
      uas: s/response_ui/response_iu/ · e52e0314
      Hans de Goede 提交于
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e52e0314
  11. 25 2月, 2014 1 次提交
  12. 19 2月, 2014 1 次提交
  13. 14 1月, 2014 1 次提交
  14. 09 1月, 2014 1 次提交
  15. 19 12月, 2013 1 次提交
  16. 18 12月, 2013 1 次提交
    • R
      usb: gadget: add "maxpacket_limit" field to struct usb_ep · e117e742
      Robert Baldyga 提交于
      This patch adds "maxpacket_limit" to struct usb_ep. This field contains
      maximum value of maxpacket supported by driver, and is set in driver probe.
      This value should be used by autoconfig() function, because value of field
      "maxpacket" is set to value from endpoint descriptor when endpoint becomes
      enabled. So when autoconfig() function will be called again for this endpoint,
      "maxpacket" value will contain wMaxPacketSize from descriptior instead of
      maximum packet size for this endpoint.
      
      For this reason this patch adds new field "maxpacket_limit" which contains
      value of maximum packet size (which defines maximum endpoint capabilities).
      This value is used in ep_matches() function used by autoconfig().
      
      Value of "maxpacket_limit" should be set in UDC driver probe function, using
      usb_ep_set_maxpacket_limit() function, defined in gadget.h. This function
      set choosen value to both "maxpacket_limit" and "maxpacket" fields.
      
      This patch modifies UDC drivers by adding support for maxpacket_limit.
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      e117e742
  17. 13 12月, 2013 4 次提交
  18. 11 12月, 2013 1 次提交
    • D
      usb: xhci: change enumeration scheme to 'new scheme' by default · 48fc7dbd
      Dan Williams 提交于
      Change the default enumeration scheme for xhci attached non-SuperSpeed
      devices from:
      
         Reset
         SetAddress [xhci address-device BSR = 0]
         GetDescriptor(8)
         GetDescriptor(18)
      
      ...to:
      
         Reset
         [xhci address-device BSR = 1]
         GetDescriptor(64)
         Reset
         SetAddress [xhci address-device BSR = 0]
         GetDescriptor(18)
      
      ...as some devices misbehave when encountering a SetAddress command
      prior to GetDescriptor.  There are known legacy devices that require
      this scheme, but testing has found at least one USB3 device that fails
      enumeration when presented with this ordering.  For now, follow the ehci
      case and enable 'new scheme' by default for non-SuperSpeed devices.
      
      To support this enumeration scheme on xhci the AddressDevice operation
      needs to be performed twice.  The first instance of the command enables
      the HC's device and slot context info for the device, but omits sending
      the device a SetAddress command (BSR == block set address request).
      Then, after GetDescriptor completes, follow up with the full
      AddressDevice+SetAddress operation.
      
      As mentioned before, this ordering of events with USB3 devices causes an
      extra state transition to be exposed to xhci.  Previously USB3 devices
      would transition directly from 'enabled' to 'addressed' and never need
      to underrun responses to 'get descriptor'. We do see the 64-byte
      descriptor fetch the correct data, but the following 18-byte descriptor
      read after the reset gets:
      
      bLength            = 0
      bDescriptorType    = 0
      bcdUSB             = 0
      bDeviceClass       = 0
      bDeviceSubClass    = 0
      bDeviceProtocol    = 0
      bMaxPacketSize0    = 9
      
      instead of:
      
      bLength            = 12
      bDescriptorType    = 1
      bcdUSB             = 300
      bDeviceClass       = 0
      bDeviceSubClass    = 0
      bDeviceProtocol    = 0
      bMaxPacketSize0    = 9
      
      which results in the discovery process looping until falling back to
      'old scheme' enumeration.
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NDavid Moore <david.moore@gmail.com>
      Suggested-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      48fc7dbd
  19. 10 12月, 2013 2 次提交
  20. 09 12月, 2013 1 次提交
  21. 03 12月, 2013 1 次提交
    • T
      usb: wusbcore: fix deadlock in wusbhc_gtk_rekey · 471e42ad
      Thomas Pugliese 提交于
      When multiple wireless USB devices are connected and one of the devices
      disconnects, the host will distribute a new group key to the remaining
      devicese using wusbhc_gtk_rekey.  wusbhc_gtk_rekey takes the
      wusbhc->mutex and holds it while it submits a URB to set the new key.
      This causes a deadlock in wa_urb_enqueue when it calls a device lookup
      helper function that takes the same lock.
      
      This patch changes wusbhc_gtk_rekey to submit a work item to set the GTK
      so that the URB is submitted without holding wusbhc->mutex.
      Signed-off-by: NThomas Pugliese <thomas.pugliese@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      471e42ad