RE: [PATCH v2 1/1] gpio: mlxbf3: Support shutdown() function

[Asmaa Mnebhi <asmaa@xxxxxxxxxx>]

Thank  you very much!

> -----Original Message-----
> From: Bartosz Golaszewski <brgl@xxxxxxxx>
> Sent: Saturday, August 10, 2024 3:36 PM
> To: andy.shevchenko@xxxxxxxxx; linus.walleij@xxxxxxxxxx; linux-
> gpio@xxxxxxxxxxxxxxx; Bartosz Golaszewski <brgl@xxxxxxxx>; Asmaa Mnebhi
> <asmaa@xxxxxxxxxx>
> Cc: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>; David Thompson
> <davthompson@xxxxxxxxxx>
> Subject: Re: [PATCH v2 1/1] gpio: mlxbf3: Support shutdown() function
> Importance: High
> 
> From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
> 
> 
> On Tue, 11 Jun 2024 13:15:09 -0400, Asmaa Mnebhi 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.
> >
> > [...]
> 
> Applied, thanks!
> 
> [1/1] gpio: mlxbf3: Support shutdown() function
>       commit: aad41832326723627ad8ac9ee8a543b6dca4454d
> 
> Best regards,
> --
> Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>