On 23.09.2024 10:51, oleksii.kuroc...@gmail.com wrote: > On Mon, 2024-09-23 at 09:20 +0200, Jan Beulich wrote: >> On 16.09.2024 17:51, oleksii.kuroc...@gmail.com wrote: >>> On Fri, 2024-09-13 at 19:45 +0200, Jan Beulich wrote: >>>> On 13.09.2024 16:35, oleksii.kuroc...@gmail.com wrote: >>>>> On Thu, 2024-09-12 at 17:28 +0200, Jan Beulich wrote: >>>>>> On 11.09.2024 12:04, Oleksii Kurochko wrote: >>>>>>> --- a/xen/common/Makefile >>>>>>> +++ b/xen/common/Makefile >>>>>>> @@ -6,6 +6,7 @@ obj-$(CONFIG_HYPFS_CONFIG) += config_data.o >>>>>>> obj-$(CONFIG_CORE_PARKING) += core_parking.o >>>>>>> obj-y += cpu.o >>>>>>> obj-$(CONFIG_DEBUG_TRACE) += debugtrace.o >>>>>>> +obj-$(call >>>>>>> or,$(CONFIG_HAS_DEVICE_TREE),$(CONFIG_HAS_ACPI)) += >>>>>>> device.o >>>>>> >>>>>> I can't spot any HAS_ACPI in the tree. And if this was >>>>>> switched >>>>>> to >>>>>> CONFIG_ACPI >>>>>> I'd further ask why the file needs building on x86. >>>>> Oh, there is no need for building this on x86. With what you >>>>> suggested >>>>> here ... >>>>> >>>>>> >>>>>> Also I think I'd prefer to avoid the of the "or" macro here: >>>>>> >>>>>> obj-$(CONFIG_ACPI) += device.o >>>>>> obj-$(CONFIG_HAS_DEVICE_TREE) += device.o >>>>> ... IIUC it will fix the issue with building this file for x86 >>>>> as >>>>> CONFIG_ACPI depends on (ARM_64 && ARM_EFI). >>>> >>>> Except that "depends on" is itself Arm-only, so won't affect x86. >>>> Or else x86 would end up without ACPI support, which would mean >>>> full breakage on about every system. >>> There is another CONFIG_ACPI in xen/drivers/acpi which is equal to >>> 'y' >>> for x86 so it seems to me that it is needed another config ( >>> GENERIC_DEVICE_INIT ? ) which will be disabled for x86 by default >>> so >>> device.o won't be compiled for x86. >>> >>> Have I overlooked something or better option exist? Probably it >>> would >>> be better to use "and" macro? >> >> I'm afraid I don't understand your response. There are two seemingly >> separate ACPI in distinct Kconfig files, yes. They combine when both >> are >> visible to kconfig (as is the case for Arm64). Can you try to re- >> express >> your question with this aspect in mind? > > I wanted to say that we can't simply rely on CONFIG_ACPI and > CONFIG_HAS_DEVICE_TREE to determine if device.o should be compiled > because, in the case of x86, CONFIG_ACPI=y, device.o will be compiled > and result in compilation errors.
Ah, I see. Of course. Ideally to be addressed without introducing yet another (new) Kconfig setting. Jan
