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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Thu, Jul 8, 2021 at 12:50 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> On Wed, Jul 7, 2021 at 3:13 PM David Heidelberg <david@xxxxxxx> wrote:
> >
> > thank you for your reply. Further investigation led me to the "irq:
> > Request and release resources for chained IRQs" (hack) which I used for
> > many previous kernels to avoid fatal panic (at PM8xxx dependent
> > components).
> > It seems it does not only collide with your patch, but also thanks to
> > your fix I can drop it since from 5.10.
> >
> > Only thing which remains is this warning in the place of RCU stall:
> >
> > [ 1.739567] ssbi c00000.ssbi: SSBI controller type: 'pmic-arbiter'
> > [ 1.741905] pm8xxx_probe: PMIC revision 1: F3
> > [ 1.747435] pm8xxx_probe: PMIC revision 2: 0B
> > [ 1.751786] ------------[ cut here ]------------
> > [ 1.756102] WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:3316
> > gpiochip_enable_irq+0xa4/0xa8
>
> OK, I guess this makes sense. I think this WARNING is actually what
> your HACK patch was trying to avoid. Presumably, though, the
> irq_request_resources() in your HACK patch ended up enabling the
> interrupt before the system was ready to handle it.
>
> Looking at pm8xxx_probe(), I guess it's effectively doing this:
>
> irq = platform_get_irq(pdev, 0);
> ...
> irq_set_chained_handler_and_data(irq, data->irq_handler, chip);
>
> ...and the IRQ is actually a GPIO. I guess nowhere in there is the
> interrupt actually requested. I'm actually a little surprised that it
> works but I'm certainly no expert.

I made this alternative solution to the problem but haven't had time to
test it on my board (APQ8060):
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator.git/commit/?h=apq8060-proper-pm8xxx-irq-path

Yours,
Linus Walleij