This patch adds the ability to add a backlink to a particular port. The
idea is to represent properly ports on expanders that are used
specifically for linking to the parent device in the topology.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
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@SteelEye.com>
this patch introduces a port object, separates out ports and phys,
with ports becoming the primary objects of the tree.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This allows the removal of the contained flag and also does a bit of
class renaming (sas_rphy->sas_device).
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
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@SteelEye.com>
Begin introducing the concept of sas remote devices that have an rphy
embedded. The first one (this) is a simple end device. All that an
end device really does is have port mode page parameters contained.
The next and more complex piece will be expander remote devices.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
I don't think these exist in silicon yet, but the aic94xx driver has a
register setting for them.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Add a flag to mark a PHY as attached to the HBA as opposed to beeing on
an expander. This is needed because various features are only supported
on those. This is a crude hack, the proper fix would be to use
different classes for host-attached vs expander phys. I'm looking into
that.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
For now supporting the ->get_linkerrors method is mandatory. I'll
probably be beaten to implement the .show_foo variables and different
types of attributes soon..
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
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 <hch@lst.de>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
