1. 09 Apr, 2014 1 commit
  2. 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
  3. 15 Mar, 2014 2 commits
  4. 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
  5. 04 Jun, 2013 1 commit
  6. 06 May, 2013 1 commit
  7. 25 Jan, 2013 2 commits
    • Aaron Lu's avatar
      [SCSI] remove can_power_off flag from scsi_device · 44ec657b
      Aaron Lu authored
      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: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      44ec657b
    • Aaron Lu's avatar
      [libata] scsi: no poll when ODD is powered off · 6f4c827e
      Aaron Lu authored
      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: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      6f4c827e
  8. 26 Nov, 2012 1 commit
  9. 13 Nov, 2012 2 commits
    • Martin K. Petersen's avatar
      [SCSI] sd: Implement support for WRITE SAME · 5db44863
      Martin K. Petersen authored
      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: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Reviewed-by: default avatarMike Snitzer <snitzer@redhat.com>
      Reviewed-by: default avatarJeff Garzik <jgarzik@redhat.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      5db44863
    • Martin K. Petersen's avatar
      [SCSI] Add a report opcode helper · 3c6bdaea
      Martin K. Petersen authored
      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: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      3c6bdaea
  10. 24 Sep, 2012 1 commit
  11. 20 Jul, 2012 3 commits
  12. 16 Jul, 2012 1 commit
  13. 29 Jun, 2012 1 commit
  14. 22 Jun, 2012 1 commit
    • Alan Stern's avatar
      SCSI & usb-storage: add try_rc_10_first flag · 6a0bdffa
      Alan Stern authored
      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: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarHans 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: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a0bdffa
  15. 16 Mar, 2012 1 commit
    • Paul Gortmaker's avatar
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker authored
      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: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  16. 08 Feb, 2012 2 commits
    • Alan Stern's avatar
      SCSI & usb-storage: add flags for VPD pages and REPORT LUNS · 09b6b51b
      Alan Stern authored
      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: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarPerry Wagle <wagle@mac.com>
      CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09b6b51b
    • Alan Stern's avatar
      SCSI: fix typo in definition of struct scsi_target · de8c46bf
      Alan Stern authored
      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: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de8c46bf
  17. 14 Dec, 2011 1 commit
  18. 30 Aug, 2011 2 commits
  19. 26 Jul, 2011 1 commit
  20. 17 May, 2011 1 commit
    • Jens Axboe's avatar
      scsi: remove performance regression due to async queue run · 9937a5e2
      Jens Axboe authored
      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: default avatarJens Axboe <jaxboe@fusionio.com>
      9937a5e2
  21. 23 Mar, 2011 1 commit
    • Krishnasamy, Somasundaram's avatar
      [SCSI] ses: Avoid kernel panic when lun 0 is not mapped · d1e12de8
      Krishnasamy, Somasundaram authored
      During device discovery, scsi mid layer sends INQUIRY command to LUN
      0. If the LUN 0 is not mapped to host, it creates a temporary
      scsi_device with LUN id 0 and sends REPORT_LUNS command to it. After
      the REPORT_LUNS succeeds, it walks through the LUN table and adds each
      LUN found to sysfs. At the end of REPORT_LUNS lun table scan, it will
      delete the temporary scsi_device of LUN 0.
      
      When scsi devices are added to sysfs, it calls add_dev function of all
      the registered class interfaces. If ses driver has been registered,
      ses_intf_add() of ses module will be called. This function calls
      scsi_device_enclosure() to check the inquiry data for EncServ
      bit. Since inquiry was not allocated for temporary LUN 0 scsi_device,
      it will cause NULL pointer exception.
      
      To fix the problem, sdev->inquiry is checked for NULL before reading it.
      Signed-off-by: default avatarSomasundaram Krishnasamy <Somasundaram.Krishnasamy@lsi.com>
      Signed-off-by: default avatarBabu Moger <babu.moger@lsi.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      d1e12de8
  22. 24 Jan, 2011 1 commit
  23. 22 Oct, 2010 2 commits
    • Hans de Goede's avatar
      scsi/sd: add a no_read_capacity_16 scsi_device flag · 5ce524bd
      Hans de Goede authored
      I seem to have a knack for digging up buggy usb devices which don't work
      with Linux, and I'm crazy enough to try to make them work.  So this time a
      friend of mine asked me to get an mp4 player (an mp3 player which can play
      videos on a small screen) to work with Linux.
      
      It is based on the well known rockbox chipset for which we already have an
      unusual devs entries to work around some of its bugs.  But this model
      comes with an additional twist.
      
      This model chokes on read_capacity_16 calls.  Now normally we don't make
      those calls, but this model comes with an sdcard slot and when there is no
      card in there (and shipped from the factory there is none), it reports a
      size of 0.  However this time the programmers actually got the
      read_capacity_10 response right!  So they substract one from the size as
      stored internally in the mp3 player before reporting it back, resulting in
      an answer of ...  0xffffffff sectors, causing sd.c to try a
      read_capacity_16, on which the device crashes.
      
      This patch adds a flag to scsi_device to indicate that a a device cannot
      handle read_capacity_16, and when this flag is set if a device reports an
      lba of 0xffffffff as answer to a read_capacity_10, assumes it tries to
      report a size of 0.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5ce524bd
    • Hans de Goede's avatar
      scsi/sr: add no_read_disc_info scsi_device flag · 8e04d805
      Hans de Goede authored
      Some USB devices emulate a usb-mass-storage attached (scsi) cdrom device,
      usually this fake cdrom contains the windows software for the device.
      While working on supporting Appotech ax3003 based photoframes, which do
      this I discovered that they will go of into lala land when ever they see a
      READ_DISC_INFO scsi command.
      
      Thus this patch adds a scsi_device flag (which can then be set by the
      usb-storage driver through an unsual-devs entry), to indicate this, and
      makes the sr driver honor this flag.
      
      I know this sucks, but as discussed on linux-scsi list there is no other
      way to make this device work properly.
      
      Looking at usb traces made under windows, windows never sends a
      READ_DISC_INFO during normal interactions with a usb cdrom device.  So as
      this cdrom emulation thingie becomes more common we might see more of this
      problem.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8e04d805
  24. 28 Jul, 2010 1 commit
    • Alan Stern's avatar
      [SCSI] implement runtime Power Management · bc4f2401
      Alan Stern authored
      This patch (as1398b) adds runtime PM support to the SCSI layer.  Only
      the machanism is provided; use of it is up to the various high-level
      drivers, and the patch doesn't change any of them.  Except for sg --
      the patch expicitly prevents a device from being runtime-suspended
      while its sg device file is open.
      
      The implementation is simplistic.  In general, hosts and targets are
      automatically suspended when all their children are asleep, but for
      them the runtime-suspend code doesn't actually do anything.  (A host's
      runtime PM status is propagated up the device tree, though, so a
      runtime-PM-aware lower-level driver could power down the host adapter
      hardware at the appropriate times.)  There are comments indicating
      where a transport class might be notified or some other hooks added.
      
      LUNs are runtime-suspended by calling the drivers' existing suspend
      handlers (and likewise for runtime-resume).  Somewhat arbitrarily, the
      implementation delays for 100 ms before suspending an eligible LUN.
      This is because there typically are occasions during bootup when the
      same device file is opened and closed several times in quick
      succession.
      
      The way this all works is that the SCSI core increments a device's
      PM-usage count when it is registered.  If a high-level driver does
      nothing then the device will not be eligible for runtime-suspend
      because of the elevated usage count.  If a high-level driver wants to
      use runtime PM then it can call scsi_autopm_put_device() in its probe
      routine to decrement the usage count and scsi_autopm_get_device() in
      its remove routine to restore the original count.
      
      Hosts, targets, and LUNs are not suspended while they are being probed
      or removed, or while the error handler is running.  In fact, a fairly
      large part of the patch consists of code to make sure that things
      aren't suspended at such times.
      
      [jejb: fix up compile issues in PM config variations]
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      bc4f2401
  25. 18 Jan, 2010 1 commit
  26. 04 Dec, 2009 2 commits
    • Chandra Seetharaman's avatar
      [SCSI] scsi_dh: Change the scsidh_activate interface to be asynchronous · 3ae31f6a
      Chandra Seetharaman authored
      Make scsi_dh_activate() function asynchronous, by taking in two additional
      parameters, one is the callback function and the other is the data to call
      the callback function with.
      Signed-off-by: default avatarChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      3ae31f6a
    • Vasu Dev's avatar
      [SCSI] add queue_depth ramp up code · 4a84067d
      Vasu Dev authored
      Current FC HBA queue_depth ramp up code depends on last queue
      full time. The sdev already  has last_queue_full_time field to
      track last queue full time but stored value is truncated by
      last four bits.
      
      So this patch updates last_queue_full_time without truncating
      last 4 bits to store full value and then updates its only
      current usages in scsi_track_queue_full to ignore last four bits
      to keep current usages same while also use this field
      in added ramp up code.
      
      Adds scsi_handle_queue_ramp_up to ramp up queue_depth on
      successful completion of IO. The scsi_handle_queue_ramp_up will
      do ramp up on all luns of a target, just same as ramp down done
      on all luns on a target.
      
      The ramp up is skipped in case the change_queue_depth is not
      supported by LLD or already reached to added max_queue_depth.
      
      Updates added max_queue_depth on every new update to default
      queue_depth value.
      
      The ramp up is also skipped if lapsed time since either last
      queue ramp up or down is less than LLD specified
      queue_ramp_up_period.
      
      Adds queue_ramp_up_period to sysfs but only if change_queue_depth
      is supported since ramp up and queue_ramp_up_period is needed only
      in case change_queue_depth is supported first.
      
      Initializes queue_ramp_up_period to 120HZ jiffies as initial
      default value, it is same as used in existing lpfc and qla2xxx.
      
      -v2
       Combined all ramp code into this single patch.
      
      -v3
       Moves max_queue_depth initialization after slave_configure is
      called from after slave_alloc calling done. Also adjusted
      max_queue_depth check to skip ramp up if current queue_depth
      is >= max_queue_depth.
      
      -v4
       Changes sdev->queue_ramp_up_period unit to ms when using sysfs i/f
      to store or show its value.
      Signed-off-by: default avatarVasu Dev <vasu.dev@intel.com>
      Tested-by: default avatarChristof Schmitt <christof.schmitt@de.ibm.com>
      Tested-by: default avatarGiridhar Malavali <giridhar.malavali@qlogic.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      4a84067d
  27. 26 Nov, 2009 1 commit
    • James Bottomley's avatar
      [SCSI] fix async scan add/remove race resulting in an oops · 860dc736
      James Bottomley authored
      Async scanning introduced a very wide window where the SCSI device is
      up and running but has not yet been added to sysfs.  We delay the
      adding until all scans have completed to retain the same ordering as
      sync scanning.
      
      This delay in visibility causes an oops if a device is removed before
      we make it visible because the SCSI removal routines have an inbuilt
      assumption that if a device is in SDEV_RUNNING state, it must be
      visible (which is not necessarily true in the async scanning case).
      
      Fix this by introducing an additional is_visible flag which we can use
      to condition the tear down so we do the right thing for running but
      not yet made visible.
      Reported-by: default avatarAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      860dc736
  28. 22 Aug, 2009 2 commits
  29. 12 Mar, 2009 2 commits