Proposal to send GSM sysfs patches on stable

[Klaus Kurzmann]

* Andy Green <andy at openmoko.com> [090304 09:56]:
> Somebody in the thread at some point said:
> | * Andy Green <andy at openmoko.com> [090302 15:55]:
> |> Somebody in the thread at some point said:
> |> | * Andy Green <andy at openmoko.com> [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.
ok, thanks :-)

> -Andy

Klaus 'mrmoku' Kurzmann