> On 16 February 2017 at 12:40 Aleksander Morgado
> wrote:
>
> On Thu, Feb 16, 2017 at 1:31 PM, Colin Helliwell
>
> wrote:
> >
>
..
> > i.e. I've left in, for now, the MM_PLUGIN_ALLOWED_DRIVERS/drivers additions.
> > ENV{ID_MM_CINT_LINMUX}="1" is added to the udev rules, and everything
> >
On Thu, Feb 16, 2017 at 1:31 PM, Colin Helliwell
wrote:
>
> I'm back on this, trying to do it properly. I've removed by mod to
> mm-plugin.c, and added a udev tag
>
> G_MODULE_EXPORT MMPlugin *
> mm_plugin_create (void)
> {
> static const gchar *subsystems[] = { "tty", "net", "usb", NULL };
>
> On 14 February 2017 at 12:59 Aleksander Morgado
> wrote:
>
> On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell
>
> > iter = g_object_ref (child);
> > while (iter && i++ < 8) {
> >
> > diff -Nur a/plugins/cinterion/mm-plugin-cinterion.c
> > b/plugins/cinterion/mm-plugin-cinterion.c
> > ---
> On 15 February 2017 at 18:04 Aleksander Morgado
> wrote:
>
...
>
> The purpose of ID_MM_PHYSDEV_UID is to have the user provide a "unique
> id" which may be used as name when referencing a modem, e.g. "mmcli -m
> NAME"; but that also serves the purpose of binding together ports with
> the sa
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 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
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 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
On Tue, 2017-02-14 at 15:16 +, Colin Helliwell wrote:
> > On 14 February 2017 at 12:59 Aleksander Morgado > der.es> wrote:
> >
> > On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell
> >
>
> ...
> > > > Yes, the idea is that both ports end up grabbed in the same
> > > > modem. How
> > > > are
> On 14 February 2017 at 12:59 Aleksander Morgado
> wrote:
>
> On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell
>
...
> > > Yes, the idea is that both ports end up grabbed in the same modem. How
> > > are these ports exposed by the kernel? Not via the usb subsystem it
> > > seems? MM needs a w
On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell
wrote:
>> > > > Thanks. The question arises from needing to have monitoring & URCs etc
>> > > > on one port of my mux driver, and ppp on the other - I need to make
>> > > > sure that ppp doesn't get run on the 'monitoring' port i.e. the one
>> >
> On 14 February 2017 at 11:54 Colin Helliwell
> wrote:
>
> > On 14 February 2017 at 11:33 Aleksander Morgado
> > wrote:
> >
> > On Tue, Feb 14, 2017 at 11:39 AM, Colin Helliwell
> >
> > wrote:
> >
> > > > > Thanks. The question arises from needing to have monitoring & URCs
> > > > > etc
> On 14 February 2017 at 11:33 Aleksander Morgado
> wrote:
>
> On Tue, Feb 14, 2017 at 11:39 AM, Colin Helliwell
>
> wrote:
>
> > > > Thanks. The question arises from needing to have monitoring & URCs etc
> > > > on one port of my mux driver, and ppp on the other - I need to make
> > > > s
On Tue, Feb 14, 2017 at 11:39 AM, Colin Helliwell
wrote:
>> > Thanks. The question arises from needing to have monitoring & URCs etc on
>> > one port of my mux driver, and ppp on the other - I need to make sure that
>> > ppp doesn't get run on the 'monitoring' port i.e. the one that gets in
>>
> On 13 February 2017 at 13:40 Aleksander Morgado
> wrote:
>
> On Mon, Feb 13, 2017 at 2:05 PM, Colin Helliwell
>
> wrote:
>
> >
> > Thanks. The question arises from needing to have monitoring & URCs etc on
> > one port of my mux driver, and ppp on the other - I need to make sure that
> >
On Mon, Feb 13, 2017 at 2:05 PM, Colin Helliwell
wrote:
>> > I’ve got two ports whitelisted for use by MM. What determines which one of
>> > them will be ‘Modem/0’ ?
>>
>> Just the first modem that finishes first probing all ports.
>>
>> > Is there a way to get MM to create/initialise 0 first, the
> On 10 February 2017 at 17:47 Aleksander Morgado
> wrote:
>
> On Fri, Feb 10, 2017 at 3:39 PM, wrote:
>
> > I’ve got two ports whitelisted for use by MM. What determines which one of
> > them will be ‘Modem/0’ ?
>
> Just the first modem that finishes first probing all ports.
>
> > Is there
On Fri, Feb 10, 2017 at 3:39 PM, wrote:
> I’ve got two ports whitelisted for use by MM. What determines which one of
> them will be ‘Modem/0’ ?
>
Just the first modem that finishes first probing all ports.
> Is there a way to get MM to create/initialise 0 first, then 1 – as opposed
> to doing b
I've got two ports whitelisted for use by MM. What determines which one of
them will be 'Modem/0' ?
Is there a way to get MM to create/initialise 0 first, then 1 - as opposed
to doing both in *parallel*?
I'm getting MM to use the Cinterion plugin for my modem, by adding
ENV{ID_MM_PLATFOR
22 matches
Mail list logo
