[Maverick][SRU] More fallout from 2.6.35.14 update

[Herton R. Krzesinski]

After one report and some automated digging I did, I came up detecting
more problems in 2.6.35.14 update. This is an attempt to avoid
regressions after applying it, before we hit bug reports.

This series contains patches which fixes referenced problems in some of
the commits present in 2.6.35.14

With the exception of the two reverts, all of them are already upstream
patches sent to stable at some point, even those without Cc: stable in
its original changelog:

* (pre-stable) x86, intel, power: Correct the MSR_IA32_ENERGY_PERF_BIAS message
has Cc: stable (with a typo), reported by Julian Wiedmann on the
2.6.35.14 tracking bug, fixes a bug introduced by "x86, intel, power:
Initialize MSR_IA32_ENERGY_PERF_BIAS" in the stable update

* (pre-stable) mm: Fix fixup_user_fault() for MMU=n
As far as I know we don't have any kernel which have CONFIG_MMU=n set,
this fixes a regression with CONFIG_MMU=n
So it's optional to take this one. Doesn't have Cc: stable, but stable
grabbed it and applied on 3.0.2 for example.

* (pre-stable) USB: serial: pl2303: rm duplicate id
This fixes a regression, Cc: stable

I Added pre-stable to these patches, but I don't know if they will come
through another 2.6.35 update, or if we will have another 2.6.35 update.
I guess these, if applied, will not require verification, since they are
stable material?

Besides them, I added two reverts related to a single regression,
instead of backporting a fix upstream:
Revert "xen: Use IRQF_FORCE_RESUME"
Revert "genirq: Add IRQF_FORCE_RESUME"
For the reverted patches, which introduces a regression
(http://bugs.launchpad.net/bugs/898139), I did not apply the upstream
fix "genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier".
I chose to revert them, because the upstream fix didn't apply cleanly,
it seems to require a similar backport as already applied on 2.6.32
stable series, but I didn't want to take a risky approach (the backport
isn't straightforward it seems), so I reverted them. May be Stefan wants
to take a look at this one.

Also since these are just related to the 2.6.35.14 update, not an SRU
per se, the BugLinks on them point to the 2.6.35.14 tracking bug. Should
a new bug be opened with an SRU Justification, or is this ok?

-- 
[]'s
Herton