From: Tejun Heo <htejun@gmail.com>
To: Alan <alan@lxorguk.ukuu.org.uk>
Cc: bzolnier@gmail.com, linux-ide@vger.kernel.org
Subject: Re: [PATCH] amd74xx: don't configure udma mode higher than BIOS did
Date: Mon, 05 Feb 2007 23:17:07 +0900 [thread overview]
Message-ID: <45C73C63.1090108@gmail.com> (raw)
In-Reply-To: <20070205132442.1516678b@localhost.localdomain>
Alan wrote:
>> To prevent that, the value is cached on driver probe and written back on
>> driver detach on pata_amd, which is necessary even when there is no
>
> Which is useless.
I can agree to 'not always effective' but its useful in common driver
load/unload cases.
>> suspend/resume as mode programming alters the content of the register.
>> amd74xx cannot be unloaded, so caching is enough. Also, doesn't
>> suspend/resume cycle store and restore PCI space anyway?
>
> If I load the driver after a kexec or after a suspend/resume cycle both
> of which are quite valid your code breaks.
I wrote about kexec in the other reply. And about loading after
suspend/resume, yeap, it's outside of saved area, so it'll probably
contain reset or random value. Again, the worst that happens is
limiting transfer mode to udma33, which, considering the likelihood of
the scenario weighted against the common case, is acceptable, IMHO.
I think the first thing we need to do is verifying this problem. If
this is a rare problem, let's forget about it. If it can be easily
reproduced, we need to do something about it one way or the other -
maybe sniffing BIOS mode as I did or maybe different smart trick.
Thanks.
--
tejun
next prev parent reply other threads:[~2007-02-05 14:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-05 7:58 [PATCH] amd74xx: don't configure udma mode higher than BIOS did Tejun Heo
2007-02-05 11:24 ` Alan
2007-02-05 12:16 ` Tejun Heo
2007-02-05 12:33 ` Tejun Heo
2007-02-05 13:24 ` Alan
2007-02-05 14:17 ` Tejun Heo [this message]
2007-02-05 13:22 ` Alan
2007-02-05 14:07 ` Tejun Heo
2007-02-05 14:34 ` Nvidia cable detection problems (was [PATCH] amd74xx: don't configure udma mode higher than BIOS did) Alan
2007-02-05 14:50 ` Tejun Heo
2007-02-05 15:49 ` Alan
[not found] ` <58cb370e0702050709w1b7682dr5dff9e7ce69465a@mail.gmail.com>
2007-02-05 17:08 ` Allen Martin
2007-02-05 18:12 ` Alan
2007-02-05 18:36 ` Tejun Heo
2007-02-05 18:55 ` Bartlomiej Zolnierkiewicz
2007-02-05 19:15 ` Tejun Heo
2007-02-05 21:27 ` Bartlomiej Zolnierkiewicz
2007-02-05 22:02 ` Alan
2007-02-05 22:00 ` Bartlomiej Zolnierkiewicz
2007-02-05 19:13 ` Alan
2007-02-05 21:43 ` Jeff Garzik
2007-02-05 15:32 ` [PATCH] amd74xx: don't configure udma mode higher than BIOS did Sergei Shtylyov
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=45C73C63.1090108@gmail.com \
--to=htejun@gmail.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bzolnier@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).