1. 03 12月, 2015 2 次提交
  2. 01 12月, 2015 1 次提交
  3. 29 8月, 2015 3 次提交
  4. 26 8月, 2015 1 次提交
  5. 01 6月, 2015 1 次提交
  6. 05 2月, 2015 1 次提交
  7. 21 1月, 2015 1 次提交
  8. 09 1月, 2015 1 次提交
  9. 15 12月, 2014 1 次提交
  10. 24 11月, 2014 1 次提交
  11. 12 11月, 2014 6 次提交
  12. 16 9月, 2014 1 次提交
    • A
      scsi: don't store LUN bits in CDB[1] for USB mass-storage devices · 50c4e964
      Alan Stern 提交于
      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: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NTiziano Bacocco <tiziano.bacocco@gmail.com>
      Acked-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      50c4e964
  13. 26 7月, 2014 3 次提交
  14. 25 7月, 2014 2 次提交
  15. 18 7月, 2014 1 次提交
  16. 01 7月, 2014 1 次提交
  17. 10 4月, 2014 1 次提交
  18. 27 3月, 2014 1 次提交
    • H
      [SCSI] Add EVPD page 0x83 and 0x80 to sysfs · b3ae8780
      Hannes Reinecke 提交于
      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: NHannes Reinecke <hare@suse.de>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      b3ae8780
  19. 16 3月, 2014 2 次提交
  20. 26 8月, 2013 1 次提交
    • E
      [SCSI] Generate uevents on certain unit attention codes · 279afdfe
      Ewan D. Milne 提交于
      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: NEwan D. Milne <emilne@redhat.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      279afdfe
  21. 05 6月, 2013 1 次提交
  22. 07 5月, 2013 1 次提交
  23. 26 1月, 2013 2 次提交
    • A
      [SCSI] remove can_power_off flag from scsi_device · 44ec657b
      Aaron Lu 提交于
      Commit 166a2967 "libata: tell scsi layer
      device supports runtime power off" introduced the can_power_off flag for
      scsi_device and is used to support ZPODD implementation in SCSI layer.
      Since ZPODD is now implemented in ATA layer, that flag is no longer
      needed, so remove it.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      44ec657b
    • A
      [libata] scsi: no poll when ODD is powered off · 6f4c827e
      Aaron Lu 提交于
      When the ODD is powered off, any action the user did to the ODD that
      would generate a media event will trigger an ACPI interrupt, so the
      poll for media event is no longer necessary. And the poll will also
      cause a runtime status change, which will stop the ODD from staying in
      powered off state, so the poll should better be stopped.
      
      But since we don't have access to the gendisk structure in LLDs, here
      comes the disk_events_disable_depth for scsi device. This field is a
      hint set by LLDs to convey information to upper layer drivers. A value
      of 0 means media poll is necessary for the device, while values above 0
      means media poll is not needed and should better be skipped. So we can
      increase its value when we are to power off the ODD in ATA layer and
      decrease its value when the ODD is powered on, effectively silence the
      media events poll.
      Signed-off-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      6f4c827e
  24. 27 11月, 2012 1 次提交
  25. 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
  26. 24 9月, 2012 1 次提交
新手
引导
客服 返回
顶部