1. 18 Aug, 2016 2 commits
  2. 18 Dec, 2015 2 commits
  3. 10 May, 2013 1 commit
    • James Bottomley's avatar
      [SCSI] sas: unify the pointlessly separated enums sas_dev_type and sas_device_type · aa9f8328
      James Bottomley authored
      These enums have been separate since the dawn of SAS, mainly because the
      latter is a procotol only enum and the former includes additional state
      for libsas.  The dichotomy causes endless confusion about which one you
      should use where and leads to pointless warnings like this:
      
      drivers/scsi/mvsas/mv_sas.c: In function 'mvs_update_phyinfo':
      drivers/scsi/mvsas/mv_sas.c:1162:34: warning: comparison between 'enum sas_device_type' and 'enum sas_dev_type' [-Wenum-compare]
      
      Fix by eliminating one of them.  The one kept is effectively the sas.h
      one, but call it sas_device_type and make sure the enums are all
      properly namespaced with the SAS_ prefix.
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      aa9f8328
  4. 01 Dec, 2012 1 commit
  5. 29 Feb, 2012 1 commit
    • Dan Williams's avatar
      [SCSI] libsas: fix sas_find_local_phy(), take phy references · f41a0c44
      Dan Williams authored
      In the direct-attached case this routine returns the phy on which this
      device was first discovered.  Which is broken if we want to support
      wide-targets, as this phy reference can become stale even though the
      port is still active.
      
      In the expander-attached case this routine tries to lookup the phy by
      scanning the attached sas addresses of the parent expander, and BUG_ONs
      if it can't find it.  However since eh and the libsas workqueue run
      independently we can still be attempting device recovery via eh after
      libsas has recorded the device as detached.  This is even easier to hit
      now that eh is blocked while device domain rediscovery takes place, and
      that libata is fed more timed out commands increasing the chances that
      it will try to recover the ata device.
      
      Arrange for dev->phy to always point to a last known good phy, it may be
      stale after the port is torn down, but it will catch up for wide port
      reconfigurations, and never be NULL.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      f41a0c44
  6. 19 Feb, 2012 2 commits
    • Dan Williams's avatar
      [SCSI] libsas: perform sas-transport resets in shost->workq context · 0b3e09da
      Dan Williams authored
      Extend the sas transport class to allow transport users to attach extra
      data to a sas_phy (->hostdata).  Use this area in libsas to move resets
      to workq context in preparation for scheduling ata device resets through
      libata-eh.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      0b3e09da
    • Dan Williams's avatar
      [SCSI] libsas: prevent domain rediscovery competing with ata error handling · 87c8331f
      Dan Williams authored
      libata error handling provides for a timeout for link recovery.  libsas
      must not rescan for previously known devices in this interval otherwise
      it may remove a device that is simply waiting for its link to recover.
      Let libata-eh make the determination of when the link is stable and
      prevent libsas (host workqueue) from taking action while this
      determination is pending.
      
      Using a mutex (ha->disco_mutex) to flush and disable revalidation while
      eh is running requires any discovery action that may block on eh be
      moved to its own context outside the lock.  Probing ATA devices
      explicitly waits on ata-eh and the cache-flush-io issued during device
      removal may also pend awaiting eh completion.  Essentially any rphy
      add/remove activity needs to run outside the lock.
      
      This adds two new cleanup states for sas_unregister_domain_devices()
      'allocated-but-not-probed', and 'flagged-for-destruction'.  In the
      'allocated-but-not-probed' state  dev->rphy points to a rphy that is
      known to have not been through a sas_rphy_add() event.  At domain
      teardown check if this device is still pending probe and cleanup
      accordingly.  Similarly if a device has already been queued for removal
      then sas_unregister_domain_devices has nothing to do.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
      87c8331f
  7. 08 Feb, 2010 1 commit
  8. 19 Apr, 2008 1 commit
  9. 11 Jan, 2008 2 commits
  10. 20 Jul, 2007 1 commit
  11. 18 Jul, 2007 2 commits
  12. 27 Jan, 2007 1 commit
    • Darrick J. Wong's avatar
      [SCSI] libsas: Clean up discovery failure handler code · 6f63caae
      Darrick J. Wong authored
      sas_rphy_delete does two things: it removes the sas_rphy from the transport
      layer and frees the sas_rphy.  This can be broken down into two functions,
      sas_rphy_remove and sas_rphy_free; sas_rphy_remove is of interest to
      sas_discover_root_expander because it calls functions that require
      sas_rphy_add as a prerequisite and can fail (namely sas_discover_expander).
      In that case, sas_discover_root_expander needs to be able to undo the effects
      of sas_rphy_add yet leave the job of freeing the sas_rphy to the caller of
      sas_discover_root_expander.
      
      This patch also removes some unnecessary code from sas_discover_end_dev
      to eliminate an unnecessary cycle of sas_notify_lldd_gone/found for SAS
      devices, thus eliminating a sas_rphy_remove call (and fixing a race condition
      where a SCSI target scan can come in between the gone and found call).
      It also moves the sas_rphy_free calls into sas_discover_domain and
      sas_ex_discover_end_dev to complement the sas_rphy_allocation via
      sas_get_port_device.
      
      This patch does not change the semantics of sas_rphy_delete.
      Signed-off-by: default avatarDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      6f63caae
  13. 13 Jan, 2007 1 commit
  14. 22 Nov, 2006 1 commit
    • Darrick J. Wong's avatar
      [PATCH] aic94xx: handle REQ_DEVICE_RESET · dea22214
      Darrick J. Wong authored
      This patch implements a REQ_DEVICE_RESET handler for the aic94xx
      driver.  Like the earlier REQ_TASK_ABORT patch, this patch defers the
      device reset to the Scsi_Host's workqueue, which has the added benefit
      of ensuring that the device reset does not happen at the same time
      that the abort tmfs are being processed.  After the phy reset, the
      busted drive should go away and be re-detected later, which is indeed
      what I've seen on both a x260 and a x206m.
      Signed-off-by: default avatarDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      dea22214
  15. 07 Sep, 2006 2 commits
  16. 27 Aug, 2006 1 commit
    • James Bottomley's avatar
      [SCSI] scsi_transport_sas: remove local_attached flag · f4ad7b58
      James Bottomley authored
      This flag denotes local attachment of the phy.  There are two problems
      with it:
      
      1) It's actually redundant ... you can get the same information simply
      by seeing whether a host is the phys parent
      2) we condition a lot of phy parameters on it on the false assumption
      that we can only control local phys.  I'm wiring up phy resets in the
      aic94xx now, and it will be able to reset non-local phys as well.
      
      I fixed 2) by moving the local check into the reset and stats function
      of the mptsas, since that seems to be the only HBA that can't
      (currently) control non-local phys.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      f4ad7b58
  17. 12 Jul, 2006 1 commit
  18. 09 Jul, 2006 1 commit
    • James Bottomley's avatar
      [SCSI] scsi_transport_sas: add unindexed ports · c9fefeb2
      James Bottomley authored
      Some SAS HBAs don't want to go to the trouble of tracking port numbers,
      so they'd simply like to say "add this port and give it a number".
      This is especially beneficial from the hotplug point of view, since
      tracking ports and the available number space can be a real pain.
      
      The current implementation uses an incrementing number per expander to
      add the port on.  However, since there can never be more ports than
      there are phys, a later implementation will try to be more intelligent
      about this.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      c9fefeb2
  19. 28 Jun, 2006 1 commit
  20. 19 Mar, 2006 1 commit
  21. 14 Mar, 2006 1 commit
    • James Bottomley's avatar
      [SCSI] add preliminary expander support to the sas transport class · 79cb1819
      James Bottomley authored
      This patch makes expanders appear as labelled objects with properties in
      the SAS tree.
      
      I've also modified the phy code to make expander phys appear labelled by
      host number, expander number and phy index.
      
      So, for my current config, you see something like this in sysfs:
      
      /sys/class/scsi_host/host1/device/phy-1:4/expander-1:0/phy-1-0:12/rphy-1:0-12/target1:0:1
      
      And the expander properties are:
      
      jejb@sparkweed> cd /sys/class/sas_expander/expander-1\:0/
      jejb@sparkweed> for f in *; do echo -n $f ": "; cat $f; done
      component_id : 29024
      component_revision_id : 4
      component_vendor_id : VITESSE
      device : cat: device: Is a directory
      level : 0
      product_id : VSC7160 Eval Brd
      product_rev : 4
      uevent : cat: uevent: Permission denied
      vendor_id : VITESSE
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      79cb1819
  22. 06 Mar, 2006 1 commit
  23. 02 Mar, 2006 1 commit
  24. 27 Feb, 2006 1 commit
  25. 28 Oct, 2005 3 commits
  26. 09 Sep, 2005 1 commit
    • Christoph Hellwig's avatar
      [SCSI] SAS transport class · c7ebbbce
      Christoph Hellwig authored
      The SAS transport class contains common code to deal with SAS HBAs, an
      aproximated representation of SAS topologies in the driver model,
      and various sysfs attributes to expose these topologies and managment
      interfaces to userspace.
      
      In addition to the basic SCSI core objects this transport class introduces
      two additional intermediate objects:  The SAS PHY as represented by struct
      sas_phy defines an "outgoing" PHY on a SAS HBA or Expander, and the SAS
      remote PHY represented by struct sas_rphy defines an "incoming" PHY on a
      SAS Expander or end device.  Note that this is purely a software concept, the
      underlying hardware for a PHY and a remote PHY is the exactly the same.
      
      There is no concept of a SAS port in this code, users can see what PHYs
      form a wide port based on the port_identifier attribute, which is the same
      for all PHYs in a port.
      
      This submission doesn't handle hot-plug addition or removal of SAS devices
      and thus doesn't do scanning in a workqueue yet, that will be added in
      phase2 after this submission.  In a third phase I will add additional
      managment infrastructure.
      
      I think this submission is ready for 2.6.14, but additional comments are
      of course very welcome.
      
      I'd like to thanks James Smart a lot for his very useful input on the
      design.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      c7ebbbce