RE: [RFC] plugin/ste: Use D-Bus API from Modem Init Daemon for autoconfig.
Hi Marcel, This patch introduces auto discovery of ST-Ericsson modems. ST-Ericsson modems are managed by a Modem Init Daemon which is responsible for start/stop/restart flashing etc. The 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. The reason for not using the standard udev paradigm is that the CAIF device is up before the modem is ready to setup AT channels. For flashless modems CAIF is used as part of the boot. The Modem Init Daemon is managing the flashless boot procedure and sets the State to on when the modem is available. so I don't like this at all. This looks pretty nasty and like an ugly hack to get something working. Please show us what Modem Init Daemon is actually doing. As mentioned above the Modem Init Daemon is responsible for: - Toggling the different GPIOs, powering the modem on/off. - Boot the modem and upload the firmware in several stages. a) Initial Z-Protocol, for handshaking the modem b) PROTROM boot protocol to upload modem firmware. c) CAIF Remote File System protocol for further firmware loading (modules) d) CAIF Remote File System protocol for serving modem file system. - Monitoring the GPIOs for modem restart and act upon this. - Enabling/Disabling the CAIF Link Layer Interface according to the modem state (GPIO). - Monitoring Thermal and Battery Warnings URC over AT and acting upon this. - In case of modem crash, the crash-dump from the modem must be downloaded to host. This needs to be synchronized so that the reboot of the modem is not started before the dump is complete. - Modem Init daemon has to expose an API in for: o triggering restart o signal modem status o initiate upgrade The Modem Init Daemon will be available in product quality under Apache License, and will be in use for several platforms (not just MeeGo) and modem versions. The issue we have is that when the CAIF Link Layer Interface is up it does not necessarily mean that the Modem is fully started. So we need to have a way to synchronize other services and modem clients when the modem is ready. The other services that needs this ready notification are: oFono, Remote File Manager, Logging Daemon. On other platforms than MeeGo there are AT based clients such as Audio, AGPS, RIL as well. We definitely need a synchronization mechanism between Modem Init Daemon and the other services, so we decided to use a D-Bus API for the Modem Init Daemon to expose the modem state and an API for initiating power-off, upgrade and reboot. Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] TODO: Add owner of provide local info task
--- TODO |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index 0d04208..a5196f7 100644 --- a/TODO +++ b/TODO @@ -362,6 +362,7 @@ Sim Toolkit Priority: High Complexity: C2 + Owner: Yang Gu yang...@intel.com Emergency Calls -- 1.7.2.3 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: Add owner of provide local info task
Hi Yang, TODO |1 + 1 files changed, 1 insertions(+), 0 deletions(-) patch has been applied. Thanks. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] sim: use mask for check of sim file status
From: Guillaume Lucas guillaumex.lu...@intel.com Is' the first bit of the sim file status who indicates if a file is valid or not. So a mask must be used to check this. --- src/sim.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/sim.c b/src/sim.c index 02ab329..2ee2b29 100644 --- a/src/sim.c +++ b/src/sim.c @@ -1290,7 +1290,7 @@ static void sim_efbdn_info_read_cb(int ok, unsigned char file_status, if (!ok) goto out; - if (file_status == SIM_FILE_STATUS_VALID) + if (file_status SIM_FILE_STATUS_VALID) sim_bdn_enabled(sim); out: @@ -1327,7 +1327,7 @@ static void sim_efadn_info_read_cb(int ok, unsigned char file_status, if (!ok) goto out; - if (file_status != SIM_FILE_STATUS_VALID) + if (!(file_status SIM_FILE_STATUS_VALID)) sim_fdn_enabled(sim); out: -- 1.7.0.4 - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] sim: use mask for check of sim file status
Hi Guillaume, On 11/05/2010 08:05 AM, Lucas, GuillaumeX wrote: From: Guillaume Lucas guillaumex.lu...@intel.com Is' the first bit of the sim file status who indicates if a file is valid or not. So a mask must be used to check this. --- src/sim.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Good catch on these. Patch has been applied, thanks. I also applied a couple of extra fixes that add more sanity checking to BDN FDN. Please check that my fixes didn't break anything else :) Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH v4 2/2] stemodem: Update gprs-context to use rtnl to create/remove interfaces.
From: Sjur Brændeland sjur.brandel...@stericsson.com
---
drivers/stemodem/gprs-context.c | 207 +--
1 files changed, 135 insertions(+), 72 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index 9f59579..4260d31 100644
--- a/drivers/stemodem/gprs-context.c
+++ b/drivers/stemodem/gprs-context.c
@@ -28,6 +28,7 @@
#include string.h
#include stdlib.h
#include stdio.h
+#include errno.h
#include glib.h
@@ -46,10 +47,11 @@
#include stemodem.h
#include caif_socket.h
#include if_caif.h
+#include caif_rtnl.h
-#define MAX_CAIF_DEVICES 7
+#define MAX_CAIF_DEVICES 4
#define MAX_DNS 2
-#define MAX_ELEM 20
+#define IP_ADDR_LEN 20
#define AUTH_BUF_LENGTH (OFONO_GPRS_MAX_USERNAME_LENGTH + \
OFONO_GPRS_MAX_PASSWORD_LENGTH + 128)
@@ -65,21 +67,29 @@ struct gprs_context_data {
};
struct conn_info {
+ /*
+* cid is allocated in oFono Core and is identifying
+* the Account. cid = 0 indicates that it is currently unused.
+*/
unsigned int cid;
- unsigned int device;
+ /* Id used by CAIF and EPPSD to identify the CAIF channel*/
unsigned int channel_id;
- char interface[10];
+ /* Linux Interface Id */
+ unsigned int ifindex;
+ /* Linux Interface name */
+ char interface[IF_NAMESIZE];
+ gboolean created;
};
struct eppsd_response {
char *current;
- char ip_address[MAX_ELEM];
- char subnet_mask[MAX_ELEM];
- char mtu[MAX_ELEM];
- char default_gateway[MAX_ELEM];
- char dns_server1[MAX_ELEM];
- char dns_server2[MAX_ELEM];
- char p_cscf_server[MAX_ELEM];
+ char ip_address[IP_ADDR_LEN];
+ char subnet_mask[IP_ADDR_LEN];
+ char mtu[IP_ADDR_LEN];
+ char default_gateway[IP_ADDR_LEN];
+ char dns_server1[IP_ADDR_LEN];
+ char dns_server2[IP_ADDR_LEN];
+ char p_cscf_server[IP_ADDR_LEN];
};
static void start_element_handler(GMarkupParseContext *context,
@@ -122,8 +132,8 @@ static void text_handler(GMarkupParseContext *context,
struct eppsd_response *rsp = user_data;
if (rsp-current) {
- strncpy(rsp-current, text, MAX_ELEM);
- rsp-current[MAX_ELEM] = 0;
+ strncpy(rsp-current, text, IP_ADDR_LEN);
+ rsp-current[IP_ADDR_LEN] = 0;
}
}
@@ -153,8 +163,7 @@ static gint conn_compare_by_cid(gconstpointer a,
gconstpointer b)
return 0;
}
-static struct conn_info *conn_info_create(unsigned int device,
- unsigned int channel_id)
+static struct conn_info *conn_info_create(unsigned int channel_id)
{
struct conn_info *connection = g_try_new0(struct conn_info, 1);
@@ -162,26 +171,61 @@ static struct conn_info *conn_info_create(unsigned int
device,
return NULL;
connection-cid = 0;
- connection-device = device;
connection-channel_id = channel_id;
return connection;
}
+static void rtnl_callback(int result, gpointer user_data,
+ char *ifname, int ifindex)
+{
+ struct conn_info *conn = user_data;
+
+ strncpy(conn-interface, ifname, sizeof(conn-interface));
+ conn-ifindex = ifindex;
+
+ if (result == 0)
+ conn-created = TRUE;
+ else {
+ conn-created = FALSE;
+ DBG(Could not create CAIF Interface);
+ }
+}
+
/*
* Creates a new IP interface for CAIF.
*/
-static gboolean caif_if_create(const char *interface, unsigned int connid)
+static gboolean caif_if_create(struct conn_info *conn)
{
- return FALSE;
+ int err;
+
+ err = caif_rtnl_create_interface(conn, IFLA_CAIF_IPV4_CONNID,
+ conn-channel_id, FALSE, rtnl_callback);
+ if (err 0) {
+ DBG(Failed to create IP interface for CAIF);
+ return FALSE;
+ }
+
+ return TRUE;
}
/*
* Removes IP interface for CAIF.
*/
-static gboolean caif_if_remove(const char *interface, unsigned int connid)
+static void caif_if_remove(struct conn_info *conn)
{
- return FALSE;
+ 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;
}
static void ste_eppsd_down_cb(gboolean ok, GAtResult *result,
@@ -192,11 +236,14 @@ static void ste_eppsd_down_cb(gboolean ok, GAtResult
*result,
struct ofono_gprs_context *gc = cbd-user;
struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
struct ofono_error error;
- struct conn_info *conn;
+ struct
[PATCH v4 1/2] stemodem: Add RTNL functionality managing CAIF Network Interfaces.
From: Sjur Brændeland sjur.brandel...@stericsson.com
---
Hi Marcel.
I'm sorry about the formatting for the v3 version of this patch.
I used git send-email via my gmail account, and ended up with base64
MIME content encoding. I dont' know what went wrong :-(
I think I have closed most of your review comments so far. I kept using
sendto as I don't quite get how to use g_io_channel_write_chars for rtnl socket.
(I think connman is using sendto as well.) I still set g_caif_devices = NULL
just in
case someone in future does init/exit more than once.
The patch has been tested activating/deactivation and I have run valgrind
showing
no leaks on some unit tests (not yet upstreamed).
Regards,
Sjur
Makefile.am |2 +
drivers/stemodem/caif_rtnl.c | 379 ++
drivers/stemodem/caif_rtnl.h | 29
3 files changed, 410 insertions(+), 0 deletions(-)
create mode 100644 drivers/stemodem/caif_rtnl.c
create mode 100644 drivers/stemodem/caif_rtnl.h
diff --git a/Makefile.am b/Makefile.am
index 05082de..f163b0a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -226,6 +226,8 @@ builtin_sources += drivers/atmodem/atutil.h \
drivers/stemodem/stemodem.c \
drivers/stemodem/voicecall.c \
drivers/stemodem/radio-settings.c \
+ drivers/stemodem/caif_rtnl.c \
+ drivers/stemodem/caif_rtnl.h \
drivers/stemodem/gprs-context.c \
drivers/stemodem/caif_socket.h \
drivers/stemodem/if_caif.h
diff --git a/drivers/stemodem/caif_rtnl.c b/drivers/stemodem/caif_rtnl.c
new file mode 100644
index 000..ad58c93
--- /dev/null
+++ b/drivers/stemodem/caif_rtnl.c
@@ -0,0 +1,379 @@
+/*
+ *
+ * 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 string.h
+#include unistd.h
+#include errno.h
+#include net/if.h
+#include net/if_arp.h
+#include fcntl.h
+#include linux/rtnetlink.h
+
+#include glib.h
+
+#include ofono/log.h
+
+#include if_caif.h
+#include caif_rtnl.h
+
+#define NLMSG_TAIL(nmsg) \
+ ((struct rtattr *) (((void *) (nmsg)) + NLMSG_ALIGN((nmsg)-nlmsg_len)))
+
+struct iplink_req {
+ struct nlmsghdr n;
+ struct ifinfomsg i;
+ char pad[1024];
+
+ int request_id;
+ int type;
+ int conn_id;
+ gpointer user_data;
+ gboolean loop_enabled;
+
+ char ifname[IF_NAMESIZE];
+ int ifindex;
+ caif_rtnl_create_cb_t callback;
+};
+
+static GSList *pending_requests;
+static guint32 rtnl_seqnr;
+static guint rtnl_watch;
+static GIOChannel *channel;
+
+static gboolean get_ifname(struct ifinfomsg *msg, int bytes,
+ const char **ifname)
+{
+ struct rtattr *attr;
+
+ for (attr = IFLA_RTA(msg); RTA_OK(attr, bytes);
+ attr = RTA_NEXT(attr, bytes)) {
+
+ if (attr-rta_type == IFLA_IFNAME
+ ifname != NULL) {
+
+ *ifname = RTA_DATA(attr);
+ return TRUE;
+ }
+ }
+
+ return FALSE;
+}
+
+static void store_newlink_param(struct iplink_req *req, unsigned short type,
+ int index, unsigned flags,
+ unsigned change, struct ifinfomsg *msg,
+ int bytes)
+{
+ const char *ifname = NULL;
+
+ get_ifname(msg, bytes, ifname);
+ strncpy(req-ifname, ifname,
+ sizeof(req-ifname));
+ req-ifname[sizeof(req-ifname)-1] = '\0';
+ req-ifindex = index;
+}
+
+static int send_rtnl_req(struct iplink_req *req)
+{
+ struct sockaddr_nl addr;
+ int sk = g_io_channel_unix_get_fd(channel);
+
+ memset(addr, 0, sizeof(addr));
+ addr.nl_family = AF_NETLINK;
+
+ return sendto(sk, req, req-n.nlmsg_len, 0,
+ (struct sockaddr *) addr, sizeof(addr));
+}
+
+static struct iplink_req *find_request(guint32 seq)
+{
+ GSList *list;
+
+ for (list = pending_requests; list; list = list-next) {
+ struct iplink_req *req = list-data;
+
+
Re: [PATCH] sim: Check SIM pin status after changing pin.
Hi Denis.
OK, I can see that this approach was rather too simplistic... Maybe checking
the returned CME error would be a better idea?
I’m a bit unsure how (or if) to proceed with this. As this is in the core,
and not our driver, it might be more on your table? If you think it is
important.
Br Marit
2010/11/2 Denis Kenzior denk...@gmail.com
Hi Marit,
On 11/02/2010 10:08 AM, Marit Henriksen wrote:
From: Marit Henriksen marit.henrik...@stericsson.com
When changing pin, it is possible to get in a state where the modem
requests puk
(if incorrect pin is entered too many times). Need to check the SIM pin
status
to discover this.
---
src/sim.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/sim.c b/src/sim.c
index 699ebe9..b2277c5 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -628,15 +628,16 @@ static DBusMessage *sim_unlock_pin(DBusConnection
*conn, DBusMessage *msg,
static void sim_change_pin_cb(const struct ofono_error *error, void
*data)
{
struct ofono_sim *sim = data;
+ DBusMessage *reply;
- if (error-type != OFONO_ERROR_TYPE_NO_ERROR) {
- __ofono_dbus_pending_reply(sim-pending,
- __ofono_error_failed(sim-pending));
- return;
- }
+ if (error-type != OFONO_ERROR_TYPE_NO_ERROR)
+ reply = __ofono_error_failed(sim-pending);
+ else
+ reply = dbus_message_new_method_return(sim-pending);
- __ofono_dbus_pending_reply(sim-pending,
-
dbus_message_new_method_return(sim-pending));
+ __ofono_dbus_pending_reply(sim-pending, reply);
+
+ sim_pin_check(sim);
I don't think that running sim_pin_check is such a good idea. That
function initializes the sim interface when +CPIN returns READY.
You also need to tear down the modem state back to pre-sim if the modem
asks for a PUK after change pin fails. That entails removing all
post_sim/post_online atoms and bring the modem back to the offline state ;)
}
static DBusMessage *sim_change_pin(DBusConnection *conn, DBusMessage
*msg,
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] sim: use mask for check of sim file status
Hi Denis, I've tested your changes and all is ok :) Regards, Guillaume -Original Message- From: Denis Kenzior [mailto:denk...@gmail.com] Sent: Friday, November 05, 2010 3:17 PM To: ofono@ofono.org Cc: Lucas, GuillaumeX Subject: Re: [PATCH] sim: use mask for check of sim file status Hi Guillaume, On 11/05/2010 08:05 AM, Lucas, GuillaumeX wrote: From: Guillaume Lucas guillaumex.lu...@intel.com Is' the first bit of the sim file status who indicates if a file is valid or not. So a mask must be used to check this. --- src/sim.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Good catch on these. Patch has been applied, thanks. I also applied a couple of extra fixes that add more sanity checking to BDN FDN. Please check that my fixes didn't break anything else :) Regards, -Denis - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] sim: use mask for check of sim file status
Hi Guillaume, I've tested your changes and all is ok :) thanks for testing this. But please refrain from top posting on this mailing list. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RFC 1/3] doc: addidng documentation for basic assisted gps
---
doc/assistedgps-manager-api.txt | 114 +++
1 files changed, 114 insertions(+), 0 deletions(-)
create mode 100644 doc/assistedgps-manager-api.txt
diff --git a/doc/assistedgps-manager-api.txt b/doc/assistedgps-manager-api.txt
new file mode 100644
index 000..b09c8b1
--- /dev/null
+++ b/doc/assistedgps-manager-api.txt
@@ -0,0 +1,114 @@
+AgpsManager hierarchy
+=
+
+Serviceorg.ofono
+Interface org.ofono.AgpsManager
+Object path[variable prefix]/{modem0,modem1,...}
+
+Methodsdict GetProperties()
+
+ Returns properties for the modem object. See
+ the properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed as read-write are
+ changeable. On success a PropertyChanged signal
+ will be emitted.
+
+ Possible Errors: [service].Error.InvalidArguments
+[service].Error.DoesNotExist
+
+ void SendLCSFrame(string frametype, string framedata)
+
+ Send a LCS position protocol frame to the Mobile
+ Network. The LCS frame typically represents a
+ Position Response.
+
+ Valid frametypes are:
+ rrlp_measure_position_response
+ rrc_measurement_report
+
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
+
+ void RequestFineTimeInjection(string rat, uint16 pulselength)
+
+ Request modem to generate a fine time injection
+ pulse. pulselength is the duration of the pulse
+ expressed in radio frames.
+
+ rat specifies the access technology used to derive
+ the pulse from and can be gsm or umts.
+ If the requested access technology is not currently
+ in use an error is returned.
+
+SignalsPropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ IncomingLCSFrame(string frametypes, string framedata)
+
+ LCS positioning protocol frame received from the
+ Mobile Network.
+
+ Valid frametypes for the LCS frame are:
+ rrlp_assistance_data
+ rrlp_measure_position_request
+ rrc_assistance_data_delivery
+ rrc_measurement_control
+
+ Note that position/measurement requests can include
+ assistance data as well.
+
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
+
+ FineTimeInjectionNotification(dict radioframenumber)
+
+ Notification about fine time injection pulse
+ generated by modem. The radioframenumber dict
+ is defined as follow:
+
+ string AccessTechnology
+ gsm or umts
+
+ uint32 TdmaFrameNumber (gsm only)
+ range 0 - 2715647 (2048*26*51)
+
+ uint16 TdmaTimeslot (gsm only)
+ range 0 - 7
+
+ uint16 TimeslotBit (gsm only)
+ range 0 - 156
+
+ uint16 TimingAdvance (gsm only)
+ range 0 - 63
+
+ uint16 BcchArfcn (gsm only)
+ range 0 - 1023
+
+ uint16 Bsic (gsm only)
+ range 0 - 64
+
+ uint16 Sfn (umts only)
+ range 0 - 4095
+
+ string RrcState (umts only)
+ cell_dch, cell_fach, cell_pch or
+ ura_pch
+
+ uint16 RoundTripTime (umts only)
+ range 0 - 32766
+
+
+Properties boolean LcsEnabled [readwrite]
+
+ If LcsEnabled is False, then no LCS
[RFC 2/3] agps: adding agps related functions
---
include/agps.h | 157
1 files changed, 157 insertions(+), 0 deletions(-)
create mode 100644 include/agps.h
diff --git a/include/agps.h b/include/agps.h
new file mode 100644
index 000..54f9b53
--- /dev/null
+++ b/include/agps.h
@@ -0,0 +1,157 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2010 Intel Corporation. All rights reserved.
+ *
+ * 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
+ *
+ */
+
+#ifndef __OFONO_AGPS_H_
+#define __OFONO_AGPS_H_
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include ofono/types.h
+
+enum ofono_lcs_frame_type {
+ RRLP_ASSISTANCE_DATA = 0, /* from modem */
+ /* Position request can include assistance data as well */
+ RRLP_MEASURE_POSITION_REQUEST = 1, /* from modem */
+ RRLP_MEASURE_POSITION_RESPONSE = 2, /* from GPS */
+ RRC_ASSISTANCE_DATA_DELIVERY = 3, /* from modem */
+ /* Measurement control can include assistance data as well */
+ RRC_MEASUREMENT_CONTROL = 4,/* from modem */
+ RRC_MEASUREMENT_REPORT = 5, /* from GPS */
+};
+
+enum ofono_access_technology {
+ RADIO_ACCESS_TECHNOLOGY_GSM = 0,/* GSM */
+ RADIO_ACCESS_TECHNOLOGY_UMTS = 1, /* UMTS */
+};
+
+enum ofono_rrc_state {
+ RRC_CELL_PCH = 0,
+ RRC_CELL_FACH = 1,
+ RRC_CELL_DCH = 2,
+ RRC_URA_PCH = 3,
+};
+
+struct ofono_lcs_frame {
+ enum ofono_lcs_frame_type lcs_frame_type;
+ int frame_length; /* size of raw_frame in bytes */
+ unsigned char *raw_frame;
+};
+
+struct ofono_lcs_gsm_fn {
+ int TDMA_frame_number; /* range 0 - 2715647 (2048*26*51) */
+ int TDMA_timeslot; /* range 0 - 7 */
+ int timeslot_bit; /* range 0 - 156 */
+ int timing_advance; /* range 0 - 63 */
+ int bcch_arfcn; /* range 0 - 1023 */
+ int bsic; /* range 0 - 64 */
+};
+
+struct ofono_lcs_utran_fn {
+ int sfn;/* range 0 - 4095 */
+ int rrc_state; /* enum ofono_rrc_state */
+ int round_trip_time;/* range 0 - 32766 */
+};
+
+struct ofono_lcs_radio_fn {
+ int radio_access_technology; /* enum access_technology */
+ union {
+ struct ofono_lcs_gsm_fn gsm_frame_number;
+ struct ofono_lcs_utran_fn utran_frame_number;
+ };
+};
+
+struct ofono_agps;
+
+typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
+ void *data);
+typedef void (*ofono_agps_receive_lcs_frame_cb_t)(
+ const struct ofono_error *error,
+ void *data);
+typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
+ struct ofono_lcs_radio_fn *radio_frame_number,
+ void *data);
+
+ /*
+* AGPS related functions, including LCS frame forwarding and
+* fine time injection
+*/
+struct ofono_agps_driver {
+ const char *name;
+ int (*probe)(struct ofono_agps *agps, unsigned int vendor,
+ void *data);
+ void (*remove)(struct ofono_agps *agps);
+
+ /* The GPS manager can configure the modem to notify Assistance Data and
+* Position Requests from the Mobile Network by setting the LcsEnabled
+* status to true. If false, no notifications are sent from modem.
+*/
+ void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled,
+ ofono_agps_receive_lcs_frame_cb_t cb, void *data);
+
+ /* Assistance Data and Position Requests from the Mobile Network are
+* signalled via the ofono_agps_lcs_frame_notify function and the
+* oFono core to an external GPS manager. This GPS manager can reply
+* to Position Requests with one or more Position Responses which
+* are then send back to the modem via the send_lcs_frame function.
+*/
+ void (*send_lcs_frame)(struct ofono_agps *agps,
+ struct ofono_lcs_frame *frame,
+ ofono_agps_send_lcs_frame_cb_t cb, void *data);
+
+
[RFC 3/3] ifxmodem: adding modem API to support agps
---
drivers/ifxmodem/agps.c | 438 +++
1 files changed, 438 insertions(+), 0 deletions(-)
create mode 100644 drivers/ifxmodem/agps.c
diff --git a/drivers/ifxmodem/agps.c b/drivers/ifxmodem/agps.c
new file mode 100644
index 000..9b68b7e
--- /dev/null
+++ b/drivers/ifxmodem/agps.c
@@ -0,0 +1,438 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2010 Intel Corporation. All rights reserved.
+ *
+ * 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
+
+#define _GNU_SOURCE
+#include string.h
+#include stdlib.h
+#include stdio.h
+#include errno.h
+
+#include glib.h
+
+#include gatchat.h
+#include gatresult.h
+
+#include ofono/log.h
+#include ofono/modem.h
+#include ofono/agps.h
+
+#include util.h
+#include ifxmodem.h
+
+struct agps_data {
+ GAtChat *chat;
+ unsigned int vendor;
+ enum ofono_access_technology rad_acc_tech;
+};
+
+struct ofono_agps;
+static enum ofono_access_technology rad_acc_tech;
+static const char *none_prefix[] = { NULL };
+
+#define FRAME_LEN 128
+
+static void pos_request_notify(GAtResult *result, gpointer user_data)
+{
+ struct ofono_agps *agps = user_data;
+ int framelen;
+ int frametype;
+ GAtResultIter iter;
+ struct ofono_lcs_frame lcsframe;
+ const char *messageframe;
+ unsigned char frame[FRAME_LEN];
+ long hexframelen;
+
+ /* Assuming Pos Req format: %XPOSR: frametype,framelen,frame */
+
+ g_at_result_iter_init(iter, result);
+
+ if (!g_at_result_iter_next(iter, %%XPOSR:))
+ return;
+
+ if (!g_at_result_iter_next_number(iter, frametype))
+ return;
+
+ if (!g_at_result_iter_next_number(iter, framelen))
+ return;
+
+ if (framelen FRAME_LEN) {
+ ofono_error(Got POS request msg more than max buffer size!);
+ return;
+ }
+
+ messageframe = g_at_result_pdu(result);
+
+ if (strlen(messageframe) sizeof(frame) * 2) { /*Hex, 2 chars/byte*/
+ ofono_error(Message frame too long!);
+ return;
+ }
+
+ if (decode_hex_own_buf(messageframe, -1, hexframelen, 0,
+ frame) == NULL) {
+ ofono_error(Unable to hex-decode the AGPS frame);
+ return;
+ }
+
+ DBG(Got POS request data: %s, %ld, frame, hexframelen);
+
+ if (hexframelen != framelen) {
+ ofono_error(hexframelen not equal to reported framelen);
+ return;
+ }
+
+ lcsframe.lcs_frame_type = frametype;
+ lcsframe.frame_length = framelen;
+ lcsframe.raw_frame = (unsigned char *)frame;
+
+ ofono_agps_lcs_frame_notify(agps, lcsframe);
+}
+
+static void inj_time_notify(GAtResult *result, gpointer user_data)
+{
+
+ struct cb_data *cbd = user_data;
+ struct agps_data *agd = cbd-user;
+ ofono_agps_inject_time_cb_t cb = cbd-cb;
+ struct ofono_lcs_radio_fn rf;
+ struct ofono_error error = { .type = OFONO_ERROR_TYPE_NO_ERROR };
+ GAtResultIter iter;
+
+ g_at_result_iter_init(iter, result);
+
+ if (!g_at_result_iter_next(iter, %%XFTI:))
+ return;
+
+ if (RADIO_ACCESS_TECHNOLOGY_GSM == rad_acc_tech) {
+
+ int fn; /* range 0 - 2715647 (2048*26*51) */
+ int ts; /* range 0 - 7 */
+ int tsb;/* range 0 - 156 */
+ int ta; /* range 0 - 63 */
+ int ba; /* range 0 - 1023 */
+ int bc; /* range 0 - 64 */
+
+ /* %XFTI:frameNum,TimeSlot,TimeSlotBit,TimeAdv,
+ * ChannelNum,ChannelId
+ */
+ if (!g_at_result_iter_next_number(iter, fn))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, ts))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, tsb))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, ta))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, ba))
+ goto err;
+
+ if (!g_at_result_iter_next_number(iter, bc))
+ goto
[PATCH] todo: ifxmodem apgs support
--- TODO |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index a5196f7..7ee7920 100644 --- a/TODO +++ b/TODO @@ -484,3 +484,8 @@ Miscellaneous Priority: Low Complexity: C4 + +- Modem support: adding support for agps in Infenion modem driver. + + Priority: High + Complexity: C3 -- 1.7.0.4 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] todo: ifxmodem apgs support
Hi Robertino, On 11/05/2010 12:55 PM, Robertino Benis wrote: --- TODO |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index a5196f7..7ee7920 100644 --- a/TODO +++ b/TODO @@ -484,3 +484,8 @@ Miscellaneous Priority: Low Complexity: C4 + +- Modem support: adding support for agps in Infenion modem driver. + + Priority: High + Complexity: C3 Please do not invent new complexities. The ones at listed at the top of the TODO file are the only ones you should be using. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] todo: ifxmodem apgs support
Hi Robertino, TODO |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index a5196f7..7ee7920 100644 --- a/TODO +++ b/TODO @@ -484,3 +484,8 @@ Miscellaneous Priority: Low Complexity: C4 + +- Modem support: adding support for agps in Infenion modem driver. + + Priority: High + Complexity: C3 I was expecting to have a section for Modem support. So something like this: Modem support = - Infineon modem: Add support ... Please run your patches through a spellchecker. It is Infineon and either Assisted GPS or aGPS. And sentences should start with a capital letter. There are still a few tasks in the TODO. So you have some examples on how we expect the format. The key point is consistency. Be it in the documentation, the TODO file or the source code itself. Please be also a bit more descriptive with the TODO entry so that others have an idea what it entails. Also please don't invent your own complexity types. The TODO file has an introduction section that describes it pretty clearly. I say this complexity task is clearly only a C1. For the priority, this is a general overall oFono priority scale. So all modem support items should be a Low. It has nothing to do with product schedules or anything alike. And please also add an Owner for the entry. That would be you in this case. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/3] doc: addidng documentation for basic assisted gps
Hi Robertino,
On 11/05/2010 12:55 PM, Robertino Benis wrote:
---
doc/assistedgps-manager-api.txt | 114
+++
1 files changed, 114 insertions(+), 0 deletions(-)
create mode 100644 doc/assistedgps-manager-api.txt
diff --git a/doc/assistedgps-manager-api.txt b/doc/assistedgps-manager-api.txt
new file mode 100644
index 000..b09c8b1
--- /dev/null
+++ b/doc/assistedgps-manager-api.txt
@@ -0,0 +1,114 @@
+AgpsManager hierarchy
+=
+
+Service org.ofono
+Interfaceorg.ofono.AgpsManager
So in general I'm currently against introducing this API as oFono
official API. I suggest prefixing this with an IFX specific identifier.
Maybe modem.ifx.AgpsManager.
+Object path [variable prefix]/{modem0,modem1,...}
+
+Methods dict GetProperties()
+
+ Returns properties for the modem object. See
+ the properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed as read-write are
+ changeable. On success a PropertyChanged signal
+ will be emitted.
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.DoesNotExist
+
+ void SendLCSFrame(string frametype, string framedata)
oFono is strict CamelCase, even for abbreviations. You do this
correctly above (AgpsManager) but not here. Please be consistent. And
it might be a good idea to not have abbreviations at all. What does LCS
stand for in this case?
+
+ Send a LCS position protocol frame to the Mobile
+ Network. The LCS frame typically represents a
+ Position Response.
+
+ Valid frametypes are:
+ rrlp_measure_position_response
+ rrc_measurement_report
+
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
Sending hex-encoded data screams as being non-portable and AT command
modem specific. Is this really your intent here?
+
+ void RequestFineTimeInjection(string rat, uint16 pulselength)
+
+ Request modem to generate a fine time injection
+ pulse. pulselength is the duration of the pulse
+ expressed in radio frames.
+
+ rat specifies the access technology used to derive
+ the pulse from and can be gsm or umts.
+ If the requested access technology is not currently
+ in use an error is returned.
It seems to me that making the upper layers pass in the rat as a
parameter to this function is a pretty bad idea. You should either have
the atom figure this out if it can (e.g. by using netreg atom) or have
the driver take care of this directly.
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ IncomingLCSFrame(string frametypes, string framedata)
+
+ LCS positioning protocol frame received from the
+ Mobile Network.
+
+ Valid frametypes for the LCS frame are:
+ rrlp_assistance_data
+ rrlp_measure_position_request
+ rrc_assistance_data_delivery
+ rrc_measurement_control
+
+ Note that position/measurement requests can include
+ assistance data as well.
+
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
Same comment as above about LCS naming and hex-encoded strings.
+
+ FineTimeInjectionNotification(dict radioframenumber)
+
+ Notification about fine time injection pulse
+ generated by modem. The radioframenumber dict
+ is defined as follow:
+
Why is this returned in a separate signal as opposed to a reply to the
RequestFineTimeInjection method call?
+ string AccessTechnology
+ gsm or umts
+
+ uint32 TdmaFrameNumber (gsm only)
+ range 0 - 2715647 (2048*26*51)
+
+
Re: [RFC 2/3] agps: adding agps related functions
Hi Robertino,
On 11/05/2010 12:55 PM, Robertino Benis wrote:
---
include/agps.h | 157
1 files changed, 157 insertions(+), 0 deletions(-)
create mode 100644 include/agps.h
diff --git a/include/agps.h b/include/agps.h
new file mode 100644
index 000..54f9b53
--- /dev/null
+++ b/include/agps.h
@@ -0,0 +1,157 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2008-2010 Intel Corporation. All rights reserved.
+ *
+ * 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
+ *
+ */
+
Please follow _all_ coding conventions in oFono. They're not optional
and we actually are pretty consistent across the board. Most of the
common 'gotcha's are documented in doc/coding-style.txt.
+#ifndef __OFONO_AGPS_H_
+#define __OFONO_AGPS_H_
That should be __OFONO_AGPS_H
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+#include ofono/types.h
+
+enum ofono_lcs_frame_type {
+ RRLP_ASSISTANCE_DATA = 0, /* from modem */
+ /* Position request can include assistance data as well */
+ RRLP_MEASURE_POSITION_REQUEST = 1, /* from modem */
+ RRLP_MEASURE_POSITION_RESPONSE = 2, /* from GPS */
+ RRC_ASSISTANCE_DATA_DELIVERY = 3, /* from modem */
+ /* Measurement control can include assistance data as well */
+ RRC_MEASUREMENT_CONTROL = 4,/* from modem */
+ RRC_MEASUREMENT_REPORT = 5, /* from GPS */
+};
+
Please see doc/coding-style.txt Section M11
+enum ofono_access_technology {
+ RADIO_ACCESS_TECHNOLOGY_GSM = 0,/* GSM */
+ RADIO_ACCESS_TECHNOLOGY_UMTS = 1, /* UMTS */
+};
+
Please see doc/coding-style.txt Section M11
+enum ofono_rrc_state {
+ RRC_CELL_PCH = 0,
+ RRC_CELL_FACH = 1,
+ RRC_CELL_DCH = 2,
+ RRC_URA_PCH = 3,
+};
+
Please see doc/coding-style.txt Section M11
+struct ofono_lcs_frame {
+ enum ofono_lcs_frame_type lcs_frame_type;
+ int frame_length; /* size of raw_frame in bytes */
+ unsigned char *raw_frame;
+};
+
+struct ofono_lcs_gsm_fn {
+ int TDMA_frame_number; /* range 0 - 2715647 (2048*26*51) */
+ int TDMA_timeslot; /* range 0 - 7 */
+ int timeslot_bit; /* range 0 - 156 */
+ int timing_advance; /* range 0 - 63 */
+ int bcch_arfcn; /* range 0 - 1023 */
+ int bsic; /* range 0 - 64 */
+};
Try to keep the same indentation level for comments
+
+struct ofono_lcs_utran_fn {
+ int sfn;/* range 0 - 4095 */
+ int rrc_state; /* enum ofono_rrc_state */
+ int round_trip_time;/* range 0 - 32766 */
+};
+
+struct ofono_lcs_radio_fn {
+ int radio_access_technology; /* enum access_technology */
You define an enum for this, but now use an int?
+ union {
+ struct ofono_lcs_gsm_fn gsm_frame_number;
+ struct ofono_lcs_utran_fn utran_frame_number;
+ };
+};
+
+struct ofono_agps;
+
+typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error
*error,
+ void *data);
+typedef void (*ofono_agps_receive_lcs_frame_cb_t)(
+ const struct ofono_error *error,
+ void *data);
+typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
+ struct ofono_lcs_radio_fn *radio_frame_number,
+ void *data);
+
+ /*
+ * AGPS related functions, including LCS frame forwarding and
+ * fine time injection
+ */
+struct ofono_agps_driver {
+ const char *name;
+ int (*probe)(struct ofono_agps *agps, unsigned int vendor,
+ void *data);
+ void (*remove)(struct ofono_agps *agps);
+
+ /* The GPS manager can configure the modem to notify Assistance Data and
+ * Position Requests from the Mobile Network by setting the LcsEnabled
+ * status to true. If false, no notifications are sent from modem.
+ */
+ void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled,
+ ofono_agps_receive_lcs_frame_cb_t cb, void *data);
+
+ /*
Re: [RFC 1/3] doc: addidng documentation for basic assisted gps
Hi Denis, doc/assistedgps-manager-api.txt | 114 +++ 1 files changed, 114 insertions(+), 0 deletions(-) create mode 100644 doc/assistedgps-manager-api.txt diff --git a/doc/assistedgps-manager-api.txt b/doc/assistedgps-manager-api.txt new file mode 100644 index 000..b09c8b1 --- /dev/null +++ b/doc/assistedgps-manager-api.txt @@ -0,0 +1,114 @@ +AgpsManager hierarchy += + +Serviceorg.ofono +Interface org.ofono.AgpsManager So in general I'm currently against introducing this API as oFono official API. I suggest prefixing this with an IFX specific identifier. Maybe modem.ifx.AgpsManager. I would actually go one step further and call this com.infineon.Agps or something like that. As I stated this many times, before we make this a generic oFono API, we need at least three types of modems that support this kind of feature and find the common API. For me this is clearly IFX and ISI right now. And it looks to me that Sjur has also shown interested, so the third one might be STE/MBM. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] sim: Check SIM pin status after changing pin.
Hi Marit, Just a gentle reminder not to top-post on this mailing list. On 11/05/2010 09:25 AM, Marit Sofie Henriksen wrote: Hi Denis. OK, I can see that this approach was rather too simplistic... Maybe checking the returned CME error would be a better idea? I’m a bit unsure how (or if) to proceed with this. As this is in the core, and not our driver, it might be more on your table? If you think it is important. Well this is definitely something we need to get right. So feel free to send a patch to the TODO file adding this task. The description is basically what I outlined in my earlier reply. E.g. if change_pin fails, we should check PIN state. If it is anything other than READY, tear the state back to pre_sim state and set the modem offline. this task can go through the regular task lifecycle. If you guys feel up to it, this is certainly something you can work on / contribute. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] sim: Check SIM pin status after changing pin.
Hi Marit, as Denis mentioned and I stated many times, please don't top post on this mailing list. It is against our mailing list etiquette. OK, I can see that this approach was rather too simplistic... Maybe checking the returned CME error would be a better idea? I’m a bit unsure how (or if) to proceed with this. As this is in the core, and not our driver, it might be more on your table? If you think it is important. So if I follow this logic, then it does mean we should not be fixing issues with the STE driver anymore? And not allowing you to use the generic AT modem and generic MBM modem drivers? Since these are strictly speaking not STE driver either. This is not how this works. Everybody works for the greater good to improve oFono. This is the way how it makes progress. The core is not a fixed piece of software. It evolves with the modems we support. If it needs to be changed or improved, then that is a task you should take up. And as explained by Denis, if you have found such a problem area inside the core, the generic drivers or anywhere else, write it down as part of the TODO list. So patches are highly encouraged. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/3] doc: addidng documentation for basic assisted gps
Hi, So in general I'm currently against introducing this API as oFono official API. I suggest prefixing this with an IFX specific identifier. Maybe modem.ifx.AgpsManager. I would actually go one step further and call this com.infineon.Agps or something like that. As I stated this many times, before we make this a generic oFono API, we need at least three types of modems that support this kind of feature and find the common API. For me this is clearly IFX and ISI right now. And it looks to me that Sjur has also shown interested, so the third one might be STE/MBM. Yes, I can confirm that we are looking into this and are planning to support AGPS for oFono. Would you be interested if we proposed an API whith transparent transport of the XML specified by 3GPP? Such an API should be possible to implement with the 3GPP standardized AGPS commands, so that a generic driver could be implemented (atmodem/agps.c). Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/3] doc: addidng documentation for basic assisted gps
Hi Sjur, On 11/05/2010 03:21 PM, Sjur Brændeland wrote: Hi, So in general I'm currently against introducing this API as oFono official API. I suggest prefixing this with an IFX specific identifier. Maybe modem.ifx.AgpsManager. I would actually go one step further and call this com.infineon.Agps or something like that. As I stated this many times, before we make this a generic oFono API, we need at least three types of modems that support this kind of feature and find the common API. For me this is clearly IFX and ISI right now. And it looks to me that Sjur has also shown interested, so the third one might be STE/MBM. Yes, I can confirm that we are looking into this and are planning to support AGPS for oFono. Would you be interested if we proposed an API whith transparent transport of the XML specified by 3GPP? Such an API should be possible to implement with the 3GPP standardized AGPS commands, so that a generic driver could be implemented (atmodem/agps.c). I would definitely like to see a 27.007 based aGPS proposal. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/3] doc: addidng documentation for basic assisted gps
oFono is strict CamelCase, even for abbreviations. You do this correctly above (AgpsManager) but not here. Please be consistent. And it might be a good idea to not have abbreviations at all. What does LCS stand for in this case? It refers to terminology from 3GPP TS 04.31: RRLP - Radio Resource LCS Protocol LCS - Location Services + The raw frame data is formatted as the concatenated + sequence of the two digit hexadecimal representation + of each of its octets. Example: 00FC2345 Sending hex-encoded data screams as being non-portable and AT command modem specific. Is this really your intent here? The intent is to send an array of octets. A string seemed a debug-friendly way of mapping it onto a DBUS API, but other suggestion for a suitable DBUS type are welcome. + void RequestFineTimeInjection(string rat, uint16 pulselength) It seems to me that making the upper layers pass in the rat as a parameter to this function is a pretty bad idea. You should either have the atom figure this out if it can (e.g. by using netreg atom) or have the driver take care of this directly. I was asked to add it as the AGPS manager that makes the request presumes a certain RAT and there is no point in generating the pulse if the RAT has changed since. See also http://lists.ofono.org/pipermail/ofono/2010-May/002347.html + + FineTimeInjectionNotification(dict radioframenumber) + + Notification about fine time injection pulse + generated by modem. The radioframenumber dict + is defined as follow: + Why is this returned in a separate signal as opposed to a reply to the RequestFineTimeInjection method call? The concern was that the reply would not be immediate, but I don't think it's that much delayed that it runs in any DBUS timeouts, so I think it can be turned into a reply instead. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/3] doc: addidng documentation for basic assisted gps
Hi Denis, So in general I'm currently against introducing this API as oFono official API. I suggest prefixing this with an IFX specific identifier. Maybe modem.ifx.AgpsManager. I would actually go one step further and call this com.infineon.Agps or something like that. As I stated this many times, before we make this a generic oFono API, we need at least three types of modems that support this kind of feature and find the common API. For me this is clearly IFX and ISI right now. And it looks to me that Sjur has also shown interested, so the third one might be STE/MBM. Yes, I can confirm that we are looking into this and are planning to support AGPS for oFono. Would you be interested if we proposed an API whith transparent transport of the XML specified by 3GPP? Such an API should be possible to implement with the 3GPP standardized AGPS commands, so that a generic driver could be implemented (atmodem/agps.c). I would definitely like to see a 27.007 based aGPS proposal. I agree. If 27.007 bothered to standardize it, the seems like a good idea to go for it. Btw. I don't like the term aGPS. Especially GPS. That is actually more like a product name and not really generic. Especially if you think about the positioning systems from the European Union or Russia. So I would like to see something like AssistedPositioning or in that spirit of it. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/3] doc: addidng documentation for basic assisted gps
Hi Waldo, oFono is strict CamelCase, even for abbreviations. You do this correctly above (AgpsManager) but not here. Please be consistent. And it might be a good idea to not have abbreviations at all. What does LCS stand for in this case? It refers to terminology from 3GPP TS 04.31: RRLP - Radio Resource LCS Protocol LCS - Location Services I am with Denis here. If you mean Location Services, then call it that way. Even within the API naming we are trying to be consistent and avoid abbreviations whenever possible. + The raw frame data is formatted as the concatenated + sequence of the two digit hexadecimal representation + of each of its octets. Example: 00FC2345 Sending hex-encoded data screams as being non-portable and AT command modem specific. Is this really your intent here? The intent is to send an array of octets. A string seemed a debug-friendly way of mapping it onto a DBUS API, but other suggestion for a suitable DBUS type are welcome. That is an array of bytes what you are looking for. A string of hex encoded octets is pretty much a bad idea for an API. It might be convenient for an AT command based modem, but a bad idea for an D-Bus based API. + void RequestFineTimeInjection(string rat, uint16 pulselength) It seems to me that making the upper layers pass in the rat as a parameter to this function is a pretty bad idea. You should either have the atom figure this out if it can (e.g. by using netreg atom) or have the driver take care of this directly. I was asked to add it as the AGPS manager that makes the request presumes a certain RAT and there is no point in generating the pulse if the RAT has changed since. See also http://lists.ofono.org/pipermail/ofono/2010-May/002347.html Seems still wrong to me. Why would an application have to deal with this. This looks like an internal implementation detail to me. Pushing such a thing out to the application is against the philosophy of our D-Bus APIs to simplify things. + FineTimeInjectionNotification(dict radioframenumber) + + Notification about fine time injection pulse + generated by modem. The radioframenumber dict + is defined as follow: + Why is this returned in a separate signal as opposed to a reply to the RequestFineTimeInjection method call? The concern was that the reply would not be immediate, but I don't think it's that much delayed that it runs in any DBUS timeouts, so I think it can be turned into a reply instead. And so is the signal. Both are bound to the scheduling of the D-Bus daemon. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH 1/4] doc: Add ModemAccessTechnology property
Hi Denis/Marcel, Hi Rajesh, doc/modem-api.txt |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/doc/modem-api.txt b/doc/modem-api.txt index c48375e..f5a3026 100644 --- a/doc/modem-api.txt +++ b/doc/modem-api.txt @@ -43,6 +43,15 @@ Properties boolean Powered [readwrite] modem. The Emergency is true if an emergency call or related operation is currently active. + string ModemAccessTechnology [readonly] + + Contains current access techonology of the modem. + Possible values are: + gsm - the current modem access technology is GSM + cdma - the current modem access technology is CDMA + + By default oFono uses gsm setting. + so you are in the org.ofono.Modem interface and its properties and you wanna prefix the property with Modem. That is rather pointless duplication of information. So just strip that. I prefix it with Modem just not to mix with the Network Access Technology. From the property name prespective I agree with you, its an redundant info as we are in org.ofono.Modem interface The obvious question we have to discuss, if we really wanna do it this way. What are the pros and what are the cons? I quite didnt get this query, pros and cons about this property usage or ? Any update on this ? If Modem prefix is the only comment, I can remove and resubmit the patch again. or is there more comments ? BR, Rajesh ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RfC] SIM file watch support.
In order to support the Refresh STK command we need to implement at
least two types of reset: UICC reset (manufacturer specific) and NAA
application reset. Other types can fall back to application reset
which can be implemented by removing all atoms and reinitialising them.
When we get a Refresh with File Change Notification we should first
check if we're even interested in the file. We check if the file is
being watched by any atom and whether the atom can deal with the change
dynamically. If not, we fall back to NAA application reset.
The proposed api lets the users of sim_fs_read register to
notifications of file change by adding a watch. In the simplest case
they can add a null watch for a file ID that they care about
(callback address is NULL), to indicate that the file is important to
us, but we haven't implemented a way to deal with the contents change
dynamically, or we can not.
(Maybe all files being read should automatically become watched, but
some files might be read only on some user action, in that case we
don't need to watch them)
stk.c will check if any of the file IDs supplied in the command have
any watches on them. If there are only watches with non-NULL
callback, it'll call all of them and not reset application. If
there are any NULL notifiers, then stk.c will fall back to full
application reset. If any of the files were cached, they need to
be re-read.
---
src/simfs.h | 12
src/sim.c | 21 -
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/src/simfs.h b/src/simfs.h
index ef962db..679955a 100644
--- a/src/simfs.h
+++ b/src/simfs.h
@@ -25,6 +25,8 @@ typedef void (*sim_fs_read_info_cb_t)(int ok, unsigned char
file_status,
int total_length, int record_length,
void *userdata);
+typedef void (*sim_fs_ef_notify_t)(int id, void *userdata);
+
struct sim_fs *sim_fs_new(struct ofono_sim *sim,
const struct ofono_sim_driver *driver);
@@ -48,3 +50,13 @@ char *sim_fs_get_cached_image(struct sim_fs *fs, int id);
void sim_fs_cache_image(struct sim_fs *fs, const char *image, int id);
void sim_fs_free(struct sim_fs *fs);
+
+int sim_fs_add_ef_watch(struct sim_fs *fs, int id,
+ sim_fs_ef_notify_t *notify, void *userdata);
+
+int sim_fs_remove_ef_watch(struct sim_fs *fs, int id,
+ sim_fs_ef_notify_t *notify, void *userdata);
+
+ofono_bool_t sim_fs_has_empty_watches(struct sim_fs *fs, int id);
+
+int sim_fs_notify_file_change(struct sim_fs *fs, int id);
diff --git a/src/sim.c b/src/sim.c
index 02ab329..ea36756 100644
--- a/src/sim.c
+++ b/src/sim.c
@@ -1184,15 +1184,23 @@ static void sim_ready(enum ofono_sim_state new_state,
void *user)
{
struct ofono_sim *sim = user;
- if (new_state != OFONO_SIM_STATE_READY)
+ if (new_state != OFONO_SIM_STATE_READY) {
+ sim_fs_remove_ef_watch(sim-simfs, SIM_EFMSISDN_FILEID,
+ NULL, sim);
+
return;
+ }
sim_own_numbers_update(sim);
+ sim_fs_add_ef_watch(sim-simfs, SIM_EFMSISDN_FILEID, NULL, sim);
ofono_sim_read(sim, SIM_EFSDN_FILEID, OFONO_SIM_FILE_STRUCTURE_FIXED,
sim_sdn_read_cb, sim);
+ sim_fs_add_ef_watch(sim-simfs, SIM_EFSDN_FILEID, NULL, sim);
+
ofono_sim_read(sim, SIM_EFIMG_FILEID, OFONO_SIM_FILE_STRUCTURE_FIXED,
sim_efimg_read_cb, sim);
+ sim_fs_add_ef_watch(sim-simfs, SIM_EFIMG_FILEID, NULL, sim);
}
static void sim_imsi_cb(const struct ofono_error *error, const char *imsi,
@@ -1437,6 +1445,7 @@ static void sim_efust_read_cb(int ok, int length, int
record,
ofono_sim_read(sim, SIM_EFEST_FILEID,
OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
sim_efest_read_cb, sim);
+ sim_fs_add_ef_watch(sim-simfs, SIM_EFEST_FILEID, NULL, sim);
return;
@@ -1497,6 +1506,7 @@ static void sim_efphase_read_cb(int ok, int length, int
record,
ofono_sim_read(sim, SIM_EFUST_FILEID,
OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
sim_efust_read_cb, sim);
+ sim_fs_add_ef_watch(sim-simfs, SIM_EFUST_FILEID, NULL, sim);
return;
}
@@ -1519,6 +1529,7 @@ static void sim_efphase_read_cb(int ok, int length, int
record,
ofono_sim_read(sim, SIM_EFSST_FILEID,
OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
sim_efsst_read_cb, sim);
+ sim_fs_add_ef_watch(sim-simfs, SIM_EFSST_FILEID, NULL, sim);
}
static void sim_initialize_after_pin(struct ofono_sim *sim)
@@ -1526,10 +1537,12 @@ static void sim_initialize_after_pin(struct ofono_sim
*sim)
ofono_sim_read(sim, SIM_EFPHASE_FILEID,
OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
