On Tue, 2 Apr 2024 22:50:29 +0300 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > The removal of the last MAX3100 device triggers the removal of > the driver. However, code doesn't update the respective global > variable and after insmod — rmmod — insmod cycle the kernel > oopses: > > max3100 spi-PRP0001:01: max3100_probe: adding port 0 > BUG: kernel NULL pointer dereference, address: 0000000000000408 > ... > RIP: 0010:serial_core_register_port+0xa0/0x840 > ... > max3100_probe+0x1b6/0x280 [max3100] > spi_probe+0x8d/0xb0 > > Update the actual state so next time UART driver will be registered > again. > > Hugo also noticed, that the error path in the probe also affected > by having the variable set, and not cleared. Instead of clearing it > move the assignment after the successfull uart_register_driver() call. > > Fixes: 7831d56b0a35 ("tty: MAX3100") > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Reviewed-by: Hugo Villeneuve <hvilleneuve@xxxxxxxxxxxx> > --- > drivers/tty/serial/max3100.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c > index 45022f2909f0..b3e63b6a402e 100644 > --- a/drivers/tty/serial/max3100.c > +++ b/drivers/tty/serial/max3100.c > @@ -749,13 +749,14 @@ static int max3100_probe(struct spi_device *spi) > mutex_lock(&max3100s_lock); > > if (!uart_driver_registered) { > - uart_driver_registered = 1; > retval = uart_register_driver(&max3100_uart_driver); > if (retval) { > printk(KERN_ERR "Couldn't register max3100 uart driver\n"); > mutex_unlock(&max3100s_lock); > return retval; > } > + > + uart_driver_registered = 1; > } > > for (i = 0; i < MAX_MAX3100; i++) > @@ -841,6 +842,7 @@ static void max3100_remove(struct spi_device *spi) > } > pr_debug("removing max3100 driver\n"); > uart_unregister_driver(&max3100_uart_driver); > + uart_driver_registered = 0; > > mutex_unlock(&max3100s_lock); > } > -- > 2.43.0.rc1.1.gbec44491f096 >