Proposal to send GSM sysfs patches on stable

Andy Green andy at
Mon Mar 2 13:40:10 CET 2009

Hash: SHA1

Somebody in the thread at some point said:

|> These guys need to uplevel to more recent kernels anyway, over time the
|> pressure for them to do so will only increase.  After some time we can
|> go back to Qi doing the right thing and the whole boot sequence will be
|> fine for this issue without workarounds in the rootfs.

| Well... speaking for SHR... I strongly prefer Qi doing the right thing
| and fix our kernel/rootfs instead (which we will do with the next kernel
| build).

It's good to hear, obviously since I found and fixed this problem I
share the desire to not have to rip the fix out again.  But -->

| Maybe a strong notice about this on openmoko-devel ML or on planet would
| be enough? At least people cannot complain about silently breaking
| things then...

I think practically we have to be compatible with old kernels for a
while.  The cost of the compatibility is quite limited in time since the
fault current goes away when GSM is turned on in initscripts; whereas
the cost of incompatibility is a sticky breakage of GSM function.
U-Boot has always "done the wrong thing" with regards to this as well,
so every U-Boot user is experiencing the workaround proposed for Qi already.

I have an idea though, what do you guys do about the U-Boot mkudfu
content?  Is there anything in there we can use to make a decision about
in Qi's GTA02 code as to how to leave the UARTs?  Eg, kernel revision?

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


More information about the openmoko-kernel mailing list