On Mon, 18 Jan 2016 22:03:19 +0000 One Thousand Gnomes <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: > > > 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
Attachment:
pgpbFoiMkatfW.pgp
Description: OpenPGP digital signature