On Fri, 2012-08-17 at 06:22 -0700, Greg KH wrote: > On Fri, Aug 17, 2012 at 09:18:44AM +0200, Daniel Vetter wrote: > > On Fri, Aug 17, 2012 at 1:18 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > > On Tue, Aug 14, 2012 at 01:50:11AM -0400, Gregs git-bot wrote: > > >> commit: 5ab3633d6907018b0b830a720e877c3884d679c3 > > >> From: Hunt Xu <mhuntxu@xxxxxxxxx> > > >> Date: Sun, 1 Jul 2012 03:45:07 +0000 > > >> Subject: drm/i915: make rc6 in sysfs functions conditional > > >> > > >> Commit 0136db586c028f71e7cc21cc183064ff0d5919c8 merges rc6 information > > >> into the power group. However, when compiled with CONFIG_PM not set, > > >> modprobing i915 would taint since power_group_name is defined as NULL. > > >> > > >> This patch makes these rc6 in sysfs functions conditional upon the > > >> definition of the CONFIG_PM macro to avoid the above-mentioned problem. > > >> > > >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45181 > > >> Cc: stable@xxxxxxxxxxxxxxx > > >> Tested-by: Kris Karas <bugs-a12@xxxxxxxxxxxxxxxx> > > >> Signed-off-by: Hunt Xu <mhuntxu@xxxxxxxxx> > > >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > >> --- > > >> drivers/gpu/drm/i915/i915_sysfs.c | 12 ++++++++++++ > > >> 1 files changed, 12 insertions(+), 0 deletions(-) > > > > > > As commit 0136db586c028f71e7cc21cc183064ff0d5919c8 only first showed up > > > in 3.6-rc1, is this patch still needed for the stable tree(s)? > > > > > > My git tag --contains claims it's in 3.5 already. > > Really? > > $ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919c8 > v3.6-rc1~59^2~56^2~76 > > Do you see something else? 'git describe --contains' seems to choose the containing tag whose tree has the shortest path from the given tree-like. So, when some branch has relatively few changes after Linus pulls it for release N and before he pulls it for release N+1 *and* he pulls it later in the merge window for release N+1, commits include in v3.N-rc1 can still be closer to v3.(N+1)-rc1 because the extra merge commits on the path to v3.N-rc1 outweigh the extra non-merge commits on the path to v3.(N+1)-rc1. git certainly doesn't (and shouldn't) know anything about ordering of tag names, but I think that if one of the containing tags is the ancestor of all the others then 'git describe --contains' should prefer to use that. Or at least, there should be some way to request that behaviour. For now, if in doubt, 'git tag --contains' will tell you all the containing tags. Ben. > > And people have reported the regressions to prove it ;-) > > Ok, fair enough, I'll apply it. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure.
Attachment:
signature.asc
Description: This is a digitally signed message part