date:20170328

[PATCH 2/4] plugins: remove explicit GDestroyNotify cast on g_free / g_object_unref

2017-03-28 Thread Ben Chan

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-cinterion.c |  6 +++---
 plugins/huawei/mm-broadband-modem-huawei.c   | 14 +++---
 plugins/icera/mm-broadband-bearer-icera.c|  2 +-
 plugins/icera/mm-broadband-modem-icera.c |  6 +++---
 plugins/iridium/mm-broadband-modem-iridium.c |  2 +-
 plugins/longcheer/mm-broadband-modem-longcheer.c |  2 +-
 plugins/mbm/mm-broadband-bearer-mbm.c|  4 ++--
 plugins/mbm/mm-broadband-modem-mbm.c |  2 +-
 plugins/mtk/mm-broadband-modem-mtk.c |  2 +-
 plugins/novatel/mm-broadband-modem-novatel-lte.c |  2 +-
 plugins/option/mm-broadband-bearer-hso.c |  4 ++--
 plugins/option/mm-broadband-modem-hso.c  |  6 +++---
 plugins/sierra/mm-broadband-bearer-sierra.c  |  2 +-
 plugins/sierra/mm-broadband-modem-sierra-icera.c |  2 +-
 plugins/sierra/mm-broadband-modem-sierra.c   |  2 +-
 plugins/telit/mm-broadband-modem-telit.c |  2 +-
 plugins/tests/test-fixture.c |  2 +-
 plugins/ublox/mm-broadband-bearer-ublox.c|  4 ++--
 plugins/ublox/mm-broadband-modem-ublox.c |  2 +-
 plugins/zte/mm-broadband-modem-zte.c |  2 +-
 21 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/plugins/altair/mm-broadband-modem-altair-lte.c 
