Re: [PATCH 1/1] serial: mcf: Don't take spinlocks in alreadyprotected functions

From: Andrew Morton
Date: Mon Jun 14 2010 - 15:12:33 EST


On Wed, 9 Jun 2010 09:56:26 +0200
ygeorgie@xxxxxxxxx wrote:

> From: Yury Georgievskiy <ygeorgie@xxxxxxxxx>
>
> Don't take the port spinlock in uart functions where the serial core
> already takes care of locking/unlocking them.
>
> The code would actually lock up on architectures where spinlocks are
> implemented.
>
> Also protect calling mcf_rx_chars/mcf_tx_chars in the
> interrupt handler by the port spinlock and use IRQ_RETVAL
> to return from isr.
>

Thanks. Did you runtime test this?

> @@ -368,11 +354,15 @@ static irqreturn_t mcf_interrupt(int irq, void *data)
> unsigned int isr;
>
> isr = readb(port->membase + MCFUART_UISR) & pp->imr;
> +
> + spin_lock(&port->lock);
> if (isr & MCFUART_UIR_RXREADY)
> mcf_rx_chars(pp);
> if (isr & MCFUART_UIR_TXREADY)
> mcf_tx_chars(pp);
> - return IRQ_HANDLED;
> + spin_unlock(&port->lock);
> +
> + return IRQ_RETVAL(isr);
> }

I think this is a little abusive of IRQ_RETVAL. If there are some bits
set in `isr' other than MCFUART_UIR_RXREADY and MCFUART_UIR_TXREADY, we
claim we handled it, only we didn't.

Probably the code works OK, but it all seems a bit uncomfortable.
Perhaps make it more explicit?


--- a/drivers/serial/mcf.c~serial-mcf-dont-take-spinlocks-in-already-protected-functions-fix
+++ a/drivers/serial/mcf.c
@@ -352,17 +352,22 @@ static irqreturn_t mcf_interrupt(int irq
struct uart_port *port = data;
struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
unsigned int isr;
+ irqreturn_t ret = IRQ_NONE;

isr = readb(port->membase + MCFUART_UISR) & pp->imr;

spin_lock(&port->lock);
- if (isr & MCFUART_UIR_RXREADY)
+ if (isr & MCFUART_UIR_RXREADY) {
mcf_rx_chars(pp);
- if (isr & MCFUART_UIR_TXREADY)
+ ret = IRQ_HANDLED;
+ }
+ if (isr & MCFUART_UIR_TXREADY) {
mcf_tx_chars(pp);
+ ret = IRQ_HANDLED;
+ }
spin_unlock(&port->lock);

- return IRQ_RETVAL(isr);
+ return ret;
}

/****************************************************************************/
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/