Mauro Carvalho Chehab <[email protected]> writes: > It seems ok to send it to stable for the stable versions that got the > HERM patches (e. g. EDAC core version updated to 3.0.0). Adding it > to older ones would cause regressions. > > In other words, if the following patch exists at -stable, then > I recommend backporting this fix: > > commit 5156a5f4e058b906c1e8c0fe2ab16f30b60dee96 > Author: Mauro Carvalho Chehab <[email protected]> > Date: Thu May 10 12:43:01 2012 -0300 > > edac: Increase version to 3.0.0 > There were lots of changes introduced to justify renaming it to > 3.0.0: > - EDAC core were redesigned to represent all types of > memory controllers; > - EDAC API were redesigned to properly represent the memory > controller hierarchy; > - a tracepoint-based API were added to report memory errors. > Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Didn't you just demonstrate why driver or subsystem version numbers in the mainline kernel are pointless at best, or just confusing if you ever backport any fixes? No matter what you do here, you will always end up wanting to know which kernel version the user is running. That is the version number telling you exactly which set of fixes were applied. The EDAC_VERSION will never tell you that. Just get rid of the private version number. Looks like it's only used to generate log noise anyway. Bjørn -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
