public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <grundler@parisc-linux.org>
To: Roland Dreier <rolandd@cisco.com>
Cc: Matthew Wilcox <matthew@wil.cx>,
	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: Thu, 27 Oct 2005 11:11:55 -0600	[thread overview]
Message-ID: <20051027171155.GA7258@colo.lackof.org> (raw)
In-Reply-To: <52hdb3yp36.fsf@cisco.com>

On Thu, Oct 27, 2005 at 08:08:45AM -0700, Roland Dreier wrote:
>     Matthew> Perhaps the right thing to do is to change pad2 (in
>     Matthew> struct pci_bus) to bus_flags and make bit 0
>     Matthew> PCI_BRIDGE_FLAGS_NO_MSI ?
> 
> Seems reasonable, but I'm still not sure how to implement this.  Where
> does this bit get set and propagated to secondary buses?

Does it have to be propagate to secondary busses?
Can't the MSI init code walk up the tree until it hits a root node?


> To give a somewhat pathological real-world example, Mellanox PCI-X
> adapters have a PCI bridge in them; in other words, a single adapter
> looks like:
...
> Also, if someone hot-plugged such an adapter into a bus below an AMD
> 8131 host bridge (I believe eg Sun V40Zs have hot-pluggable slots like
> that), then the NO_MSI flag still needs to get propagated from the
> 8131 bridge to the Mellanox bridge and set no_msi on the final device.
> 
> Where in the PCI driver code is the right place to handle all this (I
> hope by writing the code only once)?

I expect this could be contained in msi.c.
ie changes to msi_init(), pci_enable_msi(), msi_capability_init().

The flag would have to be set by whatever code claims the AMD 8131
chip.

hth,
grant

  parent reply	other threads:[~2005-10-27 17:04 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
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 [this message]
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=20051027171155.GA7258@colo.lackof.org \
    --to=grundler@parisc-linux.org \
    --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