Kernel Kernel bug caused by (cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()) on Banana Pi R64 (MT7622)

[AngeloGioacchino Del Regno]

Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
> Hi Angelo,
> 
> Jia-wei is working on this issue.
> 
> We will update progress ASAP.
> 

I think I've found something: the MT7622/7623 voltage constraints
set in mediatek-cpufreq's platform data seem to be wrong.

I've sent a commit to fix those [1] and that should solve the issue
that was seen on MT7622, but the code in the voltage tracking algorithm
is unsafe: this crash should be happening because we may be calling
regulator_set_voltage() with max_uV < min_uV --- and this is not legal.

That's happening due to the OPP tables in devicetree asking for a voltage
that is higher than the {proc,sram}_max_volt declared by the platform data
in the mediatek-cpufreq driver: the solution would be to either check the
validity of the constraints everytime se call regulator_set_voltage there,
which wouldn't be optimal IMO, or walk the OPP table at mediatek-cpufreq
probe time (or init time) to either:

1. Print a big warning in kmsg and always ignore all of the OPP entries
    that request a voltage that's higher than the maximum that we declared; or
2. Fail probe/init with an error explicitly saying that the OPP entries
    are declaring an out of range voltage for sram/proc.

Anyway, thanks for the response, hope that Jia-wei confirms, or denies
my findings and makes this driver more robust ASAP.

Thank you!
Angelo

[1]: 
https://lore.kernel.org/lkml/20221202095227.167492-1-angelogioacchino.delregno@collabora.com/

> Thanks,
> Allen
> 
> On Fri, 2022-12-02 at 10:19 +0100, AngeloGioacchino Del Regno wrote:
>> Il 02/12/22 09:57, AngeloGioacchino Del Regno ha scritto:
>>> Il 02/12/22 06:27, Viresh Kumar ha scritto:
>>>> On 01-12-22, 16:39, Thorsten Leemhuis wrote:
>>>>> Thx for clarifying. And I noticed I made a mistake: I should
>>>>> have
>>>>> directed my earlier question wrt to any progress here more into
>>>>> the
>>>>> direction of Jia-Wei Chang (who authored 6a17b3876b) and Viresh
>>>>> Kumar
>>>>> (who committed it).
>>>>
>>>> I was waiting for the platform maintainers to come up with a fix.
>>>> I
>>>> have sent a patch now to revert this, in-reply-to this thread.
>>>>
>>>> Please confirm this is working fine. Thanks.
>>>>
>>>
>>> Can you guys try this patch that I've sent a while ago?
>>>
>>>
> https://lore.kernel.org/lkml/20220909093724.40078-1-angelogioacchino.delregno@collabora.com/T/#u
>>>
>>> There were comments on it, but if that solves your issue I can push
>>> a v2
>>> to solve what was reported.
>>>
>>> Regards,
>>> Angelo
>>
>> Wait, sorry, I've re-read the stacktrace and that won't help at all.
>> MediaTek, can you please look at this issue?
>>
>> Reverting the proposed commit will make MT8183 unstable.
>>
>>