Re: Ofono with Sagem Hilo GPRS

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

Hi Andrew,

> > Seems we try to read EFmwis and get back a '\0' as a response.  This
> > probably stalls the gatchat queue and causes the sim poll timeout to
> > fire.  Or is there something else going on I'm not seeing?
> 
> Yes, it seems there's not much we can do when the queue gets stuck so
> for each of these modems we need a custom driver.  The sim polling
> code thinks the card is dead because it counts the timeout from the
> moment it submits the STATUS poll to the queue, not the moment the
> command is executed.  We need to either disable the polling or start
> timer when the command is sent to modem.

I'm still of the opinion this is not really relevant with today's hardware.  
The modem will be doing its own polling and it makes no sense for the main 
processor to do so as well (power consumption goes through the roof.)  
However, it could be some vendor is actually crazy enough to require it.

> 
> If the device doesn't have a removable card, and there's a
> vendor-specific PROACTIVE COMMAND notification then there's no point
> polling.  If the card is removable and modem doesn't support AT+CSIM,
> we can send the status through AT+CRSM instead, maybe
> atmodem/sim-poll.c should have a quirk for that.

I think we should assume that vendor specific STK notifications and non-
removable cards are the default, not the other way around.

We should keep sim polling out of atgen.  Even initializing the stk atom in 
atgen plugin is wrong due to how wildly different the modem implementations 
are.  People use atgen as the first driver to get started with oFono, so lets 
keep its feature set conservative, or at least add more intelligence into the 
atmodem stk driver.  E.g. if CSIM is not supported / allowed, don't bother 
doing anything.

However, this is now getting off-topic from the original discussion.

Regards,
-Denis