Date: Thu, 27 Oct 2005 10:36:58 -0600
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
Message-ID: <20051027163658.GA8201@parisc-linux.org>
References: <524q799p2t.fsf@cisco.com> <20051022233220.GA1463@parisc-linux.org> <52hdb3yp36.fsf@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52hdb3yp36.fsf@cisco.com>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1051
Lines: 21

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?

We can propagate it to secondary busses in pci_alloc_child_bus().
We inherit parent->ops and parent->sysdata at this point, we can also
inherit parent->whatever_flags_we_like.

Setting it from the quirk is a bit more yucky.  I *think* we're going
to have to walk the PCI tree, given that it's a FIXUP_FINAL.  Maybe it
needs to not be a FIXUP_FINAL ... a FIXUP_HEADER might get it set early
enough for it to propagate through that mechanism.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/