On Feb 15, 2017 5:39 PM, "Dan Williams" wrote:
On Wed, 2017-02-15 at 17:09 -0600, Russ Westrem wrote:
> On Feb 15, 2017 4:37 PM, "Dan Williams" wrote:
>
> On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote:
> > On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
> > wrote:
> > > Is there any
On Wed, 2017-02-15 at 17:09 -0600, Russ Westrem wrote:
> On Feb 15, 2017 4:37 PM, "Dan Williams" wrote:
>
> On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote:
> > On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
> > wrote:
> > > Is there anything in the modemmanager scripts that I could c
On Feb 15, 2017 4:37 PM, "Dan Williams" wrote:
On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote:
> On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
> wrote:
> > Is there anything in the modemmanager scripts that I could change
> > to have it
> > ignore the deregistered modem and stop it
On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote:
> On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
> wrote:
> > Is there anything in the modemmanager scripts that I could change
> > to have it
> > ignore the deregistered modem and stop it from removing it from the
> > bearer.
> > I have
On Wed, 2017-02-15 at 21:14 +0100, Aleksander Morgado wrote:
> On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
> wrote:
> > Is there anything in the modemmanager scripts that I could change
> > to have it
> > ignore the deregistered modem and stop it from removing it from the
> > bearer.
> > I have
On Wed, Feb 15, 2017 at 9:00 PM, Russ Westrem
wrote:
> Is there anything in the modemmanager scripts that I could change to have it
> ignore the deregistered modem and stop it from removing it from the bearer.
> I have a feeling these deregistrations happen often but very quickly and
> maybe if ig
On Feb 14, 2017 11:20 PM, "Dan Williams" wrote:
On Tue, 2017-02-14 at 15:46 -0600, Russ Westrem wrote:
> You mean you can still use the WWAN even if MM says it's
> disconnected?
> Not sure I understood, otherwise.
>
>
> --
> Aleksander
> https://aleksander.es
>
>
>
> No, nothing is usable untill
On Wed, Feb 15, 2017 at 4:16 PM, Colin Helliwell
wrote:
>> On 15 February 2017 at 15:07 Colin Helliwell
>> wrote:
>>
>> > On 15 February 2017 at 14:11 Aleksander Morgado
>> > wrote:
>> >
>> > Is the logic stopping there? the ID_MM_PHYSDEV_UID should take
>> > precedence to whatever parent sysf
> On 15 February 2017 at 09:12 Aleksander Morgado
> wrote:
>
> On Wed, Feb 15, 2017 at 9:49 AM, Aleksander Morgado
> wrote:
>
> > Worst case, we just add a custom mkdir step in those enums generation rules.
>
> Could you test the attached patch?
>
Hi Aleksander,
Yes, that seems to have fix
> On 15 February 2017 at 15:07 Colin Helliwell
> wrote:
>
> > On 15 February 2017 at 14:11 Aleksander Morgado
> > wrote:
> >
> > Is the logic stopping there? the ID_MM_PHYSDEV_UID should take
> > precedence to whatever parent sysfs path is set, e.g. you could set
> > each tty's own sysfs pat
> On 15 February 2017 at 14:11 Aleksander Morgado
> wrote:
>
> On Wed, Feb 15, 2017 at 10:46 AM, Colin Helliwell
>
> wrote:
>
> > > > I get the feeling its written with nearly-but-not-quite up to date
> > > > methods, or just different ones. Certainly it's not easy to compare
> > > > again
This message is used to bind a muxed data port to a controller device.
The Muxed data port has to be managed by qmi_wwan driver.
The Muxed data port is identified by:
- mux_id: the numeric ID given to qmi_wwan once created
- interface number: the interface number of the qmi controller device on
Added the following configurable values:
- upload datagram protocol
- download datagram protocol
- download datagram max size
- download max datagrams
- endpoint type
- endpoint interface number
According to last GobiNet from CodeAura project, setting the following
values is necessary to enable mu
On Wed, Feb 15, 2017 at 10:46 AM, Colin Helliwell
wrote:
>> > I get the feeling its written with nearly-but-not-quite up to date
>> > methods, or just different ones. Certainly it's not easy to compare
>> > against USB-based drivers. From what I can make out, the three virtual
>> > ports are cr
> On 15 February 2017 at 09:18 Aleksander Morgado
> wrote:
>
> On Wed, Feb 15, 2017 at 10:00 AM, Colin Helliwell
>
> wrote:
>
> > > On 14 February 2017 at 17:28 Dan Williams wrote:
> > >
> > > On Tue, 2017-02-14 at 15:16 +, Colin Helliwell wrote:
> > >
> > > > > On 14 February 2017 at
On Wed, Feb 15, 2017 at 10:00 AM, Colin Helliwell
wrote:
>> On 14 February 2017 at 17:28 Dan Williams wrote:
>>
>> On Tue, 2017-02-14 at 15:16 +, Colin Helliwell wrote:
>>
>> > > On 14 February 2017 at 12:59 Aleksander Morgado > > > der.es> wrote:
>> > >
>> > > This is it. You're saying here
On Wed, Feb 15, 2017 at 9:49 AM, Aleksander Morgado
wrote:
> Worst case, we just add a custom mkdir step in those enums generation rules.
Could you test the attached patch?
--
Aleksander
https://aleksander.es
From 56d0c49dc80a66bb606b5ecea94c1ecdbb046ed6 Mon Sep 17 00:00:00 2001
From: Aleksande
> On 14 February 2017 at 17:28 Dan Williams wrote:
>
> On Tue, 2017-02-14 at 15:16 +, Colin Helliwell wrote:
>
> > > On 14 February 2017 at 12:59 Aleksander Morgado > > der.es> wrote:
> > >
> > > This is it. You're saying here that the "physical device" that owns
> > > this port is the po
Hey,
>> The issue is really related to the ublox subdir not existing before
>> calling glib-mkenums. In my setup, the directory is created before
>> glib-mkenums runs, though. What build tools are you using? i.e. which
>> automake version?
>>
>
> automake is version 1.15
> Possibly to do with para
19 matches
Mail list logo
