Hey! > > I am a developer working on a board with a Quectel Modem, and I am in charge > of replacing our old abstraction layer with ModemManager to communicate with > this modem. > > I have been playing with ModemManager for a few days to be familiar with it. > I have read the documentation and I have been reading also the source code to > better understand how it works. > > However, a few fundamental questions remain for me, and I hope some people > here may give me some clue. > > First of all, when I list the modems found by MM, it returns not one, but two > modems: > > # mmcli -L > /org/freedesktop/ModemManager1/Modem/1 [Quectel] SG520TM > /org/freedesktop/ModemManager1/Modem/0 [Quectel] SG520TM > > One of them is linked to tty USB port and communicates only with AT commands > (ttyUSBx), the other one is linked to the PCIe port and communicates only > with QMI (wwan0qmi0). > I do not have a wwan0at0 driver. The only way to have AT commands is through > the ttyUSBx port. > > It looks like I have two separate modems, whereas I have only one physical > modem, connected to the board with two physical ports (usb & pcie). >
Yep, that is indeed possible, especially in custom boards. Also, some manufacturers may expect you to upgrade firmware only via USB while managing the modem via PCI and things like that. > The diagrams here suggest that MM can have single modems with more than one > protocol, but on the same physical port: > https://modemmanager.org/docs/modemmanager/wwan-device-types/ > > Is it possible to have MM create only one modem using two different physical > ports (ttyUSBx on USB & wwan0qmi0 on PCIe), in order to have AT & QMI > simultaneously? > > If not, does it mean that in order to have one modem with AT & QMI, I would > need to have a working wwan0at0 driver? > You can have one single modem with all the ports in the two different buses by making sure all the ports have the same ID_MM_PHYSDEV_UID tag. See https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/ModemManager-Common-udev-tags.html#ID-MM-PHYSDEV-UID:CAPS And also https://sigquit.wordpress.com/2016/10/06/naming-devices-in-modemmanager/ If you apply that tag to all the ports, e.g. using the DEVPATH of each port for example, and use the same uid in all (e.g. "MyModem") then ModemManager will bind all ports in the same modem object. Plus, you could do "mmcli -m MyModem" as well :) Of course, you need to ensure that the DEVPATH of your rules doesn't change. You can assume the DEVPATH of a port in USB or PCI won't change as long as the hardware layout is the same. A corollary of this would be that the DEVPATH for the ports in different board units with the same hardware layout (same board type) won't change either. > > My second question is about the cache handling. > I could see that MM may use cached AT results, meaning that your plugin can > have the result of an AT command without actually sending it (with the > allow_cached parameter). > This is a great feature, and experience showed us that it improves > dramatically your application latencies. Please note this applies *exclusively* to commands that are known to never change, mostly the "test" commands like e.g. "AT+CGDCONT=?" or "AT+CGACT=?". This caching feature doesn't make sense for commands that include state values in the response like e.g. "AT+CGDCONT?" or "AT+CGACT?". > > Are QMI or Dbus requests cached as well? > No, none of them. There are some commands which could be cached (e.g. those querying static info from the modem like supported services), but it's probably not very useful. -- Aleksander
