On Thursday, April 13, 2006 4:28 PM, James Bottomley wrote: > Erm, there's something else wrong here, then. The sas transport class > shouldn't be attaching to the raid volumes (only the raid components) > since a RAID volume is not a SAS device. I think when this > came up ages > ago, I said the SAS class should do a deny_binding() callback like the > SPI transport class does for the mptfusion driver ... > ???, the mptsas driver is not attaching the raid volumes to sas transport. Only the raid components are attached. What the fusion driver is doing is placing the raid volumes on virtual channel beyond the last known channel for the rphys. Basically the reverse of what you did for fusion when you added the spi transport support. What this means is the raid volumes are located at ioc->num_ports. Then we use scsi_add_device and scsi_remove_device to handle adding and removing the raid volumes attaching on this virtual channel. From mptsas_slave_alloc(), we bypass the logic for rphy handling near the comment that says "RAID Volumes placed beyond the last expected port". I beleive all this is correct, okay'd by you and Christoph several months ago. However the problem came when you added the mptsas_slave_configure. We need to add the same check that bypasses calling the sas transport layer API for anything sitting this virtual channel reserved for RAID. Eric - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
