Linux ACPI
 help / color / mirror / Atom feed
From: "Li,Rongqing" <lirongqing@baidu.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Sunil V L <sunilvl@ventanamicro.com>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Sudeep Holla <Sudeep.Holla@arm.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"Huisong Li" <lihuisong@huawei.com>
Subject: 答复: [外部邮件] Re: [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle
Date: Wed, 24 Jun 2026 01:51:14 +0000	[thread overview]
Message-ID: <731d81865e444be8a9bc07dd121975f3@baidu.com> (raw)
In-Reply-To: <CAJZ5v0j3Wnn3exbji-6PzwjCnOCJDe_pUJU9R25Bhvh1ZE3E5A@mail.gmail.com>

> > The acpi_idle_lpi_enter() function is invoked within the cpuidle path
> > after RCU has already been disabled for the current local CPU.
> > Consequently, ftrace's function_trace_call() expects RCU to be
> > actively watching before recording trace data, emitting a warning if
> > it is not.
> >
> > Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub,
> > and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with
> > __cpuidle. This moves these functions into the '.cpuidle.text'
> > section, implicitly disabling ftrace instrumentation (notrace) along
> > this sensitive path and preventing trace-induced RCU warnings during
> > idle entry.
> >
> > Fixes: a36a7fecfe60 ("ACPI / processor_idle: Add support for Low Power
> > Idle(LPI) states")
> > Signed-off-by: Li RongQing <lirongqing@baidu.com>
> > ---
> > Diff with v1: add __cpuidle to acpi_processor_ffh_lpi_enter
> >
> >  drivers/acpi/processor_idle.c | 4 ++--  drivers/acpi/riscv/cpuidle.c
> > | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/processor_idle.c
> > b/drivers/acpi/processor_idle.c index 390ab5f..4482cf2 100644
> > --- a/drivers/acpi/processor_idle.c
> > +++ b/drivers/acpi/processor_idle.c
> > @@ -1143,7 +1143,7 @@ static int acpi_processor_get_lpi_info(struct
> acpi_processor *pr)
> >         return 0;
> >  }
> >
> > -int __weak acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> > +int __weak __cpuidle acpi_processor_ffh_lpi_enter(struct
> > +acpi_lpi_state *lpi)
> >  {
> >         return -ENODEV;
> >  }
> > @@ -1156,7 +1156,7 @@ int __weak acpi_processor_ffh_lpi_enter(struct
> acpi_lpi_state *lpi)
> >   *
> >   * Return: 0 for success or negative value for error
> >   */
> > -static int acpi_idle_lpi_enter(struct cpuidle_device *dev,
> > +static int __cpuidle acpi_idle_lpi_enter(struct cpuidle_device *dev,
> >                                struct cpuidle_driver *drv, int index)
> > {
> >         struct acpi_processor *pr;
> > diff --git a/drivers/acpi/riscv/cpuidle.c
> > b/drivers/acpi/riscv/cpuidle.c index 624f9bb..c76dbab 100644
> > --- a/drivers/acpi/riscv/cpuidle.c
> > +++ b/drivers/acpi/riscv/cpuidle.c
> > @@ -66,7 +66,7 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
> >         return acpi_cpu_init_idle(cpu);  }
> >
> > -int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
> > +int __cpuidle acpi_processor_ffh_lpi_enter(struct acpi_lpi_state
> > +*lpi)
> >  {
> >         u32 state = lpi->address;
> >
> > --
> 
> Sashiko says that this change may not be sufficient to fully address the issue
> 
> https://sashiko.dev/#/patchset/20260616072617.2272-1-lirongqing%40baidu
> .com
> 
> and that appears to be a valid concern.

Should this fix be placed in a separate patch? CPU_PM_CPU_IDLE_ENTER_PARAM is also invoked by sbi_cpuidle_enter_state, which is itself already annotated with __cpuidle, so this appears to be a pre-existing issue in the RISC-V tree. It would be more appropriate to have RISC-V experts to fix it independently.

Thanks

[Li,Rongqing] 





  reply	other threads:[~2026-06-24  1:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  7:26 [PATCH][v2] ACPI: processor_idle: Mark LPI enter functions as __cpuidle lirongqing
2026-06-16 13:12 ` lihuisong (C)
2026-06-23 13:26 ` Rafael J. Wysocki
2026-06-24  1:51   ` Li,Rongqing [this message]
2026-06-24 13:17     ` [外部邮件] " Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=731d81865e444be8a9bc07dd121975f3@baidu.com \
    --to=lirongqing@baidu.com \
    --cc=Sudeep.Holla@arm.com \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=lihuisong@huawei.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=rafael@kernel.org \
    --cc=sunilvl@ventanamicro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox