Hi Michael,
On 7/28/25 5:17 PM, Michael Tokarev wrote:
> On 28.07.2025 17:56, Eric Auger wrote:
>> Hi Michael,
>
> Hi!
>
>> This commit added an imply ACPI_PCI to the PCI_EXPRESS_GENERIC_BRIDGE
>> config in hw/pci-host/Kconfig:
>>
>> config PCI_EXPRESS_GENERIC_BRIDGE
>> bool
>> select PCI_EXPRESS -> selects PCI
>> imply ACPI_PCI
>>
>> In hw/acpi/Kconfig we have:
>>
>> config ACPI_PCI
>> bool
>> depends on ACPI && PCI
>>
>> ACPI is selected by ACPI_HW_REDUCED
>>
>> config ACPI_HW_REDUCED
>> bool
>> select ACPI
>> select ACPI_MEMORY_HOTPLUG
>> select ACPI_NVDIMM
>>
>> so logically the ACPI && PCI dependencies for ACPI_PCI should be
>> resolved. What do I miss?
>
> I think it should be "select" not "imply", which seems to be stricter.
> With a devices file like I'm using - it looks like - only things which
> are selected gets enabled. But this commit brings hard dependency
> between the bridge device and ACPI_PCI, as demonstrated by my example.
> So when the bridge selects ACPI_PCI instead of implying it, whole thing
> works (I just verified it)
build_pci_host_bridge_osc_method() is called from gpex-acpi.c
pci_ss.add(when: ['CONFIG_PCI_EXPRESS_GENERIC_BRIDGE', 'CONFIG_ACPI'],
if_true: files('gpex-acpi.c'))
so the hard dependency exists only if ACPI is selected.
If you use "select" you will force ACPI_PCI even if ACPI is not set
which does not sound what we want?
regards
Eric
>
> I wonder why we build microvm-only executable in debian... Initially
> it was a small binary aimed at very fast startup and light runtime.
> But with time it grew quite a lot of things...
>
> Thanks,
>
> /mjt
>
