Is this a Bug?

[Greg Freemyer]

On Tue, Jun 21, 2011 at 5:57 PM, Christian Deussen
<chrisudeussen at googlemail.com> wrote:
>
> Hi,
> I just compiled my first Kernel from linus' tree and saw a warning in
> "sound/soc/codecs/wm8958-dsp2.c".
> I think a found a bug, but I am not sure. And I don`t want to waste the
> Kernel-dev's time on the lkml.
> In function wm8958_dsp2_fw(), at line 64, there is an uninitialized variable
> used.
>
> u32 data 32;
>   ...
>  /*not related code*/
> ...
> if (memcmp(fw->data, "WMFW", 4) != 0) {
> dev_err(codec->dev, "%s: firmware has bad file magic %08x\n",
> name, data32); //shouldn't fw->data be used?
> goto err;
> }
> Am I right? And does this detail matter anyway?
> I made several small fixes for warnings and added some #ifdef CONFIG_BLA
> when code wasnt used. Are those changes welcome on the LKML?
> Thanks for your time.

First, every part of the kernel has a maintainer.  You can look in the
maintainers file to see who it is and which mailinglist to use for the
code in question.

Your find it in the root of your kernel source directory.  Or online
at http://lxr.linux.no/#linux+v2.6.39/MAINTAINERS

So any patches need to go the right maintainer and the right mailing
list.  I for one avoid LKML itself due to the massive traffic.  But I
follow libata and ext4 and a couple others.  That makes the process
reasonable.

Note your email should be to the right list and to the right
maintainer.  Both should be on the TO: line of your email.

As to your question, I think it varies by the maintainer.

If the maintainer is carrying a lot of out of tree patches for the
part of the kernel he maintains, then every time he accepts a patch,
it has the potential to cause those patches to no longer apply.

As an example, the ext4 filesystem currently has dozens or even
hundreds of patches that have been submitted fro review, or which are
in the process of being developed, but which are not yet in the main
kernel.

A proposed patch to fix a compile warning or the code indention, etc.
is likely not welcome on its own.

On the other hand, if you are making a real code change which is an
improvement, then submitting a patch series with the first patch or
two addressing code style issues, etc. at the start of the series
would be welcome.

The reason being any other patches that are going to effect that same
part of the code are going to need to re-based anyway due to the
functional change, so putting in a cosmetic change at the same causes
little extra work in the re-basing process.

Hope that makes sense, even if it doesn't answer your question.

At the end of the day, you might just want to send the maintainer (and
the right list) a email asking if a patch like that is welcome, etc.

Greg