Messages in this thread | | | Date | Sat, 24 Jun 2023 01:34:11 +0800 | Subject | Re: [PATCH] LoongArch: Add SMT (Simultaneous Multi-Threading) support | From | WANG Xuerui <> |
| |
Hi,
On 6/24/23 01:20, Rafael J. Wysocki wrote: > On Thu, Jun 15, 2023 at 4:31 AM Huacai Chen <chenhuacai@kernel.org> wrote: >> Hi, Rafael, >> >> On Thu, Jun 15, 2023 at 2:24 AM Rafael J. Wysocki <rafael@kernel.org> wrote: >>> On Wed, Jun 14, 2023 at 11:38 AM Liupu Wang <wangliupu@loongson.cn> 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/
| |