So if we go down this path of CONFIG_WBRF and CONFIG_WBRF_ACPI, another
question would be where should the new "wbrf.c" be stored? The ACPI only
version most certainly made sense in drivers/acpi/wbrf.c, but a generic
version that only has an ACPI implementation right now not so much.
On 6/21/2023 1:30 PM, Andrew Lunn wrote:
And consumer would need to call it, but only if CONFIG_WBRF_ACPI isn't set.
Why? How is ACPI special that it does not need notifiers?
ACPI core does has notifiers that are used, but they don't work the same.
If you look at patch 4, you'll see amdgpu registers and unregisters using
both
acpi_install_notify_handler()
and
acpi_remove_notify_handler()
If we supported both ACPI notifications and non-ACPI notifications
all consumers would have to have support to register and use both types.
I don't see why it couldn't be a DT/ACPI hybrid solution for ARM64.
As said somewhere else, nobody does hybrid. In fact, turn it
around. Why not implement all this in DT, and make X86 hybrid? That
will make arm, powerpc, risc-v and mips much simpler :-)
Andrew
Doesn't coreboot do something hybrid with device tree? I thought they
generate their ACPI tables from a combination of DT and some static ASL.
