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

[Brian King]

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 see a few options:
>
>  - Log all pending writes to config space and replay the log when the
>    device is unblocked.

This would need to be dynamic in size, as a device could be blocked for 
a long time. In the scenario that this is used for power management and 
the device could be blocked for a long time, its unclear that we would 
still want all the writes accumulated to be written out when the device 
becomes unblocked.

>  - Fail writes to config space while the device is blocked.

This would be nice and simple. I know Alan had some issue with returning 
failures on reads when blocked.

Alan - do you have the same issue on writes?

>  - Write to the saved config space and then blat the saved config space
>    back to the device upon unblocking.

Would also be pretty simple to do and seems a little safer than 
potentially assaulting the recently unblocked device with who knows what 
values. The only problem I see with this is that we could end up 
returning strange values on cached reads if the writes update the cache. 
If userspace wrote to a read only register, we would end up returning 
that value on the read, which may not be the right thing to do.

> Any other ideas?

We could go back to Alan's idea of putting userspace reads/writes to 
sleep when the device is blocked, although this has additional 
complications as well...

> BTW, you know things like XFree86 go completely around the kernel's PCI
> accessors and poke at config space directly?

The purpose of this API is to provide a way for the kernel to stop 
userspace from accessing PCI devices when the results of doing so would 
be catastrophic, such as a PCI bus error. The only users of this API so 
far are device drivers running BIST on an adapter (which shouldn't 
happen on a video card AFAIK) and for PPC power management (Ben - will 
this be an issue for you?)

--
Brian King
eServer Storage I/O
IBM Linux Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/