On Tue, Dec 11, 2018 at 10:57 PM Sinan Kaya <okaya@xxxxxxxxxx> wrote: > > On 12/11/2018 4:46 PM, Rafael J. Wysocki wrote: > > On Tue, Dec 11, 2018 at 6:37 PM Sinan Kaya <okaya@xxxxxxxxxx> wrote: > >> > >> On 12/11/2018 12:09 PM, Christoph Hellwig wrote: > >>> On Mon, Dec 10, 2018 at 06:13:14PM +0000, Sinan Kaya wrote: > >>>> Getting ready to allow PCI to be disabled with ACPI enabled. Stub > >>>> out calls that depend on PCI. > >>> > >>> I think you want to skip building at least all of hwpci.c if CONFIG_PCI > >>> is disabled. Or replace that whole stiking pile of crap with something > >>> resembling C code.. > >>> > >> > >> I can give it a try but I'm under the impression that we don't touch > >> ACPICA code in general. > >> > >> Feel free to correct me. > > > > We don't as a rule, but depending on what the patch looks like, we > > might not follow the rule this time. > > > > OK. Good to know. I'll take a stab at it. > > > I wonder though what we do if some AML wants to access PCI config > > space via an opregion in there. Have you thought about that? > > > > Return an error. > > AFAIK, ACPI spec says that AML code running on non-existing op-regions to be > discarded last time I checked. I guess you mean "disregarded"? So the spec appears to expect the OS to silently ignore the failures in those cases, so why should an error be returned? > I know Linux is noisy about these. > > I did boot QEMU without CONFIG_PCI. There was a bunch of ACPI errors reported > during boot as expected but boot succeeded. There was no hard lockup/failure.
