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@xxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
