1. 13 Jul, 2016 1 commit
  2. 15 Apr, 2016 2 commits
  3. 11 Apr, 2016 1 commit
  4. 05 Apr, 2016 1 commit
  5. 05 Mar, 2016 1 commit
  6. 23 Feb, 2016 2 commits
  7. 02 Dec, 2015 2 commits
  8. 30 Nov, 2015 1 commit
  9. 28 Aug, 2015 3 commits
  10. 26 Aug, 2015 1 commit
  11. 01 Jun, 2015 1 commit
  12. 04 Feb, 2015 1 commit
  13. 20 Jan, 2015 1 commit
  14. 09 Jan, 2015 1 commit
  15. 15 Dec, 2014 1 commit
  16. 24 Nov, 2014 1 commit
  17. 12 Nov, 2014 6 commits
  18. 15 Sep, 2014 1 commit
    • Alan Stern's avatar
      scsi: don't store LUN bits in CDB[1] for USB mass-storage devices · 50c4e964
      Alan Stern authored
      The SCSI specification requires that the second Command Data Byte
      should contain the LUN value in its high-order bits if the recipient
      device reports SCSI level 2 or below.  Nevertheless, some USB
      mass-storage devices use those bits for other purposes in
      vendor-specific commands.  Currently Linux has no way to send such
      commands, because the SCSI stack always overwrites the LUN bits.
      
      Testing shows that Windows 7 and XP do not store the LUN bits in the
      CDB when sending commands to a USB device.  This doesn't matter if the
      device uses the Bulk-Only or UAS transports (which virtually all
      modern USB mass-storage devices do), as these have a separate
      mechanism for sending the LUN value.
      
      Therefore this patch introduces a flag in the Scsi_Host structure to
      inform the SCSI midlayer that a transport does not require the LUN
      bits to be stored in the CDB, and it makes usb-storage set this flag
      for all devices using the Bulk-Only transport.  (UAS is handled by a
      separate driver, but it doesn't really matter because no SCSI-2 or
      lower device is at all likely to use UAS.)
      
      The patch also cleans up the code responsible for storing the LUN
      value by adding a bitflag to the scsi_device structure.  The test for
      whether to stick the LUN value in the CDB can be made when the device
      is probed, and stored for future use rather than being made over and
      over in the fast path.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarTiziano Bacocco <tiziano.bacocco@gmail.com>
      Acked-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: default avatarJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      50c4e964
  19. 25 Jul, 2014 5 commits
  20. 17 Jul, 2014 1 commit
  21. 30 Jun, 2014 1 commit
  22. 09 Apr, 2014 1 commit
  23. 27 Mar, 2014 1 commit
    • Hannes Reinecke's avatar
      [SCSI] Add EVPD page 0x83 and 0x80 to sysfs · b3ae8780
      Hannes Reinecke authored
      EVPD page 0x83 is used to uniquely identify the device.
      So instead of having each and every program issue a separate
      SG_IO call to retrieve this information it does make far more
      sense to display it in sysfs.
      
      Some older devices (most notably tapes) will only report reliable
      information in page 0x80 (Unit Serial Number). So export this
      in the sysfs attribute 'vpd_pg80'.
      
      [jejb: checkpatch fix]
      [hare: attach after transport configure]
      [fengguang.wu@intel.com: spotted problems with the original now fixed]
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      b3ae8780
  24. 15 Mar, 2014 2 commits
  25. 26 Aug, 2013 1 commit
    • Ewan D. Milne's avatar
      [SCSI] Generate uevents on certain unit attention codes · 279afdfe
      Ewan D. Milne authored
      Generate a uevent when the following Unit Attention ASC/ASCQ
      codes are received:
      
          2A/01  MODE PARAMETERS CHANGED
          2A/09  CAPACITY DATA HAS CHANGED
          38/07  THIN PROVISIONING SOFT THRESHOLD REACHED
          3F/03  INQUIRY DATA HAS CHANGED
          3F/0E  REPORTED LUNS DATA HAS CHANGED
      
      Log kernel messages when the following Unit Attention ASC/ASCQ
      codes are received that are not as specific as those above:
      
          2A/xx  PARAMETERS CHANGED
          3F/xx  TARGET OPERATING CONDITIONS HAVE CHANGED
      
      Added logic to set expecting_lun_change for other LUNs on the target
      after REPORTED LUNS DATA HAS CHANGED is received, so that duplicate
      uevents are not generated, and clear expecting_lun_change when a
      REPORT LUNS command completes, in accordance with the SPC-3
      specification regarding reporting of the 3F 0E ASC/ASCQ UA.
      
      [jejb: remove SPC3 test in scsi_report_lun_change and some docbook fixes and
             unused variable fix, both reported by Fengguang Wu]
      Signed-off-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      279afdfe