linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] first cut at infrastructure for handling different device types in the sas class
@ 2006-03-04  4:05 James Bottomley
  2006-03-04  8:28 ` Luben Tuikov
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: James Bottomley @ 2006-03-04  4:05 UTC (permalink / raw)
  To: linux-scsi

This one actually does the end devices, since that's all I really have
to work with in my setup.  However, I can do the expanders in the same
way.  The idea is to make the rphy embedded in the enveloping device
structure, so the code which doesn't care about type can still treat the
code as a simple rphy, and the code that does care can cast out to the
device type.

Temporarily, because mptsas doesn't do this, I've put a flag in to
indicate whether the rphy is enveloped or not, however, if we enforce
this for everything, then eventually that would go away.

The example just creates a separate class for sas_end_device with some
simple properties from the end device port page:

hobholes:/sys/class# ls sas_rphy/
rphy-0:0-4  rphy-0:1-5  rphy-0:2-6  rphy-0:3-7

hobholes:/sys/class# ls sas_end_device/
rphy-0:0-4  rphy-0:1-5  rphy-0:2-6  rphy-0:3-7

hobholes:/sys/class# ls sas_end_device/rphy-0\:0-4/
device                      I_T_nexus_loss_timeout  uevent
initiator_response_timeout  ready_led_meaning

If everyone's OK with this, I'll do expanders next.

James

diff --git a/drivers/scsi/sas/sas_discover.c b/drivers/scsi/sas/sas_discover.c
index cd10c52..f1339c4 100644
--- a/drivers/scsi/sas/sas_discover.c
+++ b/drivers/scsi/sas/sas_discover.c
@@ -204,13 +204,6 @@ static int sas_get_port_device(struct sa
 		return -ENODEV;
 	}
 	phy = container_of(port->phy_list.next, struct asd_sas_phy, port_phy_el);
-	rphy = sas_rphy_alloc(phy->phy);
-	if (!rphy) {
-		spin_unlock_irqrestore(&port->phy_list_lock, flags);
-		kfree(dev);
-		return -ENODEV;
-	}
-	rphy->identify.phy_identifier = phy->phy->identify.phy_identifier;
 	spin_lock(&phy->frame_rcvd_lock);
 	memcpy(dev->frame_rcvd, phy->frame_rcvd, min(sizeof(dev->frame_rcvd),
 					     (size_t)phy->frame_rcvd_size));
@@ -237,6 +230,13 @@ static int sas_get_port_device(struct sa
 
 	sas_init_dev(dev);
 
+	rphy = dev->dev_type == SAS_END_DEV ? sas_rphy_end_device_alloc(phy->phy) : sas_rphy_alloc(phy->phy);
+	if (!rphy) {
+		spin_unlock_irqrestore(&port->phy_list_lock, flags);
+		kfree(dev);
+		return -ENODEV;
+	}
+	rphy->identify.phy_identifier = phy->phy->identify.phy_identifier;
 	memcpy(dev->sas_addr, port->attached_sas_addr, SAS_ADDR_SIZE);
 	rphy->identify.sas_address = SAS_ADDR(dev->sas_addr);
 	rphy->identify.initiator_port_protocols = dev->iproto;
diff --git a/drivers/scsi/sas/sas_scsi_host.c b/drivers/scsi/sas/sas_scsi_host.c
index af5fa7e..39ee259 100644
--- a/drivers/scsi/sas/sas_scsi_host.c
+++ b/drivers/scsi/sas/sas_scsi_host.c
@@ -569,6 +569,8 @@ int sas_slave_configure(struct scsi_devi
 	dev = sdev_to_domain_dev(scsi_dev);
 	sas_ha = dev->port->ha;
 
+	sas_read_port_mode_page(scsi_dev);
+
 	if (scsi_dev->tagged_supported) {
 		scsi_set_tag_type(scsi_dev, MSG_SIMPLE_TAG);
 		scsi_activate_tcq(scsi_dev, SAS_DEF_QD);
diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
index 434f395..a9b3750 100644
--- a/drivers/scsi/scsi_transport_sas.c
+++ b/drivers/scsi/scsi_transport_sas.c
@@ -39,6 +39,7 @@
 #define SAS_HOST_ATTRS		0
 #define SAS_PORT_ATTRS		17
 #define SAS_RPORT_ATTRS		7
+#define SAS_END_DEV_ATTRS	3
 
 struct sas_internal {
 	struct scsi_transport_template t;
@@ -47,9 +48,11 @@ struct sas_internal {
 	struct class_device_attribute private_host_attrs[SAS_HOST_ATTRS];
 	struct class_device_attribute private_phy_attrs[SAS_PORT_ATTRS];
 	struct class_device_attribute private_rphy_attrs[SAS_RPORT_ATTRS];
+	struct class_device_attribute private_end_dev_attrs[SAS_END_DEV_ATTRS];
 
 	struct transport_container phy_attr_cont;
 	struct transport_container rphy_attr_cont;
+	struct transport_container end_dev_attr_cont;
 
 	/*
 	 * The array of null terminated pointers to attributes
@@ -58,6 +61,7 @@ struct sas_internal {
 	struct class_device_attribute *host_attrs[SAS_HOST_ATTRS + 1];
 	struct class_device_attribute *phy_attrs[SAS_PORT_ATTRS + 1];
 	struct class_device_attribute *rphy_attrs[SAS_RPORT_ATTRS + 1];
+	struct class_device_attribute *end_dev_attrs[SAS_END_DEV_ATTRS + 1];
 };
 #define to_sas_internal(tmpl)	container_of(tmpl, struct sas_internal, t)
 
@@ -588,6 +592,73 @@ sas_rphy_simple_attr(identify.sas_addres
 		unsigned long long);
 sas_rphy_simple_attr(identify.phy_identifier, phy_identifier, "%d\n", u8);
 
+/* only need 8 bytes of data plus header (4 or 8) */
+#define BUF_SIZE 64
+
+int sas_read_port_mode_page(struct scsi_device *sdev)
+{
+	char *buffer = kzalloc(BUF_SIZE, GFP_KERNEL), *msdata;
+	struct sas_rphy *rphy = target_to_rphy(sdev->sdev_target);
+	struct sas_rphy_end_device *rdev;
+	struct scsi_mode_data mode_data;
+	int res, error;
+
+	BUG_ON(rphy->identify.device_type != SAS_END_DEVICE);
+
+	rdev = rphy_to_end_device(rphy);
+
+	if (!buffer)
+		return -ENOMEM;
+
+	res = scsi_mode_sense(sdev, 1, 0x19, buffer, BUF_SIZE, 30*HZ, 3,
+			      &mode_data, NULL);
+
+	error = -EINVAL;
+	if (!scsi_status_is_good(res))
+		goto out;
+
+	msdata = buffer +  mode_data.header_length +
+		mode_data.block_descriptor_length;
+
+	if (msdata - buffer > BUF_SIZE - 8)
+		goto out;
+
+	error = 0;
+
+	rdev->ready_led_meaning = msdata[2] & 0x10 ? 1 : 0;
+	rdev->I_T_nexus_loss_timeout = (msdata[4] << 8) + msdata[5];
+	rdev->initiator_response_timeout = (msdata[6] << 8) + msdata[7];
+
+ out:
+	kfree(buffer);
+	return error;
+}
+EXPORT_SYMBOL(sas_read_port_mode_page);
+
+#define sas_end_dev_show_simple(field, name, format_string, cast)	\
+static ssize_t								\
+show_sas_end_dev_##name(struct class_device *cdev, char *buf)		\
+{									\
+	struct sas_rphy *rphy = transport_class_to_rphy(cdev);		\
+	struct sas_rphy_end_device *rdev = rphy_to_end_device(rphy);	\
+									\
+	return snprintf(buf, 20, format_string, cast rdev->field);	\
+}
+
+#define sas_end_dev_simple_attr(field, name, format_string, type)	\
+	sas_end_dev_show_simple(field, name, format_string, (type))	\
+static SAS_CLASS_DEVICE_ATTR(end_dev, name, S_IRUGO, 			\
+		show_sas_end_dev_##name, NULL)
+
+sas_end_dev_simple_attr(ready_led_meaning, ready_led_meaning, "%d\n", int);
+sas_end_dev_simple_attr(I_T_nexus_loss_timeout, I_T_nexus_loss_timeout,
+			"%d\n", int);
+sas_end_dev_simple_attr(initiator_response_timeout, initiator_response_timeout,
+			"%d\n", int);
+
+static DECLARE_TRANSPORT_CLASS(sas_end_dev_class,
+			       "sas_end_device", NULL, NULL, NULL);
+
 static DECLARE_TRANSPORT_CLASS(sas_rphy_class,
 		"sas_rphy", NULL, NULL, NULL);
 
@@ -610,6 +681,35 @@ static int sas_rphy_match(struct attribu
 	return &i->rphy_attr_cont.ac == cont;
 }
 
+static int sas_end_dev_match(struct attribute_container *cont,
+			     struct device *dev)
+{
+	struct Scsi_Host *shost;
+	struct sas_internal *i;
+	struct sas_rphy *rphy;
+	int r;
+
+	if (!scsi_is_sas_rphy(dev))
+		return 0;
+	dev_printk(KERN_ERR, dev, "IN SAS END DEV MATCH\n");
+	shost = dev_to_shost(dev->parent->parent);
+	rphy = dev_to_rphy(dev);
+
+	if (!shost->transportt)
+		return 0;
+	if (shost->transportt->host_attrs.ac.class !=
+			&sas_host_class.class)
+		return 0;
+
+	i = to_sas_internal(shost->transportt);
+	r = &i->end_dev_attr_cont.ac == cont &&
+		rphy->identify.device_type == SAS_END_DEVICE &&
+		/* FIXME: remove contained eventually */
+		rphy->contained;
+	dev_printk(KERN_ERR, dev, "ABOUT TO RETURN %d\n", r);
+	return r;
+}
+
 static void sas_rphy_release(struct device *dev)
 {
 	struct sas_rphy *rphy = dev_to_rphy(dev);
@@ -650,6 +750,40 @@ struct sas_rphy *sas_rphy_alloc(struct s
 EXPORT_SYMBOL(sas_rphy_alloc);
 
 /**
+ * sas_rphy_end_device_alloc - allocate an rphy for an end device
+ *
+ * Allocates an SAS remote PHY structure, connected to @parent.
+ *
+ * Returns:
+ *	SAS PHY allocated or %NULL if the allocation failed.
+ */
+struct sas_rphy *sas_rphy_end_device_alloc(struct sas_phy *parent)
+{
+	struct Scsi_Host *shost = dev_to_shost(&parent->dev);
+	struct sas_rphy_end_device *rdev;
+
+	rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
+	if (!rdev) {
+		put_device(&parent->dev);
+		return NULL;
+	}
+
+	device_initialize(&rdev->rphy.dev);
+	rdev->rphy.dev.parent = get_device(&parent->dev);
+	rdev->rphy.dev.release = sas_rphy_release;
+	sprintf(rdev->rphy.dev.bus_id, "rphy-%d:%d-%d",
+		shost->host_no, parent->port_identifier, parent->number);
+	rdev->rphy.identify.device_type = SAS_END_DEVICE;
+	/* FIXME: mark the rphy as being contained in a larger structure */
+	rdev->rphy.contained = 1;
+	transport_setup_device(&rdev->rphy.dev);
+
+	return &rdev->rphy;
+}
+EXPORT_SYMBOL(sas_rphy_end_device_alloc);
+
+
+/**
  * sas_rphy_add  --  add a SAS remote PHY to the device hierachy
  * @rphy:	The remote PHY to be added
  *
@@ -807,51 +941,35 @@ static int sas_user_scan(struct Scsi_Hos
  * Setup / Teardown code
  */
 
-#define SETUP_RPORT_ATTRIBUTE(field)					\
-	i->private_rphy_attrs[count] = class_device_attr_##field;	\
-	i->private_rphy_attrs[count].attr.mode = S_IRUGO;		\
-	i->private_rphy_attrs[count].store = NULL;			\
-	i->rphy_attrs[count] = &i->private_rphy_attrs[count];	\
-	count++
+#define SETUP_TEMPLATE(attrb, field, perm, test)				\
+	i->private_##attrb[count] = class_device_attr_##field;		\
+	i->private_##attrb[count].attr.mode = perm;			\
+	i->private_##attrb[count].store = NULL;				\
+	i->attrb[count] = &i->private_##attrb[count];			\
+	if (test)							\
+		count++
+
+
+#define SETUP_RPORT_ATTRIBUTE(field) 					\
+	SETUP_TEMPLATE(rphy_attrs, field, S_IRUGO, 1)
 
 #define SETUP_OPTIONAL_RPORT_ATTRIBUTE(field, func)			\
-	i->private_rphy_attrs[count] = class_device_attr_##field;	\
-	i->private_rphy_attrs[count].attr.mode = S_IRUGO;		\
-	i->private_rphy_attrs[count].store = NULL;			\
-	i->rphy_attrs[count] = &i->private_rphy_attrs[count];		\
-	if (i->f->func)							\
-		count++
+	SETUP_TEMPLATE(rphy_attrs, field, S_IRUGO, i->f->func)
 
 #define SETUP_PORT_ATTRIBUTE(field)					\
-	i->private_phy_attrs[count] = class_device_attr_##field;	\
-        i->private_phy_attrs[count].attr.mode = S_IRUGO;		\
-        i->private_phy_attrs[count].store = NULL;			\
-        i->phy_attrs[count] = &i->private_phy_attrs[count];		\
-	count++
+	SETUP_TEMPLATE(phy_attrs, field, S_IRUGO, 1)
 
 #define SETUP_OPTIONAL_PORT_ATTRIBUTE(field, func)			\
-	i->private_phy_attrs[count] = class_device_attr_##field;	\
-        i->private_phy_attrs[count].attr.mode = S_IRUGO;		\
-        i->private_phy_attrs[count].store = NULL;			\
-        i->phy_attrs[count] = &i->private_phy_attrs[count];		\
-	if (i->f->func)							\
-		count++
+	SETUP_TEMPLATE(phy_attrs, field, S_IRUGO, i->f->func)
 
 #define SETUP_PORT_ATTRIBUTE_WRONLY(field)				\
-	i->private_phy_attrs[count] = class_device_attr_##field;	\
-	i->private_phy_attrs[count].attr.mode = S_IWUGO;		\
-	i->private_phy_attrs[count].show = NULL;			\
-	i->phy_attrs[count] = &i->private_phy_attrs[count];		\
-	count++
+	SETUP_TEMPLATE(phy_attrs, field, S_IWUGO, 1)
 
 #define SETUP_OPTIONAL_PORT_ATTRIBUTE_WRONLY(field, func)		\
-	i->private_phy_attrs[count] = class_device_attr_##field;	\
-	i->private_phy_attrs[count].attr.mode = S_IWUGO;		\
-	i->private_phy_attrs[count].show = NULL;			\
-	i->phy_attrs[count] = &i->private_phy_attrs[count];		\
-	if (i->f->func)							\
-		count++
+	SETUP_TEMPLATE(phy_attrs, field, S_IWUGO, i->f->func)
 
+#define SETUP_END_DEV_ATTRIBUTE(field)					\
+	SETUP_TEMPLATE(end_dev_attrs, field, S_IRUGO, 1)
 
 /**
  * sas_attach_transport  --  instantiate SAS transport template
@@ -885,6 +1003,11 @@ sas_attach_transport(struct sas_function
 	i->rphy_attr_cont.ac.match = sas_rphy_match;
 	transport_container_register(&i->rphy_attr_cont);
 
+	i->end_dev_attr_cont.ac.class = &sas_end_dev_class.class;
+	i->end_dev_attr_cont.ac.attrs = &i->end_dev_attrs[0];
+	i->end_dev_attr_cont.ac.match = sas_end_dev_match;
+	transport_container_register(&i->end_dev_attr_cont);
+
 	i->f = ft;
 
 	count = 0;
@@ -923,6 +1046,12 @@ sas_attach_transport(struct sas_function
 				       get_bay_identifier);
 	i->rphy_attrs[count] = NULL;
 
+	count = 0;
+	SETUP_END_DEV_ATTRIBUTE(end_dev_ready_led_meaning);
+	SETUP_END_DEV_ATTRIBUTE(end_dev_I_T_nexus_loss_timeout);
+	SETUP_END_DEV_ATTRIBUTE(end_dev_initiator_response_timeout);
+	i->end_dev_attrs[count] = NULL;
+
 	return &i->t;
 }
 EXPORT_SYMBOL(sas_attach_transport);
@@ -956,9 +1085,14 @@ static __init int sas_transport_init(voi
 	error = transport_class_register(&sas_rphy_class);
 	if (error)
 		goto out_unregister_phy;
+	error = transport_class_register(&sas_end_dev_class);
+	if (error)
+		goto out_unregister_rphy;
 
 	return 0;
 
+ out_unregister_rphy:
+	transport_class_unregister(&sas_rphy_class);
  out_unregister_phy:
 	transport_class_unregister(&sas_phy_class);
  out_unregister_transport:
@@ -973,6 +1107,7 @@ static void __exit sas_transport_exit(vo
 	transport_class_unregister(&sas_host_class);
 	transport_class_unregister(&sas_phy_class);
 	transport_class_unregister(&sas_rphy_class);
+	transport_class_unregister(&sas_end_dev_class);
 }
 
 MODULE_AUTHOR("Christoph Hellwig");
diff --git a/include/scsi/sas/sas_discover.h b/include/scsi/sas/sas_discover.h
index 1584d4e..2be414e 100644
--- a/include/scsi/sas/sas_discover.h
+++ b/include/scsi/sas/sas_discover.h
@@ -86,7 +86,6 @@ struct sata_device {
 struct end_device {
 	u8     ms_10:1;
 	u8     ready_led_meaning:1;
-	u8     rl_wlun:1;
 	u16    itnl_timeout; 	  /* 0 if you do not know it */
 	u16    iresp_timeout;
 };
diff --git a/include/scsi/scsi_transport_sas.h b/include/scsi/scsi_transport_sas.h
index 95e2132..96ede6e 100644
--- a/include/scsi/scsi_transport_sas.h
+++ b/include/scsi/scsi_transport_sas.h
@@ -82,6 +82,10 @@ struct sas_rphy {
 	struct sas_identify	identify;
 	struct list_head	list;
 	u32			scsi_target_id;
+	/* temporary expedient: mark the rphy as being contained 
+	 * within a type specific rphy
+	 * FIXME: pull this out when everything uses the containers */
+	unsigned		contained:1;
 };
 
 #define dev_to_rphy(d) \
@@ -90,6 +94,19 @@ struct sas_rphy {
 	dev_to_rphy((cdev)->dev)
 #define rphy_to_shost(rphy) \
 	dev_to_shost((rphy)->dev.parent)
+#define target_to_rphy(targ) \
+	dev_to_rphy((targ)->dev.parent)
+
+struct sas_rphy_end_device {
+	struct sas_rphy		rphy;
+	/* flags */
+	unsigned		ready_led_meaning:1;
+	/* parameters */
+	u16			I_T_nexus_loss_timeout;
+	u16			initiator_response_timeout;
+};
+#define rphy_to_end_device(r) \
+	container_of((r), struct sas_rphy_end_device, rphy)
 
 
 /* The functions by which the transport class and the driver communicate */
@@ -110,6 +127,7 @@ extern void sas_phy_delete(struct sas_ph
 extern int scsi_is_sas_phy(const struct device *);
 
 extern struct sas_rphy *sas_rphy_alloc(struct sas_phy *);
+extern struct sas_rphy *sas_rphy_end_device_alloc(struct sas_phy *);
 void sas_rphy_free(struct sas_rphy *);
 extern int sas_rphy_add(struct sas_rphy *);
 extern void sas_rphy_delete(struct sas_rphy *);
@@ -118,5 +136,6 @@ extern int scsi_is_sas_rphy(const struct
 extern struct scsi_transport_template *
 sas_attach_transport(struct sas_function_template *);
 extern void sas_release_transport(struct scsi_transport_template *);
+int sas_read_port_mode_page(struct scsi_device *);
 
 #endif /* SCSI_TRANSPORT_SAS_H */



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

* Re: [RFC] first cut at infrastructure for handling different device types in the sas class
  2006-03-04  4:05 [RFC] first cut at infrastructure for handling different device types in the sas class James Bottomley
@ 2006-03-04  8:28 ` Luben Tuikov
  2006-03-04 15:47 ` Christoph Hellwig
  2006-03-04 18:17 ` [RFC] first cut at infrastructure for handling different devicetypes " Moore, Eric
  2 siblings, 0 replies; 7+ messages in thread
