rilmodem/ofono — pull request #80 by tonyespy (2014-04-25 15:01:21+00:00)
Title: Fix parse data call; dynamically set setup_data_call.tech; fix gprs-context event logic

This change started out with a fix for a reported parse failure that showed up during my testing of the new provisioning code. If NM tries to activate a context that the subscriber isn't registered for, the reply to SETUP_DATA_CALL comes back with a status failure set and the rest of the settings as empty strings and/or default values. This caused the grilreply code to report a parse error, and in turn called the high-level rilmodem gprs-atom to try and deactivate the data call ( which would also fail as one had never been activated ).

While working on this change, I noticed a "TODO: consolidate this code with the unsolicited data_call_list changed code", so I did... This necessitated additional driver atom and unit test changes.

This led me to notice that the setup data call logic in gprs-context.c was using a hard-coded value for "tech" ( which was an incorrect value ), so this necessitated further changes to the g_ril_unsol_parse_data_call_list() to not map the low-level RIL RadioTech value into an ofono specific bearer or access tech value. This is now done by the high-level atoms. This now allows gprs-context to query the current gprs data tech value, and use it when initializing the data call.

Finally, while debugging I noticed some weird behavior in gprs-context. As we know have two instances of this atom created per modem, I noticed that both instances were processing unsolicited data call list changes. I changed the code so that the atom only registers for these messages after it's primary context has been activated.

I've tested this code on mako, running image #302.

Testing can be done by following the instructions for the recent provisioning changes ( ie. stop ofono, rm the current SIM's gprs settings file, add -d drivers/rilmodem/gprs-context.c to the ofono command line, and reboot ).

You should no longer see data_reply_parse errors nor deactivate data call errors during provisioning. You also should only see gprs-context messages from one instance after the initial probe calls.