From: Brian King <brking@us.ibm.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 06/15] libata: Stop using host->max_cmd_len
Date: Wed, 22 Mar 2006 17:29:16 -0600 [thread overview]
Message-ID: <4421DDCC.3@us.ibm.com> (raw)
In-Reply-To: <4420B05B.6090702@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
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@us.ibm.com>
>
> 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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: libata_cdb_len.patch --]
[-- Type: text/x-patch; name="libata_cdb_len.patch", Size: 1187 bytes --]
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@us.ibm.com>
---
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)) {
_
prev parent reply other threads:[~2006-03-22 23:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 23:04 [PATCH 06/15] libata: Stop using host->max_cmd_len Brian King
2006-03-22 2:03 ` Jeff Garzik
2006-03-22 23:29 ` Brian King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4421DDCC.3@us.ibm.com \
--to=brking@us.ibm.com \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.