Brian King wrote:
The following patch enhances libata to allow SAS device drivers
to utilize libata to talk to SATA devices. It introduces some
new APIs which allow libata to be used without allocating a
virtual scsi host.
New APIs:
ata_sas_port_alloc - Allocate an ata_port
ata_sas_port_init - Initialize an ata_port (probe device, etc)
ata_sas_port_destroy - Free an ata_port allocated by ata_sas_port_alloc
ata_sas_slave_configure - configure scsi device
ata_sas_queuecmd - queue a scsi command, similar to ata_scsi_queuecomand
These new APIs can be used either directly by a SAS LLDD or could be used
by the SAS transport class.
Possible usage for a SAS LLDD would be:
scsi_scan_host
target_alloc
ata_sas_port_alloc
slave_alloc
ata_sas_port_init
slave_configure
ata_sas_slave_configure
Commands received by the LLDD for SATA devices would call ata_sas_queuecmd.
Device teardown would occur with:
slave_destroy
port_disable
target_destroy
ata_sas_port_destroy
Signed-off-by: Brian King <brking@xxxxxxxxxx>
Overall, I am very wary of this patch. Not for patch content reasons,
but because we don't yet know how aic94xx or Broadcom SAS (both
"software stack" SAS adapters) will interface to libata.
So, this is a reluctant ACK, because I fear that this may become an
ipr-only API. I'll ACK it, because we won't have any other SAS support
for a while... but this API must be revisited with more SAS+SATA
controllers are supported.
In particular, we may need to make this API more generic: remove all
mention of "SAS", and simply create a libata API that supports
situations where ata_host_set is not the toplevel object.
Jeff
-
: 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
