From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 1/3] Add multi calls support for HFP voicecall driver
Date: Wed, 11 Nov 2009 19:21:16 -0600 [thread overview]
Message-ID: <200911111921.17039.denkenz@gmail.com> (raw)
In-Reply-To: <1257578748.2888.16.camel@zzhan17-mobl.ccr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4156 bytes --]
Hi Zhenhua,
>+static void reset_to_single_call(struct voicecall_data *vd)
>+{
>+ struct ofono_call *oc = vd->calls->data;
>+
>+ vd->call = oc;
>+ vd->cind_val[HFP_INDICATOR_CALL] = 1;
>+
>+ if (oc->direction == 1)
>+ vd->cind_val[HFP_INDICATOR_CALLSETUP] = 1;
>+ else
>+ vd->cind_val[HFP_INDICATOR_CALLSETUP] = 3;
>+}
>+
I don't see how this is supposed to work. What if the last call is a held
call?
> + if (c) {
> + nc = c->data;
> +
> + if (memcmp(nc, oc, sizeof(struct ofono_call))) {
> + oc->status = nc->status;
> +
> + /* If phone does not support multiparty call,
> + * there will have only one active call at one
> + * time. +CHUP only hang up current active call.
> + */
> + if (oc->status == CALL_STATUS_ACTIVE)
> + vd->call = oc;
Lets not set this silly variable anymore. It has way too many meanings and
uses throughout the code (most of which can be easily simplified) for the logic
to be understandable.
> +static void hfp_hold_all_active(struct ofono_voicecall *vc,
> + ofono_voicecall_cb_t cb, void *data)
> +{
> + struct voicecall_data *vd = ofono_voicecall_get_data(vc);
> +
> + if (check_mpty_feature(vc, AG_CHLD_2, cb, data)) {
> + hfp_template("AT+CHLD=2", vc, generic_cb, 0, cb, data);
> +
> + /* Some phones fail to send response back after CHLD=2.
> + * But if we have another dialing out call, we should hold
> + * +CLCC until AG creates the new call.
> + */
> + vd->clcc_source = g_timeout_add(POLL_CLCC_INTERVAL,
> + poll_clcc, vc);
This comment makes no sense. If the phone doesn't respond after CHLD=2 the
parser is stuck and we're not sending CLCC out anyway.
> +static void hfp_set_udub(struct ofono_voicecall *vc,
> + ofono_voicecall_cb_t cb, void *data)
> +{
> + unsigned int incoming_or_waiting = (1 << 4) | (1 << 5);
> + struct voicecall_data *vd = ofono_voicecall_get_data(vc);
> + struct ofono_call *call = vd->call;
> + struct release_id_req *req;
> +
> + if (vd->ag_mpty_features & AG_CHLD_0)
> + hfp_template("AT+CHLD=0", vc, generic_cb, incoming_or_waiting,
> + cb, data);
> + else {
> + req = g_try_new0(struct release_id_req, 1);
> +
> + if (!req || !call) {
> + CALLBACK_WITH_FAILURE(cb, data);
> + return;
> + }
> +
> + req->vc = vc;
> + req->cb = cb;
> + req->data = data;
> + req->id = call->id;
> +
> + g_at_chat_send(vd->chat, "AT+CHUP", none_prefix,
> + release_id_cb, req, g_free);
> + }
The core is quite specifically asking to set UDUB, not to hangup the call. If
this is not supported, then we should say so. Please get rid of this.
> +}
> +
> +static void hfp_release_all_active(struct ofono_voicecall *vc,
> + ofono_voicecall_cb_t cb, void *data)
> +{
> + struct voicecall_data *vd = ofono_voicecall_get_data(vc);
> +
> + if (check_mpty_feature(vc, AG_CHLD_1, cb, data)) {
> + hfp_template("AT+CHLD=1", vc, generic_cb, 0x1, cb, data);
> +
> + vd->clcc_source = g_timeout_add(POLL_CLCC_INTERVAL, poll_clcc,
> + vc);
Why are we scheduling the CLCC before the CHLD returned? We should wait until
CHLD fails or succeeds.
> +static void hfp_release_specific(struct ofono_voicecall *vc, int id,
> + ofono_voicecall_cb_t cb, void *data)
> +{
> + if (vd->ag_features & AG_FEATURE_ENHANCED_CALL_CONTROL) {
> + sprintf(buf, "AT+CHLD=1%d", id);
Should we be checking CHLD_1X feature?
> +
> + g_at_chat_send(vd->chat, buf, none_prefix,
> + release_id_cb, req, g_free);
> + } else if (id == (int) vd->call->id)
> + g_at_chat_send(vd->chat, "AT+CHUP", none_prefix,
> + release_id_cb, req, g_free);
In the case of a single active call we already send a CHUP. Is this really
necessary here?
> + else
> + /* If the call is held, swap and then release it */
> + g_at_chat_send(vd->chat, "AT+CHLD=2", none_prefix,
> + swap_hold_cb, req, NULL);
This breaks if the held call is a mpty call, since the entire mpty call is
released. You also can't do this if a waiting call exists.
Regards,
-Denis
next prev parent reply other threads:[~2009-11-12 1:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-07 7:25 [PATCH 1/3] Add multi calls support for HFP voicecall driver Zhenhua Zhang
2009-11-12 1:21 ` Denis Kenzior [this message]
2009-11-12 2:49 ` Zhang, Zhenhua
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200911111921.17039.denkenz@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.