From: Luben Tuikov @ 2006-03-04  8:28 UTC (permalink / raw)
  To: James Bottomley, linux-scsi

--- James Bottomley <James.Bottomley@SteelEye.com> wrote:
> This one actually does the end devices, since that's all I really have
> to work with in my setup.  However, I can do the expanders in the same
> way.
***************************************************************************
> The idea is to make the rphy embedded in the enveloping device
> structure, so the code which doesn't care about type can still treat the
> code as a simple rphy, and the code that does care can cast out to the
> device type.
***************************************************************************

James, this doesn't make sense in SAS.  Maybe you're implementing some other
protocol, but what you have here isn't SAS.  You need to understand
what a port is and what a phy is.  Then you need to understand
their (mutual) interactions.  What each one represents (or doesn't) and
their dependencies.

Then you need to understand why you don't want to represent any of those
two concepts for anything past your own ports.

True, it's all open sourced in the complete SAS Stack, but reverse-engineering
the logic isn't easy without studying the SAS spec.

> If everyone's OK with this, I'll do expanders next.

Please don't.

They are done already, sas_expander.c is the file.


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

* Re: [RFC] first cut at infrastructure for handling different device types in the sas class
  2006-03-04  4:05 [RFC] first cut at infrastructure for handling different device types in the sas class James Bottomley
  2006-03-04  8:28 ` Luben Tuikov
@ 2006-03-04 15:47 ` Christoph Hellwig
  2006-03-04 18:33   ` James Bottomley
  2006-03-04 18:17 ` [RFC] first cut at infrastructure for handling different devicetypes " Moore, Eric
  2 siblings, 1 reply; 7+ messages in thread
From: Christoph Hellwig @ 2006-03-04 15:47 UTC (permalink / raw)
  To: James Bottomley; +Cc: linux-scsi

On Fri, Mar 03, 2006 at 10:05:03PM -0600, James Bottomley wrote:
> This one actually does the end devices, since that's all I really have
> to work with in my setup.  However, I can do the expanders in the same
> way.  The idea is to make the rphy embedded in the enveloping device
> structure, so the code which doesn't care about type can still treat the
> code as a simple rphy, and the code that does care can cast out to the
> device type.
> 
> Temporarily, because mptsas doesn't do this, I've put a flag in to
> indicate whether the rphy is enveloped or not, however, if we enforce
> this for everything, then eventually that would go away.

Looks good in general, but we should probably kill the rphy naming.  That was
my invention when doing the transport class, when I still thought we'd add a
remote object for every phy in wide links.  We ended up having just a remote
object only under one of the phys for a wide link so we should probably
kill this naming invention.  In the end we should probably just have
a sas_end_device, sas_expander and sas_sata_device (or just sata_device
if we can share code with libata) and the common subset (sas_device?)
shouldn't be exposed to userland on it's own.

>  /**
> + * sas_rphy_end_device_alloc - allocate an rphy for an end device
> + *
> + * Allocates an SAS remote PHY structure, connected to @parent.
> + *
> + * Returns:
> + *	SAS PHY allocated or %NULL if the allocation failed.
> + */
> +struct sas_rphy *sas_rphy_end_device_alloc(struct sas_phy *parent)

this should become sas_end_device_alloc, and so on for the other
functions.


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

* Re: [RFC] first cut at infrastructure for handling different devicetypes in the sas class
  2006-03-04  4:05 [RFC] first cut at infrastructure for handling different device types in the sas class James Bottomley
  2006-03-04  8:28 ` Luben Tuikov
  2006-03-04 15:47 ` Christoph Hellwig
@ 2006-03-04 18:17 ` Moore, Eric
  2006-03-06 16:39   ` James Bottomley
  2 siblings, 1 reply; 7+ messages in thread
From: Moore, Eric @ 2006-03-04 18:17 UTC (permalink / raw)
  To: James Bottomley, linux-scsi

On Friday, March 03, 2006 9:05 PM, James Bottomley wrote:


> This one actually does the end devices, since that's all I really have
> to work with in my setup.  However, I can do the expanders in the same
> way.  The idea is to make the rphy embedded in the enveloping device
> structure, so the code which doesn't care about type can still treat the
> code as a simple rphy, and the code that does care can cast out to the
> device type.

I'm not clear what your intent is here.  All the info is there, so I'm not sure
why this change is needed.  The sas_transport implementation Christoph
has layed out is a flat model.  In /sys/class/sas_phy, you will see all the
phys for both hba and expander all togeather in the tree.The rphy is at the 
end of  a phy link, where it the target protocol could be SMP, STP, SATA, 
or SAS; e.g. you can see that in rphy->identify.target_port_protocols.  
You can figure out whether its an end device by the attribute by 
rphy->indentify.device_type, which could be SAS_END_DEVICE, 
SAS_EDGE_EXPANDER,  SAS_FANOUT_EXPANDER, or 
SAS_PHY_UNUSED.  

> 
> Temporarily, because mptsas doesn't do this, I've put a flag in to
> indicate whether the rphy is enveloped or not, however, if we enforce
> this for everything, then eventually that would go away.
> 

Ok, I'm not sure what this comment means, in respect to mptsas.
The mptsas driver is reporting all device types to the transport class, 
as defined in the SAS spec.

> If everyone's OK with this, I'll do expanders next.

Ok, the mptsas driver is already reporing expanders to transport class.  
This is handled from mptsas.c, in mptsas_probe_one_phy(), when
we call sas_phy_add().  When there is any attached devices  at
the end of a phy, we call  sas_rphy_add().  Both these functions 
exported from sas_transport, work well for both hba, and expanders.

The patch I sent yesterday is adding support when someone needs to 
add a expander after the start of day, or reomove one.  Its responding
to the firmware DISCOVERY event.

Eric Moore




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

* Re: [RFC] first cut at infrastructure for handling different device types in the sas class
  2006-03-04 15:47 ` Christoph Hellwig
@ 2006-03-04 18:33   ` James Bottomley
  2006-03-05  3:42     ` Luben Tuikov
  0 siblings, 1 reply; 7+ messages in thread
From: James Bottomley @ 2006-03-04 18:33 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-scsi

On Sat, 2006-03-04 at 15:47 +0000, Christoph Hellwig wrote:
> Looks good in general, but we should probably kill the rphy naming.  That was
> my invention when doing the transport class, when I still thought we'd add a
> remote object for every phy in wide links.  We ended up having just a remote
> object only under one of the phys for a wide link so we should probably
> kill this naming invention.  In the end we should probably just have
> a sas_end_device, sas_expander and sas_sata_device (or just sata_device
> if we can share code with libata) and the common subset (sas_device?)
> shouldn't be exposed to userland on it's own.

Yes ... I was going to say eventually that your rphy object is really an
rport object.

I think, additionally, it would be nice to display ports in the
hierarchy.  What I'm thinking of is basically putting phys and ports on
the same level but placing the expanders and rports (rphys) under the
port directory.  Then the phy can have a simple link to the port it's a
member of.

> this should become sas_end_device_alloc, and so on for the other
> functions.

Yes, will do the renaming ... after I spend the day in Chicago.

James



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

* Re: [RFC] first cut at infrastructure for handling different device types in the sas class
  2006-03-04 18:33   ` James Bottomley
@ 2006-03-05  3:42     ` Luben Tuikov
  0 siblings, 0 replies; 7+ messages in thread
From: Luben Tuikov @ 2006-03-05  3:42 UTC (permalink / raw)
  To: James Bottomley, Christoph Hellwig; +Cc: linux-scsi

--- James Bottomley <James.Bottomley@SteelEye.com> wrote:
>  Then the phy can have a simple link to the port it's a
> member of.

This is already the case in the SAS stack.  Here is an example of wide and
narrow ports. The wide port in this example connects to a domain with
three cascaded expanders; the narrow port to a SAS disk.

$tree -d /sys/devices/pci0000\:01/0000\:01\:04.0/host11/sas/ha 

/sys/devices/pci0000:01/0000:01:04.0/host11/sas/ha
|-- phys
|   |-- 0
|   |   `-- port -> ../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/ports/0
|   |-- 1
|   |-- 2
|   |-- 3
|   |-- 4
|   |   `-- port -> ../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/ports/1
|   |-- 5
|   |   `-- port -> ../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/ports/1
|   |-- 6
|   |   `-- port -> ../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/ports/1
|   `-- 7
|       `-- port -> ../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/ports/1
`-- ports
    |-- 0
    |   |-- domain
    |   |   `-- 500000e000031c12
    |   |       `-- LUNS
    |   |           `-- 0000000000000000
    |   `-- phys
    |       `-- 0 ->
../../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/phys/0
    `-- 1
        |-- domain
        |   `-- 50001c1716010600
        |       |-- 50001c1071609c00
        |       |   |-- 50001c1071609c02
        |       |   |-- 5000c50000102a65
        |       |   |   `-- LUNS
        |       |   |       `-- 0000000000000000
        |       |   `-- 5005076a000001e0
        |       |       |-- 5000c50000513385
        |       |       |   `-- LUNS
        |       |       |       `-- 0000000000000000
        |       |       |-- 5005076a000001ed
        |       |       |   `-- LUNS
        |       |       |       `-- 0000000000000000
        |       |       `-- 5c50000000409c11
        |       |           `-- LUNS
        |       |               `-- 0000000000000000
        |       |-- 50001c1716010603
        |       |-- 50001c171601060d
        |       |   `-- LUNS
        |       |       `-- 0000000000000000
        |       `-- 5000c50000513329
        |           `-- LUNS
        |               `-- 0000000000000000
        `-- phys
            |-- 4 ->
../../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/phys/4
            |-- 5 ->
../../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/phys/5
            |-- 6 ->
../../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/phys/6
            `-- 7 ->
../../../../../../../../../devices/pci0000:01/0000:01:04.0/host11/sas/ha/phys/7


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

* Re: [RFC] first cut at infrastructure for handling different devicetypes in the sas class
  2006-03-04 18:17 ` [RFC] first cut at infrastructure for handling different devicetypes " Moore, Eric
@ 2006-03-06 16:39   ` James Bottomley
  0 siblings, 0 replies; 7+ messages in thread
From: James Bottomley @ 2006-03-06 16:39 UTC (permalink / raw)
  To: Moore, Eric; +Cc: linux-scsi

On Sat, 2006-03-04 at 11:17 -0700, Moore, Eric wrote:
> I'm not clear what your intent is here.  All the info is there, so I'm not sure
> why this change is needed.  The sas_transport implementation Christoph
> has layed out is a flat model.  In /sys/class/sas_phy, you will see all the
> phys for both hba and expander all togeather in the tree.The rphy is at the 
> end of  a phy link, where it the target protocol could be SMP, STP, SATA, 
> or SAS; e.g. you can see that in rphy->identify.target_port_protocols.  
> You can figure out whether its an end device by the attribute by 
> rphy->indentify.device_type, which could be SAS_END_DEVICE, 
> SAS_EDGE_EXPANDER,  SAS_FANOUT_EXPANDER, or 
> SAS_PHY_UNUSED.  

Well, it's not ... the nexus loss timeout parameters weren't available.
The intent is to embed the rphys into more representative structures
that can have different parameters (an expander has parameters than an
end device doesn't and vice versa).  Eventually, when the whole lot is
converted, the ability to alloc a plain rphy will be revoked and
everything will be done via the real device type.

The aic94xx needs a full tree representation for this, so I'm planning
to add this to the sas transport class.  We really need to work out a
way for mptsas to display the tree too.  Having different topology views
for the same physical SAS topology show up when you change HBA is a bit
undesirable.

> > Temporarily, because mptsas doesn't do this, I've put a flag in to
> > indicate whether the rphy is enveloped or not, however, if we enforce
> > this for everything, then eventually that would go away.
> > 
> 
> Ok, I'm not sure what this comment means, in respect to mptsas.
> The mptsas driver is reporting all device types to the transport class, 
> as defined in the SAS spec.

It means I couldn't be bothered to add the end device allocations to
mptsas, so the code currently understands that there's a separate flag
that says whether it can be cast out to the end device or not.

> > If everyone's OK with this, I'll do expanders next.
> 
> Ok, the mptsas driver is already reporing expanders to transport class.  
> This is handled from mptsas.c, in mptsas_probe_one_phy(), when
> we call sas_phy_add().  When there is any attached devices  at
> the end of a phy, we call  sas_rphy_add().  Both these functions 
> exported from sas_transport, work well for both hba, and expanders.
> 
> The patch I sent yesterday is adding support when someone needs to 
> add a expander after the start of day, or reomove one.  Its responding
> to the firmware DISCOVERY event.

Yes, I know.  However, I need expander devices that contain the
necessary information to be able to perform discovery in the sas
transport class, so they'll appear eventually in the same way that this
patch adds end devices ... as objects with embedded rphys.

James



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

end of thread, other threads:[~2006-03-06 16:39 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-04  4:05 [RFC] first cut at infrastructure for handling different device types in the sas class James Bottomley
2006-03-04  8:28 ` Luben Tuikov
2006-03-04 15:47 ` Christoph Hellwig
2006-03-04 18:33   ` James Bottomley
2006-03-05  3:42     ` Luben Tuikov
2006-03-04 18:17 ` [RFC] first cut at infrastructure for handling different devicetypes " Moore, Eric
2006-03-06 16:39   ` James Bottomley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).