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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Jul 7, 2021 at 3:13 PM David Heidelberg <david@xxxxxxx> wrote:
>
> Doug,
>
> 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 wonder if changing it to this sequence would fix it?

irq = platform_get_irq(pdev, 0);
request_irq(irq, NULL, 0, "pm8xxx", &pdev->dev);
irq_set_chained_handler_and_data(irq, data->irq_handler, chip);

...or perhaps this sequence (though you'd have to backport IRQF_NO_AUTOEN):

irq = platform_get_irq(pdev, 0);
request_irq(irq, NULL, IRQF_NO_AUTOEN, "pm8xxx", &pdev->dev);
irq_set_chained_handler_and_data(irq, data->irq_handler, chip);
enable_irq(irq);


Of course I'm poking in the dark a bit here. In any case, it does
sound like the patch works OK without your hack patch in place so I
guess the answer is to figure out how to more properly fix the hack
patch. I probably won't be able to help tons there...

-Doug



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux