All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Roland Dreier <rolandd@cisco.com>
Cc: 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: Sat, 22 Oct 2005 17:32:20 -0600	[thread overview]
Message-ID: <20051022233220.GA1463@parisc-linux.org> (raw)
In-Reply-To: <524q799p2t.fsf@cisco.com>

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 ?

  reply	other threads:[~2005-10-22 23:32 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 [this message]
2005-10-26 22:51   ` Greg KH
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=20051022233220.GA1463@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --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 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.