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

Brian King
2005-02-01T19:02:12Z

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