From: Jeff Garzik <jgarzik@pobox.com>
To: Mark Lord <liml@rtr.ca>
Cc: IDE/ATA development list <linux-ide@vger.kernel.org>,
Tejun Heo <htejun@gmail.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH 02/02] sata_mv: workaround for multi_count errata sata24
Date: Mon, 13 Apr 2009 13:25:28 -0400 [thread overview]
Message-ID: <49E37588.10506@pobox.com> (raw)
In-Reply-To: <49E35BF8.1070402@rtr.ca>
Mark Lord wrote:
> Someday I'll fix that, if you guys don't beat me to it.
> I suppose we just need to issue the SET_MULTIPLE command from
> the drive revalidation code.
IMO this would be a good idea to do, across many ATA devices.
IIRC there is at least one other chip that snoops the set-multiple
command, and sets internal chip parameters.
Thus, like SET FEATURES - XFER MODE, it seems wise to unconditionally
issue SET MULTIPLE for ATA devices, under the logic that it
more-thoroughly initializes the controller and device, ensuring we are
at a known state at all times.
Wanna do a patch? :) Although not the greatest code location, I'm
guessing ata_dev_read_id() would probably be the place... Ideally we
would have a post-IDENTIFY reset sequence function.
Jeff
next prev parent reply other threads:[~2009-04-13 17:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-13 15:27 [PATCH 01/02] sata_mv: tidy up qc->tf usage in qc_prep() functions Mark Lord
2009-04-13 15:29 ` [PATCH 02/02] sata_mv: workaround for multi_count errata sata24 Mark Lord
2009-04-13 15:36 ` Mark Lord
2009-04-13 17:25 ` Jeff Garzik [this message]
2009-04-13 17:36 ` Mark Lord
2009-04-13 15:40 ` Alan Cox
2009-04-13 15:44 ` Mark Lord
2009-04-13 15:46 ` Mark Lord
2009-04-17 23:03 ` Jeff Garzik
2009-04-18 1:11 ` Mark Lord
2009-04-17 22:59 ` libata git repo guide (was Re: [PATCH 01/02] sata_mv: tidy up qc->tf usage in qc_prep() functions) 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=49E37588.10506@pobox.com \
--to=jgarzik@pobox.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=htejun@gmail.com \
--cc=liml@rtr.ca \
--cc=linux-ide@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.