Re: 3110 robustness fixes (patch)

[Osma Suominen]

On Thu, 6 Mar 2003, Pawel Kot wrote:

> >  static int fb3110_message_type_fold(int type)
> >  {
> >     switch (type) {
> > -   case 0x15:
>
> What is 0x15?

It's one of the three initialization message types from the phone. The
normal init sequence is that the driver sends a 0x15 message with around
20 "magic bytes" that nobody knows the meaning of, the ones captured by
watching NDS or whatever. Then the phone replies with either 0x16
(success) or 0x17 (failure). But there's also the possibility that the
phone sends 0x15 messages in the init sequence, at least according to
the comments in the old driver, so there's a handler for that too even
though it does nothing at present.

So I first decided to fold these three (0x15, 0x16, 0x17) together to
0x16 so that a single sm_block() would catch them all and joined the
three handler functions together.

But then I found out a problem with this, because the fbus-3110 forwards
not only "real" messages but also ack messages to the statemachine and
on to the incoming functions of the driver. What happens is that when
the driver sends out the first 0x15 message and waits for an 0x16, it
almost instantly gets an 0x15 ack, which is folded to 0x16 and thus
breaks the sm_block() loop, and the driver goes on with the init
sequence. It does not wait for the actual reply (0x16 or 0x17) to the
0x15 init message. Thus it sends the following message a bit too early
which sometimes confuses the phone (a race condition).

The easy fix was just to keep 0x15 messages separate from the folding
and that's what I did. The only reason I did it was that I thought it
would be nice to have all init messages taken care of by the same
handler. (And it still does, but there are now two relevant entries in
the incoming functions list so the same function is used for 0x15 and
0x16 (and 0x17, but it never appears because of folding)).

The real fix is to change fbus-3110 so that it actually differentiates
between acks and real messages - at present both are reported as both to
the statemachine (not my code! ;) ). I can't do this right now because
then I would need to do some changes in the statemachine as well and
that has to wait for post-0.5.0. Bozo's recent "fix" in fbus-3110 was a
step in this direction but it also broke the 3110...

The 3110 coding is a real experience in handling chaos ;)
Messy protocol, messy code etc. Hope you enjoy my descriptions of the
mess.

-Osma

-- 
*** Osma Suominen *** address@hidden *** http://www.iki.fi/ozone/ ***