On Tue, Mar 12, 2024 at 05:55:49PM +0000, Catalin Marinas wrote:

On Tue, Mar 12, 2024 at 10:06:06AM -0700, Christoph Lameter (Ampere) wrote:

quoted

On Mon, 11 Mar 2024, Christoph Lameter (Ampere) wrote:

quoted

This could be an issue in the ARM64 arch code itself where there maybe
an assumption elsewhere that a cpumask can always store up to NR_CPU
cpus and not only nr_cpu_ids as OFFSTACK does.

How can I exercise the opp driver in order to recreate the problem?

I assume the opp driver is ARM specific? x86 defaults to OFFSTACK so if
there is an issue with OFFSTACK in opp then it should fail with kernel
default configuration on that platform.

I checked the ARM64 arch sources use of NR_CPUS and its all fine.

Also verified in my testing logs that CONFIG_PM_OPP was set in all tests.

No warnings in the kernel log during those tests.

How to reproduce this?

I guess you need a platform with a dts that has an "operating-points-v2"
property. I don't have any around.

Sudeep was trying to trigger this code path earlier, not sure where he
got to.

I did try to trigger this on FVP by adding OPPs + some hacks to add dummy
clock provider to successfully probe this driver. I couldn't hit the issue
reported 🙁. It could be that with the hardware clock/regulator drivers, it
take a different path in OPP core.

--
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel