- 15 3月, 2006 1 次提交
-
-
由 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>
-
- 06 3月, 2006 1 次提交
-
-
由 James Bottomley 提交于
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: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 03 3月, 2006 1 次提交
-
-
由 James Bottomley 提交于
I don't think these exist in silicon yet, but the aic94xx driver has a register setting for them. Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 28 2月, 2006 1 次提交
-
-
由 Christoph Hellwig 提交于
Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 29 10月, 2005 3 次提交
-
-
由 Christoph Hellwig 提交于
Signed-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Christoph Hellwig 提交于
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: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
由 Christoph Hellwig 提交于
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: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
-
- 10 9月, 2005 1 次提交
-
-
由 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>
-