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]
Date:	Wed, 09 Jul 2014 13:35:57 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Tony Lindgren <tony@...mide.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
CC:	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	balbi@...com, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	mika.westerberg@...ux.intel.com
Subject: Re: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm

On 07/09/2014 01:17 PM, Tony Lindgren wrote:
> * One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> [140707 06:22]:
>> On Fri,  4 Jul 2014 18:34:10 +0200
>> Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
>>
>>> While comparing the OMAP-serial and the 8250 part of this I noticed that
>>> the the latter does not use runtime-pm.
>>
>> Yes it does, but 8250 parts (generally - omap presumably is special
>> here ?) need to be powered on to transmit/receive not just for register
>> access. The core uart layer implements a "pm" operation for this.
> 
> At least for omaps the UARTs need to be idled for the SoC to
> hit off-idle where the SoC is powered off and rebooted during
> idle.
>
> So we can certainly enable this in a generic way, however, this
> can only be done under the following conditions:
> 
> 1. We can save and restore the serial register context and detect
>    when context was lost in the serial driver. The context loss
>    can be detected by looking at some registers that are only
>    initialized during init.

A register check on restore context? DLL+DLH might be a good hint here
since its value should be >0 in the running case.

> 
> 2. There's a way for the serial RX pin to wake the SoC. On some
>    omaps there's a separate pin specific wake-up interrupt that
>    can be used for that.

That one would be handled by omap separately.

> 3. The serial PM features must be only enabled if requested by
>    the user via sysfs. Typically extra latency and loss of the
>    first RX character occur which is not acceptable to most
>    applications.

Unless I'm mistaken the omap driver now initializes the timeout to -1.
So nothing happens unless this is enabled separately.

> Regards,
> 
> Tony
> 

Sebastian
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