Eric Lee / smarc-fsl-linux-kernel

09 Feb, 2010

1 commit

20 Apr, 2008

1 commit

12 Jan, 2008

2 commits

21 Jul, 2007

1 commit

  • b6aff6695   [SCSI] scsi_transport_sas: add destructor for bsg ... Browse Code »

    There's currently no destructor for the bsg components. If you insert
    and remove the module, you see the bsg devices building up and up. This
    patch adds the destructor in the correct place in the transport class so
    that the bsg and request queue are removed just before the device
    destruction.

    Acked-by: FUJITA Tomonori
    Signed-off-by: James Bottomley

    James Bottomley
     

19 Jul, 2007

2 commits

  • 7aa68e80b   [SCSI] transport_sas: add SAS management protocol support ... Browse Code »

    The sas transport class attaches one bsg device to every SAS object
    (host, device, expander, etc). LLDs can define a function to handle
    SMP requests via sas_function_template::smp_handler.

    Signed-off-by: FUJITA Tomonori
    Signed-off-by: James Bottomley

    FUJITA Tomonori
     
  • 0f05df8b3   [SCSI] libsas, aic94xx: fix dma mapping cockups with ATA ... Browse Code »

    This one was noticed by Gilbert Wu of Adaptec:

    The libata core actually does the DMA mapping for you, so there has to
    be an exception in the device drivers that *don't* do dma mapping for
    ATA commands. However, since we've already done this, libsas must now
    dma map any ATA commands that it wishes to issue ... and yes, this is a
    horrible mess.

    Additionally, the test in aic94xx for ATA protocols isn't quite right.

    Signed-off-by: James Bottomley

    James Bottomley
     

28 Jan, 2007

1 commit

  • 6f63caae2   [SCSI] libsas: Clean up discovery failure handler code ... Browse Code »

    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: Darrick J. Wong
    Signed-off-by: James Bottomley

    Darrick J. Wong
     

14 Jan, 2007

1 commit

23 Nov, 2006

1 commit

  • dea222147   [PATCH] aic94xx: handle REQ_DEVICE_RESET ... Browse Code »

    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: Darrick J. Wong
    Signed-off-by: James Bottomley

    Darrick J. Wong
     

08 Sep, 2006

2 commits

28 Aug, 2006

1 commit

  • f4ad7b580   [SCSI] scsi_transport_sas: remove local_attached flag ... Browse Code »

    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: James Bottomley

    James Bottomley
     

12 Jul, 2006

1 commit

09 Jul, 2006

1 commit

  • c9fefeb26   [SCSI] scsi_transport_sas: add unindexed ports ... Browse Code »

    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: James Bottomley

    James Bottomley
     

29 Jun, 2006

1 commit

20 Mar, 2006

1 commit

15 Mar, 2006

1 commit

  • 79cb1819e   [SCSI] add preliminary expander support to the sas transport class ... Browse Code »

    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: James Bottomley

    James Bottomley
     

06 Mar, 2006

1 commit

03 Mar, 2006

1 commit

28 Feb, 2006

1 commit

29 Oct, 2005

3 commits

10 Sep, 2005

1 commit

  • c7ebbbce3   [SCSI] SAS transport class ... Browse Code »

    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: Christoph Hellwig
    Signed-off-by: James Bottomley

    Christoph Hellwig