[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1198822010.7209.32.camel@pasglop>
Date: Fri, 28 Dec 2007 17:06:50 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Loic Prylli <loic@...i.com>, Robert Hancock <hancockr@...w.ca>,
Jeff Garzik <jeff@...zik.org>,
Arjan van de Ven <arjan@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
gregkh@...e.de, linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
Martin Mares <mj@....cz>, Matthew Wilcox <matthew@....cx>,
Kai Ruhnau <kai@...getaschen.dyndns.org>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
opt-in
On Thu, 2007-12-27 at 21:37 -0800, Linus Torvalds wrote:
>
> On Fri, 28 Dec 2007, Benjamin Herrenschmidt wrote:
> >
> > I have embedded boards where proper CRS operations is critical since the
> > kernel brings the PCIe link up itself, and thus is likely to hit devices
> > still in the middle of CRS.
>
> .. but that's perfectly fine. A PCI-E bridge will certainly retry it in
> hardware (or it isn't a PCI-E bridge!).
Only a handful of times in many bridges I've seen.
> So I'm going to disable that thing. If there is some _other_ PCI-E bridge
> that is simply buggy, and cannot handle the hw retry itself or is just
> otherwise dodgy, we can have a white-list for cases where it really needs
> to be done, but the current code is just bogus.
If you disable it, then isn't there also a problem with PCIE->PCI-X
bridge which will stop issuing CRS when they should ? (not sure here, I
may be a bit confused).
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists