Re: [RFC 0/6] rust: pci: add config space read/write support

[Zhi Wang <zhiw@nvidia.com>]

On Mon, 13 Oct 2025 22:02:55 +0200
"Danilo Krummrich" <dakr@kernel.org> wrote:

ditto

> > But for the "infallible" part in PCI configuration space, the device
> > can be disconnected from the PCI bus. E.g. unresponsive device. In
> > that case, the current PCI core will mark the device as
> > "disconnected" before they causes more problems and any access to
> > the configuration space will fail with an error code. This can also
> > happen on access to "infalliable" part.
> >
> > How should we handle this case in "infallible" accessors of PCI
> > configuration space? Returning Result<> seems doesn't fit the
> > concept of "infallible", but causing a rust panic seems overkill...
> 
> Panics are for the "the machine is unrecoverably dead" case, this
> clearly isn't one of them. :)
> 
> I think we should do the same as with "normal" MMIO and just return
> the value, i.e. all bits set (PCI_ERROR_RESPONSE).
> 
> The window between physical unplug and the driver core unbinds the
> driver should be pretty small and drivers have to be able to deal
> with garbage values read from registers anyways.
> 

Was thinking about this these days. Panic seems overkill. Given the
current semantics of "infallible" (non-try) and "fallible" (try) is
decided by the driver, I think we can do the same for PCI configuration
space with the case of "PCI device could be disconnected".

- We implement both for PCI configuration space.

- The driver decides to use "non-try" or "try" according to the device
  characteristic. E.g. if the device is simple, hardly to be
  unresponsive, not supporting hotplug, or the driver is in a context
  that the device is surely responsive. The driver can be confident
  to use the "infallible" version and tolerate garbage values in the
  rare situation. Otherwise the driver can use "faillble" version to
  capture the error code if it is sure the device can sometimes be
  unresponsive.

> If we really want to handle it, you can only implement the try_*()
> methods and for the non-try_*() methods throw a compile time error,
> but I don't see a reason for that.