Re: easy alsa patches for the stable kernel?

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: easy alsa patches for the stable kernel?
    ... I added it to ALSA HG tree now. ... one be send to the stable-kernel-maintainers in parallel to adding them ... afaics) earlier that way. ... are safe to apply for older kernels. ...
    (Linux-Kernel)
  • Re: easy alsa patches for the stable kernel? (was: Re: hda_intel : Patch + Regression in 2.6.18 -
    ... I added it to ALSA HG tree now. ... one be send to the stable-kernel-maintainers in parallel to adding them ... and that's done now in the stable-series afaics. ... are safe to apply for older kernels. ...
    (Linux-Kernel)
  • Re: [PATCH] delete devfs
    ... been merging patches at a rate of about 10MB/month. ... Andrew would like to see a 2.6 tree which continues to change ... In his vision of the future, the kernel.org kernel will be the most ... keeps the developers happy and gets new code out to users quicker. ...
    (Linux-Kernel)
  • Re: [v4l-dvb-maintainer] [PATCH] media: replace remaining __FUNCT ION__ occurences
    ... I have merged the remaining pending patches into a mercurial tree, ... such a patch, I will try to get to it this week. ... codingstyle / whitespace cleanup, it should appear in a separate patch, ...
    (Linux-Kernel)
  • 2.6.17-mm4
    ... The RAID patches have been dropped due to testing failures in -mm3. ... The SCSI Attached Storage tree has been restored. ... See the `hot-fixes' directory for any important updates to this patchset. ... Fix reject due to git-agpgart.patch. ...
    (Linux-Kernel)