linux-kernel - Re: easy alsa patches for the stable kernel? (was: Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5hy7fi4oou.wl%tiwai@suse.de>
Date:	Fri, 07 Sep 2007 14:58:41 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Thorsten Leemhuis <fedora@...mhuis.info>
Cc:	Romano Giannetti <romano@....icai.upcomillas.es>,
	Andrew Morton <akpm@...ux-foundation.org>,
	roger@...puter-surgery.co.uk, linux-kernel@...r.kernel.org,
	perex@...e.cz
Subject: Re: easy alsa patches for the stable kernel? (was: Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22)

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/