On Tue, 2020-07-14 at 18:46 -0500, Bjorn Helgaas wrote: > Yes. I have no problem with that. There are a few cases where it's > important to check for errors, e.g., we read a status register and do > something based on a bit being set. A failure will return all bits > set, and we may do the wrong thing. But most of the errors we care > about will be on MMIO reads, not config reads, so we can probably > ignore most config read errors. And in both cases, we don't have the plumbing to provide accurate and reliable error returns for all platforms anyways (esp. not for MMIO). I think it makes sense to stick to the good old "if all 1's, then go out of line" including for config space. ../.. > Yep, except for things like device removal or other PCI errors. A whole bunch of these are reported asynchronously, esp for writes (and yes, including config writes, they are supposed to be non-posted but more often than not, the path from the CPU to the PCI bridge remains posted for writes including config ones). > So maybe a good place to start is by removing some of the useless > error checking for pci_read_config_*() and pci_write_config_*(). > That's a decent-sized but not impractical project that could be done > per subsystem or something: > > git grep -E "(if|return|=).*\<pci_(read|write)_config" drivers > > finds about 400 matches. > > Some of those callers probably really *do* want to check for errors, > and I guess we'd have to identify them and do them separately as you > mentioned. I'd be curious about these considering how unreliable our error return is accross the board. Cheers, Ben.
