Jeff Garzik wrote:
> Brian King wrote:
>> In preparation for SAS attached SATA devices, quit using
>> the max_cmd_len in the scsi_host struct.
>>
>> Signed-off-by: Brian King <brking@xxxxxxxxxx>
>
> I see this as a bit of a hack. In general, its best to inform upper
> layers of known limits as soon as possible. For the non-SAS case, for
> that point of view, this patch is a regression.
>
> Jeff
Is the patch below ok? Then I'll add the cdb_len checking in the SAS
unique queuecommand entry point. This would still be a hack, but it wouldn't
be a regression for the non-SAS case. The other option I see would be to
add a max_cmd_len to the scsi_device which scsi core would check.
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
In preparation for SAS attached SATA devices, which will
not have a libata scsi_host, only setup host->max_cmd_len
if ap->host exists.
Signed-off-by: Brian King <brking@xxxxxxxxxx>
---
libata-dev-bjking1/drivers/scsi/libata-core.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff -puN drivers/scsi/libata-core.c~libata_cdb_len drivers/scsi/libata-core.c
--- libata-dev/drivers/scsi/libata-core.c~libata_cdb_len 2006-03-22 11:25:25.000000000 -0600
+++ libata-dev-bjking1/drivers/scsi/libata-core.c 2006-03-22 11:25:25.000000000 -0600
@@ -1301,11 +1301,13 @@ static int ata_dev_configure(struct ata_
ap->id, dev->devno, ata_mode_string(xfer_mask));
}
- ap->host->max_cmd_len = 0;
- for (i = 0; i < ATA_MAX_DEVICES; i++)
- ap->host->max_cmd_len = max_t(unsigned int,
- ap->host->max_cmd_len,
- ap->device[i].cdb_len);
+ if (ap->host) {
+ ap->host->max_cmd_len = 0;
+ for (i = 0; i < ATA_MAX_DEVICES; i++)
+ ap->host->max_cmd_len = max_t(unsigned int,
+ ap->host->max_cmd_len,
+ ap->device[i].cdb_len);
+ }
/* limit bridge transfers to udma5, 200 sectors */
if (ata_dev_knobble(ap, dev)) {
_
