Re: cciss CSMI via sysfs for 2.6

2005-03-01 Thread Christoph Hellwig
On Fri, Feb 18, 2005 at 12:05:52PM -0800, Greg KH wrote:
> On Fri, Feb 18, 2005 at 07:46:28PM +, Christoph Hellwig wrote:
> > >  /*
> > > + * sysfs stuff
> > > + * this should be moved to it's own file, maybe cciss_sysfs.h
> > > + */
> > > +
> > > +static ssize_t cciss_firmver_show(struct device *dev, char *buf)
> > > +{
> > > + ctlr_info_t *h = dev->driver_data;
> > > +return sprintf(buf,"%c%c%c%c\n", h->firm_ver[0], h->firm_ver[1],
> > > +h->firm_ver[2], h->firm_ver[3]);
> > > +}
> > 
> > I really wish we had a common firmver release attribut in the driver
> > core, as mentioned in the fc transport class thread.  Greg?
> 
> For a device?  It seems a huge overkill to add this attribute for
> _every_ device in the system, when only a small minority can actually
> use it.  Just put it as a default scsi or transport class attribute
> instead.

it's not related to scsi or a transport at all.  I'd rather have the
notation of optional generic attributes so that every driver that
wantsa to publish it does so in the same way.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-03-01 Thread Christoph Hellwig
On Fri, Feb 18, 2005 at 12:05:52PM -0800, Greg KH wrote:
 On Fri, Feb 18, 2005 at 07:46:28PM +, Christoph Hellwig wrote:
/*
   + * sysfs stuff
   + * this should be moved to it's own file, maybe cciss_sysfs.h
   + */
   +
   +static ssize_t cciss_firmver_show(struct device *dev, char *buf)
   +{
   + ctlr_info_t *h = dev-driver_data;
   +return sprintf(buf,%c%c%c%c\n, h-firm_ver[0], h-firm_ver[1],
   +h-firm_ver[2], h-firm_ver[3]);
   +}
  
  I really wish we had a common firmver release attribut in the driver
  core, as mentioned in the fc transport class thread.  Greg?
 
 For a device?  It seems a huge overkill to add this attribute for
 _every_ device in the system, when only a small minority can actually
 use it.  Just put it as a default scsi or transport class attribute
 instead.

it's not related to scsi or a transport at all.  I'd rather have the
notation of optional generic attributes so that every driver that
wantsa to publish it does so in the same way.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: cciss CSMI via sysfs for 2.6

