linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian King <brking@us.ibm.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: jgarzik@pobox.com, James.Bottomley@steeleye.com,
	linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/2] scsi: Add scsi_device max_cmd_len
Date: Wed, 29 Mar 2006 08:15:24 -0600	[thread overview]
Message-ID: <442A967C.8070805@us.ibm.com> (raw)
In-Reply-To: <20060329091104.GB7940@infradead.org>

Christoph Hellwig wrote:
> On Tue, Mar 28, 2006 at 04:17:18PM -0600, Brian King wrote:
>> Add a max_cmd_len field to the scsi_device struct
>> to allow for per device limits of allowable command
>> lengths. This will be used by libata, which is currently
>> using the max_cmd_len field in the scsi_host struct,
>> which doesn't work for attaching libata controlled
>> SATA devices to SAS HBAs.
> 
> this sounds wrong to me.  cdb length is a limitation of the host (driver).
> A target will reject unknown commands, no matter what length they have.

In that case, this patch can probably be dropped. Currently libata has
some code that looks at all the devices attached to a port and sets
the scsi_host's max_cmd_len to the max of these values. I was assuming
this was due to some misbehaving ATA/ATAPI devices out there.

Jeff, care to comment on this one?


-- 
Brian King
eServer Storage I/O
IBM Linux Technology Center

  reply	other threads:[~2006-03-29 14:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-28 22:17 [PATCH 1/2] scsi: Add scsi_device max_cmd_len Brian King
2006-03-28 22:29 ` James Bottomley
2006-03-28 22:38   ` Brian King
2006-03-28 22:49     ` James Bottomley
2006-03-29  0:03       ` Brian King
2006-03-29  0:12         ` James Bottomley
2006-03-29  4:42           ` Brian King
2006-03-29 23:22   ` Jeff Garzik
2006-03-29  9:11 ` Christoph Hellwig
2006-03-29 14:15   ` Brian King [this message]
2006-03-29 15:05     ` Christoph Hellwig
2006-03-29 23:19   ` Jeff Garzik
2006-03-30 16:39     ` Brian King
2006-03-30 16:42       ` Brian King
2006-04-04  9:25       ` Jeff Garzik
2006-04-07 13:36         ` Brian King
2006-04-01 10:31     ` Stefan Richter

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=442A967C.8070805@us.ibm.com \
    --to=brking@us.ibm.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=hch@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).