Gustavo F. Padovan | 1 May 01:40 2010

Re: [PATCH] Add send_method_call to g_dbus

* Marcel Holtmann <marcel@...> [2010-04-27 04:33:36 +0200]:

> Hi Gustavo,
> 
> > Puting send_method_call and send_method_call_with_reply on g_dbus will
> > avoid some code duplication and will make things easier mainly for the
> > Bluetooth plugins (HFP, DUN, SAP) inside oFono.
> > ---
> >  gdbus/gdbus.h  |   12 ++++
> >  gdbus/object.c |   81 +++++++++++++++++++++++++++++
> >  plugins/hfp.c  |  154 +++++++++++++------------------------------------------
> >  3 files changed, 130 insertions(+), 117 deletions(-)
> 
> first of all, we don't intermix gdbus patches with other changes.
> Remember that these commits have to be applied to BlueZ and ConnMan as
> well.
> 
> > diff --git a/gdbus/gdbus.h b/gdbus/gdbus.h
> > index 47e18cf..ac488c5 100644
> > --- a/gdbus/gdbus.h
> > +++ b/gdbus/gdbus.h
> >  <at>  <at>  -106,12 +106,24  <at>  <at>  DBusMessage *g_dbus_create_error_valist(DBusMessage *message, const char *name,
> >  DBusMessage *g_dbus_create_reply(DBusMessage *message, int type, ...);
> >  DBusMessage *g_dbus_create_reply_valist(DBusMessage *message,
> >  						int type, va_list args);
> > +DBusMessage *g_dbus_create_method_call(const char *dest, const char *path,
> > +				const char *interface, const char *method,
> > +				int type, va_list args);
> >  
> >  gboolean g_dbus_send_message(DBusConnection *connection, DBusMessage *message);
(Continue reading)

Kalle Valo | 3 May 08:39 2010

Re: [PATCH v2 1/6] atmodem: create struct atmodem_gprs

Marcel Holtmann <marcel@...> writes:

> Hi Kalle,

Hi Marcel,

> I don't really like this. You only need to catch the CGREG anyway so we
> might just wanna add some indication method. Similar to what we have for
> network registration with ofono_netreg_status_notify.
>
> Then the messed up CGREG from Huawei modem doesn't dictate the whole
> simple one GAtChat approach. It is really their fault with no sending
> these on the proper AT command channel. No need to make other drivers
> suffer.

Sounds very good to me. I didn't even think about this because I was
under (false) impression that all AT commands must be handled in atmodem
driver.

I'm travelling the next two weeks, so it might take a while before I
have v3 ready.

--

-- 
Kalle Valo
Kalle Valo | 3 May 08:43 2010

Re: [PATCH v2 5/6] atmodem: add signal strength support for huawei

Marcel Holtmann <marcel@...> writes:

> Hi Kalle,
>
>> Huawei doesn't support CIND indications, instead it uses some non-standard
>> RSSI messages:
>> 
>> ofonod[6401]: < \r\n^RSSI:23\r\n
>> 
>> Add support for this to atmodem.
>
> please use ofono_netreg_strength_notify for this.
>
> The Huawei specific details with this stupid extra channel need to be
> handled inside the Huawei plugin. Cluttering the core with it is not a
> good idea.

I fully agree. I'll do this.

--

-- 
Kalle Valo
Torgny Johansson | 3 May 09:01 2010
Picon

Re: [PATCH] add vid/pid for Dell 5541 and 5542

fredagen den 30 april 2010 15.29.25 skrev  Marcel Holtmann:
> Hi Torgny,
> 
> > The following patch adds two new devices in the ofono.rules file:
> please use git format-patch and git send-email. Otherwise I get this:
> 
> Applying: add vid/pid for Dell 5541 and 5542
> fatal: corrupt patch at line 6
> Patch failed at 0001 add vid/pid for Dell 5541 and 5542
> 

Urgh I thought I had ironed out those issues... I'm blaming exchange :)

I'll give it a shot with git send-email in a while.

Thanks!

Regards
Torgny
torgny.johansson | 3 May 09:04 2010
Picon

[PATCH] add vid/pid for Dell 5541 and 5542

From: Torgny Johansson <torgny.johansson@...>

---
 plugins/ofono.rules |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/plugins/ofono.rules b/plugins/ofono.rules
index e6da49d..0575362 100644
--- a/plugins/ofono.rules
+++ b/plugins/ofono.rules
 <at>  <at>  -42,6 +42,10  <at>  <at>  ATTRS{idVendor}=="413c", ATTRS{idProduct}=="8147", ENV{OFONO_DRIVER}="mbm"
 ATTRS{idVendor}=="413c", ATTRS{idProduct}=="8183", ENV{OFONO_DRIVER}="mbm"
 ATTRS{idVendor}=="413c", ATTRS{idProduct}=="8184", ENV{OFONO_DRIVER}="mbm"

+# Dell F3307
+ATTRS{idVendor}=="413c", ATTRS{idProduct}=="818b", ENV{OFONO_DRIVER}="mbm"
+ATTRS{idVendor}=="413c", ATTRS{idProduct}=="818c", ENV{OFONO_DRIVER}="mbm"
+
 # Toshiba
 ATTRS{idVendor}=="0930", ATTRS{idProduct}=="130b", ENV{OFONO_DRIVER}="mbm"

--

-- 
1.7.0.4

Andrzej Zaborowski | 3 May 18:40 2010
Picon

Re: [PATCH 2/4][RFC] gatchat: Allow cancelling a running command.

Hi Denis,

On 30 April 2010 04:53, Denis Kenzior <denkenz <at> gmail.com> wrote:
>> Users need to be extra careful using the cancel functions because
>> there's a potential race condition where an OK or ERROR for the command
>> being cancelled arrives just the same moment the next command in the
>> queue is being submitted, and is treated as a response to that command.
>
> This is why this is just a really bad idea.  The only one I think we should
> cancel (and most vendors support reliably) is an ATD...

You're right, the only modem it seems to work on is the Calypso now
that I've tried a bunch of different ones.

Let's skip this patch.

>
> Are you sure your CSIM STATUS poll would actually time out or would the modem
> return a +CME/+CMS error?  In the end the modem does this polling itself...

In practice they'll return errors, though according to the specs, we
should be assuming the card is not there if we get no response for N
seconds.

On the Ericsson F3607 I found it'll actually fake a response with
status word 148,4 when card is not inserted, and doesn't do polling,
i.e. insertion can only be detected if you re-connected the modem, and
extraction only when you issued a command and the modem couldn't reach
the card to perform the command.

(Continue reading)

andrzej zaborowski | 3 May 20:22 2010
Picon

Re: [PATCH 3/4] gatchat: Emit notification when command is sent to modem.

Hi,

On 30 April 2010 07:48, Marcel Holtmann <marcel@...> wrote:
>> So I'm fine with the implementation but the name needs work.  Can we use
>> g_at_chat_send_with_submit_notify? Or maybe g_at_chat_send_full, similar to
>> how GLib does it.
>>
>> Perhaps enabling submit_notification for a given command after it has been
>> submitted with g_at_chat_send?
>>
>> e.g. g_at_chat_set_submit_notify(GAtChat *chat, guint command,
>> GAtSubmitNotifyFunc sent, gpointer user_data, GDestroyNotify notify);
>
> I am not a huge fan of the _full() stuff, but it is actually pretty nice
> for the cases where 99% of users don't care. And this seems to be one of
> them. The send_with_submit_notify() is way too long.
>
> Maybe g_at_chat_send_and_notify() is an acceptable simple version for
> this or just g_at_chat_submit() and g_at_chat_send() to keep these
> versions apart.

Here's a patch to add a g_at_chat_set_submit_notify function that
modifies an already submitted command.  Removing the destroy callback
from g_at_chat_send would require changing all the many uses of it.

Regards,
Andrew
(Continue reading)

Andrzej Zaborowski | 3 May 09:30 2010
Picon

[PATCH] Add a Calypso STK driver.

---
 Makefile.am                         |    3 +-
 drivers/calypsomodem/calypsomodem.c |    2 +
 drivers/calypsomodem/calypsomodem.h |    3 +
 drivers/calypsomodem/stk.c          |  274 +++++++++++++++++++++++++++++++++++
 plugins/phonesim.c                  |   46 +++++-
 5 files changed, 318 insertions(+), 10 deletions(-)
 create mode 100644 drivers/calypsomodem/stk.c

diff --git a/Makefile.am b/Makefile.am
index 463e52e..58d2dc0 100644
--- a/Makefile.am
+++ b/Makefile.am
 <at>  <at>  -161,7 +161,8  <at>  <at>  builtin_modules += calypsomodem
 builtin_sources += drivers/atmodem/atutil.h \
 			drivers/calypsomodem/calypsomodem.h \
 			drivers/calypsomodem/calypsomodem.c \
-			drivers/calypsomodem/voicecall.c
+			drivers/calypsomodem/voicecall.c \
+			drivers/calypsomodem/stk.c

 builtin_modules += hfpmodem
 builtin_sources += drivers/atmodem/atutil.h \
diff --git a/drivers/calypsomodem/calypsomodem.c b/drivers/calypsomodem/calypsomodem.c
index 8cd213e..2ae436a 100644
--- a/drivers/calypsomodem/calypsomodem.c
+++ b/drivers/calypsomodem/calypsomodem.c
 <at>  <at>  -35,12 +35,14  <at>  <at> 
 static int calypsomodem_init(void)
 {
(Continue reading)

Kristen Carlson Accardi | 4 May 00:23 2010
Picon

[PATCH] ppp: transition phase to DEAD when lcp finishes

change the state to DEAD when lcp finishes.  This prevents us from
calling our disconnect function again if we are already dead.
---
 gatchat/gatppp.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/gatchat/gatppp.c b/gatchat/gatppp.c
index 70669b0..dd6d84d 100644
--- a/gatchat/gatppp.c
+++ b/gatchat/gatppp.c
 <at>  <at>  -186,9 +186,6  <at>  <at>  static inline void ppp_enter_phase(GAtPPP *ppp, enum ppp_phase phase)
 {
 	g_print("Entering new phase: %d\n", phase);
 	ppp->phase = phase;
-
-	if (phase == PPP_PHASE_DEAD)
-		ppp_dead(ppp);
 }

 void ppp_set_auth(GAtPPP *ppp, const guint8* auth_data)
 <at>  <at>  -290,6 +287,10  <at>  <at>  void ppp_lcp_down_notify(GAtPPP *ppp)

 void ppp_lcp_finished_notify(GAtPPP *ppp)
 {
+	if (ppp->phase == PPP_PHASE_DEAD)
+		return;
+
+	ppp_enter_phase(ppp, PPP_PHASE_DEAD);
 	ppp_dead(ppp);
 }
(Continue reading)

Kristen Carlson Accardi | 4 May 00:45 2010
Picon

[PATCH] gatio: do not read if no read_handler

If no read_handler specified, leave data alone in case someone
else wants to read it.
---
 gatchat/gatio.c   |    4 ++++
 gatchat/gsmdial.c |   12 ++++--------
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gatchat/gatio.c b/gatchat/gatio.c
index 61b0260..b4a3806 100644
--- a/gatchat/gatio.c
+++ b/gatchat/gatio.c
 <at>  <at>  -91,6 +91,10  <at>  <at>  static gboolean received_data(GIOChannel *channel, GIOCondition cond,
 	if (cond & G_IO_NVAL)
 		return FALSE;

+	/* if nobody wants this data, leave it alone */
+	if (io->read_handler == NULL)
+		return TRUE;
+
 	/* Regardless of condition, try to read all the data available */
 	do {
 		toread = ring_buffer_avail_no_wrap(io->buf);
diff --git a/gatchat/gsmdial.c b/gatchat/gsmdial.c
index a531aa3..5fb406d 100644
--- a/gatchat/gsmdial.c
+++ b/gatchat/gsmdial.c
 <at>  <at>  -235,6 +235,8  <at>  <at>  static void ppp_connect(const char *iface, const char *ip,
 static void ppp_disconnect(GAtPPPDisconnectReason reason, gpointer user_data)
 {
 	g_print("PPP Link down: %d\n", reason);
(Continue reading)


Gmane