2005-02-22 Thread Miller, Mike (OS Dev)
> -Original Message-
> From: Toon van der Pas [mailto:[EMAIL PROTECTED]
> > +
> > +   iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
> > +   c->cmd_type = CMD_IOCTL_PEND;
> > +   c->Header.ReplyQueue = 0;
> > +   
> > +   //Do we send the whole buffer?
> > +   if (iocommand.IoctlHeader.Length > 0){
> 
> This test will always be true, no?

Yes, I'll fix that. 

Thanks,
mikem

> 
> > +   c->Header.SGList = 1;
> > +   c->Header.SGTotal = 1;
> > +   } else {
> > +   c->Header.SGList = 0;
> > +   c->Header.SGTotal = 0;
> > +   }
> 
> -- 
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: cciss CSMI via sysfs for 2.6

2005-02-22 Thread Miller, Mike (OS Dev)
 -Original Message-
 From: Toon van der Pas [mailto:[EMAIL PROTECTED]
  +
  +   iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
  +   c-cmd_type = CMD_IOCTL_PEND;
  +   c-Header.ReplyQueue = 0;
  +   
  +   //Do we send the whole buffer?
  +   if (iocommand.IoctlHeader.Length  0){
 
 This test will always be true, no?

Yes, I'll fix that. 

Thanks,
mikem

 
  +   c-Header.SGList = 1;
  +   c-Header.SGTotal = 1;
  +   } else {
  +   c-Header.SGList = 0;
  +   c-Header.SGTotal = 0;
  +   }
 
 -- 
 Debugging is twice as hard as writing the code in the first place.
 Therefore, if you write the code as cleverly as possible, you are,
 by definition, not smart enough to debug it. - Brian W. Kernighan
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-19 Thread Toon van der Pas
On Wed, Feb 16, 2005 at 10:45:12AM -0600, [EMAIL PROTECTED] wrote:
> +static ssize_t cciss_phyinfo_show(struct device *dev, char *buf)
> +{
> + ctlr_info_t *h = dev->driver_data;
> + unsigned long flags;
> + CommandList_struct *c;
> + CSMI_SAS_PHY_INFO_BUFFER iocommand;
> + CSMI_SAS_IDENTIFY p;
> + u64bit temp64;
> + DECLARE_COMPLETION(wait);
> +
> + printk(KERN_WARNING "cciss: into cciss_phyinfo_show\n");
> + memset(, 0, sizeof(CSMI_SAS_PHY_INFO_BUFFER));
> + memset(, 0, sizeof(CSMI_SAS_IDENTIFY));
> +
> + /* allocate and fill in the command */
> + if ((c = cmd_alloc(h, 0)) == NULL)
> + return -ENOMEM;
> +
> + iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
> + c->cmd_type = CMD_IOCTL_PEND;
> + c->Header.ReplyQueue = 0;
> + 
> + //Do we send the whole buffer?
> + if (iocommand.IoctlHeader.Length > 0){

This test will always be true, no?

> + c->Header.SGList = 1;
> + c->Header.SGTotal = 1;
> + } else {
> + c->Header.SGList = 0;
> + c->Header.SGTotal = 0;
> + }

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-19 Thread Toon van der Pas
On Wed, Feb 16, 2005 at 10:45:12AM -0600, [EMAIL PROTECTED] wrote:
 +static ssize_t cciss_phyinfo_show(struct device *dev, char *buf)
 +{
 + ctlr_info_t *h = dev-driver_data;
 + unsigned long flags;
 + CommandList_struct *c;
 + CSMI_SAS_PHY_INFO_BUFFER iocommand;
 + CSMI_SAS_IDENTIFY p;
 + u64bit temp64;
 + DECLARE_COMPLETION(wait);
 +
 + printk(KERN_WARNING cciss: into cciss_phyinfo_show\n);
 + memset(iocommand, 0, sizeof(CSMI_SAS_PHY_INFO_BUFFER));
 + memset(p, 0, sizeof(CSMI_SAS_IDENTIFY));
 +
 + /* allocate and fill in the command */
 + if ((c = cmd_alloc(h, 0)) == NULL)
 + return -ENOMEM;
 +
 + iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
 + c-cmd_type = CMD_IOCTL_PEND;
 + c-Header.ReplyQueue = 0;
 + 
 + //Do we send the whole buffer?
 + if (iocommand.IoctlHeader.Length  0){

This test will always be true, no?

 + c-Header.SGList = 1;
 + c-Header.SGTotal = 1;
 + } else {
 + c-Header.SGList = 0;
 + c-Header.SGTotal = 0;
 + }

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-18 Thread James Bottomley
On Fri, 2005-02-18 at 12:05 -0800, Greg KH wrote:
> For a device?  It seems a huge overkill to add this attribute for
> _every_ device in the system, when only a small minority can actually
> use it.  Just put it as a default scsi or transport class attribute
> instead.

Actually, we might be able to do this as a simple attribute container
rather than a transport class, but I agree, it's not a generic property
of every device.

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-18 Thread Greg KH
On Fri, Feb 18, 2005 at 07:46:28PM +, Christoph Hellwig wrote:
> >  /*
> > + * sysfs stuff
> > + * this should be moved to it's own file, maybe cciss_sysfs.h
> > + */
> > +
> > +static ssize_t cciss_firmver_show(struct device *dev, char *buf)
> > +{
> > +   ctlr_info_t *h = dev->driver_data;
> > +return sprintf(buf,"%c%c%c%c\n", h->firm_ver[0], h->firm_ver[1],
> > +h->firm_ver[2], h->firm_ver[3]);
> > +}
> 
> I really wish we had a common firmver release attribut in the driver
> core, as mentioned in the fc transport class thread.  Greg?

For a device?  It seems a huge overkill to add this attribute for
_every_ device in the system, when only a small minority can actually
use it.  Just put it as a default scsi or transport class attribute
instead.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-18 Thread Christoph Hellwig
>  /*
> + * sysfs stuff
> + * this should be moved to it's own file, maybe cciss_sysfs.h
> + */
> +
> +static ssize_t cciss_firmver_show(struct device *dev, char *buf)
> +{
> + ctlr_info_t *h = dev->driver_data;
> +return sprintf(buf,"%c%c%c%c\n", h->firm_ver[0], h->firm_ver[1],
> +h->firm_ver[2], h->firm_ver[3]);
> +}

I really wish we had a common firmver release attribut in the driver
core, as mentioned in the fc transport class thread.  Greg?

> +static ssize_t cciss_bus_id_show(struct device *dev, char *buf)
> +{
> +return sprintf(buf,"%s\n", dev->bus_id);
> +}

this one is already exposed in the name of the sysfs link,
see bus_add_device()

> + return sprintf(buf, "%x %x %x %x%x%x%x%x%x%x%x %x%x%x%x%x%x%x%x "
> + "%x %x %x%x%x%x%x%x\n",
> + p.bDeviceType, p.bRestricted, p.bInitiatorPortProtocol,
> + p.bRestricted2[0], 
> + p.bRestricted2[1], 
> + p.bRestricted2[2],
> + p.bRestricted2[3], 
> + p.bRestricted2[4], 
> + p.bRestricted2[5],
> + p.bRestricted2[6], 
> + p.bRestricted2[7],
> + p.bSASAddress[0],
> + p.bSASAddress[1],
> + p.bSASAddress[2],
> + p.bSASAddress[3],
> + p.bSASAddress[4],
> + p.bSASAddress[5],
> + p.bSASAddress[6],
> + p.bSASAddress[7],
> + p.bPhyIdentifier, p.bSignalClass,
> + p.bReserved[0],
> + p.bReserved[1],
> + p.bReserved[2],
> + p.bReserved[3],
> + p.bReserved[4],
> + p.bReserved[5]);
> +}

This belongs into a SAS/SATA phy transport class and should be split
into multiple attributes.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-18 Thread Christoph Hellwig
  /*
 + * sysfs stuff
 + * this should be moved to it's own file, maybe cciss_sysfs.h
 + */
 +
 +static ssize_t cciss_firmver_show(struct device *dev, char *buf)
 +{
 + ctlr_info_t *h = dev-driver_data;
 +return sprintf(buf,%c%c%c%c\n, h-firm_ver[0], h-firm_ver[1],
 +h-firm_ver[2], h-firm_ver[3]);
 +}

I really wish we had a common firmver release attribut in the driver
core, as mentioned in the fc transport class thread.  Greg?

 +static ssize_t cciss_bus_id_show(struct device *dev, char *buf)
 +{
 +return sprintf(buf,%s\n, dev-bus_id);
 +}

this one is already exposed in the name of the sysfs link,
see bus_add_device()

 + return sprintf(buf, %x %x %x %x%x%x%x%x%x%x%x %x%x%x%x%x%x%x%x 
 + %x %x %x%x%x%x%x%x\n,
 + p.bDeviceType, p.bRestricted, p.bInitiatorPortProtocol,
 + p.bRestricted2[0], 
 + p.bRestricted2[1], 
 + p.bRestricted2[2],
 + p.bRestricted2[3], 
 + p.bRestricted2[4], 
 + p.bRestricted2[5],
 + p.bRestricted2[6], 
 + p.bRestricted2[7],
 + p.bSASAddress[0],
 + p.bSASAddress[1],
 + p.bSASAddress[2],
 + p.bSASAddress[3],
 + p.bSASAddress[4],
 + p.bSASAddress[5],
 + p.bSASAddress[6],
 + p.bSASAddress[7],
 + p.bPhyIdentifier, p.bSignalClass,
 + p.bReserved[0],
 + p.bReserved[1],
 + p.bReserved[2],
 + p.bReserved[3],
 + p.bReserved[4],
 + p.bReserved[5]);
 +}

This belongs into a SAS/SATA phy transport class and should be split
into multiple attributes.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-18 Thread Greg KH
On Fri, Feb 18, 2005 at 07:46:28PM +, Christoph Hellwig wrote:
   /*
  + * sysfs stuff
  + * this should be moved to it's own file, maybe cciss_sysfs.h
  + */
  +
  +static ssize_t cciss_firmver_show(struct device *dev, char *buf)
  +{
  +   ctlr_info_t *h = dev-driver_data;
  +return sprintf(buf,%c%c%c%c\n, h-firm_ver[0], h-firm_ver[1],
  +h-firm_ver[2], h-firm_ver[3]);
  +}
 
 I really wish we had a common firmver release attribut in the driver
 core, as mentioned in the fc transport class thread.  Greg?

For a device?  It seems a huge overkill to add this attribute for
_every_ device in the system, when only a small minority can actually
use it.  Just put it as a default scsi or transport class attribute
instead.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cciss CSMI via sysfs for 2.6

2005-02-18 Thread James Bottomley
On Fri, 2005-02-18 at 12:05 -0800, Greg KH wrote:
 For a device?  It seems a huge overkill to add this attribute for
 _every_ device in the system, when only a small minority can actually
 use it.  Just put it as a default scsi or transport class attribute
 instead.

Actually, we might be able to do this as a simple attribute container
rather than a transport class, but I agree, it's not a generic property
of every device.

James


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


cciss CSMI via sysfs for 2.6

2005-02-16 Thread mike . miller
I am sending the following patch for some constructive critisms :).
This is a small part of what the CSMI Ioctls were supposed to do. I am
looking for feedback on this implementation. It is not complete, and I 
doubt anyone has hardware to test it with.
The firmware and bus_id files are only for my reference now. The part
I am interested is the get_phy_info.
For information on CSMI pls see: www.t11.org/ftp/t11/pub/sm/hba/04-468v0.pdf
Let the flames begin.

mikem

---
 drivers/block/cciss.c   |  163 +
 drivers/block/cciss_cmd.h   |3
 drivers/block/cciss_scsi.c  |2
 include/linux/cciss_ioctl.h |  189 +++-
 4 files changed, 352 insertions(+), 5 deletions(-)

diff -burNp lx2611.orig/drivers/block/cciss.c lx2611/drivers/block/cciss.c
--- lx2611.orig/drivers/block/cciss.c   2005-01-26 14:21:21.0 -0600
+++ lx2611/drivers/block/cciss.c2005-02-15 12:31:27.0 -0600
@@ -46,12 +46,12 @@
 #include 
 
 #define CCISS_DRIVER_VERSION(maj,min,submin) ((maj<<16)|(min<<8)|(submin))
-#define DRIVER_NAME "HP CISS Driver (v 2.6.4)"
+#define DRIVER_NAME "HP CISS Driver (v 2.6.4-99)"
 #define DRIVER_VERSION CCISS_DRIVER_VERSION(2,6,4)
 
 /* Embedded module documentation macros - see modules.h */
 MODULE_AUTHOR("Hewlett-Packard Company");
-MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 2.6.4");
+MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 2.6.4-99");
 MODULE_SUPPORTED_DEVICE("HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400"
" SA6i P600");
 MODULE_LICENSE("GPL");
@@ -138,6 +138,8 @@ static int sendcmd( __u8 cmd, int ctlr, 
unsigned int use_unit_num, unsigned int log_unit, __u8 page_code,
unsigned char *scsi3addr, int cmd_type);
 
+static int sas_error_check(__u8 phyId, __u8 portId, __u8 conn_rate);
+
 #ifdef CONFIG_PROC_FS
 static int cciss_proc_get_info(char *buffer, char **start, off_t offset, 
int length, int *eof, void *data);
@@ -1076,6 +1078,158 @@ cleanup1:
 }
 
 /*
+ * sysfs stuff
+ * this should be moved to it's own file, maybe cciss_sysfs.h
+ */
+
+static ssize_t cciss_firmver_show(struct device *dev, char *buf)
+{
+   ctlr_info_t *h = dev->driver_data;
+return sprintf(buf,"%c%c%c%c\n", h->firm_ver[0], h->firm_ver[1],
+h->firm_ver[2], h->firm_ver[3]);
+}
+
+static ssize_t cciss_bus_id_show(struct device *dev, char *buf)
+{
+return sprintf(buf,"%s\n", dev->bus_id);
+}
+
+static ssize_t cciss_phyinfo_show(struct device *dev, char *buf)
+{
+   ctlr_info_t *h = dev->driver_data;
+   unsigned long flags;
+   CommandList_struct *c;
+   CSMI_SAS_PHY_INFO_BUFFER iocommand;
+   CSMI_SAS_IDENTIFY p;
+   u64bit temp64;
+   DECLARE_COMPLETION(wait);
+
+   printk(KERN_WARNING "cciss: into cciss_phyinfo_show\n");
+   memset(, 0, sizeof(CSMI_SAS_PHY_INFO_BUFFER));
+   memset(, 0, sizeof(CSMI_SAS_IDENTIFY));
+
+   /* allocate and fill in the command */
+   if ((c = cmd_alloc(h, 0)) == NULL)
+   return -ENOMEM;
+
+   iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
+   c->cmd_type = CMD_IOCTL_PEND;
+   c->Header.ReplyQueue = 0;
+   
+   //Do we send the whole buffer?
+   if (iocommand.IoctlHeader.Length > 0){
+   c->Header.SGList = 1;
+   c->Header.SGTotal = 1;
+   } else {
+   c->Header.SGList = 0;
+   c->Header.SGTotal = 0;
+   }
+
+   //send the command to the controller
+   c->Header.LUN.LogDev.VolId = 0;
+   c->Header.LUN.LogDev.Mode = 0;
+   
+   c->Header.Tag.lower = c->busaddr;
+
+   c->Request.Type.Type = TYPE_CMD;
+   c->Request.Type.Attribute = ATTR_SIMPLE;
+
+   c->Request.Type.Direction = XFER_BIDIRECTIONAL;
+   c->Request.Timeout = iocommand.IoctlHeader.Timeout; // Looks like CSMI 
uses 60 secs by default
+   c->Request.CDB[0] = 0x27;  // CSMI Pass-Thru Bidirectional opcode
+   c->Request.CDB[1] = 0x00;
+   c->Request.CDB[2] = 0xcc; // Bytes 2-5 are 0xCC770014 to match with
+   c->Request.CDB[3] = 0x77; // the CC_CSMI_SAS_GET_PHY_INFO value
+   c->Request.CDB[4] = 0x00;
+   c->Request.CDB[5] = 0x14;
+   c->Request.CDB[6] = BMIC_CSMI_PASSTHRU;
+   c->Request.CDB[7] = (iocommand.IoctlHeader.Length >> 8) & 0xff;
+   c->Request.CDB[8] = iocommand.IoctlHeader.Length & 0xff;
+   c->Request.CDBLen = 16;
+
+   temp64.val = pci_map_single( h->pdev, , 
+   iocommand.IoctlHeader.Length, PCI_DMA_BIDIRECTIONAL);
+   c->SG[0].Addr.lower = temp64.val32.lower;
+   c->SG[0].Addr.upper = temp64.val32.upper;
+   c->SG[0].Len = iocommand.IoctlHeader.Length;
+   c->SG[0].Ext = 0;
+   c->waiting = 
+
+   

cciss CSMI via sysfs for 2.6

2005-02-16 Thread mike . miller
I am sending the following patch for some constructive critisms :).
This is a small part of what the CSMI Ioctls were supposed to do. I am
looking for feedback on this implementation. It is not complete, and I 
doubt anyone has hardware to test it with.
The firmware and bus_id files are only for my reference now. The part
I am interested is the get_phy_info.
For information on CSMI pls see: www.t11.org/ftp/t11/pub/sm/hba/04-468v0.pdf
Let the flames begin.

