| Message ID | 20200430174615.41185-1-tony@atomide.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | n_gsm serdev support and GNSS driver for droid4 | expand |
> My guess is that at least with the pending ofono patches, we just > want to use the raw interface for /dev/gsmtty* interface and stop > pretending we have a modem that is AT compatible. I tried to get it to work... it was not fun and I did not get far. I pushed my results... user@devuan:/my/ofono$ git push Counting objects: 10, done. Delta compression using up to 2 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 1.17 KiB | 0 bytes/s, done. Total 10 (delta 8), reused 0 (delta 0) remote: Resolving deltas: 100% (8/8), completed with 8 local objects. To github.com:pavelmachek/ofono.git fd34ca20..9042014b mux-v1.29-1 -> mux-v1.29-1 Best regards, Pavel ofonod[12922]: drivers/atmodem/network-registration.c:at_netreg_probe() Probing creg Have command of length 9 (AT+CREG=?) or ^z ofonod[12922]: Voice: > U0000AT+FOO\r ofonod[12922]: InSMS: > U0000AT+FOO\r ofonod[12922]: OutSMS: > U0000AT+FOO\r ofonod[12922]: Voice: < U0000+FOO:ERROR=9\n new bytes 18 Have line: U0000+FOO:ERROR=9 Last character is 13 command response: U0000+FOO:ERROR=9 ofonod[12922]: plugins/motmdm.c:foo_cb() handle command response ofonod[12922]: Voice: > U0000AT+SCRN=0\r ofonod[12922]: OutSMS: < U0000+FOO:ERROR=9\n new bytes 18 Have line: U0000+FOO:ERROR=9 Last character is 13 command response: U0000+FOO:ERROR=9 ofonod[12922]: plugins/motmdm.c:foo_cb() handle command response ofonod[12922]: InSMS: < U0000+FOO:ERROR=9\n new bytes 18 Have line: U0000+FOO:ERROR=9 Last character is 13 command response: U0000+FOO:ERROR=9 ofonod[12922]: plugins/motmdm.c:foo_cb() ofonod[12922]: plugins/motmdm.c:foo_cb() All channels working handle command response ofonod[12922]: Voice: < U0000+SCRN:OK\n new bytes 14 Have line: U0000+SCRN:OK Last character is 13 command response: U0000+SCRN:OK ofonod[12922]: plugins/motmdm.c:scrn_cb() handle command response ofonod[12922]: Voice: > U0000AT+CFUN=1\r ofonod[12922]: Voice: < U0000+CFUN:OK\n new bytes 14 Have line: U0000+CFUN:OK Last character is 13 command response: U0000+CFUN:OK ofonod[12922]: plugins/motmdm.c:cfun_cb() handle command response ofonod[12922]: Voice: > U0000AT+CLIP=1\r ofonod[12922]: Voice: < U0000+CLIP:OK\n new bytes 14 Have line: U0000+CLIP:OK Last character is 13 command response: U0000+CLIP:OK handle command response ofonod[12922]: Voice: > U0000AT+CCWA=1\r ofonod[12922]: Voice: < U0000+CCWA:OK\n new bytes 14 Have line: U0000+CCWA:OK Last character is 13 command response: U0000+CCWA:OK ofonod[12922]: drivers/motorolamodem/voicecall.c:motorola_voicecall_initialized() voicecall_init: registering to notifications
Hi! > Now without the chardev support, the /dev/gsmtty* using apps need > to use "U1234AT+CFUN?" format for the packets. The advantage is > less kernel code, and we keep the existing /dev/gsmtty* interface. Actually... yes, this works. But no, this is not "existing" tty interface. ttys work per character, and this interface definitely does not... it is "packet" based, write() syscalls need exactly right lengths. You can't just open minicom, and type "U1234...". You can't paste it, either (I tried). tty controls like start/stop bits and baud rate are useless here. CR/LF conversions are unwanted/dangerous because it is confusing hard to debug if you get them wrong. Now, I don't see reason why this could not be made to work, and it may be more important to have something in mainline and work with that. So if you can make this into -next, I'll not complain too loudly. But it is... still wrong and I liked motmdm* more :-). Best regards, Pavel
* Pavel Machek <pavel@denx.de> [200501 08:22]: > Hi! > > > Now without the chardev support, the /dev/gsmtty* using apps need > > to use "U1234AT+CFUN?" format for the packets. The advantage is > > less kernel code, and we keep the existing /dev/gsmtty* interface. > > Actually... yes, this works. But no, this is not "existing" tty > interface. > > ttys work per character, and this interface definitely does not... it > is "packet" based, write() syscalls need exactly right lengths. You > can't just open minicom, and type "U1234...". You can't paste it, > either (I tried). tty controls like start/stop bits and baud rate are > useless here. CR/LF conversions are unwanted/dangerous because it is > confusing hard to debug if you get them wrong. Yes.. That's what n_gsm spins up. > Now, I don't see reason why this could not be made to work, and it may > be more important to have something in mainline and work with that. So > if you can make this into -next, I'll not complain too loudly. But it > is... still wrong and I liked motmdm* more :-). Yes.. There are issues too with the motmdm* char dev interface too. I don't think it would work as is for devices with network interfaces on some channel, and continuation packets could need more handling possibly. But let's try to get the basics sorted out first and use the "raw" gsmtty* interface. More stuff can always be added later as needed. Regards, Tony
* Pavel Machek <pavel@denx.de> [200430 22:27]: > > > My guess is that at least with the pending ofono patches, we just > > want to use the raw interface for /dev/gsmtty* interface and stop > > pretending we have a modem that is AT compatible. > > I tried to get it to work... it was not fun and I did not get far. OK. Yeah it's now 2020 and still dealing with serial port stuff :) > I pushed my results... > > user@devuan:/my/ofono$ git push > Counting objects: 10, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (10/10), done. > Writing objects: 100% (10/10), 1.17 KiB | 0 bytes/s, done. > Total 10 (delta 8), reused 0 (delta 0) > remote: Resolving deltas: 100% (8/8), completed with 8 local objects. > To github.com:pavelmachek/ofono.git > fd34ca20..9042014b mux-v1.29-1 -> mux-v1.29-1 OK :) I still need to update the ALSA related patches on top of this $subject series. Also what I've noticed is that modprobe n_gsm debug=0xff hex output is currently broken since commit 091cb0994edd ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds"). Reverting the commit fixes it. Stephen, any ideas what should be changed to fix it? Regards, Tony
Hi! > My guess is that at least with the pending ofono patches, we just > want to use the raw interface for /dev/gsmtty* interface and stop > pretending we have a modem that is AT compatible. Ok, so I got ofono back to work. ... I believe. It was not that bad. SMS send/receive and outgoing call start/hangup worked at some point (I did not play with mixers). To github.com:pavelmachek/ofono.git 61d3d727..195760e9 mux-v1.29-1 -> mux-v1.29-1 Best regards, Pavel
Hi! > Now without the chardev support, the /dev/gsmtty* using apps need > to use "U1234AT+CFUN?" format for the packets. The advantage is > less kernel code, and we keep the existing /dev/gsmtty* interface. > > If we still really need the custom chardev support, that can now > be added as needed with the channel specific consumer driver(s). > > My guess is that at least with the pending ofono patches, we just > want to use the raw interface for /dev/gsmtty* interface and stop > pretending we have a modem that is AT compatible. The series: Tested-by: Pavel Machek <pavel@ucw.cz>
* Pavel Machek <pavel@denx.de> [200501 20:20]: > Hi! > > > My guess is that at least with the pending ofono patches, we just > > want to use the raw interface for /dev/gsmtty* interface and stop > > pretending we have a modem that is AT compatible. > > Ok, so I got ofono back to work. ... I believe. It was not that > bad. SMS send/receive and outgoing call start/hangup worked at some > point (I did not play with mixers). > > To github.com:pavelmachek/ofono.git > 61d3d727..195760e9 mux-v1.29-1 -> mux-v1.29-1 OK good to hear and thanks for doing it. Regards, Tony
On Fri 2020-05-01 07:52:52, Tony Lindgren wrote: > * Pavel Machek <pavel@denx.de> [200430 22:27]: > > > > > My guess is that at least with the pending ofono patches, we just > > > want to use the raw interface for /dev/gsmtty* interface and stop > > > pretending we have a modem that is AT compatible. > > > > I tried to get it to work... it was not fun and I did not get far. > > OK. Yeah it's now 2020 and still dealing with serial port stuff :) Yeah, and scary thing is... it is 2020 and serial port is _still_ complex and hard to understand and debug :-). > OK :) I still need to update the ALSA related patches on top > of this $subject series. Let me know when you have these. Pavel