<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 8, 2017 at 11:48 AM <<a href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 08 Aug 2017 05:36:34 -0000, Amit Kumar said:<br>
<br>
> When I compile arm64/defconfig kernel with W=1, build emits a lot of<br>
> warnings. When patch is required to be "build clean" then why warnings are<br>
> there? I want to understand.<br>
<br>
The warnings that come out with the default W=0 are by an large indicative<br>
of code that's syntactically correct, but probably *do* have unintended<br>
semantics, so those should be fixed up properly.<br>
<br>
The problem with W=1 is that although W=1 will generate a lot of warnings, a<br>
lot of them are things we don't actually want to go out of our way to fix.<br>
That's because W=1 turns on a *lot* of nitpicking "did you really mean to do<br>
that?" warnings - and in kernel code, yes, we often really *did* mean to do<br>
that.<br>
<br>
Now, *some* of them do indeed call for fixing. But make sure that you're<br>
fixing an *actual* problem, where the warning indicates an actual bug. All<br>
too often, we get patches that just shut the warning up, and don't fix a<br>
bug - or even worse, introduce bugs where there weren't any before.<br>
<br>
There's also something to be said for fixing warnings that are in .h files,<br>
because they end up emitting warnings for multiple .c files. A while back,<br>
I submitted a short series of "low hanging fruit" patches against the<br>
drivers/staging/lustre tree - the big win was a one-liner that silenced a<br>
macro in all 231 places it was used. But again - make sure the patch is<br>
an improvement, and not just papering over an issue.<br></blockquote><div> </div><div>Thank you for reply.</div><div><br></div><div>I have noticed that there are mostly missing prototype, variable set but not used, macro related and dtc warning unit not used in device tree.</div><div><br></div><div>As I navigate source, I'll understand which I should hunt for.</div><div><br></div><div>Last but not least, according to your suggestion, I'll hunt these warnings when I create patch. I'll not create patch to get rid of warnings.</div><div><br></div><div> Regards,</div><div>Amit Kumar</div><div><br></div></div></div>