Re: easy alsa patches for the stable kernel?

[Takashi Iwai <tiwai@suse.de>]

At Fri, 07 Sep 2007 21:42:36 +0200,
Thorsten Leemhuis wrote:
> 
> On 07.09.2007 14:58, Takashi Iwai wrote:
> > 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.
> 
> Sorry, but why?
> 
> It's just this line afaics...
> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
> ...which afaics is doing nothing more then "if DMI-Data matches FOO then
> apply know workaround BAR". Is that correct or am I missing something
> here (another patch that this one depends on that isn't in 2.6.23 yet
> maybe?)?

The patch is based on the workaround codes that have been added after
2.6.23.  Thus the patch cannot work for 2.6.23 or earlier.

> > 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...)
> 
> Then I as one of all those long-time-lkml-lurkers without programming
> skills dare to say that maybe the alsa-project might need to improve its
> workflow? Maybe you guys should maintain two git-trees (or multiple
> branches in one tree; sorry, I'm not a git expert and not sure what the
> correct terms are)?

We do have different branches, too.  Most fix patches are usually in
the branch to be pushed (although they are rarely done).  But, the
point is that I am no official subsystem maintainer.

I have an access right to add the patches to ALSA HG tree, which is
converted to git tree automatically.  So, eventually, 90% of patches
come from me.  But, the maintenance of git tree and push request are
out of my hand.  It's a frustrating situation to me, too.

> > Another problem I see is that we have little chance for testing the
> > target patches with stable kernels.
> 
> The stable maintainers release "rc" kernels before they release the
> final ones. And the patch of course should have been applied in
> linus-tree. Both things are not a perfect safety net, but I'd say it
> should be more then enough as long as we are talking about new PCI-IDs
> for existing drivers or "apply workarounds for special machines which we
> detect by their DMI data" (lot's of those seems to be needed these days).

I'm skeptical that people ever test stable rc kernels well for certain
bugs.  Also, adding new PCI ID isn't as safe as it sounds (like in
this case).  It must be tested _before_ applying.

> >  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?) 
> 
> Because he bug-reporter is likely only one that invested enough time to
> analized the problem and fix it alone or together with you guys. But
> there is likely a buch of other people that get hit by the same problem;

Well, the problem is how we can find out such unlucky guys...

> some will just say "linux sucks" and switch back to some other OS --
> especially if they never have heard of alsa or don't really know what a
> kernel really is or does.

Linux will suck really if one breaks so-called stable thing easily
without actually testing.  For stable stuff, "it should be good" isn't
enough.  It must be: "it IS good."

Don't get me wrong; I'm for stable patches.  What I'm telling here is
that we have no systematic way to find testers for certain patches on
old kernels.  (Actually, a fix for a core stuff is often much easier
to test.  But a fix specific to a certain hardware is harder to test.)


Takashi