On Fri, 2019-06-14 at 20:36 +1000, Benjamin Herrenschmidt wrote: > On Fri, 2019-06-14 at 10:57 +0100, Lorenzo Pieralisi wrote: > > > Also using "probe_only" for _DSM #5 = 0 isn't a good idea, at least as > > > implemented today in the rest of the kernel, probe_only also means we > > > shouldn't assign what was left unassigned. However _DSM #5 allows this. > > > > I am not sure about this. PCI_PROBE_ONLY cannot stop an OS from > > reassigning BARs that are clearly misconfigured, it does not make > > any sense. > > PCI_PROBE_ONLY is a linux thing which, as implemented today, implies no > assignment at all. I believe it originates as a merge of variants of > the same thing, at least one of them being one I created for powerpc > back in the days due to our proprietary hypervisor not letting you > touch any of the PCI config space. Well... you could "touch" things and even BAR size but mostly we don't even do that on powerpc on these systems these days, we read the BAR values (and a bunch of other things) from OFW and manufacture the pci_dev. The generic code still use cfg space to fill up the blanks. sparc64 uses the same technique. This least to another conversation we hinted at earlier.. we should probably have a way to do the same at least for BARs on ACPI systems so we don't have to temporarily disable access to a device to size them. This can be problematic is the device in question need to be used during the sizing. It can happen with some system devices used behind the scene by FW, or the device on which the console is (how many time did I crash bcs I had too verbose printk's in the PCI code during BAR sizing of the framebuffer or the serial card...) Cheers, Ben.
