[Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Am 21.01.2016 um 14:39 schrieb Radek Polak <psonek2 at seznam.cz>:

> On Thursday 21 of January 2016 13:05:27 Andreas Kemnade wrote:
>  
> > I must admit that I have never used qtmoko kernels because of that initramfs
> > because I do not want to /dev/mmcblk0p1 to be touched by anything
> > automatically. Just because power might end at a bad moment and there might
> > be no bootable kernel.
>  
> Well i dont think it's the case. The gta04-init mounts only the partition that you tell it to mount (e.g. via config file, or touch screen) and boots into it. Just the mount command is done from userspace and can be very nicely customized compared to "stupid" root kernel option.
>  
> Btw there was talk about "daemon" but daemon is IMO not needed at all, just single check during init that GPS is powered off.

Yes, there is a difference to a daemon: a daemon runs forever and this runs only once.
Unless someone is wrongly handling the gpio. I.e. a process that did crash.

>  
> > Well the problem is solved in some way. It is just about getting the
> > solutions accepted. That takes energy and if successful not only solves
> > GTA04 stuff but also other solutions. But that is the general problem of
> > upstreaming. You have your working solution and then put extra energy into
> > it which does often not give anything as reward (in short term).
>  
> Yup understand. But i could understand if the upstreaming is rejected.  Growing general kernel code because of 100 users while there is simple userspace solution...

Well, there is a simple user space solution for a lot of garbage in the kernel...

But this is the solution: we need to grow number of users :)

>  
> > > The real problem is e.g. that my Nokia N900 eats 3mA in suspend and
> > > lasts 6day, while GTA04 eats 25mA and needs recharging every day. I
> > > personally dont care if turning GPS on/off is 10 lines of code in
> > > userspace
> > > or 40 lines of code in kernel.
> > 
> > Well, I prefer working, standard interfaces. If the general rule is that
> > kernel is powering down things which are not used, than I want that.
> > Another solution I could life if rfkill can at least do everything.
>  
> Agree that toggling rfkill during init should be easily doable for any userspace. 

Yes, but again: we have a working solution that is better. So it is waste of time to
think about yet another.

BTW: if I remember correctly, some RFKILL solution was also rejected by
kernel maintainers, because RFKILL means RF kill but not "turn device on/off".

The result is that same that you don#t get data... But it shows how nit-picking it
might be to get things into the kernel. Especially if they don't like that you come
and disturb their circles...

BR,
Nikolaus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20160121/a895ab9b/attachment.html>