Message ID | 20240402195306.269276-1-andriy.shevchenko@linux.intel.com |
---|---|
Headers | show |
Series | serial: max3100: Put into shape | expand |
On Tue, 2 Apr 2024 22:50:29 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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@linux.intel.com> Reviewed-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> > --- > 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 >
On Tue, Apr 02, 2024 at 10:50:27PM +0300, Andy Shevchenko wrote: > Put the driver into the shape with all new bells and whistles > from the kernel. > > The first three patches marked as fixes, but there is no hurry (as it > was for ages like this in the kernel) to pipe them to stable. That's > why I sent all in one series and it's good for tty-next. > > Tested on Intel Merrifield with MAX3111e connected. > > In v2: > - fixed a few typos in the commit messages (Hugo) > - added an additional fix to patch 2 (Hugo) > - appended tag to patch 13 (Hugo) > - v1 (20240402154219.3583679-1-andriy.shevchenko@linux.intel.com) Only a portion of this series applied to my tree. Can you please rebase and resend the remaining bits? thanks, greg k-h
On Tue, Apr 09, 2024 at 03:52:19PM +0200, Greg Kroah-Hartman wrote: > On Tue, Apr 02, 2024 at 10:50:27PM +0300, Andy Shevchenko wrote: > > Put the driver into the shape with all new bells and whistles > > from the kernel. > > > > The first three patches marked as fixes, but there is no hurry (as it > > was for ages like this in the kernel) to pipe them to stable. That's > > why I sent all in one series and it's good for tty-next. > > > > Tested on Intel Merrifield with MAX3111e connected. > > > > In v2: > > - fixed a few typos in the commit messages (Hugo) > > - added an additional fix to patch 2 (Hugo) > > - appended tag to patch 13 (Hugo) > > - v1 (20240402154219.3583679-1-andriy.shevchenko@linux.intel.com) > > Only a portion of this series applied to my tree. Can you please rebase > and resend the remaining bits? Sure, thanks!
On Tue, Apr 09, 2024 at 04:55:59PM +0300, Andy Shevchenko wrote: > On Tue, Apr 09, 2024 at 03:52:19PM +0200, Greg Kroah-Hartman wrote: > > On Tue, Apr 02, 2024 at 10:50:27PM +0300, Andy Shevchenko wrote: > > > Put the driver into the shape with all new bells and whistles > > > from the kernel. > > > > > > The first three patches marked as fixes, but there is no hurry (as it > > > was for ages like this in the kernel) to pipe them to stable. That's > > > why I sent all in one series and it's good for tty-next. > > > > > > Tested on Intel Merrifield with MAX3111e connected. > > > > > > In v2: > > > - fixed a few typos in the commit messages (Hugo) > > > - added an additional fix to patch 2 (Hugo) > > > - appended tag to patch 13 (Hugo) > > > - v1 (20240402154219.3583679-1-andriy.shevchenko@linux.intel.com) > > > > Only a portion of this series applied to my tree. Can you please rebase > > and resend the remaining bits? > > Sure, thanks! v3 just has been sent: 20240409144721.638326-1-andriy.shevchenko@linux.intel.com