From: Matthew Wilcox <matthew@wil.cx>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
Christophe Lucas <c.lucas@ifrance.com>,
kernel-janitors@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [KJ] [PATCH] drivers/char/watchdog/* : pci_request_regions
Date: Thu, 17 Feb 2005 19:04:08 +0000 [thread overview]
Message-ID: <20050217190408.GW29917@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <4214E728.3030501@pobox.com>
On Thu, Feb 17, 2005 at 01:49:12PM -0500, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >On Mon, Feb 14, 2005 at 04:01:11PM +0100, Christophe Lucas wrote:
> >
> >>If PCI request regions fails, then someone else is using the
> >>hardware we wish to use. For that one case, calling
> >>pci_disable_device() is rather rude.
> >>See : http://www.ussg.iu.edu/hypermail/linux/kernel/0502.1/1061.html
> >
> >
> >Actually, that isn't necessarily true. If the request_regions call fails,
> >that can mean there's a resource conflict. If so, leaving the device
> >enabled is the worst possible thing to do as we'll now have two devices
> >trying to respond to the same io accesses.
>
> Incorrect. If request_region() fails, drivers are coded to _not_ touch
> the hardware. That's the entire purpose of the whole charade: to avoid
> having two devices responding to the same io accesses.
>
> If your driver is talking to the hardware after request_region() fails,
> it is BROKEN plain and simple.
I don't think you understood my point. Assume we really do have two
devices in the system with clashing resource settings. Yes, I really
have seen this happen; it's rare.
While the PCI device is disabled, there is no problem. But then we call
pci_enable_device(), so now the device is enabled to respond to IO and
memory resources in its BARs.
At the point we discover this, we need to disable the PCI device again
-- exactly the opposite behaviour from your case where we need to leave
the PCI device enabled when we have resource conflicts.
I think the only way to fix this is have pci_enable_device claim the
resources for the BARs before enabling the PCI device to respond to the
resources; that way we leave the enable bits the way they currently are.
No, this doesn't cure the world's ills, but it does obey "First, do
no harm". One way it'll fail is if the other driver loads after the PCI
driver that claims this resource.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
next prev parent reply other threads:[~2005-02-17 19:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050214150111.GH20620@rhum.iomeda.fr>
2005-02-14 15:12 ` Matthew Wilcox
2005-02-17 18:49 ` Jeff Garzik
2005-02-17 19:04 ` Matthew Wilcox [this message]
2005-02-17 19:22 ` 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=20050217190408.GW29917@parcelfarce.linux.theplanet.co.uk \
--to=matthew@wil.cx \
--cc=c.lucas@ifrance.com \
--cc=jgarzik@pobox.com \
--cc=kernel-janitors@lists.osdl.org \
--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®