Big update in stable

Andy Green andy at
Thu Jul 3 11:34:51 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
| Hi folks -
| I brought over a ton of patches that had accumulated in andy branch into
| stable tonight.  Because I had Mike Westerhof's neospy patchset in andy
| but I don't think it belongs in stable, and that patchset is very
| invasive, a lot of patches needed meddling when neospy was removed from
| the picture.  So it's possible there might be some breakage in stable,
| but I built it and it seemed OK, audio worked, bluetooth, was able to
| make a test call, etc.
|> (I'm still hopelessly busy at my real job, but I did find a bit of time
|> to examine this quickly; hopefully I'll have more time to commit to work
|> on stuff starting this weekend.)
|> It looks like more than the neospy stuff got yanked; there's a few
|> vestigial fragments of some of the various changes left (declarations
|> mainly) but nothing that looks like it will change anything from the old
|> behavior.  So from my point of view, the new stable has absolutely no
|> improvements for GSM handling on the GTA01 nor does it have any of the
|> GSM flow-control stuff for both 01 and 02.
|> Is this intended?  If so, what do we need to do to get any improvements
|> into stable?

First I like it and am willing to have it if it is going to lead to
serial stability.  That's why it's in andy branch so anyone can have it
from there.

Second hopefully the patchbomb into stable was the last time we do it
like that.  Stuff can go into stable every day unless there is some
reason we choose to freeze it.  So there is no window missed here.

The issues I have with taking it completely in are

~ - preprocessor based.  It's a bit heavy given how many spy actions
there are.

~ - All or nothing.  It's not in Kconfig, and it's not enabled or
disabled at runtime.  (It needs to be in Kconfig).

~ - forces s3c24xx serial code to know about "gta" (should never appear
in there)

~ - forces s3c24xx serial code to know about gta GSM port index selection
(needs to be an attribute of the port that it needs the GSM style
handling, and that attribute set in the machine init code)

So these things can be fixed, but overall what I am thinking about is
what Ben Dooks would say about what we are doing to s3c24xx serial code,
particularly if "gta" has leaked anywhere it shouldn't.

The stuff in neo1973_pm_gsm.c is skeletons in our closet so it doesn't
matter so much.  But we need to be "gta clean" in platform code, using
callbacks or flag attributes so that we can explain to Ben that we added
cool new support and bugfixes in there that are generic (and there is
some optional instrumentation code in another patch he can take or
leave, and if he takes it the users can Kconfig it out).

So I am hoping you have time to look at these angles because it seems we
need all the help we can get with the deadly handshaking problems.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list