Message ID | cover.1599141140.git.mchehab+huawei@kernel.org |
---|---|
Headers | show |
Series | address W=1 warnings at staging/media/atomisp | expand |
Em Thu, 3 Sep 2020 17:07:24 +0300 Andy Shevchenko <andriy.shevchenko@linux.intel.com> escreveu: > On Thu, Sep 03, 2020 at 03:57:32PM +0200, Mauro Carvalho Chehab wrote: > > There are some warnings reported by gcc: > > drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:164:2: warning: function ‘atomisp_css2_dbg_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] > > drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:170:2: warning: function ‘atomisp_css2_dbg_ftrace_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] > > drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:170:2: warning: function ‘atomisp_css2_dbg_ftrace_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] > > drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:176:2: warning: function ‘atomisp_css2_err_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] > > > > That are due to the usage of printf-like messages without > > enabling the error checking logic. > > > > Add the proper attributes in order to shut up such warnings. > > > +static int __attribute__((format (printf, 1, 0))) > > +atomisp_css2_dbg_ftrace_print(const char *fmt, va_list args) > > { > > ftrace_vprintk(fmt, args); > > return 0; > > } > > > > Why not to drop it completely as well? Because of this: make -s CC="gcc -fno-diagnostics-show-caret" CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y W=1 M=drivers/staging/media/atomisp/ 2>&1|grep -v ": In function ‘" drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:858:52: error: ‘ftrace_vprintk’ undeclared (first use in this function); did you mean ‘tracepoint’? drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:858:52: note: each undeclared identifier is reported only once for each function it appears in Basically, kernel.h defines it as a macro: #define ftrace_vprintk(fmt, vargs) \ do { \ if (__builtin_constant_p(fmt)) { \ static const char *trace_printk_fmt __used \ __attribute__((section("__trace_printk_fmt"))) = \ __builtin_constant_p(fmt) ? fmt : NULL; \ \ __ftrace_vbprintk(_THIS_IP_, trace_printk_fmt, vargs); \ } else \ __ftrace_vprintk(_THIS_IP_, fmt, vargs); \ } while (0) Now, a different thing would be to get rid of using trace as a debug mechanism. Right now, I don't have any strong opinion, but I guess that, while this driver is still at staging, it sounds good to be able of using traces instead of dmesg for debugging purposes, but to be honest, I didn't test yet to use ftrace for such purpose. Thanks, Mauro
Hi Greg, Em Tue, 8 Sep 2020 12:12:21 +0200 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu: > The linux-media policy is to have zero warnings with W=1. However, when > I started using a Jenkins instance at https://builder.linuxtv.org to automate > such tests, I didn't notice that a bug at the scripts were just ignoring > warnings. Please ignore this patch series. It was sent by mistake instead of a completely unrelated one. This was already merged via the media tree. Thanks, Mauro