btw, the g_list_free_full implementation seems to handle a NULL GList
argument, but the glib doc doesn't explicitly mention that. I wonder if
it's better to add `if (glist_ptr)` check anyway.
On Tue, Mar 28, 2017 at 11:23 PM, Ben Chan wrote:
> When calling g_list_free_full() to free a GList in
When calling g_list_free_full() to free a GList in dispose(), it is
necessary to reset the GList pointer to NULL as dispose() may be called
more than once.
---
src/mm-call-list.c | 1 +
src/mm-device.c| 2 ++
src/mm-sms-list.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/src/mm-call-
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
---
src/kerneldevice/mm-kernel-device-generic-rules.c | 2 +-
src/mm-bearer-list.c
g_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
---
cli/mmcli-common.c | 30 +++---
cli/mmcli-manager.c | 4 ++--
2 files changed, 17 insertions(+), 17 de
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
---
plugins/altair/mm-broadband-modem-altair-lte.c | 4 ++--
plugins/cinterion/mm-broadband-modem-cinterio
g_object_unref is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on
g_object_unref is thus not needed.
---
libmm-glib/mm-modem-messaging.c | 4 ++--
libmm-glib/mm-modem-simple.c| 2 +-
libmm-glib/mm-modem-voice.c | 4 ++--
libm
Aleksander Morgado wrote the following:
> On Tue, Mar 28, 2017 at 2:41 AM, David McCullough
> wrote:
> >> > I am a little late to the party but here is the patch I have been running
> >> > to do this. I have been meaning to clean it up and send it in. Not sure
> >> > if there is anything here t
On 28/03/17 20:24, Ben Chan wrote:
> ---
> src/mm-base-bearer.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Pushed to git master, thanks.
> diff --git a/src/mm-base-bearer.h b/src/mm-base-bearer.h
> index 1e020dc6..0a94dcb6 100644
> --- a/src/mm-base-bearer.h
> +++ b/src/mm-base-b
On Tue, Mar 28, 2017 at 8:39 PM, Dan Williams wrote:
>> > > RE PolicyMismatch: we're not quite sure what that error
>> > > represents;
>> > > we've determined that in some cases it means IPv4 vs. IPv6
>> > > mismatch and
>> > > profiles in the modem, but that doesn't seem to always be the
>> > > c
On Tue, 2017-03-28 at 18:33 +0200, Bjørn Mork wrote:
> Einar Jón writes:
> > On 23 March 2017 at 02:42, Dan Williams wrote:
> > >
> > > RE PolicyMismatch: we're not quite sure what that error
> > > represents;
> > > we've determined that in some cases it means IPv4 vs. IPv6
> > > mismatch and
>
---
src/mm-base-bearer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mm-base-bearer.h b/src/mm-base-bearer.h
index 1e020dc6..0a94dcb6 100644
--- a/src/mm-base-bearer.h
+++ b/src/mm-base-bearer.h
@@ -59,7 +59,7 @@ typedef struct _MMBaseBearerPrivate MMBaseBearerPrivate;
Einar Jón writes:
> On 23 March 2017 at 02:42, Dan Williams wrote:
>>
>> RE PolicyMismatch: we're not quite sure what that error represents;
>> we've determined that in some cases it means IPv4 vs. IPv6 mismatch and
>> profiles in the modem, but that doesn't seem to always be the case.
>
> I'm no
Thanks for the update.
A couple of more question about resetting the modem, but I should
probably start a new thread for follow-up questions.
TLDR:
1) Once I have PolicyMismatch, I'm stuck until I reset. What to do
then? See -- 1 --- below
2) I can't reset this modem using "mmcli -r -m0". What alte
On Mon, Mar 27, 2017 at 5:45 PM, Aleksander Morgado
wrote:
>>> Could you share your latest additions and the full log you're getting?
>>>
>>
>> Attached you can find the updated patch that just skips the port
>> identification if the subsystem is not tty: not sure if this is the
>> best approach..
Hey
On Mon, Mar 27, 2017 at 5:50 PM, Carlo Lobrano wrote:
> In functions
>
> - mm_broadband_modem_lock_sms_storages
> - modem_messaging_set_default_storage
>
> return with error when using current_sms_mem1_storage as +CPMS value, but
> current_sms_mem1_storage value is UNKNOWN.
>
> ---
>
>>> +
On Tue, Mar 28, 2017 at 10:57 AM, carlo wrote:
>> BTW; does the PLATFORM_DRIVER_PROBE tag work if you tag
>> "/devices/pnp0/00:05/" instead of "/devices/pnp0/00:05/tty/ttyS0"?
>
>
> uhm, no, this way ttyS0 is not whitelisted, but it works with
> "/devices/pnp0/00:05/*"
> (or "/devices/pnp0/00:05/t
I assume you have the LABEL in a new line? i.e. this:
ACTION!="add|change|move", GOTO="mm_serial_end"
DEVPATH=="/devices/pnp0/00:05/tty/ttyS0", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
LABEL="mm_serial_end"
Yes, correct :D
Baudrate? The modem should use 57600bps, as that is what MM expects.
Oh, s
On Tue, Mar 28, 2017 at 10:21 AM, carlo wrote:
> Oops
> also a == for DEVPATH test
>
Oh, yeah, and that :)
> ACTION!="add|change|move", GOTO="mm_serial_end"
> DEVPATH=="/devices/pnp0/00:05/tty/ttyS0",
> ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1" LABEL="mm_serial_end"
>
I assume you have the LABEL in
Thanks to Daniele's suggestion, I changed modem baudrate to 57600 and
now it works fine
Carlo
On 28/03/2017 10:21, carlo wrote:
> Ok, please retry after adding the missing comma between the DEVPATH
and the ENV:
Oops
also a == for DEVPATH test
ACTION!="add|change|move", GOTO="mm_serial_end
> Ok, please retry after adding the missing comma between the DEVPATH
and the ENV:
Oops
also a == for DEVPATH test
ACTION!="add|change|move", GOTO="mm_serial_end"
DEVPATH=="/devices/pnp0/00:05/tty/ttyS0",
ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1" LABEL="mm_serial_end"
Now ttyS0 is whitelisted cor
On Tue, Mar 28, 2017 at 9:01 AM, Carlo Lobrano wrote:
> Here it is
>
> $ udevadm info -p /sys/class/tty/ttyS0
> P: /devices/pnp0/00:05/tty/ttyS0
> N: ttyS0
> E: DEVNAME=/dev/ttyS0
> E: DEVPATH=/devices/pnp0/00:05/tty/ttyS0
> E: ID_MM_CANDIDATE=1
> E: MAJOR=4
> E: MINOR=64
> E: SUBSYSTEM=tty
> E: T
On Tue, Mar 28, 2017 at 2:41 AM, David McCullough
wrote:
>> > I am a little late to the party but here is the patch I have been running
>> > to do this. I have been meaning to clean it up and send it in. Not sure
>> > if there is anything here that will help out but I figured it can't hurt
>> >
Here it is
$ udevadm info -p /sys/class/tty/ttyS0
P: /devices/pnp0/00:05/tty/ttyS0
N: ttyS0
E: DEVNAME=/dev/ttyS0
E: DEVPATH=/devices/pnp0/00:05/tty/ttyS0
E: ID_MM_CANDIDATE=1
E: MAJOR=4
E: MINOR=64
E: SUBSYSTEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=955641
On Mon, 27 Mar 2017 at 20:44 Aleksa
23 matches
Mail list logo
