On Tue, 2011-04-19 at 20:11 -0700, Greg KH wrote: > On Wed, Apr 20, 2011 at 03:17:42AM +0100, Ben Hutchings wrote: > > On Tue, 2011-04-19 at 19:01 -0700, Greg KH wrote: > > > On Wed, Apr 20, 2011 at 02:40:53AM +0100, Ben Hutchings wrote: > > > > On Tue, 2011-04-19 at 13:30 -0700, Greg KH wrote: > > > > > 2.6.32-longterm review patch. If anyone has any objections, please > > > > > let us know. > > > > > > > > > > ------------------ > > > > > > > > > > From: Hans Rosenfeld <[email protected]> > > > > > > > > > > commit 9d8888c2a214aece2494a49e699a097c2ba9498b upstream. > > > > > > > > > > Remove check_c1e_idle() and use the new AMD errata checking framework > > > > > instead. > > > > > > > > Clean-up patches are generally not candidates for longterm updates. > > > > > > This was added because a follow-on patch required it. > > > > Ah yes, 'x86, AMD: Set ARAT feature on AMD processors' is using the same > > condition. > > > > Of course, that could have been backported by referring to the function > > that this removes, rather than pulling in a load of other changes with > > consequent risk of regressions. > > I prefer to take original patches for stable, it makes it easier in the > end.
It makes what easier, when? What I see here is a bug fix that is much larger than necessary, with a consequent risk of regression that seems way out of proportion to the benefit. (What actually *is* the benefit of these AMD changes?) And we have had several serious regressions in the 2.6.32.y series recently, so I really don't think we are getting the trade-off right. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
