RFC: GSM flowcontrol handling, GTA01 and GTA02

[Mike (mwester)]

Werner Almesberger wrote:
> Mike (mwester) wrote:
...
>> So, since my preferred solution (TERMIO mechanism) won't ever make it 
>> upstream, and nobody actually implements that in user-space anyway, it 
>> seems that the sysfs-based solution is the one that wins by default
> 
> Hmm, you mean that the ugliness is in the semantics of having crtscts
> set (thus telling the serial subsystem that we want it to be in charge
> of handling RTS) _and_ TIOCMBIx'ing TIOCM_RTS (thus changing RTS
> "manually", hoping that the serial subsystem won't override this in
> the next microsecond) ?

Actually, I'm not even that far along.  I'm only referring to the GTA0x-specific 
implementation that I put together -- it does exactly what we need for the GTA01 
and GTA02, but nothing more.  The s3c24xx serial driver has absolutely no code 
to manage RTS and CTS at all.  So as written, the patch I put together would not 
be accepted upstream since it is not complete nor does it completely follow the 
expected behavior (for example, it leaves (and actually relies on) crtscts mode 
being set *while* we override the RTS signal).

One could fix all of that, I expect -- by adding full support for the RTS and 
CTS signals to the driver, and then addressing the resulting potential race 
conditions that, as you described in detail, will result.  But frankly, I don't 
see that as a good use of time when we can just leave the serial driver 
untouched and accomplish the same end goal in neo1973_pm_gsm.c.  All we really 
want is to leave the UART in auto-flowcontrol mode, but override the RTS line by 
switching it to GPIO mode.  A dozen lines of code in neo-specific source, versus 
some unknown amount of code with sweeping impact to all users of s3cx24xx 
devices? -- I've switched from my original position to support the more 
practical solution :-)

...

>> Or, we could signal both, I 
>> suppose, with multiple asterisks in the wakeup reason?
> 
> That looks like the most logical solution, yes.
> 
>> Perhaps we really don't need to worry about this at this time
> 
> Yeah, I think the wakeup reason isn't something an application should
> actually try to make sense of. Since many of the events there could
> happen while suspended and while awake, there must be a mechanism to
> signal that event already. So this mechanism should just signal it
> after the resume. Anything else is likely to lead to race condition hell.

It's easy to remove the sysfs entry; that's a half-dozen lines of code in 
neo1973_pm_gsm.c that can be pulled out at any point.  But I'd love to hear the 
opinion from the folks working on the user-space stuff, especially the next 
generation replacements for neod and gsmd -- do they need anything from the 
kernel, and if so, how would they like to see it?  Who was going to use the 
wakeup reason interface, and is the GSM wakeup one of those of interest?

> - Werner

Mike (mwester)