1. 05 3月, 2014 15 次提交
  2. 26 1月, 2013 1 次提交
  3. 12 1月, 2013 6 次提交
  4. 27 9月, 2012 2 次提交
  5. 26 9月, 2012 5 次提交
  6. 26 6月, 2012 7 次提交
  7. 03 2月, 2012 3 次提交
    • S
      usb/uas: make sure data urb is gone if we receive status before that · e4d8318a
      Sebastian Andrzej Siewior 提交于
      Just run into the following:
      - new disk arrived in the system
      - udev couldn't wait to get its hands on to to run ata_id /dev/sda
      - this sent the cdb 0xa1 to the device.
      - my UAS-gadget recevied the cdb and had no idea what to do with it. It
        decided to send a status URB back with sense set to invalid opcode.
      - the host side received it status and completed the scsi command.
      - the host sent another scsi with 4kib data buffer
      - Now I was confused why the data transfer is only 512 bytes instead of
        4kib since the host is always allocating the complete transfer in one
        go.
      - Finally the system crashed while walking through the sg list.
      
      This patch adds three new flags in order to distinguish between DATA
      URB completed and outstanding. If we receive status before data, we
      cancel data and let data complete the command.
      This solves the problem for IN and OUT transfers but does not work for
      BIDI.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e4d8318a
    • S
      usb/uas: move UAS structs / defines into a header file · 348748b0
      Sebastian Andrzej Siewior 提交于
      The protocol specific structures and defines which are used by UAS are
      moved into a header files by this patch so it can be accessed by the UAS
      gadget as well.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      348748b0
    • S
      usb/uas: only bind if the hcd supports SG · c898add5
      Sebastian Andrzej Siewior 提交于
      The UAS driver requires SG support by the HCD operating the device. This
      patch stops UAS from operating on a HCD without sg support and prints a
      message to let him know.
      
      The spec says:
      |For [USB2] backward compatibility, the device shall present [BOT] as
      |alternate interface zero (primary) and [UAS] as alternate interface one
      |(secondary). A device which does not need backward compatibility with
      |[BOT] shall present [UAS] as alternate interface zero. In [USB2]
      |systems, the [BOT] driver or an associated filter driver may need to
      |issue a SET INTERFACE request for alternate interface one and then allow
      |the [UAS] driver to load.
      
      If the user used usb_modeswitch to switch to UAS then he can go back to
      BOT or use a different HCD. In case UAS is the only interface then there
      is currently no way out.
      In future usb_sg_wait() should be extended to provide a non-blocking
      interface so it can work with the UAS driver.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c898add5
  8. 22 12月, 2011 1 次提交
    • S
      usb/uas: one only one status URB/host on stream-less connection · ceb3f91f
      Sebastian Andrzej Siewior 提交于
      The status/sense URB is allocated on per-command basis. A read/write
      looks the following way on a stream-less connection:
      
      - send cmd tag X, queue status
      - receive status, oh it is a read for tag X. queue status & read
      - receive read
      - receive status, oh I'm done for tag X. Cool call complete and free
        status urb.
      
      This block repeats itself 1:1 for further commands and looks great so
      far. Lets take a look now what happens if we do allow multiple commands:
      
      - send cmd tag X, queue statusX (belongs to the command with the X tag)
      - send cmd tag Y, queue statusY (belongs to the command with the Y tag)
      - receive statusX, oh it is a read for tag X. queue statusX & a read
      - receive read
      - receive statusY, oh I'm done for tag X. Cool call complete and free statusY.
      - receive statusX, oh it is a read for tag Y. queue statusY & before we
        queue the read the the following message can be observed:
        |sd 0:0:0:0: [sda] sense urb submission failure
        followed by a second attempt with the same result.
      
      In order to address this problem we will use only one status URB for
      each scsi host in case we don't have stream support (as suggested by
      Matthew). This URB is requeued until the device removed. Nothing changes
      on stream based endpoints.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      ceb3f91f