mikem

---
 drivers/block/cciss.c   |  163 +
 drivers/block/cciss_cmd.h   |3
 drivers/block/cciss_scsi.c  |2
 include/linux/cciss_ioctl.h |  189 +++-
 4 files changed, 352 insertions(+), 5 deletions(-)

diff -burNp lx2611.orig/drivers/block/cciss.c lx2611/drivers/block/cciss.c
--- lx2611.orig/drivers/block/cciss.c   2005-01-26 14:21:21.0 -0600
+++ lx2611/drivers/block/cciss.c2005-02-15 12:31:27.0 -0600
@@ -46,12 +46,12 @@
 #include linux/completion.h
 
 #define CCISS_DRIVER_VERSION(maj,min,submin) ((maj16)|(min8)|(submin))
-#define DRIVER_NAME HP CISS Driver (v 2.6.4)
+#define DRIVER_NAME HP CISS Driver (v 2.6.4-99)
 #define DRIVER_VERSION CCISS_DRIVER_VERSION(2,6,4)
 
 /* Embedded module documentation macros - see modules.h */
 MODULE_AUTHOR(Hewlett-Packard Company);
-MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 2.6.4);
+MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 2.6.4-99);
 MODULE_SUPPORTED_DEVICE(HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400
 SA6i P600);
 MODULE_LICENSE(GPL);
