From: Tejun Heo <tj@kernel.org>
To: Mark Lord <liml@rtr.ca>
Cc: Jeff Garzik <jgarzik@pobox.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: [PATCH] libata-core More robust parsing for multi_count(v5)
Date: Fri, 20 Mar 2009 08:33:22 +0900 [thread overview]
Message-ID: <49C2D642.90706@kernel.org> (raw)
In-Reply-To: <49C281A5.5080404@rtr.ca>
Hello, Mark.
Mark Lord wrote:
> Make libata more robust when parsing the multi_count
> field from a drive's identify data. This prevents us from
> attempting to use dubious multi_count values ad infinitum.
>
> Reset dev->multi_count to zero and reprobe it each time
> through this routine, as it can change on device reset.
>
> Also ensure that the reported "maximum" value is valid
> and is a power of two, and that the reported "count" value
> is valid and also a power of two. And that the "count"
> value is not greater than the "maximum" value.
>
> Signed-off-by: Mark Lord <mlord@pobox.com>
Acked-by: Tejun Heo <tj@kernel.org>
The patch looks safe to me although requiring power_of_2 on max seems
a bit too strict. For configuration, ata_dev_configure() is the right
place. I think the following should work.
* add dev->multi_limit which is initialized to -1 on ata_dev_init().
* during ata_dev_configure() if multi_limit < 0, set it to device max.
* set dev->multi to rounddown_pow_of_two(multi_limit) and issue
SET_MULTI.
On EH side, ata_eh_speed_down() is the place to handle it. It can
probably piggy back on ATA_EH_SPDN_SPEED_DOWN block. All it has to do
is reducing dev->multi_limit. dev_config will run later and apply it.
I'm not sure how the speed down strategy should exactly be tho. It is
distinguisible from regular transfer errors?
Thanks.
--
tejun
next prev parent reply other threads:[~2009-03-19 23:33 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 14:26 [PATCH] libata-core Use more robust parsing for multi_count Mark Lord
2009-03-18 14:32 ` Alan Cox
2009-03-18 15:06 ` Mark Lord
2009-03-18 15:13 ` Mark Lord
2009-03-18 17:09 ` Alan Cox
2009-03-18 15:58 ` Mark Lord
2009-03-18 16:18 ` [PATCH] libata-core More robust parsing for multi_count(v3) Mark Lord
2009-03-18 16:24 ` Mark Lord
2009-03-19 0:23 ` Tejun Heo
2009-03-19 0:25 ` Tejun Heo
2009-03-19 17:30 ` [PATCH] libata-core More robust parsing for multi_count(v4) Mark Lord
2009-03-19 17:32 ` [PATCH] libata-core More robust parsing for multi_count(v5) Mark Lord
2009-03-19 23:33 ` Tejun Heo [this message]
2009-03-20 3:37 ` Mark Lord
2009-03-20 13:13 ` Mark Lord
2009-03-20 13:14 ` Mark Lord
2009-03-20 14:07 ` Alan Cox
2009-03-20 15:36 ` Mark Lord
2009-03-20 23:14 ` Tejun Heo
2009-03-21 0:54 ` Jeff Garzik
2009-03-21 2:17 ` Tejun Heo
2009-03-21 13:54 ` Mark Lord
2009-03-21 14:02 ` Alan Cox
2009-03-21 14:59 ` Mark Lord
2009-03-20 13:38 ` Alan Cox
2009-04-12 15:10 ` Mark Lord
2009-04-12 15:18 ` Alan Cox
2009-04-12 15:31 ` Jeff Garzik
2009-03-25 2:40 ` 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=49C2D642.90706@kernel.org \
--to=tj@kernel.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jgarzik@pobox.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.