Hi Denis,
This patch is fine, with one little fix below.
Patch message:
All QMI devices are currently piggy-backing on the 'gobi' driver to set
up the QMI atoms. For the SARA R4, this works with the addition of a quirk.
This patch adds the handling of a SARA R4 quirk to the 'gobi' driver.
The SARA R4 modem detaches permanently from the network when the NAS
Detach action is called. This is problematic because ofono calls Detach
when network connectivity is temporarily lost resulting in the modem
never attempting to reattach again when the network once again becomes
available.
Add vendor tag for uBlox SARA R4 modems.
This device is actually a Qualcomm part so it doesn't fall under the
uBlox category of devices, at all.
/Jonas
On 12/05/2021 09:40, Bing Jupiter wrote:
---
drivers/atmodem/vendor.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/atmodem
Hi Denis,
On 12/05/2021 09:40, Bing Jupiter wrote:
A comment along these lines might be appropriate:
Unlike other uBlox, the SARA R4 is actually a Qualcomm part and supports
the QMI protocol mostly as implemented in ofono. The AT command set for
this modem does not correspond to that used by
Hi Denis,
If we're going to get anywhere with this, the onus probably falls on you
to do some cleanup work on these patches. I'll write some comments on
the patches and maybe you can munge those into the commit messages...?
Bing Jupiter has been running this modem (uBlox SARA R4) for well ov
Hi,
On 24/02/2021 09:39, Bing Jupiter wrote:
---
drivers/qmimodem/gprs.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/qmimodem/gprs.c b/drivers/qmimodem/gprs.c
index 896a9e4c..90203dd3 100644
--- a/drivers/qmimodem/gprs.c
+++ b/drivers/qmimodem/gprs.c
@@ -26,6
Hi Jupiter,
Please add a description to your patch. Something along these lines:
This adds support for the uBlox SARA-R4 modem.
Unlike other uBlox devices, this modem is actually a Qualcomm part and
therefore supports the QMI protocol. For that reason, this doesn't just
jack into the usual
Hi,
On 27/11/2020 10:47, Jupiter wrote:
Hi Jonas,
Thanks for the response and kind helps.
and the modem continues to reset itself. Is this coincidental with
you removing the antenna... I can't tell?
My apology, a watchdog to monitor and to restart ofono when it lost
register was still runn
Hi,
On 20/11/2020 06:26, Jupiter wrote:
Hmm, strange, I tried to restart ofonod several times, the last one
was able to reconnect the 4G and network automatically after removing
the antenna to lose network, then adding the antenna, the only
difference was there were many messages popped out in t
Hi,
On 20/11/2020 00:39, Jupiter wrote:
Hi,
I am running ofono version 1.30 for uBlox SARA-R4 QMI on iMX6, it is
functional well, but there is one problem, it failed to be reconnected
when the 4G LTE signaling strength level is back to normal. Here is
what I tested:
- Connect antenna, it was r
Hi,
On 23/11/2020 06:45, Jupiter wrote:
How to commit code change, who should I contact for approving code change?
- prepare your patches in git on top of origin/master
- create a patch series
$ git format-patch --cover-letter origin/master -o patches
- edit the cover letter file, explaining
On 20/11/2019 10:39, JH wrote:
Sorry missing the subject, I further checked, it is not SIM issue,
then I am confused, does the 4G LTE is really using the old 2G GRPS?
Appreciate comments what is that error really means?
Thank you.
- jh
On 11/20/19, JH wrote:
Hi,
I have two 4G LTE device
Hi,
On 09/12/2019 07:50, JH wrote:
Hi,
I get 4G LTE RSSI from dbus connman service, I usually got about -61 I
thought it was accurate. But today, we are doing a test to check 4G LTE
RSSI based on different antennas, when connected to a antenna, the RSSI
is about -61, when I did not connect t
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 ever
On 25/09/2019 08:40, Richard Röjfors wrote:
Den tis 24 sep. 2019 kl 21:55 skrev Pavel Machek <mailto:pa...@ucw.cz>>:
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
The code for closing all the modem devices and flagging the modem as
unpowered is repeated several times in the driver... this patch puts
this code into a common helper for readability.
---
plugins/ublox.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff
Just reshuffling the code a bit and the 'disable' path can use the
close_devices() helper to finish up. This also prevents a bug should
the CFUN command fail to disable the modem whereby the 'aux' device
remains open but the 'modem' device has already been closed.
---
plugins/ublox.c | 12 +--
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
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.
What seems to work is
Hi Richard,
On 24/09/2019 18:11, 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
Hi Martin,
On 24/09/2019 21:20, Martin Hundebøll wrote:
Hi,
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
On 24/09/2019 18:32, Richard Röjfors wrote:
Hi Jonas,
Den tis 24 sep. 2019 kl 18:01 skrev Jonas Bonn <mailto:jo...@norrbonn.se>>:
uBlox devices present their USB interfaces well before those interfaces
are ready to respond to any commands. The documentation says to monito
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.
What seems to work is
On 24/09/2019 17:05, Denis Kenzior wrote:
Hi Jonas,
On 9/24/19 6:33 AM, 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
---
plugins/ublox.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index b65bc52a..9ee38a6b 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -102,13 +102,6 @@ static void ublox_remove(struct ofono_modem *modem)
g
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.
What seems to work is
---
plugins/quectel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/plugins/quectel.c b/plugins/quectel.c
index d4947489..1d21d6dd 100644
--- a/plugins/quectel.c
+++ b/plugins/quectel.c
@@ -1147,7 +1147,6 @@ static void quectel_set_online(struct ofono_modem *modem,
ofono_bool_t online,
stat
On Tue, Sep 3, 2019, 16:11 Richard Röjfors
wrote:
> Hi,
>
> An example log when this happened. In this case ofono thought context 4
> was still activated
> even though it was deactivated
>
Yes, I've seen this, too, and have a similar patch that I never got around
to sending. Please apply.
/Jona
Hi Richard,
On 20/08/2019 17:56, richard.rojf...@gmail.com wrote:
From: Richard Röjfors
This reverts commit 1fd419e5b4b3a87673f8e0219edb0f3ed9fca774.
This patch is fine and certainly necessary in the context of this
series. Posting it as a 'revert', however, is a bit unsavoury.
A reverte
Hi Michael,
Re-adding JH and mailing lists to conversation...
On 19/08/2019 10:00, Michael Nazzareno Trimarchi wrote:
Hi
On Mon, Aug 19, 2019 at 9:51 AM Jonas Bonn wrote:
On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
Can be chattering and rush current? Even are you sure that
On 19/08/2019 09:50, Jonas Bonn wrote:
On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
Hi
On Mon, Aug 19, 2019 at 7:38 AM Jonas Bonn wrote:
The kernel log has this:
Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1
On 19/08/2019 09:36, Michael Nazzareno Trimarchi wrote:
Hi
On Mon, Aug 19, 2019 at 7:38 AM Jonas Bonn wrote:
The kernel log has this:
Aug 17 08:51:46 solar kernel: usb 1-1: USB disconnect, device number 3
Aug 17 08:51:46 solar kernel: option1 ttyUSB0: GSM modem (1-port)
converter now
Hi JH,
On 19/08/2019 03:51, JH wrote:
Hi Michael,
On 8/18/19, Michael Nazzareno Trimarchi wrote:
Aug 17 11:32:44 solar kernel: usb 1-1: new high-speed USB device
number 5 using ci_hdrc
Aug 17 11:32:45 solar kernel: usb 1-1: New USB device found,
idVendor=05c6, idProduct=90b2, bcdDevice= 0.00
Hi JH,
On 17/08/2019 13:55, JH wrote:
On 8/17/19, JH wrote:
On 8/16/19, Daniel Wagner wrote:
The NTP code is just telling it can't reach the server. This has no
direct connenction to the next entry.
So that from NTP, don't need to worry about it.
This message is from the kernel via RTNL
Hi JH,
On 14/08/2019 13:11, JH wrote:
Hi Jonas,
On 8/14/19, Jonas Bonn wrote:
So you have no traffic over the LTE link? How do you know that it goes
down after 1-2 hours... maybe it went down after 5 minutes?
I logged link status every 10 minutes.
How? Not clear from what you posted
CC: ofono mailing list.
Please don't drop the mailing list from the conversation.
On 13/08/2019 13:51, JH wrote:
Hi Jonas,
On 8/13/19, Jonas Bonn wrote:
Hi JH,
Aug 01 08:09:39 connmand[181]: wwan0 {add} route 0.0.0.0 gw
10.114.23.146 scope 0
Aug 01 08:09:45 connmand[181]: Online
Hi JH,
On 13/08/2019 00:09, JH wrote:
Hi Jonas,
Do you have any comments about it?
Sure... there's not much to go on in the logs you've posted, just an
assertion that the LTE connection was silently dropped. It would be
better if you could show the behaviour with more complete debug output
---
drivers/ubloxmodem/ubloxmodem.c | 9 +
drivers/ubloxmodem/ubloxmodem.h | 3 ++-
plugins/udevng.c| 2 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 719c77a0..034f7db1 100644
--- a
For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient. This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementati
---
plugins/ublox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 231578fb..b65bc52a 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -406,7 +406,8 @@ static void ublox_post_online(struct ofono_modem *modem)
{
struct ubl
Some uBlox modems support multiple, simultaneously active contexts. These
contexts are either bridged to the network interface or handled
transparently by the modem acting like a router.
The problem with this approach is that ofono and ofono clients (e.g.
mmsd) expect a dedicated _local_ network
For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient. This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementati
---
plugins/ublox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index ff08a6a1..918bd3ec 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -399,7 +399,8 @@ static void ublox_post_online(struct ofono_modem *modem)
{
struct ubl
The TOBY L4 has no IPv6 support whatsoever.
---
drivers/ubloxmodem/gprs-context.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/ubloxmodem/gprs-context.c
b/drivers/ubloxmodem/gprs-context.c
index c5b789b6..ff78a42a 100644
--- a/drivers/ubloxmodem/gprs-context.c
+++ b/drivers
---
Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile.am b/Makefile.am
index 39777abc..7fb45d35 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -471,6 +471,7 @@ builtin_sources += drivers/atmodem/atutil.h \
drivers/ubloxmodem/ubloxmodem.h \
---
plugins/ublox.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 1da7101e..6e867666 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -41,6 +41,12 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+
Some u-blox devices present a USB network class device for data and some
just switch to PPP on (one of) the communication channel(s). Whether
the atmodem or ubloxmodem gprs-context driver should be used depends on
whether or not the network interface is present; check this condition
directly when
---
plugins/ublox.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 6e867666..b65bc52a 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -388,6 +389,8 @
An upcoming netreg driver for uBlox modems will need to override the
probe method in order to set itself up, but for further functionality
the "generic" AT implementations are sufficient. The easiest way to do
this is to just set up a vtable with a custom probe implementation and
defer all other m
In order to do inheritance by composition.
---
drivers/atmodem/network-registration.c | 94 +++---
drivers/atmodem/network-registration.h | 14
2 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/atmodem/network-registration.c
b/drivers/atmodem/networ
Hi Krishna,
First of all, don't top-post to this mailing list.
On 21/06/2019 11:28, Krishna wrote:
Hi Jonas,
Thanks for the patch.
Withyour patch, ofono is ableto recognize LARA modems.
Setting modem /ublox_0 online...
root@imx:/usr/lib/ofono/test# ./activate-context
*Error activating
On 02/05/2019 17:03, JH wrote:
Hi,
The official ofono recipe ofono.inc defines SYSTEMD_SERVICE_${PN} =
"ofono.service", but the ofonod is not started by system service
automatically, I have to start the ofonod manually, what could be the
issue?
This question should be directed to the OpenEm
Hi Denis,
On 22/04/2019 17:52, Denis Kenzior wrote:
What is actually different for uBlox that requires such a drastic
approach? Right now I'm seeing a duplication of CMER/CIEV and NITZ
logic. Not much else.
For the TOBY L4 I hit this:
ofono_error("This driver is not setup with Signal Stren
An upcoming netreg driver for uBlox modems will need to override the
probe method in order to set itself up, but for further functionality
the "generic" AT implementations are sufficient. The easiest way to do
this is to just set up a vtable with a custom probe implementation and
defer all other m
C... patches are not quite done. That said, feel free
to patch review if you've got a moment; the final result shouldn't
differ all that much from what's here.
Jonas Bonn (2):
atmodem: export generic netreg funcs
ublox: network-registration atom
drivers/atmodem/network-registra
For uBlox modems, a bit of custom setup is required, but after that the
generic "atmodem" (27.007-compatible) method implementations are
sufficient. This driver, therefore, just puts the custom probe method
into place and defers remaining functionality to the recently exported
atmodem implementati
---
Hi Krishna,
This patch isn't tested, but this is roughly what you'd need to get the
LARA R2 detected and running. After that, it's just a matter of going
through the details of where ofono has issues.
>From what I can see at a quick glance at the documentation, there's
nothing that particul
Hi Krishna,
On 11/04/2019 13:47, Krishna wrote:
Hi All,
Whether anyone tried ofono framework with u-blox LARA-R211 or LARA-202?
ofono currently does not support these modems, but looking quickly at
the documentation I don't see any difficulty at all in getting this to
work. You just need t
Hi Richard,
On 31/03/2019 23:19, richard.rojf...@gmail.com wrote:
From: Richard Röjfors
In a recent patch vendor family was only set if the device
did not support USBCONF, but that resulted in drivers
being registered the "generic" vendor. That caused
for instance netreg to use incorrect cmer
Hi Denis,
On 15/03/2019 17:28, Denis Kenzior wrote:
uBlox is just being too smart here. The whole bridged vs router stuff
was never intended by 27.007. They made this all up themselves. Neither
oFono nor ConnMan were designed to handle such a setup.
The main issue will be for contexts
Hi Denis,
On 15/03/2019 02:27, Denis Kenzior wrote:
Hi Jonas,
On 03/14/2019 05:37 PM, Jonas Bonn wrote:
---
Funny, I was looking at this code today and thought it was wrong. Was
going to point this out to you, but you beat me to it ;)
Here's something that I'm havi
---
Here's something that I'm having trouble understanding. The ublox
plugin creates 8 gprs_context atoms. As far as I can tell, this means
that ofono will allow it to activate 8 contexts simultaneously... right?
Why is the ublox plugin the only one that does this? Do other modems
not support
The TOBY L2 may run in either "bridge" mode or "router" mode. For this
model, query the configured mode so that the appropriate settings are
communicated when the context is activated.
---
Only compile tested... I don't actually have a TOBY L2.
/Jonas
drivers/ubloxmodem/gprs-context.c | 54 +++
Depending on the transport used on the data connection we want either
the "atmodem" (PPP) driver or the "ubloxmodem". For the "ubloxmodem",
we want to pass the model data so this patch wrangles some parameters to
make sure that right driver and right variant data are passed.
---
plugins/ublox.c |
---
drivers/ubloxmodem/gprs-context.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/ubloxmodem/gprs-context.c
b/drivers/ubloxmodem/gprs-context.c
index 1b4e17f5..bbf8627a 100644
--- a/drivers/ubloxmodem/gprs-context.c
+++ b/drivers/ubloxmodem/gprs-context.c
@@
The TOBY L4 supports only "router mode" where the modem presents a
network interface that one can run a DHCP client against. Behind this
interface, the modem takes care of routing packets via NAT by:
i) selecting the relevant context based on destination IP
ii) using the first activated context
Trying to set the networking mode to "bridge" mode in the plugin is bogus
because the setting does not apply until after the device has been
reset. Instead, the current setting should be queried.
If a user wants to set the modem networking mode, the setting should be
made outside of ofono.
The g
ttyACM0 (USB interface 02) is reportedly unreliable (breaking DHCP setup)
so the recommended approach is to use ttyACM2 (USB interface 06)
exclusively.
---
plugins/udevng.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index
There are a couple of semi-independent changes here:
* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
driv
---
plugins/ublox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 10660ff0..1c74fe09 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -408,7 +408,8 @@ static void ublox_post_sim(struct ofono_modem *modem)
--nconte
---
drivers/ubloxmodem/ubloxmodem.c | 23 +++
drivers/ubloxmodem/ubloxmodem.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 0630fcdf..9e0781f0 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/d
Some aspects of a device are detectable at runtime, like the USB profile
detection that was added in a patch preceding this one. This patch
switches the driver over from creating a new "vendor id" for each
profile to just setting a flag. This is more easily extensible as we
detect other features
The TOBY L4 doesn't seem to like seeing these two commands on the same
line...
---
plugins/ublox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index d99f5c45..10660ff0 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -282,7 +282,9 @
There are a couple of semi-independent changes here:
* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
driv
The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics. These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even more like
selecting a different "device" alt
On 13/03/2019 21:23, Jonas Bonn wrote:
There are a couple of semi-independent changes here:
* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication
On 13/03/2019 21:23, Jonas Bonn wrote:
The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics. These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even
---
plugins/ublox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index ad1b6ec7..7cb12f7f 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -409,7 +409,8 @@ static void ublox_post_sim(struct ofono_modem *modem)
--nconte
The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics. These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even more like
selecting a different "device" alt
---
plugins/udevng.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index ce8cdee1..4473c0a6 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -,7 +,6 @@ static gboolean setup_ublox(struct modem_info *modem)
ofono_modem_set_string(mod
The TOBY L4 doesn't seem to like seeing these two commands on the same
line...
---
plugins/ublox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 994761f8..ad1b6ec7 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -283,7 +283,9 @
---
drivers/ubloxmodem/ubloxmodem.c | 23 +++
drivers/ubloxmodem/ubloxmodem.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 0630fcdf..9e0781f0 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/d
nks,
Jonas
On 13/03/2019 19:37, Denis Kenzior wrote:
Hi Jonas,
On 03/12/2019 06:09 AM, Jonas Bonn wrote:
This patch adds a call to CGMM into the modem_enable path in order to
establish the specific device model. From this device model string, a
model-specific capabilities structure can be sel
Some aspects of a device are detectable at runtime, like the USB profile
detection that was added in a patch preceding this one. This patch
switches the driver over from creating a new "vendor id" for each
profile to just setting a flag. This is more easily extensible as we
detect other features
ttyACM0 (USB interface 02) is reportedly unreliable (breaking DHCP setup)
so the recommended approach is to use ttyACM2 (USB interface 06)
exclusively.
---
plugins/udevng.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index
There are a couple of semi-independent changes here:
* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
driv
This patch adds a call to CGMM into the modem_enable path in order to
establish the specific device model. From this device model string, a
model-specific capabilities structure can be selected.
---
plugins/ublox.c | 107 ++--
1 file changed, 77 inserti
This flag should be set on devices that support multiple USB profiles
and will be used to determine whether or not querying USB profiles is
appropriate/necessary.
---
drivers/ubloxmodem/ubloxmodem.c | 10 +-
drivers/ubloxmodem/ubloxmodem.h | 1 +
2 files changed, 6 insertions(+), 5 deleti
Hi,
Could I get a clarification on the behaviour you see here?
As I understand it, the SARA-R4 doesn't support the CGDATA command.
That's fine as ofono will detect this and set use_atd99 in order to
force the use of the ATD command as a fallback.
Why do you need to force this setting in the
---
plugins/ublox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 7a93adb2..bec0bf83 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -407,7 +407,8 @@ static void ublox_post_sim(struct ofono_modem *modem)
--nconte
The TOBY L4 doesn't seem to like seeing these two commands on the same
line...
---
plugins/ublox.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/plugins/ublox.c b/plugins/ublox.c
index 038b55d5..7a93adb2 100644
--- a/plugins/ublox.c
+++ b/plugins/ublox.c
@@ -281,7 +281,9 @
The TOBY L2 series of modems presents a number of different
configurations with different throughtput characteristics. These
configurations are packaged up as USB profiles; moreover, changing the
profile actually changes the USB model ID so this is even more like
selecting a different "device" alt
---
drivers/ubloxmodem/ubloxmodem.c | 23 +++
drivers/ubloxmodem/ubloxmodem.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/ubloxmodem/ubloxmodem.c b/drivers/ubloxmodem/ubloxmodem.c
index 3998f55e..49a824ed 100644
--- a/drivers/ubloxmodem/ubloxmodem.c
+++ b/d
There are a couple of semi-independent changes here:
* use the 'vendor' parameter to pass the modem 'model'
* support TOBY L4 modem which uses a fixed CID for configuring the EPS
default bearer
* add the setup of authentication parameters that was recently added to
the atmodem LTE driver
---
driv
ttyACM0 (USB interface 02) is reportedly unreliable (breaking DHCP setup)
so the recommended approach is to use ttyACM2 (USB interface 06)
exclusively.
---
plugins/udevng.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index
---
drivers/atmodem/network-registration.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/atmodem/network-registration.c
b/drivers/atmodem/network-registration.c
index 2482dfc3..1704f98c 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/at
This patch adds a call to CGMM into the modem_enable path in order to
establish the specific device model. From this device model string, a
model-specific capabilities structure can be selected.
---
plugins/ublox.c | 107 ++--
1 file changed, 77 inserti
Some aspects of a device are detectable at runtime, like the USB profile
detection that was added in a patch preceding this one. This patch
switches the driver over from creating a new "vendor id" for each
profile to just setting a flag. This is more easily extensible as we
detect other features
The 'Toby L2'-specific vendor type is used only to prevent the CMER
command from attempting to set mode '3'. For all u-blox models, mode
'3' is just an alias for mode '1'. As such, mode '1' can be used in
place of mode '3', removing the model-specific quirk in favour of a
vendor-specific quirk.
This sets up some device model data structures and adds some helpers for
manipulating them. These data structures are a first step to trying to
support the large number of devices that ublox produces with a common
driver structure.
---
drivers/ubloxmodem/ubloxmodem.c | 55
1 - 100 of 462 matches
Mail list logo