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

Reply via email to