SPI transport class and generic Domain Validation for fusion
Subsystems (2)
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
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?
Quoted 1 line · Christoph Hellwig
- there's a stale
printk("HERE2\n"); inmptscsih_writeSDP1.
Yes, sorry, I'll remove it
Quoted 1 line
- the #undef
MPTSCSIH_ENABLE_DOMAIN_VALIDATIONis 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_allocisn'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