1. 06 9月, 2012 1 次提交
  2. 20 7月, 2012 1 次提交
  3. 17 7月, 2012 1 次提交
  4. 23 6月, 2012 1 次提交
  5. 14 6月, 2012 1 次提交
    • H
      usb-storage: Add 090c:1000 to unusal-devs · afff07e6
      Hans de Goede 提交于
      This device gives a bogus answer to get_capacity(16):
      [ 8628.278614] scsi 8:0:0:0: Direct-Access     USB 2.0  USB Flash Drive  1100 PQ: 0 ANSI: 4
      [ 8628.279452] sd 8:0:0:0: Attached scsi generic sg4 type 0
      [ 8628.280338] sd 8:0:0:0: [sdd] 35747322042253313 512-byte logical blocks: (18.3 EB/15.8 EiB)
      
      So set the quirk flag to avoid using get_capacity(16) with it:
      [11731.386014] usb-storage 2-1.6:1.0: Quirks match for vid 090c pid 1000: 80000
      [11731.386075] scsi9 : usb-storage 2-1.6:1.0
      [11731.386172] usbcore: registered new interface driver usb-storage
      [11731.386175] USB Mass Storage support registered.
      [11732.387394] scsi 9:0:0:0: Direct-Access     USB 2.0  USB Flash Drive  1100 PQ: 0 ANSI: 4
      [11732.388462] sd 9:0:0:0: Attached scsi generic sg3 type 0
      [11732.389432] sd 9:0:0:0: [sdc] 7975296 512-byte logical blocks: (4.08 GB/3.80 GiB)
      
      Which makes the capacity look a lot more sane :)
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Tested-by: NSimon Raffeiner <sturmflut@lieberbiber.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afff07e6
  6. 10 5月, 2012 1 次提交
  7. 28 3月, 2012 1 次提交
  8. 02 1月, 2012 1 次提交
  9. 27 11月, 2011 1 次提交
  10. 09 8月, 2011 1 次提交
  11. 08 6月, 2011 1 次提交
    • A
      usb-storage: redo incorrect reads · 21c13a4f
      Alan Stern 提交于
      Some USB mass-storage devices have bugs that cause them not to handle
      the first READ(10) command they receive correctly.  The Corsair
      Padlock v2 returns completely bogus data for its first read (possibly
      it returns the data in encrypted form even though the device is
      supposed to be unlocked).  The Feiya SD/SDHC card reader fails to
      complete the first READ(10) command after it is plugged in or after a
      new card is inserted, returning a status code that indicates it thinks
      the command was invalid, which prevents the kernel from retrying the
      read.
      
      Since the first read of a new device or a new medium is for the
      partition sector, the kernel is unable to retrieve the device's
      partition table.  Users have to manually issue an "hdparm -z" or
      "blockdev --rereadpt" command before they can access the device.
      
      This patch (as1470) works around the problem.  It adds a new quirk
      flag, US_FL_INVALID_READ10, indicating that the first READ(10) should
      always be retried immediately, as should any failing READ(10) commands
      (provided the preceding READ(10) command succeeded, to avoid getting
      stuck in a loop).  The patch also adds appropriate unusual_devs
      entries containing the new flag.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NSven Geggus <sven-usbst@geggus.net>
      Tested-by: NPaul Hartman <paul.hartman+linux@gmail.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      CC: <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      21c13a4f
  12. 04 2月, 2011 2 次提交
  13. 23 1月, 2011 2 次提交
  14. 17 12月, 2010 1 次提交
  15. 23 10月, 2010 3 次提交
  16. 21 5月, 2010 2 次提交
  17. 19 3月, 2010 2 次提交
  18. 03 3月, 2010 1 次提交
  19. 17 2月, 2010 1 次提交
  20. 21 1月, 2010 1 次提交
    • R
      USB: fix usbstorage for 2770:915d delivers no FAT · 10d2cdb6
      Ryan May 提交于
      Resolves kernel.org bug 14914.
      
      Remove entry for 2770:915d (usb digital camera with mass storage
      support) from unusual_devs.h. The fix triggered by the entry causes
      the file system on the camera to be completely inaccessible (no
      partition table, the device is not mountable).
      
      The patch works, but let me clarify a few things about it.  All the
      patch does is remove the entry for this device from the
      drivers/usb/storage/unusual_devs.h, which is supposed to help with a
      problem with the device's reported size (I think).  I'm pretty sure it
      was originally added for a reason, so I'm not sure removing it won't
      cause other problems to reappear.  Also, I should note that this
      unusual_devs.h entry was present (and activating workarounds) in
      2.6.29, but in that version everything works fine.  Starting with
      2.6.30, things no longer work.
      Signed-off-by: NRyan May <rmay31@gmail.com>
      Cc: Rohan Hart <rohan.hart17@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      10d2cdb6
  21. 12 12月, 2009 1 次提交
    • A
      USB: usb-storage: add BAD_SENSE flag · a0bb1081
      Alan Stern 提交于
      This patch (as1311) fixes a problem in usb-storage: Some devices are
      pretty broken when it comes to reporting sense data.  The information
      they send back indicates that they have more than 18 bytes of sense
      data available, but when the system asks for more than 18 they fail or
      hang.  The symptom is that probing fails with multiple resets.
      
      The patch adds a new BAD_SENSE flag to indicate that usb-storage
      should never ask for more than 18 bytes of sense data.  The flag can
      be set in an unusual_devs entry or via the "quirks=" module parameter,
      and it is set automatically whenever a REQUEST SENSE command for more
      than 18 bytes fails or times out.
      
      An unusual_devs entry is added for the Agfa photo frame, which uses a
      Prolific chip having this bug.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Tested-by: NDaniel Kukula <daniel.kuku@gmail.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a0bb1081
  22. 10 10月, 2009 1 次提交
  23. 23 9月, 2009 1 次提交
  24. 08 8月, 2009 1 次提交
  25. 16 6月, 2009 1 次提交
  26. 09 5月, 2009 1 次提交
  27. 24 4月, 2009 1 次提交
  28. 18 4月, 2009 2 次提交
  29. 25 3月, 2009 5 次提交