Hello Rob, thanks for this feedback! On Thu, 2021-04-15 at 13:59 -0500, Rob Herring wrote: > +PPC and PCI lists > > On Thu, Apr 15, 2021 at 1:01 PM Leonardo Bras <leobras.c@xxxxxxxxx> wrote: > > > > Many other resource flag parsers already add this flag when the input > > has bits 24 & 25 set, so update this one to do the same. > > Many others? Looks like sparc and powerpc to me. > s390 also does that, but it look like it comes from a device-tree. > Those would be the > ones I worry about breaking. Sparc doesn't use of/address.c so it's > fine. Powerpc version of the flags code was only fixed in 2019, so I > don't think powerpc will care either. In powerpc I reach this function with this stack, while configuring a virtio-net device for a qemu/KVM pseries guest: pci_process_bridge_OF_ranges+0xac/0x2d4 pSeries_discover_phbs+0xc4/0x158 discover_phbs+0x40/0x60 do_one_initcall+0x60/0x2d0 kernel_init_freeable+0x308/0x3a8 kernel_init+0x2c/0x168 ret_from_kernel_thread+0x5c/0x70 For this, both MMIO32 and MMIO64 resources will have flags 0x200. > > I noticed both sparc and powerpc set PCI_BASE_ADDRESS_MEM_TYPE_64 in > the flags. AFAICT, that's not set anywhere outside of arch code. So > never for riscv, arm and arm64 at least. That leads me to > pci_std_update_resource() which is where the PCI code sets BARs and > just copies the flags in PCI_BASE_ADDRESS_MEM_MASK ignoring > IORESOURCE_* flags. So it seems like 64-bit is still not handled and > neither is prefetch. > I am not sure if you mean here: a) it's ok to add IORESOURCE_MEM_64 here, because it does not affect anything else, or b) it should be using PCI_BASE_ADDRESS_MEM_TYPE_64 (or IORESOURCE_MEM_64 | PCI_BASE_ADDRESS_MEM_TYPE_64) instead, since it's how it's added in powerpc/sparc, and else there is no point. Again, thanks for helping! Best regards, Leonardo Bras
