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

[Thorsten Leemhuis]

On 02.12.22 11:02, AngeloGioacchino Del Regno wrote:
> Il 02/12/22 10:43, Allen-KH Cheng (程冠勳) ha scritto:
>>
>> 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.

Thx for looking into this.
> I've sent a commit to fix those [1]

Quick question: is that relative to apply at this point of the 6.1 devel
cycle? Or would it be better to revert the culprit (already introduced
in 5.19) for now and reapply it together with that fix for 6.2 (and then
backport to 6.1 stable later)?

> 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.

[...]

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

Side note, that patch afaics should have:

Reported-by: Nick <vincent at systemli.org>
Link:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/

To explain: Linus[1] and others considered proper link tags important in
cases like this, as they allow anyone to look into the backstory of a
commit weeks or years later. That's nothing new, the documentation[2]
for some time says to place tags in cases like this. I care personally
(and made it a bit more explicit in the docs a while ago), because these
tags make my regression tracking efforts a whole lot easier, as they
allow my tracking bot 'regzbot' to automatically connect reports with
patches posted or committed to fix tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

[1] for details, see:
https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/

[2] see Documentation/process/submitting-patches.rst
(http://docs.kernel.org/process/submitting-patches.html) and
Documentation/process/5.Posting.rst
(https://docs.kernel.org/process/5.Posting.html)



>> 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.
>>>
>>>

#regzbot monitor:
https://lore.kernel.org/r/930778a1-5e8b-6df6-3276-42dcdadaf682@systemli.org/