Messages in this thread | | | Subject | Re: [PATCH] cpufreq: mediatek: Fix KP and lockups on proc/sram regulators error | From | Jia-Wei Chang <> | Date | Fri, 23 Sep 2022 14:38:43 +0800 |
| |
On Wed, 2022-09-21 at 12:49 +0530, Viresh Kumar wrote: > Jia, do you want to reply to this thread as the Fixes patch was added > by you ? > > On 09-09-22, 11:37, AngeloGioacchino Del Regno wrote: > > Function regulator_get_optional() returns a negative error number > > on > > any kind of regulator_get() failure: failing to check for that in > > the > > teardown path will lead to a kernel panic due to a call to function > > regulator_disable(). > > I don't see how this can happen. The code does check if the > regulators > are enabled earlier or not. > Hi Angelo,
Could you help provide more details, like the call stack of kernel panic? and how to reproduce this failure?
> > Besides that, the "proc" regulator does actually provide power to > > the > > CPU cluster(s): disabling it will produce a lockup on at least some > > SoCs, such as MT8173. > > We are just dropping the count that we increased earlier, how will > that disable the regulator which was already enabled ? > > > That consideration is also valid for the "sram" regulator, > > providing > > power to the CPU caches instead, present on some other SoCs, such > > as > > MT8183, MT8186 (and others). > > > > Resolve both situations and by simply removing the entire faulty > > branches responsible for disabling the aforementioned regulators if > > enabled, keeping in mind that these are enabled (and left enabled) > > by the bootloader before booting the kernel. > > This looks fishy, we just keep on increasing the ref count of the > regulator but never take it down. > Angelo,
Do you mean the ref count of the regulator in the kernel will be affected if that regulator is enabled earlier in the bootloader?
Thanks.
| |