Re: [PATCH 1/1] pci: Block config access during BIST (resend)

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Brian King <brking@us.ibm.com>, Greg KH <greg@kroah.com>,
	Andi Kleen <ak@muc.de>, Paul Mackerras <paulus@samba.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-pci@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH 1/1] pci: Block config access during BIST (resend)
Date: Wed, 02 Feb 2005 10:00:34 +1100	[thread overview]
Message-ID: <1107298834.5624.15.camel@gaston> (raw)
In-Reply-To: <20050201174758.GE10088@parcelfarce.linux.theplanet.co.uk>

On Tue, 2005-02-01 at 17:47 +0000, Matthew Wilcox wrote:
> On Tue, Feb 01, 2005 at 11:35:05AM -0600, Brian King wrote:
> > >If we've done a write to config space while the adapter was blocked,
> > >shouldn't we replay those accesses at this point?
> > 
> > I did not think that was necessary.
> 
> We have to do *something*.  We can't just throw away writes.

I think we can in fact. Again, nobody outside of the driver has
legitimacy to write to the config space of a device, especially if the
device is "unreachable" (either doing a BIST or power managed).

> I see a few options:
> 
>  - Log all pending writes to config space and replay the log when the
>    device is unblocked.
>  - Fail writes to config space while the device is blocked.

I agree that returning an error in this case would be a good idea.

>  - Write to the saved config space and then blat the saved config space
>    back to the device upon unblocking.
> 
> Any other ideas?
> 
> BTW, you know things like XFree86 go completely around the kernel's PCI
> accessors and poke at config space directly?

Not anymore afaik. They use /proc/bus/pci

Ben.