All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: brking@us.ibm.com
Cc: Christoph Hellwig <hch@infradead.org>,
	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: Tue, 04 Apr 2006 05:25:07 -0400	[thread overview]
Message-ID: <44323B73.9070903@pobox.com> (raw)
In-Reply-To: <442C09A8.50200@us.ibm.com>

Brian King wrote:
> Jeff Garzik wrote:
>> James Bottomley wrote:
>>> This really doesn't look correct.  What you want is a sata transport
>>> class with a max command length in the host device.
>> Christoph Hellwig wrote:
>>> 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 practice, CDB length may be limited by both the host and the device. 
>>   This applies to ATAPI, and some USB storage too IIRC.  For ATAPI, you 
>> read the CDB length from the device's IDENTIFY PACKET DEVICE info page.
> 
> So the question remains, do we need to police the CDB length on a per device
> basis, or is a per host basis ok? Will we have ATAPI devices falling on the
> floor if they get sent too large of a cdb?

It _must_ be limited by both device and host.  If you have a device that 
supports 16-byte CDBs and a host controller which only supports 12-byte 
CDBs, clearly the limit is 12, due to host.  However, a reversed 
situation (limited by device) is equally plausible/possible.

	Jeff




  parent reply	other threads:[~2006-04-04  9:25 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
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 [this message]
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=44323B73.9070903@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=brking@us.ibm.com \
    --cc=hch@infradead.org \
    --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.