public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] aic94xx: make use of the new sas_port
@ 2006-05-31  4:09 James Bottomley
  2006-05-31 19:46 ` Alexis Bruemmer
  0 siblings, 1 reply; 11+ messages in thread
From: James Bottomley @ 2006-05-31  4:09 UTC (permalink / raw)
  To: linux-scsi

This one is slightly tricky.  The aic94xx driver has a natural sas_port
at the HBA level, but it doesn't have any concept of a sas_port at the
expander level.  Since this is just a proof of concept I just rammed one
in there; however a bit more careful work will have to be done to make
this clean.

James

diff --git a/drivers/scsi/sas/sas_discover.c b/drivers/scsi/sas/sas_discover.c
index 9dd72c5..b9018b7 100644
--- a/drivers/scsi/sas/sas_discover.c
+++ b/drivers/scsi/sas/sas_discover.c
@@ -237,13 +237,15 @@ static int sas_get_port_device(struct as
 
 	switch (dev->dev_type) {
 	case SAS_END_DEV:
-		rphy = sas_end_device_alloc(phy->phy);
+		rphy = sas_end_device_alloc(port->port);
 		break;
 	case EDGE_DEV:
-		rphy = sas_expander_alloc(phy->phy, SAS_EDGE_EXPANDER_DEVICE);
+		rphy = sas_expander_alloc(port->port,
+					  SAS_EDGE_EXPANDER_DEVICE);
 		break;
 	case FANOUT_DEV:
-		rphy = sas_expander_alloc(phy->phy, SAS_FANOUT_EXPANDER_DEVICE);
+		rphy = sas_expander_alloc(port->port,
+					  SAS_FANOUT_EXPANDER_DEVICE);
 		break;
 	default:
 		printk("ERROR: Unidentified device type %d\n", dev->dev_type);
@@ -580,10 +582,6 @@ int sas_discover_end_dev(struct domain_d
 	if (res)
 		return res;
 
-
-	if (!res) {
-	}
-
 	res = sas_rphy_add(dev->rphy);
 	if (res)
 		goto out_err;
diff --git a/drivers/scsi/sas/sas_expander.c b/drivers/scsi/sas/sas_expander.c
index e716d50..5e3ba2f 100644
--- a/drivers/scsi/sas/sas_expander.c
+++ b/drivers/scsi/sas/sas_expander.c
@@ -151,7 +151,6 @@ static void sas_set_ex_phy(struct domain
 	struct sas_rphy *rphy = dev->rphy;
 
 	phy->phy = sas_phy_alloc(&rphy->dev, phy_id);
-	dev_printk(KERN_ERR, &phy->phy->dev, "ALLOCATED\n\n");
 
 	/* FIXME: error_handling */
 	BUG_ON(!phy->phy);
@@ -271,18 +270,24 @@ out_err:
 static int sas_expander_discover(struct domain_device *dev)
 {
 	struct expander_device *ex = &dev->ex_dev;
-	int res;
+	int res = -ENOMEM;
 
 	ex->ex_phy = kzalloc(sizeof(*ex->ex_phy)*ex->num_phys, GFP_KERNEL);
 	if (!ex->ex_phy)
 		return -ENOMEM;
+	ex->ex_port = kzalloc(sizeof(void *)*ex->num_phys, GFP_KERNEL);
+	if (!ex->ex_port)
+		goto out_free_phys;
 
 	res = sas_ex_phy_discover(dev, -1);
 	if (res)
 		goto out_err;
 
 	return 0;
-out_err:
+ out_err:
+	kfree(ex->ex_port);
+	ex->ex_port = NULL;
+ out_free_phys:
 	kfree(ex->ex_phy);
 	ex->ex_phy = NULL;
 	return res;
@@ -513,10 +518,20 @@ static inline void sas_ex_get_linkrate(s
 				       struct ex_phy *parent_phy)
 {
 	struct expander_device *parent_ex = &parent->ex_dev;
+	struct sas_port *port;
 	int i;
 
 	child->pathways = 0;
 
+	for (i = 0; i < parent_ex->num_phys; i++)
+		if (!parent_ex->ex_port[i])
+			break;
+
+	parent_ex->ex_port[i] = port = sas_port_alloc(&parent->rphy->dev, i);
+	BUG_ON(!port);
+	/* FIXME: better error handling */
+	BUG_ON(sas_port_add(port) != 0);
+		
 	for (i = 0; i < parent_ex->num_phys; i++) {
 		struct ex_phy *phy = &parent_ex->ex_phy[i];
 
@@ -532,6 +547,9 @@ static inline void sas_ex_get_linkrate(s
 			child->max_linkrate = max(parent->max_linkrate,
 						  phy->linkrate);
 			child->pathways++;
+			BUG_ON(phy->port != NULL);
+			phy->port = port;
+			sas_port_add_phy(port, phy->phy);
 		}
 	}
 	child->linkrate = min(parent_phy->linkrate, child->max_linkrate);
@@ -590,7 +608,7 @@ static struct domain_device *sas_ex_disc
 		}
 	} else if (phy->attached_tproto & SAS_PROTO_SSP) {
 		child->dev_type = SAS_END_DEV;
-		rphy = sas_end_device_alloc(phy->phy);
+		rphy = sas_end_device_alloc(phy->port);
 		/* FIXME: error handling */
 		BUG_ON(!rphy);
 		child->tproto = phy->attached_tproto;
@@ -613,7 +631,8 @@ static struct domain_device *sas_ex_disc
 				    "at %016llx:0x%x returned 0x%x\n",
 				    SAS_ADDR(child->sas_addr),
 				    SAS_ADDR(parent->sas_addr), phy_id, res);
-			kfree(child);
+			/* FIXME: this kfrees list elements without removing them */
+			//kfree(child);
 			return NULL;
 		}
 	} else {
@@ -649,10 +668,12 @@ static struct domain_device *sas_ex_disc
 		return NULL;
 	switch (phy->attached_dev_type) {
 	case EDGE_DEV:
-		rphy = sas_expander_alloc(phy->phy, SAS_EDGE_EXPANDER_DEVICE);
+		rphy = sas_expander_alloc(phy->port,
+					  SAS_EDGE_EXPANDER_DEVICE);
 		break;
 	case FANOUT_DEV:
-		rphy = sas_expander_alloc(phy->phy, SAS_FANOUT_EXPANDER_DEVICE);
+		rphy = sas_expander_alloc(phy->port,
+					  SAS_FANOUT_EXPANDER_DEVICE);
 		break;
 	default:
 		rphy = NULL;	/* shut gcc up */
diff --git a/drivers/scsi/sas/sas_port.c b/drivers/scsi/sas/sas_port.c
index 1a042f9..da4599d 100644
--- a/drivers/scsi/sas/sas_port.c
+++ b/drivers/scsi/sas/sas_port.c
@@ -84,13 +84,19 @@ static void sas_form_port(struct asd_sas
 		return;
 	}
 
+	if (!port->port) {
+		port->port = sas_port_alloc(phy->phy->dev.parent, port->id);
+		BUG_ON(!port->port);
+		sas_port_add(port->port);
+	}
+	sas_port_add_phy(port->port, phy->phy);
+
 	/* add the phy to the port */
 	list_add_tail(&phy->port_phy_el, &port->phy_list);
 	phy->port = port;
 	port->num_phys++;
 	port->phy_mask |= (1U << phy->id);
 
-	phy->phy->port_identifier = port->id;
 	if (!port->phy)
 		port->phy = phy->phy;
 
@@ -141,6 +147,7 @@ void sas_deform_port(struct asd_sas_phy 
 		port->port_dev->pathways--;
 
 	if (port->num_phys == 1) {
+		sas_port_delete(port->port);
 		init_completion(&port->port_gone_completion);
 		sas_discover_event(port, DISCE_PORT_GONE);
 		wait_for_completion(&port->port_gone_completion);
@@ -149,6 +156,8 @@ void sas_deform_port(struct asd_sas_phy 
 	if (si->dft->lldd_port_deformed)
 		si->dft->lldd_port_deformed(phy);
 
+	sas_port_delete_phy(port->port, phy->phy);
+
 	spin_lock(&sas_ha->phy_port_lock);
 	spin_lock(&port->phy_list_lock);
 
diff --git a/include/scsi/sas/sas_class.h b/include/scsi/sas/sas_class.h
index 0c3aae5..4b56259 100644
--- a/include/scsi/sas/sas_class.h
+++ b/include/scsi/sas/sas_class.h
@@ -180,6 +180,8 @@ struct asd_sas_port {
 
 	struct sas_ha_struct *ha;
 
+	struct sas_port	*port;
+
 	void *lldd_port;	  /* not touched by the sas class code */
 };
 
diff --git a/include/scsi/sas/sas_expander.h b/include/scsi/sas/sas_expander.h
index e83b41c..6ce6163 100644
--- a/include/scsi/sas/sas_expander.h
+++ b/include/scsi/sas/sas_expander.h
@@ -72,6 +72,7 @@ struct ex_phy {
 	int  last_da_index;
 
 	struct sas_phy *phy;
+	struct sas_port *port;
 };
 
 struct expander_device {
@@ -85,6 +86,7 @@ struct expander_device {
 	u8     enclosure_logical_id[8];
 
 	struct ex_phy *ex_phy;
+	struct sas_port **ex_port;
 };
 
 int  sas_discover_root_expander(struct domain_device *dev);



^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31  4:09 [PATCH] aic94xx: make use of the new sas_port James Bottomley
@ 2006-05-31 19:46 ` Alexis Bruemmer
  2006-05-31 20:57   ` James Bottomley
  2006-05-31 21:32   ` Douglas Gilbert
  0 siblings, 2 replies; 11+ messages in thread
