On Thu, Apr 13, 2006 at 05:28:14PM -0500, James Bottomley wrote: > On Thu, 2006-04-13 at 16:08 -0600, Moore, Eric wrote: > > This issue was created in due to recent scsi_transport_sas change, > > when sas_read_port_mode_page was added into the mptsas drivers > > slave_config entry point. > > > > This new API expects that all sdev's to be assocated to an rphy, however > > that is not the case for logical volumes, as they are created using > > scsi_add_device, instead of sas_rphy_add(). > > 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 ... mptsas_slave_configure isn't anything sas transport class specificy, it's the ->slave_configure method in the host template for all fusion SAS controllers. Independent of possibly needing a ->deny_binding this is the right thing to do here. - : 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
