Re: 8250 Serial console unusable

[Stanislav Brabec <sbrabec@suse.cz>]

Daniel Drake wrote:
> It
> looks like Stanislav works with machines with a similar requirement,
> which I guess suffer the same problem in Linus master:

Zaurus machines. Well, the current vanilla does not work with
no_console_suspend on Zaurus as well.

Changing
if (console_suspend_enabled || !uart_console(uport)) {
in resume process just above the line
/* Protected by port mutex for now */
to
if (1) {
makes resume working with no_console_suspend again. So one of lines
inside does something important.

I never sent this patch to the list, because I suspect, that would break
other machines in this simple stupid form.

> What's the right way to go around solving this, that doesn't step on
> anyones toes?

Try to find exact instruction that needs to be called. See the topic
"[PATCH RESEND 0/2] two serial_core suspend/resume fixes".

> From an ignorant high-level perspective, it doesn't sound unreasonable
> or complicated to simply unconditionally restore the correct port
> configuration on resume. I'm having trouble understanding the argument
> against this perspective presented in commit 891b9dd10.

You cannot do it. There may exist a hardware, where resume depends on
suspend previously called. But it does not happen with
no_console_suspend. You have to find a subset, that is able to set
console to working state without suspend/resume disparity.

Maybe adding non-stopping save/restore in addition to suspend/resume in
all drivers may be cleaner solution.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec@suse.cz
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html