From: Alexis Bruemmer @ 2006-05-31 19:46 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-scsi

These patches look good and are running on our x260 and the ppc64
(power).  I was just wondering about a few things under the sys/class/:

there is a sas_device, sas_end_device, and a sas_expander dir.
sas_device contains the same info as sas_end_device, and a sas_expander
can we eliminate one or the other?  Or was this a design choice?

Also during the boot process on the x260 with an expander we see these
printk's:
sas: phy[n] matched wide port0
If we are going to print this then we better be sure that this is truly
a wide port.  It seems under the sys/class/ we have both a single
port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n].  and
although each phy seems to have the same sas_address the end_device
attached to that phy have unique addresses.  My understanding is that a
wide port has multiple phys with the same sas address and are attached
to one end device.  I believe that the expander situation is not the
same as wide port.  If this is the case then it is as simple as changing
the printk statement to not say "wide port"

I am more than happy to make these changes if everyone agrees that they
should be made.

Thanks,

Alexis 


On Tue, 2006-05-30 at 23:09 -0500, James Bottomley wrote:
> This one is slightly tricky.  The aic94xx driver has a natural sas_port
> at the HBA level, but it doesn't have any concept of a sas_port at the
> expander level.  Since this is just a proof of concept I just rammed one
> in there; however a bit more careful work will have to be done to make
> this clean.
> 
> James
> 
> diff --git a/drivers/scsi/sas/sas_discover.c b/drivers/scsi/sas/sas_discover.c
> index 9dd72c5..b9018b7 100644
> --- a/drivers/scsi/sas/sas_discover.c
> +++ b/drivers/scsi/sas/sas_discover.c
> @@ -237,13 +237,15 @@ static int sas_get_port_device(struct as
>  
>  	switch (dev->dev_type) {
>  	case SAS_END_DEV:
> -		rphy = sas_end_device_alloc(phy->phy);
> +		rphy = sas_end_device_alloc(port->port);
>  		break;
>  	case EDGE_DEV:
> -		rphy = sas_expander_alloc(phy->phy, SAS_EDGE_EXPANDER_DEVICE);
> +		rphy = sas_expander_alloc(port->port,
> +					  SAS_EDGE_EXPANDER_DEVICE);
>  		break;
>  	case FANOUT_DEV:
> -		rphy = sas_expander_alloc(phy->phy, SAS_FANOUT_EXPANDER_DEVICE);
> +		rphy = sas_expander_alloc(port->port,
> +					  SAS_FANOUT_EXPANDER_DEVICE);
>  		break;
>  	default:
>  		printk("ERROR: Unidentified device type %d\n", dev->dev_type);
> @@ -580,10 +582,6 @@ int sas_discover_end_dev(struct domain_d
>  	if (res)
>  		return res;
>  
> -
> -	if (!res) {
> -	}
> -
>  	res = sas_rphy_add(dev->rphy);
>  	if (res)
>  		goto out_err;
> diff --git a/drivers/scsi/sas/sas_expander.c b/drivers/scsi/sas/sas_expander.c
> index e716d50..5e3ba2f 100644
> --- a/drivers/scsi/sas/sas_expander.c
> +++ b/drivers/scsi/sas/sas_expander.c
> @@ -151,7 +151,6 @@ static void sas_set_ex_phy(struct domain
>  	struct sas_rphy *rphy = dev->rphy;
>  
>  	phy->phy = sas_phy_alloc(&rphy->dev, phy_id);
> -	dev_printk(KERN_ERR, &phy->phy->dev, "ALLOCATED\n\n");
>  
>  	/* FIXME: error_handling */
>  	BUG_ON(!phy->phy);
> @@ -271,18 +270,24 @@ out_err:
>  static int sas_expander_discover(struct domain_device *dev)
>  {
>  	struct expander_device *ex = &dev->ex_dev;
> -	int res;
> +	int res = -ENOMEM;
>  
>  	ex->ex_phy = kzalloc(sizeof(*ex->ex_phy)*ex->num_phys, GFP_KERNEL);
>  	if (!ex->ex_phy)
>  		return -ENOMEM;
> +	ex->ex_port = kzalloc(sizeof(void *)*ex->num_phys, GFP_KERNEL);
> +	if (!ex->ex_port)
> +		goto out_free_phys;
>  
>  	res = sas_ex_phy_discover(dev, -1);
>  	if (res)
>  		goto out_err;
>  
>  	return 0;
> -out_err:
> + out_err:
> +	kfree(ex->ex_port);
> +	ex->ex_port = NULL;
> + out_free_phys:
>  	kfree(ex->ex_phy);
>  	ex->ex_phy = NULL;
>  	return res;
> @@ -513,10 +518,20 @@ static inline void sas_ex_get_linkrate(s
>  				       struct ex_phy *parent_phy)
>  {
>  	struct expander_device *parent_ex = &parent->ex_dev;
> +	struct sas_port *port;
>  	int i;
>  
>  	child->pathways = 0;
>  
> +	for (i = 0; i < parent_ex->num_phys; i++)
> +		if (!parent_ex->ex_port[i])
> +			break;
> +
> +	parent_ex->ex_port[i] = port = sas_port_alloc(&parent->rphy->dev, i);
> +	BUG_ON(!port);
> +	/* FIXME: better error handling */
> +	BUG_ON(sas_port_add(port) != 0);
> +		
>  	for (i = 0; i < parent_ex->num_phys; i++) {
>  		struct ex_phy *phy = &parent_ex->ex_phy[i];
>  
> @@ -532,6 +547,9 @@ static inline void sas_ex_get_linkrate(s
>  			child->max_linkrate = max(parent->max_linkrate,
>  						  phy->linkrate);
>  			child->pathways++;
> +			BUG_ON(phy->port != NULL);
> +			phy->port = port;
> +			sas_port_add_phy(port, phy->phy);
>  		}
>  	}
>  	child->linkrate = min(parent_phy->linkrate, child->max_linkrate);
> @@ -590,7 +608,7 @@ static struct domain_device *sas_ex_disc
>  		}
>  	} else if (phy->attached_tproto & SAS_PROTO_SSP) {
>  		child->dev_type = SAS_END_DEV;
> -		rphy = sas_end_device_alloc(phy->phy);
> +		rphy = sas_end_device_alloc(phy->port);
>  		/* FIXME: error handling */
>  		BUG_ON(!rphy);
>  		child->tproto = phy->attached_tproto;
> @@ -613,7 +631,8 @@ static struct domain_device *sas_ex_disc
>  				    "at %016llx:0x%x returned 0x%x\n",
>  				    SAS_ADDR(child->sas_addr),
>  				    SAS_ADDR(parent->sas_addr), phy_id, res);
> -			kfree(child);
> +			/* FIXME: this kfrees list elements without removing them */
> +			//kfree(child);
>  			return NULL;
>  		}
>  	} else {
> @@ -649,10 +668,12 @@ static struct domain_device *sas_ex_disc
>  		return NULL;
>  	switch (phy->attached_dev_type) {
>  	case EDGE_DEV:
> -		rphy = sas_expander_alloc(phy->phy, SAS_EDGE_EXPANDER_DEVICE);
> +		rphy = sas_expander_alloc(phy->port,
> +					  SAS_EDGE_EXPANDER_DEVICE);
>  		break;
>  	case FANOUT_DEV:
> -		rphy = sas_expander_alloc(phy->phy, SAS_FANOUT_EXPANDER_DEVICE);
> +		rphy = sas_expander_alloc(phy->port,
> +					  SAS_FANOUT_EXPANDER_DEVICE);
>  		break;
>  	default:
>  		rphy = NULL;	/* shut gcc up */
> diff --git a/drivers/scsi/sas/sas_port.c b/drivers/scsi/sas/sas_port.c
> index 1a042f9..da4599d 100644
> --- a/drivers/scsi/sas/sas_port.c
> +++ b/drivers/scsi/sas/sas_port.c
> @@ -84,13 +84,19 @@ static void sas_form_port(struct asd_sas
>  		return;
>  	}
>  
> +	if (!port->port) {
> +		port->port = sas_port_alloc(phy->phy->dev.parent, port->id);
> +		BUG_ON(!port->port);
> +		sas_port_add(port->port);
> +	}
> +	sas_port_add_phy(port->port, phy->phy);
> +
>  	/* add the phy to the port */
>  	list_add_tail(&phy->port_phy_el, &port->phy_list);
>  	phy->port = port;
>  	port->num_phys++;
>  	port->phy_mask |= (1U << phy->id);
>  
> -	phy->phy->port_identifier = port->id;
>  	if (!port->phy)
>  		port->phy = phy->phy;
>  
> @@ -141,6 +147,7 @@ void sas_deform_port(struct asd_sas_phy 
>  		port->port_dev->pathways--;
>  
>  	if (port->num_phys == 1) {
> +		sas_port_delete(port->port);
>  		init_completion(&port->port_gone_completion);
>  		sas_discover_event(port, DISCE_PORT_GONE);
>  		wait_for_completion(&port->port_gone_completion);
> @@ -149,6 +156,8 @@ void sas_deform_port(struct asd_sas_phy 
>  	if (si->dft->lldd_port_deformed)
>  		si->dft->lldd_port_deformed(phy);
>  
> +	sas_port_delete_phy(port->port, phy->phy);
> +
>  	spin_lock(&sas_ha->phy_port_lock);
>  	spin_lock(&port->phy_list_lock);
>  
> diff --git a/include/scsi/sas/sas_class.h b/include/scsi/sas/sas_class.h
> index 0c3aae5..4b56259 100644
> --- a/include/scsi/sas/sas_class.h
> +++ b/include/scsi/sas/sas_class.h
> @@ -180,6 +180,8 @@ struct asd_sas_port {
>  
>  	struct sas_ha_struct *ha;
>  
> +	struct sas_port	*port;
> +
>  	void *lldd_port;	  /* not touched by the sas class code */
>  };
>  
> diff --git a/include/scsi/sas/sas_expander.h b/include/scsi/sas/sas_expander.h
> index e83b41c..6ce6163 100644
> --- a/include/scsi/sas/sas_expander.h
> +++ b/include/scsi/sas/sas_expander.h
> @@ -72,6 +72,7 @@ struct ex_phy {
>  	int  last_da_index;
>  
>  	struct sas_phy *phy;
> +	struct sas_port *port;
>  };
>  
>  struct expander_device {
> @@ -85,6 +86,7 @@ struct expander_device {
>  	u8     enclosure_logical_id[8];
>  
>  	struct ex_phy *ex_phy;
> +	struct sas_port **ex_port;
>  };
>  
>  int  sas_discover_root_expander(struct domain_device *dev);
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 19:46 ` Alexis Bruemmer
@ 2006-05-31 20:57   ` James Bottomley
  2006-05-31 22:00     ` Alexis Bruemmer
  2006-05-31 21:32   ` Douglas Gilbert
  1 sibling, 1 reply; 11+ messages in thread
From: James Bottomley @ 2006-05-31 20:57 UTC (permalink / raw)
  To: Alexis Bruemmer; +Cc: linux-scsi

On Wed, 2006-05-31 at 12:46 -0700, Alexis Bruemmer wrote:
> there is a sas_device, sas_end_device, and a sas_expander dir.
> sas_device contains the same info as sas_end_device, and a sas_expander
> can we eliminate one or the other?  Or was this a design choice?

Not really.  This is a design choice given to us by the interface.
Everything that's connected to a port is a sas_device.  As such, they
all share a set of characteristics (initiator and target roles, sas
address and so forth).  The specific devices (sas_expander and
sas_end_device) contain only parameters that are specific to the device,
so the expander shows the manufacturer and component info.  The
end_device shows the SAS mandated parameters like ready led and nexus
loss timeout).

> Also during the boot process on the x260 with an expander we see these
> printk's:
> sas: phy[n] matched wide port0
> If we are going to print this then we better be sure that this is truly
> a wide port.  It seems under the sys/class/ we have both a single
> port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n].  and
> although each phy seems to have the same sas_address the end_device
> attached to that phy have unique addresses.  My understanding is that a
> wide port has multiple phys with the same sas address and are attached
> to one end device.  I believe that the expander situation is not the
> same as wide port.  If this is the case then it is as simple as changing
> the printk statement to not say "wide port"

As I read the code, it only prints that when it actually finds a wide
port (as in a port that already has a phy attached) ... do an ls -R of
your tree and I'll see if I can figure out what your topology is.

James



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 19:46 ` Alexis Bruemmer
  2006-05-31 20:57   ` James Bottomley
@ 2006-05-31 21:32   ` Douglas Gilbert
  2006-05-31 22:30     ` Alexis Bruemmer
  2006-06-01 16:21     ` Douglas Gilbert
  1 sibling, 2 replies; 11+ messages in thread
From: Douglas Gilbert @ 2006-05-31 21:32 UTC (permalink / raw)
  To: Alexis Bruemmer; +Cc: James Bottomley, linux-scsi

Alexis Bruemmer wrote:
> These patches look good and are running on our x260 and the ppc64
> (power).  I was just wondering about a few things under the sys/class/:
> 
> there is a sas_device, sas_end_device, and a sas_expander dir.
> sas_device contains the same info as sas_end_device, and a sas_expander
> can we eliminate one or the other?  Or was this a design choice?
> 
> Also during the boot process on the x260 with an expander we see these
> printk's:
> sas: phy[n] matched wide port0
> If we are going to print this then we better be sure that this is truly
> a wide port.  It seems under the sys/class/ we have both a single
> port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n].  and
> although each phy seems to have the same sas_address the end_device
> attached to that phy have unique addresses.  My understanding is that a
> wide port has multiple phys with the same sas address and are attached
> to one end device.

A wide port is an abstraction just above the link
layer in which two or more links running between
the same two devices have phys with the same SAS
addresses associated with them.

Assume we have two phys on a HBA connected to two
phys on an expander, then two other phys on the
expander connected to a dual ported SAS disk.
That is one wide port connection (between the
at HBA and the expander) and two narrow
port connections (between the expander and each
port on the SAS disk).

This comes about because phys on a HBA share a
SAS address, phys on a expander share a SAS address
but phys of a dual ported SAS disk have distinct
SAS addresses.
[Could someone suggest an instructive diagram url
of this as the sas drafts are a bit complex.]

You are probably aware of this distinction but my
guess is a lot of other people aren't.

Put another way, seen from a LLD or discover process when
multiple phys on the same device have this tuple
<SAS_address, attached_SAS_address> equal then there is
a wide port connection.

This also means that it is possible to talk about
a narrow port in the absence of an established
link but not possible to talk about a wide port
until there are two or more established links.

It may also be worth pointing out that there is not data
aggregation on a wide port, but there is command aggregation.
So a 2 phy wide port connection will not run a single SCSI
command twice as fast, but can run two co-incident SCSI
commands at full link speed (i.e. up to 3 Gbps currently).

  I believe that the expander situation is not the
> same as wide port.  If this is the case then it is as simple as changing
> the printk statement to not say "wide port"
> 
> I am more than happy to make these changes if everyone agrees that they
> should be made.

It may also be useful to use the term "narrow"
sometimes, especially if there is a transition
from wide to narrow (e.g. due to a faulty cable
or a link reset on one of the links).

Doug Gilbert

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 20:57   ` James Bottomley
@ 2006-05-31 22:00     ` Alexis Bruemmer
  2006-05-31 22:11       ` James Bottomley
  0 siblings, 1 reply; 11+ messages in thread
From: Alexis Bruemmer @ 2006-05-31 22:00 UTC (permalink / raw)
  To: James Bottomley; +Cc: Alexis Bruemmer, linux-scsi

On Wed, 2006-05-31 at 15:57 -0500, James Bottomley wrote:
> On Wed, 2006-05-31 at 12:46 -0700, Alexis Bruemmer wrote:
> > there is a sas_device, sas_end_device, and a sas_expander dir.
> > sas_device contains the same info as sas_end_device, and a sas_expander
> > can we eliminate one or the other?  Or was this a design choice?
> 
> Not really.  This is a design choice given to us by the interface.
> Everything that's connected to a port is a sas_device.  As such, they
> all share a set of characteristics (initiator and target roles, sas
> address and so forth).  The specific devices (sas_expander and
> sas_end_device) contain only parameters that are specific to the device,
> so the expander shows the manufacturer and component info.  The
> end_device shows the SAS mandated parameters like ready led and nexus
> loss timeout).
OK, makes sense

> 
> > Also during the boot process on the x260 with an expander we see these
> > printk's:
> > sas: phy[n] matched wide port0
> > If we are going to print this then we better be sure that this is truly
> > a wide port.  It seems under the sys/class/ we have both a single
> > port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n].  and
> > although each phy seems to have the same sas_address the end_device
> > attached to that phy have unique addresses.  My understanding is that a
> > wide port has multiple phys with the same sas address and are attached
> > to one end device.  I believe that the expander situation is not the
> > same as wide port.  If this is the case then it is as simple as changing
> > the printk statement to not say "wide port"
> 
> As I read the code, it only prints that when it actually finds a wide
> port (as in a port that already has a phy attached) ... do an ls -R of
> your tree and I'll see if I can figure out what your topology is.
Below is a ls -R of my tree on this machine.  It seems that it sees the
expander as a wide port (port-0:0) and then the expander has a series of
phys attached to end devices.  What I am curious about is the
port-0:0:[0...4]-- the way this is laid out it seems that there is one
port for each phy which is attached to one end device, which would be a
narrow port.  Does your x260 create the same topology?

--Alexis


tree:
sas_device:
end_device-0:0-0  end_device-0:1-1  end_device-0:2-2  end_device-0:3-3
end_device-0:4-4  expander-0:0

sas_device/end_device-0:0-0:
device  device_type  initiator_port_protocols  phy_identifier
sas_address  target_port_protocols  uevent

sas_device/end_device-0:1-1:
device  device_type  initiator_port_protocols  phy_identifier
sas_address  target_port_protocols  uevent

sas_device/end_device-0:2-2:
device  device_type  initiator_port_protocols  phy_identifier
sas_address  target_port_protocols  uevent

sas_device/end_device-0:3-3:
device  device_type  initiator_port_protocols  phy_identifier
sas_address  target_port_protocols  uevent

sas_device/end_device-0:4-4:
device  device_type  initiator_port_protocols  phy_identifier
sas_address  target_port_protocols  uevent

sas_device/expander-0:0:
device  device_type  initiator_port_protocols  phy_identifier
sas_address  target_port_protocols  uevent

sas_end_device:
end_device-0:0-0  end_device-0:1-1  end_device-0:2-2  end_device-0:3-3
end_device-0:4-4

sas_end_device/end_device-0:0-0:
device  initiator_response_timeout  I_T_nexus_loss_timeout
ready_led_meaning  uevent

sas_end_device/end_device-0:1-1:
device  initiator_response_timeout  I_T_nexus_loss_timeout
ready_led_meaning  uevent

sas_end_device/end_device-0:2-2:
device  initiator_response_timeout  I_T_nexus_loss_timeout
ready_led_meaning  uevent

sas_end_device/end_device-0:3-3:
device  initiator_response_timeout  I_T_nexus_loss_timeout
ready_led_meaning  uevent

sas_end_device/end_device-0:4-4:
device  initiator_response_timeout  I_T_nexus_loss_timeout
ready_led_meaning  uevent

sas_expander:
expander-0:0

sas_expander/expander-0:0:
component_id  component_revision_id  component_vendor_id  device  level
product_id  product_rev  uevent  vendor_id

sas_host:
host0

sas_host/host0:
device  uevent

sas_phy:
phy-0:0    phy-0-0:1   phy-0-0:11  phy-0-0:2  phy-0-0:4  phy-0-0:6
phy-0-0:8  phy-0:1  phy-0:3  phy-0:5  phy-0:7
phy-0-0:0  phy-0-0:10  phy-0-0:12  phy-0-0:3  phy-0-0:5  phy-0-0:7
phy-0-0:9  phy-0:2  phy-0:4  phy-0:6

sas_phy/phy-0:0:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:0:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:1:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:10:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:11:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:12:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:2:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:3:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:4:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:5:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:6:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:7:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:8:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0-0:9:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0:1:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0:2:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0:3:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0:4:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0:5:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0:6:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_phy/phy-0:7:
device                    invalid_dword_count       maximum_linkrate_hw
negotiated_linkrate      running_disparity_error_count  uevent
device_type               loss_of_dword_sync_count  minimum_linkrate
phy_identifier           sas_address
initiator_port_protocols  maximum_linkrate          minimum_linkrate_hw
phy_reset_problem_count  target_port_protocols

sas_port:
port-0:0  port-0:0:0  port-0:0:1  port-0:0:2  port-0:0:3  port-0:0:4

sas_port/port-0:0:
device  num_phys  uevent

sas_port/port-0:0:0:
device  num_phys  uevent

sas_port/port-0:0:1:
device  num_phys  uevent

sas_port/port-0:0:2:
device  num_phys  uevent

sas_port/port-0:0:3:
device  num_phys  uevent

sas_port/port-0:0:4:
device  num_phys  uevent




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 22:00     ` Alexis Bruemmer
@ 2006-05-31 22:11       ` James Bottomley
  0 siblings, 0 replies; 11+ messages in thread
From: James Bottomley @ 2006-05-31 22:11 UTC (permalink / raw)
  To: Alexis Bruemmer; +Cc: linux-scsi

On Wed, 2006-05-31 at 15:00 -0700, Alexis Bruemmer wrote:
> Below is a ls -R of my tree on this machine.  It seems that it sees
> the
> expander as a wide port (port-0:0) and then the expander has a series
> of
> phys attached to end devices.  What I am curious about is the
> port-0:0:[0...4]-- the way this is laid out it seems that there is one
> port for each phy which is attached to one end device, which would be
> a
> narrow port.  Does your x260 create the same topology?

Yes, that's by design.

Now every start point for a device must be a port (either narrow or
wide).  The port-0:0:X are ports formed on the expander.  And, since you
only have narrow devices attached, that's all it shows  you'll see this
if you look at the tree under /sys/devices rather than /sys/class (since
the latter is flat).  All of the port-0:0:x will show up under
expander-0:0 (just do ls /sys/class/sas_expander/expander-0:0/device/ to
see this).

James



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 21:32   ` Douglas Gilbert
@ 2006-05-31 22:30     ` Alexis Bruemmer
  2006-05-31 22:37       ` James Bottomley
  2006-06-01 16:21     ` Douglas Gilbert
  1 sibling, 1 reply; 11+ messages in thread
From: Alexis Bruemmer @ 2006-05-31 22:30 UTC (permalink / raw)
  To: dougg; +Cc: Alexis Bruemmer, James Bottomley, linux-scsi

On Wed, 2006-05-31 at 17:32 -0400, Douglas Gilbert wrote:
> Alexis Bruemmer wrote:
> > These patches look good and are running on our x260 and the ppc64
> > (power).  I was just wondering about a few things under the sys/class/:
> > 
> > there is a sas_device, sas_end_device, and a sas_expander dir.
> > sas_device contains the same info as sas_end_device, and a sas_expander
> > can we eliminate one or the other?  Or was this a design choice?
> > 
> > Also during the boot process on the x260 with an expander we see these
> > printk's:
> > sas: phy[n] matched wide port0
> > If we are going to print this then we better be sure that this is truly
> > a wide port.  It seems under the sys/class/ we have both a single
> > port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n].  and
> > although each phy seems to have the same sas_address the end_device
> > attached to that phy have unique addresses.  My understanding is that a
> > wide port has multiple phys with the same sas address and are attached
> > to one end device.
> 
> A wide port is an abstraction just above the link
> layer in which two or more links running between
> the same two devices have phys with the same SAS
> addresses associated with them.
> 
> Assume we have two phys on a HBA connected to two
> phys on an expander, then two other phys on the
> expander connected to a dual ported SAS disk.
> That is one wide port connection (between the
> at HBA and the expander) and two narrow
> port connections (between the expander and each
> port on the SAS disk).
> 
> This comes about because phys on a HBA share a
> SAS address, phys on a expander share a SAS address
> but phys of a dual ported SAS disk have distinct
> SAS addresses.
> [Could someone suggest an instructive diagram url
> of this as the sas drafts are a bit complex.]

This would be assume!

> 
> You are probably aware of this distinction but my
> guess is a lot of other people aren't.
> 
> Put another way, seen from a LLD or discover process when
> multiple phys on the same device have this tuple
> <SAS_address, attached_SAS_address> equal then there is
> a wide port connection.

If this is the case then according to the below print out we do not have
a wide port on this machine:

sas: phy0 added to port0, phy_mask:0x1
[  155.328494] sas: phy1 matched wide port0
[  155.328499] sas: phy1 added to port0, phy_mask:0x3
[  155.328516] sas: phy2 matched wide port0
[  155.328520] sas: phy2 added to port0, phy_mask:0x7
[  155.328541] sas: phy3 matched wide port0
[  155.328548] sas: phy3 added to port0, phy_mask:0xf
[  155.328578] sas: DOING DISCOVERY on port 0, pid:1785
[  155.328917] sas: ex 5005076a00000a40 phy00:T attached: 50010b9000021585
[  155.328996] sas: ex 5005076a00000a40 phy01:T attached: 50010b9000021575
[  155.329081] sas: ex 5005076a00000a40 phy02:T attached: 50010b900004b87e
[  155.329169] sas: ex 5005076a00000a40 phy03:S attached: 5005076a011061c0

The sas_address and the sas_attached_address are different

> 
> This also means that it is possible to talk about
> a narrow port in the absence of an established
> link but not possible to talk about a wide port
> until there are two or more established links.
> 
> It may also be worth pointing out that there is not data
> aggregation on a wide port, but there is command aggregation.
> So a 2 phy wide port connection will not run a single SCSI
> command twice as fast, but can run two co-incident SCSI
> commands at full link speed (i.e. up to 3 Gbps currently).
> 
>   I believe that the expander situation is not the
> > same as wide port.  If this is the case then it is as simple as changing
> > the printk statement to not say "wide port"
> > 
> > I am more than happy to make these changes if everyone agrees that they
> > should be made.
> 
> It may also be useful to use the term "narrow"
> sometimes, especially if there is a transition
> from wide to narrow (e.g. due to a faulty cable
> or a link reset on one of the links).
> 
> Doug Gilbert
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 22:30     ` Alexis Bruemmer
@ 2006-05-31 22:37       ` James Bottomley
  2006-05-31 23:16         ` Alexis Bruemmer
  0 siblings, 1 reply; 11+ messages in thread
From: James Bottomley @ 2006-05-31 22:37 UTC (permalink / raw)
  To: Alexis Bruemmer; +Cc: dougg, linux-scsi

On Wed, 2006-05-31 at 15:30 -0700, Alexis Bruemmer wrote:
> sas: phy0 added to port0, phy_mask:0x1
> [  155.328494] sas: phy1 matched wide port0
> [  155.328499] sas: phy1 added to port0, phy_mask:0x3
> [  155.328516] sas: phy2 matched wide port0
> [  155.328520] sas: phy2 added to port0, phy_mask:0x7
> [  155.328541] sas: phy3 matched wide port0
> [  155.328548] sas: phy3 added to port0, phy_mask:0xf
> [  155.328578] sas: DOING DISCOVERY on port 0, pid:1785
> [  155.328917] sas: ex 5005076a00000a40 phy00:T attached:
> 50010b9000021585
> [  155.328996] sas: ex 5005076a00000a40 phy01:T attached:
> 50010b9000021575
> [  155.329081] sas: ex 5005076a00000a40 phy02:T attached:
> 50010b900004b87e
> [  155.329169] sas: ex 5005076a00000a40 phy03:S attached:
> 5005076a011061c0

No.  Look again.  the first four, which are a wide port, are phys 0-3 on
the HBA.

The second four, which have separate attached devices are phys 0-3 on
the expander (that's what the sightly cryptic ex 5005076a00000a40 phy<n>
means).

You can see this better in the transport class tree

James



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 22:37       ` James Bottomley
@ 2006-05-31 23:16         ` Alexis Bruemmer
  0 siblings, 0 replies; 11+ messages in thread
From: Alexis Bruemmer @ 2006-05-31 23:16 UTC (permalink / raw)
  To: James Bottomley; +Cc: Alexis Bruemmer, dougg, linux-scsi

On Wed, 2006-05-31 at 17:37 -0500, James Bottomley wrote:
> On Wed, 2006-05-31 at 15:30 -0700, Alexis Bruemmer wrote:
> > sas: phy0 added to port0, phy_mask:0x1
> > [  155.328494] sas: phy1 matched wide port0
> > [  155.328499] sas: phy1 added to port0, phy_mask:0x3
> > [  155.328516] sas: phy2 matched wide port0
> > [  155.328520] sas: phy2 added to port0, phy_mask:0x7
> > [  155.328541] sas: phy3 matched wide port0
> > [  155.328548] sas: phy3 added to port0, phy_mask:0xf
> > [  155.328578] sas: DOING DISCOVERY on port 0, pid:1785
> > [  155.328917] sas: ex 5005076a00000a40 phy00:T attached:
> > 50010b9000021585
> > [  155.328996] sas: ex 5005076a00000a40 phy01:T attached:
> > 50010b9000021575
> > [  155.329081] sas: ex 5005076a00000a40 phy02:T attached:
> > 50010b900004b87e
> > [  155.329169] sas: ex 5005076a00000a40 phy03:S attached:
> > 5005076a011061c0
> 
> No.  Look again.  the first four, which are a wide port, are phys 0-3 on
> the HBA.
> 
> The second four, which have separate attached devices are phys 0-3 on
> the expander (that's what the sightly cryptic ex 5005076a00000a40 phy<n>
> means).
> 
> You can see this better in the transport class tree
> 
> James

OK, that makes more sense, thank you for explaining. 

--Alexis
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-05-31 21:32   ` Douglas Gilbert
  2006-05-31 22:30     ` Alexis Bruemmer
@ 2006-06-01 16:21     ` Douglas Gilbert
  2006-06-01 21:40       ` James Bottomley
  1 sibling, 1 reply; 11+ messages in thread
From: Douglas Gilbert @ 2006-06-01 16:21 UTC (permalink / raw)
  To: Alexis Bruemmer; +Cc: James Bottomley, linux-scsi

[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]

Douglas Gilbert wrote:
> Alexis Bruemmer wrote:
> 
>>These patches look good and are running on our x260 and the ppc64
>>(power).  I was just wondering about a few things under the sys/class/:
>>
>>there is a sas_device, sas_end_device, and a sas_expander dir.
>>sas_device contains the same info as sas_end_device, and a sas_expander
>>can we eliminate one or the other?  Or was this a design choice?
>>
>>Also during the boot process on the x260 with an expander we see these
>>printk's:
>>sas: phy[n] matched wide port0
>>If we are going to print this then we better be sure that this is truly
>>a wide port.  It seems under the sys/class/ we have both a single
>>port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n].  and
>>although each phy seems to have the same sas_address the end_device
>>attached to that phy have unique addresses.  My understanding is that a
>>wide port has multiple phys with the same sas address and are attached
>>to one end device.
> 
> 
> A wide port is an abstraction just above the link
> layer in which two or more links running between
> the same two devices have phys with the same SAS
> addresses associated with them.
> 
> Assume we have two phys on a HBA connected to two
> phys on an expander, then two other phys on the
> expander connected to a dual ported SAS disk.
> That is one wide port connection (between the
> at HBA and the expander) and two narrow
> port connections (between the expander and each
> port on the SAS disk).
> 
> This comes about because phys on a HBA share a
> SAS address, phys on a expander share a SAS address
> but phys of a dual ported SAS disk have distinct
> SAS addresses.
> [Could someone suggest an instructive diagram url
> of this as the sas drafts are a bit complex.]
> 
> You are probably aware of this distinction but my
> guess is a lot of other people aren't.
> 
> Put another way, seen from a LLD or discover process when
> multiple phys on the same device have this tuple
> <SAS_address, attached_SAS_address> equal then there is
> a wide port connection.

I don't have a diagram, but I do have some real
output. The hardware is set up as in my example
above with a LSI SAS HBA (0x500605b00006f260).
There is a twelve port expander (0x500605b000000af0)
with phy ids 3 and 4 connected to the HBA, and phy
ids 8 and 9 connected to a dual ported SAS disk.

sg_vpd shows the naa-5 addresses for /dev/sdb
and /dev/sdc . So many to choose from! The first
is the lu name, next is the port identifier and the
last two are different renderings of the target device
name. Only the target port identifiers differ (the
secondary port is usually one higher than the primary).

[Aside: if lsscsi was to show a device's wwn then I
 believe it should show the lu name (if there is one).
 Thoughts?]

Doing a SMP discover on the expander's connected phys
shows a 2 link wide port to the HBA because the
two <sas_addres, attached_sas_address> tuples match. Note
that the attached phy ids (i.e. on the HBA) are not
consecutive. There are also two narrow port links to the
primary and secondary ports of the SAS disk.

Doug Gilbert



[-- Attachment #2: wide_narrow_ex.txt --]
[-- Type: text/plain, Size: 2057 bytes --]

[root@sas ~]# lsscsi
[0:0:0:0]    disk    ATA      WDC WD360GD-00FL 33.0  /dev/sda
[4:2:0:0]    disk    SEAGATE  ST336754SS       0003  /dev/sdb
[4:2:1:0]    disk    SEAGATE  ST336754SS       0003  /dev/sdc

[root@sas ~]# sg_vpd /dev/sdb -iq
0x5000c50000520a2b
0x5000c50000520a2a
0x5000c50000520a28
naa.5000C50000520A28

[root@sas ~]# sg_vpd /dev/sdc -iq
0x5000c50000520a2b
0x5000c50000520a29
0x5000c50000520a28
naa.5000C50000520A28

[root@sas ~]# smp_discover -s 0x500605b000000af0 /dev/mptctl -b -p 3
Discover response:
  phy identifier: 3
  attached device type: end device
  negotiated physical link rate: phy enabled; 3 Gbps
  attached initiator: ssp=1 stp=1 smp=1 sata_host=0
  attached target: ssp=0 stp=0 smp=0 sata_device=0
  SAS address: 0x500605b000000af0
  attached SAS address: 0x500605b00006f260
  attached phy identifier: 0

[root@sas ~]# smp_discover -s 0x500605b000000af0 /dev/mptctl -b -p 4
Discover response:
  phy identifier: 4
  attached device type: end device
  negotiated physical link rate: phy enabled; 3 Gbps
  attached initiator: ssp=1 stp=1 smp=1 sata_host=0
  attached target: ssp=0 stp=0 smp=0 sata_device=0
  SAS address: 0x500605b000000af0
  attached SAS address: 0x500605b00006f260
  attached phy identifier: 3

[root@sas ~]# smp_discover -s 0x500605b000000af0 /dev/mptctl -b -p 8
Discover response:
  phy identifier: 8
  attached device type: end device
  negotiated physical link rate: phy enabled; 3 Gbps
  attached initiator: ssp=0 stp=0 smp=0 sata_host=0
  attached target: ssp=1 stp=0 smp=0 sata_device=0
  SAS address: 0x500605b000000af0
  attached SAS address: 0x5000c50000520a2a
  attached phy identifier: 1

[root@sas ~]# smp_discover -s 0x500605b000000af0 /dev/mptctl -b -p 9
Discover response:
  phy identifier: 9
  attached device type: end device
  negotiated physical link rate: phy enabled; 3 Gbps
  attached initiator: ssp=0 stp=0 smp=0 sata_host=0
  attached target: ssp=1 stp=0 smp=0 sata_device=0
  SAS address: 0x500605b000000af0
  attached SAS address: 0x5000c50000520a29
  attached phy identifier: 0

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] aic94xx: make use of the new sas_port
  2006-06-01 16:21     ` Douglas Gilbert
@ 2006-06-01 21:40       ` James Bottomley
  0 siblings, 0 replies; 11+ messages in thread
From: James Bottomley @ 2006-06-01 21:40 UTC (permalink / raw)
  To: dougg; +Cc: Alexis Bruemmer, linux-scsi

On Thu, 2006-06-01 at 12:21 -0400, Douglas Gilbert wrote:
> >>Also during the boot process on the x260 with an expander we see these
> >>printk's:
> >>sas: phy[n] matched wide port0
> >>If we are going to print this then we better be sure that this is truly
> >>a wide port.  It seems under the sys/class/ we have both a single
> >>port0:0 and then also port-0:0:[n]-- a port[n] for each phy[n].  and
> >>although each phy seems to have the same sas_address the end_device
> >>attached to that phy have unique addresses.  My understanding is that a
> >>wide port has multiple phys with the same sas address and are attached
> >>to one end device.

Just for reference, this is what my x260 looks like:

./
  +-- phy-0:0/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:0@ -> ../../../../../class/sas_phy/phy-0:0
  |   +-- uevent
  +-- phy-0:1/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:1@ -> ../../../../../class/sas_phy/phy-0:1
  |   +-- uevent
  +-- phy-0:2/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:2@ -> ../../../../../class/sas_phy/phy-0:2
  |   +-- uevent
  +-- phy-0:3/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:3@ -> ../../../../../class/sas_phy/phy-0:3
  |   +-- uevent
  +-- phy-0:4/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:4@ -> ../../../../../class/sas_phy/phy-0:4
  |   +-- uevent
  +-- phy-0:5/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:5@ -> ../../../../../class/sas_phy/phy-0:5
  |   +-- uevent
  +-- phy-0:6/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:6@ -> ../../../../../class/sas_phy/phy-0:6
  |   +-- uevent
  +-- phy-0:7/
  |   +-- port@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_phy:phy-0:7@ -> ../../../../../class/sas_phy/phy-0:7
  |   +-- uevent
  +-- port-0:0/
  |   +-- expander-0:0/
  |   |   +-- phy-0-0:0/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:0@ -> ../../../../../../../class/sas_phy/phy-0-0:0
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:1/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:1@ -> ../../../../../../../class/sas_phy/phy-0-0:1
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:10/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:10@ -> ../../../../../../../class/sas_phy/phy-0-0:10
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:11/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:11@ -> ../../../../../../../class/sas_phy/phy-0-0:11
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:12/
  |   |   |   +-- port@ -> ../../../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/port-0:0:0
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:12@ -> ../../../../../../../class/sas_phy/phy-0-0:12
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:2/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:2@ -> ../../../../../../../class/sas_phy/phy-0-0:2
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:3/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:3@ -> ../../../../../../../class/sas_phy/phy-0-0:3
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:4/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:4@ -> ../../../../../../../class/sas_phy/phy-0-0:4
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:5/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:5@ -> ../../../../../../../class/sas_phy/phy-0-0:5
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:6/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:6@ -> ../../../../../../../class/sas_phy/phy-0-0:6
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:7/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:7@ -> ../../../../../../../class/sas_phy/phy-0-0:7
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:8/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:8@ -> ../../../../../../../class/sas_phy/phy-0-0:8
  |   |   |   +-- uevent
  |   |   +-- phy-0-0:9/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-0:9@ -> ../../../../../../../class/sas_phy/phy-0-0:9
  |   |   |   +-- uevent
  |   |   +-- port-0:0:0/
  |   |   |   +-- end_device-0:0-0/
  |   |   |   |   +-- power/
  |   |   |   |   |   +-- state
  |   |   |   |   |   +-- wakeup
  |   |   |   |   +-- sas_device:end_device-0:0-0@ -> ../../../../../../../../class/sas_device/end_device-0:0-0
  |   |   |   |   +-- sas_end_device:end_device-0:0-0@ -> ../../../../../../../../class/sas_end_device/end_device-0:0-0
  |   |   |   |   +-- target0:0:0/
  |   |   |   |   |   +-- 0:0:0:0/
  |   |   |   |   |   |   +-- bus@ -> ../../../../../../../../../../bus/scsi
  |   |   |   |   |   |   +-- delete
  |   |   |   |   |   |   +-- device_blocked
  |   |   |   |   |   |   +-- iocounterbits
  |   |   |   |   |   |   +-- iodone_cnt
  |   |   |   |   |   |   +-- ioerr_cnt
  |   |   |   |   |   |   +-- iorequest_cnt
  |   |   |   |   |   |   +-- model
  |   |   |   |   |   |   +-- power/
  |   |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   |   +-- wakeup
  |   |   |   |   |   |   +-- queue_depth
  |   |   |   |   |   |   +-- queue_type
  |   |   |   |   |   |   +-- rescan
  |   |   |   |   |   |   +-- rev
  |   |   |   |   |   |   +-- scsi_device:0:0:0:0@ -> ../../../../../../../../../../class/scsi_device/0:0:0:0
  |   |   |   |   |   |   +-- scsi_level
  |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   +-- timeout
  |   |   |   |   |   |   +-- type
  |   |   |   |   |   |   +-- uevent
  |   |   |   |   |   |   +-- vendor
  |   |   |   |   |   +-- power/
  |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   +-- wakeup
  |   |   |   |   |   +-- uevent
  |   |   |   |   +-- uevent
  |   |   |   +-- phy-0-0:12@ -> ../../../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/phy-0-0:12
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_port:port-0:0:0@ -> ../../../../../../../class/sas_port/port-0:0:0
  |   |   |   +-- uevent
  |   |   +-- power/
  |   |   |   +-- state
  |   |   |   +-- wakeup
  |   |   +-- sas_device:expander-0:0@ -> ../../../../../../class/sas_device/expander-0:0
  |   |   +-- sas_expander:expander-0:0@ -> ../../../../../../class/sas_expander/expander-0:0
  |   |   +-- uevent
  |   +-- phy-0:0@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:0
  |   +-- phy-0:1@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:1
  |   +-- phy-0:2@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:2
  |   +-- phy-0:3@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:3
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_port:port-0:0@ -> ../../../../../class/sas_port/port-0:0
  |   +-- uevent
  +-- port-0:1/
  |   +-- expander-0:1/
  |   |   +-- phy-0-1:0/
  |   |   |   +-- port@ -> ../../../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1/expander-0:1/port-0:1:0
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:0@ -> ../../../../../../../class/sas_phy/phy-0-1:0
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:1/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:1@ -> ../../../../../../../class/sas_phy/phy-0-1:1
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:10/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:10@ -> ../../../../../../../class/sas_phy/phy-0-1:10
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:11/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:11@ -> ../../../../../../../class/sas_phy/phy-0-1:11
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:12/
  |   |   |   +-- port@ -> ../../../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1/expander-0:1/port-0:1:1
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:12@ -> ../../../../../../../class/sas_phy/phy-0-1:12
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:2/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:2@ -> ../../../../../../../class/sas_phy/phy-0-1:2
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:3/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:3@ -> ../../../../../../../class/sas_phy/phy-0-1:3
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:4/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:4@ -> ../../../../../../../class/sas_phy/phy-0-1:4
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:5/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:5@ -> ../../../../../../../class/sas_phy/phy-0-1:5
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:6/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:6@ -> ../../../../../../../class/sas_phy/phy-0-1:6
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:7/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:7@ -> ../../../../../../../class/sas_phy/phy-0-1:7
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:8/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:8@ -> ../../../../../../../class/sas_phy/phy-0-1:8
  |   |   |   +-- uevent
  |   |   +-- phy-0-1:9/
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_phy:phy-0-1:9@ -> ../../../../../../../class/sas_phy/phy-0-1:9
  |   |   |   +-- uevent
  |   |   +-- port-0:1:0/
  |   |   |   +-- end_device-0:0-0/
  |   |   |   |   +-- power/
  |   |   |   |   |   +-- state
  |   |   |   |   |   +-- wakeup
  |   |   |   |   +-- target0:0:1/
  |   |   |   |   |   +-- 0:0:1:0/
  |   |   |   |   |   |   +-- block:sda@ -> ../../../../../../../../../../block/sda
  |   |   |   |   |   |   +-- bus@ -> ../../../../../../../../../../bus/scsi
  |   |   |   |   |   |   +-- delete
  |   |   |   |   |   |   +-- device_blocked
  |   |   |   |   |   |   +-- driver@ -> ../../../../../../../../../../bus/scsi/drivers/sd
  |   |   |   |   |   |   +-- iocounterbits
  |   |   |   |   |   |   +-- iodone_cnt
  |   |   |   |   |   |   +-- ioerr_cnt
  |   |   |   |   |   |   +-- iorequest_cnt
  |   |   |   |   |   |   +-- model
  |   |   |   |   |   |   +-- power/
  |   |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   |   +-- wakeup
  |   |   |   |   |   |   +-- queue_depth
  |   |   |   |   |   |   +-- queue_type
  |   |   |   |   |   |   +-- rescan
  |   |   |   |   |   |   +-- rev
  |   |   |   |   |   |   +-- scsi_device:0:0:1:0@ -> ../../../../../../../../../../class/scsi_device/0:0:1:0
  |   |   |   |   |   |   +-- scsi_disk:0:0:1:0@ -> ../../../../../../../../../../class/scsi_disk/0:0:1:0
  |   |   |   |   |   |   +-- scsi_level
  |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   +-- timeout
  |   |   |   |   |   |   +-- type
  |   |   |   |   |   |   +-- uevent
  |   |   |   |   |   |   +-- vendor
  |   |   |   |   |   +-- power/
  |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   +-- wakeup
  |   |   |   |   |   +-- uevent
  |   |   |   |   +-- uevent
  |   |   |   +-- phy-0-1:0@ -> ../../../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1/expander-0:1/phy-0-1:0
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_port:port-0:1:0@ -> ../../../../../../../class/sas_port/port-0:1:0
  |   |   |   +-- uevent
  |   |   +-- port-0:1:1/
  |   |   |   +-- end_device-0:1-1/
  |   |   |   |   +-- power/
  |   |   |   |   |   +-- state
  |   |   |   |   |   +-- wakeup
  |   |   |   |   +-- sas_device:end_device-0:1-1@ -> ../../../../../../../../class/sas_device/end_device-0:1-1
  |   |   |   |   +-- sas_end_device:end_device-0:1-1@ -> ../../../../../../../../class/sas_end_device/end_device-0:1-1
  |   |   |   |   +-- target0:1:2/
  |   |   |   |   |   +-- 0:1:2:0/
  |   |   |   |   |   |   +-- bus@ -> ../../../../../../../../../../bus/scsi
  |   |   |   |   |   |   +-- delete
  |   |   |   |   |   |   +-- device_blocked
  |   |   |   |   |   |   +-- iocounterbits
  |   |   |   |   |   |   +-- iodone_cnt
  |   |   |   |   |   |   +-- ioerr_cnt
  |   |   |   |   |   |   +-- iorequest_cnt
  |   |   |   |   |   |   +-- model
  |   |   |   |   |   |   +-- power/
  |   |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   |   +-- wakeup
  |   |   |   |   |   |   +-- queue_depth
  |   |   |   |   |   |   +-- queue_type
  |   |   |   |   |   |   +-- rescan
  |   |   |   |   |   |   +-- rev
  |   |   |   |   |   |   +-- scsi_device:0:1:2:0@ -> ../../../../../../../../../../class/scsi_device/0:1:2:0
  |   |   |   |   |   |   +-- scsi_level
  |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   +-- timeout
  |   |   |   |   |   |   +-- type
  |   |   |   |   |   |   +-- uevent
  |   |   |   |   |   |   +-- vendor
  |   |   |   |   |   +-- power/
  |   |   |   |   |   |   +-- state
  |   |   |   |   |   |   +-- wakeup
  |   |   |   |   |   +-- uevent
  |   |   |   |   +-- uevent
  |   |   |   +-- phy-0-1:12@ -> ../../../../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:1/expander-0:1/phy-0-1:12
  |   |   |   +-- power/
  |   |   |   |   +-- state
  |   |   |   |   +-- wakeup
  |   |   |   +-- sas_port:port-0:1:1@ -> ../../../../../../../class/sas_port/port-0:1:1
  |   |   |   +-- uevent
  |   |   +-- power/
  |   |   |   +-- state
  |   |   |   +-- wakeup
  |   |   +-- sas_device:expander-0:1@ -> ../../../../../../class/sas_device/expander-0:1
  |   |   +-- sas_expander:expander-0:1@ -> ../../../../../../class/sas_expander/expander-0:1
  |   |   +-- uevent
  |   +-- phy-0:4@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:4
  |   +-- phy-0:5@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:5
  |   +-- phy-0:6@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:6
  |   +-- phy-0:7@ -> ../../../../../devices/pci0000:01/0000:01:02.0/host0/phy-0:7
  |   +-- power/
  |   |   +-- state
  |   |   +-- wakeup
  |   +-- sas_port:port-0:1@ -> ../../../../../class/sas_port/port-0:1
  |   +-- uevent
  +-- power/
  |   +-- state
  |   +-- wakeup
  +-- sas_host:host0@ -> ../../../../class/sas_host/host0
  +-- scsi_host:host0@ -> ../../../../class/scsi_host/host0
  +-- uevent

As you see: two wide ports over 8 phys on the HBA then three single
ports on the expanders for the two SES monitors and the one disk.

James



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2006-06-01 21:40 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-31  4:09 [PATCH] aic94xx: make use of the new sas_port James Bottomley
2006-05-31 19:46 ` Alexis Bruemmer
2006-05-31 20:57   ` James Bottomley
2006-05-31 22:00     ` Alexis Bruemmer
2006-05-31 22:11       ` James Bottomley
2006-05-31 21:32   ` Douglas Gilbert
2006-05-31 22:30     ` Alexis Bruemmer
2006-05-31 22:37       ` James Bottomley
2006-05-31 23:16         ` Alexis Bruemmer
2006-06-01 16:21     ` Douglas Gilbert
2006-06-01 21:40       ` James Bottomley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox