Re: [PATCH] isimodem: notify sms-status-reports, too
Hi Pekka, 2011/4/12 : > From: Pekka Pessi > > --- > drivers/isimodem/sms.c | 11 ++- > 1 files changed, 10 insertions(+), 1 deletions(-) I actually ended up pushing a fix for this as part of the wgmodem2.5 additions. Thanks anyway! Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] isimodem: fix call_create_resp handling
Hi Pekka, 2011/4/12 : > From: Pekka Pessi > > In case of call creation failure modem may return a valid call id in > order to send CALL_SERVICE_DENIED_IND which we do not handle. > > Fixes MeeGo bug#15855. > --- > drivers/isimodem/voicecall.c | 39 +-- > 1 files changed, 33 insertions(+), 6 deletions(-) Patch has been pushed. Thanks! Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] isimodem: notify sms-status-reports, too
From: Pekka Pessi --- drivers/isimodem/sms.c | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/drivers/isimodem/sms.c b/drivers/isimodem/sms.c index 6f6b247..40dfa1d 100644 --- a/drivers/isimodem/sms.c +++ b/drivers/isimodem/sms.c @@ -564,6 +564,8 @@ static void routing_ntf_cb(const GIsiMessage *msg, void *data) GIsiSubBlockIter iter; uint8_t pdu[176]; + uint8_t len; + uint8_t tp_mti; if (g_isi_msg_id(msg) != SMS_PP_ROUTING_NTF) return; @@ -586,7 +588,14 @@ static void routing_ntf_cb(const GIsiMessage *msg, void *data) memcpy(pdu, addr.data, addr.len); memcpy(pdu + addr.len, tpdu.data, tpdu.len); - ofono_sms_deliver_notify(sms, pdu, tpdu.len + addr.len, tpdu.len); + len = addr.len + tpdu.len; + + tp_mti = pdu[addr.len] & 0x3; + + if (tp_mti == 0) + ofono_sms_deliver_notify(sms, pdu, len, tpdu.len); + else if (tp_mti == 2) + ofono_sms_status_notify(sms, pdu, len, tpdu.len); /* * FIXME: We should not ack the DELIVER unless it has been -- 1.7.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] TODO: set owner on DUN profile and DUN usb
--- TODO |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/TODO b/TODO index 3491436..573f0f7 100644 --- a/TODO +++ b/TODO @@ -137,6 +137,7 @@ Modem Emulator Complexity: C4 Priority: Medium + Owner: Guillaume Zajac Depends: PPP Server mode -- 1.7.1 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] isimodem: fix call_create_resp handling
From: Pekka Pessi
In case of call creation failure modem may return a valid call id in
order to send CALL_SERVICE_DENIED_IND which we do not handle.
Fixes MeeGo bug#15855.
---
drivers/isimodem/voicecall.c | 39 +--
1 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/isimodem/voicecall.c b/drivers/isimodem/voicecall.c
index 2cbd046..121cad6 100644
--- a/drivers/isimodem/voicecall.c
+++ b/drivers/isimodem/voicecall.c
@@ -574,15 +574,42 @@ static void isi_call_create_resp(const GIsiMessage *msg,
void *data)
{
struct isi_call_req_ctx *irc = data;
uint8_t call_id;
-
- if (!check_response_status(msg, CALL_CREATE_RESP) ||
- !g_isi_msg_data_get_byte(msg, 0, &call_id) ||
- call_id == CALL_ID_NONE) {
- isi_ctx_return_failure(irc);
- return;
+ uint8_t subblocks;
+
+ if (!check_response_status(msg, CALL_CREATE_RESP))
+ goto failure;
+
+ if (!g_isi_msg_data_get_byte(msg, 0, &call_id) ||
+ call_id == CALL_ID_NONE)
+ goto failure;
+
+ if (!g_isi_msg_data_get_byte(msg, 1, &subblocks))
+ goto failure;
+
+ if (subblocks != 0) {
+ GIsiSubBlockIter iter;
+ struct isi_call call = { 0 };
+
+ for (g_isi_sb_iter_init(&iter, msg, 2);
+ g_isi_sb_iter_is_valid(&iter);
+ g_isi_sb_iter_next(&iter)) {
+
+ switch (g_isi_sb_iter_get_id(&iter)) {
+ case CALL_CAUSE:
+ isi_call_cause_sb_proc(NULL, &call, &iter);
+ DBG("CALL_CREATE_RESP "
+ "cause_type=0x%02x cause=0x%02x",
+ call.cause_type, call.cause);
+ goto failure;
+ }
+ }
}
isi_ctx_return_success(irc);
+ return;
+
+failure:
+ isi_ctx_return_failure(irc);
}
static struct isi_call_req_ctx *isi_modem_call_create_req(
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 17/20] atmodem: add lte specific functions
Hi Vijay, >> That is still an assumption that needs to be confirmed. So >> does the default context activation from just uses APN == "" >> and then the network picks the APN to activate. Or does it >> just use the APN value from CID 1 for example. >> > > At this point , if the returned cid is out of range it is assumed this > would be default context (already activated). > Network has the APN and other required mandatory parameters required for > activation of default context. > This is done part of implicit attach process. > What Marcel is driving at is this comment from 27.007: "The s for network-initiated PDP contexts will have values outside the ranges indicated for the in the test form of the commands +CGDCONT and +CGDSCONT." Please do note that default EPS bearer is not network-initiated. It is ME-initiated. So I currently see no basis for your assumption. Have you checked how existing LTE modems actually do this? Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 10/20] doc: add PreferredMode property to modem
Hi Vijay, >> I don't like that this is being exposed on the modem >> interface. This really belongs on a separate atom. Not all >> modems are going to be LTE enabled yet... >> > Preferred mode is modem property on which mode modem is going to > operate. > Currently we have restricted this to read only for below reasons. > 1.No proper business case on why would user needs to play around this. > Unless operator give privilege to user to configure the modem behavior. > 2.Setting the preferred mode from user side would bring in new API for > driver essentially. > So again, this property is simply not going onto the Modem interface. It doesn't belong there since not all modems will be LTE enabled. In particular those pesky CDMA-only modems or 3G/2G GSM modems. You really need to put this on a separate atom dealing with IMS. And as mentioned before, I still see no actual use-case for this property. Until the usecase is presented, this property should be dropped. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 09/20] modem: add preferred ue mode handling
Hi Vijay, >> These values are really not telling anyone anything. How do >> you envision the upper layers using this information? >> > > Current preferred mode would show up as part of modem property for EPS > modem on the similar lines of onlne,powered,lockdown..etc. Yes, I know what a property is ;) > And also this property gets signalled if preferred mode changes.This is > currently happening during the enabling modem process. > We currently don't have option to set this from user side. You still have not answered the question. How do you envision the UI actually using this information. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 20/20] modem: Add netreg watch for tech switch
Hi Vijay, >> >> So what exactly needs to be done here? > > I see this as sort of placeholder for calling enablers for managing > atoms. > Relevent calls can be made considering access tech and modem operational > mode. > This would come into play as a result of acess technology switch (CSFB > to LTE and viceversa). This is really too vague. Do you have an actual usecase in mind here? Otherwise this code is really not show-casing anything right now. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 17/20] atmodem: add lte specific functions
>> This is really not working out, since you still need to get >> the interface for this context. The fact that a context is >> active does not necessarily mean that all the resources have >> been properly allocated. >> Namely a gprs-context allocated and all the implications >> (e.g. AT channel dedicated to the gprs-context is taken, ppp >> / high speed data connection established, etc.) >> >> Only the core can do the context allocation, so you still >> need to let the core decide what to do. >> > > I agree on your comments here. > Infact have missed out to put a todo here on interface assignment so > that this can be taken up when we work with real modem. > Interface assignment is not going to happen here, please re-think this entire approach. You really need to let the core allocate a context properly. >>> if (g_at_chat_send(psd->chat, "AT+CGREG?", cgreg_prefix, >>> at_cgreg_cb, cbd, g_free) > 0) >>> return; >> >> This is really just a bad idea. The core needs to understand >> the concept of CEREG properly, not try to hide this in the driver. >> > Intention here is to hide to the core on details of registraion > technology. > If core needs these awareness and want to fire relevent > API/functionality based on current access tech, would bring in new APIs > to driver for 3G registraion status and LTE registraion status. > This will also result in core to base it behaviour depending on acess > technology. Please get this idea out of your head. The core should know about LTE specific details. Changing the core is not something to be afraid of. The driver should not be hiding anything besides manufacturer specific details. The philosophy behind oFono's drivers has always been to make them dumb as rocks. If you're trying to make the driver smart, then you are already breaking one of the primary design principles. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC PATCH 08/20] include: add set preferred ue mode api
Hi Vijay, >>> +void ofono_modem_set_preferred_ue_mode(struct ofono_modem >> *modem, int >>> +mode); >>> + >> >> Are you assuming that the UE mode cannot be changed? If so, >> doesn't this map to +CEMODE AT command? Doesn't it allow a >> set operation to change the UE mode? >> > > We have made this currently read only as i don't see any usecase of this > being set from user side(settings or any other). > If a set provision need arises, this would bring in new API to driver > side as well to do the job. Also this would be purly apply for LTE. Then I don't see a need to even tell this information to the core then. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 17/20] atmodem: add lte specific functions
Hi Marcel,
Let me thank for the comments.
I am happy to see default context stuff dominate our discussion which is
kind of my expectation as well.
I agree that these things are not so clear from the spec point of view
and hopeful that they will shape out via for discussion and some support
from modem friends in community.
Any how I would consider all these comments going forward.
More comments in line.
Regards
Vijay
> -Original Message-
> From: ofono-boun...@ofono.org
> [mailto:ofono-boun...@ofono.org] On Behalf Of Marcel Holtmann
> Sent: 12 April 2011 06:44
> To: ofono@ofono.org
> Subject: Re: [RFC PATCH 17/20] atmodem: add lte specific functions
>
> Hi Vijay,
>
> > +static void at_cgcontrdp_cb(gboolean ok, GAtResult
> *result, gpointer
> > +user_data) {
> > + struct ofono_packet_service *ps = user_data;
> > + struct packet_service_data *psd =
> ofono_packet_service_get_data(ps);
> > + GAtResultIter iter;
> > + int cid, bearer_id;
> > + const char *apn, *address, *gateway, *dns1, *dns2;
> > + const char *dns[3];
> > + struct ofono_default_context_param *param;
> > +
> > + if (!ok)
> > + return;
> > +
> > + g_at_result_iter_init(&iter, result);
> > +
> > + if (g_at_result_iter_next(&iter, "+CGCONTRDP:") == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_number(&iter, &cid) == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_number(&iter, &bearer_id) == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_string(&iter, &apn) == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_string(&iter, &address) == FALSE)
> > + goto out;
> > +
> > + if (g_at_result_iter_next_string(&iter, &gateway) == FALSE)
> > + goto out;
> > +
> > + if (g_at_result_iter_next_string(&iter, &dns1) == FALSE)
> > + goto out;
> > +
> > + if (g_at_result_iter_next_string(&iter, &dns2) == FALSE)
> > + goto out;
> > +
> > + dns[0] = dns1;
> > + dns[1] = dns2;
> > + dns[2] = 0;
> > +
> > +out:
> > + param = g_new0(struct ofono_default_context_param, 1);
> > + if (param == NULL)
> > + return;
> > +
> > + param->cid = cid;
> > + param->proto = psd->default_context_type;
> > + param->apn = apn;
> > + param->address = address;
> > + param->gateway = gateway;
> > + param->dns = dns;
> > +
> > + ofono_packet_service_default_context_notify(ps, param);
> > +
> > + g_free(param);
> > + param = NULL;
> > +}
> > +
> > +static void at_cgdcont_cb(gboolean ok, GAtResult *result, gpointer
> > +user_data) {
> > + struct ofono_packet_service *ps = user_data;
> > + struct packet_service_data *psd =
> ofono_packet_service_get_data(ps);
> > + GAtResultIter iter;
> > + int cid;
> > + const char *pdp_type;
> > + char buf[64];
> > + gboolean found = FALSE;
> > +
> > + if (!ok)
> > + return;
> > +
> > + g_at_result_iter_init(&iter, result);
> > +
> > + while (!found && g_at_result_iter_next(&iter, "+CGDCONT:")) {
> > + if (g_at_result_iter_next_number(&iter, &cid) == FALSE)
> > + return;
> > +
> > + if (psd->default_cid != cid)
> > + continue;
> > +
> > + g_at_result_iter_next_string(&iter, &pdp_type);
> > +
> > + found = TRUE;
> > + }
> > +
> > + if (found == FALSE)
> > + return;
> > +
> > + if (g_str_equal(pdp_type, "IP"))
> > + psd->default_context_type = OFONO_PACKET_PROTO_IP;
> > + else if (g_str_equal(pdp_type, "IPV6"))
> > + psd->default_context_type = OFONO_PACKET_PROTO_IPV6;
> > + else if (g_str_equal(pdp_type, "IPV4V6"))
> > + psd->default_context_type = OFONO_PACKET_PROTO_IPV4V6;
> > +
> > + snprintf(buf, sizeof(buf), "AT+CGCONTRDP=%i", psd->default_cid);
>
> this looks wrong to me. Reading the CGDCONT information is
> not going to help us. We should just read CGCONTRDP if
> available or CGADDR it not.
>
> If we are a dual stack, then we will see two lines of
> CGCONTRDP, if not then I assume we can tell from the address
> if we are IP or IPV6. Same applies to CGADDR in case
> CGCONTRDP is not available.
>
> And of course we need to keep CGPIAF in mind.
Agreed that we can just do with CGCONTRDP and aviod CGDCONT.
Hope you are saying to differentiate IP and IPV6 based on the address
format.
>
> For me it is also important if is set
> or not since that tells us that this is the IMS context. And
> I would expect that all networks will use that one as default context.
>
> > + g_at_chat_send(psd->chat, buf, cgcontrdp_prefix,
> at_cgcontrdp_cb,
> > +
> ps, NULL);
> > +}
> > +
> > static void at_packet_service_registration_status(
> > struct ofono_packet_service *ps,
> >
> ofono_packet_service_status_cb_t cb, @@ -138,6 +273,13 @@ static
> >
RE: [RFC PATCH 10/20] doc: add PreferredMode property to modem
Hi Dennis, > "data centric". > > + "PS mode 1" UE registers only to EPS > > + services, and > UE's usage setting > > + is "voice centric". > > + > > I don't like that this is being exposed on the modem > interface. This really belongs on a separate atom. Not all > modems are going to be LTE enabled yet... > Preferred mode is modem property on which mode modem is going to operate. Currently we have restricted this to read only for below reasons. 1.No proper business case on why would user needs to play around this. Unless operator give privilege to user to configure the modem behavior. 2.Setting the preferred mode from user side would bring in new API for driver essentially. Regards, Vijay > -Original Message- > From: Denis Kenzior [mailto:denk...@gmail.com] > Sent: 11 April 2011 22:28 > To: ofono@ofono.org > Cc: Nayani Vijay > Subject: Re: [RFC PATCH 10/20] doc: add PreferredMode > property to modem > > Hi Vijay, > > On 04/11/2011 05:20 AM, Vijay Nayani wrote: > > --- > > doc/modem-api.txt | 18 ++ > > 1 files changed, 18 insertions(+), 0 deletions(-) > > > > diff --git a/doc/modem-api.txt b/doc/modem-api.txt index > > fa400a2..c79bffa 100644 > > --- a/doc/modem-api.txt > > +++ b/doc/modem-api.txt > > @@ -54,6 +54,24 @@ Properties boolean Powered [readwrite] > > modem. The Emergency is true if an > emergency call or > > related operation is currently active. > > > > + string PreferredMode [readonly, optional] > > + > > + Preferred UE mode setting. A UE > attached for EPS services > > + shall operate in one of the following > operation modes: > > + > > + "PS mode 2" UE registers only to EPS > > + services, and > UE's usage setting > > + is "data centric". > > + "CS/PS mode 1" UE registers to > both EPS and > > + non-EPS > services, and UE's usage > > + setting is > "voice centric". > > + "CS/PS mode 2" UE registers to > both EPS and > > + non-EPS > services, and UE's usage > > + setting is > "data centric". > > + "PS mode 1" UE registers only to EPS > > + services, and > UE's usage setting > > + is "voice centric". > > + > > I don't like that this is being exposed on the modem > interface. This really belongs on a separate atom. Not all > modems are going to be LTE enabled yet... > > Have you looked at the IMS/LTE API proposal from Sjur a while back? > > > string Name [readonly, optional] > > > > Friendly name of the modem device. > > Regards, > -Denis > ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 09/20] modem: add preferred ue mode handling
Hi Dennis,
> -Original Message-
> From: Denis Kenzior [mailto:denk...@gmail.com]
> Sent: 11 April 2011 22:36
> To: ofono@ofono.org
> Cc: Nayani Vijay
> Subject: Re: [RFC PATCH 09/20] modem: add preferred ue mode handling
>
> Hi Vijay,
>
> > +static const char *preferred_ue_mode_to_string(int mode) {
> > + switch (mode) {
> > + case PREFERRED_UE_MODE_PS_DATA_CENTRIC:
> > + return "PS mode 2";
> > + case PREFERRED_UE_MODE_CS_PS_VOICE_CENTRIC:
> > + return "PS/CS mode 1";
> > + case PREFERRED_UE_MODE_CS_PS_DATA_CENTRIC:
> > + return "PS/CS mode 2";
> > + case PREFERRED_UE_MODE_PS_VOICE_CENTRIC:
> > + return "PS mode 1";
> > + }
> > +
> > + return "unknown";
> > +}
> > +
>
> These values are really not telling anyone anything. How do
> you envision the upper layers using this information?
>
Current preferred mode would show up as part of modem property for EPS
modem on the similar lines of onlne,powered,lockdown..etc.
And also this property gets signalled if preferred mode changes.This is
currently happening during the enabling modem process.
We currently don't have option to set this from user side.
> Regards,
> -Denis
>
Regards,
Vijay
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 20/20] modem: Add netreg watch for tech switch
Hi Denis,
> > + case PREFERRED_UE_MODE_CS_PS_DATA_CENTRIC:
> > + /*
> > +* All atoms needs to be created which is
> > +* already done
> > +*/
> > + break;
> > + }
> > + break;
> > + case ACCESS_TECHNOLOGY_GSM:
> > + case ACCESS_TECHNOLOGY_GSM_COMPACT:
> > + case ACCESS_TECHNOLOGY_UTRAN:
> > + case ACCESS_TECHNOLOGY_GSM_EGPRS:
> > + case ACCESS_TECHNOLOGY_UTRAN_HSDPA:
> > + case ACCESS_TECHNOLOGY_UTRAN_HSUPA:
> > + case ACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA:
> > + switch(modem->pref_mode) {
> > + case PREFERRED_UE_MODE_PS_VOICE_CENTRIC:
> > + /* Switch to 3G */
> > + break;
> > + case PREFERRED_UE_MODE_CS_PS_VOICE_CENTRIC:
> > + case PREFERRED_UE_MODE_CS_PS_DATA_CENTRIC:
> > + /*
> > +* All atoms needs to be created which
> is already
> > +* done.
> > +*/
> > + break;
> > + default:
> > + break;
> > + }
> > + break;
> > + }
> > +}
> > +
>
> So what exactly needs to be done here?
I see this as sort of placeholder for calling enablers for managing
atoms.
Relevent calls can be made considering access tech and modem operational
mode.
This would come into play as a result of acess technology switch (CSFB
to LTE and viceversa).
Regards,
Vijay
> -Original Message-
> From: Denis Kenzior [mailto:denk...@gmail.com]
> Sent: 11 April 2011 22:57
> To: ofono@ofono.org
> Cc: Nayani Vijay
> Subject: Re: [RFC PATCH 20/20] modem: Add netreg watch for tech switch
>
> Hi Vijay,
>
> > +static void netreg_status_watch(int status, int lac, int
> ci, int tech,
> > + const char *mcc, const
> char *mnc,
> > + void *data)
> > +{
> > + struct ofono_modem *modem = data;
> > +
> > + if (status != NETWORK_REGISTRATION_STATUS_REGISTERED &&
> > + status != NETWORK_REGISTRATION_STATUS_ROAMING)
> > + return;
> > +
> > + switch (tech) {
> > + case ACCESS_TECHNOLOGY_EUTRAN:
> > + switch(modem->pref_mode) {
> > + case PREFERRED_UE_MODE_PS_VOICE_CENTRIC:
> > + case PREFERRED_UE_MODE_PS_DATA_CENTRIC:
> > + /* No need to do any switching */
> > + break;
> > + case PREFERRED_UE_MODE_CS_PS_VOICE_CENTRIC:
> > + case PREFERRED_UE_MODE_CS_PS_DATA_CENTRIC:
> > + /*
> > +* All atoms needs to be created which is
> > +* already done
> > +*/
> > + break;
> > + }
> > + break;
> > + case ACCESS_TECHNOLOGY_GSM:
> > + case ACCESS_TECHNOLOGY_GSM_COMPACT:
> > + case ACCESS_TECHNOLOGY_UTRAN:
> > + case ACCESS_TECHNOLOGY_GSM_EGPRS:
> > + case ACCESS_TECHNOLOGY_UTRAN_HSDPA:
> > + case ACCESS_TECHNOLOGY_UTRAN_HSUPA:
> > + case ACCESS_TECHNOLOGY_UTRAN_HSDPA_HSUPA:
> > + switch(modem->pref_mode) {
> > + case PREFERRED_UE_MODE_PS_VOICE_CENTRIC:
> > + /* Switch to 3G */
> > + break;
> > + case PREFERRED_UE_MODE_CS_PS_VOICE_CENTRIC:
> > + case PREFERRED_UE_MODE_CS_PS_DATA_CENTRIC:
> > + /*
> > +* All atoms needs to be created which
> is already
> > +* done.
> > +*/
> > + break;
> > + default:
> > + break;
> > + }
> > + break;
> > + }
> > +}
> > +
>
> So what exactly needs to be done here?
>
> Regards,
> -Denis
>
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [RFC PATCH 17/20] atmodem: add lte specific functions
> -Original Message-
> From: Denis Kenzior [mailto:denk...@gmail.com]
> Sent: 11 April 2011 22:55
> To: ofono@ofono.org
> Cc: Nayani Vijay
> Subject: Re: [RFC PATCH 17/20] atmodem: add lte specific functions
>
> On 04/11/2011 05:20 AM, Vijay Nayani wrote:
> > Changes include: Registration of CEREG events, registration status
> > query based on registered technology, handling of ME PDN ACT CGEV
> > event, reading of default context params and notification
> of default
> > context params to the core.
> > ---
> > drivers/atmodem/packet-service.c | 238
> > ++
> > 1 files changed, 238 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/atmodem/packet-service.c
> > b/drivers/atmodem/packet-service.c
> > index d9d..b766a3b 100644
> > --- a/drivers/atmodem/packet-service.c
> > +++ b/drivers/atmodem/packet-service.c
> > @@ -4,6 +4,7 @@
> > *
> > * Copyright (C) 2008-2010 Intel Corporation. All rights
> reserved.
> > * Copyright (C) 2010 ST-Ericsson AB.
> > + * Copyright 2011 EB(Elektrobit).
> > *
> > * 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
> > @@ -40,17 +41,23 @@ #include "gatchat.h"
> > #include "gatresult.h"
> >
> > +#include "common.h"
> > +
> > #include "atmodem.h"
> > #include "vendor.h"
> >
> > static const char *cgreg_prefix[] = { "+CGREG:", NULL }; static
> > const char *cgdcont_prefix[] = { "+CGDCONT:", NULL };
> > +static const char *cereg_prefix[] = { "+CEREG:", NULL };
> static const
> > +char *cgcontrdp_prefix[] = { "+CGCONTRDP:", NULL };
> > static const char *none_prefix[] = { NULL };
> >
> > struct packet_service_data {
> > GAtChat *chat;
> > int default_cid;
> > int default_context_type;
> > + int cid_min;
> > + int cid_max;
> > unsigned int vendor;
> > };
> >
> > @@ -109,6 +116,134 @@ static void at_cgreg_cb(gboolean ok,
> GAtResult *result, gpointer user_data)
> > cb(&error, status, cbd->data);
> > }
> >
> > +static void at_cereg_cb(gboolean ok, GAtResult *result, gpointer
> > +user_data) {
> > + struct cb_data *cbd = user_data;
> > + ofono_packet_service_status_cb_t cb = cbd->cb;
> > + struct ofono_error error;
> > + int status;
> > + struct packet_service_data *psd = cbd->user;
> > +
> > + decode_at_error(&error, g_at_result_final_response(result));
> > +
> > + if (!ok) {
> > + cb(&error, -1, cbd->data);
> > + return;
> > + }
> > +
> > + if (at_util_parse_reg(result, "+CEREG:", NULL, &status,
> > + NULL, NULL, NULL, psd->vendor)
> == FALSE) {
> > + CALLBACK_WITH_FAILURE(cb, -1, cbd->data);
> > + return;
> > + }
> > +
> > + cb(&error, status, cbd->data);
> > +}
> > +
> > +static void at_cgcontrdp_cb(gboolean ok, GAtResult
> *result, gpointer
> > +user_data) {
> > + struct ofono_packet_service *ps = user_data;
> > + struct packet_service_data *psd =
> ofono_packet_service_get_data(ps);
> > + GAtResultIter iter;
> > + int cid, bearer_id;
> > + const char *apn, *address, *gateway, *dns1, *dns2;
> > + const char *dns[3];
> > + struct ofono_default_context_param *param;
> > +
> > + if (!ok)
> > + return;
> > +
> > + g_at_result_iter_init(&iter, result);
> > +
> > + if (g_at_result_iter_next(&iter, "+CGCONTRDP:") == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_number(&iter, &cid) == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_number(&iter, &bearer_id) == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_string(&iter, &apn) == FALSE)
> > + return;
> > +
> > + if (g_at_result_iter_next_string(&iter, &address) == FALSE)
> > + goto out;
> > +
> > + if (g_at_result_iter_next_string(&iter, &gateway) == FALSE)
> > + goto out;
> > +
> > + if (g_at_result_iter_next_string(&iter, &dns1) == FALSE)
> > + goto out;
> > +
> > + if (g_at_result_iter_next_string(&iter, &dns2) == FALSE)
> > + goto out;
> > +
> > + dns[0] = dns1;
> > + dns[1] = dns2;
> > + dns[2] = 0;
> > +
> > +out:
> > + param = g_new0(struct ofono_default_context_param, 1);
> > + if (param == NULL)
> > + return;
> > +
> > + param->cid = cid;
> > + param->proto = psd->default_context_type;
> > + param->apn = apn;
> > + param->address = address;
> > + param->gateway = gateway;
> > + param->dns = dns;
> > +
> > + ofono_packet_service_default_context_notify(ps, param);
>
> This is really not working out, since you still need to get
> the interface for this context. The fact that a context is
> active does not necessarily mean that all the resources have
> been properly allocated.
> Namely a gprs-context allocated and all the implications
> (e.g. AT channel dedicated to the gprs-context is taken, ppp
> / high speed data
RE: [RFC PATCH 08/20] include: add set preferred ue mode api
Hi Denis, > -Original Message- > From: Denis Kenzior [mailto:denk...@gmail.com] > Sent: 11 April 2011 22:35 > To: ofono@ofono.org > Cc: Nayani Vijay > Subject: Re: [RFC PATCH 08/20] include: add set preferred ue mode api > > Hi Vijay, > > On 04/11/2011 05:20 AM, Vijay Nayani wrote: > > --- > > include/modem.h |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/include/modem.h b/include/modem.h index > 5a34370..e416f50 > > 100644 > > --- a/include/modem.h > > +++ b/include/modem.h > > @@ -51,6 +51,8 @@ void ofono_modem_reset(struct ofono_modem > *modem); > > void ofono_modem_set_powered(struct ofono_modem *modem, > ofono_bool_t > > powered); ofono_bool_t ofono_modem_get_powered(struct ofono_modem > > *modem); > > > > +void ofono_modem_set_preferred_ue_mode(struct ofono_modem > *modem, int > > +mode); > > + > > Are you assuming that the UE mode cannot be changed? If so, > doesn't this map to +CEMODE AT command? Doesn't it allow a > set operation to change the UE mode? > We have made this currently read only as i don't see any usecase of this being set from user side(settings or any other). If a set provision need arises, this would bring in new API to driver side as well to do the job. Also this would be purly apply for LTE. > > ofono_bool_t ofono_modem_get_online(struct ofono_modem *modem); > > > > ofono_bool_t ofono_modem_get_emergency_mode(struct ofono_modem > > *modem); > > Regards, > -Denis > Regards, Vijay ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
