Message ID | 20200821071644.109970-1-lee.jones@linaro.org (mailing list archive) |
---|---|
Headers | show |
Series | Set 2: Rid W=1 warnings in Wireless | expand |
On 2020-08-21 09:16, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > I see that after our discussion about the carl9170 change in this thread following your patch: <https://lkml.org/lkml/2020/8/14/291> you decided the best way to address our requirements, was to "drop" your patch from the series, instead of just implementing the requested changes. :( > There are quite a few W=1 warnings in the Wireless. My plan > is to work through all of them over the next few weeks. > Hopefully it won't be too long before drivers/net/wireless > builds clean with W=1 enabled. Just a parting note for your consideration: Since 5.7 [0], it has become rather easy to also compile the linux kernel with clang and the LLVM Utilities. <https://www.kernel.org/doc/html/latest/kbuild/llvm.html> I hope this information can help you to see beyond that one-unamed "compiler" bias there... I wish you the best of luck in your endeavors. Christian [0] <https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-Kbuild-Easier-LLVM>
On Sat, 22 Aug 2020, Christian Lamparter wrote: > On 2020-08-21 09:16, Lee Jones wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > I see that after our discussion about the carl9170 change in this > thread following your patch: <https://lkml.org/lkml/2020/8/14/291> > > you decided the best way to address our requirements, was to "drop" > your patch from the series, instead of just implementing the requested > changes. :( No, this is "set 2", not "v2". The patch you refer to is in the first set. Looks like I am waiting for your reply [0]: [0] https://lkml.org/lkml/2020/8/18/334 > > There are quite a few W=1 warnings in the Wireless. My plan > > is to work through all of them over the next few weeks. > > Hopefully it won't be too long before drivers/net/wireless > > builds clean with W=1 enabled. > > Just a parting note for your consideration: > > Since 5.7 [0], it has become rather easy to also compile the linux kernel > with clang and the LLVM Utilities. > <https://www.kernel.org/doc/html/latest/kbuild/llvm.html> > > I hope this information can help you to see beyond that one-unamed > "compiler" bias there... I wish you the best of luck in your endeavors. Never used them. GCC has always worked well for me. What are their benefits over GCC? I already build for 5 architectures locally and a great deal more (arch * defconfigs) using remote testing infrastructures. Multiplying them without very good reason sounds like a *potential* waste of already limited computation resources. > Christian > > [0] <https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-Kbuild-Easier-LLVM>
Lee Jones <lee.jones@linaro.org> writes: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > There are quite a few W=1 warnings in the Wireless. My plan > is to work through all of them over the next few weeks. > Hopefully it won't be too long before drivers/net/wireless > builds clean with W=1 enabled. BTW, now the patches are in random order and it's quite annoying to review when there's no logic. Grouping them by the driver would be a lot more pleasent for reviewers.
On Tue, 01 Sep 2020, Kalle Valo wrote: > Lee Jones <lee.jones@linaro.org> writes: > > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > There are quite a few W=1 warnings in the Wireless. My plan > > is to work through all of them over the next few weeks. > > Hopefully it won't be too long before drivers/net/wireless > > builds clean with W=1 enabled. > > BTW, now the patches are in random order and it's quite annoying to > review when there's no logic. Grouping them by the driver would be a lot > more pleasent for reviewers. My script makes a best effort attempt to group changes by file. It takes the first warning presented by the compiler then greps the output for all issues pertaining to that file. I then split the patch by issue (i.e. different patches for; kernel-doc, unused variables, bracketing etc). One issue you might be seeing is the potential for one fixed issue to cause another i.e. when one unused variable is removed which was the only user of another, leading to a subsequent fix of the newly unused variable. Other than that, I'm not sure why they would end up out of order.