1. 12 11月, 2014 5 次提交
  2. 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
  3. 26 7月, 2014 3 次提交
  4. 25 7月, 2014 2 次提交
  5. 18 7月, 2014 1 次提交
  6. 01 7月, 2014 1 次提交
  7. 10 4月, 2014 1 次提交
  8. 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
  9. 16 3月, 2014 2 次提交
  10. 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
  11. 05 6月, 2013 1 次提交
  12. 07 5月, 2013 1 次提交
  13. 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
  14. 27 11月, 2012 1 次提交
  15. 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
  16. 24 9月, 2012 1 次提交
  17. 20 7月, 2012 3 次提交
  18. 17 7月, 2012 1 次提交
  19. 29 6月, 2012 1 次提交
  20. 23 6月, 2012 1 次提交
    • A
      SCSI & usb-storage: add try_rc_10_first flag · 6a0bdffa
      Alan Stern 提交于
      Several bug reports have been received recently for USB mass-storage
      devices that don't handle READ CAPACITY(16) commands properly.  They
      report bogus sizes, in some cases becoming unusable as a result.
      
      The bugs were triggered by commit
      09b6b51b (SCSI & usb-storage: add
      flags for VPD pages and REPORT LUNS), which caused usb-storage to stop
      overriding the SCSI level reported by devices.  By default, the sd
      driver will try READ CAPACITY(16) first for any device whose level is
      above SCSI_SPC_2.
      
      It seems likely that any device large enough to require the use of
      READ CAPACITY(16) (i.e., 2 TB or more) would be able to handle READ
      CAPACITY(10) commands properly.  Indeed, I don't know of any devices
      that don't handle READ CAPACITY(10) properly.
      
      Therefore this patch (as1559) adds a new flag telling the sd driver
      to try READ CAPACITY(10) before READ CAPACITY(16), and sets this flag
      for every USB mass-storage device.  If a device really is larger than
      2 TB, sd will fall back to READ CAPACITY(16) just as it used to.
      
      This fixes Bugzilla #43391.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NHans de Goede <hdegoede@redhat.com>
      CC: "James E.J. Bottomley" <JBottomley@parallels.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a0bdffa
  21. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  22. 09 2月, 2012 2 次提交
    • A
      SCSI & usb-storage: add flags for VPD pages and REPORT LUNS · 09b6b51b
      Alan Stern 提交于
      This patch (as1507) adds a skip_vpd_pages flag to struct scsi_device
      and a no_report_luns flag to struct scsi_target.  The first is used to
      control whether sd will look at VPD pages for information on block
      provisioning, limits, and characteristics.  The second prevents
      scsi_report_lun_scan() from issuing a REPORT LUNS command.
      
      The patch also modifies usb-storage to set the new flag bits for all
      USB devices and targets, and to stop adjusting the scsi_level value.
      
      Historically we have seen that USB mass-storage devices often don't
      support VPD pages or REPORT LUNS properly.  Until now we have avoided
      these things by setting the scsi_level to SCSI_2 for all USB devices.
      But this has the side effect of storing the LUN bits into the second
      byte of each CDB, and now we have a report of a device which doesn't
      like that.  The best solution is to stop abusing scsi_level and
      instead have separate flags for VPD pages and REPORT LUNS.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Reported-by: NPerry Wagle <wagle@mac.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09b6b51b
    • A
      SCSI: fix typo in definition of struct scsi_target · de8c46bf
      Alan Stern 提交于
      This patch (as1506) corrects a typo in the definition of the
      scsi_target structure.  pdt_1f_for_no_lun is supposed to be a
      single-bit flag, not a full-sized integer.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de8c46bf
  23. 15 12月, 2011 1 次提交
  24. 31 8月, 2011 2 次提交
  25. 27 7月, 2011 1 次提交
  26. 17 5月, 2011 1 次提交
    • J
      scsi: remove performance regression due to async queue run · 9937a5e2
      Jens Axboe 提交于
      Commit c21e6beb removed our queue request_fn re-enter
      protection, and defaulted to always running the queues from
      kblockd to be safe. This was a known potential slow down,
      but should be safe.
      
      Unfortunately this is causing big performance regressions for
      some, so we need to improve this logic. Looking into the details
      of the re-enter, the real issue is on requeue of requests.
      
      Requeue of requests upon seeing a BUSY condition from the device
      ends up re-running the queue, causing traces like this:
      
      scsi_request_fn()
              scsi_dispatch_cmd()
                      scsi_queue_insert()
                              __scsi_queue_insert()
                                      scsi_run_queue()
      					scsi_request_fn()
      						...
      
      potentially causing the issue we want to avoid. So special
      case the requeue re-run of the queue, but improve it to offload
      the entire run of local queue and starved queue from a single
      workqueue callback. This is a lot better than potentially
      kicking off a workqueue run for each device seen.
      
      This also fixes the issue of the local device going into recursion,
      since the above mentioned commit never moved that queue run out
      of line.
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      9937a5e2