[PATCH 2/5] I2O: SPARC fixes

[PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

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

Changes:
--------
- Fixed lot of BE <-> LE bugs which prevent it from working on SPARC.

Signed-off-by: Markus Lidel <Markus.Lidel@shadowconnect.com>

[-- Attachment #2: i2o-sparc.patch --]
[-- Type: text/x-patch, Size: 12983 bytes --]

Index: linux-2.6.14/drivers/message/i2o/Kconfig
===================================================================
--- linux-2.6.14.orig/drivers/message/i2o/Kconfig	2005-11-13 19:59:37.820815086 +0100
+++ linux-2.6.14/drivers/message/i2o/Kconfig	2005-11-13 20:00:14.970785853 +0100
@@ -24,6 +24,18 @@
 
 	  If unsure, say N.
 
+config I2O_LCT_NOTIFY_ON_CHANGES
+	bool "Enable LCT notification"
+	depends on I2O
+	default y
+	---help---
+	  Only say N here if you have a I2O controller from SUN. The SUN
+	  firmware doesn't support LCT notification on changes. If this option
+	  is enabled on such a controller the driver will hang up in a endless
+	  loop. On all other controllers say Y.
+
+	  If unsure, say Y.
+
 config I2O_EXT_ADAPTEC
 	bool "Enable Adaptec extensions"
 	depends on I2O
Index: linux-2.6.14/drivers/message/i2o/device.c
===================================================================
--- linux-2.6.14.orig/drivers/message/i2o/device.c	2005-11-13 19:59:37.820815086 +0100
+++ linux-2.6.14/drivers/message/i2o/device.c	2005-11-13 20:00:23.611244213 +0100
@@ -275,56 +275,83 @@
 {
 	struct i2o_device *dev, *tmp;
 	i2o_lct *lct;
-	int i;
-	int max;
+	u32 *dlct = c->dlct.virt;
+	int max = 0, i = 0;
+	u16 table_size;
+	u32 buf;
 
 	down(&c->lct_lock);
 
 	kfree(c->lct);
 
-	lct = c->dlct.virt;
+	buf = le32_to_cpu(*dlct++);
+	table_size = buf & 0xffff;
 
-	c->lct = kmalloc(lct->table_size * 4, GFP_KERNEL);
-	if (!c->lct) {
+	lct = c->lct = kmalloc(table_size * 4, GFP_KERNEL);
+	if (!lct) {
 		up(&c->lct_lock);
 		return -ENOMEM;
 	}
 
-	if (lct->table_size * 4 > c->dlct.len) {
-		memcpy(c->lct, c->dlct.virt, c->dlct.len);
-		up(&c->lct_lock);
-		return -EAGAIN;
-	}
-
-	memcpy(c->lct, c->dlct.virt, lct->table_size * 4);
+	lct->lct_ver = buf >> 28;
+	lct->boot_tid = buf >> 16 & 0xfff;
+	lct->table_size = table_size;
+	lct->change_ind = le32_to_cpu(*dlct++);
+	lct->iop_flags = le32_to_cpu(*dlct++);
 
-	lct = c->lct;
-
-	max = (lct->table_size - 3) / 9;
+	table_size -= 3;
 
 	pr_debug("%s: LCT has %d entries (LCT size: %d)\n", c->name, max,
 		 lct->table_size);
 
-	/* remove devices, which are not in the LCT anymore */
-	list_for_each_entry_safe(dev, tmp, &c->devices, list) {
+	while (table_size > 0) {
+		i2o_lct_entry *entry = &lct->lct_entry[max];
 		int found = 0;
 
-		for (i = 0; i < max; i++) {
-			if (lct->lct_entry[i].tid == dev->lct_data.tid) {
+		buf = le32_to_cpu(*dlct++);
+		entry->entry_size = buf & 0xffff;
+		entry->tid = buf >> 16 & 0xfff;
+
+		entry->change_ind = le32_to_cpu(*dlct++);
+		entry->device_flags = le32_to_cpu(*dlct++);
+
+		buf = le32_to_cpu(*dlct++);
+		entry->class_id = buf & 0xfff;
+		entry->version = buf >> 12 & 0xf;
+		entry->vendor_id = buf >> 16;
+
+		entry->sub_class = le32_to_cpu(*dlct++);
+
+		buf = le32_to_cpu(*dlct++);
+		entry->user_tid = buf & 0xfff;
+		entry->parent_tid = buf >> 12 & 0xfff;
+		entry->bios_info = buf >> 24;
+
+		memcpy(&entry->identity_tag, dlct, 8);
+		dlct += 2;
+
+		entry->event_capabilities = le32_to_cpu(*dlct++);
+
+		/* add new devices, which are new in the LCT */
+		list_for_each_entry_safe(dev, tmp, &c->devices, list) {
+			if (entry->tid == dev->lct_data.tid) {
 				found = 1;
 				break;
 			}
 		}
 
 		if (!found)
-			i2o_device_remove(dev);
+			i2o_device_add(c, entry);
+
+		table_size -= 9;
+		max++;
 	}
 
-	/* add new devices, which are new in the LCT */
-	for (i = 0; i < max; i++) {
+	/* remove devices, which are not in the LCT anymore */
+	list_for_each_entry_safe(dev, tmp, &c->devices, list) {
 		int found = 0;
 
-		list_for_each_entry_safe(dev, tmp, &c->devices, list) {
+		for (i = 0; i < max; i++) {
 			if (lct->lct_entry[i].tid == dev->lct_data.tid) {
 				found = 1;
 				break;
@@ -332,8 +359,9 @@
 		}
 
 		if (!found)
-			i2o_device_add(c, &lct->lct_entry[i]);
+			i2o_device_remove(dev);
 	}
+
 	up(&c->lct_lock);
 
 	return 0;
@@ -447,9 +475,6 @@
 		   int oplen, void *reslist, int reslen)
 {
 	struct i2o_message *msg;
-	u32 *res32 = (u32 *) reslist;
-	u32 *restmp = (u32 *) reslist;
-	int len = 0;
 	int i = 0;
 	int rc;
 	struct i2o_dma res;
@@ -473,7 +498,6 @@
 	msg->body[i++] = cpu_to_le32(0x00000000);
 	msg->body[i++] = cpu_to_le32(0x4C000000 | oplen);	/* OperationList */
 	memcpy(&msg->body[i], oplist, oplen);
-
 	i += (oplen / 4 + (oplen % 4 ? 1 : 0));
 	msg->body[i++] = cpu_to_le32(0xD0000000 | res.len);	/* ResultList */
 	msg->body[i++] = cpu_to_le32(res.phys);
@@ -491,36 +515,7 @@
 	memcpy(reslist, res.virt, res.len);
 	i2o_dma_free(dev, &res);
 
-	/* Query failed */
-	if (rc)
-		return rc;
-	/*
-	 * Calculate number of bytes of Result LIST
-	 * We need to loop through each Result BLOCK and grab the length
-	 */
-	restmp = res32 + 1;
-	len = 1;
-	for (i = 0; i < (res32[0] & 0X0000FFFF); i++) {
-		if (restmp[0] & 0x00FF0000) {	/* BlockStatus != SUCCESS */
-			printk(KERN_WARNING
-			       "%s - Error:\n  ErrorInfoSize = 0x%02x, "
-			       "BlockStatus = 0x%02x, BlockSize = 0x%04x\n",
-			       (cmd ==
-				I2O_CMD_UTIL_PARAMS_SET) ? "PARAMS_SET" :
-			       "PARAMS_GET", res32[1] >> 24,
-			       (res32[1] >> 16) & 0xFF, res32[1] & 0xFFFF);
-
-			/*
-			 *      If this is the only request,than we return an error
-			 */
-			if ((res32[0] & 0x0000FFFF) == 1) {
-				return -((res32[1] >> 16) & 0xFF);	/* -BlockStatus */
-			}
-		}
-		len += restmp[0] & 0x0000FFFF;	/* Length of res BLOCK */
-		restmp += restmp[0] & 0x0000FFFF;	/* Skip to next BLOCK */
-	}
-	return (len << 2);	/* bytes used by result list */
+	return rc;
 }
 
 /*
@@ -529,28 +524,25 @@
 int i2o_parm_field_get(struct i2o_device *i2o_dev, int group, int field,
 		       void *buf, int buflen)
 {
-	u16 opblk[] = { 1, 0, I2O_PARAMS_FIELD_GET, group, 1, field };
+	u32 opblk[] = { cpu_to_le32(0x00000001),
+		cpu_to_le32((u16) group << 16 | I2O_PARAMS_FIELD_GET),
+		cpu_to_le32((s16) field << 16 | 0x00000001)
+	};
 	u8 *resblk;		/* 8 bytes for header */
-	int size;
-
-	if (field == -1)	/* whole group */
-		opblk[4] = -1;
+	int rc;
 
 	resblk = kmalloc(buflen + 8, GFP_KERNEL | GFP_ATOMIC);
 	if (!resblk)
 		return -ENOMEM;
 
-	size = i2o_parm_issue(i2o_dev, I2O_CMD_UTIL_PARAMS_GET, opblk,
-			      sizeof(opblk), resblk, buflen + 8);
+	rc = i2o_parm_issue(i2o_dev, I2O_CMD_UTIL_PARAMS_GET, opblk,
+			    sizeof(opblk), resblk, buflen + 8);
 
 	memcpy(buf, resblk + 8, buflen);	/* cut off header */
 
 	kfree(resblk);
 
-	if (size > buflen)
-		return buflen;
-
-	return size;
+	return rc;
 }
 
 /*
Index: linux-2.6.14/drivers/message/i2o/exec-osm.c
===================================================================
--- linux-2.6.14.orig/drivers/message/i2o/exec-osm.c	2005-11-13 19:59:37.820815086 +0100
+++ linux-2.6.14/drivers/message/i2o/exec-osm.c	2005-11-13 20:00:15.078791582 +0100
@@ -72,7 +72,7 @@
 
 	wait = kmalloc(sizeof(*wait), GFP_KERNEL);
 	if (!wait)
-		return ERR_PTR(-ENOMEM);
+		return NULL;
 
 	memset(wait, 0, sizeof(*wait));
 
@@ -266,8 +266,8 @@
 	struct i2o_device *dev = to_i2o_device(d);
 	u16 id;
 
-	if (i2o_parm_field_get(dev, 0x0000, 0, &id, 2)) {
-		sprintf(buf, "0x%04x", id);
+	if (!i2o_parm_field_get(dev, 0x0000, 0, &id, 2)) {
+		sprintf(buf, "0x%04x", le16_to_cpu(id));
 		return strlen(buf) + 1;
 	}
 
@@ -288,8 +288,8 @@
 	struct i2o_device *dev = to_i2o_device(d);
 	u16 id;
 
-	if (i2o_parm_field_get(dev, 0x0000, 1, &id, 2)) {
-		sprintf(buf, "0x%04x", id);
+	if (!i2o_parm_field_get(dev, 0x0000, 1, &id, 2)) {
+		sprintf(buf, "0x%04x", le16_to_cpu(id));
 		return strlen(buf) + 1;
 	}
 
@@ -359,7 +359,9 @@
 	if (i2o_device_parse_lct(c) != -EAGAIN)
 		change_ind = c->lct->change_ind + 1;
 
+#ifdef CONFIG_I2O_LCT_NOTIFY_ON_CHANGES
 	i2o_exec_lct_notify(c, change_ind);
+#endif
 };
 
 /**
@@ -507,7 +509,8 @@
 
 	dev = &c->pdev->dev;
 
-	if (i2o_dma_realloc(dev, &c->dlct, sb->expected_lct_size, GFP_KERNEL))
+	if (i2o_dma_realloc
+	    (dev, &c->dlct, le32_to_cpu(sb->expected_lct_size), GFP_KERNEL))
 		return -ENOMEM;
 
 	msg = i2o_msg_get_wait(c, I2O_TIMEOUT_MESSAGE_GET);
Index: linux-2.6.14/drivers/message/i2o/i2o_block.c
===================================================================
--- linux-2.6.14.orig/drivers/message/i2o/i2o_block.c	2005-11-13 19:59:37.820815086 +0100
+++ linux-2.6.14/drivers/message/i2o/i2o_block.c	2005-11-13 20:00:15.082791795 +0100
@@ -1050,8 +1050,8 @@
 	int rc;
 	u64 size;
 	u32 blocksize;
-	u32 flags, status;
 	u16 body_size = 4;
+	u16 power;
 	unsigned short max_sectors;
 
 #ifdef CONFIG_I2O_EXT_ADAPTEC
@@ -1109,22 +1109,20 @@
 	 *      Ask for the current media data. If that isn't supported
 	 *      then we ask for the device capacity data
 	 */
-	if (i2o_parm_field_get(i2o_dev, 0x0004, 1, &blocksize, 4) ||
-	    i2o_parm_field_get(i2o_dev, 0x0000, 3, &blocksize, 4)) {
-		blk_queue_hardsect_size(queue, blocksize);
+	if (!i2o_parm_field_get(i2o_dev, 0x0004, 1, &blocksize, 4) ||
+	    !i2o_parm_field_get(i2o_dev, 0x0000, 3, &blocksize, 4)) {
+		blk_queue_hardsect_size(queue, le32_to_cpu(blocksize));
 	} else
 		osm_warn("unable to get blocksize of %s\n", gd->disk_name);
 
-	if (i2o_parm_field_get(i2o_dev, 0x0004, 0, &size, 8) ||
-	    i2o_parm_field_get(i2o_dev, 0x0000, 4, &size, 8)) {
-		set_capacity(gd, size >> KERNEL_SECTOR_SHIFT);
+	if (!i2o_parm_field_get(i2o_dev, 0x0004, 0, &size, 8) ||
+	    !i2o_parm_field_get(i2o_dev, 0x0000, 4, &size, 8)) {
+		set_capacity(gd, le64_to_cpu(size) >> KERNEL_SECTOR_SHIFT);
 	} else
 		osm_warn("could not get size of %s\n", gd->disk_name);
 
-	if (!i2o_parm_field_get(i2o_dev, 0x0000, 2, &i2o_blk_dev->power, 2))
-		i2o_blk_dev->power = 0;
-	i2o_parm_field_get(i2o_dev, 0x0000, 5, &flags, 4);
-	i2o_parm_field_get(i2o_dev, 0x0000, 6, &status, 4);
+	if (!i2o_parm_field_get(i2o_dev, 0x0000, 2, &power, 2))
+		i2o_blk_dev->power = power;
 
 	i2o_event_register(i2o_dev, &i2o_block_driver, 0, 0xffffffff);
 
Index: linux-2.6.14/drivers/message/i2o/i2o_scsi.c
===================================================================
--- linux-2.6.14.orig/drivers/message/i2o/i2o_scsi.c	2005-11-13 19:59:37.824815298 +0100
+++ linux-2.6.14/drivers/message/i2o/i2o_scsi.c	2005-11-13 20:00:15.082791795 +0100
@@ -113,7 +113,7 @@
 
 	list_for_each_entry(i2o_dev, &c->devices, list)
 	    if (i2o_dev->lct_data.class_id == I2O_CLASS_BUS_ADAPTER) {
-		if (i2o_parm_field_get(i2o_dev, 0x0000, 0, &type, 1)
+		if (!i2o_parm_field_get(i2o_dev, 0x0000, 0, &type, 1)
 		    && (type == 0x01))	/* SCSI bus */
 			max_channel++;
 	}
@@ -146,7 +146,7 @@
 	i = 0;
 	list_for_each_entry(i2o_dev, &c->devices, list)
 	    if (i2o_dev->lct_data.class_id == I2O_CLASS_BUS_ADAPTER) {
-		if (i2o_parm_field_get(i2o_dev, 0x0000, 0, &type, 1)
+		if (!i2o_parm_field_get(i2o_dev, 0x0000, 0, &type, 1)
 		    && (type == 0x01))	/* only SCSI bus */
 			i2o_shost->channel[i++] = i2o_dev;
 
@@ -238,13 +238,15 @@
 			u8 type;
 			struct i2o_device *d = i2o_shost->channel[0];
 
-			if (i2o_parm_field_get(d, 0x0000, 0, &type, 1)
+			if (!i2o_parm_field_get(d, 0x0000, 0, &type, 1)
 			    && (type == 0x01))	/* SCSI bus */
-				if (i2o_parm_field_get(d, 0x0200, 4, &id, 4)) {
+				if (!i2o_parm_field_get(d, 0x0200, 4, &id, 4)) {
 					channel = 0;
 					if (i2o_dev->lct_data.class_id ==
 					    I2O_CLASS_RANDOM_BLOCK_STORAGE)
-						lun = i2o_shost->lun++;
+						lun =
+						    cpu_to_le64(i2o_shost->
+								lun++);
 					else
 						lun = 0;
 				}
@@ -253,10 +255,10 @@
 		break;
 
 	case I2O_CLASS_SCSI_PERIPHERAL:
-		if (i2o_parm_field_get(i2o_dev, 0x0000, 3, &id, 4) < 0)
+		if (i2o_parm_field_get(i2o_dev, 0x0000, 3, &id, 4))
 			return -EFAULT;
 
-		if (i2o_parm_field_get(i2o_dev, 0x0000, 4, &lun, 8) < 0)
+		if (i2o_parm_field_get(i2o_dev, 0x0000, 4, &lun, 8))
 			return -EFAULT;
 
 		parent = i2o_iop_find_device(c, i2o_dev->lct_data.parent_tid);
@@ -281,20 +283,22 @@
 		return -EFAULT;
 	}
 
-	if (id >= scsi_host->max_id) {
-		osm_warn("SCSI device id (%d) >= max_id of I2O host (%d)", id,
-			 scsi_host->max_id);
+	if (le32_to_cpu(id) >= scsi_host->max_id) {
+		osm_warn("SCSI device id (%d) >= max_id of I2O host (%d)",
+			 le32_to_cpu(id), scsi_host->max_id);
 		return -EFAULT;
 	}
 
-	if (lun >= scsi_host->max_lun) {
-		osm_warn("SCSI device id (%d) >= max_lun of I2O host (%d)",
-			 (unsigned int)lun, scsi_host->max_lun);
+	if (le64_to_cpu(lun) >= scsi_host->max_lun) {
+		osm_warn("SCSI device lun (%lu) >= max_lun of I2O host (%d)",
+			 (long unsigned int)le64_to_cpu(lun),
+			 scsi_host->max_lun);
 		return -EFAULT;
 	}
 
 	scsi_dev =
-	    __scsi_add_device(i2o_shost->scsi_host, channel, id, lun, i2o_dev);
+	    __scsi_add_device(i2o_shost->scsi_host, channel, le32_to_cpu(id),
+			      le64_to_cpu(lun), i2o_dev);
 
 	if (IS_ERR(scsi_dev)) {
 		osm_warn("can not add SCSI device %03x\n",
@@ -306,7 +310,8 @@
 			  "scsi");
 
 	osm_info("device added (TID: %03x) channel: %d, id: %d, lun: %d\n",
-		 i2o_dev->lct_data.tid, channel, id, (unsigned int)lun);
+		 i2o_dev->lct_data.tid, channel, le32_to_cpu(id),
+		 (unsigned int)le64_to_cpu(lun));
 
 	return 0;
 };

Re: [PATCH 2/5] I2O: SPARC fixes

[David S. Miller]

From: Markus Lidel <Markus.Lidel@shadowconnect.com>
Date: Tue, 15 Nov 2005 10:31:09 +0100

> +config I2O_LCT_NOTIFY_ON_CHANGES
> +	bool "Enable LCT notification"
> +	depends on I2O
> +	default y
> +	---help---
> +	  Only say N here if you have a I2O controller from SUN. The SUN
> +	  firmware doesn't support LCT notification on changes. If this option
> +	  is enabled on such a controller the driver will hang up in a endless
> +	  loop. On all other controllers say Y.
> +
> +	  If unsure, say Y.
> +

This should be detected at runtime, and that is easily done.

You can use the PCI device to get at the firmware device
node, and use that to look for a firmware device node property
that identifies it as a card from Sun.

Usually the "name" property has some identifying string in it.
Sometimes there is a property with the string "fcode" in it and you
could look for that as well.

Re: [PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

Hello,

David S. Miller wrote:
> From: Markus Lidel <Markus.Lidel@shadowconnect.com>
>>+config I2O_LCT_NOTIFY_ON_CHANGES
>>+	bool "Enable LCT notification"
>>+	depends on I2O
>>+	default y
>>+	---help---
>>+	  Only say N here if you have a I2O controller from SUN. The SUN
>>+	  firmware doesn't support LCT notification on changes. If this option
>>+	  is enabled on such a controller the driver will hang up in a endless
>>+	  loop. On all other controllers say Y.
>>+
>>+	  If unsure, say Y.
>>+
> 
> This should be detected at runtime, and that is easily done.
> You can use the PCI device to get at the firmware device
> node, and use that to look for a firmware device node property
> that identifies it as a card from Sun.
> Usually the "name" property has some identifying string in it.
> Sometimes there is a property with the string "fcode" in it and you
> could look for that as well.

OK, i'll look at it... Thanks for the hint!



Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: [PATCH 2/5] I2O: SPARC fixes

[David S. Miller]

From: Markus Lidel <Markus.Lidel@shadowconnect.com>
Date: Wed, 16 Nov 2005 13:25:50 +0100

> > This should be detected at runtime, and that is easily done.
> > You can use the PCI device to get at the firmware device
> > node, and use that to look for a firmware device node property
> > that identifies it as a card from Sun.
> > Usually the "name" property has some identifying string in it.
> > Sometimes there is a property with the string "fcode" in it and you
> > could look for that as well.
> 
> OK, i'll look at it... Thanks for the hint!

Actually, my idea won't work if the card is used in a non-Sparc
system.  Do these cards have PCI subsystem vendor or device ID's that
identify it as a Sun card?

Re: [PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

Hello,

David S. Miller wrote:
>>>This should be detected at runtime, and that is easily done.
>>>You can use the PCI device to get at the firmware device
>>>node, and use that to look for a firmware device node property
>>>that identifies it as a card from Sun.
>>>Usually the "name" property has some identifying string in it.
>>>Sometimes there is a property with the string "fcode" in it and you
>>>could look for that as well.
>>OK, i'll look at it... Thanks for the hint!
> Actually, my idea won't work if the card is used in a non-Sparc
> system.  Do these cards have PCI subsystem vendor or device ID's that
> identify it as a Sun card?

I don't know, because currently i only look for the PCI class. I'll check 
it out and report back...

Thank you very much for your help!



Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: [PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

Hello,

David S. Miller wrote:
> From: Markus Lidel <Markus.Lidel@shadowconnect.com>
> Date: Wed, 16 Nov 2005 13:25:50 +0100
>>>This should be detected at runtime, and that is easily done.
>>>You can use the PCI device to get at the firmware device
>>>node, and use that to look for a firmware device node property
>>>that identifies it as a card from Sun.
>>>Usually the "name" property has some identifying string in it.
>>>Sometimes there is a property with the string "fcode" in it and you
>>>could look for that as well.
>>OK, i'll look at it... Thanks for the hint!
> Actually, my idea won't work if the card is used in a non-Sparc
> system.  Do these cards have PCI subsystem vendor or device ID's that
> identify it as a Sun card?

Here's the output of lspci:

0003:01:03.0 Memory controller: Adaptec (formerly DPT) Domino RAID Engine 
(rev 02)
         Subsystem: Adaptec (formerly DPT) Domino RAID Engine
         Flags: bus master, medium devsel, latency 32, IRQ 0082efe0
         BIST result: 00
         Memory at 000001c980100000 (32-bit, non-prefetchable) [size=64K]
         Memory at 000001c988000000 (32-bit, prefetchable) [size=128M]

0003:01:04.0 I2O: Adaptec (formerly DPT) SmartRAID V Controller (rev 03)
         Subsystem: Adaptec (formerly DPT) SmartRAID V Controller
         Flags: bus master, medium devsel, latency 1, IRQ 0082ef80
         BIST result: 00
         Memory at 000001c990000000 (32-bit, non-prefetchable) [size=2M]
         I/O ports at 0000000002010400 [size=256]
         Expansion ROM at 0000000080000000 [disabled] [size=32K]

As it looks it's equal to the "Intel" based cards...

Don't think it will work then, right?



Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: [PATCH 2/5] I2O: SPARC fixes

[David S. Miller]

From: Markus Lidel <Markus.Lidel@shadowconnect.com>
Date: Sat, 19 Nov 2005 02:07:39 +0100

> Here's the output of lspci:
> 
> 0003:01:03.0 Memory controller: Adaptec (formerly DPT) Domino RAID Engine 
> (rev 02)
>          Subsystem: Adaptec (formerly DPT) Domino RAID Engine
>          Flags: bus master, medium devsel, latency 32, IRQ 0082efe0
>          BIST result: 00
>          Memory at 000001c980100000 (32-bit, non-prefetchable) [size=64K]
>          Memory at 000001c988000000 (32-bit, prefetchable) [size=128M]
> 
> 0003:01:04.0 I2O: Adaptec (formerly DPT) SmartRAID V Controller (rev 03)
>          Subsystem: Adaptec (formerly DPT) SmartRAID V Controller
>          Flags: bus master, medium devsel, latency 1, IRQ 0082ef80
>          BIST result: 00
>          Memory at 000001c990000000 (32-bit, non-prefetchable) [size=2M]
>          I/O ports at 0000000002010400 [size=256]
>          Expansion ROM at 0000000080000000 [disabled] [size=32K]
> 
> As it looks it's equal to the "Intel" based cards...
> 
> Don't think it will work then, right?

No, it won't.

Ho hum, I guess keep it a config option for now until we find a
way to auto-detect this reliably.

Re: [PATCH 2/5] I2O: SPARC fixes

[Alan Cox]

On Gwe, 2005-11-18 at 17:22 -0800, David S. Miller wrote:
> Ho hum, I guess keep it a config option for now until we find a
> way to auto-detect this reliably.

The notify functionality is mandatory. You are seeing the same cards
fail on sparc but work on x86. This sounds to me a lot more like an
unfound endian bug that needs fixing than a real lack of support

Re: [PATCH 2/5] I2O: SPARC fixes

[David S. Miller]

From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Sat, 19 Nov 2005 03:30:39 +0000

> On Gwe, 2005-11-18 at 17:22 -0800, David S. Miller wrote:
> > Ho hum, I guess keep it a config option for now until we find a
> > way to auto-detect this reliably.
> 
> The notify functionality is mandatory. You are seeing the same cards
> fail on sparc but work on x86. This sounds to me a lot more like an
> unfound endian bug that needs fixing than a real lack of support

That's very possible, but it also could be that the cards
that fail only on Sparc have Sun forth firmware on them,
which would thus only load firmware on Sparc boxes.

I still think the endianness theory is more likely, however.

Perhaps the I2O datastructures should be endian annotated
and then pushed through sparse. :-)

Re: [PATCH 2/5] I2O: SPARC fixes

[Alan Cox]

On Gwe, 2005-11-18 at 20:37 -0800, David S. Miller wrote:
> That's very possible, but it also could be that the cards
> that fail only on Sparc have Sun forth firmware on them,
> which would thus only load firmware on Sparc boxes.

The firmware on the DPT I2O card processor is kept in flash on the
processor. The BIOS setup code might be different but nothing at the
business end of things

Re: [PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

Hi...

Alan Cox wrote:
>> On Gwe, 2005-11-18 at 17:22 -0800, David S. Miller wrote:
>>>Ho hum, I guess keep it a config option for now until we find a
>>>way to auto-detect this reliably.
>> The notify functionality is mandatory. You are seeing the same cards
>> fail on sparc but work on x86. This sounds to me a lot more like an
>> unfound endian bug that needs fixing than a real lack of support
>>That's very possible, but it also could be that the cards
>>that fail only on Sparc have Sun forth firmware on them,
>>which would thus only load firmware on Sparc boxes.
> The firmware on the DPT I2O card processor is kept in flash on the
> processor. The BIOS setup code might be different but nothing at the
> business end of things

That's right there are two different firmwares. One for "Intel"-cards and 
one for SUN-cards. The LCT-Notify function works as follow.

The LCT on the I2O controller has a change indicator which is incremented 
by the I2O controller each time something changes (e. g. a disk is 
removed or added or so). The i2o_exec_lct_notify() function only send a 
number to the I2O controller. If this number is <= then the current 
change indicator of the LCT, then the controller send out the new LCT to 
the OS. On startup the change indicator is normally 1. So if there is 
some BE<->LE issue, then the function wouldn't send in 0x00000002 but 
0x02000000. What should happen then is that you won't be notified for a 
long time. But that didn't happened, and the controller immediately send 
out the LCT, although if you send in 0xffffffff. And as i'm told, this is 
wanted for some reason for the "SUN"-firmware.

It should probably be "fixed" if you upload a "Intel"-firmware onto the 
I2O controller, but because i don't own a SPARC machine with a PCI slot 
myself, i don't want to try it out on someones else machine and probably 
break it :-)

If someone has a SPARC machine with an I2O controller, and he want to try 
it out, please let me know...

Bye...
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: [PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

Hi...

David S. Miller wrote:
> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Sat, 19 Nov 2005 03:30:39 +0000
>>On Gwe, 2005-11-18 at 17:22 -0800, David S. Miller wrote:
>>>Ho hum, I guess keep it a config option for now until we find a
>>>way to auto-detect this reliably.
>>The notify functionality is mandatory. You are seeing the same cards
>>fail on sparc but work on x86. This sounds to me a lot more like an
>>unfound endian bug that needs fixing than a real lack of support
> That's very possible, but it also could be that the cards
> that fail only on Sparc have Sun forth firmware on them,
> which would thus only load firmware on Sparc boxes.
> I still think the endianness theory is more likely, however.
> Perhaps the I2O datastructures should be endian annotated
> and then pushed through sparse. :-)

Sounds good to me. Could i then find out if some BE<=>LE issues are still 
left? If so, is there a document which describes how it is done, or at 
least has a driver added it already?

Bye...
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: [PATCH 2/5] I2O: SPARC fixes

[Al Viro]

On Sun, Nov 20, 2005 at 10:42:09PM +0100, Markus Lidel wrote:
> Hi...
> Sounds good to me. Could i then find out if some BE<=>LE issues are still 
> left? If so, is there a document which describes how it is done, or at 
> least has a driver added it already?

Hmm...

struct i2o_message {
        union {
                struct {
                        u8 version_offset;
                        u8 flags;
                        u16 size;
                        u32 target_tid:12;
                        u32 init_tid:12;
                        u32 function:8;
                        u32 icntxt;     /* initiator context */
                        u32 tcntxt;     /* transaction context */
                } s;
                u32 head[4];
        } u;
        /* List follows */
        u32 body[0];
};

is one hell of an endianness issue right fscking there.

Re: [PATCH 2/5] I2O: SPARC fixes

[Al Viro]

	And here's another fun one:
                evt->size = size;
                evt->tcntxt = le32_to_cpu(msg->u.s.tcntxt);
                evt->event_indicator = le32_to_cpu(msg->body[0]);
                memcpy(&evt->tcntxt, &msg->u.s.tcntxt, size * 4);
in i2o_driver_dispatch().

We have
struct i2o_event {
        struct work_struct work;
        struct i2o_device *i2o_dev;     /* I2O device pointer from which the
                                           event reply was initiated */
        u16 size;               /* Size of data in 32-bit words */
        u32 tcntxt;             /* Transaction context used at
                                   registration */
        u32 event_indicator;    /* Event indicator from reply */
        u32 data[0];            /* Event data from reply */
};

and
in msg tcntxt goes right before body[0].  So we copy two 32bit values
converting to host order and then immediately overwrite them with
unconverted ones.

Looks like these assignments were meant to go *after* memcpy() and
serve as a fixup...

Re: [PATCH 2/5] I2O: SPARC fixes

[Al Viro]

On Sun, Nov 20, 2005 at 11:07:14PM +0000, Al Viro wrote:
> 	And here's another fun one:
>                 evt->size = size;
>                 evt->tcntxt = le32_to_cpu(msg->u.s.tcntxt);
>                 evt->event_indicator = le32_to_cpu(msg->body[0]);
>                 memcpy(&evt->tcntxt, &msg->u.s.tcntxt, size * 4);
> in i2o_driver_dispatch().

Gaaack...  Old code used to be
                       evt = kmalloc(size * 4 + sizeof(*evt), GFP_ATOMIC);
                       if (!evt)
                               return -ENOMEM;
                       memset(evt, 0, size * 4 + sizeof(*evt));

                       evt->size = size;
                       memcpy_fromio(&evt->tcntxt, &msg->u.s.tcntxt,
                                    (size + 2) * 4);

Then it became
               evt->size = size;
               evt->tcntxt = readl(&msg->u.s.tcntxt);
               evt->event_indicator = readl(&msg->body[0]);
               memcpy_fromio(&evt->tcntxt, &msg->u.s.tcntxt, size * 4);

See the problem with it?  The last copy should be from &msg->body[1] to
evt->data.  As it is, we do not copy the last 8 bytes (which might or
might not be a problem) *AND* we overwrite tcntxt and event_indicator
with bus-endian values right after having host-endian ones carefully
assigned to them.

Breakage happened in
diff-tree 61fbfa8129c1771061a0e9f47747854293081c5b (from 34d6e07570ef74b96513145
Author: Markus Lidel <Markus.Lidel@shadowconnect.com>
Date:   Thu Jun 23 22:02:11 2005 -0700

    [PATCH] I2O: bugfixes and compability enhancements

Re: [PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

Hello,

Al Viro wrote:
> On Sun, Nov 20, 2005 at 11:07:14PM +0000, Al Viro wrote:
>>	And here's another fun one:
>>                evt->size = size;
>>                evt->tcntxt = le32_to_cpu(msg->u.s.tcntxt);
>>                evt->event_indicator = le32_to_cpu(msg->body[0]);
>>                memcpy(&evt->tcntxt, &msg->u.s.tcntxt, size * 4);
>>in i2o_driver_dispatch().
> Gaaack...  Old code used to be
>                        evt = kmalloc(size * 4 + sizeof(*evt), GFP_ATOMIC);
>                        if (!evt)
>                                return -ENOMEM;
>                        memset(evt, 0, size * 4 + sizeof(*evt));
> 
>                        evt->size = size;
>                        memcpy_fromio(&evt->tcntxt, &msg->u.s.tcntxt,
>                                     (size + 2) * 4);
> Then it became
>                evt->size = size;
>                evt->tcntxt = readl(&msg->u.s.tcntxt);
>                evt->event_indicator = readl(&msg->body[0]);
>                memcpy_fromio(&evt->tcntxt, &msg->u.s.tcntxt, size * 4);
> See the problem with it?  The last copy should be from &msg->body[1] to
> evt->data.  As it is, we do not copy the last 8 bytes (which might or
> might not be a problem) *AND* we overwrite tcntxt and event_indicator

At the moment it's not a problem, because the event system is not used...

> with bus-endian values right after having host-endian ones carefully
> assigned to them.

Yep, you're right...  the memcpy_fromio is wrong... It should be:

memcpy_fromio(&evt->body[1], &msg->body[1], size * 4);

as you already mentioned...

Thanks for your help.


Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com

Re: [PATCH 2/5] I2O: SPARC fixes

[Al Viro]

On Mon, Nov 21, 2005 at 01:48:10AM +0100, Markus Lidel wrote:
> Yep, you're right...  the memcpy_fromio is wrong... It should be:
> 
> memcpy_fromio(&evt->body[1], &msg->body[1], size * 4);
> 
> as you already mentioned...

BTW, should that be memcpy() or memcpy_fromio()?  IOW, what memory
does msg point to?

Re: [PATCH 2/5] I2O: SPARC fixes

[Al Viro]

On Mon, Nov 21, 2005 at 01:48:10AM +0100, Markus Lidel wrote:
> memcpy_fromio(&evt->body[1], &msg->body[1], size * 4);

                evt->data, surely?

Re: [PATCH 2/5] I2O: SPARC fixes

[Markus Lidel]

Hello,

Al Viro wrote:
> On Mon, Nov 21, 2005 at 01:48:10AM +0100, Markus Lidel wrote:
>>memcpy_fromio(&evt->body[1], &msg->body[1], size * 4);
>                 evt->data, surely?

Hehehe, probably i should first try to compile it before replying :-) But 
better late then never :-)

Here the proper line:

   memcpy(&evt->data, &msg->body[1], size * 4);

Thanks for you help!



Best regards,


Markus Lidel
------------------------------------------
Markus Lidel (Senior IT Consultant)

Shadow Connect GmbH
Carl-Reisch-Weg 12
D-86381 Krumbach
Germany

Phone:  +49 82 82/99 51-0
Fax:    +49 82 82/99 51-11

E-Mail: Markus.Lidel@shadowconnect.com
URL:    http://www.shadowconnect.com