Re: (probably) Qualcomm PM8xxx PMIC chips driver issue in 5.10+ kernel

[Doug Anderson <dianders@xxxxxxxxxxxx>]

Hi,

On Tue, Jun 29, 2021 at 4:27 PM David Heidelberg <david@xxxxxxx> wrote:
>
> I did bisection and it lead me to the commit
>
> pinctrl: qcom: Don't clear pending interrupts when enabling
> 39afef8a282b8ce63edb8d2ceb8a71e5440de059 for 5.10 (equal to
> cf9d052aa6005f1e8dfaf491d83bf37f368af69e for upstream)
>
> adding people into CC, I assume it's possible it just uncovers
> different issue, but reverting it makes 5.10.y usable.

Sorry that my change is causing problems for you! :(

If I had to guess my intuition would tell me that this is happening:

1. The bootloader on your system is leaving some GPIO interrupt
asserted but masked.

2. Some driver in your system is requesting its interrupt in its probe
call before it's actually ready for the interrupt to fire.

3. Since the driver isn't really ready for the interrupt, it doesn't
clear things properly and the interrupt just keeps firing over and
over again and the system just locks.

It's been several months since I wrote that change, but I believe that
before that change then requesting an interrupt would implicitly "ack"
any pending interrupt and that will no longer be the case now.

Assuming that the above is true then probably the best way to fix it
is to figure out which driver is requesting its irq too early and move
the request to later in its probe.

You might be able to use "initcall_debug" to help find out what driver
is probing. You should also be able to add some printouts to the
pinctrl driver to see what interrupt is actually firing, though it
might be hard to figure out exactly where to put the logs since it
uses a bunch of common code. Hrm, actually, maybe the easiest is to
add a log to msm_gpio_irq_enable(), even just adding a dump_stack() to
that function. If my guess is right then whatever the last stack
dumped would point to the problem.


-Doug