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?)?
If my above analyze is correct (which IMHO is at least correct for some
of all those alsa-patches that get applied) then I'd say: it's worth
applying them to linus-git tree even after the merge-window, as the risk
that something is wrong is small (¹) and the benefit for users is big
enough to be worth the risk, as users get the fix in their hands 60 - 80
days (round about the time a typical devel cycle takes these days
afaics) earlier that way.
60 - 80 days might sound like not that much to some people, but if we
want to make Linux compatible to todays hardware (and not only
yesterdays) we imho can't wait nearly 1/4 of a year (or longer, as it
takes some time until such a fix hits the distributions, but that's
another part of the problem), as a typical market-lifetime of a modern
notebook is often not much longer then a year in total afaics.
(¹) -- sure, typos or stupid side-effects can happen always -- but
that's not enough a reasons to stand still
Nevertheless let me use to use this moment and say: thx for all your
work Takashi!
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)?
E.g. look at how Jeff handles it for libata; he pushes big stuff during
each merge window; after that lots of small updates (new PCI-IDs) and of
course fixes make it to tree quite often (weekly normally afaics,
sometimes more often, sometimes more seldom) until nearly right before
the release of a new Linus-Kernel -- bigger stuff in parallel gets into
another branch, which gets testing in -mm and in parts gets merged
during the next merge-window.
And even better: he pushes small improvements like the PCI-IDs (see
links I gave earlier) to the stable tree as well. That, afaics, happens
in just a few days sometimes; this is how it looks to me from the outside:
- jeff prepares his tree with a patch that for example adds two new
PCI-IDs to a existing driver
- he asks linus to pull it and waits to do that
- some days after linus pulled them jeff pushes the patch to another
git-branch/tree and asks the stable-guys to pull that one, which they do
sooner or later
For alsa it's seems there is only the hg-tree which gets everything
(small and big updates) that has to wait for the next merge-window to
get into the proper kernel (but not into stable). E.g. in the worst case
it might nearly take a half a year until even a small patch gets out to
the users if that patch was made right after a merge window got closed
for a release. That's IMHO way to long.
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).
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;
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.
CU
knurd
-
