[PATCH v2 01/10] Add parser for items next action indicator objects
--- src/stkutil.c | 36 src/stkutil.h |9 + 2 files changed, 45 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index c5e0369..3f7183f 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -67,6 +67,29 @@ static gboolean parse_dataobj_common_bool(struct comprehension_tlv_iter *iter, return TRUE; } +/* For data object that only has a byte array with variable length */ +static gboolean parse_dataobj_common_byte_array( + struct comprehension_tlv_iter *iter, + enum stk_data_object_type type, + unsigned char *array, unsigned int *array_len) +{ + const unsigned char *data; + unsigned int len; + + if (comprehension_tlv_iter_get_tag(iter) != type) + return FALSE; + + len = comprehension_tlv_iter_get_length(iter); + if (len < 1) + return FALSE; + + data = comprehension_tlv_iter_get_data(iter); + *array_len = len; + memcpy(array, data, len); + + return TRUE; +} + /* Defined in TS 102.223 Section 8.1 */ static gboolean parse_dataobj_address(struct comprehension_tlv_iter *iter, void *user) @@ -643,6 +666,17 @@ static gboolean parse_dataobj_network_measurement_results( return TRUE; } +/* Defined in TS 102.223 Section 8.24 */ +static gboolean parse_dataobj_items_next_action_indicator( + struct comprehension_tlv_iter *iter, void *user) +{ + struct stk_items_next_action_indicator *inai = user; + + return parse_dataobj_common_byte_array(iter, + STK_DATA_OBJECT_TYPE_ITEMS_NEXT_ACTION_INDICATOR, + inai->list, &inai->len); +} + /* Defined in TS 102.223 Section 8.31 */ static gboolean parse_dataobj_icon_id(struct comprehension_tlv_iter *iter, void *user) @@ -760,6 +794,8 @@ static dataobj_handler handler_for_type(enum stk_data_object_type type) return parse_dataobj_help_request; case STK_DATA_OBJECT_TYPE_NETWORK_MEASUREMENT_RESULTS: return parse_dataobj_network_measurement_results; + case STK_DATA_OBJECT_TYPE_ITEMS_NEXT_ACTION_INDICATOR: + return parse_dataobj_items_next_action_indicator; case STK_DATA_OBJECT_TYPE_ICON_ID: return parse_dataobj_icon_id; case STK_DATA_OBJECT_TYPE_IMMEDIATE_RESPONSE: diff --git a/src/stkutil.h b/src/stkutil.h index a9495de..c4b8970 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -370,6 +370,15 @@ struct stk_file { }; /* + * According to 102.223 Section 8.24 the length of CTLV is 1 byte. This means + * that the maximum size is 127 according to the rules of CTLVs. + */ +struct stk_items_next_action_indicator { + unsigned char list[127]; + unsigned int len; +}; + +/* * According to 102.223 Section 8.72 the length of text attribute CTLV is 1 * byte. This means that the maximum size is 127 according to the rules * of CTLVs. Empty attribute options will have len of 0. -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 03/10] Add parser for event list objects
--- src/stkutil.c | 12 src/stkutil.h | 33 + 2 files changed, 45 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index 3f7183f..aa57543 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -677,6 +677,16 @@ static gboolean parse_dataobj_items_next_action_indicator( inai->list, &inai->len); } +/* Defined in TS 102.223 Section 8.25 */ +static gboolean parse_dataobj_event_list( + struct comprehension_tlv_iter *iter, void *user) +{ + struct stk_event_list *el = user; + + return parse_dataobj_common_byte_array(iter, + STK_DATA_OBJECT_TYPE_EVENT_LIST, el->list, &el->len); +} + /* Defined in TS 102.223 Section 8.31 */ static gboolean parse_dataobj_icon_id(struct comprehension_tlv_iter *iter, void *user) @@ -796,6 +806,8 @@ static dataobj_handler handler_for_type(enum stk_data_object_type type) return parse_dataobj_network_measurement_results; case STK_DATA_OBJECT_TYPE_ITEMS_NEXT_ACTION_INDICATOR: return parse_dataobj_items_next_action_indicator; + case STK_DATA_OBJECT_TYPE_EVENT_LIST: + return parse_dataobj_event_list; case STK_DATA_OBJECT_TYPE_ICON_ID: return parse_dataobj_icon_id; case STK_DATA_OBJECT_TYPE_IMMEDIATE_RESPONSE: diff --git a/src/stkutil.h b/src/stkutil.h index 0a9c145..12428ca 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -266,6 +266,30 @@ enum stk_tone_type { STK_TONE_TYPE_MELODY_8 =0x47 }; +enum stk_event_type { + STK_EVENT_TYPE_MT_CALL =0x00, + STK_EVENT_TYPE_CALL_CONNECTED = 0x01, + STK_EVENT_TYPE_CALL_DISCONNECTED = 0x02, + STK_EVENT_TYPE_LOCATION_STATUS =0x03, + STK_EVENT_TYPE_USER_ACTIVITY = 0x04, + STK_EVENT_TYPE_IDLE_SCREEN_AVAILABLE = 0x05, + STK_EVENT_TYPE_CARD_READER_STATUS = 0x06, + STK_EVENT_TYPE_LANGUAGE_SELECTION = 0x07, + STK_EVENT_TYPE_BROWSER_TERMINATION =0x08, + STK_EVENT_TYPE_DATA_AVAILABLE = 0x09, + STK_EVENT_TYPE_CHANNEL_STATUS = 0x0A, + STK_EVENT_TYPE_SINGLE_ACCESS_TECHNOLOGY_CHANGE =0x0B, + STK_EVENT_TYPE_DISPLAY_PARAMETERS_CHANGED = 0x0C, + STK_EVENT_TYPE_LOCAL_CONNECTION = 0x0D, + STK_EVENT_TYPE_NETWORK_SEARCH_MODE_CHANGE = 0x0E, + STK_EVENT_TYPE_BROWSING_STATUS =0x0F, + STK_EVENT_TYPE_FRAMES_INFORMATION_CHANGE = 0x10, + STK_EVENT_TYPE_I_WLAN_ACCESS_STATUS = 0x11, + STK_EVENT_TYPE_NETWORK_REJECTION = 0x12, + STK_EVENT_TYPE_HCI_CONNECTIVITY_EVENT = 0x13, + STK_EVENT_TYPE_MULTIPLE_ACCESS_TECHNOLOGIES_CHANGE =0x14 +}; + /* Defined in TS 102.223 Section 8.1 */ struct stk_address { unsigned char ton_npi; @@ -379,6 +403,15 @@ struct stk_items_next_action_indicator { }; /* + * According to 102.223 Section 8.25, there are 21 kinds of event type and no + * one should appear more than once. + */ +struct stk_event_list { + unsigned char list[21]; + unsigned int len; +}; + +/* * According to 102.223 Section 8.72 the length of text attribute CTLV is 1 * byte. This means that the maximum size is 127 according to the rules * of CTLVs. Empty attribute options will have len of 0. -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 04/10] Add parser for cause objects
--- src/stkutil.c | 30 ++ src/stkutil.h |9 + 2 files changed, 39 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index aa57543..14d3999 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -687,6 +687,34 @@ static gboolean parse_dataobj_event_list( STK_DATA_OBJECT_TYPE_EVENT_LIST, el->list, &el->len); } +/* Defined in TS 102.223 Section 8.26 */ +static gboolean parse_dataobj_cause( + struct comprehension_tlv_iter *iter, void *user) +{ + struct stk_cause *cause = user; + const unsigned char *data; + unsigned int len; + + if (comprehension_tlv_iter_get_tag(iter) != STK_DATA_OBJECT_TYPE_CAUSE) + return FALSE; + + len = comprehension_tlv_iter_get_length(iter); + if ((len == 1) || (len > 30)) + return FALSE; + + if (len == 0) { + cause->has_cause = TRUE; + return TRUE; + } + + data = comprehension_tlv_iter_get_data(iter); + cause->len = len; + memcpy(cause->cause, data, len); + cause->has_cause = TRUE; + + return TRUE; +} + /* Defined in TS 102.223 Section 8.31 */ static gboolean parse_dataobj_icon_id(struct comprehension_tlv_iter *iter, void *user) @@ -808,6 +836,8 @@ static dataobj_handler handler_for_type(enum stk_data_object_type type) return parse_dataobj_items_next_action_indicator; case STK_DATA_OBJECT_TYPE_EVENT_LIST: return parse_dataobj_event_list; + case STK_DATA_OBJECT_TYPE_CAUSE: + return parse_dataobj_cause; case STK_DATA_OBJECT_TYPE_ICON_ID: return parse_dataobj_icon_id; case STK_DATA_OBJECT_TYPE_IMMEDIATE_RESPONSE: diff --git a/src/stkutil.h b/src/stkutil.h index 12428ca..e719403 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -412,6 +412,15 @@ struct stk_event_list { }; /* + * According to 102.223 Section 8.26, the maximum length of cause is 30. + */ +struct stk_cause { + unsigned char cause[30]; + unsigned int len; + ofono_bool_t has_cause; +}; + +/* * According to 102.223 Section 8.72 the length of text attribute CTLV is 1 * byte. This means that the maximum size is 127 according to the rules * of CTLVs. Empty attribute options will have len of 0. -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 02/10] Adjust the sequence of comprehension tlv structures
--- src/stkutil.h | 22 +++--- 1 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/stkutil.h b/src/stkutil.h index c4b8970..0a9c145 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -347,17 +347,6 @@ struct stk_result { unsigned char *additional; }; -/* Defined in TS 102.223 Section 8.19 */ -struct stk_location_info { - char mnc[OFONO_MAX_MNC_LENGTH + 1]; - char mcc[OFONO_MAX_MCC_LENGTH + 1]; - unsigned short lac_tac; - ofono_bool_t has_ci; - unsigned short ci; - ofono_bool_t has_ext_ci; - unsigned short ext_ci; -}; - /* Define the struct of single file in TS102.223 Section 8.18. * According to TS 11.11 Section 6.2, each file id has two bytes, and the * maximum Dedicated File level is 2. So the maximum size of file is 8, which @@ -369,6 +358,17 @@ struct stk_file { unsigned int len; }; +/* Defined in TS 102.223 Section 8.19 */ +struct stk_location_info { + char mnc[OFONO_MAX_MNC_LENGTH + 1]; + char mcc[OFONO_MAX_MCC_LENGTH + 1]; + unsigned short lac_tac; + ofono_bool_t has_ci; + unsigned short ci; + ofono_bool_t has_ext_ci; + unsigned short ext_ci; +}; + /* * According to 102.223 Section 8.24 the length of CTLV is 1 byte. This means * that the maximum size is 127 according to the rules of CTLVs. -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 05/10] Add parser for location status objects
--- src/stkutil.c | 30 ++ src/stkutil.h |6 ++ 2 files changed, 36 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index 14d3999..37cb81e 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -67,6 +67,26 @@ static gboolean parse_dataobj_common_bool(struct comprehension_tlv_iter *iter, return TRUE; } +/* For data object that only has one byte */ +static gboolean parse_dataobj_common_byte( + struct comprehension_tlv_iter *iter, void *user, + enum stk_data_object_type type) +{ + char *byte = user; + const unsigned char *data; + + if (comprehension_tlv_iter_get_tag(iter) != type) + return FALSE; + + if (comprehension_tlv_iter_get_length(iter) != 1) + return FALSE; + + data = comprehension_tlv_iter_get_data(iter); + *byte = data[0]; + + return TRUE; +} + /* For data object that only has a byte array with variable length */ static gboolean parse_dataobj_common_byte_array( struct comprehension_tlv_iter *iter, @@ -715,6 +735,14 @@ static gboolean parse_dataobj_cause( return TRUE; } +/* Defined in TS 102.223 Section 8.27 */ +static gboolean parse_dataobj_location_status( + struct comprehension_tlv_iter *iter, void *user) +{ + return parse_dataobj_common_byte(iter, user, + STK_DATA_OBJECT_TYPE_LOCATION_STATUS); +} + /* Defined in TS 102.223 Section 8.31 */ static gboolean parse_dataobj_icon_id(struct comprehension_tlv_iter *iter, void *user) @@ -838,6 +866,8 @@ static dataobj_handler handler_for_type(enum stk_data_object_type type) return parse_dataobj_event_list; case STK_DATA_OBJECT_TYPE_CAUSE: return parse_dataobj_cause; + case STK_DATA_OBJECT_TYPE_LOCATION_STATUS: + return parse_dataobj_location_status; case STK_DATA_OBJECT_TYPE_ICON_ID: return parse_dataobj_icon_id; case STK_DATA_OBJECT_TYPE_IMMEDIATE_RESPONSE: diff --git a/src/stkutil.h b/src/stkutil.h index e719403..00e351b 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -290,6 +290,12 @@ enum stk_event_type { STK_EVENT_TYPE_MULTIPLE_ACCESS_TECHNOLOGIES_CHANGE =0x14 }; +enum stk_service_state { + STK_NORMAL_SERVICE =0x00, + STK_LIMITED_SERVICE = 0x01, + STK_NO_SERVICE =0x02 +}; + /* Defined in TS 102.223 Section 8.1 */ struct stk_address { unsigned char ton_npi; -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 07/10] Add parser for call control requested action objects
--- src/stkutil.c | 20 src/stkutil.h |6 ++ 2 files changed, 26 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index 189d831..c901213 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -753,6 +753,24 @@ static gboolean parse_dataobj_transaction_id( STK_DATA_OBJECT_TYPE_TRANSACTION_ID, ti->list, &ti->len); } +/* Defined in TS 102.223 Section 8.30 */ +static gboolean parse_dataobj_call_control_requested_action( + struct comprehension_tlv_iter *iter, void *user) +{ + struct stk_call_control_requested_action *action = user; + unsigned int len; + + len = comprehension_tlv_iter_get_length(iter); + + action->action = g_try_malloc(len); + if (action->action == NULL) + return FALSE; + + return parse_dataobj_common_byte_array(iter, + STK_DATA_OBJECT_TYPE_CALL_CONTROL_REQUESTED_ACTION, + action->action, &action->len); +} + /* Defined in TS 102.223 Section 8.31 */ static gboolean parse_dataobj_icon_id(struct comprehension_tlv_iter *iter, void *user) @@ -880,6 +898,8 @@ static dataobj_handler handler_for_type(enum stk_data_object_type type) return parse_dataobj_location_status; case STK_DATA_OBJECT_TYPE_TRANSACTION_ID: return parse_dataobj_transaction_id; + case STK_DATA_OBJECT_TYPE_CALL_CONTROL_REQUESTED_ACTION: + return parse_dataobj_call_control_requested_action; case STK_DATA_OBJECT_TYPE_ICON_ID: return parse_dataobj_icon_id; case STK_DATA_OBJECT_TYPE_IMMEDIATE_RESPONSE: diff --git a/src/stkutil.h b/src/stkutil.h index 4c2f195..1eae1cd 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -435,6 +435,12 @@ struct stk_transaction_id { unsigned int len; }; +/* Defined in TS 102.223 Section 8.30 */ +struct stk_call_control_requested_action { + unsigned char *action; + unsigned int len; +}; + /* * According to 102.223 Section 8.72 the length of text attribute CTLV is 1 * byte. This means that the maximum size is 127 according to the rules -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 09/10] Adjust the sequence of icon identifier structure
--- src/stkutil.h | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-) diff --git a/src/stkutil.h b/src/stkutil.h index 0820dda..a3674e4 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -343,15 +343,6 @@ struct stk_ccp { }; /* - * Icon ID denotes a file on the SIM filesystem. Since EF cannot have record - * ids of 0, we use icon_id with 0 to denote empty icon_identifier objects - */ -struct stk_icon_identifier { - unsigned char qualifier; - unsigned char id; -}; - -/* * According to 102.223 Section 8.8 interval values of 0x00 are reserved. * We use this to denote empty duration objects. */ @@ -447,6 +438,16 @@ struct stk_call_control_requested_action { }; /* + * Defined in TS 102.223 Section 8.31 + * Icon ID denotes a file on the SIM filesystem. Since EF cannot have record + * ids of 0, we use icon_id with 0 to denote empty icon_identifier objects + */ +struct stk_icon_identifier { + unsigned char qualifier; + unsigned char id; +}; + +/* * According to 102.223 Section 8.72 the length of text attribute CTLV is 1 * byte. This means that the maximum size is 127 according to the rules * of CTLVs. Empty attribute options will have len of 0. -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 06/10] Add parser for transaction identifier objects
--- src/stkutil.c | 12 src/stkutil.h |9 + 2 files changed, 21 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index 37cb81e..189d831 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -743,6 +743,16 @@ static gboolean parse_dataobj_location_status( STK_DATA_OBJECT_TYPE_LOCATION_STATUS); } +/* Defined in TS 102.223 Section 8.28 */ +static gboolean parse_dataobj_transaction_id( + struct comprehension_tlv_iter *iter, void *user) +{ + struct stk_transaction_id *ti = user; + + return parse_dataobj_common_byte_array(iter, + STK_DATA_OBJECT_TYPE_TRANSACTION_ID, ti->list, &ti->len); +} + /* Defined in TS 102.223 Section 8.31 */ static gboolean parse_dataobj_icon_id(struct comprehension_tlv_iter *iter, void *user) @@ -868,6 +878,8 @@ static dataobj_handler handler_for_type(enum stk_data_object_type type) return parse_dataobj_cause; case STK_DATA_OBJECT_TYPE_LOCATION_STATUS: return parse_dataobj_location_status; + case STK_DATA_OBJECT_TYPE_TRANSACTION_ID: + return parse_dataobj_transaction_id; case STK_DATA_OBJECT_TYPE_ICON_ID: return parse_dataobj_icon_id; case STK_DATA_OBJECT_TYPE_IMMEDIATE_RESPONSE: diff --git a/src/stkutil.h b/src/stkutil.h index 00e351b..4c2f195 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -427,6 +427,15 @@ struct stk_cause { }; /* + * According to 102.223 Section 8.28 the length of CTLV is 1 byte. This means + * that the maximum size is 127 according to the rules of CTLVs. + */ +struct stk_transaction_id { + unsigned char list[127]; + unsigned int len; +}; + +/* * According to 102.223 Section 8.72 the length of text attribute CTLV is 1 * byte. This means that the maximum size is 127 according to the rules * of CTLVs. Empty attribute options will have len of 0. -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 08/10] Add enum for icon qualifier
--- src/stkutil.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/stkutil.h b/src/stkutil.h index 1eae1cd..0820dda 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -296,6 +296,11 @@ enum stk_service_state { STK_NO_SERVICE =0x02 }; +enum stk_icon_qualifier { + STK_ICON_QUALIFIER_TYPE_SELF_EXPLANATORY = 0x00, + STK_ICON_QUALIFIER_TYPE_NON_SELF_EXPLANATORY = 0x01 +}; + /* Defined in TS 102.223 Section 8.1 */ struct stk_address { unsigned char ton_npi; -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v2 10/10] Add parser for item icon identifier list objects
--- src/stkutil.c | 26 ++ src/stkutil.h | 12 2 files changed, 38 insertions(+), 0 deletions(-) diff --git a/src/stkutil.c b/src/stkutil.c index c901213..5b95cba 100644 --- a/src/stkutil.c +++ b/src/stkutil.c @@ -793,6 +793,30 @@ static gboolean parse_dataobj_icon_id(struct comprehension_tlv_iter *iter, return TRUE; } +/* Defined in TS 102.223 Section 8.32 */ +static gboolean parse_dataobj_item_icon_id_list( + struct comprehension_tlv_iter *iter, void *user) +{ + struct stk_item_icon_id_list *iiil = user; + const unsigned char *data; + unsigned int len; + + if (comprehension_tlv_iter_get_tag(iter) != + STK_DATA_OBJECT_TYPE_ITEM_ICON_ID_LIST) + return FALSE; + + len = comprehension_tlv_iter_get_length(iter); + if (len < 2) + return FALSE; + + data = comprehension_tlv_iter_get_data(iter); + iiil->qualifier = data[0]; + iiil->len = len - 1; + memcpy(iiil->list, data + 1, iiil->len); + + return TRUE; +} + /* Defined in 102.223 Section 8.43 */ static gboolean parse_dataobj_imm_resp(struct comprehension_tlv_iter *iter, void *user) @@ -902,6 +926,8 @@ static dataobj_handler handler_for_type(enum stk_data_object_type type) return parse_dataobj_call_control_requested_action; case STK_DATA_OBJECT_TYPE_ICON_ID: return parse_dataobj_icon_id; + case STK_DATA_OBJECT_TYPE_ITEM_ICON_ID_LIST: + return parse_dataobj_item_icon_id_list; case STK_DATA_OBJECT_TYPE_IMMEDIATE_RESPONSE: return parse_dataobj_imm_resp; case STK_DATA_OBJECT_TYPE_TEXT_ATTRIBUTE: diff --git a/src/stkutil.h b/src/stkutil.h index a3674e4..5cb50f1 100644 --- a/src/stkutil.h +++ b/src/stkutil.h @@ -447,6 +447,18 @@ struct stk_icon_identifier { unsigned char id; }; +/* + * According to 102.223 Section 8.32 the length of CTLV is 1 byte. This means + * that the maximum size is 127 according to the rules of CTLVs. This size also + * includes icon list qualifier for 1 byte, so the maxmimum size of icon + * identifier list is 126. + */ +struct stk_item_icon_id_list { + unsigned char qualifier; + unsigned char list[126]; + unsigned int len; +}; + /* * According to 102.223 Section 8.72 the length of text attribute CTLV is 1 * byte. This means that the maximum size is 127 according to the rules -- 1.6.3.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
2010/3/29 Denis Kenzior : >> However, then powering modem down, there are problems. The N900 modem >> control needs to make difference between the state where the modem is >> no more useful and the safe-to-exit state when the power off request >> has been completed, modem has flushed its state to flash and given >> some time to safely turn off the SIM card. > > So if I understand correctly, you are saying that once the powered=off request > has been sent down to the modem, no other requests are valid. In other words, > oFono's current implementation does not remove the atoms until powered=off > request succeeds (which might result in those atoms attempting operations), > which is wrong. That is also a problem. The other problem is that the party controlling the modem power state is supposed to keep GPIO lines in known position for a while after the modem has indicated it has been powered down. In an N900 running maemo, a daemon called sscd does that. sscd exits only after modem has been safely powered down during reboot and shutdown. If ofonod does the controlling, it should hang around after power off for a while, too. Another solution is to use sscd-like daemon also with ofono (the oFono Powered property would then just follow the power state of the modem). >> Also, if an another SetProperty("Powered") call is made while the >> driver is powering the modem on or off, the change is ignored. It >> seems to me that we need more fine grained power control than just the >> current boolean in the core, too. > > We reply with the busy error, you're correct. However, I don't really see > anything better we can do here, do you have any suggestions? Keep the target state around somewhere, or call enable/disable regardless of the current state of the Powered property? -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
2010/3/29 Bastian, Waldo : > Pekka Pessi wrote: >> I've been porting the N900 modem control code to oFono. The semantics >> of Powered is fine with respect of the atoms, in other words, if the >> modem crashes and boots itself, all the atoms are flushed nicely. >> When powering up, the Powered can be set to true when the modem is >> really up and running. > > Do you have an overview of the different modes and transitions that the N900 > modem control is using today? Not really. What do you want to know? There are some design documents describing GPIO line usage, something about SSI used for phonet messages and how modem bootloader interacts with it, and documents about the MTC design and different MTC states. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
ti, 2010-03-30 kello 13:36 +0200, ext Pekka Pessi kirjoitti: > Another solution is to use sscd-like daemon also with ofono (the oFono > Powered property would then just follow the power state of the modem). My preference would be to have these things handled as oFono plugins. That being the recommended way of course doesn't preclude some other modem needing a slave plugin that monitors the accomplishments of a separate daemon. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Updated v2 patches to handle the asynchronized callback
Hi, Please review updated patches. Thanks! ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 1/2] Add server send result code
--- gatchat/gatserver.c | 141 +++ gatchat/gatserver.h | 17 ++ 2 files changed, 137 insertions(+), 21 deletions(-) diff --git a/gatchat/gatserver.c b/gatchat/gatserver.c index c75fbf5..5f21766 100644 --- a/gatchat/gatserver.c +++ b/gatchat/gatserver.c @@ -33,6 +33,8 @@ #include "gatserver.h" #define BUF_SIZE 4096 +/* + the max length of information text + */ +#define MAX_TEXT_SIZE 2052 /* #define WRITE_SCHEDULER_DEBUG 1 */ enum ParserState { @@ -112,9 +114,15 @@ struct _GAtServer { guint max_read_attempts;/* Max reads per select */ enum ParserState parser_state; gboolean destroyed; /* Re-entrancy guard */ + char *last_line;/* Last read line */ + unsigned int cur_pos; /* Read offset of last_line */ + GAtServerResult last_result;/* Last command's result code */ + gboolean final_called; /* Is send_final called */ + gboolean wait_final;/* Wait for final result code */ }; static void g_at_server_wakeup_writer(GAtServer *server); +static void server_parse_line(GAtServer *server); static struct ring_buffer *allocate_next(GAtServer *server) { @@ -156,11 +164,11 @@ static void send_common(GAtServer *server, const char *buf, unsigned int len) g_at_server_wakeup_writer(server); } -static void g_at_server_send_final(GAtServer *server, GAtServerResult result) +static void send_result_common(GAtServer *server, const char *result) + { struct v250_settings v250 = server->v250; - const char *result_str = server_result_to_string(result); - char buf[1024]; + char buf[MAX_TEXT_SIZE]; char t = v250.s3; char r = v250.s4; unsigned int len; @@ -168,19 +176,89 @@ static void g_at_server_send_final(GAtServer *server, GAtServerResult result) if (v250.quiet) return; - if (result_str == NULL) + if (result == NULL) return; if (v250.is_v1) - len = snprintf(buf, sizeof(buf), "%c%c%s%c%c", t, r, result_str, + len = snprintf(buf, sizeof(buf), "%c%c%s%c%c", t, r, result, t, r); else - len = snprintf(buf, sizeof(buf), "%u%c", (unsigned int) result, + len = snprintf(buf, sizeof(buf), "%s%c", result, t); send_common(server, buf, MIN(len, sizeof(buf)-1)); } +static void g_at_server_send_flush(GAtServer *server, GAtServerResult result) +{ + char buf[1024]; + + if (server->v250.is_v1) + sprintf(buf, "%s", server_result_to_string(result)); + else + sprintf(buf, "%u", (unsigned int)result); + + send_result_common(server, buf); +} + +void g_at_server_send_final(GAtServer *server, GAtServerResult result) +{ + server->final_called = TRUE; + server->last_result = result; + + /* Continue to process next command */ + if (result == G_AT_SERVER_RESULT_OK && !server->wait_final) + return; + + if (result != G_AT_SERVER_RESULT_OK) + /* Emit the final result of a command line */ + g_at_server_send_flush(server, result); + else + server_parse_line(server); +} + +void g_at_server_send_ext_final(GAtServer *server, const char *result) +{ + send_result_common(server, result); + + server->final_called = TRUE; + server->wait_final = FALSE; +} + +void g_at_server_send_intermediate(GAtServer *server, const char *result) +{ + send_result_common(server, result); +} + +void g_at_server_send_unsolicited(GAtServer *server, const char *result) +{ + send_result_common(server, result); +} + +void g_at_server_send_info_text(GAtServer *server, GSList *text) +{ + char buf[MAX_TEXT_SIZE]; + char t = server->v250.s3; + char r = server->v250.s4; + unsigned int len; + GSList *l; + + if (!text) + return; + + for (l = text; l; l = l->next) { + char *line = l->data; + if (!line) + return; + + len = snprintf(buf, sizeof(buf), "%c%c%s", t, r, line); + send_common(server, buf, MIN(len, sizeof(buf)-1)); + } + + len = snprintf(buf, sizeof(buf), "%c%c", t, r); + send_common(server, buf, len); +} + static inline gboolean is_extended_command_prefix(const char c) { switch (c) { @@ -203,7 +281,7 @@ static void at_command_notify(GAtServer *server, char *command, node = g_hash_table_lookup(server->command_list, prefix); if (node == NULL) { - g_at_server_send_final(server, G_AT_SERVER_RESULT_ERROR); + g_at_server_send_flush(server, G_AT_SERVER_RESULT_ERROR); return; } @@ -414,32 +49
[PATCH 2/2] Add flag to parse one command line at once
--- gatchat/gatserver.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/gatchat/gatserver.c b/gatchat/gatserver.c index 5f21766..ce78857 100644 --- a/gatchat/gatserver.c +++ b/gatchat/gatserver.c @@ -119,6 +119,7 @@ struct _GAtServer { GAtServerResult last_result;/* Last command's result code */ gboolean final_called; /* Is send_final called */ gboolean wait_final;/* Wait for final result code */ + gboolean parse_ready; /* Ready to parse next line */ }; static void g_at_server_wakeup_writer(GAtServer *server); @@ -199,6 +200,8 @@ static void g_at_server_send_flush(GAtServer *server, GAtServerResult result) sprintf(buf, "%u", (unsigned int)result); send_result_common(server, buf); + + server->parse_ready = TRUE; } void g_at_server_send_final(GAtServer *server, GAtServerResult result) @@ -223,6 +226,7 @@ void g_at_server_send_ext_final(GAtServer *server, const char *result) server->final_called = TRUE; server->wait_final = FALSE; + server->parse_ready = TRUE; } void g_at_server_send_intermediate(GAtServer *server, const char *result) @@ -721,6 +725,7 @@ static void new_bytes(GAtServer *p) p->last_line = extract_line(p); if (p->last_line) { p->cur_pos = 0; + p->parse_ready = FALSE; server_parse_line(p); } else @@ -777,6 +782,10 @@ static gboolean received_data(GIOChannel *channel, GIOCondition cond, g_at_util_debug_chat(TRUE, (char *)buf, rbytes, server->debugf, server->debug_data); + /* Ignore incoming bytes when processing a command line */ + if (!server->parse_ready) + continue; + read_count++; total_read += rbytes; @@ -963,6 +972,7 @@ GAtServer *g_at_server_new(GIOChannel *io) server->ref_count = 1; v250_settings_create(&server->v250); server->channel = io; + server->parse_ready = TRUE; server->command_list = g_hash_table_new_full(g_str_hash, g_str_equal, g_free, at_notify_node_destroy); -- 1.6.6.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Pekka, > That is also a problem. The other problem is that the party > controlling the modem power state is supposed to keep GPIO lines in > known position for a while after the modem has indicated it has been > powered down. In an N900 running maemo, a daemon called sscd does > that. sscd exits only after modem has been safely powered down during > reboot and shutdown. If ofonod does the controlling, it should hang > around after power off for a while, too. So I'm still having trouble understanding the issue. When oFono calls disable, the driver is expected to take all necessary steps to disable the modem. If that means waiting N seconds after the command has been sent, so be it. During shutdown of the daemon, oFonod waits for a grace period and waits on any devices that are being shut down. In effect it "hangs around" after power off. If I'm still on the wrong track, someone please explain it to me better. > > Another solution is to use sscd-like daemon also with ofono (the oFono > Powered property would then just follow the power state of the modem). Automatic powerup is actually possible from the driver. See HFP driver for details. > > We reply with the busy error, you're correct. However, I don't really > > see anything better we can do here, do you have any suggestions? > > Keep the target state around somewhere, or call enable/disable > regardless of the current state of the Powered property? > Note that oFono does not record the powered preferences, ConnMan is responsible for that. Sending a disable when we are already disabled would be wrong and would break some plugins. And I'm still having trouble understanding why you want this. Please give concrete use-cases. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Aki, > > Another solution is to use sscd-like daemon also with ofono (the oFono > > Powered property would then just follow the power state of the modem). > > My preference would be to have these things handled as oFono plugins. > That being the recommended way of course doesn't preclude some other > modem needing a slave plugin that monitors the accomplishments of a > separate daemon. why do we need this at all? Can't your kernel driver take care of this? And obvious second question is why your kernel driver is not integrated with the RFKILL subsystem? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Pekka, > >> I've been porting the N900 modem control code to oFono. The semantics > >> of Powered is fine with respect of the atoms, in other words, if the > >> modem crashes and boots itself, all the atoms are flushed nicely. > >> When powering up, the Powered can be set to true when the modem is > >> really up and running. > > > > Do you have an overview of the different modes and transitions that the > > N900 modem control is using today? > > Not really. What do you want to know? There are some design documents > describing GPIO line usage, something about SSI used for phonet > messages and how modem bootloader interacts with it, and documents > about the MTC design and different MTC states. this really sounds like you guys should implement RFKILL support for the Phonet subsystem. Solving this in userspace is wrong since the GPIO lines are deeply attached to specific hardware design. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Testing asset for oFono
Hi, There are currently a bunch of helper scripts under /test for the D-Bus API in addition to unit tests, and I'm wondering if there are any plans to automate especially the former into a suite that could be run semi-regularly, or even at 'make distcheck'? I think it would be useful to have something like the current scripts, but modified to be actual test cases as well as more easily parametrized. The tests could then be driven with a set of parameters (which cases to run, what numbers to call, etc.) and a default test profile to work with, for example, the default phonesim configuration. Other profiles could then be made for other test environments, such as a live modem and a test network or network simulator. Any thoughts on this? Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 09/10] Adjust the sequence of icon identifier structure
Hi Yang, > --- > src/stkutil.h | 19 ++- > 1 files changed, 10 insertions(+), 9 deletions(-) Please sanity check your patches, while applying I got this: Applying: Add parser for items next action indicator objects Applying: Adjust the sequence of comprehension tlv structures Applying: Add parser for event list objects Applying: Add parser for cause objects Applying: Add parser for location status objects Applying: Add parser for transaction identifier objects Applying: Add parser for call control requested action objects Applying: Add enum for icon qualifier Applying: Adjust the sequence of icon identifier structure /home/denkenz/ofono-master/.git/rebase-apply/patch:38: trailing whitespace. /* fatal: 1 line adds whitespace errors. Patch failed at 0009 Adjust the sequence of icon identifier structure When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". Use [apply] whitespace = error in your git config and apply locally to make sure they do so cleanly. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 01/10] Add parser for items next action indicator objects
Hi Yang, > +/* For data object that only has a byte array with variable length */ > +static gboolean parse_dataobj_common_byte_array( > + struct comprehension_tlv_iter *iter, > + enum stk_data_object_type type, > + unsigned char *array, unsigned int *array_len) > +{ > + const unsigned char *data; > + unsigned int len; > + > + if (comprehension_tlv_iter_get_tag(iter) != type) > + return FALSE; > + > + len = comprehension_tlv_iter_get_length(iter); > + if (len < 1) > + return FALSE; > + > + data = comprehension_tlv_iter_get_data(iter); > + *array_len = len; > + memcpy(array, data, len); > + > + return TRUE; > +} > + So I can see the point of this function for a byte array that requires to be allocated. For fixed size arrays this function is not adequate; it does not do length (boundary) checking for instance. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Denis, 2010/3/30 Denis Kenzior : >> That is also a problem. The other problem is that the party >> controlling the modem power state is supposed to keep GPIO lines in >> known position for a while after the modem has indicated it has been >> powered down. In an N900 running maemo, a daemon called sscd does >> that. sscd exits only after modem has been safely powered down during >> reboot and shutdown. If ofonod does the controlling, it should hang >> around after power off for a while, too. > > So I'm still having trouble understanding the issue. When oFono calls > disable, the driver is expected to take all necessary steps to disable the > modem. If that means waiting N seconds after the command has been sent, so be > it. During shutdown of the daemon, oFonod waits for a grace period and waits > on any devices that are being shut down. In effect it "hangs around" after > power off. >> Another solution is to use sscd-like daemon also with ofono (the oFono >> Powered property would then just follow the power state of the modem). > > Automatic powerup is actually possible from the driver. See HFP driver for > details. > >> > We reply with the busy error, you're correct. However, I don't really >> > see anything better we can do here, do you have any suggestions? >> >> Keep the target state around somewhere, or call enable/disable >> regardless of the current state of the Powered property? >> > > Note that oFono does not record the powered preferences, ConnMan is > responsible for that. > > Sending a disable when we are already disabled would be wrong and would break > some plugins. > > And I'm still having trouble understanding why you want this. Please give > concrete use-cases. Sure. I want Powered-1 that controls the atoms. Atoms should be loaded when modem is in responsive state and removed when, e.g., modem reboots. This we can do now, iow, if you connect a Nokia phone via USB, oFono can follow its state via the MTC indications it sends on top of the phonet link running over USB. I want Powered-2 that controls the modem power. When ofonod starts in N900, it should power up the internal modem. When ofonod terminates itself, it should shut down modem nicely before calling exit(). Now, enable/disable/ofono_modem_set_powered() controls both aspects; I want to separate them. It is also possible to implement Powered-2 in the probe/remove methods; however, they are quite time-consuming operations and best done from the mainloop. It seems to me that Marcel thinks "Powered" should control the RF state, too. So, a separate property for enabling he RF would be nice, too. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Pekka, > >> That is also a problem. The other problem is that the party > >> controlling the modem power state is supposed to keep GPIO lines in > >> known position for a while after the modem has indicated it has been > >> powered down. In an N900 running maemo, a daemon called sscd does > >> that. sscd exits only after modem has been safely powered down during > >> reboot and shutdown. If ofonod does the controlling, it should hang > >> around after power off for a while, too. > > > > So I'm still having trouble understanding the issue. When oFono calls > > disable, the driver is expected to take all necessary steps to disable the > > modem. If that means waiting N seconds after the command has been sent, so > > be > > it. During shutdown of the daemon, oFonod waits for a grace period and > > waits > > on any devices that are being shut down. In effect it "hangs around" after > > power off. > > >> Another solution is to use sscd-like daemon also with ofono (the oFono > >> Powered property would then just follow the power state of the modem). > > > > Automatic powerup is actually possible from the driver. See HFP driver for > > details. > > > >> > We reply with the busy error, you're correct. However, I don't really > >> > see anything better we can do here, do you have any suggestions? > >> > >> Keep the target state around somewhere, or call enable/disable > >> regardless of the current state of the Powered property? > >> > > > > Note that oFono does not record the powered preferences, ConnMan is > > responsible for that. > > > > Sending a disable when we are already disabled would be wrong and would > > break > > some plugins. > > > > And I'm still having trouble understanding why you want this. Please give > > concrete use-cases. > > Sure. > > I want Powered-1 that controls the atoms. Atoms should be loaded when > modem is in responsive state and removed when, e.g., modem reboots. > This we can do now, iow, if you connect a Nokia phone via USB, oFono > can follow its state via the MTC indications it sends on top of the > phonet link running over USB. > > I want Powered-2 that controls the modem power. When ofonod starts in > N900, it should power up the internal modem. When ofonod terminates > itself, it should shut down modem nicely before calling exit(). > > Now, enable/disable/ofono_modem_set_powered() controls both aspects; I > want to separate them. It is also possible to implement Powered-2 in > the probe/remove methods; however, they are quite time-consuming > operations and best done from the mainloop. I am with Denis here. I am missing the point in what you are trying to achieve. The complexity you propose should not be exposed to the applications at all. This can be all handled internally. Or I am missing something essential, but right now, I don't see it. > It seems to me that Marcel thinks "Powered" should control the RF > state, too. So, a separate property for enabling he RF would be nice, > too. That is what I call RFKILL and we have a proper subsystem for that. And it is different from your Power-1 and Power-2 thing? Sorry, but you really lost me now. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Pekka, > Sure. > > I want Powered-1 that controls the atoms. Atoms should be loaded when > modem is in responsive state and removed when, e.g., modem reboots. > This we can do now, iow, if you connect a Nokia phone via USB, oFono > can follow its state via the MTC indications it sends on top of the > phonet link running over USB. > > I want Powered-2 that controls the modem power. When ofonod starts in > N900, it should power up the internal modem. When ofonod terminates > itself, it should shut down modem nicely before calling exit(). So I think I finally understood. What you're trying to achieve is modem presence detection / removal. The equivalent of what udev / modemconf plugins do for oFono. Except that your modem is always present and you need to power it up / down. The answer is that exposing this as a property is not going to happen because it is fundamentally wrong. And in effect it already is exposed, e.g. the fact that modem object is present in oFono. You have several options here: - Create an oFono plugin to listen to an external daemon and create/destroy the modem object appropriately - Create an oFono plugin that will replace the external daemon and create/destroy the modem object appropriately - Implement this properly in the kernel driver and signal device presence via netlink / udev / etc Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
2010/3/30 Marcel Holtmann : >> > So I'm still having trouble understanding the issue. When oFono calls >> > disable, the driver is expected to take all necessary steps to disable the >> > modem. If that means waiting N seconds after the command has been sent, >> > so be >> > it. During shutdown of the daemon, oFonod waits for a grace period and >> > waits >> > on any devices that are being shut down. In effect it "hangs around" after >> > power off. >> >> >> Another solution is to use sscd-like daemon also with ofono (the oFono >> >> Powered property would then just follow the power state of the modem). >> > >> > Automatic powerup is actually possible from the driver. See HFP driver for >> > details. >> > >> >> > We reply with the busy error, you're correct. However, I don't really >> >> > see anything better we can do here, do you have any suggestions? >> >> >> >> Keep the target state around somewhere, or call enable/disable >> >> regardless of the current state of the Powered property? >> >> >> > >> > Note that oFono does not record the powered preferences, ConnMan is >> > responsible for that. >> > >> > Sending a disable when we are already disabled would be wrong and would >> > break >> > some plugins. >> > >> > And I'm still having trouble understanding why you want this. Please give >> > concrete use-cases. >> >> Sure. >> >> I want Powered-1 that controls the atoms. Atoms should be loaded when >> modem is in responsive state and removed when, e.g., modem reboots. >> This we can do now, iow, if you connect a Nokia phone via USB, oFono >> can follow its state via the MTC indications it sends on top of the >> phonet link running over USB. >> >> I want Powered-2 that controls the modem power. When ofonod starts in >> N900, it should power up the internal modem. When ofonod terminates >> itself, it should shut down modem nicely before calling exit(). >> >> Now, enable/disable/ofono_modem_set_powered() controls both aspects; I >> want to separate them. It is also possible to implement Powered-2 in >> the probe/remove methods; however, they are quite time-consuming >> operations and best done from the mainloop. > > I am with Denis here. I am missing the point in what you are trying to > achieve. The complexity you propose should not be exposed to the > applications at all. This can be all handled internally. Or I am missing > something essential, but right now, I don't see it. I'm trying to 1) load atoms only after when isimodem is up and running and reset the state of the isimodem atoms in case the isimodem reboots (or user turns off a Nokia handset connected via USB) 2) have asyncronous probe and remove 3) separate rf state and availablity of the atoms, especially the SIM atoms. With the current enable/disable/ofono_modem_set_powered, I can do 1) or 2), but not both. I can not do 3 at all. >> It seems to me that Marcel thinks "Powered" should control the RF >> state, too. So, a separate property for enabling he RF would be nice, >> too. > > That is what I call RFKILL and we have a proper subsystem for that. Huh? How do you plan to rfkill a modem behind serial line (over bluetooth? over USB? over SSI?)? Should we add a kernel driver for all the modems? How do you plan to solve the interaction between ofonod at commands and the rfkill driver? Phonet is just a glorified serial line with binary protocol. Kernel drivers do not care what is at the other end of that serial line. There are gpio lines to wake up the thing at the end of serial line; gpio lines have their own kernel driver. That is all we need from kernel. -- Pekka.Pessi mail at nokia.com ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi, 2010/3/30 Marcel Holtmann : >> It seems to me that Marcel thinks "Powered" should control the RF >> state, too. So, a separate property for enabling he RF would be nice, >> too. > > That is what I call RFKILL and we have a proper subsystem for that. And > it is different from your Power-1 and Power-2 thing? Sorry, but you > really lost me now. RF is controlled using ISI protocol and the PN_MTC service. Like sending AT+CFUN=1/4 in the ste modem plugin's enable() and disable() ops. I suppose we'll do the same, then, too. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
2010/3/30 Denis Kenzior : > The answer is that exposing this as a property is not going to happen because > it is fundamentally wrong. And in effect it already is exposed, e.g. the fact > that modem object is present in oFono. You have several options here: So I think what you are saying is that if a modem object exists, it is available. That is, the HW has been powered up and initialized properly. And that the Powered property is about whether or not the modem's cellular is active (RF on/off). If this is the case, then I think it'll do. There is a corner case when the modem is borked and cannot be properly powered but needs to be taken to a care point (not that that ever happens IRL ;), and I would rather see this indicated explicitly rather than implicitly by ModemManager returning an empty list of modems. > - Create an oFono plugin to listen to an external daemon and create/destroy > the modem object appropriately This is what we were doing previously with N900: sscd would power up the modem, and we would find out about it via netlink in the isimodem driver. > - Create an oFono plugin that will replace the external daemon and > create/destroy the modem object appropriately ... and this seems like the best way forward here now. > - Implement this properly in the kernel driver and signal device presence via > netlink / udev / etc I don't think this makes sense, really. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Pekka, > >> > So I'm still having trouble understanding the issue. When oFono calls > >> > disable, the driver is expected to take all necessary steps to disable > >> > the > >> > modem. If that means waiting N seconds after the command has been sent, > >> > so be > >> > it. During shutdown of the daemon, oFonod waits for a grace period and > >> > waits > >> > on any devices that are being shut down. In effect it "hangs around" > >> > after > >> > power off. > >> > >> >> Another solution is to use sscd-like daemon also with ofono (the oFono > >> >> Powered property would then just follow the power state of the modem). > >> > > >> > Automatic powerup is actually possible from the driver. See HFP driver > >> > for > >> > details. > >> > > >> >> > We reply with the busy error, you're correct. However, I don't really > >> >> > see anything better we can do here, do you have any suggestions? > >> >> > >> >> Keep the target state around somewhere, or call enable/disable > >> >> regardless of the current state of the Powered property? > >> >> > >> > > >> > Note that oFono does not record the powered preferences, ConnMan is > >> > responsible for that. > >> > > >> > Sending a disable when we are already disabled would be wrong and would > >> > break > >> > some plugins. > >> > > >> > And I'm still having trouble understanding why you want this. Please > >> > give > >> > concrete use-cases. > >> > >> Sure. > >> > >> I want Powered-1 that controls the atoms. Atoms should be loaded when > >> modem is in responsive state and removed when, e.g., modem reboots. > >> This we can do now, iow, if you connect a Nokia phone via USB, oFono > >> can follow its state via the MTC indications it sends on top of the > >> phonet link running over USB. > >> > >> I want Powered-2 that controls the modem power. When ofonod starts in > >> N900, it should power up the internal modem. When ofonod terminates > >> itself, it should shut down modem nicely before calling exit(). > >> > >> Now, enable/disable/ofono_modem_set_powered() controls both aspects; I > >> want to separate them. It is also possible to implement Powered-2 in > >> the probe/remove methods; however, they are quite time-consuming > >> operations and best done from the mainloop. > > > > I am with Denis here. I am missing the point in what you are trying to > > achieve. The complexity you propose should not be exposed to the > > applications at all. This can be all handled internally. Or I am missing > > something essential, but right now, I don't see it. > > I'm trying to > 1) load atoms only after when isimodem is up and running and reset the > state of the isimodem atoms in case the isimodem reboots (or user > turns off a Nokia handset connected via USB) > 2) have asyncronous probe and remove > 3) separate rf state and availablity of the atoms, especially the SIM atoms. > > With the current enable/disable/ofono_modem_set_powered, I can do 1) > or 2), but not both. I can not do 3 at all. non of these should be solved via the D-Bus at all. Really this is internal modem specific details. You are approaching this wrongly. 1) If the modem reboots, then handle this inside the isimodem plugin of oFono. No reason to involve userspace here. If the handset gets turned off, then the modem object just goes away. 2) What do you mean by this. They are asynchronous. 3) I don't understand this. We have pre-sim and post-sim functionality. If you RFKILL a radio it would be same as removing its object path. Or do you wanna access the SIM card while RFKILLed. What is that good for? > >> It seems to me that Marcel thinks "Powered" should control the RF > >> state, too. So, a separate property for enabling he RF would be nice, > >> too. > > > > That is what I call RFKILL and we have a proper subsystem for that. > > Huh? How do you plan to rfkill a modem behind serial line (over > bluetooth? over USB? over SSI?)? Should we add a kernel driver for all > the modems? How do you plan to solve the interaction between ofonod at > commands and the rfkill driver? > > Phonet is just a glorified serial line with binary protocol. Kernel > drivers do not care what is at the other end of that serial line. > There are gpio lines to wake up the thing at the end of serial line; > gpio lines have their own kernel driver. That is all we need from > kernel. This is no reason to not integrate Phonet with RFKILL. RFKILL can kill the radio interface or the whole device. So if it chooses to take the device off the Phonet "bus", then that is fine as well. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
Hi Aki, > 2010/3/30 Denis Kenzior : > > The answer is that exposing this as a property is not going to happen > > because it is fundamentally wrong. And in effect it already is exposed, > > e.g. the fact that modem object is present in oFono. You have several > > options here: > > So I think what you are saying is that if a modem object exists, it is > available. That is, the HW has been powered up and initialized > properly. And that the Powered property is about whether or not the > modem's cellular is active (RF on/off). Powered is about whether the modem is useable. Today we don't make a distinction between tx/rx off with sim, tx/rx off without sim, or fully active. We need to look closely at whether enabling flight mode (e.g. SIM on, while TX/RX is off) makes sense. It is something we should consider, but challenging since most of the SIM attributes are exposed through atoms which won't be generally available when in Flight mode (e.g. SMSC address on SIM atom, MBDN on message waiting, etc) > > If this is the case, then I think it'll do. > > There is a corner case when the modem is borked and cannot be properly > powered but needs to be taken to a care point (not that that ever > happens IRL ;), and I would rather see this indicated explicitly > rather than implicitly by ModemManager returning an empty list of > modems. So finally someone tells me an actual use case, how hard was that? :) It is still possible to expose this information on the interface provided by your custom plugin, I'm against exposing this as a property on Modem interface. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
2010/3/30 Denis Kenzior : > We need to look closely at whether enabling flight mode (e.g. SIM on, while > TX/RX is off) makes sense. It is something we should consider, but > challenging > since most of the SIM attributes are exposed through atoms which won't be > generally available when in Flight mode (e.g. SMSC address on SIM atom, MBDN > on message waiting, etc) I think this is mostly about SIM PIN. For instance, in the N900, PIN is entered very early in the boot process, but RF is activated (Powered=true in oFono) only after the desktop is fully usable. Granted, you could always prompt for the PIN only after the desktop is fully usable, but the point is, this is now the only option you have available with oFono. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not "Powered"
2010/3/30 Marcel Holtmann : >> >> > So I'm still having trouble understanding the issue. When oFono calls >> >> > disable, the driver is expected to take all necessary steps to disable >> >> > the >> >> > modem. If that means waiting N seconds after the command has been >> >> > sent, so be >> >> > it. During shutdown of the daemon, oFonod waits for a grace period and >> >> > waits >> >> > on any devices that are being shut down. In effect it "hangs around" >> >> > after >> >> > power off. >> >> >> >> >> Another solution is to use sscd-like daemon also with ofono (the oFono >> >> >> Powered property would then just follow the power state of the modem). >> >> > >> >> > Automatic powerup is actually possible from the driver. See HFP driver >> >> > for >> >> > details. >> >> > >> >> >> > We reply with the busy error, you're correct. However, I don't >> >> >> > really >> >> >> > see anything better we can do here, do you have any suggestions? >> >> >> >> >> >> Keep the target state around somewhere, or call enable/disable >> >> >> regardless of the current state of the Powered property? >> >> >> >> >> > >> >> > Note that oFono does not record the powered preferences, ConnMan is >> >> > responsible for that. >> >> > >> >> > Sending a disable when we are already disabled would be wrong and would >> >> > break >> >> > some plugins. >> >> > >> >> > And I'm still having trouble understanding why you want this. Please >> >> > give >> >> > concrete use-cases. >> >> >> >> Sure. >> >> >> >> I want Powered-1 that controls the atoms. Atoms should be loaded when >> >> modem is in responsive state and removed when, e.g., modem reboots. >> >> This we can do now, iow, if you connect a Nokia phone via USB, oFono >> >> can follow its state via the MTC indications it sends on top of the >> >> phonet link running over USB. >> >> >> >> I want Powered-2 that controls the modem power. When ofonod starts in >> >> N900, it should power up the internal modem. When ofonod terminates >> >> itself, it should shut down modem nicely before calling exit(). >> >> >> >> Now, enable/disable/ofono_modem_set_powered() controls both aspects; I >> >> want to separate them. It is also possible to implement Powered-2 in >> >> the probe/remove methods; however, they are quite time-consuming >> >> operations and best done from the mainloop. >> > >> > I am with Denis here. I am missing the point in what you are trying to >> > achieve. The complexity you propose should not be exposed to the >> > applications at all. This can be all handled internally. Or I am missing >> > something essential, but right now, I don't see it. >> >> I'm trying to >> 1) load atoms only after when isimodem is up and running and reset the >> state of the isimodem atoms in case the isimodem reboots (or user >> turns off a Nokia handset connected via USB) >> 2) have asyncronous probe and remove >> 3) separate rf state and availablity of the atoms, especially the SIM atoms. >> >> With the current enable/disable/ofono_modem_set_powered, I can do 1) >> or 2), but not both. I can not do 3 at all. > > non of these should be solved via the D-Bus at all. Really this is > internal modem specific details. You are approaching this wrongly. 1) and 2) are already done through D-Bus, only thing is missing is oFono core properly supporting transitions between Powered false and true. > 1) If the modem reboots, then handle this inside the isimodem plugin of > oFono. It is already handled fine in core. isidriver calls ofono_modem_set_powered(false) when it detects that isimodem reboots. When modem is back in business, it calls ofono_modem_set_powered(true). Is there a particular reason why I should reinvent the wheel? >No reason to involve userspace here. If the handset gets turned > off, then the modem object just goes away. What is the difference between modem object not being there at all and modem object being there, but with Powered=false? With the current ofono core, removing the object path will also remove the config information. > 2) What do you mean by this. They are asynchronous. Not in the master branch. enable() and disable() are async, probe() and remove() are sync. How the driver knows if the disable() is called because someone just tried to set Powered=false or if ofonod is terminating? In first case, I just want modem to go standby (and flush the atoms) and keep the SIM warmed up and ready, in the second case, driver should ask modem to do proper power off and then does all the required jazz with the gpio lines. It would be help much if disable() would indicate if "soft" poweroff or "hard" poweroff is required; likewise ofono_modem_set_powered() could take enum with transitional states (powering_on, powered_on, powering_off, powered_off + perhaps something like powered_standby). If you don't feel like doing it, I'm happy to contribute. > 3) I don't understand this. We have pre-sim and post-sim functionality. > If you RFKILL a radio it would be same as r
Re: Access to SIM card when Modem is not "Powered"
Hi Pekka, > >> I'm trying to > >> 1) load atoms only after when isimodem is up and running and reset the > >> state of the isimodem atoms in case the isimodem reboots (or user > >> turns off a Nokia handset connected via USB) > >> 2) have asyncronous probe and remove > >> 3) separate rf state and availablity of the atoms, especially the SIM > >> atoms. > >> > >> With the current enable/disable/ofono_modem_set_powered, I can do 1) > >> or 2), but not both. I can not do 3 at all. > > > > non of these should be solved via the D-Bus at all. Really this is > > internal modem specific details. You are approaching this wrongly. > > 1) and 2) are already done through D-Bus, only thing is missing is > oFono core properly supporting transitions between Powered false and > true. So I just checked again, and we remove all atoms when turning off (even if off subsequently fails). So I really don't see a need to expose the transition (e.g. going up, going down) as a property. How do you want to use this information? > > > 1) If the modem reboots, then handle this inside the isimodem plugin of > > oFono. > > It is already handled fine in core. isidriver calls > ofono_modem_set_powered(false) when it detects that isimodem reboots. > When modem is back in business, it calls > ofono_modem_set_powered(true). > > Is there a particular reason why I should reinvent the wheel? > >From your earlier posts it wasn't clear that you're happy with how this works. > I perceived that there was some issue... > >No reason to involve userspace here. If the handset gets turned > > off, then the modem object just goes away. > > What is the difference between modem object not being there at all and > modem object being there, but with Powered=false? Think of it conceptually as a USB device being in an off state but still on the bus. You still know the device is attached, even if it is of limited use. Remember that we use this to populate remote bluetooth devices, modems configured via modemconf and udev/netlink. This conveys presence and potential usability. > > With the current ofono core, removing the object path will also remove > the config information. What are you using the config information for? It is possible that we should implement ofono_modem_unregister that would keep around the non-driver bits of the modem object. So far I have not done so because I saw no need... > > > 2) What do you mean by this. They are asynchronous. > > Not in the master branch. enable() and disable() are async, probe() > and remove() are sync. probe and remove are sync for a reason, the core is going to become extremely complicated otherwise. Been there and done that, so you better have a very good reason for wanting this. > > How the driver knows if the disable() is called because someone just > tried to set Powered=false or if ofonod is terminating? In first case, > I just want modem to go standby (and flush the atoms) and keep the SIM > warmed up and ready, in the second case, driver should ask modem to do > proper power off and then does all the required jazz with the gpio > lines. It would be help much if disable() would indicate if "soft" > poweroff or "hard" poweroff is required; likewise This can be added, but the question is are you sure you need it? None of the other hardware we have would benefit from this functionality at all. This immediately raises the question of usefulness. Are you sure this isn't better accomplished by a specific plugin for your system as discussed elsewhere in this thread? > ofono_modem_set_powered() could take enum with transitional states > (powering_on, powered_on, powering_off, powered_off + perhaps > something like powered_standby). If you don't feel like doing it, I'm > happy to contribute. Again, usecase please. How are you going to use this information? > > > 3) I don't understand this. We have pre-sim and post-sim functionality. > > If you RFKILL a radio it would be same as removing its object path. Or > > do you wanna access the SIM card while RFKILLed. What is that good for? > > Nobody wants to re-enter the pin code if they exit flight mode. It > should be possible to spool SMSs while the device is in flight mode. > > Is there any good reason to keep SIM offlimits? Please note that if your enable/disable behavior only shuts the rx/tx circuits then repeating PIN entry won't be a problem. And I already commented on this elsewhere in the thread. All I ask is that before we start adding tons of properties we first make sure the user can actually use them intelligently, that there is an actual (not just perceived) use case. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] Fix ignore incoming bytes during parsing
Server processes one command line at one time, so ignore the rest incoming bytes during the command parsing. --- gatchat/gatserver.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/gatchat/gatserver.c b/gatchat/gatserver.c index e04e0d2..911bbef 100644 --- a/gatchat/gatserver.c +++ b/gatchat/gatserver.c @@ -781,6 +781,10 @@ static gboolean received_data(GIOChannel *channel, GIOCondition cond, g_at_util_debug_chat(TRUE, (char *)buf, rbytes, server->debugf, server->debug_data); + /* Ignore incoming bytes when processing a command line */ + if (server->processing_cmdline) + continue; + read_count++; total_read += rbytes; -- 1.6.6.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono