Re: [PATCH 14/15] gatchat: added command completion by timeout

[Denis Kenzior <denkenz@gmail.com>]

Hi Максим,

>>
>> Ok, but which modems?  Do you have an OFONO_AT_DEBUG log trace you
>> can share?
> 
> Similar behavior is observed on simcom modems. There are no logs yet,
> but it clearly shows that there is no response to the command.

A log would be useful to help me understand what is happening.

> 
>> Anyhow, at the very least you need to make this an opt-in
>> feature.  As I pointed
>> out, opting in *all* modem drivers into this functionality will break
>> some of them.
> 
> I can suggest adding a property to the modem driver data that will
> enable this function for it.

Sure, that's fine.

> 
> Multiple commands that are sent over an interface shared with a PPP
> connection. I have a suspicion that when switching from data
> transmission to command processing, the modem does not process AT
> commands through this interface. But the time frame for this switch is
> not clear.

Most devices come setup with 2-3 pre-multiplexed AT command ports.  Most modem 
drivers without a high-speed network interface follow the following pattern:
- One AT command port for most AT commands, always active (Modem)
- One AT command port for PPP.  This port is used to send CGDCONT/CGDATA 
commands and is suspended for the duration of the PPP session (Data)

Are you saying that when the PPP session is ended (NO CARRIER sent?) then 
subsequent commands sent to the Data port time out?  Or what is happening?

>> What you're describing is vendor specific behavior and has to be
>> treated as such.
> 
> How to properly handle a lack of response to a command? Should I add a
> property to the modem driver to enable this feature in GAtChat? Or
> should we separately process the lack of response for those commands
> for which such modem behavior was observed?

I'd like to better understand the problem before offering solutions.  What you 
outline above are all possible strategies.

Regards,
-Denis