Two functions in include/scsi/sas_ata.h don't have static inlines
leading to problems if they're built in:
On Thu, 2008-04-03 at 14:06 +0200, Toralf Förster wrote:
> drivers/scsi/mvsas.o: In function `sas_ata_init_host_and_port':
> mvsas.c:(.text+0x0): multiple definition of `sas_ata_init_host_and_port'
> drivers/scsi/libsas/built-in.o:(.text+0x37f4): first defined here
> drivers/scsi/mvsas.o: In function `sas_ata_task_abort':
> mvsas.c:(.text+0x7): multiple definition of `sas_ata_task_abort'
> drivers/scsi/libsas/built-in.o:(.text+0x37fb): first defined here
> make[2]: *** [drivers/scsi/built-in.o] Error 1
> make[1]: *** [drivers/scsi] Error 2
> make: *** [drivers] Error 2
Add the correct static inline modifiers.
Tested-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Not everyone wants libsas automatically to pull in libata. This patch
makes the behaviour configurable, so you can build libsas with or
without ATA support.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
ATA devices need special handling for sas_task_abort. If the ATA command
came from SCSI, then we merely need to tell SCSI to abort the scsi_cmnd.
However, internal commands require a bit more work--we need to fill the qc
with the appropriate error status and complete the command, and eventually
post_internal will issue the actual ABORT TASK.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This is a respin of my earlier patch that migrates the ATA support code
into a separate file. For now, the controversial linking bits have
been removed per James Bottomley's request for a patch that contains
only the migration diffs, which means that libsas continues to require
libata. I intend to address that problem in a separate patch.
This patch is against the aic94xx-sas-2.6 git tree, and it has been
sanity tested on my x206m with Seagate SATA and SAS disks without
uncovering any new problems.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
