date:20190925

Re: [PATCH v3 0/3] ublox device initialisation

2019-09-25 Thread Denis Kenzior


Hi Jonas,

On 9/24/19 11:35 PM, Jonas Bonn wrote:

Changed in v3:
- consolidate device closing into a common helper
- remove timeout in disable function

Jonas Bonn (3):
   ublox: consolidate teardown in common function
   ublox: use common close_devices when modem disabled
   ublox: rework device initialization sequence

  plugins/ublox.c | 155 
  1 file changed, 118 insertions(+), 37 deletions(-)



All applied, thanks.

Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH] udev: Adding PCIe as a subsystem in udev

2019-09-25 Thread Denis Kenzior


Hi Antara,

On 9/25/19 4:55 AM, Antara Borwankar wrote:

Adding support for enumerating PCIe types of modems in ofono
---
  plugins/udevng.c | 195 +--
  1 file changed, 174 insertions(+), 21 deletions(-)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 1b54b4a..bebbc2d 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -41,6 +41,7 @@
  enum modem_type {
MODEM_TYPE_USB,
MODEM_TYPE_SERIAL,
+   MODEM_TYPE_PCIE,
  };
  
  struct modem_info {

@@ -1229,26 +1230,43 @@ static gboolean setup_xmm7xxx(struct modem_info *modem)
info->interface, info->number, info->label,
info->sysattr, info->subsystem);
  
