Thank you Andy and Linus for approving my patch! Hi Bart, could you please apply this patch? Thank you, Asmaa > -----Original Message----- > From: Linus Walleij <linus.walleij@xxxxxxxxxx> > Sent: Monday, June 17, 2024 5:05 AM > To: Asmaa Mnebhi <asmaa@xxxxxxxxxx> > Cc: andy.shevchenko@xxxxxxxxx; bgolaszewski@xxxxxxxxxxxx; linux- > gpio@xxxxxxxxxxxxxxx; David Thompson <davthompson@xxxxxxxxxx> > Subject: Re: [PATCH v2 1/1] gpio: mlxbf3: Support shutdown() function > Importance: High > > On Tue, Jun 11, 2024 at 7:15 PM Asmaa Mnebhi <asmaa@xxxxxxxxxx> > wrote: > > > During Linux graceful reboot, the GPIO interrupts are not disabled. > > Since the drivers are not removed during graceful reboot, the logic to > > call mlxbf3_gpio_irq_disable() is not triggered. > > Interrupts that remain enabled can cause issues on subsequent boots. > > > > For example, the mlxbf-gige driver contains PHY logic to bring up the link. > > If the gpio-mlxbf3 driver loads first, the mlxbf-gige driver will use > > a GPIO interrupt to bring up the link. > > Otherwise, it will use polling. > > The next time Linux boots and loads the drivers in this order, we > encounter the issue: > > - mlxbf-gige loads first and uses polling while the GPIO10 > > interrupt is still enabled from the previous boot. So if > > the interrupt triggers, there is nothing to clear it. > > - gpio-mlxbf3 loads. > > - i2c-mlxbf loads. The interrupt doesn't trigger for I2C > > because it is shared with the GPIO interrupt line which > > was not cleared. > > > > The solution is to add a shutdown function to the GPIO driver to clear > > and disable all interrupts. Also clear the interrupt after disabling it in > mlxbf3_gpio_irq_disable(). > > > > Fixes: 38a700efc510 ("gpio: mlxbf3: Add gpio driver support") > > Signed-off-by: Asmaa Mnebhi <asmaa@xxxxxxxxxx> > > Reviewed-by: David Thompson <davthompson@xxxxxxxxxx> > > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > > Yours, > Linus Walleij