1. 28 1月, 2007 1 次提交
    • D
      [SCSI] libsas: Clean up discovery failure handler code · 6f63caae
      Darrick J. Wong 提交于
      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: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      6f63caae
  2. 27 1月, 2007 1 次提交
  3. 14 1月, 2007 3 次提交
  4. 04 12月, 2006 1 次提交
  5. 08 9月, 2006 1 次提交
  6. 28 8月, 2006 1 次提交
    • J
      [SCSI] scsi_transport_sas: remove local_attached flag · f4ad7b58
      James Bottomley 提交于
      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: NJames Bottomley <James.Bottomley@SteelEye.com>
      f4ad7b58
  7. 12 7月, 2006 2 次提交
  8. 09 7月, 2006 1 次提交
    • J
      [SCSI] scsi_transport_sas: add unindexed ports · c9fefeb2
      James Bottomley 提交于
      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: NJames Bottomley <James.Bottomley@SteelEye.com>
      c9fefeb2
  9. 29 6月, 2006 1 次提交
  10. 12 6月, 2006 1 次提交
  11. 10 6月, 2006 1 次提交
  12. 20 5月, 2006 2 次提交
  13. 15 4月, 2006 1 次提交
  14. 13 4月, 2006 2 次提交
  15. 20 3月, 2006 1 次提交
  16. 15 3月, 2006 1 次提交
    • J
      [SCSI] add preliminary expander support to the sas transport class · 79cb1819
      James Bottomley 提交于
      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: NJames Bottomley <James.Bottomley@SteelEye.com>
      79cb1819
  17. 10 3月, 2006 1 次提交
  18. 06 3月, 2006 1 次提交
  19. 03 3月, 2006 2 次提交
  20. 28 2月, 2006 2 次提交
  21. 01 2月, 2006 1 次提交
  22. 15 1月, 2006 3 次提交
  23. 13 1月, 2006 1 次提交
  24. 07 11月, 2005 1 次提交
  25. 29 10月, 2005 3 次提交
  26. 26 9月, 2005 1 次提交
  27. 10 9月, 2005 2 次提交
    • J
    • C
      [SCSI] SAS transport class · c7ebbbce
      Christoph Hellwig 提交于
      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: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      c7ebbbce