On Sun, Aug 18, 2019 at 6:19 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Note that the gpio_chip structure already has a init_valid_mask > callback which runs after gpiochip_irqchip_init_valid_mask wich > allocs gpio_chip.irq.valid_mask, so we might use that, but: > > That is intended to setup the valid_mask for the pins, not for > the IRQs, which would mean we are abusing it a bit and it runs > after gpiochip_add_irqchip(), which might be too late I guess. Yeah there are two of them which is quite confusing. I am trying to clean up the mess step by step. The initialization of the valid_mask for the pins itself (which is BTW also there for ACPI mainly) is rewritten, I just merged these: https://lore.kernel.org/linux-gpio/20190819084904.30027-1-linus.walleij@xxxxxxxxxx/ https://lore.kernel.org/linux-gpio/20190819091140.622-1-linus.walleij@xxxxxxxxxx/ https://lore.kernel.org/linux-gpio/20190819093058.10863-1-linus.walleij@xxxxxxxxxx/ This makes things a bit clearer, now I "just" need to do the same for the gpio_irq_chip. > So it looks like we need a gpio_chip.irq.init_valid_mask callback > to fix this ordering problem and until this is fixed we should revert > 2e65e0fad935f578e998656d3e7be5a26e072b0e. Do you think this patch, created in response to an ACPI bug in similar vein for PL061 fixes the ordering problem: https://lore.kernel.org/linux-gpio/20190820080527.11796-1-linus.walleij@xxxxxxxxxx/ Just applying it on top and see if the interrups storm is fixed would be super... I actually don't think it is the setting up of .irq.valid_mask after registering the chip that is the problem, but rather the semantic ordering in the gpiochip_add_data_with_key() function that this patch tries to fix. Yours, Linus Walleij
