1. 10 5月, 2013 1 次提交
    • J
      [SCSI] sas: unify the pointlessly separated enums sas_dev_type and sas_device_type · aa9f8328
      James Bottomley 提交于
      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: NJames Bottomley <JBottomley@Parallels.com>
      aa9f8328
  2. 24 8月, 2012 1 次提交
    • D
      [SCSI] libsas: suspend / resume support · 303694ee
      Dan Williams 提交于
      libsas power management routines to suspend and recover the sas domain
      based on a model where the lldd is allowed and expected to be
      "forgetful".
      
      sas_suspend_ha - disable event processing allowing the lldd to take down
                       links without concern for causing hotplug events.
                       Regardless of whether the lldd actually posts link down
                       messages libsas notifies the lldd that all
                       domain_devices are gone.
      
      sas_prep_resume_ha - on the way back up before the lldd starts link
                           training clean out any spurious events that were
                           generated on the way down, and re-enable event
                           processing
      
      sas_resume_ha - after the lldd has started and decided that all phys
      		have posted link-up events this routine is called to let
      		libsas start it's own timeout of any phys that did not
      		resume.  After the timeout an lldd can cancel the
                      phy teardown by posting a link-up event.
      
      Storage for ex_change_count (u16) and phy_change_count (u8) are changed
      to int so they can be set to -1 to indicate 'invalidated'.
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Reviewed-by: NJacek Danecki <jacek.danecki@intel.com>
      Tested-by: NMaciej Patelczyk <maciej.patelczyk@intel.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      303694ee
  3. 23 4月, 2012 2 次提交
    • D
      [SCSI] Revert "[SCSI] libsas: fix sas port naming" · b4698d88
      Dan Williams 提交于
      This reverts commit a692b0ee.
      
      Tom reports:
      
      [    8.741033] ------------[ cut here ]------------
      [    8.741038] WARNING: at fs/sysfs/dir.c:508 sysfs_add_one+0xc1/0xf0()
      [    8.741040] Hardware name: To Be Filled By O.E.M.
      [    8.741041] sysfs: cannot create duplicate filename
      
      ...and missing 2 out of 4 drives connected to mvsas.  Commit a692b0ee
      made the assumption that all the phy ids an lldd registers to libsas are
      unique.  However, in the "multi-chip" case mvsas does a rather annoying
      duplication of phy ids in the array passed to libsas.  So, for example,
      chip0 has phy0-3 at ha phy index 0-3 and chip1 has its phy0-3 at ha phy
      index 4-7.  The more natural model would be to create a scsi_host (and
      sas_ha) per chip (controller), but for now revert the naming fix which
      unfortunately means dealing with unpredictable end-device names for a
      bit longer.
      
      Cc: Xiangliang Yu <yuxiangl@marvell.com>
      Cc: Patrick Thomson <patrick.s.thomson@intel.com>
      Reported-by: NTom Rini <trini@ti.com>
      Tested-by: NTom Rini <trini@ti.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      b4698d88
    • D
      [SCSI] libsas: introduce sas_work to fix sas_drain_work vs sas_queue_work · 22b9153f
      Dan Williams 提交于
      When requeuing work to a draining workqueue the last work instance may
      not be idle, so sas_queue_work() must not touch work->entry.  Introduce
      sas_work with a drain_node list_head to have a private list for
      collecting work deferred due to drain collision.
      
      Fixes reports like:
        BUG: unable to handle kernel NULL pointer dereference at           (null)
        IP: [<ffffffff810410d4>] process_one_work+0x2e/0x338
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      22b9153f
  4. 01 3月, 2012 4 次提交
  5. 20 2月, 2012 3 次提交
  6. 27 5月, 2011 1 次提交
  7. 22 12月, 2010 1 次提交
  8. 17 7月, 2009 1 次提交
  9. 03 1月, 2009 1 次提交
  10. 27 7月, 2008 1 次提交
  11. 24 2月, 2008 1 次提交
    • J
      [SCSI] libsas: use the supplied address for SATA devices rather than changing it · a29c0515
      James Bottomley 提交于
      Once the phy reset is plumbed in properly, SATA error handling fails
      nastily because we change the port attached_sas_address using the WWN
      field of the IDENTIFY message.  This is a nice thing to do in theory,
      but it really destroys hotplug because any event on the port causes an
      automatic mismatch between the sas_address the phy just picked up and
      the one we propagate into the port.  However ugly they are, we have to
      stick with the sas addresses made up by the phys and expanders.
      
      Also does a few cosmetic changes to the way port printing is done to
      make it clearer how a port is formed.
      Signed-off-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
      a29c0515
  12. 28 1月, 2007 1 次提交
    • D
      [SCSI] libsas: Fix incorrect sas_port deformation in sas_form_port · 3b6e9faf
      Darrick J. Wong 提交于
      Currently, sas_form_port checks the given asd_sas_phy's sas_phy to see if
      there's already a port attached.  If so, the SAS addresses of the port and
      the phy are compared to determine if we need to detach from the port
      because the addresses don't match or if we can stop; the SAS address stored
      in the sas_port reflects whatever device _was_ attached to the port/phy, and
      the SAS address stored in the sas_port reflects whatever device we just
      discovered.  As written, the code detaches from the port if the addresses
      _do_ match, and prints an error if they do _not_ match.  I believe this to
      be incorrect, as it seems more logical to keep the port if the addresses
      match (i.e. the phy was reset but the device didn't change), and detach it
      they do not (i.e. the device changed).
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      3b6e9faf
  13. 14 1月, 2007 1 次提交
  14. 22 11月, 2006 1 次提交
  15. 29 8月, 2006 1 次提交
    • J
      [SCSI] aic94xx: new driver · 2908d778
      James Bottomley 提交于
      This is the end point of the separate aic94xx driver based on the
      original driver and transport class from Luben Tuikov
      <ltuikov@yahoo.com>
      
      The log of the separate development is:
      
      Alexis Bruemmer:
        o aic94xx: fix hotplug/unplug for expanderless systems
        o aic94xx: disable split completion timer/setting by default
        o aic94xx: wide port off expander support
        o aic94xx: remove various inline functions
        o aic94xx: use bitops
        o aic94xx: remove queue comment
        o aic94xx: remove sas_common.c
        o aic94xx: sas remove depot's
        o aic94xx: use available list_for_each_entry_safe_reverse()
        o aic94xx: sas header file merge
      
      James Bottomley:
        o aic94xx: fix TF_TMF_NO_CTX processing
        o aic94xx: convert to request_firmware interface
        o aic94xx: fix hotplug/unplug
        o aic94xx: add link error counts to the expander phys
        o aic94xx: add transport class phy reset capability
        o aic94xx: remove local_attached flag
        o Remove README
        o Fixup Makefile variable for libsas rename
        o Rename sas->libsas
        o aic94xx: correct return code for sas_discover_event
        o aic94xx: use parent backlink port
        o aic94xx: remove channel abstraction
        o aic94xx: fix routing algorithms
        o aic94xx: add backlink port
        o aic94xx: fix cascaded expander properties
        o aic94xx: fix sleep under lock
        o aic94xx: fix panic on module removal in complex topology
        o aic94xx: make use of the new sas_port
        o rename sas_port to asd_sas_port
        o Fix for eh_strategy_handler move
        o aic94xx: move entirely over to correct transport class formulation
        o remove last vestages of sas_rphy_alloc()
        o update for eh_timed_out move
        o Preliminary expander support for aic94xx
        o sas: remove event thread
        o minor warning cleanups
        o remove last vestiges of id mapping arrays
        o Further updates
        o Convert aic94xx over entirely to the transport class end device and
        o update aic94xx/sas to use the new sas transport class end device
        o [PATCH] aic94xx: attaching to the sas transport class
        o Add missing completion removal from prior patch
        o [PATCH] aic94xx: attaching to the sas transport class
        o Build fixes from akpm
      
      Jeff Garzik:
        o [scsi aic94xx] Remove ->owner from PCI info table
      
      Luben Tuikov:
        o initial aic94xx driver
      
      Mike Anderson:
        o aic94xx: fix panic on module insertion
        o aic94xx: stub out SATA_DEV case
        o aic94xx: compile warning cleanups
        o aic94xx: sas_alloc_task
        o aic94xx: ref count update
        o aic94xx nexus loss time value
        o [PATCH] aic94xx: driver assertion in non-x86 BIOS env
      
      Randy Dunlap:
        o libsas: externs not needed
      
      Robert Tarte:
        o aic94xx: sequence patch - fixes SATA support
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      2908d778