Adding Telit ME310G1-WW support

[Sebastian Sjoholm]

Hi,

Regarding the ECM. I have been working with the BG95 which uses the same
chipset (MDM9205) it exposes the qmi device, but it is not either possible
to use, on BG95 it is not supported at all, even it is exposed. Might be
related.

-Sebastian

On Sun, Jul 12, 2020 at 8:28 PM Mark Deneen <mdeneen at gmail.com> wrote:

> On Sun, Jul 12, 2020 at 3:08 AM Aleksander Morgado
> <aleksander at aleksander.es> wrote:
> >
> > Hey!
> >
> > > I've attached a patch which uses the "custom regex" feature of the
> > > existing parser in order to detect PPP and say that things are good.
> > > A few things to note:
> > >
> > > * I created the regex based on data I saw output from my modem.  At
> > > best it is correct, at worst it won't do any harm.
> >
> > I find this regex is extremely specific to your usecase. As you said
> > it may be a fix, or it may not do anything, that isn't a complete
> > solution, and I think we should try to find some other way to handle
> > this if possible.
> >
> > I find it very very weird that the modem doesn't reply a CONNECT
> > response after the ATD, that would be a very weird firmware bug! Maybe
> > the TTY we're using for connection isn't the correct one? @Daniele
> > Palmas @Carlo Lobrano Do you guys have any idea of why this may be
> > happening in the ME310?
>
> There are two ports which accept AT commands, and both behave in the
> same fashion.  Here's some more information on the modem:
>
> Output of AT#SWPKGV:
>
> 37.00.210-B038-P0C.210000
> M0C.200000-B038
> P0C.210000
> A0C.210000
>
> ATI0: 332
> ATI1: 0
> ATI2:
> ATI3: Telit
> ATI4: ME310G1-WW
> ATI5: DOB v.2.0
>
> I would not be surprised if the "-WW" part has different functionality.
>
> I issued the AT commands in picocom as well to confirm that CONNECT
> was never sent.
>
>
> > > * Ideally I would only use this for the ME310 modem, but I didn't see
> > > a way to do that in the plugin.  I'm certainly open to suggestions.
> >
> > If we needed a quirk like this one, we could flag via udev with a new
> udev tag.
> >
> > > This particular device has a second port configuration (1bc7:1102),
> > > which which  looks like this:
> > >
> > > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=atmel-ehci/3p, 480M
> > >     |__ Port 2: Dev 7, If 0, Class=Vendor Specific Class,
> Driver=option, 480M
> > >     |__ Port 2: Dev 7, If 1, Class=Vendor Specific Class,
> Driver=option, 480M
> > >     |__ Port 2: Dev 7, If 2, Class=Vendor Specific Class,
> Driver=option, 480M
> > >     |__ Port 2: Dev 7, If 3, Class=Communications, Driver=cdc_ether,
> 480M
> > >     |__ Port 2: Dev 7, If 4, Class=CDC Data, Driver=cdc_ether, 480M
> > >
> > > I've not been able to get the cdc_ether portion working yet, although
> > > I am hopeful.  If both ECM and "option" serial interfaces are
> > > available, how does ModemManager choose between them?
> >
> > MM doesn't have any implementation yet to handle ECM interfaces in
> > Telit modems, but that would definitely be preferred over PPP in a
> > TTY.
>
> I would also prefer to use ECM over pppd, but I've not found a way to
> make this work yet.
>
>
> > Regarding the patch itself, you shouldn't add the regex to the primary
> > port. You should run mm_base_modem_peek_data_ports() and add the regex
> > to all data ports that are TTYs (MM_IS_PORT_SERIAL()). But as said, I
> > would totally prefer to have this solved somehow without needing to
> > detect the PPP stream, because it is pppd the only one who should be
> > touching that (MM yields the control of the TTY to pppd as soon as the
> > port is in data mode).
>
> This is easy enough to do, but I will focus on getting ECM working first.
>
> Thanks for the response, Aleksander.
>
>
> -M
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20200712/1f07d31b/attachment.htm>