Hi,
On 6/24/23 01:20, Rafael J. Wysocki wrote:
On Thu, Jun 15, 2023 at 4:31 AM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
Hi, Rafael,
On Thu, Jun 15, 2023 at 2:24 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
On Wed, Jun 14, 2023 at 11:38 AM Liupu Wang <wangliupu@xxxxxxxxxxx> wrote:
[snip]
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ccbeab9500ec..00dd309b6682 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -542,10 +542,10 @@ config ACPI_PFRUT
if ARM64
source "drivers/acpi/arm64/Kconfig"
+endif
config ACPI_PPTT
bool
-endif
x86 doesn't use PPTT as of today. Why do you enable it for them?
ACPI_PPTT is an invisible symbol, it cannot be enabled by explicitly
selecting and its default value is n, so I think it isn't enabled for
x86. On the other hand, moving it out of ARM64 can make other archs
don't need to modify this file any more if they need PPTT.
AFAICS, setting ACPI_PPTT causes pptt.c to be compiled and if it is
never going to be used by the given arch, it will just be dead code.
Can't this be avoided?
FYI I've just tried a x86_64 defconfig build and ACPI_PPTT isn't being
enabled, nor is there a pptt.o signifying the same thing.
> drivers/acpi/Makefile
> 109:obj-$(CONFIG_ACPI_PPTT) += pptt.o
This should mean that, if nothing is selecting ACPI_PPTT then the file
isn't going to be compiled? Right now it seems only arch/arm64 and
arch/loongarch are doing so based on my cursory grep. Or do you mean we
should be extra careful and keep the guard around the symbol to ensure
it's nonexistent on other irrelevant arches?
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
