All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.