Re: [PATCH v2 2/2] cpufreq: qcom-hw: Delay enabling throttle_irq

[Lukasz Luba <lukasz.luba@arm.com>]

On 1/28/22 6:30 PM, Bjorn Andersson wrote:
> On Fri 28 Jan 02:39 PST 2022, Lukasz Luba wrote:
> 
>>
>>
>> On 1/28/22 3:25 AM, Bjorn Andersson wrote:
>>> In the event that the SoC is under thermal pressure while booting it's
>>> possible for the dcvs notification to happen inbetween the cpufreq
>>> framework calling init and it actually updating the policy's
>>> related_cpus cpumask.
>>>
>>> Prior to the introduction of the thermal pressure update helper an empty
>>> cpumask would simply result in the thermal pressure of no cpus being
>>> updated, but the new code will attempt to dereference an invalid per_cpu
>>> variable.
>>
>> Just to confirm, is that per-cpu var the 'policy->related_cpus' in this
>> driver?
>>
> 
> Correct, we boot under thermal pressure, so the interrupt fires before
> we return from "init", which means that related_cpus is still 0.
> 
>>>
>>> Avoid this problem by using the newly reintroduced "ready" callback, to
>>> postpone enabling the IRQ until the related_cpus cpumask is filled in.
>>>
>>> Fixes: 0258cb19c77d ("cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function")
>>
>> You have 'Fixes' tagging here, which might be picked by the stable tree.
>> The code uses the reverted callback .ready(), which might be missing
>> there (since patch 1/2 doesn't have tagging). This patch looks like a
>> proper fix for the root cause.
>>
> 
> Yes, the pair would need to be picked up.
> 
>> Anyway, I'm going to send a patch, which adds a check for null cpumask
>> in the topology_update_thermal_pressure()
>> It was removed after the review comments:
>> https://lore.kernel.org/linux-pm/20211028054459.dve6s2my2tq7odem@vireshk-i7/
>>
> 
> I attempted that in v1:
> https://lore.kernel.org/all/20220118185612.2067031-2-bjorn.andersson@linaro.org/
> 
> And while patch 1 is broken, I think Greg and Sudeep made it clear that
> they didn't want a condition to guard against the caller passing cpus of
> 0.

Thanks for the link, I missed that conversation.

> 
> That's why I in v2 reverted to postpone the thermal pressure IRQ until
> cpufreq is "ready".

Which is fixing the root cause, but involves this backporting
of the new API callback into stable.

Sorry to hear that you had to fight with this tricky mem fault.
There is a 'good' outcome from this: we know that the platform
instantly has thermal issues during boot.

Regards,
Lukasz