Is this a Bug?

[Wilson Felipe]

you can use the get_maintainer.pl script:

~/linux-2.6 $ ./scripts/get_maintainer.pl -f sound/soc/codecs/wm8958-dsp2.c

it will give you the maintainers names and emails

On Wed, Jun 22, 2011 at 12:49 AM, Greg Freemyer <greg.freemyer at gmail.com> wrote:
> 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
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>