Re: Code from OpenEZX used for Motorola Milestone.
On Mon, 4 Jan 2010 12:49:34 -0800
Erik Gilling wrote:
> On Sun, Dec 27, 2009 at 6:39 AM, Michael 'Mickey' Lauer
> wrote:
> > Am Sonntag, den 27.12.2009, 15:21 +0100 schrieb Antonio Ospite:
> >
> >> Timothy Meade (tmzt) reported that there is some code from OpenEZX[0]
> >> which has been used as a base for the TS 07.10/27.010 mux driver for
> >> Motorola Milestone[1] (which is a GSM Droid, Droid is also addressed
> >> with the codename Sholes, IIUC). You can find some evidence here:
> >>
> >> http://android.git.kernel.org/?p=kernel/omap.git;a=blob;f=drivers/misc/ts27010mux/ts27010_mux.c;h=e95b7c71f43257f835aa65afffe6dec074c442c1;hb=android-omap-2.6.29-eclair
> >
> > Good find. Unfortunately it still looks pretty baseband specific,
> > I would have welcomed a driver that supports the standardized protocols
> > instead.
>
> This driver is almost a complete rewrite of the driver from Motorola.
> That driver had significant code-rot, race conditions, and possible
> buffer overflows. The driver was primarily written to the TS 27.010
> spec. There are a a few bits that are specific to the Motorola
> baseband. Also, flow control was left unimplemented.
>
The driver is indeed way cleaner than the one we use in OpenEZX, and
with some quite limited changes it can be made to work with EZX
platform baseband processor too, see the attached proof-of-concept
patch; basically all it needed were sequence numbers and ACK packets
support, and adjusted dlci-tty mapping. It kind of works but it still
needs some more work.
> >> It would be great if our code and the one from Motorola could be
> >> kept in sync somehow, that would also ease mainline submission a lot
> >> in the long run.
> >
> > You realize this is a pipe dream, right? ;) Oh well, hope dies last.
>
Erik, would you at least accept patches? I also found some small
defects.
If we collaborate on this driver, what should we consider as the
"upstream" repository where to get the latest version of it, on which we
can base our modifications? Is the aforementioned android git repo ok?
I'd also like to discuss the dlci-tty mapping: can we get completely rid
of it assuming an implicit 1:1 mapping? And, how are you opening
channel 0 with the current ts27010mux driver?
Thanks in advance,
Antonio Ospite
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Make ts27010mux driver work with EZX baseband processor
ts27010mux is a TS 07.10/27.010 mux kernel driver for Motorola Milestone
developed by Erik Gilling.
It can be found here:
http://android.git.kernel.org/?p=kernel/omap.git;a=blob;f=drivers/misc/ts27010mux/ts27010_mux.c;h=e95b7c71f43257f835aa65afffe6dec074c442c1;hb=android-omap-2.6.29-eclair
In order to check out the code:
git clone git://android.git.kernel.org/kernel/omap.git
git checkout remotes/origin/android-omap-2.6.29-eclair
ls -l drivers/misc/ts27010mux
This patch adds sequence numbers, ACK packets, and adjusts the dli-tty
mapping to work with the baseband processor used in Motorola EZX
platform.
Antonio Ospite
http://ao2.it
diff -pruN __mux/ts27010mux//ts0710.h drivers/char/ts27010mux//ts0710.h
--- __mux/ts27010mux//ts0710.h 2010-02-14 12:17:25.0 +0100
+++ drivers/char/ts27010mux//ts0710.h 2010-02-20 19:32:42.0 +0100
@@ -53,7 +53,7 @@
#define FLAG_SIZE 2
#define TS0710_MAX_HDR_SIZE 5
-#define DEF_TS0710_MTU 512
+#define DEF_TS0710_MTU 256
#define TS0710_BASIC_FLAG 0xF9
diff -pruN __mux/ts27010mux//ts27010_mux.c drivers/char/ts27010mux//ts27010_mux.c
--- __mux/ts27010mux//ts27010_mux.c 2010-02-17 18:33:44.0 +0100
+++ drivers/char/ts27010mux//ts27010_mux.c 2010-02-20 20:18:06.0 +0100
@@ -94,10 +94,12 @@
#define CMDTAG 0x55
#define DATATAG 0xAA
-static const u8 tty2dlci[NR_MUXS] =
-{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
-static const u8 iscmdtty[NR_MUXS] =
-{ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 };
+#define ACK 0x4F
+
+static const u8 tty2dlci[NR_MUXS+1] =
+{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
+static const u8 iscmdtty[NR_MUXS+1] =
+{ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 };
struct dlci_tty {
const u8 cmdtty;
@@ -105,7 +107,7 @@ struct dlci_tty {
};
static const struct dlci_tty dlci2tty[] = {
- {0, 0}, /* DLCI 0 */
+ //{0, 0}, /* DLCI 0 */
{0, 0},/* DLCI 1 */
{1, 1},/* DLCI 2 */
{2, 2},/* DLCI 3 */
@@ -126,6 +128,7 @@ static const struct dlci_tty dlci2tty[]
enum recv_state {
RECV_STATE_IDLE,
+ RECV_STATE_BP_SLIDE_SEQ,
RECV_STATE_ADDR,
RECV_STATE_CONTROL,
RECV_STATE_LEN,
@@ -247,7 +250,7 @@ static void ts27010_debugstr(const char
static int ts0710_valid_dlci(u8 dlci)
{
- if ((dlci < TS0710_MAX_CHN) && (dlci > 0))
+ if ((dlci < TS0710_MAX_CHN)) /
Kernel/Userspace 07.10 muxer (was Re: Code from OpenEZX used for Motorola Milestone.)
Hi Erik On Mon, Jan 04, 2010 at 12:49:34PM -0800, Erik Gilling wrote: > My personal opinion is that this code doesn't really need to be in the > kernel. In Android's case it could be integrated into the radio interface > layer in user space. Well, the question is if you really can afford that many additional context switches. For a GPRS modem, you can still afford to pipe all the data from the kernel through userspace, back into the kernel and back into userspace. But once you move into the 3G world, I doubt you want the added latency and power consumption that results from a userspace 07.10 multiplexer. Sure, if your baseband has a separate interface for data and you use 07.10 just for signalling / SMS, then it doesn't matter. Regards, Harald -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Re: Code from OpenEZX used for Motorola Milestone.
On Sun, Dec 27, 2009 at 6:39 AM, Michael 'Mickey' Lauer
wrote:
> Am Sonntag, den 27.12.2009, 15:21 +0100 schrieb Antonio Ospite:
>> Timothy Meade (tmzt) reported that there is some code from OpenEZX[0]
>> which has been used as a base for the TS 07.10/27.010 mux driver for
>> Motorola Milestone[1] (which is a GSM Droid, Droid is also addressed
>> with the codename Sholes, IIUC). You can find some evidence here:
>>
>> http://android.git.kernel.org/?p=kernel/omap.git;a=blob;f=drivers/misc/ts27010mux/ts27010_mux.c;h=e95b7c71f43257f835aa65afffe6dec074c442c1;hb=android-omap-2.6.29-eclair
>
> Good find. Unfortunately it still looks pretty baseband specific,
> I would have welcomed a driver that supports the standardized protocols
> instead.
This driver is almost a complete rewrite of the driver from Motorola.
That driver had significant code-rot, race conditions, and possible
buffer overflows. The driver was primarily written to the TS 27.010
spec. There are a a few bits that are specific to the Motorola
baseband. Also, flow control was left unimplemented.
>> The code they used as a base is an old version of "our" mux driver
>> (which, in turn, was based on the one used by Motorola in EZX), which
>> was still using an explicit mapping between DLCIs and TTYs, Ilya Petrov
>> has done a great work simplifying this in our current driver, see:
>>
>> http://git.openezx.org/openezx.git?a=blob;f=drivers/char/ts0710_mux.c;h=e7fbf6df6543d877b3da60c6bbd15cbf17716d29;hb=refs/heads/ezx/current
>
> This looks amazingly clean compared to the previous mess. Is this up and
> running for production code? Which device node is it exported via? I'd
> like to base fsogsmd's Freescale Neptune plugin around this new
> interface.
A quick look through the source gives me concerns about race
conditions. There are no synchronization primitives in the code.
Lines like:
if (st->state == OUT_OF_PACKET) {
st->state = INSIDE_PACKET;
are problematic without synchronization.
Also the code has quite a lot of global state which is generally discouraged.
>> It would be great if our code and the one from Motorola could be
>> kept in sync somehow, that would also ease mainline submission a lot
>> in the long run.
>
> You realize this is a pipe dream, right? ;) Oh well, hope dies last.
The time I'll have to work on our code is highly dependent on which
basebands are chosen for future projects we work on. My personal
opinion is that this code doesn't really need to be in the kernel. In
Android's case it could be integrated into the radio interface layer
in user space. The kernel TTY layer is not well understood and nobody
wants to maintain it. Just take a look at the first line of
Documentation/serial/tty.txt: "Your guide to the ancient and twisted
locking policies of the tty layer and
the warped logic behind them. Beware all ye who read on."
Cheers,
Erik
-Erik
Re: Code from OpenEZX used for Motorola Milestone.
Am Sonntag, den 27.12.2009, 15:21 +0100 schrieb Antonio Ospite: > Timothy Meade (tmzt) reported that there is some code from OpenEZX[0] > which has been used as a base for the TS 07.10/27.010 mux driver for > Motorola Milestone[1] (which is a GSM Droid, Droid is also addressed > with the codename Sholes, IIUC). You can find some evidence here: > > http://android.git.kernel.org/?p=kernel/omap.git;a=blob;f=drivers/misc/ts27010mux/ts27010_mux.c;h=e95b7c71f43257f835aa65afffe6dec074c442c1;hb=android-omap-2.6.29-eclair Good find. Unfortunately it still looks pretty baseband specific, I would have welcomed a driver that supports the standardized protocols instead. > The code they used as a base is an old version of "our" mux driver > (which, in turn, was based on the one used by Motorola in EZX), which > was still using an explicit mapping between DLCIs and TTYs, Ilya Petrov > has done a great work simplifying this in our current driver, see: > > http://git.openezx.org/openezx.git?a=blob;f=drivers/char/ts0710_mux.c;h=e7fbf6df6543d877b3da60c6bbd15cbf17716d29;hb=refs/heads/ezx/current This looks amazingly clean compared to the previous mess. Is this up and running for production code? Which device node is it exported via? I'd like to base fsogsmd's Freescale Neptune plugin around this new interface. > It would be great if our code and the one from Motorola could be > kept in sync somehow, that would also ease mainline submission a lot > in the long run. You realize this is a pipe dream, right? ;) Oh well, hope dies last. Cheers, :M freesmartphone.org
Code from OpenEZX used for Motorola Milestone.
Hi, Timothy Meade (tmzt) reported that there is some code from OpenEZX[0] which has been used as a base for the TS 07.10/27.010 mux driver for Motorola Milestone[1] (which is a GSM Droid, Droid is also addressed with the codename Sholes, IIUC). You can find some evidence here: http://android.git.kernel.org/?p=kernel/omap.git;a=blob;f=drivers/misc/ts27010mux/ts27010_mux.c;h=e95b7c71f43257f835aa65afffe6dec074c442c1;hb=android-omap-2.6.29-eclair You can see that the module author is reported to be Harald Welte, "The Name You Know" (cit.). In order to check out the code: git clone git://android.git.kernel.org/kernel/omap.git git checkout remotes/origin/android-omap-2.6.29-eclair ls -l drivers/misc/ts27010mux The code they used as a base is an old version of "our" mux driver (which, in turn, was based on the one used by Motorola in EZX), which was still using an explicit mapping between DLCIs and TTYs, Ilya Petrov has done a great work simplifying this in our current driver, see: http://git.openezx.org/openezx.git?a=blob;f=drivers/char/ts0710_mux.c;h=e7fbf6df6543d877b3da60c6bbd15cbf17716d29;hb=refs/heads/ezx/current It would be great if our code and the one from Motorola could be kept in sync somehow, that would also ease mainline submission a lot in the long run. I am CCing some of the developers of the Milestone mux driver, taken from git log, to hear some opinion from them. With Kind Regards, Antonio Ospite [0] http://openezx.org [1] http://en.wikipedia.org/wiki/Motorola_Droid -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpImVXqlM1XK.pgp Description: PGP signature
