Re: [review] New 'fibocom' plugin
Hey, >> You may know this better than me; are all DIAG ports from all qualcomm >> modems ever of the same class/subclass/protocol? i.e. Cls=ff(vend.) >> Sub=ff Prot=ff >> In other words, should we bother probing QCDM for ports that are not >> ff/ff/ff? > > Hi Aleksander, > > at least some Huawei mobiles like ME909u > > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber1 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass 1 > bInterfaceProtocol 19 > iInterface 51 HUAWEI Mobile Connect - Application Interface > > and Cinterion PLS8 with firmware >= 02.x > > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber9 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass10 CDC Data > bInterfaceSubClass 0 Unused > bInterfaceProtocol 0 > iInterface 8 CDC ACM Data for DIAG > > are exceptions to the rule. > Oh well, those 2 examples are already too many, I don't think the ff/ff/ff suggestion is a good one :) -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
>> >> > On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT >> >> > ports >> >> > on the L850-GL module (e.g. >> >> > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov >> >> > erlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port- >> >> > types.rules). >> >> > >> >> > The modem is functional with just MBIM and supported via the >> >> > generic >> >> > plugin, which is the approach we took on Chrome OS. IMHO, there is >> >> > little added benefit with a new modem plugin. More importantly, AT >> >> > probing takes quite some time, and I observed it often took 7 >> >> > seconds. >> >> > We've been trying hard for some time to move everything to purely >> >> > MBIM >> >> > or QMI :) >> >> > >> >> >> >> I'm going to extend this plugin in the following weeks with more >> >> features that will require the use of the AT port, e.g. GPS location >> >> and such. I agree that probing is a bit slow right now, but that is >> >> just because the DIAG port goes first through a series of AT probing >> >> steps which are not needed. For devices with fixed layouts like this >> >> one, adding udev tags to specify port types isn't bad IMO, and we >> >> should probably do that for the DIAG port (i.e. flag it as "not AT" >> >> for example). >> > >> > Agreed; ideally we can begin to restrict which ports we bother probing >> > for DIAG, since with QMI and MBIM DIAG is much less useful these days. >> > > > IIRC, I initially blacklisted two out of the three AT ports, but > initial AT probing still took seconds to complete (and seconds matter > a lot on Chrome OS as we're pretty sensitive to the overall time from > boot to connect), which drove me into blacklisting all AT ports. For > functionality that isn't implemented by standard MBIM command set, > we've pushing for MBIM extensions -- actually, you'll expect a few > related patches from me soon :-) > > Regarding your patches, I think they won't interfere with our AT > blacklist on this modem. In the worst case, we can simply skip > installing the fibocom plugin, which should allow us to gracefully > fall back to the generic plugin and use only MBIM. Yes, the plugin won't interfere in any way as long as you keep it MBIM-only by blacklisting all TTYs. I may understand what you say about the slow probing, though. Looks like that may be similar to what I've seen with the also Intel-based TOBY-L4, where the ttys are exposed early in the kernel, but then they require some time to be ready for AT. That would cause slow probing of TTYs indeed. I guess users may need to decide between having more features given by an AT fallback or gaining some extra seconds during boot. For the generic MM case we should worry about the former I'd say. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
On Thu, Jul 19, 2018 at 09:44:57PM +0200, Aleksander Morgado wrote: > On Thu, Jul 19, 2018 at 9:23 PM, Dan Williams wrote: > > On Thu, 2018-07-19 at 21:10 +0200, Aleksander Morgado wrote: > >> > On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT > >> > ports > >> > on the L850-GL module (e.g. > >> > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov > >> > erlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port- > >> > types.rules). > >> > > >> > The modem is functional with just MBIM and supported via the > >> > generic > >> > plugin, which is the approach we took on Chrome OS. IMHO, there is > >> > little added benefit with a new modem plugin. More importantly, AT > >> > probing takes quite some time, and I observed it often took 7 > >> > seconds. > >> > We've been trying hard for some time to move everything to purely > >> > MBIM > >> > or QMI :) > >> > > >> > >> I'm going to extend this plugin in the following weeks with more > >> features that will require the use of the AT port, e.g. GPS location > >> and such. I agree that probing is a bit slow right now, but that is > >> just because the DIAG port goes first through a series of AT probing > >> steps which are not needed. For devices with fixed layouts like this > >> one, adding udev tags to specify port types isn't bad IMO, and we > >> should probably do that for the DIAG port (i.e. flag it as "not AT" > >> for example). > > > > Agreed; ideally we can begin to restrict which ports we bother probing > > for DIAG, since with QMI and MBIM DIAG is much less useful these days. > > > > You may know this better than me; are all DIAG ports from all qualcomm > modems ever of the same class/subclass/protocol? i.e. Cls=ff(vend.) > Sub=ff Prot=ff > In other words, should we bother probing QCDM for ports that are not ff/ff/ff? Hi Aleksander, at least some Huawei mobiles like ME909u Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 19 iInterface 51 HUAWEI Mobile Connect - Application Interface and Cinterion PLS8 with firmware >= 02.x Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber9 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 8 CDC ACM Data for DIAG are exceptions to the rule. Regards, Reinhard ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
On Thu, Jul 19, 2018 at 12:45 PM Aleksander Morgado wrote: > > On Thu, Jul 19, 2018 at 9:23 PM, Dan Williams wrote: > > On Thu, 2018-07-19 at 21:10 +0200, Aleksander Morgado wrote: > >> > On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT > >> > ports > >> > on the L850-GL module (e.g. > >> > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov > >> > erlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port- > >> > types.rules). > >> > > >> > The modem is functional with just MBIM and supported via the > >> > generic > >> > plugin, which is the approach we took on Chrome OS. IMHO, there is > >> > little added benefit with a new modem plugin. More importantly, AT > >> > probing takes quite some time, and I observed it often took 7 > >> > seconds. > >> > We've been trying hard for some time to move everything to purely > >> > MBIM > >> > or QMI :) > >> > > >> > >> I'm going to extend this plugin in the following weeks with more > >> features that will require the use of the AT port, e.g. GPS location > >> and such. I agree that probing is a bit slow right now, but that is > >> just because the DIAG port goes first through a series of AT probing > >> steps which are not needed. For devices with fixed layouts like this > >> one, adding udev tags to specify port types isn't bad IMO, and we > >> should probably do that for the DIAG port (i.e. flag it as "not AT" > >> for example). > > > > Agreed; ideally we can begin to restrict which ports we bother probing > > for DIAG, since with QMI and MBIM DIAG is much less useful these days. > > IIRC, I initially blacklisted two out of the three AT ports, but initial AT probing still took seconds to complete (and seconds matter a lot on Chrome OS as we're pretty sensitive to the overall time from boot to connect), which drove me into blacklisting all AT ports. For functionality that isn't implemented by standard MBIM command set, we've pushing for MBIM extensions -- actually, you'll expect a few related patches from me soon :-) Regarding your patches, I think they won't interfere with our AT blacklist on this modem. In the worst case, we can simply skip installing the fibocom plugin, which should allow us to gracefully fall back to the generic plugin and use only MBIM. > > You may know this better than me; are all DIAG ports from all qualcomm > modems ever of the same class/subclass/protocol? i.e. Cls=ff(vend.) > Sub=ff Prot=ff > In other words, should we bother probing QCDM for ports that are not ff/ff/ff? > > -- > Aleksander > https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
On Thu, Jul 19, 2018 at 9:23 PM, Dan Williams wrote: > On Thu, 2018-07-19 at 21:10 +0200, Aleksander Morgado wrote: >> > On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT >> > ports >> > on the L850-GL module (e.g. >> > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov >> > erlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port- >> > types.rules). >> > >> > The modem is functional with just MBIM and supported via the >> > generic >> > plugin, which is the approach we took on Chrome OS. IMHO, there is >> > little added benefit with a new modem plugin. More importantly, AT >> > probing takes quite some time, and I observed it often took 7 >> > seconds. >> > We've been trying hard for some time to move everything to purely >> > MBIM >> > or QMI :) >> > >> >> I'm going to extend this plugin in the following weeks with more >> features that will require the use of the AT port, e.g. GPS location >> and such. I agree that probing is a bit slow right now, but that is >> just because the DIAG port goes first through a series of AT probing >> steps which are not needed. For devices with fixed layouts like this >> one, adding udev tags to specify port types isn't bad IMO, and we >> should probably do that for the DIAG port (i.e. flag it as "not AT" >> for example). > > Agreed; ideally we can begin to restrict which ports we bother probing > for DIAG, since with QMI and MBIM DIAG is much less useful these days. > You may know this better than me; are all DIAG ports from all qualcomm modems ever of the same class/subclass/protocol? i.e. Cls=ff(vend.) Sub=ff Prot=ff In other words, should we bother probing QCDM for ports that are not ff/ff/ff? -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
On Thu, 2018-07-19 at 21:10 +0200, Aleksander Morgado wrote: > > On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT > > ports > > on the L850-GL module (e.g. > > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov > > erlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port- > > types.rules). > > > > The modem is functional with just MBIM and supported via the > > generic > > plugin, which is the approach we took on Chrome OS. IMHO, there is > > little added benefit with a new modem plugin. More importantly, AT > > probing takes quite some time, and I observed it often took 7 > > seconds. > > We've been trying hard for some time to move everything to purely > > MBIM > > or QMI :) > > > > I'm going to extend this plugin in the following weeks with more > features that will require the use of the AT port, e.g. GPS location > and such. I agree that probing is a bit slow right now, but that is > just because the DIAG port goes first through a series of AT probing > steps which are not needed. For devices with fixed layouts like this > one, adding udev tags to specify port types isn't bad IMO, and we > should probably do that for the DIAG port (i.e. flag it as "not AT" > for example). Agreed; ideally we can begin to restrict which ports we bother probing for DIAG, since with QMI and MBIM DIAG is much less useful these days. Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
> On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT ports > on the L850-GL module (e.g. > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port-types.rules). > > The modem is functional with just MBIM and supported via the generic > plugin, which is the approach we took on Chrome OS. IMHO, there is > little added benefit with a new modem plugin. More importantly, AT > probing takes quite some time, and I observed it often took 7 seconds. > We've been trying hard for some time to move everything to purely MBIM > or QMI :) > I'm going to extend this plugin in the following weeks with more features that will require the use of the AT port, e.g. GPS location and such. I agree that probing is a bit slow right now, but that is just because the DIAG port goes first through a series of AT probing steps which are not needed. For devices with fixed layouts like this one, adding udev tags to specify port types isn't bad IMO, and we should probably do that for the DIAG port (i.e. flag it as "not AT" for example). -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [review] New 'fibocom' plugin
Hi Aleksander, On Chrome OS, we simply use ID_MM_PORT_IGNORE to ignore all AT ports on the L850-GL module (e.g. https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/net-misc/modemmanager-next/files/77-mm-fibocom-port-types.rules). The modem is functional with just MBIM and supported via the generic plugin, which is the approach we took on Chrome OS. IMHO, there is little added benefit with a new modem plugin. More importantly, AT probing takes quite some time, and I observed it often took 7 seconds. We've been trying hard for some time to move everything to purely MBIM or QMI :) WDYT? Thanks, Ben On Thu, Jul 19, 2018 at 7:09 AM Aleksander Morgado wrote: > > Hey all, > > See this MR introducing a new Fibocom plugin, which right now just > maps support for AT/MBIM based devices. > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/12 > > Tested with the L850-GL module (MBIM+2 AT ports+Intel trace port), and > explicitly blacklisted the Intel trace port. > > Comments welcome > > -- > Aleksander > https://aleksander.es > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
[review] New 'fibocom' plugin
Hey all, See this MR introducing a new Fibocom plugin, which right now just maps support for AT/MBIM based devices. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/12 Tested with the L850-GL module (MBIM+2 AT ports+Intel trace port), and explicitly blacklisted the Intel trace port. Comments welcome -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
