public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Roland Dreier <rolandd@cisco.com>,
	gregkh@suse.de, mst@mellanox.co.il, linux-kernel@vger.kernel.org,
	linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: AMD 8131 and MSI quirk
Date: Wed, 26 Oct 2005 15:51:40 -0700	[thread overview]
Message-ID: <20051026225140.GD13495@kroah.com> (raw)
In-Reply-To: <20051022233220.GA1463@parisc-linux.org>

On Sat, Oct 22, 2005 at 05:32:20PM -0600, Matthew Wilcox wrote:
> On Sat, Oct 22, 2005 at 03:14:34PM -0700, Roland Dreier wrote:
> > The current quirk_amd_8131_ioapic() function sets a global
> > pci_msi_quirk flag, which disables MSI/MSI-X for all devices in the
> > system.  This is safe but suboptimal, because there may be devices on
> > other buses not related to the AMD 8131 bridge, for which MSI would
> > work fine.  As an example, see the end of this email for a lspci -t
> > from a real Opteron system that has PCI-X buses coming from an AMD
> > 8131 and PCI Express buses coming from an Nforce4 bridge -- MSI works
> > fine for the Mellanox InfiniBand adapter on the PCIe bus, if we allow
> > it to be enabled.
> > 
> > I guess what we really should be doing is setting the dev->no_msi flag
> > for all devices below the AMD 8131 PCI-X bridge rather than turning
> > off MSI globally.  Of course this is somewhat tricky, since a device
> > could be hotplugged onto a bus below the AMD 8131.  Greg, any thoughts
> > about the proper way to use the driver model infrastructure to handle
> > this?
> 
> Perhaps the right thing to do is to change pad2 (in struct pci_bus) to
> bus_flags and make bit 0 PCI_BRIDGE_FLAGS_NO_MSI ?

Yeah, I can't think of any way to use the device tree to do this, so
this sounds as good a way as any.

thanks,

greg k-h

  reply	other threads:[~2005-10-26 22:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-22 22:14 AMD 8131 and MSI quirk Roland Dreier
2005-10-22 23:32 ` Matthew Wilcox
2005-10-26 22:51   ` Greg KH [this message]
2005-10-27  6:30     ` Ivan Kokshaysky
2005-10-27 15:08   ` Roland Dreier
2005-10-27 16:36     ` Matthew Wilcox
2005-10-27 17:11     ` Grant Grundler
2006-02-14 16:52 ` Michael S. Tsirkin
2006-02-14 16:56   ` Matthew Wilcox
2006-02-14 17:17     ` Roland Dreier
2006-02-14 17:19   ` Roland Dreier
2006-02-14 18:03   ` Kristen Accardi
2006-02-14 21:21     ` Michael S. Tsirkin
2006-02-14 22:06       ` Kristen Accardi
2006-02-14 22:10         ` Michael S. Tsirkin
2006-02-14 22:52           ` Kristen Accardi
2006-02-14 18:27   ` Roland Dreier
2006-02-14 20:03     ` Matthew Wilcox
2006-02-14 21:24       ` Roland Dreier
2006-02-14 21:11     ` Michael S. Tsirkin
2006-02-14 21:24       ` Roland Dreier
2006-02-17  0:09   ` Greg KH
2006-02-17  0:16     ` Roland Dreier

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=20051026225140.GD13495@kroah.com \
    --to=greg@kroah.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=matthew@wil.cx \
    --cc=mst@mellanox.co.il \
    --cc=rolandd@cisco.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox