linux-kernel - Re: [PATCH] kernel/printk.c: Concerns about the console handover

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64N.0709211454570.2724@blysk.ds.pg.gda.pl>
Date:	Fri, 21 Sep 2007 15:36:05 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Gerd Hoffmann <kraxel@...e.de>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org, Yinghai.Lu@....COM,
	bryan.wu@...log.com, dilinger@...ued.net, kraxel@...hat.com,
	lethal@...ux-sh.org, rgetz@...ckfin.uclinux.org,
	vapier.adi@...il.com
Subject: Re: [PATCH] kernel/printk.c: Concerns about the console handover

On Fri, 21 Sep 2007, Russell King wrote:

> I suspect the correct fix for this is to take the fix in the ARM tree
> for serial_core's console initialisation, and ensure that zs.c handles
> the power management of the port (enabling/disabling transmitter)
> in the power management callback.

 Hmm, it sounds a bit hackish to me.  The serial part is from the 1970s -- 
nobody thought of power management back then.  And even though the 
DECstation is about 20 years younger, it does not provide any means for 
power management either -- it is a workstation/server class system after 
all.

> You can find the fix in the mbox archive:
> 
>  http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cut/arm:devel.mbox

 Hmm, nothing of relevance there.

 I see no problem with implementing the ->pm() call as something like:

void zs_pm(struct uart_port uport, unsigned int state, unsigned int oldstate)
{
	struct zs_port *zport = to_zport(uport);

	if (state < 3)
		zport->regs[5] |= TxENAB;
	else
		zport->regs[5] &= ~TxENAB;
	write_zsreg(zport, R5, zport->regs[5]);
}

itself, but it looks more like a workaround than a fix to me.  I'll have 
to think about it and also double-check it is safe.  The SCC is about as 
complicated as you can get with a serial port.

 Thanks for the hint though.

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