[PATCH] serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c

[PATCH] serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c

[Arjan van de Ven]

From: Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH] serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c

enable_irq_wake() and disable_irq_wake() need to be balanced.
However, serial_core.c calls these for different conditions during
the suspend and resume functions...

This is causing a regular WARN_ON() as found at
http://www.kerneloops.org/search.php?search=set_irq_wake

This patch makes the conditions for triggering the _wake
enable/disable sequence identical.

Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
 drivers/serial/serial_core.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index eab0327..4df9ee1 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -2054,6 +2054,8 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *port)
 int uart_resume_port(struct uart_driver *drv, struct uart_port *port)
 {
 	struct uart_state *state = drv->state + port->line;
+	struct device *tty_dev;
+	struct uart_match match = {port, drv};
 
 	mutex_lock(&state->mutex);
 
@@ -2063,7 +2065,8 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *port)
 		return 0;
 	}
 
-	if (!port->suspended) {
+	tty_dev = device_find_child(port->dev, &match, serial_match_port);
+	if (!port->suspended && device_may_wakeup(tty_dev)) {
 		disable_irq_wake(port->irq);
 		mutex_unlock(&state->mutex);
 		return 0;
-- 
1.5.4.5

Re: [PATCH] serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c

[Andrew Morton]

On Mon, 19 May 2008 20:11:41 -0700
Arjan van de Ven <arjan@linux.intel.com> wrote:

> From: Arjan van de Ven <arjan@linux.intel.com>
> Subject: [PATCH] serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c
> 
> enable_irq_wake() and disable_irq_wake() need to be balanced.
> However, serial_core.c calls these for different conditions during
> the suspend and resume functions...
> 
> This is causing a regular WARN_ON() as found at
> http://www.kerneloops.org/search.php?search=set_irq_wake
> 
> This patch makes the conditions for triggering the _wake
> enable/disable sequence identical.
> 
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
> ---
>  drivers/serial/serial_core.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
> index eab0327..4df9ee1 100644
> --- a/drivers/serial/serial_core.c
> +++ b/drivers/serial/serial_core.c
> @@ -2054,6 +2054,8 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *port)
>  int uart_resume_port(struct uart_driver *drv, struct uart_port *port)
>  {
>  	struct uart_state *state = drv->state + port->line;
> +	struct device *tty_dev;
> +	struct uart_match match = {port, drv};
>  
>  	mutex_lock(&state->mutex);
>  
> @@ -2063,7 +2065,8 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *port)
>  		return 0;
>  	}
>  
> -	if (!port->suspended) {
> +	tty_dev = device_find_child(port->dev, &match, serial_match_port);
> +	if (!port->suspended && device_may_wakeup(tty_dev)) {
>  		disable_irq_wake(port->irq);
>  		mutex_unlock(&state->mutex);
>  		return 0;

erp, is that the easiest way of going from a uart_driver* to a device*?
Doing a lookup each time is a bit unusual.

Re: [PATCH] serial: fix enable_irq_wake/disable_irq_wake imbalance in serial_core.c

[Arjan van de Ven]

Andrew Morton wrote:
>>  	}
>>  
>> -	if (!port->suspended) {
>> +	tty_dev = device_find_child(port->dev, &match, serial_match_port);
>> +	if (!port->suspended && device_may_wakeup(tty_dev)) {
>>  		disable_irq_wake(port->irq);
>>  		mutex_unlock(&state->mutex);
>>  		return 0;
> 
> erp, is that the easiest way of going from a uart_driver* to a device*?
> Doing a lookup each time is a bit unusual.
> 

this is during suspend/resume only, so I figured it wasn't going to be that performance critical;
I wanted the code to be as symmetric as possible rather than fastest..