Re: [PATCH] pinctrl: mcp23s08: Allocate irq_chip dynamic

[Jan Kundrát]

On pÃtek 8. bÅezna 2019 10:15:50 CET, Linus Walleij wrote:
> On Tue, Mar 5, 2019 at 4:19 PM Jan KundrÃt <jan.kundrat@xxxxxxxxx> wrote:
>
> > This commit should probably go to 5.0-stable and 4.20-stable as well
>
> I doubt that this commit is fixing a regression, but who knows...
> > If I cherry-pick the following two commits to my 5.0, my board boots once
> > again:
> >
> > 16f4372fd7a5 pinctrl: mcp23s08: use struct_size() in devm_kzalloc()
> > 19ab5ca9b77d pinctrl: mcp23s08: Allocate irq_chip dynamic
>
> Hm weird.

My working theory is that this is because I have two physical chips on the 
same SPI CS. If I am correct, it works like this between 4.20 and current 
gpio-next:

- GPIO expander #1 is initialized, including the irqchip
- GPIO expander #2 is initialized, and the irqchip initialization fails
- an interrupt on a shared IRQ line which is common to GPIO expanders #1 
and #2 and one other unrelated device starts to be processed
- GPIO expander #1 says "not mine interrupt"
- GPIO expander #2 attempts to dereference a null pointer becase since 
171948ea33e14, the gpiochip->irq.irq_enable/disable are not initialized

> > As on "why am I hitting this while nobody else did", my board has a shared
> > IRQ line which is active during bootup, perhaps that might have something
> > to do with this -- I don't know.
>
> Sounds like the code in mcp23s08 .probe() should write to all
> registers clearing and disabling interrupts before proceeding to
> request interrupts or register the irqchip, else it will fire immediately
> and cause oopses.

I do not think that this would help me. My IRQ line is shared with another 
chip, so it can be physically asserted even if this particular GPIO 
expander doesn't generate an interrupt.

I suspect that this configuration (multiple MCP23S17 on one SPI CS, and an 
IRQ line shared with something else) is quite rare...

With kind regards,
Jan