[PATCH 1/3] Fix: Set data to NULL in hfpmodem drivers
Hi,
The patch is to set data to NULL in hfpmodem drivers.
---
drivers/hfpmodem/network-registration.c |2 ++
drivers/hfpmodem/voicecall.c|3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/hfpmodem/network-registration.c
b/drivers/hfpmodem/network-registration.c
index 13e8628..702b7a9 100644
--- a/drivers/hfpmodem/network-registration.c
+++ b/drivers/hfpmodem/network-registration.c
@@ -333,6 +333,8 @@ static void hfp_netreg_remove(struct ofono_netreg
*netreg)
{
struct netreg_data *nd = ofono_netreg_get_data(netreg);
+ ofono_netreg_set_data(netreg, NULL);
+
g_free(nd);
}
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index 8847985..9ba72e4 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -514,6 +514,9 @@ static void hfp_voicecall_remove(struct
ofono_voicecall *vc)
g_slist_foreach(vd-calls, (GFunc) g_free, NULL);
g_slist_free(vd-calls);
+
+ ofono_voicecall_set_data(vc, NULL);
+
g_free(vd);
}
--
1.6.2.5
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 3/3] Replace parse_clcc by at_util_parse_clcc in atmodem voicecall
Replace parse_clcc by at_util_parse_clcc in atmodem voicecall.
---
drivers/atmodem/voicecall.c | 59
+-
1 files changed, 2 insertions(+), 57 deletions(-)
diff --git a/drivers/atmodem/voicecall.c b/drivers/atmodem/voicecall.c
index 9ed3696..9dae1c8 100644
--- a/drivers/atmodem/voicecall.c
+++ b/drivers/atmodem/voicecall.c
@@ -119,61 +119,6 @@ static struct ofono_call *create_call(struct
voicecall_data *d, int type,
return call;
}
-static GSList *parse_clcc(GAtResult *result)
-{
- GAtResultIter iter;
- GSList *l = NULL;
- int id, dir, status, type;
- struct ofono_call *call;
-
- g_at_result_iter_init(iter, result);
-
- while (g_at_result_iter_next(iter, +CLCC:)) {
- const char *str = ;
- int number_type = 129;
-
- if (!g_at_result_iter_next_number(iter, id))
- continue;
-
- if (!g_at_result_iter_next_number(iter, dir))
- continue;
-
- if (!g_at_result_iter_next_number(iter, status))
- continue;
-
- if (!g_at_result_iter_next_number(iter, type))
- continue;
-
- if (!g_at_result_iter_skip_next(iter))
- continue;
-
- if (g_at_result_iter_next_string(iter, str))
- g_at_result_iter_next_number(iter, number_type);
-
- call = g_try_new0(struct ofono_call, 1);
-
- if (!call)
- break;
-
- call-id = id;
- call-direction = dir;
- call-status = status;
- call-type = type;
- strncpy(call-phone_number.number, str,
- OFONO_MAX_PHONE_NUMBER_LENGTH);
- call-phone_number.type = number_type;
-
- if (strlen(call-phone_number.number) 0)
- call-clip_validity = 0;
- else
- call-clip_validity = 2;
-
- l = g_slist_insert_sorted(l, call, at_util_call_compare);
- }
-
- return l;
-}
-
static void clcc_poll_cb(gboolean ok, GAtResult *result, gpointer
user_data)
{
struct ofono_voicecall *vc = user_data;
@@ -191,7 +136,7 @@ static void clcc_poll_cb(gboolean ok, GAtResult
*result, gpointer user_data)
return;
}
- calls = parse_clcc(result);
+ calls = at_util_parse_clcc(result);
n = calls;
o = vd-calls;
@@ -482,7 +427,7 @@ static void clcc_cb(gboolean ok, GAtResult *result,
gpointer user_data)
goto out;
}
- calls = parse_clcc(result);
+ calls = at_util_parse_clcc(result);
if (calls == NULL) {
CALLBACK_WITH_FAILURE(cb, 0, NULL, cbd-data);
--
1.6.2.5
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH 4/4] Fix: Fill in the phone number info for outgoing call
Hi Denis, Denis Kenzior wrote: Hi Zhenhua, +ofono_voicecall_notify(vc, call); + As I mentioned above, you do not need to do this. oFono will synthesize the outgoing call properly. Worst case we will send a PropertyChanged signal after CLCC is polled and the new number is obtained. I recreate the patch to use the way you mentioned. We notify the voicecall to core after CLCC is polled. Instead of notify it in atd_cb. The comments in patch is also updated. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono Regards, Zhenhua 0001-Fix-Fill-in-the-phone-number-info-for-outgoing-call.patch Description: 0001-Fix-Fill-in-the-phone-number-info-for-outgoing-call.patch ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
ppp
Hello, We need a ppp interface for our modem. I was told on the chat forum that a tap/tun device was to be used. Has anyone else started with this or thought how to implement this? After reading briefly the code from pppd, the implementation, for a first draft, is pretty straight forward (w/o encryption, etc. in userspace). Just dial the apn, and hand over the tty fd to ppp via ioctl. Steps (borrowed from pppd): 1. Dial the apn (in ofonod). 2. Some synchronization code. 3. hand over tty fd to ppp driver via ioctl. the IP. I know i am simplifying the process. Is this the way to go? Regards, Ryan ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/3] Add parse_clcc into atutil.c
Hi Zhenhua, Patch has been applied. Thanks. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: ppp
Hi Ryan, Hello, We need a ppp interface for our modem. I was told on the chat forum that a tap/tun device was to be used. Has anyone else started with this or thought how to implement this? We're currently working on a userspace ppp implementation that will integrate with GAtChat. The goal here is to make it integrate well with the current multiplexed channel capability in GAtMux/GatChat and not need to involve an external daemon. After reading briefly the code from pppd, the implementation, for a first draft, is pretty straight forward (w/o encryption, etc. in userspace). Just dial the apn, and hand over the tty fd to ppp via ioctl. Unfortunately it is not that simple. pppd requires a proper kernel file descriptor to hand off to the kernel ppp line discipline. In our userspace implementation that is not the case. 1 kernel file descriptor is shared by potentially many GAtChat channels using a multiplexing protocol. Hence why we can't reuse the kernel implementation. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 1/2] Rename call to active_call to be more meanful
Rename vd-call to vd-active_call in hfpmodem voicecall.c
---
drivers/hfpmodem/voicecall.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index 9ba72e4..60ac45d 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -53,7 +53,7 @@ static const char *chld_prefix[] = { +CHLD:, NULL };
struct voicecall_data {
GAtChat *chat;
GSList *calls;
- struct ofono_call *call;
+ struct ofono_call *active_call;
unsigned int ag_features;
unsigned int ag_mpty_features;
unsigned char cind_pos[HFP_INDICATOR_LAST];
@@ -103,7 +103,7 @@ static struct ofono_call *create_call(struct
voicecall_data *d, int type,
call-clip_validity = clip;
- d-call = call;
+ d-active_call = call;
return call;
}
@@ -339,8 +339,8 @@ static void release_call(struct ofono_voicecall *vc,
struct ofono_call *call)
vd-calls = g_slist_remove(vd-calls, call);
- if (call == vd-call)
- vd-call = NULL;
+ if (call == vd-active_call)
+ vd-active_call = NULL;
g_free(call);
}
@@ -403,7 +403,7 @@ static void ciev_notify(GAtResult *result, gpointer
user_data)
{
struct ofono_voicecall *vc = user_data;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
- struct ofono_call *call = vd-call;
+ struct ofono_call *call = vd-active_call;
int index;
int value;
GAtResultIter iter;
@@ -491,7 +491,7 @@ static int hfp_voicecall_probe(struct
ofono_voicecall *vc, unsigned int vendor,
vd-chat = data-chat;
vd-ag_features = data-ag_features;
- vd-call = NULL;
+ vd-active_call = NULL;
memcpy(vd-cind_pos, data-cind_pos, HFP_INDICATOR_LAST);
memcpy(vd-cind_val, data-cind_val, HFP_INDICATOR_LAST);
--
1.6.2.5
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 2/2] Refactor code order and remove unusable variables
No impact to code correctness for voicecall.
---
drivers/hfpmodem/voicecall.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index 60ac45d..4b75904 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -99,10 +99,10 @@ static struct ofono_call *create_call(struct
voicecall_data *d, int type,
call-phone_number.type = num_type;
}
- d-calls = g_slist_insert_sorted(d-calls, call,
at_util_call_compare);
-
call-clip_validity = clip;
+ d-calls = g_slist_insert_sorted(d-calls, call,
at_util_call_compare);
+
d-active_call = call;
return call;
@@ -138,8 +138,6 @@ static void atd_cb(gboolean ok, GAtResult *result,
gpointer user_data)
struct ofono_voicecall *vc = cbd-user;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
ofono_voicecall_cb_t cb = cbd-cb;
- int type = 128;
- int validity = 2;
struct ofono_error error;
struct ofono_call *call;
@@ -150,7 +148,7 @@ static void atd_cb(gboolean ok, GAtResult *result,
gpointer user_data)
if (!ok)
goto out;
- call = create_call(vd, 0, 0, CALL_STATUS_DIALING, NULL, type,
validity);
+ call = create_call(vd, 0, 0, CALL_STATUS_DIALING, NULL, 128, 2);
if (!call) {
ofono_error(Unable to allocate call,
@@ -404,8 +402,7 @@ static void ciev_notify(GAtResult *result, gpointer
user_data)
struct ofono_voicecall *vc = user_data;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
struct ofono_call *call = vd-active_call;
- int index;
- int value;
+ int index, value;
GAtResultIter iter;
g_at_result_iter_init(iter, result);
--
1.6.2.5
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Patch on unsupported AT command
Hi all, If some unsupported AT command is issued, different modem may have their own response. Now at my hand is a Huawei modem (EM770W), and it returns COMMAND NOT SUPPORT. In my case, this modem doesn't support AT+CGAUTO=0 in atmodem/gprs.c. Current oFono will hang there for it's not a valid return. We may have some quirk to handle this problem, the same way as current code in network-registration.c with CALYPSO. But I wonder if it's better to add the response string into terminator table, so that we don't need this kind of quirk here and there. I'm not sure if this is the better/best way to handle this problem. After all, the table may become larger and larger is more and more specific terminator like this are added. Comments are welcome! Regards, -Yang 0001-Add-terminator-for-unsupported-AT-command-of-Huawei.patch Description: 0001-Add-terminator-for-unsupported-AT-command-of-Huawei.patch ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
