|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 5/5] xen/common: move device initialization code to common code
On Mon, 2024-09-23 at 16:43 +0200, Jan Beulich wrote:
> On 17.09.2024 18:15, Oleksii Kurochko wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -12,6 +12,14 @@ config CORE_PARKING
> > bool
> > depends on NR_CPUS > 1
> >
> > +config DEVICE_INIT
> > + bool
> > + default !X86
>
> This can simply be "def_bool y" as ...
>
> > + depends on !X86 && (ACPI || HAS_DEVICE_TREE)
>
> ... this enforces all restrictions. As indicated before I'd prefer if
> we
> could get away without yet another Kconfig constant, which would then
> also eliminate my concern about the expression not really covering
> for
> the case where x86 would obtain DT support (and hence likely needing
> the
> initialization here, too). What about ...
>
> > --- 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-$(CONFIG_DEVICE_INIT) += device.o
>
> obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
> obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device.o
>
> ? (Eventually we could then simplify this to just obj-$(CONFIG_ACPI),
> to allow DT on x86, making sure the ACPI part of the file builds for
> x86 but does nothing there.)
I am okay with this solution. It seems I misunderstood you in the first
version of this patch series. When "obj-$(or ... )" was used, I decided
it wasn’t a good approach to use 'or', 'filter-out', or other similar
functions in Makefiles for such cases. I couldn't come up with a better
solution at the time, so I introduced a new config instead.
The only issue I see with this approach is that in device.c, there is
the following code:
#ifdef CONFIG_ACPI
extern const struct acpi_device_desc _asdevice[], _aedevice[];
int __init acpi_device_init(enum device_class class, const void *data,
int class_type)
...
#endif
This shouldn't be compiled for X86. However, it will still be compiled
if we simplify to:
obj-$(CONFIG_HAS_DEVICE_TREE) += device.o
obj-$(CONFIG_ACPI) += device.o
The situation where we have CONFIG_HAS_DEVICE_TREE=y and CONFIG_ACPI=y
is possible ( if X86 will start or already using CONFIG_HAS_DEVICE_TREE
). The same will be if the second obj looks like: "obj-$(filter-out
$(CONFIG_X86),$(CONFIG_ACPI)) += device.o" and X86 will use
CONFIG_HAS_DEVICE_TREE.
To resolve this, we probably need two separate files: device-dt.c and
device-acpi.c, and then use:
obj-$(CONFIG_HAS_DEVICE_TREE) += device-dt.o
obj-$(filter-out $(CONFIG_X86),$(CONFIG_ACPI)) += device-acpi.o
Alternatively, we could make an exception in device.c and add a
!CONFIG_X86 condition:
#if defined(CONFIG_ACPI) && !defined(CONFIG_X86)
extern const struct acpi_device_desc _asdevice[], _aedevice[];
int __init acpi_device_init(enum device_class class, const void
*data, int class_type)
...
#endif
~ Oleksii
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |