Hey, > On Tue, 9 Feb 2021 10:20:30 +0100 Aleksander Morgado wrote: > > This may be a stupid suggestion, but would the integration look less a > > backdoor if it would have been named "mhi_wwan" and it exposed already > > all the AT+DIAG+QMI+MBIM+NMEA possible channels as chardevs, not just > > QMI? > > What's DIAG? DIAG/QCDM is an older protocol in Qualcomm based modems; in USB based devices we would get a TTY that speaks this protocol. In legacy CDMA modems this was required for actual device control (and ModemManager has a libqcdm for that https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tree/master/libqcdm) but in all newest modems I'd say this is exclusively used for modem trace retrieval (e.g. asking the modem to enable some internal traces of the LTE stack which are downloaded in the host via this port). When debugging issues with manufacturers, this is what they would ask you to do, use this port to retrieve these traces (e.g. Quectel's QLog program does that, each manufacturer keeps its own). > Who's going to remember that this is a backdoor driver > a year from now when Qualcomm sends a one liner patches which just > adds a single ID to open another channel? I'm obviously not going to argue about that possibility; although, wouldn't it make more sense to discuss that whenever that happens? This work is implemented in a very generic way probably, but it focuses on WWAN control ports, which is what we need in userspace. Right now this mhi_uci integration can be used for QMI control of the modems, and I assume once that gets merged (if ever!), more patches would arrive to enable AT, DIAG and MBIM control ports. The channels associated to these WWAN control protocols have clearly defined channel ids, and I believe the device itself chooses which channels are exposed, so a device may e.g. say that it's going to expose only the MBIM control port. This is also very manufacturer dependent I think; I know for example that WWAN modules for laptops will probably want to expose the MBIM channel instead of QMI, so that the same HW integration is used in both Linux and Windows easily. The single and generic mhi_uci integration for all these different WWAN control ports would allow any of those combinations, very much like with USB devices and different USB configurations. Userspace is also ready for this integration, btw; at least libmbim and libqmi don't have any problem with these chardevs, and ModemManager has a branch ready to land to support this new integration. A lot of new laptops that are already being sold since last year come now with PCIe-only WWAN modules, and unfortunately I've also seen different manufacturers pushing their own out-of-tree variants of this same mhi_uci idea with better or worse luck. I personally was very glad to see this work moving forward. -- Aleksander
