[PATCH v2] Add custom flow control settings for Telit HE910, UE910, UL865

[Dan Williams]

On Fri, 2015-03-13 at 17:02 +0100, Aleksander Morgado wrote:
> On Fri, Mar 13, 2015 at 3:20 PM, Dan Williams <dcbw at redhat.com> wrote:
> >> 2015-03-12 22:11 GMT+01:00 Aleksander Morgado <aleksander at aleksander.es>:
> >> > On Thu, Mar 12, 2015 at 9:32 PM, Ben Chan <benchan at chromium.org> wrote:
> >> >> Not sure about UE910 / UL865, we probably want to ignore a few
> >> >> interfaces on HE910 as these ports aren't responding to AT probe and
> >> >> don't want to waste extra time probing them. I can rebase my patch
> >> >> earlier to all the following rules. What do you think?
> >> >>
> >> >>
> >> >> ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021",
> >> >> ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_PORT_IGNORE}="1"
> >> >> ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021",
> >> >> ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_PORT_IGNORE}="1"
> >> >> ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021",
> >> >> ENV{.MM_USBIFNUM}=="08", ENV{ID_MM_PORT_IGNORE}="1"
> >> >> ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021",
> >> >> ENV{.MM_USBIFNUM}=="0a", ENV{ID_MM_PORT_IGNORE}="1"
> >> >> ATTRS{idVendor}=="1bc7", ATTRS{idProduct}=="0021",
> >> >> ENV{.MM_USBIFNUM}=="0c", ENV{ID_MM_PORT_IGNORE}="1"
> >> >
> >> > Daniele, what do you think about this? I don't have any of those
> >> > modems to check that myself.
> >> >
> >> > If the ports don't reply to AT or anything, then what are those ports
> >> > for? (just wondering) I guess one may be a GPS data port, but what
> >> > about the others? Also, what's the kernel driver managing those ports?
> >> >
> >>
> >> HE910/UE910/UL865 use the standard cdc-acm driver.
> >>
> >> Some useful information can be found in "HE910/UE910/UL865 Families Ports
> >> Arrangements User Guide" (it can be found in Telit website).
> >>
> >> The AT command AT#PORTCFG sets the ports behaviour.
> >>
> >> For the factory setting (#PORTCFG=1) only the two interfaces I put in
> >> the udev rules are linked to AT parsers, so I think it is safe to
> >> ignore the other
> >> ones.
> >>
> >> The other ports are used with different #PORTCFG settings (for modem traces,
> >> gps, additional AT parser, appzone...)
> >
> > Yeah, this is what I was afraid of, and one reason why we have the MM
> > probing behavior.  The port configuration can often be changed in
> > firmware (or by a firmware update) so the same static udev rules cannot
> > always be used.
> >
> > *however*, we can ship a set of default udev rules and describe the port
> > configuration it should be used for, and then individual users or
> > packagers can override those rules for their specific use-cases if they
> > wish.  eg, we could have a 77-telit-910-portcfg-1.rules and
> > 77-telit-910-portcfg-5.rules which correspond to each #PORTCFG layout
> > for each modem?
> 
> Why not run AT#PORTCFG? during probing to query the port layout, and
> based on that decide which if# is primary and which is data? (like we
> do with e.g. Huawei?)

Yeah, or that.  And stop probing other ports when we get a response.

Dan