Proposal to send GSM sysfs patches on stable

Andy Green andy at
Wed Mar 4 09:55:47 CET 2009

Hash: SHA1

Somebody in the thread at some point said:
| * Andy Green <andy at> [090302 15:55]:
|> Somebody in the thread at some point said:
|> | * Andy Green <andy at> [090302 15:21]:
|> |> Somebody in the thread at some point said:
|> |> | Dear Andy,
|> |> |
|> |> | Andy Green wrote (ao):
|> |> |> Otherwise, they will simply propose people keep using U-Boot and
|> not Qi
|> |> |> as their "fix". To the extent we pull some extra current until
GSM is
|> |> |> turned on, Qi is then compatible with old and new kernels. So
it's the
|> |> |> best path right now AFAICT.
|> |> |
|> |> | Would it be too inconvenient to have a 'correct' Qi and a
|> |> | 'backwards compatible' Qi?
|> |
|> |> It's not inconvenient if it can choose what to do at runtime,
based on a
|> |> sign from the U-Boot header that the kernel it's going to run can cope
|> |> with the right thing.
|> | what does this mean when booting from SD? No u-boot header involved
|> | there, no?
|> There is the same U-Boot header on our kernels no matter where you're
|> booting it from.
|> And it is a fixed-length (64 byte) header.
| So... in the end you decided to just revert it?

Reverting it has made a solution no worse than U-Boot, I got halfway
through a version-checking patch and more urgent things have come up.
So don't worry, I will try to optimize power in those few seconds
between boot and GSM being turned on by initscript for you.

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


More information about the openmoko-kernel mailing list