1. 07 3月, 2013 2 次提交
    • B
      USB: storage: fix Huawei mode switching regression · ab4b7164
      Bjørn Mork 提交于
      This reverts commit 200e0d99 ("USB: storage: optimize to match the
      Huawei USB storage devices and support new switch command" and the
      followup bugfix commit cd060956 ("USB: storage: properly handle
      the endian issues of idProduct").
      
      The commit effectively added a large number of Huawei devices to
      the deprecated usb-storage mode switching logic.  Many of these
      devices have been in use and supported by the userspace
      usb_modeswitch utility for years.  Forcing the switching inside
      the kernel causes a number of regressions as a result of ignoring
      existing onfigurations, and also completely takes away the ability
      to configure mode switching per device/system/user.
      
      Known regressions caused by this:
       - Some of the devices support multiple modes, using different
        switching commands.  There are existing configurations taking
        advantage of this.
      
       - There is a real use case for disabling mode switching and
        instead mounting the exposed storage device. This becomes
        impossible with switching logic inside the usb-storage driver.
      
       - At least on device fail as a result of the usb-storage switching
        command, becoming completely unswitchable. This is possibly a
        firmware bug, but still a regression because the device work as
        expected using usb_modeswitch defaults.
      
      In-kernel mode switching was deprecated years ago with the
      development of the more user friendly userspace alternatives. The
      existing list of devices in usb-storage was only kept to prevent
      breaking already working systems.  The long term plan is to remove
      the list, not to add to it. Ref:
      http://permalink.gmane.org/gmane.linux.usb.general/28543
      
      Cc: <fangxiaozhi@huawei.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ab4b7164
    • B
  2. 15 2月, 2013 1 次提交
  3. 09 2月, 2013 1 次提交
  4. 05 2月, 2013 2 次提交
  5. 26 1月, 2013 1 次提交
  6. 21 1月, 2013 1 次提交
  7. 12 1月, 2013 6 次提交
  8. 29 11月, 2012 1 次提交
  9. 27 11月, 2012 1 次提交
  10. 19 11月, 2012 1 次提交
  11. 14 11月, 2012 2 次提交
    • M
      [SCSI] sd: Implement support for WRITE SAME · 5db44863
      Martin K. Petersen 提交于
      Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
      driver.
      
       - We set the default maximum to 0xFFFF because there are several
         devices out there that only support two-byte block counts even with
         WRITE SAME(16). We only enable transfers bigger than 0xFFFF if the
         device explicitly reports MAXIMUM WRITE SAME LENGTH in the BLOCK
         LIMITS VPD.
      
       - max_write_same_blocks can be overriden per-device basis in sysfs.
      
       - The UNMAP discovery heuristics remain unchanged but the discard
         limits are tweaked to match the "real" WRITE SAME commands.
      
       - In the error handling logic we now distinguish between WRITE SAME
         with and without UNMAP set.
      
      The discovery process heuristics are:
      
       - If the device reports a SCSI level of SPC-3 or greater we'll issue
         READ SUPPORTED OPERATION CODES to find out whether WRITE SAME(16) is
         supported. If that's the case we will use it.
      
       - If the device supports the block limits VPD and reports a MAXIMUM
         WRITE SAME LENGTH bigger than 0xFFFF we will use WRITE SAME(16).
      
       - Otherwise we will use WRITE SAME(10) unless the target LBA is beyond
         0xFFFFFFFF or the block count exceeds 0xFFFF.
      
       - no_write_same is set for ATA, FireWire and USB.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: NMike Snitzer <snitzer@redhat.com>
      Reviewed-by: NJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      5db44863
    • M
      [SCSI] Add a report opcode helper · 3c6bdaea
      Martin K. Petersen 提交于
      The REPORT SUPPORTED OPERATION CODES command can be used to query
      whether a given opcode is supported by a device. Add a helper function
      that allows us to look up commands.
      
      We only issue RSOC if the device reports compliance with SPC-3 or
      later. But to err on the side of caution we disable the command for ATA,
      FireWire and USB.
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      3c6bdaea
  12. 31 10月, 2012 1 次提交
    • J
      USB: ums_realtek: fix build warning · 806df3ac
      Jingoo Han 提交于
      When rts51x_read_status() returns USB_STOR_TRANSPORT_ERROR,
      an error happens. This patch fixes build warning as below:
      
      drivers/usb/storage/realtek_cr.c: In function 'init_realtek_cr':
      drivers/usb/storage/realtek_cr.c:476:33: warning: 'buf[15]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[15]' was declared here
      drivers/usb/storage/realtek_cr.c:475:33: warning: 'buf[14]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[14]' was declared here
      drivers/usb/storage/realtek_cr.c:474:50: warning: 'buf[13]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[13]' was declared here
      drivers/usb/storage/realtek_cr.c:472:30: warning: 'buf[12]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[12]' was declared here
      drivers/usb/storage/realtek_cr.c:471:31: warning: 'buf[11]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[11]' was declared here
      drivers/usb/storage/realtek_cr.c:470:31: warning: 'buf[10]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[10]' was declared here
      drivers/usb/storage/realtek_cr.c:469:30: warning: 'buf[9]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[9]' was declared here
      drivers/usb/storage/realtek_cr.c:468:27: warning: 'buf[8]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[8]' was declared here
      drivers/usb/storage/realtek_cr.c:468:43: warning: 'buf[7]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[7]' was declared here
      drivers/usb/storage/realtek_cr.c:467:30: warning: 'buf[6]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[6]' was declared here
      drivers/usb/storage/realtek_cr.c:466:30: warning: 'buf[5]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[5]' was declared here
      drivers/usb/storage/realtek_cr.c:465:28: warning: 'buf[4]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[4]' was declared here
      drivers/usb/storage/realtek_cr.c:464:24: warning: 'buf[3]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[3]' was declared here
      drivers/usb/storage/realtek_cr.c:464:40: warning: 'buf[2]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[2]' was declared here
      drivers/usb/storage/realtek_cr.c:463:24: warning: 'buf[1]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[1]' was declared here
      drivers/usb/storage/realtek_cr.c:463:40: warning: 'buf[0]' may be used uninitialized in this function [-Wuninitialized]
      drivers/usb/storage/realtek_cr.c:455:5: note: 'buf[0]' was declared here
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      806df3ac
  13. 25 10月, 2012 1 次提交
  14. 27 9月, 2012 2 次提交
  15. 26 9月, 2012 5 次提交
  16. 22 9月, 2012 1 次提交
  17. 06 9月, 2012 1 次提交
  18. 21 8月, 2012 1 次提交
  19. 16 8月, 2012 1 次提交
  20. 20 7月, 2012 2 次提交
  21. 17 7月, 2012 2 次提交
  22. 26 6月, 2012 4 次提交