On Wed, Mar 10, 2021 at 1:27 AM Hector Martin <marcan@xxxxxxxxx> wrote: > > On 10/03/2021 07.06, Rob Herring wrote: > >> My main concern here is that this creates an inconsistency in the device > >> tree representation that only works because PCI drivers happen not to > >> use these code paths. Logically, having "nonposted-mmio" above the PCI > >> controller would imply that it applies to that bus too. Sure, it doesn't > >> matter for Linux since it is ignored, but this creates an implicit > >> exception that PCI buses always use posted modes. > > > > We could be stricter that "nonposted-mmio" must be in the immediate > > parent. That's kind of in line with how addressing already works. > > Every level has to have 'ranges' to be an MMIO address, and the > > address cell size is set by the immediate parent. > > > >> Then if a device comes along that due to some twisted fabric logic needs > >> nonposted nGnRnE mappings for PCIe (even though the actual PCIe ops will > >> end up posted at the bus anyway)... how do we represent that? Declare > >> that another "nonposted-mmio" on the PCIe bus means "no, really, use > >> nonposted mmio for this"? > > > > If we're strict, yes. The PCI host bridge would have to have "nonposted-mmio". > > Works for me; then let's just make it non-recursive. > > Do you think we can get rid of the Apple-only optimization if we do > this? It would mean only looking at the parent during address > resolution, not recursing all the way to the top, so presumably the > performance impact would be quite minimal. Yeah, that should be fine. I'd keep an IS_ENABLED() config check though. Then I'll also know if anyone else needs this. Rob
