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
next prev parent 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.