Skip to contentSkip to conversation

SPI transport class and generic Domain Validation for fusion

PATCH In review James Bottomley 2 participants 3 messages Aug 8, 2005 – Aug 9, 2005

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 SPI transport class and generic Domain Validation for fusion

Eric,

This attached patch should do DV on both physical devices and the underlying devices of fusion IM assemblies (providing you apply it on top of the prior underlying device exposure patch), which, I believe was your only outstanding concern with the last generic DV patch.

There is one slight unsightly piece: the IM device still attaches to the transport class however all the parameters it shows actually belong to the underlying device at that id ... I could do with finding a way of persuading the SPI transport class not to attach to RAID devices.

Since this addresses all of LSI's prior concerns, may I now apply it?

James

---

 Kconfig    |    1 
 mptscsih.c | 2000 -------------------------------------------------------------
 mptscsih.h |    2 
 mptspi.c   |  434 ++++++++++++-
 4 files changed, 404 insertions(+), 2033 deletions(-)

---

drivers/message/fusion/Kconfig +1 -0
@@ -9,6 +9,7 @@ config FUSION_SPI
 	tristate "Fusion MPT ScsiHost drivers for SPI"
 	depends on PCI && SCSI
 	select FUSION
+	select SCSI_SPI_ATTRS
 	---help---
 	  SCSI HOST support for a parallel SCSI host adapters.
 
drivers/message/fusion/mptscsih.c +5 -1995

2,100 lines not on this page · raw message

drivers/message/fusion/mptscsih.h +1 -1
@@ -67,7 +67,7 @@
  * capabilities.
  */
 
-#define MPTSCSIH_ENABLE_DOMAIN_VALIDATION
+#undef MPTSCSIH_ENABLE_DOMAIN_VALIDATION
 
 
 /* SCSI driver setup structure. Settings can be overridden
drivers/message/fusion/mptspi.c +397 -37

493 lines not on this page · raw message

#1 lore raw
Quoted 7 lines · James Bottomley

Eric,

This attached patch should do DV on both physical devices and the underlying devices of fusion IM assemblies (providing you apply it on top of the prior underlying device exposure patch), which, I believe was your only outstanding concern with the last generic DV patch.

Quoted 6 lines

There is one slight unsightly piece: the IM device still attaches to the transport class however all the parameters it shows actually belong to the underlying device at that id ... I could do with finding a way of persuading the SPI transport class not to attach to RAID devices.

Since this addresses all of LSI's prior concerns, may I now apply it?

- there's a stale printk("HERE2\n"); in mptscsih_writeSDP1.
- the #undef MPTSCSIH_ENABLE_DOMAIN_VALIDATION is probably not needed
- the hd == NULL check in mptspi_target_alloc isn't needed
- should the driver print a warning about too old firmware when we can't access page 0?

#2 lore raw
Quoted 1 line · Christoph Hellwig

- there's a stale printk("HERE2\n"); in mptscsih_writeSDP1.

Yes, sorry, I'll remove it

Quoted 1 line

- the #undef MPTSCSIH_ENABLE_DOMAIN_VALIDATION is probably not needed

There's actually an awful lot of other cruft besides this that can come out of the driver (inquiry snooping leaps to mind).

Quoted 1 line

- the hd == NULL check in mptspi_target_alloc isn't needed

Yes, OK.

Quoted 2 lines

- should the driver print a warning about too old firmware when we can't access page 0?

I'll defer to LSI on this one. We can't attach the transport classes in this case ... which is what I do. But on the other hand, LSI didn't do DV in this case either, so the current situation is identical to what we had previously.

But yes, this type of situation seems quite common. The fusion card HP sent me initially had this problem, and it does seem to be possible to upgrade all the problem cards, so reporting the issue and recommending an upgrade seems to be a good approach.

James