serial: 8250: Fix oops for port->pm on uart_change_pm()

Message ID 20230804131553.52927-1-tony@atomide.com
State New
Headers
Series serial: 8250: Fix oops for port->pm on uart_change_pm() |

Commit Message

Tony Lindgren Aug. 4, 2023, 1:15 p.m. UTC
  Unloading a hardware specific 8250 driver can produce error "Unable to
handle kernel paging request at virtual address" about ten seconds after
unloading the driver. This happens on uart_hangup() calling
uart_change_pm().

Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port
specific driver unbind") was only a partial fix. If the hardware specific
driver has initialized port->pm function, we need to clear port->pm too.
Just reinitializing port->ops does not do this. Otherwise serial8250_pm()
will call port->pm() instead of serial8250_do_pm().

Fixes: 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind")
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/tty/serial/8250/8250_port.c | 1 +
 1 file changed, 1 insertion(+)
  

Comments

Andy Shevchenko Aug. 4, 2023, 7:44 p.m. UTC | #1
On Fri, Aug 04, 2023 at 04:15:51PM +0300, Tony Lindgren wrote:
> Unloading a hardware specific 8250 driver can produce error "Unable to
> handle kernel paging request at virtual address" about ten seconds after
> unloading the driver. This happens on uart_hangup() calling
> uart_change_pm().
> 
> Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port
> specific driver unbind") was only a partial fix. If the hardware specific
> driver has initialized port->pm function, we need to clear port->pm too.
> Just reinitializing port->ops does not do this. Otherwise serial8250_pm()
> will call port->pm() instead of serial8250_do_pm().

Oh, good catch!
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
  
Dhruva Gole Aug. 5, 2023, 5:04 a.m. UTC | #2
On Aug 04, 2023 at 16:15:51 +0300, Tony Lindgren wrote:
> Unloading a hardware specific 8250 driver can produce error "Unable to
> handle kernel paging request at virtual address" about ten seconds after
> unloading the driver. This happens on uart_hangup() calling
> uart_change_pm().
> 
> Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port
> specific driver unbind") was only a partial fix. If the hardware specific
> driver has initialized port->pm function, we need to clear port->pm too.
> Just reinitializing port->ops does not do this. Otherwise serial8250_pm()
> will call port->pm() instead of serial8250_do_pm().

Thanks for catching and fixing this!

> 
> Fixes: 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind")
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
>  drivers/tty/serial/8250/8250_port.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -3278,6 +3278,7 @@ void serial8250_init_port(struct uart_8250_port *up)
>  
>  	spin_lock_init(&port->lock);
>  	port->ctrl_id = 0;
> +	port->pm = NULL;

Reviewed-by: Dhruva Gole <d-gole@ti.com>

>  	port->ops = &serial8250_pops;
>  	port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);
>  
> -- 
> 2.41.0
  

Patch

diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -3278,6 +3278,7 @@  void serial8250_init_port(struct uart_8250_port *up)
 
 	spin_lock_init(&port->lock);
 	port->ctrl_id = 0;
+	port->pm = NULL;
 	port->ops = &serial8250_pops;
 	port->has_sysrq = IS_ENABLED(CONFIG_SERIAL_8250_CONSOLE);