[PATCH] scsi_transport_spi: Export host width and HBA id

[PATCH] scsi_transport_spi: Export host width and HBA id

[Hannes Reinecke]

Currently it's impossible to find out if the host supports
wide SCSI unless you're committed to trawl through syslog.
And it's near impossible to find the actual HBA id, which
is settable for some SCSI HBAs (like aic7xxx).
So export them via sysfs.

Signed-off-by: Hannes Reinecke <hare@suse.de>

diff --git a/drivers/scsi/scsi_transport_spi.c b/drivers/scsi/scsi_transport_spi.c
index 8a172d4..f5a3a68 100644
--- a/drivers/scsi/scsi_transport_spi.c
+++ b/drivers/scsi/scsi_transport_spi.c
@@ -597,6 +597,28 @@ static DEVICE_ATTR(signalling, S_IRUGO,
 		   show_spi_host_signalling,
 		   store_spi_host_signalling);
 
+static ssize_t show_spi_host_width(struct device *cdev,
+				      struct device_attribute *attr,
+				      char *buf)
+{
+	struct Scsi_Host *shost = transport_class_to_shost(cdev);
+
+	return sprintf(buf, "%s\n", shost->max_id == 16 ? "wide" : "narrow");
+}
+static DEVICE_ATTR(width, S_IRUGO,
+		   show_spi_host_width, NULL);
+
+static ssize_t show_spi_host_hba_id(struct device *cdev,
+				    struct device_attribute *attr,
+				    char *buf)
+{
+	struct Scsi_Host *shost = transport_class_to_shost(cdev);
+
+	return sprintf(buf, "%d\n", shost->this_id);
+}
+static DEVICE_ATTR(hba_id, S_IRUGO,
+		   show_spi_host_hba_id, NULL);
+
 #define DV_SET(x, y)			\
 	if(i->f->set_##x)		\
 		i->f->set_##x(sdev->sdev_target, y)
@@ -1380,6 +1402,8 @@ static DECLARE_ANON_TRANSPORT_CLASS(spi_device_class,
 
 static struct attribute *host_attributes[] = {
 	&dev_attr_signalling.attr,
+	&dev_attr_width.attr,
+	&dev_attr_hba_id.attr,
 	NULL
 };
 

Re: [PATCH] scsi_transport_spi: Export host width and HBA id

[James Bottomley]

On Wed, 2011-06-01 at 15:18 +0200, Hannes Reinecke wrote:
> Currently it's impossible to find out if the host supports
> wide SCSI unless you're committed to trawl through syslog.
> And it's near impossible to find the actual HBA id, which
> is settable for some SCSI HBAs (like aic7xxx).
> So export them via sysfs.

Um, that's what the the 

/sys/class/spi_transport/target<x:y:x>/max_width

parameter gives you, isn't it?

max_width tells you if the HBA/device combination supports wide; width
tells you if the device is using it.

James

Re: [PATCH] scsi_transport_spi: Export host width and HBA id

[Hannes Reinecke]

On 06/01/2011 04:56 PM, James Bottomley wrote:
> On Wed, 2011-06-01 at 15:18 +0200, Hannes Reinecke wrote:
>> Currently it's impossible to find out if the host supports
>> wide SCSI unless you're committed to trawl through syslog.
>> And it's near impossible to find the actual HBA id, which
>> is settable for some SCSI HBAs (like aic7xxx).
>> So export them via sysfs.
>
> Um, that's what the the
>
> /sys/class/spi_transport/target<x:y:x>/max_width
>
> parameter gives you, isn't it?
>
> max_width tells you if the HBA/device combination supports wide; width
> tells you if the device is using it.
>
Not quite. You'll only have that parameter if there is a target 
attached to the HBA.
If there is none you still wouldn't know how far you should be 
scanning as there won't be any indicator in sysfs.

In this case that's an ESX server emulating an sym53c8xx HBA.
And disks attached to it on the fly.
If you start up with no disks attached and attach a new disc
to eg target ID 12 you're stuck.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi_transport_spi: Export host width and HBA id

[Douglas Gilbert]

On 11-06-01 11:00 AM, Hannes Reinecke wrote:
> On 06/01/2011 04:56 PM, James Bottomley wrote:
>> On Wed, 2011-06-01 at 15:18 +0200, Hannes Reinecke wrote:
>>> Currently it's impossible to find out if the host supports
>>> wide SCSI unless you're committed to trawl through syslog.
>>> And it's near impossible to find the actual HBA id, which
>>> is settable for some SCSI HBAs (like aic7xxx).
>>> So export them via sysfs.
>>
>> Um, that's what the the
>>
>> /sys/class/spi_transport/target<x:y:x>/max_width
>>
>> parameter gives you, isn't it?
>>
>> max_width tells you if the HBA/device combination supports wide; width
>> tells you if the device is using it.
>>
> Not quite. You'll only have that parameter if there is a target attached to the
> HBA.
> If there is none you still wouldn't know how far you should be scanning as there
> won't be any indicator in sysfs.
>
> In this case that's an ESX server emulating an sym53c8xx HBA.
> And disks attached to it on the fly.
> If you start up with no disks attached and attach a new disc
> to eg target ID 12 you're stuck.

It is about time that VMware emulated SAS rather than SPI for
virtual storage. Then if something changes, ESX can emulate
a SAS Broadcast(Change) and then smarter SAS HBA drivers will
run their discover process and find the changes.

Doug Gilbert

Re: [PATCH] scsi_transport_spi: Export host width and HBA id

[Hannes Reinecke]

On 06/01/2011 05:15 PM, Douglas Gilbert wrote:
> On 11-06-01 11:00 AM, Hannes Reinecke wrote:
>> On 06/01/2011 04:56 PM, James Bottomley wrote:
>>> On Wed, 2011-06-01 at 15:18 +0200, Hannes Reinecke wrote:
>>>> Currently it's impossible to find out if the host supports
>>>> wide SCSI unless you're committed to trawl through syslog.
>>>> And it's near impossible to find the actual HBA id, which
>>>> is settable for some SCSI HBAs (like aic7xxx).
>>>> So export them via sysfs.
>>>
>>> Um, that's what the the
>>>
>>> /sys/class/spi_transport/target<x:y:x>/max_width
>>>
>>> parameter gives you, isn't it?
>>>
>>> max_width tells you if the HBA/device combination supports wide;
>>> width
>>> tells you if the device is using it.
>>>
>> Not quite. You'll only have that parameter if there is a target
>> attached to the
>> HBA.
>> If there is none you still wouldn't know how far you should be
>> scanning as there
>> won't be any indicator in sysfs.
>>
>> In this case that's an ESX server emulating an sym53c8xx HBA.
>> And disks attached to it on the fly.
>> If you start up with no disks attached and attach a new disc
>> to eg target ID 12 you're stuck.
>
> It is about time that VMware emulated SAS rather than SPI for
> virtual storage. Then if something changes, ESX can emulate
> a SAS Broadcast(Change) and then smarter SAS HBA drivers will
> run their discover process and find the changes.
>
Hey, don't tell me.
I'm fighting for years to get my megaraid SAS emulation into Qemu.
And it took me about the same time to get VMWare to buy into the 
idea of supporting VPD page 0x83.

So I won't hold my breath there.
And, btw, we'd need the hba_id anyway if we ever want to calculate 
transport IDs on SCSI parallel devices :-).

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html