From mboxrd@z Thu Jan 1 00:00:00 1970 From: greg.freemyer@gmail.com (Greg Freemyer) Date: Tue, 21 Jun 2011 18:49:36 -0400 Subject: Is this a Bug? In-Reply-To: <7088ABF5-4E3C-4FA6-BFD0-C163251CCB3D@gmail.com> References: <7088ABF5-4E3C-4FA6-BFD0-C163251CCB3D@gmail.com> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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