08 Sep, 2006

2 commits


28 Aug, 2006

1 commit

  • 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

  • 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

  • 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

  • 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