mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: igor@novg.net
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <jgarzik@pobox.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2.6.38.1] pata_it821x: Add module param to force UDMA on Vortex86SX
Date: Sat, 26 Mar 2011 16:58:55 +0300	[thread overview]
Message-ID: <90c1a5f93e6d67aec9f67a1d4c0deb86@novg.net> (raw)
In-Reply-To: <20110326125441.3e628850@lxorguk.ukuu.org.uk>

 On Sat, 26 Mar 2011 12:54:41 +0000, Alan Cox wrote:
>>  May be there are errors with pure IDE devices or with older 
>> revisions
>>  of Vortex86SX
>>  boards, i do no know. But for my device i have 2x improvement in 
>> I/O
>>  speed when
>>  enabling UDMA/33 instead of MWDMA, so i think this parameter would 
>> be
>>  useful.
>
> "I do not know" is not a good basis for hacking storage code,
> particularly if it was to turn out that the reason was something like
> silent data corruption (eg as with UDMA on the old OSB4 controllers 
> in
> some cases)
>

 Well, by "i do not know" i meant that i do not have other (older) DMP
 hardware, nor do i have means to connect pure IDE device to my device
 (DMP-2300).
 I just can state that i was having a root FS on a CompactFlash for 
 quite
 a long time with UDMA enabled, and i have not observed any problems, 
 and
 have seen no signs of data corruption either.

 I am just proposing to give users an option to enable UDMA at their own 
 risk,
 maybe add comment stating that enabling this option may or may not
 cause silent data corruption. Or maybe to add this as a sub-option to 
 the
 driver in Kconfig to switch on/off at compile time with detailed 
 description
 under ---help---

> The change came via DMP signoff (the manufacturer) so any adjustment 
> of
> this sort of checking really ought to go via DMP as well.
>
>>  Also fix to initialize default value for parameter 'noraid'.
>
> This does not need initialising - C guarantees static variables start 
> at
> zero. If that makes a difference you have other problems.

 Sorry, my bad.

> So NAK this.
>
> Although if you want to take it up with DMP and find out if they have
> updated rules or checks that want pushing that might be useful.

 No, i do not intend to contact them, i just wanted people to have an 
 on/off
 switch in kernel, not to push this patch by all means necessary.

 If this option is considered by community unneeded, i'll just have to 
 patch my
 own kernel with every upgrade :)

> Alan


  reply	other threads:[~2011-03-26 13:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-26 12:30 igor
2011-03-26 12:54 ` Alan Cox
2011-03-26 13:58   ` igor [this message]
2011-03-26 15:54     ` Alan Cox

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=90c1a5f93e6d67aec9f67a1d4c0deb86@novg.net \
    --to=igor@novg.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®