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:	Tue, 1 May 2012 10:27:58 +1000
From:	NeilBrown <neilb@...e.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-serial@...r.kernel.org,
	linux-pm@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: Question:  How to power-manage UART-attached devices.

On Mon, 30 Apr 2012 16:50:16 -0700 "H. Peter Anvin" <hpa@...or.com> wrote:

> On 04/30/2012 04:47 PM, NeilBrown wrote:
> > 
> > I imagine this proposal as being like a virtual DTR line.  It may
> > not always be appropriate to connect DTR to the power switch, but
> > sometimes it is.
> > 
> 
> Yeah, that's pretty much what I'm suggesting.
> 
> 	-hpa

Yes, so you are :-)

I was distracted by the TIOCPOWER suggestion, and I really didn't want any
new action by user-space, I would much prefer it all "just works".
But you also mentioned "termios flags" but by that I suspect you are
referring to HUPCL which is documented as:

       HUPCL  Lower modem control lines after last process closes  the  device
              (hang up).

without really saying which modem control lines.  Looking at the code it
seems to be talking about DTR and RTS.  It only says "lower on last close"
but doesn't say "raise on first open" but maybe that is assumed.
So as long as HUPCL is the default, defining a virtual DTR line might be just
what I want, and HUPCL could be disabled of someone want to keep the device
powered on while it is closed.

So I think I want to:
 1/ teach omap-serial to drive a given GPIO as a DTR line
 2/ write a 'gpio-regulator' driver which provides a single GPIO and
    turns a given regulator 'on' or 'off' depending on the state of the GPIO
 3/ write a special-purpose GPIO driver which provides a single GPIO
    and toggles another GPIO whenever the state of the first changes, and also
    monitors the serial RX pin when the device should be 'off', and toggles
    again if it sees RX activity.
 4/ Keeping using rfkill to power the GPS antenna.

Sounds like a plan.

Thanks,
NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