b/plugins/altair/mm-broadband-modem-altair-lte.c
index 1155a7a1..572a1bfd 100644
--- a/plugins/altair/mm-broadband-modem-altair-lte.c
+++ b/plugins/altair/mm-broadband-modem-altair-lte.c
@@ -128,7 +128,7 @@ broadband_bearer_new_ready (GObject *source,
 else
 g_simple_async_result_set_op_res_gpointer (simple,
bearer,
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 g_simple_async_result_complete (simple);
 g_object_unref (simple);
 }
@@ -198,7 +198,7 @@ load_unlock_retries_ready (MMBaseModem *self,
 mm_unlock_retries_set (retries, MM_MODEM_LOCK_SIM_PUK2, puk2);
 g_simple_async_result_set_op_res_gpointer (operation_result,
retries,
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 } else {
 g_simple_async_result_set_error (operation_result,
  MM_CORE_ERROR,
diff --git a/plugins/cinterion/mm-broadband-modem-cinterion.c 
b/plugins/cinterion/mm-broadband-modem-cinterion.c
index ae092a0e..4a4e18bf 100644
--- a/plugins/cinterion/mm-broadband-modem-cinterion.c
+++ b/plugins/cinterion/mm-broadband-modem-cinterion.c
@@ -1438,7 +1438,7 @@ load_unlock_retries_context_step 
(LoadUnlockRetriesContext *ctx)
 if (ctx->i == G_N_ELEMENTS (unlock_retries_map)) {
 g_simple_async_result_set_op_res_gpointer (ctx->result,
g_object_ref (ctx->retries),
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 load_unlock_retries_context_complete_and_free (ctx);
 return;
 }
@@ -1643,7 +1643,7 @@ broadband_bearer_cinterion_new_ready (GObject 
*source,
 if (!bearer)
 g_simple_async_result_take_error (ctx->result, error);
 else
-g_simple_async_result_set_op_res_gpointer (ctx->result, bearer, 
(GDestroyNotify)g_object_unref);
+g_simple_async_result_set_op_res_gpointer (ctx->result, bearer, 
g_object_unref);
 create_bearer_context_complete_and_free (ctx);
 }
 
@@ -1659,7 +1659,7 @@ broadband_bearer_new_ready (GObject *source,
 if (!bearer)
 g_simple_async_result_take_error (ctx->result, error);
 else
-g_simple_async_result_set_op_res_gpointer (ctx->result, bearer, 
(GDestroyNotify)g_object_unref);
+g_simple_async_result_set_op_res_gpointer (ctx->result, bearer, 
g_object_unref);
 create_bearer_context_complete_and_free (ctx);
 }
 
diff --git a/plugins/huawei/mm-broadband-modem-huawei.c 
b/plugins/huawei/mm-broadband-modem-huawei.c
index 74e680b4..49c77e9a 100644
--- a/plugins/huawei/mm-broadband-modem-huawei.c
+++ b/plugins/huawei/mm-broadband-modem-huawei.c
@@ -1933,7 +1933,7 @@ set_3gpp_unsolicited_events_handlers 
(MMBroadbandModemHuawei *self,
 NULL);
 }
 
-g_list_free_full (ports, (GDestroyNotify)g_object_unref);
+g_list_free_full (ports, g_object_unref);
 }
 
 static gboolean
@@ -2266,7 +2266,7 @@ broadband_bearer_huawei_new_ready (GObject *source,
 if (!bearer)
 g_simple_async_result_take_error

[PATCH 4/4] libmm-glib: remove explicit GDestroyNotify cast on g_object_unref

2017-03-28 Thread Ben Chan

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 ++--
 libmm-glib/mm-modem.c   | 6 +++---
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/libmm-glib/mm-modem-messaging.c b/libmm-glib/mm-modem-messaging.c
index 682cae93..a6e281fc 100644
--- a/libmm-glib/mm-modem-messaging.c
+++ b/libmm-glib/mm-modem-messaging.c
@@ -230,7 +230,7 @@ typedef struct {
 static void
 sms_object_list_free (GList *list)
 {
-g_list_free_full (list, (GDestroyNotify) g_object_unref);
+g_list_free_full (list, g_object_unref);
 }
 
 static void
@@ -492,7 +492,7 @@ new_sms_object_ready (GDBusConnection *connection,
 else
 g_simple_async_result_set_op_res_gpointer (ctx->result,
sms,
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 
 create_sms_context_complete_and_free (ctx);
 }
diff --git a/libmm-glib/mm-modem-simple.c b/libmm-glib/mm-modem-simple.c
index 9338c453..14624995 100644
--- a/libmm-glib/mm-modem-simple.c
+++ b/libmm-glib/mm-modem-simple.c
@@ -138,7 +138,7 @@ new_bearer_ready (GDBusConnection *connection,
 else
 g_simple_async_result_set_op_res_gpointer (ctx->result,
bearer,
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 
 connect_context_complete_and_free (ctx);
 }
diff --git a/libmm-glib/mm-modem-voice.c b/libmm-glib/mm-modem-voice.c
index f517b1b9..1d649454 100644
--- a/libmm-glib/mm-modem-voice.c
+++ b/libmm-glib/mm-modem-voice.c
@@ -95,7 +95,7 @@ typedef struct {
 static void
 call_object_list_free (GList *list)
 {
-g_list_free_full (list, (GDestroyNotify) g_object_unref);
+g_list_free_full (list, g_object_unref);
 }
 
 static void
@@ -357,7 +357,7 @@ new_call_object_ready (GDBusConnection *connection,
 else
 g_simple_async_result_set_op_res_gpointer (ctx->result,
call,
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 
 create_call_context_complete_and_free (ctx);
 }
diff --git a/libmm-glib/mm-modem.c b/libmm-glib/mm-modem.c
index 80181f68..25e042d0 100644
--- a/libmm-glib/mm-modem.c
+++ b/libmm-glib/mm-modem.c
@@ -1763,7 +1763,7 @@ typedef struct {
 static void
 bearer_object_list_free (GList *list)
 {
-g_list_free_full (list, (GDestroyNotify) g_object_unref);
+g_list_free_full (list, g_object_unref);
 }
 
 static void
@@ -2027,7 +2027,7 @@ modem_new_bearer_ready (GDBusConnection *connection,
 else
 g_simple_async_result_set_op_res_gpointer (ctx->result,
bearer,
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 
 create_bearer_context_complete_and_free (ctx);
 }
@@ -2868,7 +2868,7 @@ modem_get_sim_ready (GDBusConnection *connection,
 else
 g_simple_async_result_set_op_res_gpointer (simple,
sim,
-   
(GDestroyNotify)g_object_unref);
+   g_object_unref);
 
 g_simple_async_result_complete (simple);
 g_object_unref (simple);
-- 
2.12.2.564.g063fe858b8-goog

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Quectel UC20: Correct way to get it up and running on embedded?

2017-03-28 Thread Aleksander Morgado

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
>> > > case.
>> >
>> > I'm not sure what is causing it, but it's quite easy to reproduce
>> > by
>> > messing with the kernel module (e.g. reloading it):
>> > $ sudo rmmod qmi_wwan
>> > $ sudo modprobe qmi_wwan
>>
>> My best guess is that you experience some mismatch between an
>> auto-connected bearer and the bearer you try to connect.  But it's a
>> wild guess.  Try messing with the preconfigured profiles, changing
>> between IP, IPV6 and IPV4V6 contexts and see if you can prevent the
>> issue that way.
>
> Are the QMI "autoconnect" settings actually the EPS Default Bearer, or
> are they different?  Maybe
>
> qmicli --wds-set-autoconnect-settings=disabled
>
> would do the trick, but I don't know for sure.

I don't think the auto-connection in QMI relates to the EPS Default
Bearer, although also, not sure :)

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH] base-bearer: fix typo in 'bearer-default-ip-family' property name

2017-03-28 Thread Ben Chan

---
 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;
 #define MM_BASE_BEARER_MODEM "bearer-modem"
 #define MM_BASE_BEARER_STATUS"bearer-status"
 #define MM_BASE_BEARER_CONFIG"bearer-config"
-#define MM_BASE_BEARER_DEFAULT_IP_FAMILY "bearer-deafult-ip-family"
+#define MM_BASE_BEARER_DEFAULT_IP_FAMILY "bearer-default-ip-family"
 
 typedef enum { /*< underscore_name=mm_bearer_status >*/
 MM_BEARER_STATUS_DISCONNECTED,
-- 
2.12.2.564.g063fe858b8-goog

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Quectel UC20: Correct way to get it up and running on embedded?

2017-03-28 Thread Bjørn Mork

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 not sure what is causing it, but it's quite easy to reproduce by
> messing with the kernel module (e.g. reloading it):
> $ sudo rmmod qmi_wwan
> $ sudo modprobe qmi_wwan

My best guess is that you experience some mismatch between an
auto-connected bearer and the bearer you try to connect.  But it's a
wild guess.  Try messing with the preconfigured profiles, changing
between IP, IPV6 and IPV4V6 contexts and see if you can prevent the
issue that way.

> I have a couple of other ways to reset the modem, but no easy ones:
> 1)  The Quectel manual says that the command
> AT+QRST=1,0
> will reset the modem immediately, but I don't know how to send AT
> commands to the modem.
> There's no /dev/ttyUSB*, although the device is connected via USB:
> $ mmcli -m 0 | grep devices
>   System   | device:
> '/sys/devices/pci:00/:00:17.0/:01:00.0/:02:08.3/usb2/2-3'
>
> 2) There's also a Control Signal Pin PERST# on the UC20 Mini PCIe board:
> - You can reset the module by driving the PERST# to a low level
> voltage of more than 150ms and then release it.
> Messing with the pins seems a bit drastic...
>
> 3) Rebooting the linux machine also seems to work, but this kills our uptime.

You could try a USB reset.  There is a utility for that in the latest
(yet unreleased) usbutils:
https://github.com/gregkh/usbutils/blob/master/usbreset.c

This will reset the USB device controller, but not necessarily reboot
the modem. So I am not sure it makes any difference in your case.  But
worth trying if you haven't already.

Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Quectel UC20: Correct way to get it up and running on embedded?

2017-03-28 Thread Einar Jón

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 alternatives do
I have? See -- 2 --- below

Full version:
 1 
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 not sure what is causing it, but it's quite easy to reproduce by
messing with the kernel module (e.g. reloading it):
$ sudo rmmod qmi_wwan
$ sudo modprobe qmi_wwan

After that I'm stuck in the following loop - I have moved ifup to
CONNECTED state, so it is not interrupting this flow:
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Disabling modem...
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Modem state: REGISTERED
-> DISABLING
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Registration State: UNKNOWN
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Modem state: DISABLING -> DISABLED
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Enabling modem...
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Modem state: DISABLED -> ENABLING
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Operator Code: 20404
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Operator Name: DATA ONLY
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Registration State: HOME
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Modem state: ENABLING -> REGISTERED
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Current operator: 20404
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Modem state: REGISTERED
-> CONNECTING
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Modem state: CONNECTING
-> REGISTERED
Mar 28 16:21:05 ubuntu12 modemmonitor[1383]: Bearer connect failed
(attempt 1): org.freedesktop.libqmi.Error.Protocol.PolicyMismatch: QMI
protocol error (79): 'PolicyMismatch'
Mar 28 16:21:06 ubuntu12 modemmonitor[1383]: Disabling modem...

According to this:
https://lists.freedesktop.org/archives/libqmi-devel/2014-August/000901.html
a modem reset should be sufficient.

But if I don't reset, this loop will continue about once a second,
which is now what I want.
* Any suggestions on what to do when my system gets in a mess like this?

 2 
Unfortunately the UC20 doesn't seem to support a reset using the DBUS.
Is this a limitation of ModemManager or the UC20 modem?
$ mmcli -m 0 -rv
[28 Mar 2017, 16:27:35] [Debug] ModemManager process found at ':1.3'
[28 Mar 2017, 16:27:35] [Debug] Assuming '0' is the modem index
[28 Mar 2017, 16:27:35] [Debug] Modem found at
'/org/freedesktop/ModemManager1/Modem/0'

[28 Mar 2017, 16:27:35] [Debug] Synchronously reseting modem...
error: couldn't reset the modem:
'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Unsupported:
Cannot reset the modem: operation not supported'

I have a couple of other ways to reset the modem, but no easy ones:
1)  The Quectel manual says that the command
AT+QRST=1,0
will reset the modem immediately, but I don't know how to send AT
commands to the modem.
There's no /dev/ttyUSB*, although the device is connected via USB:
$ mmcli -m 0 | grep devices
  System   | device:
'/sys/devices/pci:00/:00:17.0/:01:00.0/:02:08.3/usb2/2-3'

2) There's also a Control Signal Pin PERST# on the UC20 Mini PCIe board:
- You can reset the module by driving the PERST# to a low level
voltage of more than 150ms and then release it.
Messing with the pins seems a bit drastic...

3) Rebooting the linux machine also seems to work, but this kills our uptime.

-- 
Best regards
Einar Jón
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] telit: support QMI and MBIM modems

2017-03-28 Thread Aleksander Morgado

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...
>>
>
> Yes, that approach is fine I think; it should cover all the cases
> where you do want port type hints (AT primary, AT secondary and NMEA).

Daniele, I've pushed your patch to git master.

Thanks!

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Flow control settings for RS232 modems

2017-03-28 Thread Aleksander Morgado

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/tty/*" if we want to be more selective)"

Is it that multiple TTYs are being exposed under the same
/devices/pnp0/00:05/ path?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Flow control settings for RS232 modems

2017-03-28 Thread Aleksander Morgado

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 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"

> Now ttyS0 is whitelisted correctly, but still some problems in using Telit
> plugin (or any other plugin). MM log attached.

Baudrate? The modem should use 57600bps, as that is what MM expects.
If a different one, you can add a new rule like:
DEVPATH=="/devices/pnp0/00:05/tty/ttyS0", ENV{ID_MM_TTY_BAUDRATE}="115200"

Also, 8N1 as serial port settings, but I doubt it's different in your modem.

BTW; does the PLATFORM_DRIVER_PROBE tag work if you tag
"/devices/pnp0/00:05/" instead of "/devices/pnp0/00:05/tty/ttyS0"?

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Flow control settings for RS232 modems

2017-03-28 Thread carlo

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"
DEVPATH=="/devices/pnp0/00:05/tty/ttyS0", 
ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1" LABEL="mm_serial_end"


Now ttyS0 is whitelisted correctly, but still some problems in using 
Telit plugin (or any other plugin). MM log attached.


Carlo



On 28/03/2017 09:41, Aleksander Morgado wrote:

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: TAGS=:systemd:
E: USEC_INITIALIZED=955641


On Mon, 27 Mar 2017 at 20:44 Aleksander Morgado
wrote:

On Mon, Mar 27, 2017 at 6:04 PM, carlo  wrote:

Does this work?

# cat < /lib/udev/rules.d/78-mm-serial.rules
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"
EOF
# udevadm control --reload
# udevadm trigger
// Relaunch MM

Ok, please retry after adding the missing comma between the DEVPATH and the ENV:

# cat < /lib/udev/rules.d/78-mm-serial.rules
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"
EOF
# udevadm control --reload
# udevadm trigger
# udevadm info -p /sys/class/tty/ttyS0

This should really add the tag.





___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Flow control settings for RS232 modems

2017-03-28 Thread Aleksander Morgado

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: TAGS=:systemd:
> E: USEC_INITIALIZED=955641
>
>
> On Mon, 27 Mar 2017 at 20:44 Aleksander Morgado 
> wrote:
>>
>> On Mon, Mar 27, 2017 at 6:04 PM, carlo  wrote:
>> >> Does this work?
>> >>
>> >> # cat < /lib/udev/rules.d/78-mm-serial.rules
>> >> 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"
>> >> EOF
>> >> # udevadm control --reload
>> >> # udevadm trigger
>> >> // Relaunch MM
>> >

Ok, please retry after adding the missing comma between the DEVPATH and the ENV:

# cat < /lib/udev/rules.d/78-mm-serial.rules
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"
EOF
# udevadm control --reload
# udevadm trigger
# udevadm info -p /sys/class/tty/ttyS0

This should really add the tag.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: [PATCH] telit: support QMI and MBIM modems

2017-03-28 Thread Aleksander Morgado

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 
>> > :-)
>>
>> This is more or less the MBIM part of what we're suggesting to do but
>> on mm-1-6, right? In git master we no longer require the TELIT_TAGGED
>> tag, and we have the "mm_kernel_device" support instead of the
>> GUDevDevice.
>>
>> David, if you could test your setup with git master (it's compatible
>> to 1.6.x) and Daniele's updated patch, it would be great.
>
> I would love to.  I have been trying to move to master for some time now but
> on our platform there is a severe memory corruption in later versions that 
> has been very
> hard to track down.
>
> One of the object initialisers is overwriting memory in the wrong part of an 
> object and
> causing MM to crash.  I did know where is was (and who) but I was pulled off 
> it for
> higher priority issues and it sbeen a while now :-(
>
> Any thoughts on what could be causing glib object iitialisers to get out of 
> sync would
> be appreciated.  IIRC is was in and around the SIM creation and all in 
> egenric code.
> Doesn't seem to matter which Modem I am using it will crash.  Eventually I 
> will be
> free'd up to resolve this, hopefully sooner rather than later ;-)
>

Oh, is this a new thing? Is this in some specific platform or plain
i386/x86_64? I'll give it some valgrind runs to see if I find
something.

> As for the Telit, it would be nice if we could pull in some of the Telit 
> plugins AT
> command based methods to supplement the MBIM interface.  I couldn't see any 
> example of
> that but any advice on the best approach would be appreciated.

A good example of how to do something like this is the Cinterion
plugin, where we supplement the QMI interface with AT commands to
manage GPS.

-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Flow control settings for RS232 modems

2017-03-28 Thread Carlo Lobrano

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 Aleksander Morgado 
wrote:

> On Mon, Mar 27, 2017 at 6:04 PM, carlo  wrote:
> >> Does this work?
> >>
> >> # cat < /lib/udev/rules.d/78-mm-serial.rules
> >> 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"
> >> EOF
> >> # udevadm control --reload
> >> # udevadm trigger
> >> // Relaunch MM
> >
> > unfortunately no, I got the same result
>
> Can you run "udevadm info -p /sys/class/tty/ttyS0" (i.e. without
> --atribute-walk)
>
> --
> Aleksander
> https://aleksander.es
>
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

[PATCH 2/4] plugins: remove explicit GDestroyNotify cast on g_free / g_object_unref

[PATCH 4/4] libmm-glib: remove explicit GDestroyNotify cast on g_object_unref

Re: Quectel UC20: Correct way to get it up and running on embedded?

[PATCH] base-bearer: fix typo in 'bearer-default-ip-family' property name

Re: Quectel UC20: Correct way to get it up and running on embedded?

Re: Quectel UC20: Correct way to get it up and running on embedded?

Re: [PATCH] telit: support QMI and MBIM modems

Re: Flow control settings for RS232 modems

Re: Flow control settings for RS232 modems

Re: Flow control settings for RS232 modems

Re: Flow control settings for RS232 modems

Re: [PATCH] telit: support QMI and MBIM modems

Re: Flow control settings for RS232 modems

13 matches

Site Navigation

Mail list logo

Footer information