@@ -138,6 +138,8 @@ static int sendcmd( __u8 cmd, int ctlr, 
unsigned int use_unit_num, unsigned int log_unit, __u8 page_code,
unsigned char *scsi3addr, int cmd_type);
 
+static int sas_error_check(__u8 phyId, __u8 portId, __u8 conn_rate);
+
 #ifdef CONFIG_PROC_FS
 static int cciss_proc_get_info(char *buffer, char **start, off_t offset, 
int length, int *eof, void *data);
@@ -1076,6 +1078,158 @@ cleanup1:
 }
 
 /*
+ * sysfs stuff
+ * this should be moved to it's own file, maybe cciss_sysfs.h
+ */
+
+static ssize_t cciss_firmver_show(struct device *dev, char *buf)
+{
+   ctlr_info_t *h = dev-driver_data;
+return sprintf(buf,%c%c%c%c\n, h-firm_ver[0], h-firm_ver[1],
+h-firm_ver[2], h-firm_ver[3]);
+}
+
+static ssize_t cciss_bus_id_show(struct device *dev, char *buf)
+{
+return sprintf(buf,%s\n, dev-bus_id);
+}
+
+static ssize_t cciss_phyinfo_show(struct device *dev, char *buf)
+{
+   ctlr_info_t *h = dev-driver_data;
+   unsigned long flags;
+   CommandList_struct *c;
+   CSMI_SAS_PHY_INFO_BUFFER iocommand;
+   CSMI_SAS_IDENTIFY p;
+   u64bit temp64;
+   DECLARE_COMPLETION(wait);
+
+   printk(KERN_WARNING cciss: into cciss_phyinfo_show\n);
+   memset(iocommand, 0, sizeof(CSMI_SAS_PHY_INFO_BUFFER));
+   memset(p, 0, sizeof(CSMI_SAS_IDENTIFY));
+
+   /* allocate and fill in the command */
+   if ((c = cmd_alloc(h, 0)) == NULL)
+   return -ENOMEM;
+
+   iocommand.IoctlHeader.Length = sizeof(CSMI_SAS_PHY_INFO_BUFFER);
+   c-cmd_type = CMD_IOCTL_PEND;
+   c-Header.ReplyQueue = 0;
+   
+   //Do we send the whole buffer?
+   if (iocommand.IoctlHeader.Length  0){
+   c-Header.SGList = 1;
+   c-Header.SGTotal = 1;
+   } else {
+   c-Header.SGList = 0;
+   c-Header.SGTotal = 0;
+   }
+
+   //send the command to the controller
+   c-Header.LUN.LogDev.VolId = 0;
+   c-Header.LUN.LogDev.Mode = 0;
+   
+   c-Header.Tag.lower = c-busaddr;
+
+   c-Request.Type.Type = TYPE_CMD;
+   c-Request.Type.Attribute = ATTR_SIMPLE;
+
+   c-Request.Type.Direction = XFER_BIDIRECTIONAL;
+   c-Request.Timeout = iocommand.IoctlHeader.Timeout; // Looks like CSMI 
uses 60 secs by default
+   c-Request.CDB[0] = 0x27;  // CSMI Pass-Thru Bidirectional opcode
+   c-Request.CDB[1] = 0x00;
+   c-Request.CDB[2] = 0xcc; // Bytes 2-5 are 0xCC770014 to match with
+   c-Request.CDB[3] = 0x77; // the CC_CSMI_SAS_GET_PHY_INFO value
+   c-Request.CDB[4] = 0x00;
+   c-Request.CDB[5] = 0x14;
+   c-Request.CDB[6] = BMIC_CSMI_PASSTHRU;
+   c-Request.CDB[7] = (iocommand.IoctlHeader.Length  8)  0xff;
+   c-Request.CDB[8] = iocommand.IoctlHeader.Length  0xff;
+   c-Request.CDBLen = 16;
+
+   temp64.val = pci_map_single( h-pdev, p, 
+   iocommand.IoctlHeader.Length, PCI_DMA_BIDIRECTIONAL);
+   c-SG[0].Addr.lower = temp64.val32.lower;
+   c-SG[0].Addr.upper = temp64.val32.upper;
+   c-SG[0].Len = iocommand.IoctlHeader.Length;
+   c-SG[0].Ext = 0;
+   c-waiting = wait;
+
+   spin_lock_irqsave(CCISS_LOCK(h-ctlr), flags);
+