The ACPI processor driver is not currently enabled for RISC-V.
This is required to enable CPU related functionalities like
LPI and CPPC. Hence, enable ACPI_PROCESSOR for RISC-V.
Signed-off-by: Sunil V L <[email protected]>
---
drivers/acpi/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index f819e760ff19..9a920752171c 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -282,7 +282,7 @@ config ACPI_CPPC_LIB
config ACPI_PROCESSOR
tristate "Processor"
- depends on X86 || ARM64 || LOONGARCH
+ depends on X86 || ARM64 || LOONGARCH || RISCV
select ACPI_PROCESSOR_IDLE
select ACPI_CPU_FREQ_PSS if X86 || LOONGARCH
select THERMAL
--
2.34.1
On Thu, Jan 11, 2024 at 03:00:57PM +0530, Sunil V L wrote:
> The ACPI processor driver is not currently enabled for RISC-V.
> This is required to enable CPU related functionalities like
> LPI and CPPC. Hence, enable ACPI_PROCESSOR for RISC-V.
>
> Signed-off-by: Sunil V L <[email protected]>
> ---
> drivers/acpi/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index f819e760ff19..9a920752171c 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -282,7 +282,7 @@ config ACPI_CPPC_LIB
>
> config ACPI_PROCESSOR
> tristate "Processor"
> - depends on X86 || ARM64 || LOONGARCH
> + depends on X86 || ARM64 || LOONGARCH || RISCV
> select ACPI_PROCESSOR_IDLE
> select ACPI_CPU_FREQ_PSS if X86 || LOONGARCH
> select THERMAL
> --
> 2.34.1
>
Hi Sunil,
Typically we'll want the Kconfig changes to come at the end of a series,
or squashed into the patch that adds support for it, otherwise there's
risk of build breakage during bisection. In this case, we're safe because
the two new functions (I looked ahead) have __weak versions when they're
not present.
Also, interestingly, it looks like this ancient line
obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
in drivers/acpi/Makefile should be removed, since there's no
drivers/acpi/processor.c file. I guess the make process silently
filters object files which don't have corresponding source files?
Maybe we should write a Makefile analyzer to see what other lines
can be removed...
Anyway, for this patch, which I'd prefer to be swapped in order with
the other patch, or just squashed into the other patch,
Reviewed-by: Andrew Jones <[email protected]>
Thanks,
drew
On Thu, Jan 11, 2024 at 11:00:12AM +0100, Andrew Jones wrote:
> On Thu, Jan 11, 2024 at 03:00:57PM +0530, Sunil V L wrote:
> > The ACPI processor driver is not currently enabled for RISC-V.
> > This is required to enable CPU related functionalities like
> > LPI and CPPC. Hence, enable ACPI_PROCESSOR for RISC-V.
> >
> > Signed-off-by: Sunil V L <[email protected]>
> > ---
> > drivers/acpi/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index f819e760ff19..9a920752171c 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -282,7 +282,7 @@ config ACPI_CPPC_LIB
> >
> > config ACPI_PROCESSOR
> > tristate "Processor"
> > - depends on X86 || ARM64 || LOONGARCH
> > + depends on X86 || ARM64 || LOONGARCH || RISCV
> > select ACPI_PROCESSOR_IDLE
> > select ACPI_CPU_FREQ_PSS if X86 || LOONGARCH
> > select THERMAL
> > --
> > 2.34.1
> >
>
> Hi Sunil,
>
> Typically we'll want the Kconfig changes to come at the end of a series,
> or squashed into the patch that adds support for it, otherwise there's
> risk of build breakage during bisection. In this case, we're safe because
> the two new functions (I looked ahead) have __weak versions when they're
> not present.
>
Sure. Let me swap the order of the patches.
> Also, interestingly, it looks like this ancient line
>
> obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
>
> in drivers/acpi/Makefile should be removed, since there's no
> drivers/acpi/processor.c file. I guess the make process silently
> filters object files which don't have corresponding source files?
> Maybe we should write a Makefile analyzer to see what other lines
> can be removed...
>
Interesting.
Hi Rafael, any thoughts?
> Anyway, for this patch, which I'd prefer to be swapped in order with
> the other patch, or just squashed into the other patch,
>
I prefer to keep as 2 separate patches. I will swap the order.
> Reviewed-by: Andrew Jones <[email protected]>
>
Thanks!
Sunil
On Thu, Jan 11, 2024 at 11:00:12AM +0100, Andrew Jones wrote:
[...]
> Also, interestingly, it looks like this ancient line
>
> obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
>
> in drivers/acpi/Makefile should be removed,
No
> since there's no drivers/acpi/processor.c file.
Correct, but ..
> I guess the make process silently filters object files which don't have
> corresponding source files?
May be, but I doubt if that is the case here.
processor.o is just aggregation of all processor_*.o and this will be
the processor.ko when built as a module.
--
Regards,
Sudeep
On Thu, Jan 11, 2024 at 12:16:06PM +0000, Sudeep Holla wrote:
> On Thu, Jan 11, 2024 at 11:00:12AM +0100, Andrew Jones wrote:
>
> [...]
>
> > Also, interestingly, it looks like this ancient line
> >
> > obj-$(CONFIG_ACPI_PROCESSOR) += processor.o
> >
> > in drivers/acpi/Makefile should be removed,
>
> No
>
> > since there's no drivers/acpi/processor.c file.
>
> Correct, but ..
>
> > I guess the make process silently filters object files which don't have
> > corresponding source files?
>
> May be, but I doubt if that is the case here.
>
> processor.o is just aggregation of all processor_*.o and this will be
> the processor.ko when built as a module.
Oh, I see. I had tried looking for a processor.o after building, to see if
it was something like that, but it still didn't appear. It didn't occur to
me to also try ACPI_PROCESSOR as a module.
I'll go put my head in some sand now.
Thanks,
drew