Em Thu, 3 Sep 2020 17:07:24 +0300
Andy Shevchenko <andriy.shevche...@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
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
