[PATCH v2 01/10] Add parser for items next action indicator objects

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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

[Yang Gu]

---
 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"

[Pekka Pessi]

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"

[Pekka Pessi]

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"

[Aki Niemi]

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

[Zhenhua Zhang]

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

[Zhenhua Zhang]

---
 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

[Zhenhua Zhang]

---
 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"

[Denis Kenzior]

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"

[Marcel Holtmann]

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"

[Marcel Holtmann]

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

[Aki Niemi]

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

[Denis Kenzior]

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

[Denis Kenzior]

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"

[Pekka Pessi]

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"

[Marcel Holtmann]

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"

[Denis Kenzior]

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"

[Pekka Pessi]

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"

[Aki Niemi]

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"

[Aki Niemi]

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"

[Marcel Holtmann]

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"

[Denis Kenzior]

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"

[Aki Niemi]

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"

[Pekka Pessi]

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"

[Denis Kenzior]

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

[Zhenhua Zhang]

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