-		if (g_strcmp0(modem->model,"095a") == 0) {

-   if (g_strcmp0(info->subsystem, "tty") == 0) {
-   if (g_strcmp0(info->number, "00") == 0)
-   mdm = info->devnode;
-   } else if (g_strcmp0(info->subsystem, "net") == 0) {
-   if (g_strcmp0(info->number, "06") == 0)
-   net = info->devnode;
-   if (g_strcmp0(info->number, "08") == 0)
-   net2 = info->devnode;
-   if (g_strcmp0(info->number, "0a") == 0)
-   net3 = info->devnode;
+   if (g_strcmp0(info->subsystem, "pci") == 0) {
+   if ((g_strcmp0(modem->vendor,"0x8086") == 0) &&
+   (g_strcmp0(modem->model,"0x7560") == 
0)) {
+   mdm = "/dev/iat";
+   net = "inm0";
+   net2 = "inm1";
+   net3 = "inm2";
+   ofono_modem_set_string(modem->modem,
+   "CtrlPath", 
"/PCIE/IOSM/CTRL/1");
+   ofono_modem_set_string(modem->modem, "DataPath",
+   "/PCIE/IOSM/IPS/");
}
-   } else {
-   if (g_strcmp0(info->subsystem, "tty") == 0) {
-   if (g_strcmp0(info->number, "02") == 0)
-   mdm = info->devnode;
-   } else if (g_strcmp0(info->subsystem, "net") == 0) {
-   if (g_strcmp0(info->number, "00") == 0)
-   net = info->devnode;
+   } else { /* For USB */
+   if (g_strcmp0(modem->model,"095a") == 0) {
+   if (g_strcmp0(info->subsystem, "tty") == 0) {
+   if (g_strcmp0(info->number, "00") == 0)
+   mdm = info->devnode;
+   } else if (g_strcmp0(info->subsystem, "net") == 
0) {
+   if (g_strcmp0(info->number, "06") == 0)
+   net = info->devnode;
+   if (g_strcmp0(info->number, "08") == 0)
+   net2 = info->devnode;
+   if (g_strcmp0(info->number, "0a") == 0)
+   net3 = info->devnode;
+   }
+   } else {
+   if (g_strcmp0(info->subsystem, "tty") == 0) {
+   if (g_strcmp0(info->number, "02") == 0)
+   mdm = info->devnode;
+   } else if (g_strcmp0(info->subsystem, "net") == 
0) {
+   if (g_strcmp0(info->number, "00") == 0)
+   net = info->devnode;
+   }
}
+
+   ofono_modem_set_string(modem->modem, "CtrlPath", 
"/USBCDC/0");
+   ofono_modem_set_string(modem->modem, "DataPath", 
"/USBHS/NCM/");


Lines > 80 characters, please see doc/coding-style.txt


}
}
  
@@ -1266,9 +1284,6 @@ static gboolean setup_xmm7xxx(struct modem_info *modem)

if (net3)
ofono_modem_set_string(modem->modem, "NetworkInterface3", net3);
  
-	ofono_modem_set_string(modem->modem, "CtrlPath", "/USBCDC/0");

-   ofono_modem_set_string(modem->modem, "DataPath", "/USBHS/NCM/");
-
return TRUE;
  }
  
@@ -1437,6 +1452,7 @@ static void destroy_modem(gpointer data)
  
  	switch (modem->type) {

case MODEM_TYPE_USB:
+   case MODEM_TYPE_PCIE:
for (list = modem->devices; list; list = list->next) {
struct device_info

Re: [PATCH] ublox: network-registration: Check ureg for tech also for L2 modems

2019-09-25 Thread Denis Kenzior


Hi Richard,

On 9/24/19 11:11 AM, richard.rojf...@gmail.com wrote:

From: Richard Röjfors 

It seems like the CREG reporting from the L2 modems are quite
buggy. An example for a L210 where CREG reports UTRAN while
COPS and UREG reports LTE. A manual poll also indicates LTE.

I also found that the technology mapping was incorrect,
probably confused with enum packet_bearer.

A commented log showing where CREG is not trustable:

UREG indicates LTE
21:59:29 : < \r\n+UREG: 7\r\n
21:59:29 : < \r\n+CIEV: 9,2\r\n
21:59:29 : < \r\n+CGEV: NW MODIFY 1,0,0\r\n
21:59:31 : < \r\n+CIEV: 2,2\r\n
21:59:39 : < \r\n+CIEV: 2,3\r\n
21:59:44 : < \r\n+CIEV: 2,2\r\n
22:01:38 : < \r\n+CIEV: 2,3\r\n
22:01:43 : < \r\n+CIEV: 2,2\r\n

A CREG indicating UTRAN with HSDPA and HSUPA
22:29:39 : < \r\n+CREG: 5,"","",6\r\n
22:29:39 : > AT\r
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS=3,2\r
22:29:39 : < \r\n+CIEV: 9,2\r\n
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS?\r

An immediate cops indicating LTE
22:29:39 : < \r\n+COPS: 0,2,"24007",7\r\n
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+CSQ\r
22:29:39 : < \r\n+CIEV: 2,4\r\n
22:29:39 : < \r\n+CSQ: 26,4\r\n
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+CGATT=1\r
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS=3,0\r
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+COPS?\r

Another cops also indicates LTE
22:29:39 : < \r\n+COPS: 0,0,"Tele2",7\r\n <- 7: LTE
22:29:39 : < \r\nOK\r\n
22:29:39 : > AT+CGREG?\r

CGREG indicates unknown -> normal on LTE
22:29:39 : < \r\n+CGREG: 2,4\r\n
22:29:39 : < \r\nOK\r\n
22:29:44 : < \r\n+CIEV: 9,2\r\n
22:29:46 : < \r\n+CIEV: 2,2\r\n
22:56:23 : < \r\n+CIEV: 2,3\r\n
22:56:28 : < \r\n+CIEV: 2,2\r\n
22:59:40 : < \r\n+CIEV: 2,4\r\n

Manual poll shows we are running LTE
at+creg?
+CREG: 2,5,"2AFC","01DB0206",7

OK
---
  drivers/ubloxmodem/network-registration.c | 34 +++
  1 file changed, 28 insertions(+), 6 deletions(-)



Applied, thanks.

Regards,
-Denis

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

[PATCH] udev: Adding PCIe as a subsystem in udev

2019-09-25 Thread Antara Borwankar

Adding support for enumerating PCIe types of modems in ofono
---
 plugins/udevng.c | 195 +--
 1 file changed, 174 insertions(+), 21 deletions(-)

diff --git a/plugins/udevng.c b/plugins/udevng.c
index 1b54b4a..bebbc2d 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -41,6 +41,7 @@
 enum modem_type {
MODEM_TYPE_USB,
MODEM_TYPE_SERIAL,
+   MODEM_TYPE_PCIE,
 };
 
 struct modem_info {
@@ -1229,26 +1230,43 @@ static gboolean setup_xmm7xxx(struct modem_info *modem)
info->interface, info->number, info->label,
info->sysattr, info->subsystem);
 
-   if (g_strcmp0(modem->model,"095a") == 0) {
-   if (g_strcmp0(info->subsystem, "tty") == 0) {
-   if (g_strcmp0(info->number, "00") == 0)
-   mdm = info->devnode;
-   } else if (g_strcmp0(info->subsystem, "net") == 0) {
-   if (g_strcmp0(info->number, "06") == 0)
-   net = info->devnode;
-   if (g_strcmp0(info->number, "08") == 0)
-   net2 = info->devnode;
-   if (g_strcmp0(info->number, "0a") == 0)
-   net3 = info->devnode;
+   if (g_strcmp0(info->subsystem, "pci") == 0) {
+   if ((g_strcmp0(modem->vendor,"0x8086") == 0) &&
+   (g_strcmp0(modem->model,"0x7560") == 
0)) {
+   mdm = "/dev/iat";
+   net = "inm0";
+   net2 = "inm1";
+   net3 = "inm2";
+   ofono_modem_set_string(modem->modem,
+   "CtrlPath", 
"/PCIE/IOSM/CTRL/1");
+   ofono_modem_set_string(modem->modem, "DataPath",
+   "/PCIE/IOSM/IPS/");
}
-   } else {
-   if (g_strcmp0(info->subsystem, "tty") == 0) {
-   if (g_strcmp0(info->number, "02") == 0)
-   mdm = info->devnode;
-   } else if (g_strcmp0(info->subsystem, "net") == 0) {
-   if (g_strcmp0(info->number, "00") == 0)
-   net = info->devnode;
+   } else { /* For USB */
+   if (g_strcmp0(modem->model,"095a") == 0) {
+   if (g_strcmp0(info->subsystem, "tty") == 0) {
+   if (g_strcmp0(info->number, "00") == 0)
+   mdm = info->devnode;
+   } else if (g_strcmp0(info->subsystem, "net") == 
0) {
+   if (g_strcmp0(info->number, "06") == 0)
+   net = info->devnode;
+   if (g_strcmp0(info->number, "08") == 0)
+   net2 = info->devnode;
+   if (g_strcmp0(info->number, "0a") == 0)
+   net3 = info->devnode;
+   }
+   } else {
+   if (g_strcmp0(info->subsystem, "tty") == 0) {
+   if (g_strcmp0(info->number, "02") == 0)
+   mdm = info->devnode;
+   } else if (g_strcmp0(info->subsystem, "net") == 
0) {
+   if (g_strcmp0(info->number, "00") == 0)
+   net = info->devnode;
+   }
}
+
+   ofono_modem_set_string(modem->modem, "CtrlPath", 
"/USBCDC/0");
+   ofono_modem_set_string(modem->modem, "DataPath", 
"/USBHS/NCM/");
}
}
 
@@ -1266,9 +1284,6 @@ static gboolean setup_xmm7xxx(struct modem_info *modem)
if (net3)
ofono_modem_set_string(modem->modem, "NetworkInterface3", net3);
 
-   ofono_modem_set_string(modem->modem, "CtrlPath", "/USBCDC/0");
-   ofono_modem_set_string(modem->modem, "DataPath", "/USBHS/NCM/");
-
return TRUE;
 }
 
@@ -1437,6 +1452,7 @@ static void destroy_modem(gpointer data)
 
switch (modem->type) {
case MODEM_TYPE_USB:
+   case MODEM_TYPE_PCIE:
for (list = modem->devices; list; list = list->next) {
struct device_info *info = list->data;
 
@@ -1467,6 +1483,7 @@ static gboolean check_remove(gpointer key, gpointer 
value, gpointer

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

2019-09-25 Thread Jonas Bonn

Hi Martin,

On 25/09/2019 09:27, Martin Hundebøll wrote:

Hi Jonas,

On 9/25/19 5:44 AM, Jonas Bonn wrote:

On 24/09/2019 21:20, Martin Hundebøll wrote:

On 24/09/2019 20.09, Martin Hundebøll wrote:

On 24/09/2019 19.23, Denis Kenzior wrote:
Furthermore, there's not an AT command sent every 500 ms.  The 
command gets requeued after 500ms, but it doesn't actually go out 
until the modem responds to the first one... not quite sure why 
this works, to be honest.

Funny.  But not real confidence inspiring :)

Martin, any ideas what could be going wrong here?

The code looks quite familiar :)

For good reason! :)

Jonas, do you have a log with OFONO_AT_DEBUG=1 set?

ofonod[31545]: Aux: > AT\r
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: plugins/ublox.c:init_cmd_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: Aux: < \r\n+AT: READY\r\n
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > ATE0\r
ofonod[31545]: Aux: < ATE0
ofonod[31545]: Aux: < \r\r\nOK\r\n

For the record, here one from my setup:

UART: > AT\r
UART: < \371\013s\001\222\371
../git/plugins/quectel.c:init_timeout_cb() 0x61000d40
UART: > AT\r
UART: < \r\nOK\r\n
../git/plugins/quectel.c:init_cmd_cb() 0x61000d40
../git/src/modem.c:get_modem_property() modem 0x61000d40 property 
RtsCts

UART: > ATE0\r
UART: < \r\nOK\r\n

So yours looks a bit different... you really do lose the first AT 
command into a black hole.  The uBlox modem seems to not lose anything 
sent over the USB bus but rather buffers it up and responds later.  
That said, according to the documentation it _could_ lose the AT 
command so one cannot rely on the response just turning up eventually.

Could it be safe to assume that it will lose only a single AT command? 
In that case, it should be enough to send just two AT's. Once the first 
OK is received, you could wait 500 ms for the second OK, or retry the 
second AT in case of a timeout?

No lost AT:
  > AT   // Send first
  > AT   // Send second and wait
  < OK   // Wait 500 ms
  < OK   // Start initialization

One lost AT
  > AT   // Send first
  > AT   // Send second and wait
  < OK   // Wait 500 ms
  > AT   // Retry second
  < OK   // Start initialization

That's pretty much what we've got, isn't it?

The thing that wasn't clear to me, though, was why every invocation of 
init_timeout_cb doesn't result in a new AT command being sent?  It's 
like the command is set to be retried in the first invocation, but it 
never gets sent so the subsequent retries amount to no-ops.  This 
behaviour is agreeable in this case, but I don't quite understand why 
it works this way...

Can the usb-to-serial driver block further writes until the modem is ready?

Not the driver but the modem.  If the USB bulk endpoint on the modem 
side decides it is busy (for example, because it's buffers are full), it 
can NAK subsequent packets until it's ready to receive again.  It's not 
out of the question that Linux is smart enough to return EAGAIN for a 
write in that case... but I would suspect that the OS would normally 
buffer the write() for more than one AT command before this happened. 
For that reason, I can't see why ofono would be able to detect this... 
from ofono's point of view it should just look like there's a series of 
AT commands going out and no responses coming back.  There must be some 
magic in g_io_...???

/Jonas

// Martin

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

2019-09-25 Thread Martin Hundebøll

Hi Jonas,

On 9/25/19 5:44 AM, Jonas Bonn wrote:

On 24/09/2019 21:20, Martin Hundebøll wrote:

On 24/09/2019 20.09, Martin Hundebøll wrote:

On 24/09/2019 19.23, Denis Kenzior wrote:
Furthermore, there's not an AT command sent every 500 ms.  The 
command gets requeued after 500ms, but it doesn't actually go out 
until the modem responds to the first one... not quite sure why 
this works, to be honest.

Funny.  But not real confidence inspiring :)

Martin, any ideas what could be going wrong here?

The code looks quite familiar :)

For good reason! :)

Jonas, do you have a log with OFONO_AT_DEBUG=1 set?

ofonod[31545]: Aux: > AT\r
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < AT\r
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: plugins/ublox.c:init_cmd_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: < \r\nOK\r\n
ofonod[31545]: Aux: < \r\n+AT: READY\r\n
ofonod[31545]: plugins/ublox.c:init_timeout_cb() 0x563f7c2cebc0
ofonod[31545]: Aux: > ATE0\r
ofonod[31545]: Aux: < ATE0
ofonod[31545]: Aux: < \r\r\nOK\r\n

For the record, here one from my setup:

UART: > AT\r
UART: < \371\013s\001\222\371
../git/plugins/quectel.c:init_timeout_cb() 0x61000d40
UART: > AT\r
UART: < \r\nOK\r\n
../git/plugins/quectel.c:init_cmd_cb() 0x61000d40
../git/src/modem.c:get_modem_property() modem 0x61000d40 property 
RtsCts

UART: > ATE0\r
UART: < \r\nOK\r\n

So yours looks a bit different... you really do lose the first AT 
command into a black hole.  The uBlox modem seems to not lose anything 
sent over the USB bus but rather buffers it up and responds later.  That 
said, according to the documentation it _could_ lose the AT command so 
one cannot rely on the response just turning up eventually.

Could it be safe to assume that it will lose only a single AT command? 
In that case, it should be enough to send just two AT's. Once the first 
OK is received, you could wait 500 ms for the second OK, or retry the 
second AT in case of a timeout?

No lost AT:
 > AT   // Send first
 > AT   // Send second and wait
 < OK   // Wait 500 ms
 < OK   // Start initialization

One lost AT
 > AT   // Send first
 > AT   // Send second and wait
 < OK   // Wait 500 ms
 > AT   // Retry second
 < OK   // Start initialization

The thing that wasn't clear to me, though, was why every invocation of 
init_timeout_cb doesn't result in a new AT command being sent?  It's 
like the command is set to be retried in the first invocation, but it 
never gets sent so the subsequent retries amount to no-ops.  This 
behaviour is agreeable in this case, but I don't quite understand why it 
works this way...

Can the usb-to-serial driver block further writes until the modem is ready?

// Martin
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

2019-09-25 Thread Jonas Bonn

On 25/09/2019 08:40, Richard Röjfors wrote:
Den tis 24 sep. 2019 kl 21:55 skrev Pavel Machek >:

On Tue 2019-09-24 18:01:26, Jonas Bonn wrote:
 > uBlox devices present their USB interfaces well before those
interfaces
 > are ready to respond to any commands.  The documentation says to
monitor
 > the 'greeting text' to detect readiness, but this 'greeting text'
is not
 > actually specified for any device other than the TOBY L4.

Collecting "greeting texts" from all the modems we want to support
should not be hard, right?

...given that one has access to all the devices!

Honestly, I suspect the documentation is garbage.  There are no greeting 
texts for devices other than the L4; probing is just a matter of waiting 
for AT to respond to with OK.

I don't think that's a good idea. What if ofono is restated and the 
modem is still running?

In this case, the TOBY-L4 does not provide a greeting text.

/Jonas

--Richard

___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH] ublox: network-registration: Check ureg for tech also for L2 modems

2019-09-25 Thread Richard Röjfors

Hi Jonas

Den ons 25 sep. 2019 kl 06:05 skrev Jonas Bonn :

>
> For the TOBY-L4, RAT changes won't trigger a CREG URC... for whatever
> reason, this command is so brittle that they needed to bypass it with a
> UREG command.  For the L2, they don't bother to document this, but it
> appears to suffer from the same deficiencies as the L4.  CGREG and
> friends appear to suffer from the same ailment... they don't have a firm
> grasp of the overall state so they return "unknown" as a fallback.
>

For CGREG unknown seems to be used when the modem is running LTE,
at least for L2, which kind of make sense I guess. Since cereg is what to be
used at that time.

But I also have a bad feeling about CREG and L2, most often CREG URC's are
sent,
but not always. And sometimes like here the CREG URC has the wrong tech.

I'm starting to think if we should also subscribe to UREG in netreg for
ublox,
but thats another commit ;-)

--Richard
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

2019-09-25 Thread Richard Röjfors

Den tis 24 sep. 2019 kl 21:55 skrev Pavel Machek :

> On Tue 2019-09-24 18:01:26, Jonas Bonn wrote:
> > uBlox devices present their USB interfaces well before those interfaces
> > are ready to respond to any commands.  The documentation says to monitor
> > the 'greeting text' to detect readiness, but this 'greeting text' is not
> > actually specified for any device other than the TOBY L4.
>
> Collecting "greeting texts" from all the modems we want to support
> should not be hard, right?
>

I don't think that's a good idea. What if ofono is restated and the modem
is still running?

--Richard
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Re: [PATCH v3 0/3] ublox device initialisation

Re: [PATCH] udev: Adding PCIe as a subsystem in udev

Re: [PATCH] ublox: network-registration: Check ureg for tech also for L2 modems

[PATCH] udev: Adding PCIe as a subsystem in udev

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

Re: [PATCH] ublox: network-registration: Check ureg for tech also for L2 modems

Re: [PATCH v2 1/1] ublox: rework device initialization sequence

9 matches

Site Navigation

Mail list logo

Footer information