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

[oleksii.kurochko@xxxxxxxxx]

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.

~ Oleksii