Hi Alexander,
yes you understood correctly and I agree with the suggestion. I'll work on
it.
Thanks
On 6 July 2017 at 18:44, Aleksander Morgado
wrote:
> On Thu, Jul 6, 2017 at 5:10 PM, Carlo Lobrano wrote:
> > looking at sim hot swap code, I noticed that even if sim swap
> configuration
> > f
When returning an enum value via g_task_return_int, some code assumes
the enum value is always non-negative and thus considers that a negative
value implies an error. This assumption could be invalidated if a
negative value is later added to the enum. To make it less error prone
to future changes,
On Thu, 2017-07-06 at 12:35 -0700, Ben Chan wrote:
> When returning an enum value via g_task_return_int, some code assumes
> the enum value is always non-negative and thus considers that a
> negative
> value implies an error. This assumption could be invalidated if a
> negative value is later added
When returning an enum value via g_task_return_int, some code assumes
the enum value is always non-negative and thus considers that a negative
value implies an error. This assumption could be invalidated if a
negative value is later added to the enum. To make it less error prone
to future changes,
When returning an enum value via g_task_return_int, some code assumes
the enum value is always non-negative and thus considers that a negative
value implies an error. This assumption could be invalidated if a
negative value is later added to the enum. To make it less error prone
to future changes,
When returning an enum value via g_task_return_int, some code assumes
the enum value is always non-negative and thus considers that a negative
value implies an error. This assumption could be invalidated if a
negative value is later added to the enum. To make it less error prone
to future changes,
mm_plugin_supports_port_finish directly casts the value returned by
g_task_propagate_int to MMPluginSupportsResult enum value, which
implicitly assumes MM_PLUGIN_SUPPORTS_PORT_UNKNOWN equals to -1.
Instead of relying on such an implicit assumption, this patch modifies
the code to check if the GErro
On Thu, 2017-07-06 at 15:57 +0200, Tore Anderson wrote:
> * Bjørn Mork
>
> > Having access to the full power of QMI is an advantage if you want
> > to do
> > "advanced" stuff like cell monitoring etc. But if you can run QMI
> > over
> > MBIM, and then there is absolutely no reason to use the more
On Thu, Jul 6, 2017 at 5:10 PM, Carlo Lobrano wrote:
> looking at sim hot swap code, I noticed that even if sim swap configuration
> fails at some point (in core or in the modem), we still print the message
> "SIM is missing, but the modem supports SIM hot swap. Waiting for SIM...",
> which is kin
* Bjørn Mork
> Having access to the full power of QMI is an advantage if you want to do
> "advanced" stuff like cell monitoring etc. But if you can run QMI over
> MBIM, and then there is absolutely no reason to use the more cumbersome
> configuration. MBIM is also the safer choice based on what m
Hey,
looking at sim hot swap code, I noticed that even if sim swap configuration
fails at some point (in core or in the modem), we still print the message
"SIM is missing, but the modem supports SIM hot swap. Waiting for
SIM...", which is kind of misleading in that case.
I'm working on a patch an
* Bjørn Mork
> Tore Anderson writes:
>
>> The good news is that HP support agreed to replace my lt4132 with a
>> lt4120, which is a Foxconn device that I hope works better.
>
> I'm impressed! Wonder if they have a suitable checkbox in their
> customer satisfaction form or whatever?
>
> "Reaso
My unit is actually LT4120, but the same udev sentences went well here as
well.
root@SBC01:~# mbimcli -p -d /dev/cdc-wdm0 --query-device-caps
[/dev/cdc-wdm0] Device capabilities retrieved:
Device type: 'remote'
Cellular class: 'gsm'
Voice class: 'no-voice'
Sim class: 'removable'
On Thu, Jul 6, 2017 at 10:55 AM, Bjørn Mork wrote:
>> After switching it to configuration #3 (MBIM) everything Just Worked
>> without any further tinkering. I see the blog post author went for
>> configuration #1 instead, and that looks more cumbersome pull off.
>> Maybe it has any distinct advant
On Thu, Jul 6, 2017 at 7:26 AM, Tore Anderson wrote:
>> The LT4120 might have it's own challenges. The website you are
>> referring to does add udev rule to set the configuration of the
>> modem, as it seems to be in win8 mode as original, and that the Linux
>> system does not seem to cope with ve
On 06/07/17 00:12, Ben Chan wrote:
> ---
> src/mm-base-call.c | 27 ++-
> 1 file changed, 6 insertions(+), 21 deletions(-)
>
Pushed to git master, thanks.
Also please note that I pushed a follow up commit removing the unneeded
g_task_set_task_data() call.
> diff --git a
On 06/07/17 00:12, Ben Chan wrote:
> ---
> src/mm-base-call.c | 55
> ++
> 1 file changed, 18 insertions(+), 37 deletions(-)
>
Pushed to git master, thanks.
Also please note that I pushed a follow up commit removing the unneeded
g_task_set_ta
On 06/07/17 00:12, Ben Chan wrote:
> ---
> src/mm-base-call.c | 59
> ++
> 1 file changed, 20 insertions(+), 39 deletions(-)
>
Pushed to git master, thanks.
Also please note that I pushed a follow up commit removing the unneeded
g_task_set_ta
On 06/07/17 00:12, Ben Chan wrote:
> ---
> src/mm-base-call.c | 44 +++-
> 1 file changed, 11 insertions(+), 33 deletions(-)
>
Pushed to git master, thanks.
Also please note that I pushed a follow up commit removing the unneeded
g_task_set_task_data() cal
On 06/07/17 00:12, Ben Chan wrote:
> ---
> src/mm-base-call.c | 53 +
> 1 file changed, 17 insertions(+), 36 deletions(-)
>
Pushed to git master, thanks.
Also please note that I pushed a follow up commit removing the unneeded
g_task_set_task_d
Tore Anderson writes:
> After switching it to configuration #3 (MBIM) everything Just Worked
> without any further tinkering. I see the blog post author went for
> configuration #1 instead, and that looks more cumbersome pull off.
> Maybe it has any distinct advantage over MBIM mode he needed, I
On 06/07/17 07:20, Ben Chan wrote:
> When returning an enum value via g_task_return_int, some code assumes
> the enum value is always non-negative and thus considers that a negative
> value implies an error. This assumption could be invalidated if a
> negative value is later added to the enum. To m
Tore Anderson writes:
> The good news is that HP support agreed to replace my lt4132 with a
> lt4120, which is a Foxconn device that I hope works better.
I'm impressed! Wonder if they have a suitable checkbox in their
customer satisfaction form or whatever?
"Reason for RMA:
[ ] DOA
[ ] Grem
23 matches
Mail list logo
