[PATCH 2/3] arm64: smp: Implement cpus_has_pending_ipi()

Ulf Hansson ulf.hansson at linaro.org
Fri Oct 10 01:03:47 PDT 2025


On Mon, 6 Oct 2025 at 16:41, Sudeep Holla <sudeep.holla at arm.com> wrote:
>
> On Mon, Oct 06, 2025 at 02:22:49PM +0200, Ulf Hansson wrote:
> > On Mon, 6 Oct 2025 at 12:54, Sudeep Holla <sudeep.holla at arm.com> wrote:
> > >
> > > 2. I understand this is intended for the DragonBoard 410c, where the firmware
> > >    can’t be updated. However, ideally, the PSCI firmware should handle checking
> > >    for pending IPIs if that’s important for the platform. The firmware could
> > >    perform this check at the CPU PPU/HW level and prevent entering the
> > >    state if needed.
> >
> > I think this is exactly what is happening on Dragonboard 410c (see the
> > stats I shared in the commit message in patch3).
> >
> > The PSCI FW refuses to enter the suggested idlestate and the call fails.
> >
>
> Ah OK, the PSCI FW is doing the job correctly, we are just attempting to
> reduce the failures by catching few cases earlier in the OSPM itself ?

Correct!

> Sure it only reduces the failures but it can't eliminate those as IPI might
> be issued after this check in the OSPM. I understand the call to firmware
> can be prevented.

Yes!

Although, it seems we are ending up doing a ping-pong game with the
FW. Note that, if the FW responds with an error because we have tried
to enter an idlestate for a group of CPUs, nothing prevents idling the
CPU again and hence we might re-try with the same idlestate (at least
until the pending IPI gets delivered).

My point is, this problem seems not negligible, as you can see from
the stats I have shared in the commit message of patch3.

Kind regards
Uffe



More information about the linux-arm-kernel mailing list