Re: cciss CSMI via sysfs for 2.6
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
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
> -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
-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
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
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
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
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
> /* > + * 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
/* + * 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
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
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
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
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); +