All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH_v0 1/5] doc: Add bearer property
Date: Fri, 02 Dec 2011 06:10:17 -0600	[thread overview]
Message-ID: <4ED8C029.80808@gmail.com> (raw)
In-Reply-To: <4EDC9F8D.30107@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Hi Guillaume,

>> The 1X and EVDO registration status is already handled by the
>> NetworkRegistration interface (namely Strength for 1X and DataStrength
>> for EV-DO).
> 
> As we propose this "bearer" property for GSM into connman-api.txt, why
> don't we for CDMA?
> It would be easier to have same property in GSM and CDMA to recover the
> info at network panel level for instance to display technology used.

Because Bearer property for ConnectionManager for GSM is different.  It
is a dynamic property that changes based on network resource allocation.
 The NetworkRegistration Technology property is simply an indication of
what technology the network cell supports.  Hence the rather different
set of values between the two.

> 
> We have the same kind of information into network.c namely "technology",
> should we add this property also into cdma-netreg.c?
> I saw it in a TODO into network-api.txt:
> [...]
> string Technology [readonly, optional]
> 
>             Contains the technology of the current network.
> 
>             The possible values are: "gsm", "edge", "umts", "hspa",
>                             "lte"
> 
>             TODO: Values for CDMA and EVDO based networks.
> [...]
> We have to add the values into common.h, right?

Nope, that TODO is just stale and has been removed.

> 
>> Whether we need an SVDO indicator is another question entirely, but it
>> definitely does not belong in ConnectionManager.  All SVDO indicates is
>> whether data + voice are possible simultaneously.
>>
> 
> Can't we specify at least the technology?

Perhaps, but right now this seems like a convenience feature and very
low on the priority list.  I'd rather we implement the current API
proposal first in its entirety before rushing off to define new APIs.

Regards,
-Denis

  reply	other threads:[~2011-12-02 12:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-02 14:00 [PATCH_v0 0/5] Add bearer recovery implementation for CDMA modems Guillaume Zajac
2011-12-02 14:00 ` [PATCH_v0 1/5] doc: Add bearer property Guillaume Zajac
2011-11-30  9:30   ` Denis Kenzior
2011-12-05 10:40     ` Guillaume Zajac
2011-12-02 12:10       ` Denis Kenzior [this message]
2011-12-02 14:00 ` [PATCH_v0 2/5] cdma-connman: Add bearer notification public function declaration Guillaume Zajac
2011-12-02 14:00 ` [PATCH_v0 3/5] cdma-connman: Add bearer property implementation Guillaume Zajac
2011-12-02 14:00 ` [PATCH_v0 4/5] cdmamodem: Add bearer recovery into connman driver Guillaume Zajac
2011-12-02 14:00 ` [PATCH_v0 5/5] huaweicdma: Specify vendor ID while creating cdma-connman atom Guillaume Zajac

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=4ED8C029.80808@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.