-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
|> didn't (yet) have the patches in the form they should have been. To be |> honest, I was expecting a few go-rounds of discussions and changes |> before they would be committed! Well beauty and functionality are two different things... if we got feedback about functionality of the patches that is very valuable and independent of how we might have to rearrange the code for "beauty" reasons. Since it all remains patches just in "andy" branch we can swap them out for updated versions real easy. |> And there is an organization issue I'd like comments on -- I think if we |> pull the GSM IRQ handler out of mach-gta0x.c and into neo1973_pm_gsm.c, |> it'll clean up some things. Also, perhaps some of this stuff will be |> more palatable if it were enabled via Kconfig. | |> I agree with the general principle on keeping GTA-specific things out of |> the serial driver... but the problem is that issues of one sort or |> another keep dragging me back into that code. Dealing with some of the |> GSM issues and requirements from code outside the serial driver is |> rather like repairing one's roof -- from across the street :-) If there |> are generic ways we can solve problems instead, we should definitely |> explore those ways. The same thing happened in the pcf50xxx drivers, it does not live in its own little world and blobs out all over the place. But the serial driver is already upstream, I just imagine Ben Dooks' head exploding seeing we propose to turn his nice generic s3c24xx serial driver into a GTAxx serial driver. The most we can expect him to accept in there is some function pointer hooks in the platform stuff, maybe any true s3c-specific handshake management functions. (That way if as we suspect it is a 2410 errata issue we can sell that to Ben). It doesn't mean changing the functionality of the patches much, just pouring ALL GTAxx code out from the serial driver into mach-gtaxx.c and having a tunnel into that from upstream stuff via callbacks or variables in platform data. Also the Neospy stuff seems to invade a few places and would be best conditional on a Kconfig option too as you suggested. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkg9BfYACgkQOjLpvpq7dMoJXwCfZ7LDFAh4zJoOjOrDqVjIWgk4 2AEAniDt1gfphMYCyU59j1P700sT3kwq =2h9g -----END PGP SIGNATURE-----
