From: Linus Torvalds <torvalds@linux-foundation.org>
To: Deepak Saxena <dsaxena@plexity.net>
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 8250: Don't restore NS16550 mode when console suspend is disabled
Date: Tue, 12 May 2009 15:00:16 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.2.01.0905121452190.3343@localhost.localdomain> (raw)
In-Reply-To: <20090512210015.GA25540@plexity.net>
On Tue, 12 May 2009, Deepak Saxena wrote:
>
> Commit b5b82df6, from May 2007, breaks no_console_suspend on the OLPC
> XO laptop. Basically what happens is that upon returning from resume,
> serial8250_resume_port() will reconfigure the port for high speed
> mode and all console output will be garbled, making debug of the
> resume path painful. This patch modifies serial8250_resume_port() to
> not touch the port in the case where it is the console port and console
> suspend is disabled.
>
> Signed-off-by: Deepak Saxena <dsaxena@laptop.org>
>
> ---
> The OLPC tree has been carrying a workaround for about two years but
> this patch is not the version we've been using. That one can be
> found at http://dev.laptop.org/~dsaxena/patches/console_suspend_old.patch.
> I prefer the approach of handling this in the 8250 driver itself.
Hmm. I already applied this, but then after looking closer, I undid that.
Why? It looks buggy:
> - if (up->capabilities & UART_NATSEMI) {
> + if ((up->capabilities & UART_NATSEMI) &&
> + (!uart_console(&up->port) && console_suspend_enabled)) {
> unsigned char tmp;
Isn't that second test wrong? Should it not be
if ((up->capabilities & UART_NATSEMI) &&
(console_suspend_enabled || !uart_console(&up->port)) {
instead?
In fact, I'd suggest making a helper function called
"do_suspend_uart(up)", something like
/*
* Suspend the uart port unless it's a console.
*
* But suspend even consoles if "console_suspend_enabled"
* is set.
*/
static inline int do_suspend_uart(struct uart_port *port)
{
return console_suspend_enabled || !uart_console(port);
}
and then make all these things (including the _existing_ cases in
uart_suspend_port() use that helper function, rather than writing it out.
Linus
next prev parent reply other threads:[~2009-05-12 22:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-12 21:00 [PATCH] 8250: Don't restore NS16550 mode when console suspend is disabled Deepak Saxena
2009-05-12 22:00 ` Linus Torvalds [this message]
2009-05-13 0:18 ` Alan Cox
2009-05-13 0:28 ` Deepak Saxena
2009-05-13 8:44 ` Alan Cox
2009-05-13 14:58 ` Linus Torvalds
2009-05-13 15:35 ` Alan Cox
2009-05-13 18:04 ` Deepak Saxena
2009-05-13 18:46 ` Alan Cox
2009-05-18 18:24 ` Deepak Saxena
2009-05-18 19:07 ` Alan Cox
2009-05-13 1:01 ` Joe Perches
2009-05-13 0:34 ` Deepak Saxena
2009-05-12 22:08 ` Michał Mirosław
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=alpine.LFD.2.01.0905121452190.3343@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=dsaxena@plexity.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox