All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>
Cc: Andries Brouwer <aebr@win.tue.nl>, linux-scsi@vger.kernel.org
Subject: Re: use_10_for_ms revisited?
Date: Sun, 29 Jun 2003 14:17:41 -0400	[thread overview]
Message-ID: <3EFF2D45.1040203@pobox.com> (raw)
In-Reply-To: <20030629110205.A4728@one-eyed-alien.net>

Matthew Dharm wrote:
> Right now, we can handle this case with a slave_configure() function that
> sets use_10_for_ms and use_10_for_rw, like usb-storage does now.  The
> heuristic code in usb-storage is on the way out, once sr.c is converted (in
> progress).
> 
> Devices easily identified, heuristics gone, repeated code very minimal (2
> lines) -- sounds like a winner to me.  Actually, I have a feeling that any
> algorithm to try to determine MMC or not (complete with it's own heuristic
> to handle strange devices) will be much longer than those repeated 2 lines.

No argument, I'm sold :)  Sounds like a good plan.

That still doesn't address the issue use_10_for_ms being _too_ 
fine-grained, though:  mode sense is but one part of the larger picture.

We will still have duplicated ATAPI (and other?) logic in USB storage, 
ide-scsi, my driver, and elsewhere for items which are common to MMC. 
For many cases, it is silly to set a whole list of use_10_for_foo 
variables, when they are all unconditionally set to 1 when MMC is 
detected (->slave_configure).

So, a concrete suggestion would be:

Create 'mmc' bit for each scsi_device, set at slave_configure time. 
use_10_for_foo and other code can derive values from this.  i.e. provide 
enough information that can automatically set all those use_10_for_foo 
variables.

	Jeff



  reply	other threads:[~2003-06-29 18:03 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-29  6:30 use_10_for_ms revisited? Jeff Garzik
2003-06-29  6:38 ` Matthew Dharm
2003-06-29  6:47   ` Jeff Garzik
2003-06-29  6:54     ` Matthew Dharm
2003-06-29  7:27       ` Jeff Garzik
2003-06-29 10:31         ` Alan Cox
2003-06-29 10:22 ` Andries Brouwer
2003-06-29 16:33   ` Jeff Garzik
2003-06-29 17:36     ` Andries Brouwer
2003-06-29 17:58       ` Jeff Garzik
2003-06-29 18:02         ` Matthew Dharm
2003-06-29 18:17           ` Jeff Garzik [this message]
2003-06-29 18:35             ` Matthew Dharm
2003-06-29 18:36             ` James Bottomley
2003-06-29 19:07               ` Jeff Garzik
2003-06-30  0:23                 ` Matthew Dharm
2003-06-30  3:24                   ` Jeff Garzik
2003-06-29 18:25         ` Andries Brouwer
2003-06-29 18:32           ` Jeff Garzik

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=3EFF2D45.1040203@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=aebr@win.tue.nl \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mdharm-scsi@one-eyed-alien.net \
    /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.