Messages in this thread | | | Subject | Re: [RFC PATCH 00/35] Move all PCIBIOS* definitions into arch/x86 | From | Benjamin Herrenschmidt <> | Date | Wed, 15 Jul 2020 12:19:46 +1000 |
| |
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.
| |