Hi Joey, > These add support for Qualcomm-based smartphone modems. > > The first is fairly straightforward: searching for "rpmsg"-subsystem devices > and supporting them in gobi as a serial device. A friend has tested it on the > mainline kernel, with the help of something like `rpmsgexport > /dev/rpmsg_ctrl0 DATA5_CNTL` (https://github.com/andersson/rpmsgexport) and > then giving the created rpmsg node OFONO_DRIVER=gobi property.
I would actually prefer that the functionality of RPMSG_CREATE_EPT_IOCTL gets done inside oFono’s plugin. Also lifetime rules of that created node are wonky. I would expect that oFono quits, they are returned back to RPMSG subsystem. > The second is uglier, and maybe controversial, since it's for Qualcomm's > forked kernel. The smdpkt device doesn't support polling for write, so oFono > would wait forever on the poll. This would probably be a 5-line fix in the > kernel, but there are thousands of kernel forks, so I thought it might be > better to workaround in oFono. I've tested it on Samsung S4 Mini LTE, running > a kernel based on the MSM fork. I would still fix this upstream and only workaround devices blacklisted with a quirk. This reminds me also why RPMSG is not actually exported as a socket in the first. Creating a device node first and then using it later is always prone to race conditions. An alternative is to open the control character device and turn it into a proper pipe for QMI. I would like to see some proper fixes in the RPMSG subsystem to allow for proper handling by a telephony daemon. On a side note, we had all these race conditions and issues with GSM 07.07 multiplexer code before. Having to wait for a device node to be create is crap. One reason why oFono comes with a builtin GSM 07.07 implementation. Regards Marcel _______________________________________________ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
