From: Darren Hart <dvhart@linux.intel.com>
To: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Feng Tang <feng.tang@intel.com>,
Alexander Stein <alexander.stein@systec-electronic.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Cox <alan@linux.intel.com>,
linux-serial@vger.kernel.org
Subject: Re: [RFC PATCH] pch_uart: Add eg20t_port lock field, avoid recursive spinlocks
Date: Fri, 01 Jun 2012 11:36:29 -0700 [thread overview]
Message-ID: <4FC90BAD.3080606@linux.intel.com> (raw)
In-Reply-To: <CANKRQnhZErpvcsRW3ukNzY0_zv4x=5OzQ-sr+aeuxL63=tQ=4A@mail.gmail.com>
On 06/01/2012 01:30 AM, Tomoya MORINAGA wrote:
> On Thu, May 31, 2012 at 5:54 PM, Darren Hart <dvhart@linux.intel.com> wrote:
>> @@ -1376,7 +1379,8 @@ static void pch_uart_set_termios(struct uart_port *port,
>>
>> baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk / 16);
>>
>> - spin_lock_irqsave(&port->lock, flags);
>> + spin_lock_irqsave(&priv->lock, flags);
>> + spin_lock(&port->lock);
>>
>> uart_update_timeout(port, termios->c_cflag, baud);
>> rtn = pch_uart_hal_set_line(priv, baud, parity, bits, stb);
>> @@ -1389,7 +1393,8 @@ static void pch_uart_set_termios(struct uart_port *port,
>> tty_termios_encode_baud_rate(termios, baud, baud);
>>
>> out:
>> - spin_unlock_irqrestore(&port->lock, flags);
>> + spin_unlock(&port->lock);
>> + spin_unlock_irqrestore(&priv->lock, flags);
>> }
>
> Are both port->lock and priv->lock really necessary ?
The priv lock protects the pch_uart_hal* calls and the io access.
The port lock protects the uart_update_timeout call. I'm assuming the
8250.c driver is correct in holding the port lock before making this
call and making other modifcations to the port struct.
So yes, I believe both are required. The port->lock was used as the lock
to protect the private data in the interrupt handler,
pch_uart_interrupt. If we could avoid holding that lock across the
entire function, limiting it to just around the pch_uart_hal calls
(perhaps by adding it to the hal calls and adding lockless __pch_uart*
calls) we could avoid the recursive lock that occurs with handle_rx. I
still think a priv-lock is a good idea though, even if just to clarify
what is being protected.
Thoughts?
>
>
>> @@ -1572,7 +1578,9 @@ pch_console_write(struct console *co, const char *s, unsigned int count)
>>
>> if (locked)
>> spin_unlock(&priv->port.lock);
>> + spin_unlock(&priv->lock);
>> local_irq_restore(flags);
>> +
>> }
>
> Looks spare blank line.
Thanks, will fix for V2 after this discussion wraps up.
>
> thanks.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2012-06-01 18:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-31 8:54 [RFC PATCH] pch_uart: Add eg20t_port lock field, avoid recursive spinlocks Darren Hart
2012-06-01 8:30 ` Tomoya MORINAGA
2012-06-01 8:30 ` Tomoya MORINAGA
2012-06-01 18:36 ` Darren Hart [this message]
2012-06-05 22:07 ` Darren Hart
2012-06-05 23:48 ` Tomoya MORINAGA
2012-06-18 21:41 ` Darren Hart
2012-06-18 22:21 ` Greg Kroah-Hartman
2012-06-19 9:14 ` Alan Cox
2012-06-19 17:35 ` Darren Hart
2012-06-19 17:54 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FC90BAD.3080606@linux.intel.com \
--to=dvhart@linux.intel.com \
--cc=alan@linux.intel.com \
--cc=alexander.stein@systec-electronic.com \
--cc=feng.tang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=tomoya.rohm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.