Big update in stable

[Mike (mwester)]

Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

Yes, but nobody but a couple of developers builds that, so no images
actually use the kernel.  Honestly, developers don't need the fixes
because they're not trying to make the phone work as a phone -- it's the
users who need this, and if we're not going to make these changes
available in the base kernel built and distributed with each image, then
there's really no point, is 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.

Again, the nspy part is but 3 of the entire patchset that got dumped
out.  I think it's rather useful, but if this all it takes to keep it
out, then, fine, remove it.  For goodness sake, it's *DEBUG* code! And
it's a very small part of the entire set of changes!  (Which, I'll note,
were originally packaged at a very fine granularity -- down to the file
level -- for exactly the ability to pick and choose what goes in and
what goes out!)

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

Again, nspy part -- you can't be serious that the flow-control should be
Kconfig?

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

Sorry, there's no other way to do it.  The GTA console code MUST know
that it is suppressed, for reasons I have covered, over -- and over --
and over -- and over again.  We can probably implement some horrible
awful hackery with callbacks and obscure structs so that we can put a
conditional in the console code to prevent the resume race condition
from puking all over the GSM, but a simple extern set/cleared by
neo1973_pm_gsm code is clearly the simple and obvious way to do it.

If this sort of objection is going to prevent the thousands of GTA01's
shipped by Openmoko from working correctly, then this is simply
shortsighted wrongheaded thinking.

Sorry, the GTA01's design was BROKEN and to expect that we can put a
patch together to work around it that can be covertly slipped upstream
under the guise of something generally useful for all S3c24xx users
isn't realistic; OM will have to maintain this patch themselves.

> ~ - 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)

See previous comment.

> 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.

Again, I repeat this because it's the whole point -- to think that Ben
Dooks is going to accept code who's sole function is to work around the
botched GTA01 mux and the broken flow control on the GSM chosen for
these devices.

And honestly, is the resume ordering callback stuff that was added any
less obtrusive?  Not only is it difficult to read and figure out, it
really doesn't do anything to solve any problems.  I have no idea why
that was added, but I would think that the 2 or 3 lines to suppress the
console is no less obtrusive.

> 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.

As you can tell, I'm both extremely busy right now with my real job, and
I'm about out of patience.  I've reworked this stuff several times now,
and repackaged it -- and written dissertations on all of this on my web
site and on this list.  Honestly, it's not that hard to sort out which
patches are debug, which are functional, and which ones we just need to
accept as they are because their ugliness reflects the horrors of the
hardware beneath.

As I said, I'll maintain my own tree for the moment, and be done with
it.  IMO, the problem is that OM has abandoned the GTA01 entirely, and
hasn't run into the problems this stuff will address on the GTA02.  When
that happens, perhaps that's a better time to get the right attention to
this matter.  Or perhaps someone else can re-invent the wheel in a
manner that they prefer.

I grow weary.

> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkhsnTUACgkQOjLpvpq7dMoNAQCeIGEOlHnfXfdznW+By/DbGipH
> LHgAnRppg1YU7BiVMef5Y4jVIuSHnOgz
> =eqqe
> -----END PGP SIGNATURE-----
> 

Regards,
Mike (mwester)