From: Tony Lindgren <tony@atomide•com>
To: Pavel Machek <pavel@ucw•cz>
Cc: mpartap@gmx•net, merlijn@wizzup•org, sre@kernel•org,
kernel list <linux-kernel@vger•kernel.org>,
nekit1000@gmail•com, ofono@ofono•org, linux-omap@vger•kernel.org,
linux-arm-kernel <linux-arm-kernel@lists•infradead.org>
Subject: Re: Droid 4 modem support in kernel & ofono
Date: Fri, 8 Feb 2019 07:22:24 -0800 [thread overview]
Message-ID: <20190208152224.GG5720@atomide.com> (raw)
In-Reply-To: <20190207221745.GA12219@amd>
* Pavel Machek <pavel@ucw•cz> [190207 22:18]:
> Hi!
>
> > > Ok, so I got calls and smses somehow working in kernel&ofono ... which
> > > is really all I need.
> >
> > Nice :)
> >
> > I think the SIM card reading and writing should be doable
> > using dlci10 /dev/motmdm10 for AT+CRSM calls..
>
> Might be. Sorry, this is outside of my area of interest, because LTE
> would not be on usable frequencies, anyway.
Oh I did not mean LTE, I meant for general SIM access for
ofono for pin codes etc. Anyways, if anybody needs the sim,
it should be available at /dev/motmdm10.
> > > I pushed the tree to git@github•com:pavelmachek/ofono.git , branch
> > > d4... But I had to do some "rather interesting" hacks. D4 modem
> > > expects packets and current kernel drivers rely on write() boundaries
> > > and flush(). .. which is a bit of problem for in ofonod, as it expects
> > > to work with bytestream with no explicit packet boundaries.
> > >
> > > However D4 still uses normal AT commands, so... it would be good to be
> > > able to use AT parsing framework in ofono.
> > >
> > > I believe easiest solution would be to automatically do the packet
> > > splitting in kernel, it should be as easy as splitting on \r and
> > > ^Z. (Currently packets are only generated when \r or ^Z is seen on
> > > write boundary, but that does not work well for ofono).
> >
> > OK yeah it's worth trying. I hit that issue too with the
> > flush needed for droid4-sms-tools scripts. And the traffic
> > we're seeing is minimal and AFAIK there's no network port
> > for ts27010. And SMS messages are PDU encoded anyways.
> >
> > Hmm should we do it for \r\n and \r? Otherwise the \n
> > will be left out of the packet :)
>
> I guess splitting on \n makes sense, yes.
>
> Ofono normally uses just \r. Translating it to \r\n in kernel (ttys
> already do that) would be super nice, but I think this is easy enough
> to handle in ofono.
Do you have some simple test case with printf?
This test case works just fine already:
$ printf "AT+CFUN=1\rAT+SCRN=0\r" > /dev/motmdm1
But maybe the modem behaves in a different way for different
dlci.. So a minimal test case would be good to have :)
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists•infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-02-08 15:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 20:36 Droid 4 modem support in kernel & ofono Pavel Machek
2019-02-01 20:50 ` Tony Lindgren
2019-02-07 22:17 ` Pavel Machek
2019-02-08 15:22 ` Tony Lindgren [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190208152224.GG5720@atomide.com \
--to=tony@atomide$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-omap@vger$(echo .)kernel.org \
--cc=merlijn@wizzup$(echo .)org \
--cc=mpartap@gmx$(echo .)net \
--cc=nekit1000@gmail$(echo .)com \
--cc=ofono@ofono$(echo .)org \
--cc=pavel@ucw$(echo .)cz \
--cc=sre@kernel$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox