Proposal to send GSM sysfs patches on stable

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> 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?
|
| Just another data point that would confirm Qi's behavior as correct:
| kernels that do not set the UART data lines correctly are broken from
| the point-of-view of kexec.
|
| Kexec does not use the bootloader; the rules for kexec require that the
| kernel drivers set everything they need as they initialize because they
| cannot assume anything about the state the hardware had when the kexec
| happened.

Yes no argument about that.  This was what I was saying a few weeks ago
must be our new philosophy about driver init, modular or not, it has to
force whatever it says it is driving to whatever state it's going to
claim the peripheral is in on driver init, at probe time.

| So I guess I am worried that patching Qi to fix this may just defer this
| problem to that time when we see a kexec-based boot-menu appear --
| perhaps we really do need to put a firm boundary on this issue, and
| leave Qi alone.  (And yes, that will cause some problems for other
| distros, but at this point I suspect that the distros that cannot
| back-port this patch into their distro kernels are probably dead, and
| their users are unlikely to switch to Qi in the first place -- and as
| Paul points out, it can also be fixed from user-space... I'm just not
| sure that changing Qi is going to make this better; it's a kernel bug,
| clearly.)

I think the answer that will satisfy everyone for now is to start using
either the kernel version or maybe better an "epoch index" in the unused
(by U-Boot or Qi) entry point field in the header.  Then kernels can
signal their capability or lack of it to the bootloader and its
device-specific code can adapt generally.  Then next time we get one of
these type of issues we can slipstream it in without problems.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmr/HMACgkQOjLpvpq7dMpjJgCcC+cVv5Y89uzpCcIlYaD5lt9D
3eoAoIYM/tpvY/Wqv0E2pKCIIUt4U5Uv
=vJAu
-----END PGP SIGNATURE-----