Cinterion MV31-W modem support

[ROSTANSKI Tomasz]

Hi,

I tried mbimcli with -p option but the result is the same - timeout.
I also tried the latest linux-next kernel, but there's no difference.

The modem is M.2 factor connected to mPCIe slot via M.2 to mPCIe adapter. I tried two different adapters but with no luck.
I see no errors in kernel log, basing on mhi debugfs I see that the modem is switching from M3 to M0 mode when mbimcli is executed, and then moves back to M3, so it looks ok.

Regards,
Tomasz

-----Original Message-----
From: Loic Poulain <loic.poulain at linaro.org> 
Sent: Friday, July 30, 2021 12:51 PM
To: Aleksander Morgado <aleksander at aleksander.es>
Cc: ROSTANSKI Tomasz <tomasz.rostanski at thalesgroup.com>; modemmanager-devel at lists.freedesktop.org
Subject: Re: Cinterion MV31-W modem support

On Fri, 30 Jul 2021 at 12:42, Loic Poulain <loic.poulain at linaro.org> wrote:
>
> On Fri, 30 Jul 2021 at 12:18, Aleksander Morgado 
> <aleksander at aleksander.es> wrote:
> >
> > Hey,
> >
> > > The change I made is for cinterion plugin only:
> > > diff --git a/plugins/cinterion/mm-plugin-cinterion.c 
> > > b/plugins/cinterion/mm-plugin-cinterion.c
> > > index 48fbb1ac..fe97f900 100644
> > > --- a/plugins/cinterion/mm-plugin-cinterion.c
> > > +++ b/plugins/cinterion/mm-plugin-cinterion.c
> > > @@ -181,9 +181,9 @@ grab_port (MMPlugin *self,  G_MODULE_EXPORT 
> > > MMPlugin *  mm_plugin_create (void)  {
> > > -    static const gchar *subsystems[] = { "tty", "net", "usbmisc", NULL };
> > > +    static const gchar *subsystems[] = { "tty", "net", "usbmisc", 
> > > + "wwan", NULL };
> > >      static const gchar *vendor_strings[] = { "cinterion", "siemens", NULL };
> > > -    static const guint16 vendor_ids[] = { 0x1e2d, 0x0681, 0 };
> > > +    static const guint16 vendor_ids[] = { 0x1e2d, 0x0681, 0x1269, 
> > > + 0 };
> > >      static const MMAsyncMethod custom_init = {
> > >          .async  = G_CALLBACK (cinterion_custom_init),
> > >          .finish = G_CALLBACK (cinterion_custom_init_finish),
> > >
> > > The quectel plugins does not whitelist the 0x1269:
> > > [...]
> > > [5328]: <debug> [plugin-manager] loaded plugin 'quectel' from '/usr/lib/ModemManager/libmm-plugin-quect el.so'
> > > [5328]: <debug> [filter] registered plugin whitelist vendor id: 
> > > 2c7c
> > > [5328]: <debug> [filter] registered plugin whitelist vendor id: 
> > > 1eac
> > > [5328]: <debug> [plugin-manager] loaded plugin 'pantech' from '/usr/lib/ModemManager/libmm-plugin-pante ch.so'
> > > [...]
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: found '3' 
> > > plugins to try
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: will try with plugin 'quectel'
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: will try with plugin 'cinterion'
> > > [5328]: <debug> [plugin-manager] task 10,wwan0mbim0: will try with plugin 'generic'
> > > [...]
> > > So it's weird it matches the MV31-W modem
> >
> > Yes, this is very very weird, and something we'll need to fix at 
> > some point. I'll try to see if I can find a reason for that.
> >
> > >
> > > I also tried using the mbimcli directly but it does not work as well:
> > > root at OpenWrt:~# mbimcli --query-device-caps -d /dev/wwan0mbim0 -v
> > > [30 Jul 2021, 06:19:33] [Debug] opening device...
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Couldn't query 
> > > maximum message size: IOCTL_WDM_MAX_COMMAND failed: Not a tty
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Couldn't find 
> > > descriptors file, possibly not using cdc_mbim
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Fallback to 
> > > default max control message size: 4096
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Sent message...
> > > <<<<<< RAW:
> > > <<<<<<   length = 16
> > > <<<<<<   data   = 01:00:00:00:10:00:00:00:01:00:00:00:00:10:00:00
> > >
> > > [30 Jul 2021, 06:19:34] [Debug] [/dev/wwan0mbim0] Sent message (translated)...
> > > <<<<<< Header:
> > > <<<<<<   length      = 16
> > > <<<<<<   type        = open (0x00000001)
> > > <<<<<<   transaction = 1
> > > <<<<<< Contents:
> > > <<<<<<   max control transfer = 4096
> > > [...]
> > > [30 Jul 2021, 06:19:59] [Debug] [/dev/wwan0mbim0] Sent message...
> > > <<<<<< RAW:
> > > <<<<<<   length = 16
> > > <<<<<<   data   = 01:00:00:00:10:00:00:00:06:00:00:00:00:10:00:00
> > >
> > > [30 Jul 2021, 06:19:59] [Debug] [/dev/wwan0mbim0] Sent message (translated)...
> > > <<<<<< Header:
> > > <<<<<<   length      = 16
> > > <<<<<<   type        = open (0x00000001)
> > > <<<<<<   transaction = 6
> > > <<<<<< Contents:
> > > <<<<<<   max control transfer = 4096
> > >
> > > [30 Jul 2021, 06:20:04] [Debug] open operation timed out: closed
> > > error: couldn't open the MbimDevice: Operation timed out: device 
> > > is close
> >
> > Maybe @Loic Poulain can spot something?
>
> Timeout usually happens when the mbim proxy is already running. So you 
> should use -p option here, or stop the mbim proxy.
> Point is that if wwan port is opened by two different processes, 
> you're not sure which one will read mbim reply, and you can end with 
> timeout.

BTW, serial device tools usually rely on lock file to acquire a tty dev (in /var/lock/), maybe we should do the same for mbim, and have e.g. /var/lock/LCK..wwan0mbim0. I think issue is common to any mbim (and qmi) implementation (WWAN, USB...).

>
> Regards,
> Loic