drm request 2
in [Kernel]
|
Prev: gpio: introduce it8761e_gpio driver for IT8761E Super I/O chip
Next: [GIT PATCH] driver core patches for 2.6.33-git
From: Linus Torvalds on 2 Mar 2010 18:10 On Tue, 2 Mar 2010, Linus Torvalds wrote: > > I disabled it in the merge, since I had to fix up that file anyway. But > please don't make me do these so-called "evil merges" where I end up > modifying the thing I merge. Never mind. I've unpulled the whole effin' mess since it doesn't even compile: drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of �nouveau_register_dsm_handler� drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of �nouveau_register_dsm_handler� was here drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of �nouveau_unregister_dsm_handler� drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of �nouveau_unregister_dsm_handler� was here because not only was that VGA_SWITCHEROO Kconfig default the wrong way around, the thing had clearly never ever been tested at all. Why does sh*t like this even make it to me? Was this ever at all in -next? I assume not, since that would have picked up on basic compile failures. Grr. Things like this is what makes me go "Ok, there's always the next merge window, maybe it will have gotten some testing by then". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 2 Mar 2010 18:10 On Tue, 2 Mar 2010, Linus Torvalds wrote: > > It's still code. And if the user didn't ask for it, it should damn well > not be there. And I repeat: unless the feature cures cancer, it's not on by default. Sometimes we split up _old_ features as config options, or do things that are meant to be turned off only for embedded people. THEN we use that whole 'default y' thing, because doing a "make oldconfig" should give you the same configuration you had before. But if it's not an old feature that used to not have a config option at all, and it doesn't cure cancer, you never EVER do "default y". Because when I do "make oldconfig", and I see a "Y" default, it makes me go "I'm not pulling that piece of sh*t". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 2 Mar 2010 18:10 > > x86 after PPC (I think I just validated Ingo). > > Why is VGA_SWITCHEROO enabled by default? because it does nothing on anything except the laptops in question and on those it does nothing except add a control file in debugfs? So how am I supposed to indicate to distro vendors that something should be turned on? If you think that distro kernel maintainers really understand every config option that goes past, I've got a bridge. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 2 Mar 2010 18:20 > > Never mind. I've unpulled the whole effin' mess since it doesn't even > compile: > > drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of �nouveau_register_dsm_handler� > drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of �nouveau_register_dsm_handler� was here > drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of �nouveau_unregister_dsm_handler� > drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of �nouveau_unregister_dsm_handler� was here > > because not only was that VGA_SWITCHEROO Kconfig default the wrong way > around, the thing had clearly never ever been tested at all. > > Why does sh*t like this even make it to me? Was this ever at all in -next? > I assume not, since that would have picked up on basic compile failures. > > Grr. Things like this is what makes me go "Ok, there's always the next > merge window, maybe it will have gotten some testing by then". Linux next didn't pick up this build failure, wierdly neither did the powerpc build I did with this turned off, because ACPI was also off on ppc, it was in linux-next for at least 2 days, and from what I can see that found the ppc problems, it never found the x86 option since it was on by default. I'm going to just rip the nouveau bits out of the patch, btw nouveau is in staging, so you are being a bit OTT, calm down. Dave.
From: Dave Airlie on 2 Mar 2010 18:30
0/3/3 Dave Airlie <airlied(a)linux.ie>: >> >> Never mind. I've unpulled the whole effin' mess since it doesn't even >> compile: >> >> � � � drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of �nouveau_register_dsm_handler� >> � � � drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of �nouveau_register_dsm_handler� was here >> � � � drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of �nouveau_unregister_dsm_handler� >> � � � drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of �nouveau_unregister_dsm_handler� was here >> >> because not only was that VGA_SWITCHEROO Kconfig default the wrong way >> around, the thing had clearly never ever been tested at all. >> >> Why does sh*t like this even make it to me? Was this ever at all in -next? >> I assume not, since that would have picked up on basic compile failures. >> >> Grr. Things like this is what makes me go "Ok, there's always the next >> merge window, maybe it will have gotten some testing by then". > > Linux next didn't pick up this build failure, wierdly neither did the > powerpc build I did with this turned off, because ACPI was also off on > ppc, it was in linux-next for at least 2 days, and from what I can see > that found the ppc problems, it never found the x86 option since it was on > by default. > > I'm going to just rip the nouveau bits out of the patch, btw nouveau is in > staging, so you are being a bit OTT, calm down.\ Anyways sfr just confirmed linux-next doesn't build CONFIG_STAGING drivers so again that wouldn't have helped. So you made us pull nouveau into staging, now you are giving out because staging drivers have issues? In any case I've fixed the default y and the STAGING build in my tree. Did I mention that driver is in STAGING? Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |