Hi Marcel.
> I do need another look at the RTNL magic and casting. That always drives
> my crazy when I look at that. In the meantime, please address these
> details first.
I have some RTNL unit tests ready if your're interested.
Also I hope I have closed most open issues from your review
in the
From: Sjur Brændeland
As requested, this is our initial proposal for a minimal API
in order to support E911, based on the 27.007 defined AT
commands.
We've discussed internally different names for this API:
AGNSSManager or AssistedGlobalNavigationSatelliteSystem,
but ended up with the si
From: Sjur Brændeland
---
Makefile.am |2 +
drivers/stemodem/caif_rtnl.c | 340 ++
drivers/stemodem/caif_rtnl.h | 29
3 files changed, 371 insertions(+), 0 deletions(-)
create mode 100644 drivers/stemodem/caif_rtnl.c
create
From: Sjur Brændeland
This patch-set applies on top of:
"[PATCH v5] stemodem: Add RTNL functionality managing CAIF Network Interfaces."
I have broken this patch-set into three separate patches as requested.
1) Bug-fixes and renaming
2) Restructuring for creating interfaces st
From: Sjur Brændeland
* renamed MAX_LEN to IP_ADDR_LEN
* removed memory leak from unneeded strdup when parsing xml response.
* better handling of AT error responses
* reduced number of caif interfaces to 4
---
drivers/stemodem/gprs-context.c | 54 ++
1
From: Sjur Brændeland
Create the network interfaces statically at start up
instead of dynamically for each PDP activation.
---
drivers/stemodem/gprs-context.c | 98 --
1 files changed, 52 insertions(+), 46 deletions(-)
diff --git a/drivers/stemodem/gprs
From: Sjur Brændeland
Use rtnl_caif_* functions to create network interfaces.
The conn_info struct is also re-structured in order to
hold the relevant information for network interfaces.
---
drivers/stemodem/gprs-context.c | 76 ++-
1 files changed, 67
Hi Marcel.
>> - struct conn_info *conn;
>> + struct conn_info *conn = NULL;
>> GSList *l;
>
> why do you need the conn = NULL assignment here? I haven't even looked
> into your code flow, but I prefer clearly to not have these.
I have removed this and tried to remove some of the oth
From: Sjur Brændeland
Changes:
o Restructure code so interfaces are created statically when probe is called.
o Removed some of the unnecessary initializations at declaration.
o No longer reporting "default gateway" on PtP IP Interface.
o Bugfix: Handle network initiated de
From: Sjur Brændeland
---
drivers/stemodem/gprs-context.c | 43 ++-
1 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index d8db23b..899379c 100644
--- a/drivers/stemodem/gprs
Hi Marcel.
>> 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.
>
> do you have a link to the D-Bus
Hi Marcel.
> So far this looks like a nice and simple proposal. And it is driven by
> an existing standard. I like that.
>
> Sjur, are you guys up to the task of sending an initial atom
> implementation and atmodem driver for it?
Yes, I think we should be able to, as longs as there is no big hurr
From: Sjur Brændeland
---
doc/coding-style.txt |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/doc/coding-style.txt b/doc/coding-style.txt
index 6fa355e..fb43891 100644
--- a/doc/coding-style.txt
+++ b/doc/coding-style.txt
@@ -205,6 +205,10 @@ default: // wrong
From: Sjur Brændeland
---
TODO |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/TODO b/TODO
index bf2305b..dec43fd 100644
--- a/TODO
+++ b/TODO
@@ -496,3 +496,11 @@ Miscellaneous
Priority: Low
Complexity: C4
+
+- Add Location Service API for providing
From: Sjur Brændeland
Use the type __u32 for sequence counting rather than guint32,
and "void *" instead of gpointer.
Reduce the size of RTNL message buffer from 4096 to 1024,
as this should be sufficient to hold the NEWLINK message.
---
drivers/stemodem/caif_rtnl.c | 14 +++
From: Sjur Brændeland
This patch introduces auto discovery of ST-Ericsson modems.
ST-Ericsson modems are managed by a Modem Init Daemon that
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
Hi Marcel.
> so how to you handle the case if you have two or more CAIF based modems
> in the system? oFono does not impose a limit here.
I guess there are at least two different scenarios here:
a) DualSim - In this case the Modem Init Daemon is working with one
piece of HW, and will expose on
Hi Denis & Marcel.
> From: Sjur Brændeland
>
> Changes:
> o Restructure code so interfaces are created statically when probe is called.
> o Removed some of the unnecessary initializations at declaration.
> o No longer reporting "default gateway" on PtP IP Inter
From: Sjur Brændeland
Changes:
o Restructure code so interfaces are created statically when probe is called.
o Removed some of the unnecessary initializations at declaration.
o No longer reporting "default gateway" on PtP IP Interface.
o Bugfix: Handle network initiated deactivation.
-
From: Sjur Brændeland
---
drivers/stemodem/gprs-context.c | 43 ++-
1 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index 3ccda87..3859107 100644
--- a/drivers/stemodem/gprs
From: Sjur Brændeland
Use the type __u32 for sequence counting rather than guint32,
and "void *" instead of gpointer.
Reduce the size of RTNL message buffer from 4096 to 1024,
as this should be sufficient to hold the NEWLINK message.
---
Last patch was sent with base64 encoding :-(
From: Sjur Brændeland
This patch set introduces unit tests for functionality in
o CAIF RTNL functions in drivers/stemodem/caif_rtnl.c
o GPRS context handling in drivers/stemodem/gprs-context.c
o Radio State settings in drivers/stemodem/radio-settings.c
o Test for CAIF Character devices are
From: Sjur Brændeland
- Remove tests for CAIF Character device. Character devices are depreceated
and replaced with Sockets.
- Add RTNL Tests for creating and removing CAIF GPRS Network Interface.
---
Makefile.am |4 +-
unit/test-caif.c | 108
From: Sjur Brændeland
Add unit tests for AT handling in stemodem/radio-settings.c and
stemodem/gprs-context.c. The tests integrates with gatchat
and verifies AT commands sent to modem and simulates modem
responses.
---
Makefile.am | 15 ++-
unit/test-ste.c | 554
Hi George.
> it looks as if two functions:
>
> caif_if_create/remove (struct conn_info *conn)
>
> do nothing but verify the return results of functions:
>
> caif_rtnl_create_interface/caif_rtnl_delete_interface
>
> declared in in caif_rtnl.h
>
> Which means if you #include caif_rtnl.h in gprs-con
From: Sjur Brændeland
Changes:
o Restructure code so interfaces are created statically when probe is called.
o Removed some of the unnecessary initializations at declaration.
o No longer reporting "default gateway" on PtP IP Interface.
o Bugfix: Handle network initiated deactivation
From: Sjur Brændeland
---
Changes from V2:
o Squashed functions caif_if_create info ste_gprs_context_probe
drivers/stemodem/gprs-context.c | 44 --
1 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers
Hi Denis.
>> Have you received this patch in readable format?
>> I'm sending patches using git send-email over gmail,
>> and when I check sent items in gmail, it comes up as base64 encoded.
>> Is this garbled for you as well?
>
> They seem to come through fine for me at least.
Good, that's a reli
From: Simon Lethbridge
This is our second proposal for the Assisted Satellite Navigation API,
this time including an Agent API. Hopefully most of the review comments
on our last proposal are included here.
As you can see we have changed the name again, this time to
"Assisted Satellite Navigation
Hi Marcel,
Marcel Holtmann wrote:
>> > 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 wo
From: Sjur Brændeland
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 "de
From: Sjur Brændeland
---
drivers/stemodem/gprs-context.c | 44 --
1 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index bfc0d65..21ca126 100644
--- a/drivers/stemodem/gprs
From: Sjur Brændeland
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
Hi Krishna,
> 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
From: Sjur Brændeland
This patch introduces auto discovery of ST-Ericsson modems.
ST-Ericsson modems (M5XX, 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
From: Sjur Brændeland
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 "de
From: Sjur Brændeland
---
drivers/stemodem/gprs-context.c | 43 --
1 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index 7bdcdb8..1762fb3 100644
--- a/drivers/stemodem/gprs
From: Lasse Kunnasluoto
---
test/test-call-barring | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/test/test-call-barring b/test/test-call-barring
index 5385a10..0756011 100755
--- a/test/test-call-barring
+++ b/test/test-call-barring
@@ -14,6 +14,7 @@ def pr
Hi Marcel.
>> +
>> +/* 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
Hi Marcel.
>> > 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
From: Sjur Brændeland
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 Dbu
Hi Kris,
> I am trying to understand CAIF protocol implementation in OFono. I am
> getting "Failed to create CAIF socket for AT" when i am trying to enable my
> modem.
Maybe the easies way to check if you have CAIF running is to try out
unit/test-caif.
It will try to open a CAIF Socket to the mo
Hi Marcel.
> 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 Daemo
Hi Marcel,
>> 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 Property
Hi Marcel,
> 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 wi
From: Sjur Brændeland
This is the latest version of the Modem Init Daemon API.
STE Modem Init Deamon Manager
=
Service com.stericsson.modeminit
Interface com.stericsson.modeminit.Manager
Object path /
Methods array{object,dict} GetModems
From: Sjur Brændeland
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 Dbu
From: Sjur Brændeland
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 Dbu
Hi Martin.
On Thu, Jan 6, 2011 at 10:46 AM, wrote:
> From: blutolan
Your git-config is wrong, you need to set name and email right in your
git-config before committing.
Regards,
Sjur
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/list
Hi Redouane,
...
> +static void gprs_cid_take(struct ofono_gprs *gprs, unsigned int id)
> +{
> + idmap_take(gprs->cid_map, id);
> +}
> +
How do we assure that this CID is not already in use?
I think the M7400 is going to use CID=0 and M700 uses CID=1.
Perhaps we should make sure CID=0 is a le
Hi,
> From my understanding the ID in the core is an internal ID for oFono core,
> even if today we usually have a mapping 1 to 1 between oFono core ID and
> modems CID.
> Denis, Marcel could you confirm ?
Negative, to my understanding the CID is allocated in src/gprs.c and used
when activating
Hi Marcel and Denis.
> 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...
Regards,
Sjur
_
Hi Fred,
Frederic wrote:
> The collision can only occur if the +CGDCONT (or +CGDSCONT) command from
> Ofono is sent at the same time as PDP context activation URC from the modem,
> and both use the same CID.
>
> But in that case, the modem should not reply "OK" to the PDP context
> configurati
Hi Marcel.
>> +static void get_modems()
>> +{
>
> so these are declared as get_modems(void) btw. The compiler should have
> warned you about this.
I don't get a compiler warning for this one, not even with -Wall
-Wextra -Wpedantic on GCC 4.4.3.
But a new rule in the coding-style should perhaps be
From: Sjur Brændeland
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 Dbu
From: Sjur Brændeland
---
Marcel, Denis,
Here is the patch, please apply it if you agree. I'm easy :-)
Regards,
Sjur
doc/coding-style.txt | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/doc/coding-style.txt b/doc/coding-style.txt
index 3bee240..40
Hi Marcel.
> you are out of luck today ;)
Darn, I forgot to pull. Hang on I'll be back shortly
Regards,
Sjur
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
From: Sjur Brændeland
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 Dbu
Hi Tomasz, don't worry the tone on the list is quite rough. If you
like marit or I can review tomorrow, but feel free to send patch as
well if you like. :) Sjur
2011/1/12, Tomasz Gregorek :
> Hi Marcel
> I already had my solution in head and misunderstood you. I will correct and
> retest it.
> Br
Hi,
Pekka Pessi wrote:
> The 27.007 for release 9 (from version 9.3.0 onwards) says:
>
> NOTE 1: 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.
>
> The change was proposed by STE last Feb
Hi,
So far we have been discussing CID races, but if we solve the CID issue,
we still might end up with two "identical" Connections activated with the same
connection properties (APN, Username, Password), one initiated by the modem
in the LTE Combined Attach procedure and the other being a "normal
Hi Pekka.
Pekka Pessi wrote:
>> I'm not sure we have any problems with Network Initiated Connection in oFono,
>> unless someone is planning to add support for Network Initiated
>> Primary Contexts / PDN Connections.
>
> AFAIK the initial LTE default bearer context can be network-initiated,
> and
From: Sjur Brændeland
---
I think we should consider changing the way we handle
signal strength in oFono.
In the past I have seen very frequent signal strength
reports from the modem under certain network conditions.
I think we can improve the power consumption by changing
the design here. I
Hi,
I notice that there has been a couple of bug reports sent on this list lately,
and usually the response is "care to send a patch for it?".
oFono homepage states: "A bug tracking system is in the process of
being set up."
What is the status of this?
It seems to be possible to submit bugs on o
From: Sjur Brændeland
Features:
- The QoS information is presented as an array of QoS settings with
an associated list IP Packet Filters. Only the QoS data for
connection context of type IMS will be reported.
The assumption is that QoS is only going to be used by IMS applications
Hi Rémi,
>> - The QoS information is presented as an array of QoS settings with
>> an associated list IP Packet Filters. Only the QoS data for
>> connection context of type IMS will be reported.
>>
>> The assumption is that QoS is only going to be used by IMS applications.
>> Initially I w
Hi Kai,
>>> + array{dict,array{dict}} QosFilters [readonly, optional]
>>> +
>>> + Information about the QoSes and associated Packet
>>> + Filters for the Default PDN and it's dedicated bearers.
>>> + It is organized as a list of Q
Hi Pekka,
>> Features:
>> - The QoS information is presented as an array of QoS settings with
>> an associated list IP Packet Filters. Only the QoS data for
>> connection context of type IMS will be reported.
>>
>> The assumption is that QoS is only going to be used by IMS applications.
>> Ini
From: Simon Lethbridge
This patch introduces support for Global Satellite Navigation System (GNSS),
using the AT commands AT+CPOS and +CPOSR as specified 3GPP 27.007.
---
Hi Denis,
2010/11/30 Denis Kenzior :
>> +AssistedSatelliteNavigation hierarchy
>What do you think of naming this AssistedNavi
Hi,
> + dict IPv6Settings [readonly, optional]
> +
> + Holds all the IPv6 network settings.
> +
> + string Interface [readonly, optional]
> +
> + Holds the name of the IPv6 network interface
> +
From: Simon Lethbridge
This patch introduces support for Global Satellite Navigation System (GNSS),
using the AT commands AT+CPOS and +CPOSR as specified 3GPP 27.007.
---
Changes from v1 (28 Jan):
s/SendPositioningControl/SendPositioningElement/
Thanks Rémi, for spotting this one,
Changes fr
Hi Arun,
>> + string PrivateImsIdentity [readonly, optional]
>> +
>> + Identity used for IMS registration.
>> + Available if present on the ISIM.
>> +
>> + string PublicImsIdentity [readonly, optional]
>> +
>> + Identity used for IMS registr
Hi Pekka.
>> Do you think we will ever have more than one IMS ConnectionContext pr SIM?
>> If not not we could probably keep the PcscfAddresses in this IMS API (see
>> object-path proposal below).
>
> Unfortunately, yes.
Could you please elaborate on this.
Do you really foresee a scenario where
Hi Marcel & Aki
>> > The current API has 'gsm', 'umts', 'lte' and 'any'. I think you are
>> > suggesting something like 'all-but-lte', right?
>> I think it would be nice if user could be able to select multiple
>> preferred bands, not just only one. The use case I came up with was
>> this 'all-bu
From: Sjur Brændeland
Thanks for lots of useful feedback from last RFC,
here is my next revision on the LTE/IMS API.
Comments are still very much welcome!
Changes from RFC-V1:
- Renamed IMS to IpMultimediaSubsystem (some places)
- Changed registration of IMS application
Hi Rémi,
> > +Service org.ofono
> > +Interface org.ofono.IpMultimediaSubsystem
> > +Object path [variable prefix]
>
> I guess this is meant to be a modem object path, but it seems the oFono
> documentation is already a bit sloppy on this point.
Yes, this should be the modem objec
Hi Redouane,
>> + void UnRegister(object path)
>> +
>> + Un-register a IpMultimediaSubsystemAgent.
>
> Register and UnRegister functions are not really symmetric here ...
> How object path is used by UnRegister function ??
> Maybe we should have :
> void UnRegister(
Hi Rémi,
>> > > + boolean PreConditionCheck(string Type, string
>> > > PeerAddress, + uint16 PeerPort,
>> > > uint16 LocalPort) +
>> >
>> > That stuff is per context. Should it not be in the context object rather
>> > than in the IMS manager?
>>
>>
From: Sjur Brændeland
With latest changes the P-CSCF addresses from ISIM can be read
from the IpMultimediaIdentity objects and the P-CSCF addresses
returned as dynamic parameters for the PDN Connection are avilable
in the ConnectionContext object.
I have also added LocalAddress to the IMS QoS
Jarko Poutiainen wrote:
> Hi,
>
> I have agreed with Sjur that I would take ownership of this.
...
> - Owner: Sjur Brændeland
> + Owner: Jarko Poutiainen
Acked-by: Sjur Brændeland
Regards
/Sjur
___
ofono mailing list
ofono
ing polling with
CLCC, but are using our proprietary call events. This impacts most functions.
The functions reusable from "atmodem" are "remove", "swap_without_accept", and
"send_tones". I guess we could copy the three common functions from "atmodem"
into
"stemodem" voicecall.c if you prefer this.
For Network Registration we have almost identical implementation, the difference
is that for signal strength reporting we are using "AT+CIND" instead of "CSQ"
and "CIEV".
"CSQ" is not working for WCDMA in our case.
I see that in the initialization function there is a switch on vendor.
I guess we could go for this approach if you think this is better.
>
>> +/* Create a CAIF socket for AT Service */
>> +fd = socket(AF_CAIF, SOCK_SEQPACKET, CAIFPROTO_AT); +
>> +/* Connect to the AT Service at the modem */
>> +connect(fd, (struct sockaddr *) &addr, sizeof(addr));
>> +channel = g_io_channel_unix_new(fd);
>
> You need to check the results of socket() and connect() calls.
Sure, will fix this.
Regards
Sjur Brændeland
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Hi Marcel.
Thank you for lots of feedback on patches. Marit who has done most of the
implementation is gone for a few days so we'll have to wait until end of
next week with the next oFono patch-set.
Marcel Holtmann wrote:
+ /* Need to change to gsm_permissive syntax in order to
+ *
Hi Denis.
Denis Kenzior wrote:
>> +static void ste_release_specific(struct ofono_voicecall *vc, int id,
>> +ofono_voicecall_cb_t cb, void *data) {
>> +struct voicecall_data *vd = ofono_voicecall_get_data(vc);
>> +struct release_id_req *req = g_try_new0(struct r
Hi Denis:
Denis Kenzior wrote:
> Hi Sjur,
>
>>> All of this logic needs to go away. The core already handles all of
>>> this, including selection of ATH/CHLD, waiting/held. Please review
>>> src/voicecall.c. If the core logic is not sufficient or does not
>>> properly handle a certain case, then
Hi Denis.
Sorry if you get this mail twice, something went wrong when posting this last
time so
I'm resending it.
We have done some testing with the STE modem for call termination, and this is
the result:
TC |Call #1 | Call #2 | Call #3 | Command | Result
---|---
Hi Denis.
We have done some testing with the STE modem for call termination,
and this is the result:
TC |Call #1 | Call #2 | Call #3 | Command | Result
---|
1 |ACTIVE | ACTIVE | .. | ATH | call 1, 2 termin
Hi Marcel.
Marcel Holtmann wrote:
>> len = sprintf(buf, "AT+CGDCONT=%u,\"IP\"", ctx->cid);
>>
>> if (ctx->apn)
>> snprintf(buf + len, sizeof(buf) - len - 3, ",\"%s\"",
>> ctx->apn);
>>
>> +/* Set username and password. Must be done after context creation */
>> +
Hi Marcel.
Marcel Holtmann wrote:
> Hi Sjur,
>
>> diff --git a/drivers/stemodem/gprs-context.c
>> b/drivers/stemodem/gprs-context.c index c178fb6..79e697b 100644
>> --- a/drivers/stemodem/gprs-context.c
>> +++ b/drivers/stemodem/gprs-context.c
>> @@ -187,9 +187,11 @@ static gboolean caif_if_creat
Hi Denis.
We have done some testing with the STE modem for call termination, and this is
the result:
TC |Call #1 | Call #2 | Call #3 | Command | Result
---|
1 |ACTIVE | ACTIVE | .. | ATH | call 1, 2 terminate
From: Sjur Brændeland
This patch splits the callback hangup into hangup_all and hangup_active.
---
Hi Denis,
I'm picking up a really old thread here...
> Denis Kenzior wrote:
>>>> c) If you have an call on hold and initiate a new call, but want to
>>>> te
Hi Denis,
Denis Kenzior wrote:
>> I'm picking up a really old thread here...
>Yes a really old thread ;)
Better late than never, right? :-)
...
>> However, I think we can solve this even simpler if we just
>> call hangup for any ALERTING/DIALING call..
>This is a real gray area. On some devices
From: Sjur Brændeland
This patch fixes problem with terminating calls in state DIALING/ALERTING
for STE-modem. The main change is that voicecall-callback function
hangup is split into the functions hangup_all and hangup_active.
CHANGES:
include/voicecall.h:
o hangup is replaced with
Hi Denis.
...
>> +static void at_hangup_active(struct ofono_voicecall *vc,
>> + ofono_voicecall_cb_t cb, void *data)
>> +{
>> + /* Hangup currently active call */
>
> It might be safer to only implement hangup_active in the generic driver.
> However, since this driver is o
From: Sjur Brændeland
---
drivers/atmodem/voicecall.c |4 ++--
drivers/calypsomodem/voicecall.c |2 +-
drivers/hfpmodem/voicecall.c |2 +-
drivers/isimodem/voicecall.c |2 +-
drivers/stemodem/voicecall.c |2 +-
include/voicecall.h |2 +-
6
From: Sjur Brændeland
This patch fixes problem for modems that cannot terminate DIALING/ALERTING
calls with CHUP=1X. The main change is that voicecall-callback function
hangup is split into the functions hangup_all and hangup_active.
Changes:
o In cases where hangup previously was used
From: Sjur Brændeland
---
src/voicecall.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/voicecall.c b/src/voicecall.c
index 49b9c79..4341d29 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -758,15 +758,21 @@ static void
From: Sjur Brændeland
---
drivers/atmodem/voicecall.c |4 ++--
drivers/calypsomodem/voicecall.c |2 +-
drivers/hfpmodem/voicecall.c |2 +-
drivers/isimodem/voicecall.c |2 +-
drivers/stemodem/voicecall.c |2 +-
include/voicecall.h |2 +-
6
From: Sjur Brændeland
This patch fixes problem for modems that cannot terminate DIALING/ALERTING
calls with CHUP=1X. The main change is that voicecall-callback function
hangup is split into the functions hangup_all and hangup_active.
Changes:
o In cases where hangup previously was used
From: Sjur Brændeland
---
src/voicecall.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/voicecall.c b/src/voicecall.c
index 49b9c79..4341d29 100644
--- a/src/voicecall.c
+++ b/src/voicecall.c
@@ -758,15 +758,21 @@ static void
From: Sjur Brændeland
---
drivers/stemodem/gprs-context.c | 48 +-
1 files changed, 2 insertions(+), 46 deletions(-)
diff --git a/drivers/stemodem/gprs-context.c b/drivers/stemodem/gprs-context.c
index 2e54f9f..29ee446 100644
--- a/drivers/stemodem/gprs
1 - 100 of 164 matches
Mail list logo
