From mboxrd@z Thu Jan 1 00:00:00 1970 From: wfelipe@gmail.com (Wilson Felipe) Date: Wed, 22 Jun 2011 09:28:48 +0200 Subject: Is this a Bug? In-Reply-To: References: <7088ABF5-4E3C-4FA6-BFD0-C163251CCB3D@gmail.com> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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 wrote: > On Tue, Jun 21, 2011 at 5:57 PM, Christian Deussen > 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 >