From: Jeff Garzik <jgarzik@pobox.com>
To: Roland Dreier <roland@topspin.com>
Cc: Greg KH <greg@kroah.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: avoiding pci_disable_device()...
Date: Mon, 14 Feb 2005 17:25:08 -0500 [thread overview]
Message-ID: <42112544.2030006@pobox.com> (raw)
In-Reply-To: <52d5v224z3.fsf@topspin.com>
Roland Dreier wrote:
> Jeff> That's an MSI bug.
>
> Jeff> A current PCI driver -should- be using pci_request_regions().
>
> Hmm... I'm not sure everyone would agree with that. It does make
> sense that the MSI-X core wants to make sure that it owns the MSI-X
> table without having someone else stomp on it.
The idea is right but the implementation is definitely incorrect, for
multiple reasons:
* Every PCI driver should call pci_request_regions(), because there
should only be one pci_driver associated with that set of resources.
* Therefore, any _addition_ to the PCI API that prevents a driver from
using pci_request_regions() causes multiple problems, by virtue of
diverging from the other 98% of the kernel's PCI drivers, which use
pci_request_regions().
IOW, MSI-X's implementation incorrectly constrains PCI driver authors.
* Programmer over-protection. Who is attempting to stomp on MSI-X
tables? If a driver is reading an MSI-X bar and doing something without
consulting the kernel MSI-X code, that's a bug and most likely a
violation of the PCI spec. Fix the driver.
In Linux we don't over-protect programmers with a zillion sanity checks
for every internal API call; that leads to bloat, and papers over bugs
that should be fixed.
Jeff
next prev parent reply other threads:[~2005-02-14 22:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-14 1:42 avoiding pci_disable_device() Jeff Garzik
2005-02-14 19:06 ` Greg KH
2005-02-14 18:08 ` Alan Cox
2005-02-14 19:24 ` Takashi Iwai
2005-02-14 19:34 ` Greg KH
2005-02-14 19:50 ` Takashi Iwai
2005-02-14 19:54 ` Jeff Garzik
2005-02-14 19:51 ` Jeff Garzik
2005-02-14 19:58 ` Roland Dreier
2005-02-14 20:00 ` Jeff Garzik
2005-02-14 21:42 ` Roland Dreier
2005-02-14 22:25 ` Jeff Garzik [this message]
2005-02-14 22:46 ` Roland Dreier
2005-02-17 23:07 ` Greg KH
2005-02-14 20:02 ` Arjan van de Ven
2005-02-15 2:05 ` Jeff Garzik
2005-02-16 11:27 ` Takashi Iwai
2005-02-16 13:44 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2005-02-14 10:43 Michal Rokos
2005-02-14 11:08 ` Christoph Hellwig
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=42112544.2030006@pobox.com \
--to=jgarzik@pobox.com \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@topspin.com \
/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.