On Mon, 18 Jan 2016 22:03:19 +0000
One Thousand Gnomes [off-list ref] wrote:

quoted

quoted

Your user space can do it (as most Android does).

How can it do it in automatically in a standardized way without need for daemon support?

You don't need to - it can be device specific. In Android it usually is.
I've never understood why low end devices don't also abstract user space
descriptions of power control into DT nodes as well as kernel properties ?

Well, on these android devices, they are only intended to run android and
have another abstraction layer where you can hide things.
If doing actions on opening or closing a tty should not be implemented in
kernel space, then an alternative I see would be to at least have proper
rfkill support for bluetooth and gps in kernel. Then userspace can at least
can talk to a standardised interface. So userspace just has to implement
generic things.

That would mean for the kernel drivers needed:


W2CBW003/bluetooth:
   map the rfkill to just a simple regulator

W2SG0004/gps:
   being notified about incoming data
     a) the nice way: getting it from the tty/tty_port layer
 	(but requiring changes at generic kernel code)
        or
     b) the ugly way:
        remux the data line as a gpio and simply look for state
        changes during rfkill call (probably only during unblock)
	The first characters after power on would probably be lost
        toggle a gpio depending on the desired and detected state

Regards,
Andreas