Re: [RFC PATCH] gprs: add function to handle activated context
Hi Sjur, I thought that we came to the conclusion that CID=0 is pretty much a really bad idea. So I would prefer that your modem is actually not using CID=0 ever. Yea, I know you or Denis said so, but I'm not sure we understood your concern... I really thought it became pretty much clear during the discussion that introducing a CID=0 that is just special on LTE is a pretty much bad idea. As long as CID=0 concept does not exist in GSM/UMTS, you should not make LTE a special case. It will not fit and just makes things utterly complex for the telephony stack to figure out when contexts are moved from LTE to GSM/UMTS. If CID=0 is not valid for GSM/UTMS then you are in big trouble to make this work properly. And if it is valid, then there is no difference between it being CID=0 or any other CID. So please step away from the CID=0 idea and just give the next free CID to the network activated context. And per specification the CID start with 1. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] stk: Remove unwanted error check
Hi Jeevaka, Possible return values of __ofono_voicecall_tone_send are -ENOSYS, -ENOENT, -ENOMEM and -EINVAL. --- src/stk.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] Fix compile warning at MeeGo The gcc version is MeeGo 4.5.1
Hi Martin,
src/call-forwarding.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/call-forwarding.c b/src/call-forwarding.c
index 512f223..36ba4f1 100644
--- a/src/call-forwarding.c
+++ b/src/call-forwarding.c
@@ -246,7 +246,7 @@ static gboolean is_cfu_enabled(struct
ofono_call_forwarding *cf,
static void sim_set_cf_indicator(struct ofono_call_forwarding *cf)
{
gboolean cfu_voice;
- struct ofono_call_forwarding_condition *cond;
+ struct ofono_call_forwarding_condition *cond = NULL;
cfu_voice = is_cfu_enabled(cf, cond);
I really hate trying to fix compiler warnings like this.
/*
* For now we only support Voice, although Fax all Data
* basic services are applicable as well.
*/
for (; l; l = l-next) {
cond = l-data;
if (cond-cls BEARER_CLASS_VOICE)
continue;
if (out)
*out = cond;
return TRUE;
}
return FALSE;
So this is clearly a false positive. The only why this would fail is
This is not a false positive, it is quite possible not to reach the for(;;)
branch, and uninitialized the *cond.
I have added
*out = NULL;
Out of the branch, and found that the warning gone.
So here I think gcc is right, and we need the patch.
it is a false positive.
The only caller that uses the cond value is sim_set_cf_indicator. And it
only uses conf if the return value is TRUE. So where can this go wrong?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v3] ifx: Adding modem selftest for Infineon modem
Hi Robertino,
This is another attempt to submit a patch that triggers Infineon
modem selftest during ofono boot. Patch addresses issues raised
by Marcel from the previous submissions.
---
as a general comment, changelogs and notes for the reviewer have to
between --- and the diffstat. They should not be part of the commit
message. The commit messages becomes part of ofono.git, the comments are
just for the reviewer.
plugins/ifx.c | 76 +---
1 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/plugins/ifx.c b/plugins/ifx.c
index c0a69c2..e0eb982 100644
--- a/plugins/ifx.c
+++ b/plugins/ifx.c
@@ -71,6 +71,8 @@
#define GPRS3_DLC 4
#define AUX_DLC 5
+#define IFX_SELF_TESTS_TIMEOUT 10
+
I asked this 3 times now, where is this magic value of 10 seconds coming
from. What is the average expected execution time of each test?
static char *dlc_prefixes[NUM_DLC] = { Voice: , Net: , GPRS1: ,
GPRS2: , GPRS3: , Aux: };
@@ -81,6 +83,16 @@ static const char *dlc_nodes[NUM_DLC] = { /dev/ttyGSM1,
/dev/ttyGSM2,
static const char *none_prefix[] = { NULL };
static const char *xdrv_prefix[] = { +XDRV:, NULL };
+static struct {
+ char *test_desc;
+ char *at_cmd;
+} const mst[] = {
+ { AT Command Test, ATE0 +CMEE=1 }, /* set echo error reporting */
I really don't like to put ATE0 into this. It is not a selftest or test
command.
+ { RTC GTI Test, a...@rtc:rtc_gti_test_verify_32khz() },
+ { Device Version Test, a...@vers:device_version_id() },
+ { NULL, NULL }
+};
And I like to still see an answer why we have to trigger selftests here.
Can we just not have one AT command to check the modem health and be
done with it?
Another question that I did ask is to see some sample results from these
test cases in failure and success case. Do we actually care about test
description here at all or can we just drop it?
struct ifx_data {
GIOChannel *device;
GAtMux *mux;
@@ -99,6 +111,7 @@ struct ifx_data {
int audio_loopback;
struct ofono_sim *sim;
gboolean have_sim;
+ int self_test_idx;
};
static void ifx_debug(const char *str, void *user_data)
@@ -545,6 +558,52 @@ static gboolean mux_timeout_cb(gpointer user_data)
return FALSE;
}
+static void ifx_self_test_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct ifx_data *data = ofono_modem_get_data(modem);
+
+ if (data-mux_init_timeout 0) {
+ g_source_remove(data-mux_init_timeout);
+ data-mux_init_timeout = 0;
+ }
This is rather pointless. We are not starting a timeout for every single
command. The mux_timeout handling was designed for spawning the overall
setup process and not just one command.
+ if (!ok) {
+ ofono_error(Modem %s: FAIL,
+ mst[data-self_test_idx].test_desc);
+ g_at_chat_unref(data-dlcs[AUX_DLC]);
+ data-dlcs[AUX_DLC] = NULL;
+
+ g_io_channel_unref(data-device);
+ data-device = NULL;
+
+ ofono_modem_set_powered(modem, FALSE);
+
+ return;
+ }
+
+ data-self_test_idx++;
+
+ if (mst[data-self_test_idx].at_cmd != NULL) {
+ g_at_chat_send(data-dlcs[AUX_DLC],
+ mst[data-self_test_idx].at_cmd,
+ NULL, ifx_self_test_cb, modem, NULL);
+
+ data-mux_init_timeout = g_timeout_add_seconds(
+ IFX_SELF_TESTS_TIMEOUT, mux_timeout_cb, modem);
+
Just using return here and bothering with the else branch would result
in a lot simpler to read code.
+ } else {/* Enable MUX Channels */
+ data-frame_size = 1509;
+ g_at_chat_send(data-dlcs[AUX_DLC],
+ AT+CMUX=0,0,,1509,10,3,30,,, NULL,
+ mux_setup_cb, modem, NULL);
+
+ data-mux_init_timeout = g_timeout_add_seconds(5,
+ mux_timeout_cb, modem);
+ }
+}
+
static int ifx_enable(struct ofono_modem *modem)
{
struct ifx_data *data = ofono_modem_get_data(modem);
@@ -595,18 +654,15 @@ static int ifx_enable(struct ofono_modem *modem)
if (getenv(OFONO_AT_DEBUG))
g_at_chat_set_debug(chat, ifx_debug, Master: );
- g_at_chat_send(chat, ATE0 +CMEE=1, NULL,
- NULL, NULL, NULL);
-
- data-frame_size = 1509;
-
- g_at_chat_send(chat, AT+CMUX=0,0,,1509,10,3,30,,, NULL,
- mux_setup_cb, modem, NULL);
+ /* Execute Modem Self tests */
+ data-dlcs[AUX_DLC] = chat;
+ data-self_test_idx = 0;
- data-mux_init_timeout = g_timeout_add_seconds(5, mux_timeout_cb,
-
Re: [PATCHv4 1/1] plugin: Add ste modem initd integration
Hi Sjur,
This patch introduces auto discovery of ST-Ericsson modems.
ST-Ericsson modems (M57XX, M7XX, M74XX) are managed by a
Modem Init Daemon responsible for start, power cycles,
flashing etc. This STE plugin monitors the modem state exposed
from the Modem Init Damon's Dbus API. When the modem is in state
on the STE modem is created and registered. Muliple modem
instances, and reset handling is supported.
---
Changes:
- Adapted to new Dbus API, using GetModems method and PropertyChange signal
- Using Serial as modem id
- Review comments from last v3
Makefile.am |4 +
plugins/stemgr.c | 345
++
2 files changed, 349 insertions(+), 0 deletions(-)
create mode 100644 plugins/stemgr.c
diff --git a/Makefile.am b/Makefile.am
index 8a8555d..6fc4c62 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -223,6 +223,10 @@ builtin_sources += drivers/atmodem/atutil.h \
drivers/ifxmodem/gprs-context.c \
drivers/ifxmodem/stk.c
+
+builtin_modules += stemgr
+builtin_sources += plugins/stemgr.c
+
This is a minor nitpick, but I think this is better placed between ste
and caif plugin details. And not on top of stemodem.
builtin_modules += stemodem
builtin_sources += drivers/atmodem/atutil.h \
drivers/stemodem/stemodem.h \
diff --git a/plugins/stemgr.c b/plugins/stemgr.c
new file mode 100644
index 000..467d0f8
--- /dev/null
+++ b/plugins/stemgr.c
@@ -0,0 +1,345 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2011 ST-Ericsson AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include errno.h
+#include string.h
+#include net/if.h
+
+#include glib.h
+#include gdbus.h
+
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include ofono/plugin.h
+#include ofono/log.h
+#include ofono/modem.h
+#include ofono/dbus.h
+
+/*
+ * ST-Ericsson's Modem Init Daemon is used for controling the modem power
+ * cycles and provides a dbus API for modem state and properties.
+ */
+#define MGR_SERVICE com.stericsson.modeminit
+#define MGR_MGR_INTERFACEMGR_SERVICE .Manager
Really? MGR_MGR and not MGR_MANAGER ;)
+#define MGR_GET_MODEMS GetModems
+#define GET_MODEMS_TIMEOUT 5000
+
+#define MGR_MODEM_INTERFACE MGR_SERVICE .Modem
+#define PROPERTY_CHANGED PropertyChanged
+
+enum ste_state {
+ STE_PENDING,
+ STE_REGISTERED,
+ STE_RESETTING
+};
+
+struct ste_modem {
+ struct ofono_modem *modem;
+ char *path;
You don't have to necessarily do it this way, but since you are using
the path memory also as index for your hash table it might be good to
put it first in your struct.
+ enum ste_state state;
+ char *serial;
+ char *interface;
+};
+
+static GHashTable *modem_list;
+static guint mgr_api_watch;
It is more like a service watch or daemon watch.
+static guint mgr_state_watch;
And this is property changed watch, right?
+static DBusConnection *connection;
+static gboolean get_modems_call_pending;
What is this exactly for? How many do you expect to have pending?
+static inline gboolean is_ready(const char *action)
+{
+ return g_strcmp0(action, ready) == 0;
+}
+
+static inline gboolean is_reset(const char *action)
+{
+ return g_strcmp0(action, dumping) == 0;
+}
This is nasty. Why not convert the state into an enum once and be done
with it.
+static void state_change(struct ste_modem *stemodem, const char *action)
+{
+
Scrap this empty line ;)
+ switch (stemodem-state) {
+ case STE_PENDING:
+
+ if (!is_ready(action))
+ break;
+
+ stemodem-modem = ofono_modem_create(stemodem-serial,
+ ste);
+ if (stemodem-modem == NULL) {
+ ofono_error(Could not create modem %s, %s,
+ stemodem-path, stemodem-serial);
+ return;
+ }
+
+ DBG(register modem %s, %s, stemodem-path, stemodem-serial);
+ ofono_modem_set_string(stemodem-modem, Interface,
+
Re: [RFC PATCH] gprs: add function to handle activated context
Hi Redouane, gprs: add function to handle activated context ofono_gprs_context_activated : this function is symetric to ofono_gprs_context_deactivated. This function must be call by any gprs-context driver when a context has been activated without explicit request. Behavior of the function : List all the context and try to find correct APN we have to be careful to only match against APN==APN and Username== + Password==. The username and password option is pretty much pointless, but it is present and we do support it. So we need to make sure the APN matching sensible. Or does the network provide us with additional information about the username + password as well? If such context is not found create a new one with Internet type. I don't really agree that we should create a context if no match is found. I think the better sensible strategy is to hold this information internally and only map it to a context once the user or provisioning creates it. Also oFono will create at least one Internet context automatically. And in the future that might be auto-provisioned. Another option would be to introduce the concept of temporary context where the lifetime is mandated by the network. For the context (found or created): Update the settings Set to active Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] dbus: fix appending on dict for types other than string
Hi Lucas, According to dbus documentation, dbus_message_iter_append_basic() expects a const char** if type is string and a simple pointer for other types. Since we a iterating an array, the value passed is already a pointer. --- src/dbus.c | 20 ++-- 1 files changed, 18 insertions(+), 2 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCHv3] network: query signal strength
Hi Marit, Signal strength is set to -1 whenever registration status changes and differs from registered or roaming. When registration status changes again to registered or roaming, the signal strength needs to be updated, added query towards driver to get it. --- src/network.c | 29 + 1 files changed, 17 insertions(+), 12 deletions(-) patch has been applied. I also put back the check to ignore signal strength notifications when not registered. With this fix that change should become obsolete. Aki, since you remove that check originally, please double check that this does not break for you. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings
Hi Jukka,
thinking about this a bit more and with the background that there is
already an existing public database, we might should just enable a
provision driver inside the oFono core.
Meaning that we can have multiple implementations of different databases
with just different priorities. Each nicely separated in their own
plugin and we don't bother the oFono core with where to get the data
from. So my idea would be that the oFono core just asks to provision a
new context. If a plugin feels responsible, then it does so. If not then
it stays empty.
Running oFono on the desktop/netbook etc. it makes sense to use the
current mobile broadband provider database. However on a phone that is a
not so good database. And for you guys it would also be possible to
continue using a CSV based format.
This sounds very good to me. Making provisioning modular makes a lot of
sense.
But I am not yet very familiar with oFono plugin architecture. Is there
some pattern in oFono code I could follow when implementing this, or
could you or someone provide some skeleton code how this should go?
In my patch (3/4) for gprs.c, I call get_operator_settings() (in
operator-settings.c), which returns list of gprs_access_settings, that
are then created as contexts. I assume now this get_operator_settings()
would somehow call registered provisioning modules, that similarly would
return list of gprs_access_settings? Or should these plugins directly
call some new gprs atom interface to create the contexts?
the oFono plugins work like kernel modules. They are pretty much
generic. Inside the init function you can a driver register function and
inside the exit function, you call the driver unregister function.
We need to discuss some more details here, but something along these
lines should do it:
struct ofono_gprs_provision_driver {
const char *name,
int priorty,
int (*setup_context) (struct ofono_gprs_primary_context *context),
};
int ofono_gprs_provision_driver_register(const struct
ofono_gprs_provision_driver *);
void ofono_gprs_provision_driver_unregister(const struct
ofono_gprs_provision_driver *);
I am not 100% sure about the naming here, but something along these
lines seems to be the way to go.
Then your specific plugin would look like this:
static int setup_context(struct ofono_gprs_primary_context *context)
{
...
return 0;
}
static const ofono_gprs_provision_driver driver {
.name = test,
.setup_context = setup_context,
};
static int plugin_init(void)
{
return ofono_gprs_provision_driver_register(driver);
}
static void plugin_exit(void)
{
ofono_gprs_provision_driver_unregister(driver);
}
OFONO_PLUGIN_DEFINE(myplugin, My provision plugin, VERSION,
OFONO_PLUGIN_PRIORITY_DEFAULT, plugin_init, plugin_exit)
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCHv3] stemodem: Fix for MT call not working when caller id is hidden.
Hi Marit, In *ECAV, the number will not be included if caller id is hidden. Set it to an empty string in that case, and set number type to 128, unknown number type. --- drivers/stemodem/voicecall.c | 15 ++- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/stemodem/voicecall.c b/drivers/stemodem/voicecall.c index bf68f52..7f0a19f 100644 --- a/drivers/stemodem/voicecall.c +++ b/drivers/stemodem/voicecall.c @@ -1,4 +1,4 @@ -/* +e/* What is this ;) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings
Hi Kalle, thinking about this a bit more and with the background that there is already an existing public database, we might should just enable a provision driver inside the oFono core. Meaning that we can have multiple implementations of different databases with just different priorities. Each nicely separated in their own plugin and we don't bother the oFono core with where to get the data from. So my idea would be that the oFono core just asks to provision a new context. If a plugin feels responsible, then it does so. If not then it stays empty. I like the idea. Simple to implement and we get maximum extensibility. Are you willing to take a plugin into ofono git which would use mobile-broadband-provider-info database? Or should people maintain the plugins out of tree? in general I would accept any of such plugins into the tree. However we need to be a bit careful with the priority. And of course they need to have some sort of usage. What I expect to see in long term is that we have two or three different formats. And they just differ because of the different vertical targets. For me the best would be to have all plugins in ofono tree and enable/disable them with configure switches. I wanna use priorities and smart detection to use them. Nothing for the user to configure. Just installing some extra packages should active its usage. And yes, I want to make it possible to build all plugins at all time. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCHv4] stemodem: Fix for MT call not working when caller id is hidden.
Hi Marit, In *ECAV, the number will not be included if caller id is hidden. Set it to an empty string in that case, and set number type to 128, unknown number type. --- drivers/stemodem/voicecall.c | 13 + 1 files changed, 9 insertions(+), 4 deletions(-) patch has been applied. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings
Hi Jukka,
the oFono plugins work like kernel modules. They are pretty much
generic. Inside the init function you can a driver register function and
inside the exit function, you call the driver unregister function.
Right, that seems clear enough.
static int setup_context(struct ofono_gprs_primary_context *context)
{
...
return 0;
}
static const ofono_gprs_provision_driver driver {
.name = test,
.setup_context = setup_context,
};
I guess that current struct ofono_gprs_primary_context* is not enough
for provisioning data, it is missing at least name, MMS proxy and server
information. Should those (and whatever might be needed in future) be
added into that struct, or should we define some
struct ofono_gprs_provisioning_data {
struct ofono_gprs_primary_context pri;
char name[MAX_CONTEXT_NAME_LENGTH + 1];
char message_proxy[MAX_MESSAGE_PROXY_LENGTH + 1];
char message_center[MAX_MESSAGE_CENTER_LENGTH + 1];
}
struct pri_context in gprs.c contains everything, but has extra
gprs-internal stuff.
Also setup_context() needs ofono_gprs_context_type as in-parameter.
it is just an example and we most likely need a bit more thinking about
it. To be honest, I just spent only 10 minutes on it to give you a brief
idea on how I think this could be done.
And a question about the priorities, if there is more than one
provisioning plugin: would plugins be called in priority order, and
after first returns something, rest would not be called?
Inside oFono we have not used this concept, but inside ConnMan we just
order the drivers by priority. And then call the function in priority
order. If it returns 0, then we try the next, if it return = 0 then we
stop calling. First one with highest priority wins ;)
We might need to add a probe() and remove() callback to do some basic
detection of the driver pre-constraints. This needs to be figured out as
well.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/4 v2] Network Time plugin
Hi Remi, So the idea of having an oFono D-Bus API to export time information is just wrong from my point of view. The plugin inside oFono should tell the time daemon about this. That would be race-prone by design. For all we know, the time daemon might be started after oFono (or restarted). It's pretty basic design to have a getter and a change signal for any kind of value. there is no race here. The timed plugin inside oFono can just keep the time and only send it out when timed starts. You can easily monitor deamons lifetime with D-Bus. You just said that you did not want oFono to keep the time reference value. This is self-contradictory. Now you admit that oFono does need to keep it. I said that 3-4 emails early already. It is either that or you just go ahead and set the system if timed is not running. But then it is far simpler to have a D-Bus getter and a D-Bus signal by any sane measure of complexity. So you did consider the complexity on both sides, ofonod and timed? And not just looked at one side of picture? Besides, I find hard-coding The One time daemon in the oFono plugin rather silly. It's really nothing but an arbitrary design limitation that would be overcome with a clean D-Bus API like we proposed several times. It is a plugin that monitors the existence of such a daemon. So we can have multiple plugins for each daemon. And we can even have them all active at the same time. So where do you see a problem here? So that is far more complicated, inextensible and it consumes more CPU (more D-Bus interactions). This makes absolutely no sense. Are you kidding me here? Where is the more D-Bus interaction going to happen. It would be nice if you actually start counting both sides of the equation here. So you really want timed to monitor the oFono manager interface with their modems and then the method calls and signals from the time interface. Please count again what consumes more D-Bus interactions. And not the time daemon go out and bother with additional sources etc. Last time I checked, NTP clients go out and bother to ask the configured NTP server, not the other way around. I fail to see reason why oFono should work the other way around. I do see several reasons why it should not. You need to tell NTP client (or the ntpd running) the time servers to use. Check how we do that in ConnMan. we tell ntpd about time servers and not the other way around. That's the point: the one who wants to learn the time (the NTP client, or the time daemon) is the one ASKING for it from the one who knows (the NTP server or oFono). The other direction is just totally backward design. Who is telling NTP client where the servers are? Or is the NTP client just going out fishing for NTP servers. Maybe we should just turn ofonod into an NTP time source and then let ntpd just always use that one. Problem solved and nicely integrated with the desktop world as well. And if you take the normalized time based on a monotonic clock, such a plugin that just send a D-Bus message to a time daemon is actually a lot simpler than exposing a full blown D-Bus interface. It's very marginally simpler: one signal against one signal plus one getter that will share much marshalling code with the signal. But that's irrelevant. It actually works. The sole signal design is broken. I was talking about a method call to timed and not a signal. It's largelly irrelevant. There's no functional difference between a method call without response and a signal. There is a big difference when you look at potential wakeups of other processes. A method call is always directed, a signal is broadcasted. So the plugin just has to store the normalized time in memory. And if a time daemon is present, then send out an update if needed, otherwise don't bother. Oh? That would actualy be far more complicated, as the plugin would then need to track down the presence of the time daemon. I see some contradiction here. And that is a problem with D-Bus how? With g_dbus_add_service_watch this is dead simple actually. Simpler than providing a D-Bus interface. I never said this was not feasible. I said this was more complicated and disingenuous. I actually said that it is a lot simpler. If you don't believe me, why don't you just code both versions of the plugin and then compare them. And it is also a lot simpler for timed to integrate with this. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCHv2] plugin: Add ste modem initd integration
Hi Sjur,
what about potential USB based CAIF devices?
Good question, but in a Bridge Setup for a phone this will not really
be devices that come and go.
I belive it will still be a fixed HW setup where the Modem Init Daemon
will have static knowledge of the
USB modems. But I'll discuss this with my coleagues tomorrow.
In case of true USB dongles the modem should look pretty much
identical to MBM USB dongles.
I personally would prefer that USB devices just expose CAIF directly.
The whole handling of multiple hardcoded TTY and network interface is
only sub-optimal.
I know it is kinda nice to use standard USB class drivers, but the
flexibility that CAIF actually gives you goes away.
From my point of view, it should be similar to Phonet/ISI over USB. At
least on Linux we have a CAIF subsystem ;)
I would just ask to send the property changed signal for the serial
number before sending the signal for on/ready.
It will require a re-design of the state machine in the Modem Init Daemon,
but I'll check into this tomorrow.
Here is the latest version of the Dbus API:
STE Modem Init Deamon Manager
=
Service com.stericsson.modeminit
Interface com.stericsson.modeminit.ModemManager
Just call it com.stericsson.modeminit.Manager. That gives you the chance
to also include other methods/signals later on if needed.
Object path /
Methods array{object,dict} GetModems()
Get array of STE Modem objects and their state and
properties (out signature 'a(oa{sv})').
The method should only be call once per application.
Further changes shall be monitored via StateChange
signals.
STE Modem
=
Service com.stericsson.modeminit
Interface com.stericsson.modeminit.Modem
Object path variable
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
Propertiesstring State [readonly]
The modems state is dynamic can can have the following
values:
booting Modem is powered up (flashed version)
or Modem is powered up and firmware upload
is completed. (flashless version)
upgrading Firmware upgrade on going
or Flashing manager under execution -
modem in service mode.
onModem has booted and is ready for use.
This implies that all AT channels are
available, the modem might be in
e.g. flight mode.
NOTE: Consider change name to ready
dumping Modem has crashed and dump is ongoing
off Modem is powered off.
string AtInterface[readonly]
CAIF Link Layer interface to be used for
AT channels for a modem.
Why is there an At in here? I know that mainly only AT command
channels will be used, but the CAIF interface can be also used to
request debug channels and other things. So I would just call it
Interface only to say what's the interface name is to bind to.
string Serial[optional,readonly]
Serial Number or IMEI for the Modem. The Serial will
not be available until the modem can open an AT channel.
Otherwise, this looks a lot simpler and cleaner.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.
Hi Pekka, Andrew is currently looking on how to do SIM application discovery. So I like to get his input on this as well. The AT+CUAD looks straightforward enough. Unfortunately I've yet to see a modem implementing AT+CUAD. the MBM F35xx does support this. At least when I quickly check while we were in Paris. So I assume all MBM hardware should support it. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] dbus: fix appending on dict for types other than string
Hi Lucas,
According to dbus documentation, dbus_message_iter_append_basic()
expects a const char** if type is string and a simple pointer for
other types. Since we a iterating an array, the value passed is already
a pointer.
---
src/dbus.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/dbus.c b/src/dbus.c
index c24615f..292f11a 100644
--- a/src/dbus.c
+++ b/src/dbus.c
@@ -139,8 +139,13 @@ static void append_dict_variant(DBusMessageIter *iter,
int type, void *val)
dbus_message_iter_append_basic(entry, DBUS_TYPE_STRING,
(val_array[i + 0]));
- dbus_message_iter_append_basic(entry, type,
- (val_array[i + 1]));
+ if (type == DBUS_TYPE_STRING) {
+ dbus_message_iter_append_basic(entry, type,
+ (val_array[i + 1]));
+ } else {
+ dbus_message_iter_append_basic(entry, type,
+ val_array[i + 1]);
+ }
this does looks a bit hackish. Can you put it into context please. It
might be that our call chain is wrong.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] dbus: fix appending on dict for types other than string
Hi Lucas, the append_basic D-Bus function works fine on **char and *uint8. So either a pointer to a string (*char) or pointer to a byte (uint8. You differentiate between pointer to a string and pointer to a byte in that function. So it is different since normally it is the caller that has to give the right pointer in the first place. Yeah, true... But if we don't differentiate the types here I'd need to cast an uint8 to void* that is not even allowed by our warning flags as I said, I am fine with checking the type, but I would like to see a comment in the code why we differentiate in this case. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/4 v2] Network Time plugin
Hi Aki, But then it is far simpler to have a D-Bus getter and a D-Bus signal by any sane measure of complexity. So you did consider the complexity on both sides, ofonod and timed? And not just looked at one side of picture? Timed also needs to follow the registration status, namely the MNC/MCC of the registered network. This information it needs to be able to find the correct timezone, as the UTC offset alone only indicates the geographic longitude for the timezone. Factor that in to the equation, and timed already needs to enumerate available modems, call GetProperties, and listen to the NetworkRegistration interface's PropertyChanged signals. However, if we refactor the time plugin to also send the MNC/MCC pair -- or better yet, the ISO country code based on MCC or even the actual timezone from matching zone.tab entry -- then following netreg is no longer needed. *Then* I agree a method call is actually a lot simpler from timed point of view; all it needs to do is implement a single method on some org.ofono.NetworkTimeConsumer interface and not worry about enumerating modems via ModemManager or listening on any signals. we are doing the country alpha2 matching to MCC already in ConnMan for the WiFi regulatory enforcement update. I am not sure that I wanna copy these tables around all the time. So the struct ofono_nettime_context has already a reference to struct ofono_modem, so why not add a reference to the struct ofono_netreg and then you have the MCC/MNC details available inside the plugin. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings
Hi Aki, Any particular reason why you can't use the same format as in mobile-broadband-provider-info? I think reusing the format here makes sense, actually. If not for anything else than to be able to use an existing database for testing. my thinking was that we should read the MBPI database if present and use it as much as possible. Since oFono will not ship a database by default anyway. However we do need an extensible way of per-operator overrides at least. And while MBPI database might work on the desktop, I think it will fail on a mobile phone. The information in it are too desktop centric. I also have a small problem on how it tries to solve the problem of virtual providers and/or different contract details. This part of the database if more designed for UI usage than for system usage. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings
Hi Jukka, Well, my intention was to make format simple and fast to parse, but still be extensible enough, which I think my proposed format fulfills. These access-elements contain just data needed for GPRS context settings (as attributes), and if there is need for any other operator specific provisioning information, you can always add separate elements, this is still proper XML. But IMHO it is really ugly and not a properly designed XML. Well, to me it looks simple, compact and clean, and most certainly provides all necessary extensibility any XML format provides. Again, why not use mobile-broadband-provider-info DTD? If there's something missing, I'm sure maintainers are willing to extend it. No need to reinvent the wheel. In this format biggest thing that I see missing is type of access point (internet,mms,lte), protocol (for IPv6) and mms-server (or homepage). And I assume name of provider could be interpreted as SPN for provisioning. The good point of using mobile-broadband-provider-info is that it would indeed provide existing database for testing purposes. For product creation, manufacturers will anyway create their own databases, and there the format does not matter much. I think we need something in between both formats. The mobile-broadband-provider-info is too much and too complex from my point of view. It contains too much details that are not really helping us if you wanna do provisioning. We need to automate this and can not really ask the user. On the other hand, I would prefer a little bit more XML style nesting or we just use key files right away. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCHv2 1/4] sim: add ofono_sim_get_mnc_length
Hi Jukka, include/sim.h |1 + src/sim.c |8 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/include/sim.h b/include/sim.h index 7860e24..3d0c6b7 100644 --- a/include/sim.h +++ b/include/sim.h @@ -173,6 +173,7 @@ void ofono_sim_set_data(struct ofono_sim *sim, void *data); void *ofono_sim_get_data(struct ofono_sim *sim); const char *ofono_sim_get_imsi(struct ofono_sim *sim); +int ofono_sim_get_mnc_length(struct ofono_sim *sim); actually that value is an unsigned char. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 5/5] cell-info: Documentation
Hi Aki,
What is the reason behind a{sv}aa{sv} here? Wouldn't it be simpler to
just go with aa{sv} and declare that the first dict is always the
current serving cell? Are the information from the current cell really
that different than from the neighbors?
The rationale is that this is the format OMA-TS-ULP-V2_0-20100816-C and
3GPP RRC define for user plane location. Also, all modems don't provide
the same information for serving and neighbor cells; e.g. isimodem
follows the above mentioned specs. I believe that for location purposes
the information included in the a{sv} part is not needed for neighbors.
Hence making the structure flat would not really make things simpler.
I originally suggested a{sv}aa{sv}, but I don't see a problem this
being just a flat aa{sv}. The keys in dicts can always be different,
and if the documentation clearly states that the first dict is always
meta-data, followed by the actual neighbor measurements, it'll work
just the same.
so the position engine would need the details that you provide in the
current serving cell. And just following network registration is not
good enough here?
Also the information from the current serving cell are really different
from the neighbor cell information?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/4 v2] Network Time plugin
Hi Remi, So the idea of having an oFono D-Bus API to export time information is just wrong from my point of view. The plugin inside oFono should tell the time daemon about this. That would be race-prone by design. For all we know, the time daemon might be started after oFono (or restarted). It's pretty basic design to have a getter and a change signal for any kind of value. there is no race here. The timed plugin inside oFono can just keep the time and only send it out when timed starts. You can easily monitor deamons lifetime with D-Bus. Besides, I find hard-coding The One time daemon in the oFono plugin rather silly. It's really nothing but an arbitrary design limitation that would be overcome with a clean D-Bus API like we proposed several times. It is a plugin that monitors the existence of such a daemon. So we can have multiple plugins for each daemon. And we can even have them all active at the same time. So where do you see a problem here? And not the time daemon go out and bother with additional sources etc. Last time I checked, NTP clients go out and bother to ask the configured NTP server, not the other way around. I fail to see reason why oFono should work the other way around. I do see several reasons why it should not. You need to tell NTP client (or the ntpd running) the time servers to use. Check how we do that in ConnMan. we tell ntpd about time servers and not the other way around. And if you take the normalized time based on a monotonic clock, such a plugin that just send a D-Bus message to a time daemon is actually a lot simpler than exposing a full blown D-Bus interface. It's very marginally simpler: one signal against one signal plus one getter that will share much marshalling code with the signal. But that's irrelevant. It actually works. The sole signal design is broken. I was talking about a method call to timed and not a signal. So the plugin just has to store the normalized time in memory. And if a time daemon is present, then send out an update if needed, otherwise don't bother. Oh? That would actualy be far more complicated, as the plugin would then need to track down the presence of the time daemon. I see some contradiction here. And that is a problem with D-Bus how? With g_dbus_add_service_watch this is dead simple actually. Simpler than providing a D-Bus interface. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC sim-authenticate PATCH 2/3] Added doc/sim-authentication-api.txt.
Hi Pekka,
The EAP applications on SIM should be handled separately. The
EapSimAuthenticate and EapAkaAuthenticate do not require a special EAP
application on SIM, but they use ordinary cellular authentication.
---
doc/sim-authentication-api.txt | 66
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 doc/sim-authentication-api.txt
diff --git a/doc/sim-authentication-api.txt
b/doc/sim-authentication-api.txt
new file mode 100644
index 000..9a033bf
--- /dev/null
+++ b/doc/sim-authentication-api.txt
@@ -0,0 +1,66 @@
+SimAuthentication hierarchy
+===
+
+Service org.ofono
+Interfaceorg.ofono.SimAuthentication
+Object path [variable prefix]/{modem0,modem1,...}
+
+Methods byte{array} EapSimAuthenticate(array{byte} rand)
+
+ Executes the SIM authentication algorithm for
+ RFC 4186 EAP SIM authentication method.
+
+ The input parameter is RAND, a 16-byte array.
+ In case of successful authentication operation
+ the SRES parameter is returned as a 4-byte array.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.NotImplemented
+
+ dict EapAkaAuthenticate(array{byte} rand, array{byte} autn)
so I would rather have an interface where you can discover the supported
authentication applications on the SIM card and then have one interface
to execute them.
The application using this interface needs somehow to know what methods
are available and not do some try and error execution.
Do you have something like this in your mind?
Methods dict Authenticate(string appl, array{byte} RAND,
array{byte} AUTN)
In case of successful SIM authentication the
returned dictionary contains following item:
byte{array} SRES - SRES parameter
In case of successful AKA authentication the
returned dictionary contains following items:
byte{array} RES - AKA RES parameter
byte{array} CK - AKA Ciphering key
byte{array} IK - AKA Integrity key
In case of unsuccessful authentication the
returned dictionary contain following item:
byte{array} AUTS - AKA AUTS parameter
Possible Errors: [service].Error.InvalidArguments
[service].Error.NotImplemented
Propertiesarray{string} Applications [readwrite]
Contains the list of supported authentication
applications. The possible values are:
EAP-SIM - GSM SIM authentication for EAP
EAP-AKA - AKA authentication for EAP
IMS-AKA - AKA authentication for IMS
GBA - GBA authentication
yep, that is similar to what I was thinking about. Andrew is currently
looking on how to do SIM application discovery. So I like to get his
input on this as well.
On AT command modems, we are pretty much tight into SIM application
discover and execution of authentication methods. At least when reading
the specification. I have not yet tested this since right now we are not
even bothering with SIM application details inside oFono at all.
For WISPr 2.0 and 802.1x we will need to make this work as well.
The EAP SIM is a subset of any proper AKA mechanism, but that should be
fine as well. Just having an empty AUTN array seems fine to me.
I'll see how GBA will fit to the architecture. According to the ISI
modem spec it might be straightforward.
Is there a public specification for GBA by any chance?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCHv2] plugin: Add ste modem initd integration
Hi Sjur,
is this the full API or only part of it. If it is just a part of it,
please send the full API for the daemon. Just looking at this piece, I
am not really thinking that this is a good API. It is actually pretty
much broken :(
Ok, here's an updated version of the Modem Init Daemon DBus API.
I hope this is aligned with what we discussed on the IRC.
STE Modem Init Deamon Manager
Service com.stericsson.modeminit
Interface com.stericsson.modeminit.Manager
Object path /
Methods array{object,dict} GetModems()
Get array of STE Modem objects and their state and
properties (out signature 'a(oa{sv})').
The method should only be call once per application.
Further changes shall be monitored via StateChange
signals.
You also need the following signals:
ModemAdded(object, dict)
ModemRemoved(object)
STE Modem
Service com.stericsson.modeminit
Interface com.stericsson.modeminit.Modem
Object path variable
Signals StateChange(string State)
The modems state sent from when
a modem state change occurs. State is the only
dynamic property in this Interface.
I would personally just go straight for PropertyChanged signal here and
not bother with StateChanged. It is actually ...Changed since at that
time the state has already changed ;)
Propertiesstring State [readonly]
The modems state is dynamic can can have the following
values:
booting Modem is powered up (flashed version)
or Modem is powered up and firmware upload
is completed. (flashless version)
upgrading Firmware upgrade on going
or Flashing manager under execution -
modem in service mode.
on Modem has booted and is ready for use.
This implies that all AT channels are
available, the modem might be in
e.g. flight mode.
dumping Modem has crashed and dump is ongoing
off Modem is powered off.
I personally would call it ready instead of on since the modem is
actually on, it is just not ready yet.
string CaifAtInterface [readonly]
CAIF Link Layer interface to be used for
AT channels for a modem.
I would really just call this Interface to make it simpler. Don't
think that you are expecting more than just CAIF interface here anyway.
And in addition if we can have the modem serial number here as Serial
as well would be good. Even it is is not right away available, you can
signal a change via PropertyChanged signal.
That way we can construct a proper modem object path inside oFono. I
really rather use the serial number and only fallback to the interface
name.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCHv2] plugin: Add ste modem initd integration
Hi Sjur, Signals StateChange(string State) The modems state sent from when a modem state change occurs. State is the only dynamic property in this Interface. I would personally just go straight for PropertyChanged signal here and not bother with StateChanged. It is actually ...Changed since at that time the state has already changed ;) OK, I'll look into this. I thought StateChange was the only dynamic parameter, but I might have been wrong here (see below). You also need the following signals: ModemAdded(object, dict) ModemRemoved(object) I think I'd rather add this when I see a use case for it. The Modem Init Deamon would need to know what GPIOs are associated with what modems, and what CAIF interfaces to use etc. This information is not dynamic, at least not at the moment. So ModemAdded and ModemRemoved will not happen in the current implementation, all the modems will be known when the Manager interface becomes available. what about potential USB based CAIF devices? ... string CaifAtInterface [readonly] CAIF Link Layer interface to be used for AT channels for a modem. I would really just call this Interface to make it simpler. Don't think that you are expecting more than just CAIF interface here anyway. OK, Fair enough. And in addition if we can have the modem serial number here as Serial as well would be good. Even it is is not right away available, you can signal a change via PropertyChanged signal. That way we can construct a proper modem object path inside oFono. I really rather use the serial number and only fallback to the interface name. OK, a Serial property is doable, but I think this is only available after state on (ready) That is fine. We have the same case in oFono that the SubscriberIdentity only becomes available a bit later. That is in the end easy to handle. I would just ask to send the property changed signal for the serial number before sending the signal for on/ready. has been reached. The drawback is that my assumption of State being the only dynamic property wrong. Crap you were right - I might need to add a PropertyChanged signal. This way you are a lot more flexible in the future. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCHv2 1/4] Automatic provisioning of GPRS context settings
Hi Jukka, Here is another RFC patchset about implementing automatic provisioning of Internet and MMS GPRS context settings. (Internet Access Provider database TODO item). In case there are no previously configured contexts found during gprs atom registration, this code tries to provision Internet and MMS contexts based on MCC, MNC and SPN (Service Provider Name) values read from SIM. Settings are read from an operator settings database. thinking about this a bit more and with the background that there is already an existing public database, we might should just enable a provision driver inside the oFono core. Meaning that we can have multiple implementations of different databases with just different priorities. Each nicely separated in their own plugin and we don't bother the oFono core with where to get the data from. So my idea would be that the oFono core just asks to provision a new context. If a plugin feels responsible, then it does so. If not then it stays empty. Running oFono on the desktop/netbook etc. it makes sense to use the current mobile broadband provider database. However on a phone that is a not so good database. And for you guys it would also be possible to continue using a CSV based format. Thoughts? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: New file about using the calypso modem
Hi Neil, doc/calypso-modem.txt | 22 ++ 1 files changed, 22 insertions(+), 0 deletions(-) create mode 100644 doc/calypso-modem.txt patch has been applied, but you might also wanna add this to Makefile.am so it becomes part of the tarballs. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Include doc/calypso-modem.txt in distribution
Hi Neil, Makefile.am |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: New file about using the calypso modem
Hi Neil,
doc/calypso-modem.txt | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 doc/calypso-modem.txt
diff --git a/doc/calypso-modem.txt b/doc/calypso-modem.txt
new file mode 100644
index 000..ea3e0bb
--- /dev/null
+++ b/doc/calypso-modem.txt
@@ -0,0 +1,22 @@
+Calypso modem usage
+===
+
+On the Openmoko Freerunner phone, the Calypso modem is presented by
+the kernel as serial device /dev/ttySAC0. To allow Ofono to
it is spelled oFono.
+autodetect and use this, a simple udev rule is needed:
+
+KERNEL==ttySAC0, ENV{OFONO_DRIVER}=calypso
+
+You can put this in any file in /lib/udev/rules.d. A logical choice
+is the 55-openmoko-gta01-gta02.rules file, if it exists in your
+Freerunner distribution.
+
+With this rule in place:
+
+- ofono will detect the Calypso modem when it starts up, and the
Same here. It is oFono.
+ `list-modems' test script will show this, but will not power it up
+
+- the `enable-modem' test script can be used to power it up
+
+- a subsequent `list-modems' will show lots of information, including
+ network registration.
Since we had this discussion on IRC. Has this rule been proven to do the
right thing? Even in case of the weird renaming of the original serial
port?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 5/5] cell-info: Documentation
Hi Antti,
doc/cell-info.txt | 124
+
1 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 doc/cell-info.txt
diff --git a/doc/cell-info.txt b/doc/cell-info.txt
new file mode 100644
index 000..b288e69
--- /dev/null
+++ b/doc/cell-info.txt
@@ -0,0 +1,124 @@
+Cell Info hierarchy
+===
+
+Service org.ofono
+Interfaceorg.ofono.CellInfo
+Object path [variable prefix]/{modem0,modem1,...}
+
+Methods a{sv}aa{sv} GetNeighborCellInfo()
+
+ Calling this procedure returns properties of serving
+ and neighbouring cells in GSM or WCDMA networks. This
+ information can be used to determine current location
+ using triangulation over neighbouring cell tower
+ locations and estimated distances.
+
+ The return value consists of two parts: 1) dictionary
+ of common information about network and serving cell 2)
+ array of dictionaries containing measurement results
+ of neighbouring cells. The contents of the dictionaries
+ follow the specification OMA-TS-ULP-V2_0-20100816-C for
+ user plane Location and is described in properties
+ section.
+
+ a{sv} GetProperties
+
+ Calling this procedure returns properties of serving
+ cell in GSM or WCDMA networks. Effectively the data
+ returned is the part 1 of the data returned by
+ GetNeighborCellInfo.
why do we bother here with two methods calls. What is the use of getting
only half of the information. You are making the same call to the
hardware, so why not return the same information.
The method name org.ofono.CellInfo.GetNeighborCellInfo is also not
really good. I duplicates the CellInfo information. So I would just have
called this GetNeighbors.
What is the reason behind a{sv}aa{sv} here? Wouldn't it be simpler to
just go with aa{sv} and declare that the first dict is always the
current serving cell? Are the information from the current cell really
that different than from the neighbors?
One other think that I don't really like with the GetProperties part is
that we could expect a PropertiesChanged signal. However that is not
really going to happen since the query should only be done on demand. So
I would prefer if we then don't have properties at all in this case.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/3] call-settings: rename CalledLine* properties
Hi Lucas, COLP and COLR are better named respectively as ConnectedLinePresentaion and ConnectedLineRestriction as stated in 27.007 sections 7.8 and 7.31. don't forget the scripts in the test directory. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Happy holidays to everyone
Hello everyone, and once more we have the Christmas release of oFono behind us. This year it was version 0.37 and I like to thank you guys for your constant contributions. The statistics of the project are impressive. We have 67 individual contributors with 4278 commits. If you compare this to last year, then we have 39 new contributors and 2814 new commits. The line count for C source files increased from 44816 to 107039. Language Files CodeComment Comment % Blank Total - - - - - - c 280 107039 9554 8.2% 26478 143071 python 66 2083 75 3.5%769 2927 automake 1438 0 0.0%100538 cpp 1376 36 8.7% 36448 html 1374 0 0.0% 12386 autoconf 1170 1 0.6% 37208 shell 3 30 3 9.1% 8 41 - - - - - - Total 353 110510 9669 8.0% 27440 147619 When looking at the changed lines of code, we have to give a big thank you to Denis for his constant contributions. And also a big thank you to Andrew and Yang for their work on SIM Toolkit support. Developers with the most changed lines -- Denis Kenzior 80016 (34.2%) Andrzej Zaborowski27962 (11.9%) Yang Gu 25203 (10.8%) Marcel Holtmann 24574 (10.5%) Aki Niemi 19997 (8.5%) Looking from a corporate perspective, then it shows us ProFusion, ST-Ericsson and Elektrobit as additional major contributors. Big thank you for the interest in this project. Top lines changed by employer - Intel 182365 (77.9%) Nokia38583 (16.5%) ProFUSION 5347 (2.3%) ST-Ericsson 3094 (1.3%) Elektrobit1662 (0.7%) So enjoy your vacation and a Happy New Year :) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: n900 not recongnized by ofono?
Hi Antti, It appears that after commit 374dd32812026c3d728f2a14f78357463f12a3f8 ofono is no longer registering n900 properly. At least 'list-modems' shows empty list even if two commit earlier [isigen0] is there as it should. Has the functionality changed or is this regression? the ofono.rules udev file changed. Have you installed the new one? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: oFono release plan?
Hi Aki, - SIM authentication API (EAP-SIM, EAP-AKA, IMS and GBA) Can you please add more light on what is supported. I could not find this info in the todo list. In short, we need to expose certain security services offered by the SIM card that utilize the crypto algorithms on the card. This is used for instance in voice over LTE authentication procedures. Probably needs to be added to the TODO. right now Andrew is looking into the SIM application discovery with AT command modems. Once we have that, we can look into what is needed for using the EAP methods and add details TODO items. Just adding a simple TODO item entry that we split out later into more detailed once would be fine with me. In theory we want an interface that suits all SIM authentication needs. Besides IMS, the second big user will be WISPr 2.0 for WiFi hotspots. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 2/5 v2] cell-info: Header file for cell-info atom
Hi Antti,
---
include/cell-info.h | 133
+++
1 files changed, 133 insertions(+), 0 deletions(-) create mode
100644 include/cell-info.h
diff --git a/include/cell-info.h b/include/cell-info.h new file mode
100644 index 000..3941e69
--- /dev/null
+++ b/include/cell-info.h
@@ -0,0 +1,133 @@
+/*
...
...
...
+struct ofono_cell_info_driver {
+ const char *name;
+ int (*probe)(struct ofono_cell_info *ci,
+ unsigned int vendor,
+ void *data);
+ void (*remove)(struct ofono_cell_info *ci);
+ void (*query)(struct ofono_cell_info *ci,
+ ofono_cell_info_query_cb_t,
+ void *data);
+};
+
To be aligning with the other header files, do we need to add one 'cb'
after 'ofono_cell_info_query_cb_t' here?
This seems to be a matter with no clear convention. In sms.h and
netreg.h some callbacks have 'cb' and some not. I agree that if within
a function's parameter list some parameters have name declared, so
should all have.
we are trying to be consistent, but some of these slipped through in the
initial development phase of oFono.
Once we find them, we document them in doc/coding-style.txt and then
slowly start fixing these up. This is an ongoing process and pretty hard
if your codebase reaches over 100k lines of code.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: PATCH: Enable udev-based autodetection of calypso modem on Freerunner
Hi Neil, Then I didn't look far back enough (or I'm simply blind). But I still prefer this to be inside the driver or HACKING.calypso for easier access. I am with you that this needs to be documented better than GIT commit logs. However I do prefer doc/calypso-modem.txt and doc/ifx-modem.txt though since I don't wanna clutter the root directory. Sounds good to me. Cool. Once I've worked out the simplest udev rule for calypso, I'll submit a patch to create doc/calypso-modem.txt to document that. (I don't yet understand why it makes sense for calypso to be handled differently from other cases in plugins/ofono.rules, but I'm happy to trust that there is a good reason for this.) the other cases come from an unique vendor and product ID. The Calypso and also IFX modems are based on device nodes. These are not unique. They are platform specific. Not all platform will have a Calypso modem behind /dev/ttySAC0 for example. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2, 7/7] cdmaphonesim: Add CDMA SMS Support
Hi Lei, Makefile.am | 10 ++ plugins/cdmaphonesim.c| 328 + plugins/cdmaphonesim.conf | 14 ++ 3 files changed, 352 insertions(+), 0 deletions(-) create mode 100644 plugins/cdmaphonesim.c create mode 100644 plugins/cdmaphonesim.conf do we really want to do it this way? I am not so sure that this is the best way. I would prefer to just have one /etc/ofono/phonesim.conf configuration file. And maybe we need to start splitting phonesim plugin into a view pieces and move it to its own directory. It then could also contain its own atom driver implementations there. So my main concern here is really that phonesim support is just for engineering. It has nothing to do with real production hardware. And I don't wanna clutter the source or its installation with it. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/4 v2] Network Time plugin
Hi Aki, There is no problem. If you still think there is a problem, you need to continue the previous thread on this subject and prove your point. And in case timed is not running it should just set the current time directly. You're welcome to write such a plugin -- this is why nettime is a plugin API after all. It might make sense in some platforms, especially those that don't have a working monotonic clock... actually I spent time thinking about this and the whole time daemon idea and what are potential input sources. So the idea of having an oFono D-Bus API to export time information is just wrong from my point of view. The plugin inside oFono should tell the time daemon about this. And not the time daemon go out and bother with additional sources etc. And if you take the normalized time based on a monotonic clock, such a plugin that just send a D-Bus message to a time daemon is actually a lot simpler than exposing a full blown D-Bus interface. So the plugin just has to store the normalized time in memory. And if a time daemon is present, then send out an update if needed, otherwise don't bother. I really like to see it implemented this way. It is simpler and makes a lot more sense than sending out D-Bus signals to everybody for time changes. In addition there will be more source for time and/or timezone information. For example the GeoIP country information returned by ConnMan portal service. We are not exposing a Getter/Changed D-Bus API from ConnMan for this either. We just will sending these information to interested parties. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCHv2] plugin: Add ste modem initd integration
Hi Sjur,
This is a bad D-Bus API btw. Using a D-Bus method to trigger signal
sending. You will wake up any listener for that signal. What is wrong
with just having a GetState?
My problem is that I need to get the path, or modem serial-number if
you like, to the
modem(s). As I don't know the start order I have to query the state at
startup.
So this will happens only once. The simples way for me to get the path is
to send ResendState to path /. This will then send the state info
for all modem
paths.
I don't think I have the path them available at connect...
If you have any other ideas of how to query the modem instances I'm all
ears?
I think you need to resend the D-Bus API of your init daemon. I need to
have a second look.
This is an extract of the Modem Init Daemon D-Bus API.
I have removed the GetState API as we don't know the object
path of the modem when oFOno has just booted. Instead we
have added the ResendState API. This will be called initially
when oFono starts to query the modem instances and their
state. After startup state changes are handed as signals
with StateChange. (There are some exceptions to this but
they should be only corner cases).
Modem Init Deamon
Service com.stericsson.modeminit
Interface com.stericsson.modeminit.Modem
Object path /{modem-serial} or /
Methods
void ResendState()
Resends state information for all modems.
This method must use with '/' as object path.
string GetCaifIfName()
Returns the CAIF Link Layer interface used for
AT channels for a specific modem. This method
must use the same object path as used in StateChange.
Signals StateChange(string status)
The modems state sent from Modem Init Daemon when
a modem state change occurs. The object path must
be the identifier of the modem (typically
the serial-id or IMEI of the HW).
booting Modem is powered up (flashed version)
or Modem is powered up and firmware upload
is completed. (flashless version)
upgrading Firmware upgrade on going
or Flashing manager under execution -
modem in service mode.
on Modem has booted and is ready for use.
This implies that all AT channels are
available, the modem might be in
e.g. flight mode.
dumping Modem has crashed and dump is ongoing
off Modem is powered off.
is this the full API or only part of it. If it is just a part of it,
please send the full API for the daemon. Just looking at this piece, I
am not really thinking that this is a good API. It is actually pretty
much broken :(
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 0/4] Atom for Neighbour Cell Info
Hi Antti, This series of patches implements an interface for client application to fetch the ECID information of neighbouring cells using DBUS. src/cell-info.c | 537 +++ include/cell-info.h | 66 +++ include/dbus.h |1 + src/ofono.h|1 + Makefile.am |4 ++-- I am missing the D-Bus API documentation in this patch. I know that proposals have been posted, but you need to pick that up and make it part of your patchset. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] udev: Fix warning in compilation
Hi Antti, plugins/udev.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) patch has been applied. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 0/4] Automatic provisioning of GPRS context settings
Hi Jukka, Here is a first attempt to implement automatic provisioning of Internet and MMS GPRS context settings. (Internet Access Provider database TODO item). In case there are no previously configured contexts found during gprs atom registration, this code tries to provision Internet and MMS contexts based on MCC, MNC and SPN (Service Provider Name) values read from SIM. Settings are read from an operator settings database. Settings database is CSV (comma separated values) formatted file(s) with fields for: (type=INTERNET|MMS protocol=ipv4|ipv6) MCC,MNC,SPN,type,UI name, APN, username, password, protocol, proxy IP address, proxy port, MMS server URL e.g. file /etc/ofono/operator-settings/50-default.csv: 001,01,test,INTERNET,Network Tester GPRS,internet,, 246,81,oFono,INTERNET,Phonesim Internet,internet.apn,,,ipv4,,, 246,81,oFono,MMS,Phonesim MMS,mms.apn,mmsuser,mmspass,ipv4,10.10.10.10,8080,http://192.168.0.111:8002 This format is loosely based on what was used in Nokia N900 for similar use. I am really not set on a file format, but my obvious question is if we don't wanna better use keyfile or XML based database since that are the file formats we are currently using inside oFono. We have not used CSV at all so far. My vote would go for keyfile or XML since it is a bit more self explanatory with its fields. And the order of values doesn't really matter. The one thing that I don't like about CSV is that you have no real flexibility with its format. Especially coming think about that we might have to extend this additional information for IMS or operator specific behavior. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: oFono release plan?
Hi Sjur, Do you have a release plan defined for oFono? When will you release oFono 1.0? We do not have a concrete plan as of yet. For the most part we were quite happy with the current set of oFono APIs, however with LTE support on the horizon we might have to revisit some of them. the upcoming LTE support holds us a little bit back. So Denis and I are a bit careful about calling it 1.0 just yet. In general the rule was to go for 1.0, when the D-Bus API seemed to be working out nicely. For most atoms we have that right now and I am pretty happy with the current API. It might need one additional in depth review, but changes would be absolutely minor (besides LTE of course). And then we wanted to get at least one GCF pre-certification result before calling it 1.0 for real. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/4 v2] Network Time plugin
Hi Antti, please do not top-post on this mailing list. Could someone review this patch. It has been waiting for review a while now. Thanks. snip This series of patches introduces the network time part of the NITZ feature as outlined in 3GPP spec 22.042. The Network Time plugin has two DBUS interfaces for client applications: notification signal and polling method call. The time information consists of three dictionary entries: 1) time and date in seconds from epoch (renormalized to time indicatation arrival time); 2) daylight saving time; 3) timezone. I am still saying that the plugin should monitor the presence of timed and then just send a D-Bus message to timed. That saves us the problem with the timestamping. And in case timed is not running it should just set the current time directly. I really prefer that we don't hand out timestamps over the D-Bus API. That seems wrong to me. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCHv2 1/2] stemodem: Create network interfaces statically
Hi Sjur, Changes: o Restructure code so interfaces are created statically when probe is called, instead of creating interfaces dynamically at activation. o Changed debug messages. o Removed some of the unnecessary initializations at declaration. o No longer reporting default gateway for PtP IP Interface. o Bugfix: Handle network initiated deactivation. --- drivers/stemodem/gprs-context.c | 149 +- 1 files changed, 82 insertions(+), 67 deletions(-) looks good to me now. Patch has been applied. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCHv2 2/2] stemodem: Use RTNL to create network interfaces.
Hi Sjur, drivers/stemodem/gprs-context.c | 43 -- 1 files changed, 36 insertions(+), 7 deletions(-) patch has been applied. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCHv2] plugin: Add ste modem initd integration
Hi Sjur, + +/* ResetState requests resending of StateChange. */ +#define MID_RESEND_STATE ResendState This is a bad D-Bus API btw. Using a D-Bus method to trigger signal sending. You will wake up any listener for that signal. What is wrong with just having a GetState? My problem is that I need to get the path, or modem serial-number if you like, to the modem(s). As I don't know the start order I have to query the state at startup. So this will happens only once. The simples way for me to get the path is to send ResendState to path /. This will then send the state info for all modem paths. I don't think I have the path them available at connect... If you have any other ideas of how to query the modem instances I'm all ears? I think you need to resend the D-Bus API of your init daemon. I need to have a second look. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: oFono release plan?
Hi Aki, the upcoming LTE support holds us a little bit back. So Denis and I are a bit careful about calling it 1.0 just yet. Can you elaborate here? I thought the conclusion of our discussions was that the D-Bus API will see practically no changes due to LTE. we don't know that yet for sure. They might be all internal, but there might be also D-Bus visible changes. We will see once LTE support lands in oFono. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/4 v2] Network Time plugin
Hi Aki, I am still saying that the plugin should monitor the presence of timed and then just send a D-Bus message to timed. That saves us the problem with the timestamping. There is no problem. If you still think there is a problem, you need to continue the previous thread on this subject and prove your point. And in case timed is not running it should just set the current time directly. You're welcome to write such a plugin -- this is why nettime is a plugin API after all. It might make sense in some platforms, especially those that don't have a working monotonic clock... true, but as long as you guys are proposing an official org.ofono API it has to fit in a general context of oFono. I really prefer that we don't hand out timestamps over the D-Bus API. That seems wrong to me. No timestamp is sent. Please read the patches. So that got fixed. Is this really enough for you guys to just normalize the value that you are getting? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: PATCH: Enable udev-based autodetection of calypso modem on Freerunner
Hi Denis,
I think the better way would be to drop a udev rule directly into
/etc/udev.d or similar. The rule should be as simple as:
KERNEL==ttySAC0, ENV{OFONO_DRIVER}=calypso
Do you mean in another file than 97-ofono.rules?
Yep.
I prefer not to have this inside ofono.git at all. We also leave the IFX
specific ones out. It is really up to the package maintainers to get
this sorted.
We could document this as Freerunner specific notes to point people into
the right direction. And we should maybe to the same for IFX since that
is currently only documented in the GIT commit logs.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: PATCH: Enable udev-based autodetection of calypso modem on Freerunner
Hi Denis,
We could document this as Freerunner specific notes to point people into
the right direction. And we should maybe to the same for IFX since that
is currently only documented in the GIT commit logs.
Documentation inside the individual modem driver is the way to go. And
IFX isn't even documented in git commit logs. I looked ;)
commit 3443a7a177fbaca24c84658968aff0a55db8a51d
Author: Marcel Holtmann mar...@holtmann.org
Date: Sat Sep 18 22:08:41 2010 +0900
udev: Add support for IFX device detection
The IFX device detection is pretty static, but instead of using
a static configuration file it is important to know when the device
node is actually present. For this udev is perfect. Adding a simple
udev rule is all that it takes:
KERNEL==ttyIFX[0-9]*, ENV{OFONO_DRIVER}=ifx
With this rule for every TTY with the kernel name like ttyIFX0, a new
modem will be added and the IFX modem plugin driver requested for it.
this is not enough?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: PATCH: Enable udev-based autodetection of calypso modem on Freerunner
Hi Denis,
We could document this as Freerunner specific notes to point people into
the right direction. And we should maybe to the same for IFX since that
is currently only documented in the GIT commit logs.
Documentation inside the individual modem driver is the way to go. And
IFX isn't even documented in git commit logs. I looked ;)
commit 3443a7a177fbaca24c84658968aff0a55db8a51d
Author: Marcel Holtmann mar...@holtmann.org
Date: Sat Sep 18 22:08:41 2010 +0900
udev: Add support for IFX device detection
The IFX device detection is pretty static, but instead of using
a static configuration file it is important to know when the device
node is actually present. For this udev is perfect. Adding a simple
udev rule is all that it takes:
KERNEL==ttyIFX[0-9]*, ENV{OFONO_DRIVER}=ifx
With this rule for every TTY with the kernel name like ttyIFX0, a new
modem will be added and the IFX modem plugin driver requested for it.
this is not enough?
Then I didn't look far back enough (or I'm simply blind). But I still
prefer this to be inside the driver or HACKING.calypso for easier access.
I am with you that this needs to be documented better than GIT commit
logs.
However I do prefer doc/calypso-modem.txt and doc/ifx-modem.txt though
since I don't wanna clutter the root directory.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2] ifx: Adding modem selftest to Infineon modem
Hi Robertino,
diff --git a/plugins/ifx.c b/plugins/ifx.c
index 2f4c65b..3647dbc 100644
--- a/plugins/ifx.c
+++ b/plugins/ifx.c
@@ -71,6 +71,8 @@
#define GPRS3_DLC 4
#define AUX_DLC 5
+#define IFX_SELF_TESTS_TIMEOUT 5
+
this is not what I meant actually. Adding a comment for the
g_timeout_add_seconds is just fine.
What I wanted to know is where the actual value came from. Is 5 seconds
enough? How do we know the time a test takes?
static char *dlc_prefixes[NUM_DLC] = { Voice: , Net: , GPRS1: ,
GPRS2: , GPRS3: , Aux: };
@@ -80,6 +82,18 @@ static const char *dlc_nodes[NUM_DLC] = { /dev/ttyGSM1,
/dev/ttyGSM2,
static const char *none_prefix[] = { NULL };
static const char *xdrv_prefix[] = { +XDRV:, NULL };
+static const char *empty_prefix[] = { , NULL };
This is still wrong. See my comment from the original email. I am not
sure you really know what { , NULL } means.
+struct ifx_self_tests {
+ char *test_desc;
+ char *at_cmd;
+};
+
+static const struct ifx_self_tests mst[] = {
+ { RTC GTI Test, a...@rtc:rtc_gti_test_verify_32khz() },
+ { Device Version Test, a...@vers:device_version_id() },
+ { NULL, NULL }
+};
No need to declare the struct before assigning it. Just do it all in
once. And fix up the indentation for the values. Just one tab please.
struct ifx_data {
GIOChannel *device;
@@ -99,6 +113,8 @@ struct ifx_data {
int audio_loopback;
struct ofono_sim *sim;
gboolean have_sim;
+ guint self_test_timeout;
+ int self_test_idx;
};
static void ifx_debug(const char *str, void *user_data)
@@ -545,6 +561,64 @@ static gboolean mux_timeout_cb(gpointer user_data)
return FALSE;
}
+static gboolean self_test_timeout_cb(gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct ifx_data *data = ofono_modem_get_data(modem);
+
+ ofono_error(Modem %s: TIMED OUT,
+ mst[data-self_test_idx].test_desc);
+
+ g_source_remove(data-self_test_timeout);
+ data-self_test_timeout = 0;
+
+ shutdown_device(data);
+ ofono_modem_set_powered(modem, FALSE);
+
+ return FALSE;
+}
I am stopping right here now actually. Please fix my review comments
from the initial review as well. This function is still broken.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 8/9] udev: Add cdmagen
Hi Dara, struct ofono_modem *modem; @@ -533,6 +552,8 @@ done: add_isi(modem, udev_device); else if (g_strcmp0(driver, n900) == 0) add_isi(modem, udev_device); + else if (g_strcmp0(driver, cdmagen) == 0) + add_cdmagen(modem, udev_device); } this is actually wrong. The generic drivers running against phonesim should not be done via udev. We did remove atgen for a reason actually since it was not really useful. Even the isigen driver needs to be renamed into isiusb or usbpn in the long term. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v2 7/9] ofono-rules: Add cdmagen device
Hi Dara,
plugins/ofono.rules |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/plugins/ofono.rules b/plugins/ofono.rules
index da8a8ef..34698f0 100644
--- a/plugins/ofono.rules
+++ b/plugins/ofono.rules
@@ -429,6 +429,10 @@ ATTRS{idVendor}==0930, ATTRS{idProduct}==1311,
ENV{OFONO_DRIVER}=mbm
# Nokia Internet Stick CS-10
ATTRS{idVendor}==0421, ATTRS{idProduct}==060e, ENV{OFONO_DRIVER}=nokia
+# Nokia CDMA Device
+ATTRS{idVendor}==0421, ATTRS{idProduct}==023e,
ENV{OFONO_DRIVER}=cdmagen
+ATTRS{idVendor}==0421, ATTRS{idProduct}==00b6,
ENV{OFONO_DRIVER}=cdmagen
+
since this is Nokia specific device, then using nokiacdma would be a
better name. Or using OFONO_DRIVER=nokia NOKIA_MODE=cdma and sharing the
driver might be useful.
It really all depends how much they have in common. So what kind of
hardware is this actually? A phone or a real USB dongle?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: Voice call audio routing
Hi Niko, While testing an e169 huawei card I was able to make voice calls and hear something with aplay and /dev/ttyUSB1. On the openmoko/freerunner is a matter of HW switches, on the n900 IIRC is done with pulseaudio. I guess that voice call audio routing is not in oFono plans, if I'm correct is there a reference project (may be not depending deeply on meego) that abstracts that task in an extensible/pluggable way? check tools/huawei-audio.c for a really simple example of the audio processing. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifx: adding Infineon modem self test
Hi Waldo, The conclusion was that these two test commands should be issued from the AP to ensure that the modem is functioning properly. I am not aware of the conclusion. My understanding is still that the modem firmware is suppose to do its selftests all by itself. It does not. this is really new to me. Last time this has been talked about, that was different. So what is the reasoning behind doing these selftests from the host. It makes it easier for the host to record diagnostics / error codes this way. At the moment this is limited to recording it in the log file, as oFono doesn't provide a good way for reporting back error conditions when powering up a modem fails. There is nothing more that you can provide to the host anyway. Just having one AT command to read the selftest log from the modem would have been just fine. Right now I am not seeing any advantage why the host should execute selftests. And essentially this really only makes sense once the oFono core can mark a modem as broken and then just not even try to re-enable it. We don't even have a state for this since it was never a requirement to have such a state. While Lockdown comes pretty close, it is semantically something totally different. There is also the other thing, that we have no numbers on the expected execution time of these selftests. This needs to be documented inside the code. Otherwise this gets out of control. And just to make this clear. These are run on every oFono modem enabling execution. This is different from just on initial modem power on. Are you okay with the impact on modem enabling time? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] ifx: adding Infineon modem self test
Hi Robertino,
static const char *none_prefix[] = { NULL };
static const char *xdrv_prefix[] = { +XDRV:, NULL };
+static const char *empty_prefix[] = { , NULL };
this is essentially to just passing NULL as argument. What are you
trying to achieve here?
+static const char *modem_self_tests[][2] = {
+ { RTC Test, a...@rtc:rtc_gti_test_verify_32khz() },
+ { Version Info Test, a...@vers:device_version_id()
},
+ { NULL, NULL } };
The coding style is broken here. Please check the oFono source code for
example on how to format these type of array correctly.
In addition the string array is wrong. It should be a struct array. The
magic of [1] and [2] for picking the command or the text string is not
intuitive and leads to unreadable code.
struct ifx_data {
GIOChannel *device;
@@ -99,6 +105,8 @@ struct ifx_data {
int audio_loopback;
struct ofono_sim *sim;
gboolean have_sim;
+ guint self_test_timeout;
+ int self_test_idx;
};
static void ifx_debug(const char *str, void *user_data)
@@ -545,6 +553,82 @@ static gboolean mux_timeout_cb(gpointer user_data)
return FALSE;
}
+static gboolean self_test_timeout_cb(gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct ifx_data *data = ofono_modem_get_data(modem);
+
+ ofono_error(Timeout with modem self_test);
You need an extra empty line here. The error is logically separated.
+ g_source_remove(data-self_test_timeout);
You can not remove a source in its own callback. Have you tested this
code path actually?
+ data-self_test_timeout = 0;
+
+ shutdown_device(data);
You can not use shutdown_device here since the multiplexer is not ready
yet. If you decide the execute the selftests before bringing up the
multiplexer then this is a different error path.
You need to cleanup data-dlcs[AUX_DLC] and data-device in this failure
case.
+ ofono_modem_set_powered(modem, FALSE);
This needs an extra empty before the return statement.
+ return FALSE;
+}
+
+static void ifx_self_test_get_device_resp(GAtResult *result, int test_id)
+{
The function is just wrong in conjunction with your array approach.
+ GAtResultIter iter;
+ const char *str;
+
+ ofono_info(Modem Response: %s,
+ modem_self_tests[test_id][0]);
Can you give an example on a positive and negative selftest response
here. I don't wanna spam the logs with details if everything is fine.
This should use ofono_error and that only in case of an error.
+ g_at_result_iter_init(iter, result);
+
+ while (g_at_result_iter_next(iter, NULL)) {
+
+ if (g_at_result_iter_next_string(iter, str))
+ ofono_info(Modem Response: %s, str);
+ }
What is this while loop actually doing? How does a response look like.
+}
+
+static void ifx_self_test_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_modem *modem = user_data;
+ struct ifx_data *data = ofono_modem_get_data(modem);
+
+ if (ok) {
This needs to be a if (!ok) here actually and then leaving this function
with a simple error case.
Having the positive handling nested is not a good idea and we don't
really do it that way.
+
+ if (data-self_test_timeout 0) {
+ g_source_remove(data-self_test_timeout);
+ data-self_test_timeout = 0;
+ }
+
+ ifx_self_test_get_device_resp(result, data-self_test_idx);
+ data-self_test_idx++;
+
+ if (modem_self_tests[data-self_test_idx][1] != NULL) {
+
No empty line here.
+ g_at_chat_send(data-dlcs[AUX_DLC],
+ modem_self_tests[data-self_test_idx][1],
+ empty_prefix, ifx_self_test_cb, modem, NULL);
+
+ data-self_test_timeout = g_timeout_add_seconds(10,
+ self_test_timeout_cb, modem);
+ return;
No empty line here, but this is not needed in case of (!ok) anyway.
+ } else {
+
No empty line here either.
+ /* Enable MUX Channels */
+ data-frame_size = 1509;
+ g_at_chat_send(data-dlcs[AUX_DLC],
+ AT+CMUX=0,0,,1509,10,3,30,,, NULL,
+ mux_setup_cb, modem, NULL);
+
+ data-mux_init_timeout = g_timeout_add_seconds(5,
+ mux_timeout_cb, modem);
+ return;
+ }
+ }
With proper if (error) { ... ; return; } coding style this function
becomes a lot more readable.
+
+ ofono_error(Modem %s: FAIL, modem_self_tests[data-self_test_idx][0]);
+ shutdown_device(data);
Again here, the
Re: [PATCH 0/5] Call Counters (2nd)
Hi Remi, Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult. My take here is that a granularity of 1 minute is enough. There are definitely call fares with sub-minute granularity. The minute is definitely INSUFFICIENT. let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes. As said earlier, this is about the talk time. The scenario is a user ejects the battery during an already long-standing call or gets the device to crash or reset, gets billed, and comes and complain to its operator that (s)he gets overcharged. The counters will be much more wrong if we do not flush them to disk frequently. We do not need to implement the billing policy for that. This is only about the total talk time. If we talk about correct billing minutes then you are just opening pandora's box. Since we don't know the billing. And difference between air time, incoming/outgoing calls, multiparty calls, hold calls etc. and their billing schemes make this just insane. Sure. We don't wants this. So what is the actual requirement here. So far ever single answer was not satisfying. And that is why I proposed to just make this count the talk time. The requirement is that the user cannot deduct (much) talk time from the call counters. is actually everybody in agreement here that we talk about actual time spent on the phone talking? Denis and myself clearly see it that this is a sensible approach to overall call counters. And if that is the case, then this maps closely to what PA has to track anyway. The more and more we talk about this, the more and more it makes sense to me to do this as a plugin to PA that stores the overall call time values into Tracker. And then can also be reset via Tracker. This would satisfy all my concern that I have from an process wakeup and IO utilization overhead and battery consumption point of view. Doing this every 10 seconds and displaying it on a per second level sounds insane to me. So I made a lengthy call to my mum this morning, using a desk phone. And it was showing minute:second, not just minutes. I have never seen a phone that does not show seconds and it would look pretty dumb to me. You do realize that this is NOT the feature we are talking about here. The actual display of the duration of a call is pretty simple and currently easy to handle inside the UI. And that can be done up to the millisecond display if you or your UI designer wants it. The proposed call counters here are long term counters showing your overall time. So showing minutes seems to be precise enough. Showing minutes, as in flushing the counters every 60 seconds might work, but I'd rather make this a configurable knob. That said, I do believe the stored value has to be more precise than minutes. Otherwise per call error may add up far too quickly. I don't see this as a problem at all. This does not add up. So if you loose 59 seconds in a 4 hours call, then that is pretty much statistically irrelevant. And that is only the case if you magically loose your battery. In case you run out of battery or end the call properly, you will still get the accurate counter to the second. Since the device management daemon or oFono will inform you about it. What you should really ask yourself is what you present to the user. If you use your phone for 3 phone calls that are less than three seconds, you might wanna display seconds. However in that case you have the accurate counter when ending the call in the first place. If you loose your battery and have not used the phone longer than a minute, why bother. This is not the problem that needs to be solved. If you spent something crazy like 60 hours on the phone per month and then loose 59 seconds, it makes no difference either. At that point that inaccuracy is statistically irrelevant and can be ignored. And again, this is only a problem if you battery magically gets loose and flies away. Otherwise you are accurate to the second. So in conclusion having an IO sync of the ongoing call every 60 seconds seems to be reasonable enough. And at the same time you keep a down to the second call time in case of a healthy device. With all this in mind. How often does someone magically loose the battery and then goes complain to someone about a big difference in the bills. Or is this more an esoteric feature request. Can we not try to solve this sensible without going overboard and trying to solve world hunger ;) Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] ifx: adding Infineon modem self test
Hi Waldo, Adding Infineon modem selftest to the plugin. It executes couple of AT commands, and based on the responses, it continues with ifx modem enabling or powers the modem down. didn't we conclude that the modem should do all these by itself? My understanding is that the modem executes these. And not that we have to trigger them. The conclusion was that these two test commands should be issued from the AP to ensure that the modem is functioning properly. I am not aware of the conclusion. My understanding is still that the modem firmware is suppose to do its selftests all by itself. So what is the reasoning behind doing these selftests from the host. Right now I am failing to see the benefit of these. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] ifx: adding Infineon modem self test
Hi Robertino, Adding Infineon modem selftest to the plugin. It executes couple of AT commands, and based on the responses, it continues with ifx modem enabling or powers the modem down. didn't we conclude that the modem should do all these by itself? My understanding is that the modem executes these. And not that we have to trigger them. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/5] Call Counters (2nd)
Hi Remi, Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult. My take here is that a granularity of 1 minute is enough. There are definitely call fares with sub-minute granularity. The minute is definitely INSUFFICIENT. let me repeat my question here. Does this suppose to be represent spent time on calls (what I called talk time) or actual billing minutes. If we talk about correct billing minutes then you are just opening pandora's box. Since we don't know the billing. And difference between air time, incoming/outgoing calls, multiparty calls, hold calls etc. and their billing schemes make this just insane. So what is the actual requirement here. So far ever single answer was not satisfying. And that is why I proposed to just make this count the talk time. Doing this every 10 seconds and displaying it on a per second level sounds insane to me. So I made a lengthy call to my mum this morning, using a desk phone. And it was showing minute:second, not just minutes. I have never seen a phone that does not show seconds and it would look pretty dumb to me. You do realize that this is NOT the feature we are talking about here. The actual display of the duration of a call is pretty simple and currently easy to handle inside the UI. And that can be done up to the millisecond display if you or your UI designer wants it. The proposed call counters here are long term counters showing your overall time. So showing minutes seems to be precise enough. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/3] Attach GPRS on demand
Hi Mika, I'm not quite sure what you mean here. There are many different cases, where the network can detach a UE from GPRS service. See possible detach causes in 24.008. Currently, oFono does not recover at all. Trying to figure out when GPRS is again available can get pretty complicated and the different detach causes require different handling. IMO, the simplest approach by far is to retry GPRS attach when someone actually needs a PDP context. So here's the problem, ConnMan is in charge of activating the context on Meego. ConnMan activates the context once we're attached. So how do you expect your 'on-demand' re-attach to work exactly? ConnMan really should not care whether we are attached or not. Why do you need a trigger in ConnMan, anyway? As far as I can see, a GPRS connection should only be activated if some client of ConnMan requests it. so what about the cases when roaming is allowed or not? These needs to be taken into account and that is oFono's job. That is the reason why ConnMan follows the attach state. Since we don't wanna activate a context when roaming and data roaming is not allowed. Besides, 24.008 cause codes give us plenty of hints of whether / when to re-attach, and only a few of them require 'special' handling. I still think that we should come up with some strategy to re-attach automatically when detached by the network. Even if you can come up with an algorithm, testing it is very very challenging. There are plenty of differences in operator networks and it is very difficult to cover all cases. Making sure that the algorithm works requires extensive IOT and Field testing. We really don't want a case, where oFono fails to re-attach for whatever reason. We also don't want the case where oFono has not yet attempted to re-attach (e.g. on a timer) and a PDP context activation fails, even though GPRS would actually be available. I don't think such an algorithm is hard. Either we are forbidden, then we wait until we switch to a new cell. Otherwise we will just retry to attach. For the above reasons, retrying attach on PDP context activation makes sense as a safe-guard, regardless of whether we have a re-attach algorithm or not. We use on-demand attach in pretty much all our products (except for certain operator specific variants) precisely because it is certain to work. No funny business. If there is GPRS service, you get a connection. It is also an approach that should work with any AT modem as well. This is really not ConnMan's problem and I don't wanna make it ConnMan's problem. I am really against just pushing this problem off to someone else. And in ConnMan we have even less information to decide what happens when context activation fails. The algorithm to handle such rare error conditions smoothly becomes more complicated than making this easier. So I agree with Denis that we need to fix this inside oFono and just try to intelligently re-attach. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/5] Call Counters (2nd)
Hi Kai, - lots of modems still handle all audio and PA will know nothing about calls at all with these modems actually Denis raised the same question, but then again this is for a product specific requirement. And for that product we know that PA will do the audio processing. not really. We need modem adaptation for call counters and need an API that works with all modems. And I'd assume other handset vendors need such an API as well (either in oFono or somewhere else). Important for me is to weight the extra costs of IO and CPU consumption when doing this inside oFono. And since ofonod itself would actually not wake up during a phone call, I think this is not a good fit. I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio). So the big cost of bringing CPU, memories et al online are already taken at this point, and the additional cost of running ofonod for a while is minimal (compared to waking up some non-realtime thread of pulseaudio, or some other component, to do the same). this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 0/5] Call Counters (2nd)
Hi Kai, I share the concern for the IO/CPU cost, but I don't think it matters much in which daemon this is done. Especially if some slack is allowed for the timers (which should be the case), ofonod will be scheduled when the CPU is anyways woken up (e.g. modem/audio interrupts wake up pulseaudio). this is not really true. We can not wakeup ofonod every single second. You might wanna start running powertop. uhm, but I'm not claiming that. I was just stating that moving the timers to e.g. pulseaudio in this case won't save much if anything (the CPU will be woken up anyways, and the cost between scheduling ofonod or a thread from PA, has really no difference to overall consumption.. the CPU is woken up anyways and roughly the same code to handle the timer is run). So whether this code is in oFono or elsewhere, does not matter much (to overall power consumption). The main question is of course how often the counters are synced. actually it does matter since you have no extra context switch and in addition you not accidentally wake up PA and then ofonod. You have one centralized wakeup of one thread. Of course this should be smart and done along with the PA audio processing and not async to that one. If we consider that the only sensible thing is to track the actual talking time, then PA becomes a nice choice for this. This doesn't mean that you should be implementing it, but I am still maintaining that this would be a pretty damn smart way of solving this efficiently. Personally I think the every-10sec interval is too short. It's also highly system specific when wakeups start to get too costly, so picking up one value seems difficult. My take here is that a granularity of 1 minute is enough. Doing this every 10 seconds and displaying it on a per second level sounds insane to me. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: CAIF Protocol : oFono
Hi Sjur, We understand that CAIF is coming as kernel driver in linux 2.6.36. We are trying to write some test application which will make use of CAIF kernel driver to interact with ST-Ericsson Modem. When we connect any modem how OFono recognizes it? Is it based on rule mentioned in 97-ofono.rules? or will it consider modem.conf file? modem.conf support was removed from oFono a while ago. I have sent patches and discussed solutions for startup on this list. In a smartphone configuration STE will use a modem init daemon to control start/stop/restart of the modem, so our proposal is that the STE plugin uses the DBUS API from this daemon to recognice the STE modem. Alternatively we could use udev rules and subscribe to CAIF interface state changes. I'm still waiting for review comments or feedback for my patches in this area (since 17. Nov). this slipped through. Sorry about that, but we just had way too many emails lately. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RESEND PATCH] plugin: Add ste modem initd integration
Hi Sjur,
This patch introduces auto discovery of ST-Ericsson modems.
ST-Ericsson modems (M57XX, M7XX, M74XX) are managed by a
Modem Init Daemon that is responsible for start/stop/restart
flashing etc. This STE plugin monitors the modem state exposed
from the Modem Init Damon Dbus API. When the modem is in state
on the STE modem is created and registered.
Currently only a single modem instance is supported,
support for multiple modems should be added in the future.
I am not really happy about this here. I prefer that we do that right
from the beginning. Multiple modem support should be default.
---
Makefile.am |5 ++
configure.ac |6 ++
plugins/stemid.c | 195
++
3 files changed, 206 insertions(+), 0 deletions(-)
create mode 100644 plugins/stemid.c
diff --git a/Makefile.am b/Makefile.am
index f841b4c..aaf5de5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -81,6 +81,11 @@ gatchat_sources = gatchat/gatchat.h gatchat/gatchat.c \
udev_files = plugins/ofono.rules
+if STE_MODEM_INITD
+builtin_modules += stemid
+builtin_sources += plugins/stemid.c
+endif
+
if UDEV
builtin_modules += udev
builtin_sources += plugins/udev.c
diff --git a/configure.ac b/configure.ac
index c0f4217..4dff372 100644
--- a/configure.ac
+++ b/configure.ac
@@ -175,6 +175,12 @@ AC_ARG_ENABLE(datafiles,
AC_HELP_STRING([--disable-datafiles],
AM_CONDITIONAL(DATAFILES, test ${enable_datafiles} != no)
+AC_ARG_ENABLE(ste_modem_initd, AC_HELP_STRING([--disable-ste-modem-initd],
+ [disable auto discovery of STE modem using modem init
daemon]),
+ [enable_ste_modem_initd=${enableval}])
+
+AM_CONDITIONAL(STE_MODEM_INITD, test ${enable_ste_modem_initd} != no)
+
Don't bother with the conditional stuff. Just always built in the
plugin. There is no harm here and I can sort this out later cleanly when
we have a bit better understanding of what requires what.
if (test ${prefix} = NONE); then
dnl no prefix and no localstatedir, so default to /var
if (test $localstatedir = '${prefix}/var'); then
diff --git a/plugins/stemid.c b/plugins/stemid.c
new file mode 100644
index 000..7041e5e
--- /dev/null
+++ b/plugins/stemid.c
@@ -0,0 +1,195 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2010 ST-Ericsson AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include errno.h
+#include stdio.h
+#include fcntl.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include net/if.h
+
+#include gdbus.h
+#include glib.h
+#include gatchat.h
+
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include ofono/plugin.h
+#include ofono/log.h
+#include ofono/modem.h
+#include ofono/dbus.h
+#include ofono/version.h
+
+/*
+ * ST-Ericsson's modem init daemon defines the signal StateChange
+ * and the method GetState. When state is on the STE modem is
+ * created and registered.
+ */
+#define STATUS_CHANGED StateChange
+#define MID_SERVICE com.stericsson.modeminit
+#define MID_INTERFACEMID_SERVICE .Modem
+#define GET_STATEGetState
+#define MID_STATE_ON on
+#define MID_STATE_DISCONNECT disconnect
+#define TIMEOUT 5000
+
+static struct ofono_modem *ste_modem;
+static guint mid_api_watch;
+static guint mid_state_watch;
+
+static void handle_stemodem(const char *state)
+{
+
+ DBG(state:%s, state);
+
+ if (strcmp(state, MID_STATE_ON) == 0) {
+ int err;
+
+ if (ste_modem != NULL)
+ return;
+
+ ste_modem = ofono_modem_create(ste, ste);
If you do such an init daemon anyway, can't you not at least also expose
the serial number in a proper format?
+ DBG(register STE modem);
+ err = ofono_modem_register(ste_modem);
+ } else {
+
+ if (ste_modem == NULL)
+ return;
+
+ ofono_modem_remove(ste_modem);
+ ste_modem = NULL;
+ }
+}
+
+static void mid_getstate_reply(DBusPendingCall *call, void *user_data)
+{
+ DBusMessage *reply;
+ char *state;
+
+ reply = dbus_pending_call_steal_reply(call);
+
+ if
Re: [RESEND PATCHv2 2/2] stemodem: Use RTNL to create network interfaces.
Hi Sjur,
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index bfc0d65..21ca126 100644
--- a/drivers/stemodem/gprs-context.c
+++ b/drivers/stemodem/gprs-context.c
@@ -47,6 +47,7 @@
#include stemodem.h
#include caif_socket.h
#include if_caif.h
+#include caif_rtnl.h
#define MAX_CAIF_DEVICES 4
#define MAX_DNS 2
@@ -172,12 +173,20 @@ static struct conn_info *conn_info_create(unsigned int
channel_id)
return connection;
}
-/*
- * Creates a new IP interface for CAIF.
- */
-static gboolean caif_if_create(struct conn_info *conn)
+static void rtnl_callback(int ifindex, const char *ifname, void *user_data)
{
- return FALSE;
+ struct conn_info *conn = user_data;
+
+ if (ifindex 0) {
+ conn-created = FALSE;
+ ofono_error(Failed to create caif interface %s,
+ conn-interface);
+ return;
+ }
+
+ strncpy(conn-interface, ifname, sizeof(conn-interface));
+ conn-ifindex = ifindex;
+ conn-created = TRUE;
}
/*
@@ -185,6 +194,18 @@ static gboolean caif_if_create(struct conn_info *conn)
*/
static void caif_if_remove(struct conn_info *conn)
{
+ if (!conn-created)
+ return;
+
+ if (caif_rtnl_delete_interface(conn-ifindex) 0) {
+ ofono_error(Failed to delete caif interface %s,
+ conn-interface);
+ return;
+ }
+
+ DBG(removed CAIF interface ch:%d ifname:%s ifindex:%d\n,
+ conn-channel_id, conn-interface, conn-ifindex);
+ return;
You don't need return here. Please remove that.
}
static void ste_eppsd_down_cb(gboolean ok, GAtResult *result,
@@ -526,7 +547,7 @@ static int ste_gprs_context_probe(struct
ofono_gprs_context *gc,
GAtChat *chat = data;
struct gprs_context_data *gcd;
struct conn_info *ci;
- int i;
+ int i,err;
Extra whitespace between i and err.
gcd = g_new0(struct gprs_context_data, 1);
gcd-chat = g_at_chat_clone(chat);
@@ -539,7 +560,14 @@ static int ste_gprs_context_probe(struct
ofono_gprs_context *gc,
ci = conn_info_create(i+1);
if (!ci)
return -ENOMEM;
- caif_if_create(ci);
+ err = caif_rtnl_create_interface(IFLA_CAIF_IPV4_CONNID,
+ ci-channel_id, FALSE,
+ rtnl_callback, ci);
+ if (err 0) {
+ DBG(Failed to create IP interface for CAIF);
+ return err;
+ }
+
g_caif_devices = g_slist_append(g_caif_devices, ci);
}
@@ -571,10 +599,12 @@ static struct ofono_gprs_context_driver driver = {
void ste_gprs_context_init()
{
+ caif_rtnl_init();
ofono_gprs_context_driver_register(driver);
}
void ste_gprs_context_exit()
{
+ caif_rtnl_exit();
ofono_gprs_context_driver_unregister(driver);
}
Are you sure you want rtnl_exit before removing the driver?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/3] plugins: Implementation of Network Time plugin
Hi Aki, where is this timed running? I prefer the plugin just send a D-Bus message to the timed directly instead of a Get/Changed API kind of thing. AFAIK, timed is in system bus. However, I fail to see how you can make this any simpler. In the end, one of the two entities has to implement a service that the other one uses. There also needs to be some synchronization for when the entities start up. A getter/signal API is also what timed uses in Harmattan, but of course if you have a better idea, I'm all ears. is timed actually open source and I can have a look at it? so what about this? Where is the timed respository? I really wanna have a look at it and see what it is doing. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/5] Call Counters (2nd)
Hi Aki, Here a proposal for call counters implementation for keeping track of the total incoming and outgoing call duration counters. Each established call instance is contributing to either of the call duration counters. The 2 counters are updated periodically when there is an established call and the information is stored in a file. The bookkeeping of the call duration counters are per IMSI number. The implementation makes use of the history framework which had to be expanded with a function for marking the beginning of a voice call. There is a D-Bus interface to call counters for reading and clearing the counters. This set looks good to me, and I believe you fixed the issues from previous review comments. Denis, are you ok with this? so Denis and I talked about this a little bit and I am not fine with this at all. Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API. My main concerns are here that we are waking up ofonod every 10 seconds and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API. What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here. In addition to that, what is the problem with just updating the stats after the call has ended? Are you really expecting realtime updates of call time stats for some hidden UI stats menu? This would be a really expensive change for just doing that. Has anybody looked at how we are doing realtime stats inside ConnMan? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/4] isimodem2.5: Changes to add isimodem2.5
Hi Jessica, Updates in Makefile.am - adding of isimodem2.5 Adding of drivers/isimodem2.5/ files to fully listed functionality. Regards, Jessica Nilsson --- Makefile.am| 36 +- drivers/isimodem2.5/call-barring.c | 503 ++ drivers/isimodem2.5/call-forwarding.c | 613 +++ drivers/isimodem2.5/call-settings.c| 1093 + drivers/isimodem2.5/call.h | 237 + drivers/isimodem2.5/cbs.c | 433 ++ drivers/isimodem2.5/checkpatch.pl | 2789 drivers/isimodem2.5/debug.c| 694 +++ drivers/isimodem2.5/debug.h| 66 + drivers/isimodem2.5/devinfo.c | 246 + drivers/isimodem2.5/gpds-context.c | 788 drivers/isimodem2.5/gpds.c | 395 ++ drivers/isimodem2.5/gpds.h | 295 ++ drivers/isimodem2.5/gss.h | 84 + drivers/isimodem2.5/info.h | 53 + drivers/isimodem2.5/isimodem.c | 534 +++ drivers/isimodem2.5/isimodem.h | 69 + drivers/isimodem2.5/isiutil.h | 64 + drivers/isimodem2.5/mce.h | 65 + drivers/isimodem2.5/network-registration.c | 1158 + drivers/isimodem2.5/network.h | 257 ++ drivers/isimodem2.5/phonebook.c| 1320 ++ drivers/isimodem2.5/radio-settings.c | 313 ++ drivers/isimodem2.5/simu_resps.h | 6800 drivers/isimodem2.5/sms.c | 869 drivers/isimodem2.5/sms.h | 188 + drivers/isimodem2.5/ss.h | 174 + drivers/isimodem2.5/ssn.c | 456 ++ drivers/isimodem2.5/timeout.h | 33 + drivers/isimodem2.5/uicc.c | 3316 ++ drivers/isimodem2.5/uicc.h | 253 ++ drivers/isimodem2.5/uicc_interface.h | 40 + drivers/isimodem2.5/ussd.c | 341 ++ drivers/isimodem2.5/voicecall.c| 1555 +++ 34 files changed, 26128 insertions(+), 2 deletions(-) create mode 100644 drivers/isimodem2.5/call-barring.c create mode 100644 drivers/isimodem2.5/call-forwarding.c create mode 100644 drivers/isimodem2.5/call-settings.c create mode 100644 drivers/isimodem2.5/call.h create mode 100644 drivers/isimodem2.5/cbs.c create mode 100755 drivers/isimodem2.5/checkpatch.pl create mode 100644 drivers/isimodem2.5/debug.c create mode 100644 drivers/isimodem2.5/debug.h create mode 100644 drivers/isimodem2.5/devinfo.c create mode 100644 drivers/isimodem2.5/gpds-context.c create mode 100644 drivers/isimodem2.5/gpds.c create mode 100644 drivers/isimodem2.5/gpds.h create mode 100644 drivers/isimodem2.5/gss.h create mode 100644 drivers/isimodem2.5/info.h create mode 100644 drivers/isimodem2.5/isimodem.c create mode 100644 drivers/isimodem2.5/isimodem.h create mode 100644 drivers/isimodem2.5/isiutil.h create mode 100644 drivers/isimodem2.5/mce.h create mode 100644 drivers/isimodem2.5/network-registration.c create mode 100644 drivers/isimodem2.5/network.h create mode 100644 drivers/isimodem2.5/phonebook.c create mode 100644 drivers/isimodem2.5/radio-settings.c create mode 100644 drivers/isimodem2.5/simu_resps.h create mode 100644 drivers/isimodem2.5/sms.c create mode 100644 drivers/isimodem2.5/sms.h create mode 100644 drivers/isimodem2.5/ss.h create mode 100644 drivers/isimodem2.5/ssn.c create mode 100644 drivers/isimodem2.5/timeout.h create mode 100644 drivers/isimodem2.5/uicc.c create mode 100644 drivers/isimodem2.5/uicc.h create mode 100644 drivers/isimodem2.5/uicc_interface.h create mode 100644 drivers/isimodem2.5/ussd.c create mode 100644 drivers/isimodem2.5/voicecall.c this is not gonna work this way. No one can review such a massive patch. Actually Evolution even refused to format this for me. So please split this into one patch per atom driver. In addition, I don't a point in a filename. So isimodem25 or isimodem2 or something like that please. I am open for proposals. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/4] gisi: Changes to prepare for isimodem2.5
Hi Jessica, This set of patches introduces the isimodem2.5. WG2.5 (isimodem2.5) Supported features list: General: Online / Offline mode (RF on/off) Voice call: MO/MT call Multiparty call (max 7 calls) Transfer call Swap calls Hold calls Hang up all Hang up specific call Disconnect reason (Network/local/remote) Send DTMF tones PS data: Primary PDP context (IPv4 only) APN: User name and password supported Attach mode: Manual (Automatic works as well, but not activated) Data flow control not activated (Not supported by Kernel) SMS: Send and receieve SMS Concatenated messages supported (up to 255 messages) Class 0 Delivery reports Read / Write SMSC to SIM card Bearer settings supported (CS or PS) Supplementary Services: Call Barring VoiceOutgoing VoiceIncoming Call Settings CalledLineRestriction HideCallerId CallingLinePresentation CalledLinePresentation VoiceCallWaiting CallingLineRestriction Call Forwarding Voice Not Reachable Voice Busy Voice No Reply Voice Unconditional USSD MO USSD MT USSD NOT SUPPORTED SSN CS Network: Network registration Scanning available networks Selecting automatically and manually the target network Changing RAT between GSM/UMTS/ANY Registration status: Cell ID, LAC, MNC, Current Technology (GSM, UMTS, EDGE, HSDPA, HSUPA, HSDPAHSUPA) Deregister RSSI (%) SIM: Read IMSI MSISDN (Subscriber numbers) SDN (Service Dialing Numbers) PIN/PIN2/PUK/PUK2 supported (reset/change/lock) Read file info from SIM Read FIle (Transparent, Linear Cyclic) * Some functionalities flagged out as ofono core is not using these Write File (Transparent, Linear Cyclic) * Some functionalities flagged out as ofono core is not using these MCC MNC CardIdentifier PreferredLanguages Export contacts(SIM phonebook): SIM and USIM cards supported Name Number (extension record supported) Additional number Email No limitiation in amount of records read from SIM CBS: CBS reception in GSM Subscribe Topics in range or specific value Phone Info: Revision of the modem SW IMEI This specific patch contains updates in Makefile.am, configure.ac and gisi to prepare the addition of isimodem2.5 Added 2 new files to gisi pipe_wg25.c and pipe_wg25.h, isimodem2.5 pipe implementation due to pipe handler not on modem side. this needs to be split into separate patches and the commit message needs to be a bit cleaner. Also is this in sync with the GISI re-write Aki is doing? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/5] Call Counters (2nd)
Hi Aki, so Denis and I talked about this a little bit and I am not fine with this at all. Next time, can you invite me to join your little talk? because you are not sitting next to me right now ;) Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API. We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable. Fair enough, but when I look at such a feature as a whole, then my question is when does it need to be shown? What is your user interaction requirement with this data? Andras, please explain what reasonable reliable means. and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API. What do you mean? Do you mean your iPhone has no such UI? I have actually tested this with an iPhone and it has such an UI element, but it is not realtime. It gets updated after the call has been completed. So why can't we just update/reset this in Tracker via the history plugin in a general way. I am failing to see the need for this inside oFono. It seems to me that doing this within the scope of the Tracker integration is a lot cleaner and better for CPU and IO usage. The reason these are not properties is just because it makes no sense to update the counters live. The UI can poll if it so wishes, but the poll interval is not something we want to decide. What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here. In addition to that, what is the problem with just updating the stats after the call has ended? Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear. I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit. You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could potentially misfunction in this area would be an emergency call. But that is a total different use case anyway. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/4] isimodem2.5: Changes to add isimodem2.5
Hi Jessica, So please split this into one patch per atom driver. We are starting to look at this split up. Do you have any other suggestions? I really want one patch per atom driver. In addition, I don't a point in a filename. So isimodem25 or isimodem2 or something like that please. I am open for proposals. Let's go for isimodem25 Please sync with Aki if it might not be better to do the vendor quirk system that we are using with atmodem. I am open here for suggestions and you guys have more experience in what can be shared and what is different. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/4]simutil: Changes to prepare for isimodem2.5
Hi Jessica,
updates in src/simutil.h
Adding some sim file id and sim dir id mostly related to phonebook usim/sim.
please write a proper commit message here. The subject is not acceptable
since it misleads what this patch is doing.
Also updates in src/... comments are not really useful. We have the
diffstat for this.
---
src/simutil.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/src/simutil.h b/src/simutil.h
index 92b2e0f..bc53255 100644
--- a/src/simutil.h
+++ b/src/simutil.h
@@ -19,6 +19,8 @@
*
*/
+#include types.h
+
What is this include for? Please remove it.
enum sim_fileid {
SIM_EFPL_FILEID = 0x2f05,
SIM_EF_ICCID_FILEID = 0x2fe2,
@@ -49,6 +51,25 @@ enum sim_fileid {
SIM_EFCBMIR_FILEID = 0x6f50,
SIM_EFCBMI_FILEID = 0x6f45,
SIM_EFCBMID_FILEID = 0x6f48,
+ SIM_EFSMSP_FILEID = 0x6f42,
+ SIM_EFIMSI_FILEID = 0x6F07,
+
+ /* Phonebook (USIM) */
+ SIM_EFPBR_FILEID = 0x4f30,
+ SIM_EFPSC_FILEID = 0x4F22,
+ SIM_EFCC_FILEID = 0x4F23,
+ SIM_EFPUID_FILEID = 0x4F24,
+ /* Phonebook (SIM) */
+ SIM_EFADN_SIM_FILEID = 0x6F3A,
+ SIM_EFEXT1_SIM_FILEID = 0x6F4A,
+};
So please be consistent with lower-case hex encoding. So 0x6f07 etc.
Also we should keep this information sorted. I know there is a sorting
bug in there that needs to be fixed as well.
And while at it, you could be the one that makes this enum finally
compliant to our coding style. This is one of our old left-overs that we
have get fixed. We just never got around to it. Are you up for such a
task?
So you could just fix the coding style in one patch, fix the sorting in
another and then add the new values.
+enum sim_dirid {
+ MF_FILEID = 0x3F00,
+ DFTELECOM_FILEID = 0x7F10,
+ DFGSM_FILEID = 0x7F20,
+ DFPHONEBOOK_FILEID = 0x5F3A,
+ DFMULTIMEDIA_FILEID = 0x5F3B
};
Please use a proper SIM_* prefix here and you can just put them into the
sim_fileid enum. However this should be a separate patch to get a clear
commit history of the changes.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 7/9] gdbus: explicitly compare pointers to NULL
Hi Lucas, This patch was generated by the following semantic patch (http://coccinelle.lip6.fr/) // smpl @fix disable is_null,isnt_null1@ expression *E; @@ - !E + E == NULL // /smpl --- gdbus/object.c | 24 gdbus/polkit.c |2 +- gdbus/watch.c | 21 ++--- 3 files changed, 23 insertions(+), 24 deletions(-) patch has been applied to all projects. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/5] Call Counters (2nd)
Hi Andras, Lets take this one step and please explain to me what your requirements and objectives are. I also wanna see a top to bottom from UI down to the modem usage of this API. We need a UI showing total MO and MT call times. They also need to be able to be reset, if the user so wishes. The data needs to be reasonably reliable. Fair enough, but when I look at such a feature as a whole, then my question is when does it need to be shown? What is your user interaction requirement with this data? Andras, please explain what reasonable reliable means. The call counters are shown to the user when he or she opens up an application/applet whatever UI component that is meant for showing this information. do we have a clear use case requirement from an UI point of view on how this is expected to be working. I checked with my iPhone and how it does it. Basically it just updates after the call and only after you re-entered that menu. So here again, do we have a requirement to make this realtime or not. And I mean that from an user interaction point of view. Coming to the reliability part, saving the call counters information often enough, gives us sort of hard guarantee that whatever happens with any subsystem, be that SW or HW, the call counters will stay enough accurate. Syncing to the permanent storage, based on our product requirements, should take place in fact every 5 sec, or could be configurable. Writing and syncing something to disk every 5 seconds costs us IO. Is this really a sacrifice that is acceptable. There might be some liability issues if for some reason the counters would loose time, the user my blame the phone manufacturer for the extra expenses incurred by inaccurate counters. To be honest the counters can not be considered accurate anyway. Only the billing system has the final say. and consuming heavy IO with writing this information to disk. In addition to that there is no clear UI usage for the getter API. What do you mean? Do you mean your iPhone has no such UI? I have actually tested this with an iPhone and it has such an UI element, but it is not realtime. It gets updated after the call has been completed. So why can't we just update/reset this in Tracker via the history plugin in a general way. I am failing to see the need for this inside oFono. It seems to me that doing this within the scope of the Tracker integration is a lot cleaner and better for CPU and IO usage. We can discuss the place of the call counters plugin, but I think using the ofono history framework is a reasonable choice, with the note that the it needs to be expanded with a history function called in the beginning of a call. The call counters plugin could be an optionally compiled/included (dynamic) plugin or downgraded to experimental status. So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution. The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker. Would such an architecture work for you guys? The reason these are not properties is just because it makes no sense to update the counters live. The UI can poll if it so wishes, but the poll interval is not something we want to decide. What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here. In addition to that, what is the problem with just updating the stats after the call has ended? Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and IO we can bear. I think this is not a good idea to have oFono handles this. Why can't the system daemon just shutdown all calls when the battery reaches critical limit. You will never fully run down the battery anyway. One of the system health components in the system will prevent it and then can cleanly shutdown oFono and thus all calls. The only case where the system could potentially misfunction in this area would be an emergency call. But that is a total different use case anyway. It was already pointed out by Mika Liljeberg there could be cases when we might not get the chance to sync our data. We need to be prepared to cope with such cases as well (syncing the data often enough). Are these cases are really real life problems. For example with devices moving toward hotswap SIM cards, the exchange of battery and accidentally (or on purpose) removal seems to become more and more unrealistic.
Re: [PATCH 0/5] Call Counters (2nd)
Hi Andras, The call counters are shown to the user when he or she opens up an application/applet whatever UI component that is meant for showing this information. do we have a clear use case requirement from an UI point of view on how this is expected to be working. In our case, it is expected to have the counters information shown to the user continuously updated with about 1 second granularity, as long as the user keeps opened the UI showing the counters. This practically means live call counters in the UI. are your interaction designers aware of that users wanna use their phone for making phone calls and not watching call counters increasing every single second? My iPhone has a granularity of 1 minute and I actually had to go out of my normal calling behavior to watch that counter. And it does not update actually during the call. It only updates when the call end. And just to be clear here. Calling a D-Bus method every single second is not acceptable. That is a sure way to drain you battery. I checked with my iPhone and how it does it. Basically it just updates after the call and only after you re-entered that menu. So here again, do we have a requirement to make this realtime or not. And I mean that from an user interaction point of view. Coming to the reliability part, saving the call counters information often enough, gives us sort of hard guarantee that whatever happens with any subsystem, be that SW or HW, the call counters will stay enough accurate. Syncing to the permanent storage, based on our product requirements, should take place in fact every 5 sec, or could be configurable. Writing and syncing something to disk every 5 seconds costs us IO. Is this really a sacrifice that is acceptable. I agree, from pure technical point of view it's a costly operation. So here is my problem with this whole idea. How much do you care about battery life and call time? You keep waking up ofonod during the call (which is not needed) and you keep the IO active. So from how I am looking at this problem, ofonod is the wrong place to solve this. There might be some liability issues if for some reason the counters would loose time, the user my blame the phone manufacturer for the extra expenses incurred by inaccurate counters. To be honest the counters can not be considered accurate anyway. Only the billing system has the final say. I think any info we decide to show to the user has to be accurate enough, otherwise becomes meaningless. Even if we entertain this for a bit, does a user really care about seconds of overall call time. For a single call, maybe, but for your overall call time. Is minutes not enough? How accurate does this really have to be? We can discuss the place of the call counters plugin, but I think using the ofono history framework is a reasonable choice, with the note that the it needs to be expanded with a history function called in the beginning of a call. The call counters plugin could be an optionally compiled/included (dynamic) plugin or downgraded to experimental status. So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution. The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker. Would such an architecture work for you guys? I don't know at the moment whether this solution is good and elegant enough, we need to think about it. Please think about this. While not obvious at first, it seems pretty much reasonable to me. PA will be most likely active anyway. However here is one thing that is unclear to me. Are we tracking talk time or call time. In case of call time, how do we deal with multiparty calls etc. Is a call on hold equals double time and so on. So does this have to reflect billed time or actual time spent talking on the phone. I am really missing a well defined features requirement from top to bottom with these details explained. The reason these are not properties is just because it makes no sense to update the counters live. The UI can poll if it so wishes, but the poll interval is not something we want to decide. What are the granularity there. What is the expected user experience with this API. I don't see any clear usage model here. In addition to that, what is the problem with just updating the stats after the call has ended? Because if your battery runs out in the middle of a 4 hour conference call, your timers are not updated and become worthless. Obviously, this is a compromise between how reliable the counters are and how many wakeups and
RE: [PATCH 0/5] Call Counters (2nd)
Hi Kai, So I am actually thinking that doing that inside PulseAudio is a lot more efficient solution. The idea is that PA already runs in the user session and has to monitor the uplink/downlink state (and additionally could monitor call states as well if needed). So it knows when a call is active and it is active anyway doing the audio processing. So it could just then go ahead and write your call accounting into Tracker. Pulseaudio (or the meego PA modules for voice) isn't really an option for at least the following reasons: - lots of modems still handle all audio and PA will know nothing about calls at all with these modems actually Denis raised the same question, but then again this is for a product specific requirement. And for that product we know that PA will do the audio processing. - PA does not really care about individual calls, but whether the audio traffic channel is connected or not - multi-call cases, cases were traffic channel is reconnected mid-call, etc, etc, PA simply does not know enough (and should not) And that is my point (see other email). This should be tracking talk time and not individual call time. And thus it would be fitting nicely into PA in that case. I guess this could be done in higher layers on top of oFono (telepathy-ring, dialer app, policy framework, etc), but I don't really know enough about the call timer stuff to comment on the pro/cons of this. Important for me is to weight the extra costs of IO and CPU consumption when doing this inside oFono. And since ofonod itself would actually not wake up during a phone call, I think this is not a good fit. It could be that PA is not a good candidate either, but to me it looks like a pretty smart place to handle this. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/3] plugins: Implementation of Network Time plugin
Hi Remi, where is this timed running? I prefer the plugin just send a D-Bus message to the timed directly instead of a Get/Changed API kind of thing. AFAIK, Get/Changed is the simplest functional way to avoid races, where say oFono would receive the time before timed can process it. The getter also enables implementing trivial a tool à la ntpdate. then please answer my questions from my other email. If we receive the time before timed (or any other time daemon) is running, who does ensure the current timestamp of this received time and what it correlates to. The answer is in the patch. It makes me wonder if you even read it? When we receive NITZ from the modem, we take a timestamp from the monotonic clock. From there, we have plenty of options, mostly boiling down to: (1) Give an estimate of the current wall time: nitz + (now(CLOCK_MONOTONIC) - timestamp) This induces avoidable imprecision, but it is easiest to understand. (2) Give both the NITZ time and the monotonic timestamp, and let the time daemon do all the maths. IIRC, that's what timed would like, although I find it needlessly complicated. (3) Give an estimate of the time of day of the monotonic clock origin, which is to say the time of day of the system boot: nitz - timestamp. The time daemon can then add the current monotonic time. This is a bit more precise than (1), and a bit simpler than (2), which is why I was suggesting that. If no time daemon is running it is safer to just set this time as system time right away and then let the time daemon adjust it later. Either oFono maintains the time (may be a configuration option), or it does not. I would really hate to have oFono set the system time depending on the effect of the phase of moon on the ordering of the boot sequence. But just handing out a random time from a random time before is not helping. And oFono is not suppose to track time and it corelation to it. Antti's patch returns an extrapolation of the _current_ wall time by adding the time since the NITZ was received to the NITZ. This is not at all random. Obviously, we need a working monotonic clock - but I think a mobile device without a working timer is about as useful as a brick. I have seen a bunch of devices where we have not a proper clock value to begin with. And in that case there is nothing really useful we can do with it, except just set the system clock right away. So the other problem with the timestamp and NITZ and the time daemon not running is that we have no idea what happens in between. While this might be short time and could potentially work, I still don't see this as a good solution at all. Right now, I still think that either we set the system clock right away if no time daemon is running and if time daemon is running, then we send a D-Bus method to that time daemon. And we can easily track this D-Bus name owner notifications. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Mark ofono/*.h symbolink links as built sources
Hi Remi, This forces automake/make to build them first if needed (as before). But it avoids marking every single header as a dependency of every single object. Thus we do not need a bogus full rebuild of the tree everytime a header is added. --- Makefile.am |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Specify vendor ID for Huawei modem while creating GPRS context
Hi Tonny,
plugins/huawei.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/plugins/huawei.c b/plugins/huawei.c
index 25dfaca..32cf70d 100644
--- a/plugins/huawei.c
+++ b/plugins/huawei.c
@@ -454,7 +454,7 @@ static void huawei_disconnect(gpointer user_data)
data-sim_state == HUAWEI_SIM_STATE_INVALID_CS) {
ofono_info(Reopened GPRS context channel);
- data-gc = ofono_gprs_context_create(modem, 0, atmodem,
+ data-gc = ofono_gprs_context_create(modem, OFONO_VENDOR_HUAWEI,
atmodem,
data-modem);
this not doing anything. Behavior is still the same.
if (data-gprs data-gc)
@@ -631,12 +631,12 @@ static void huawei_post_online(struct ofono_modem
*modem)
if (data-sim_state == HUAWEI_SIM_STATE_VALID ||
data-sim_state == HUAWEI_SIM_STATE_INVALID_CS) {
- data-gprs = ofono_gprs_create(modem, 0, atmodem, data-pcui);
+ data-gprs = ofono_gprs_create(modem, OFONO_VENDOR_HUAWEI,
atmodem,
data-pcui);
if (data-ndis == TRUE)
- data-gc = ofono_gprs_context_create(modem, 0,
+ data-gc = ofono_gprs_context_create(modem,
OFONO_VENDOR_HUAWEI,
huaweimodem, data-pcui);
This one makes no sense. It is Huawei specific already.
else
- data-gc = ofono_gprs_context_create(modem, 0,
+ data-gc = ofono_gprs_context_create(modem,
OFONO_VENDOR_HUAWEI,
atmodem, data-modem);
This is also not doing anything either actually.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/3] plugins: Implementation of Network Time plugin
Hi Aki, where is this timed running? I prefer the plugin just send a D-Bus message to the timed directly instead of a Get/Changed API kind of thing. AFAIK, timed is in system bus. However, I fail to see how you can make this any simpler. In the end, one of the two entities has to implement a service that the other one uses. There also needs to be some synchronization for when the entities start up. A getter/signal API is also what timed uses in Harmattan, but of course if you have a better idea, I'm all ears. is timed actually open source and I can have a look at it? What is the advantage of oFono storing the time value from NITZ and provide it over a getter/signal API. In that case we also need to store a timestamp when we received the NITZ result. Otherwise the value has no real meaning since we can not correlate it to anything. That said, ofonod is not responsible for time tracking and so is not the modem. This means that our time source is inaccurate by definition. Ans so is our timestamp. And that makes the NITZ information useless that retreive via a getter method. What do you wanna do with an inaccurate time information? Instead of trying to keep track of time inside oFono, I would propose that we just send a method call with the currently received NITZ and only when we receive them to a timed (if started). Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RESEND] [PATCH] Mark ofono/*.h symbolink links as built sources
Hi Remi, This forces automake/make to build them first if needed (as before). But it avoids marking every single header as a dependency of every single object. Thus we do not need a bogus full rebuild of the tree everytime a header is added. I have run some tests on this and seems fine to me. --- Makefile.am |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index a4c47e8..ee7949d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -326,7 +326,8 @@ src_ofonod_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ @CAPNG_LIBS@ -ldl src_ofonod_LDFLAGS = -Wl,--export-dynamic \ -Wl,--version-script=$(srcdir)/src/ofono.ver -CLEANFILES = src/builtin.h $(local_headers) $(rules_DATA) +BUILT_SOURCES = $(local_headers) +CLEANFILES = src/builtin.h $(BUILT_SOURCES) $(rules_DATA) But can you please add an empty line between these two variable assignments. Just for consistency with the rest of the Makefile.am code. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] HACKING: Add ofono.conf file copy command required
Hi Daniel, + Copy configuration file which specifies the required security policies +# sudo cp ./src/ofono.conf /etc/dbus-1/system.d/ + Considered to add this too? sudo killall -HUP dbus-daemon that is actually a bad idea. I would not recommend it. The dbus-daemon should be built with inotify support and if not, then reboot of the system is a better idea. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Add voice call boolean property for MO/MT distinction
Hi Remi, do me a favor and try not to break the threading next time. * At Nokia, we also have some non-standard commands for internal use. * Some operators require some funky AT commands of their own. It might not be possible to open-source them, even if we want to. And these should be on an engineering mode only USB CDC ACM interface with a different backend anyway. I already mentioned that the same software must run in certification and in user's hands for whole device certification to be valid. But anyway, some of those commands were requested as DUN extensions, not as testing stuff. So no no no. I am getting a bit sick of this secrecy. oFono is for all intense and purposes open source. So if you want a proper discussion here then please list the AT command in question. Since you are clearly working on this right now, please compile a list of required AT commands and share it. A good place to list the required commands for whole device certification would be the doc/ directory. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: ConnectionContext creation for LTE PDN Connection.
Hi Remi, as I mentioned before, please do NOT break threading. why would bringing an interface up interfere? We are doing this right now. Just the IP assignment is done by ConnMan, but the interface up/down status is controlled by oFono or even BlueZ in case of Bluetooth. Logically whoever sets the IP parameters should bring the interface administratively up. This is layer 3. oFono does layer 2. It should either create/remove the interface and/or play with the dormant and/or carrier flags. If you think we should change the current behavior, then please send patches for oFono and BlueZ and also ConnMan to fix this. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Add voice call boolean property for MO/MT distinction
Hi Aki, I am getting a bit sick of this secrecy. oFono is for all intense and purposes open source. So if you want a proper discussion here then please list the AT command in question. So this patch seems to be to enable reporting call direction as part of reporting call status using AT+CLCC. It is needed by HFP as well as a conformance suite for USB ACM that Rémi is working on. as I said before, someone has to do the due diligence and start listing all required AT commands for conformance testing. I want to see the full picture and not some random patches here and there. I am still not convinced that these details should be exposed via D-Bus APIs at all. Using the internal AT emulator would be a way better fit. So can you guys come up with a detailed list of AT commands for this? I want to have this documented. Then we can have a proper discussion since this is not getting anywhere. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Mark ofono/*.h symbolink links as built sources
Hi Remi, This forces automake/make to build them first if needed (as before). But it avoids marking every single header as a dependency of every single object. Thus we do not need a bogus full rebuild of the tree everytime a header is added. I had this before, but it caused problems with make distcheck. So you have double checked that this still works? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] configure: do not hard-code the C run-time library name
Hi Remi, Since oFono does (obviously) not use -nostdlib, this only broke support for alternative C run-times. --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) looks good enough to me. Patch has been applied. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/3] Use %m instead of strerror() in syslog messages
Hi Remi, strerror() is not thread-safe, nor in the glibc implementation, nor in the POSIX specification. In my experience, it will infrequently crash when another thread uses locale data in any way, including string formatting and such... Since the Huawei driver uses thread, we might as well avoid strerror(). --- drivers/isimodem/sim.c |3 ++- plugins/hfp.c |4 ++-- plugins/isigen.c | 13 - plugins/n900.c | 14 +++--- plugins/nokia-gpio.c | 29 + 5 files changed, 36 insertions(+), 27 deletions(-) Since we do not use threads, do you still want this patch? If you do, can you please break this up into two patches, one for drivers/isimodem and one for plugins? We prefer patches to be split by directory. Why do we initialize glib and dbus with thread support? If the plan is to smoothen the hypothetical use of threads in the future, then this patch should probably go in as well? we do not initialize it with thread support, but in case a plugin actually uses threads it could force it. This is common across BlueZ, ConnMan and oFono and really just in case thing. In ConnMan we have this case with the WiMAX plugin. For oFono we should hopefully never require threading support. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] Add voice call boolean property for MO/MT distinction
Hi Remi, This becomes a problem if we have more than one application managing voice calls. And I expect that will _be_ the most common case. You have the main call UI, but you also have the Bluetooth headset/carkit, the USB AT commands port, and possibly some third party call applications. Right. At least for HFP the call direction needs to be in the AT+CLCC reply. I.e. if the bluetoothd ofono telephony driver is used and bluetoothd starts after one or more calls are already in progress bluetoothd wouldn't have seen the call setup process and therefore not know the direction of the call (without this property). Yeah. For USB CDC ACM gadget functionality, there is basically the same problem. Because oFono assumes it has full control over the modem, most cellular commands have to go through the oFono D-Bus API. However, a number of other commands talk to completely different stuff, including but not limited to: * AT+CBC et al deals with energy management, which is proprietary in Nokia's case and hence cannot be reached from GPL'd oFono. where is the problem here. An oFono plugin could just talk D-Bus to this daemon. * AT+CKPD, AT+CTSA and friends use either Linux uinput driver or perhaps to the windowing framework (X11, Wayland?). This is not even a problem. Using uinput and this is solved. Wayland talks kernel input only anyway and so can X11. * AT+CBKLT is hooked to the screensaver whatever takes care of it. No matter what you do, this is a more complex problem. The screensaver run as user session. You might just need to modify it to also listen on the D-Bus system bus on a well defined service name and problem solved. * AT+CPBR and friends is hooked to the phonebook, which is Qt-based, and therefore inadequate inside oFono. I am not buying into the AT+CPBR for the local and user specific phonebook. That one is inside Tracker anyway and also inside the user session. Trying to really support this is a broken idea. CPBR can not expose the information of modern contacts storage anyway, so just don't bother. If you really care about it then use Bluetooth PBAP via obexd which we have enabled already. * At Nokia, we also have some non-standard commands for internal use. * Some operators require some funky AT commands of their own. It might not be possible to open-source them, even if we want to. And these should be on an engineering mode only USB CDC ACM interface with a different backend anyway. I would like to emphasize that, even if many of those commands are mostly if not only used in testing, they may still need to cooperate with oFono and/or to be present in the end-user devices. Besides, duplicating the implementation effort inside and outside oFono would be a waste of time. All in all, implementing the AT commands DCE emulator inside oFono is not a realistic option. That is not to say that it must be closed-source, at least not most parts of it, but it's going to (have to) talk D-Bus to oFono. I disagree here. The AT commands emulator belongs inside oFono. Only because someone wants to shoehorn this into something nasty, doesn't mean we should do it. And I am not going to scarifies the simplicity of the oFono D-Bus API for this. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: ConnectionContext creation for LTE PDN Connection.
Hi Remi, Or should oFono automatically create a Connection Context? Furthermore, should oFono automatically proceed and set Active=true, bind the connection to a network interface and set network interface in state UP, Definitely not. This would interfere with any other existing IP connection, say WiFi. why would bringing an interface up interfere? We are doing this right now. Just the IP assignment is done by ConnMan, but the interface up/down status is controlled by oFono or even BlueZ in case of Bluetooth. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: How to get the OMA DRM right object file coming from WAP Push?
Hi Aki, Can the two methods help me to handle files from WAP push? Yes. You need to implement the PushNotificationAgent interface, and register this object with oFono using the RegisterAgent() method. there is actually a test/test-push-notification Python example in the code base that shows how this works. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
Hi Jaakko, To be honest, the more and more I think about this, the more my conclusion is to not support phonebook export. It is a bad idea. It is highly complex and it is not a feature that will be used anyway. Ok, got it. Do you have any insight if MeeGo still wants this (http://bugs.meego.com/show_bug.cgi?id=4476)? the requirement comes from wanting to pass the Chinese type approval. For a general user it makes no sense. This is a 21st century smart phone and not some feature phone from the 90ties. That said, I am curious on how Apple can sell the iPhone on the Chinese market without having support for writing to the SIM phonebook. Nobody could give me an answer to that so far. If they do, will they need to maintain a separate branch, or do they need to implement it somehow with a separate component? Private branches or a separate components are not allowed. It is either oFono supports it or it does not. This is actually pretty much a black or white feature. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RERESEND] [PATCH 2/2] Update the network documentation
Hi Remi, doc/network-api.txt |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/doc/network-api.txt b/doc/network-api.txt index 083e918..9fb9974 100644 --- a/doc/network-api.txt +++ b/doc/network-api.txt @@ -125,8 +125,9 @@ Propertiesstring Mode [readonly] Contains the technology of the current network. - The possible values are: gsm, edge, umts, hspa, - lte + The possible values are: gsm, edge, umts, + hsdpa, hsupa, hspa (meaning both hsdpa and hsupa) + and lte so what is the intended usage for showing this difference? When we discussed this the last time, it was clear that we need to show a difference between 3G (umts) and 3.5G (hspa) and where HSPA would be either HSDPA or HSUPA or both. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
Hi Jaakko,
no index number. We will never use them. It is either the full
phonebook
at once or nothing. The write function has to empty out left over
entries.
...
Actually I prefer we use proper Dict field names. We never use anything
literally from the specifications in this area. So why start now.
Please propose proper human readable names.
Well, if we want a generic data structure, I assume it shouldn't be locked to
any finite amount of phone numbers (number, adnumber) per contact either?
Thus we should implement merging and I guess at the same time effort also the
same number categorization that is implemented witht he current Import()
function.
So the aa{sv} parameter/return value would be of format:
{
'name': string,
'group' : string, // optional, for eg. organization
'hidden' : integer, // boolean value: defaults to 0
'numbers' : array of dict {
'number' : string,
'category' : integer
},
'emails' : array of dict {
'address' : string,
'category' : integer
},
'voip_uris' : array of dict {
'uri' : string,
'category' : integer
},
}
category : enum { // like existing enum phonebook_number_type
HOME, MOBILE, FAX, WORK, OTHER
}
this feels a bit too complicated for me. I actually don't want to
over-design this feature, but it does have to be consistent with our
other key names.
To be honest, the more and more I think about this, the more my
conclusion is to not support phonebook export. It is a bad idea. It is
highly complex and it is not a feature that will be used anyway.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] TODO: Add vCard export to SM/ME stores
Hi Jaako, Is there already a specification/draft of the format of this dict? If not, I would be tempted to use the 27.007 +CPBR/W field names as keys (e.g. index, number, type, text, adnumber, secondtext, sip_uri, etc.) there is not. So you need to propose one here. For simplicity, I would propose that both import and export would use an array of dict's with the 27.007 keys: index: type=integer, import=always export=ignored no index number. We will never use them. It is either the full phonebook at once or nothing. The write function has to empty out left over entries. number: type=string, import=always/empty export=optional/empty type: type=integer, import=always export=mandatory text: type=string, import=always/empty export=optional/empty hidden: type=int, import=always, export=optional/default=0 group: type=string, import=if nonempty, export=optional adnumber: type=string, import=if nonempty, export=optional adtype: type=integer, import/export=mandatory if adnumber nonempty secondtext: type=string, import=if nonempty, export=optional email: type=string, import=if nonempty, export=optional sip_uri: type=string, import=if nonempty, export=optional tel_uri: type=string, import=if nonempty, export=optional Actually I prefer we use proper Dict field names. We never use anything literally from the specifications in this area. So why start now. Please propose proper human readable names. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
