Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965450AbXIGM6w (ORCPT ); Fri, 7 Sep 2007 08:58:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965280AbXIGM6o (ORCPT ); Fri, 7 Sep 2007 08:58:44 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58389 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965100AbXIGM6o (ORCPT ); Fri, 7 Sep 2007 08:58:44 -0400 Date: Fri, 07 Sep 2007 14:58:41 +0200 Message-ID: From: Takashi Iwai To: Thorsten Leemhuis Cc: Romano Giannetti , Andrew Morton , roger@computer-surgery.co.uk, linux-kernel@vger.kernel.org, perex@suse.cz Subject: Re: easy alsa patches for the stable kernel? (was: Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22) In-Reply-To: <46E13E31.1050409@leemhuis.info> References: <20070822222902.GA28563@computer-surgery.co.uk> <20070905083844.6637da1e.akpm@linux-foundation.org> <20070905091633.87cfaa81.akpm@linux-foundation.org> <1189091390.3212.3.camel@rukbat> <1189115313.7275.5.camel@rukbat> <1189153347.15955.5.camel@rukbat> <46E13E31.1050409@leemhuis.info> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 MULE XEmacs/21.5 (beta28) (fuki) (+CVS-20070806) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3616 Lines: 74 At Fri, 07 Sep 2007 14:04:01 +0200, Thorsten Leemhuis wrote: > > On 07.09.2007 12:21, Takashi Iwai wrote: > > At Fri, 07 Sep 2007 10:22:27 +0200, > > Romano Giannetti wrote: > >> Takashi: good news! > >> > >> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > >> index 3557865..496d119 100644 > >> --- a/sound/pci/hda/patch_realtek.c > >> +++ b/sound/pci/hda/patch_realtek.c > >> @@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = { > >> static struct snd_pci_quirk alc268_cfg_tbl[] = { > >> SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST), > >> SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA), > >> + SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA), > >> SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA), > >> SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER), > >> SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER), > > > > Ah good. I added it to ALSA HG tree now. > > Just wondering: should easy-and-obvious and less-risky patches like this > one be send to the stable-kernel-maintainers in parallel to adding them > to the HG-Tree (or shortly afterwards)? It could safe users lots of > trouble if such improvements make it quickly into production-ready > kernel-releases (and from there they might even find their way into some > distribution kernels quickly). Hardware then would "just work". Well, this patch is defenitely not for 2.6.23 or stable kernel. It's for 2.6.24. > Sure, before the stable-maintainer will take such patches they needs to > be added to linus git-tree beforehand as well. And sure, patches like > the one above are not fixing a regression (at least in this case if I > read the thread correctly; the old subject thus is misleading afaics), > but it's similar to a new PCI-ID that gets added to a existing driver -- > and that's done now in the stable-series afaics (?). > > The alsa-maintainers seem to be in the best position to do this, but it > seems they rarely do it. I for example was hit by a regression (sound > worked in 2.6.20 and broke afterwards; was fixed in 2.6.23-git by the > following patch in case anybody is wondering: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a4eed138add1018846d17e813560b0c7c0ae8e01 > ), but the alsa-developers did not submit it for stable afaics. Sure, I > could do that myself, but as I said: the alsa-maintainers really have > the best overview over the alsa-patches and should know which patches > are safe to apply for older kernels. I occasionally do but sometimes forget. The problem is often that I want first the merge to Linus tree, and then I forget to submit to stable tree when the merge takes long time in the end. (Ther merge of alsa.git is too spotty, and that's another big problem for me. In short, I do NOT maintain alsa.git tree at all...) Another problem I see is that we have little chance for testing the target patches with stable kernels. Even it looks OK and works for the later kernels, it often doesn't work or break magically with the older kernels. Usually, I have no affected hardware, and bug reporters test only with the recent version (partly because developers ask first to try the latest version -- if it works, why to downgrade again?) thanks, Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/