On Fri, 2019-06-14 at 15:13 -0500, Bjorn Helgaas wrote: > Ok, I have to read about this. I haven't seen a device with that on > > yet, it looks messy at a quick glance. > > > > Can ACPI convey the information ? On powerpc and sparc64 we have ways > > to read the BAR values from the device-tree created by OF when it > > assigned them. > > I agree, EA is messy. > > I don't think it's feasible to do this in ACPI. It's a pretty > fundamental principle of PCI that you can discover what resources a > device needs and uses by looking at its config space. In general PCIe > requires ECAM, which gives the OS direct access to config space, > although it does allow exceptions for architecture-specific firmware > interfaces for accessing config space, e.g., ia64 SAL (PCIe r4.0, sec > 7.2.2). So this isn't something I need, but if others do, we can find a reasonable compromise here and push it to the spec. It's actually fairly easy: If a device is used by FW (SMM, SMCCC or whatever other runtime thingy) to the extent that temporarily disabling it for BAR sizing can cause random boot failures (if the wrong event happens at the wrong time), it would be easy for FW to "mark" that device as such (_DSM #5 == 2 ? just kidding...) and provide some forms of properties/datas that expose the resources that were assigned. On OF, the properties for that already exist, so just adding something like "no-bar-sizing" or such in the node for the device would do. It's easy because FW only has to "represent" endpoints that have such properties and leave everything else to the OS. There is no need to mandate a full representation of all PCI devices. There are a few details to be careful of, for example, if any bridge in the parent chain of such an endpoint has BARs (not windows, actual BARs), then they should have those properties too, otherwise sizing them will temporarily disable the path to the device since BAR sizing should be done with memory/io decode off. But otherwise, it's a pretty trivial thing to specify and implement I suspect. A lot easier than requiring HW to implement EA is my gut feeling :-) As I said, I don't have a pressing need for that now (could have come in handy back in the powermac days ... oh well). But if enough people do, I'm happy to help ironing something out. Cheers, Ben
