Re: [PATCH v1 3/3] xen/common: move device initialization code to common code

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.09.2024 10:51, oleksii.kurochko@xxxxxxxxx wrote:
> On Mon, 2024-09-23 at 09:20 +0200, Jan Beulich wrote:
>> On 16.09.2024 17:51, oleksii.kurochko@xxxxxxxxx wrote:
>>> On Fri, 2024-09-13 at 19:45 +0200, Jan Beulich wrote:
>>>> On 13.09.2024 16:35, oleksii.kurochko@xxxxxxxxx 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