public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-media@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] media: atomisp: get rid of -Wsuggest-attribute=format warnings
Date: Thu, 3 Sep 2020 16:27:51 +0200	[thread overview]
Message-ID: <20200903162751.1dd13300@coco.lan> (raw)
In-Reply-To: <20200903140724.GE1891694@smile.fi.intel.com>

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

  reply	other threads:[~2020-09-03 14:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-03 13:57 [PATCH 0/5] address W=1 warnings at staging/media/atomisp Mauro Carvalho Chehab
2020-09-03 13:57 ` [PATCH 1/5] media: atomisp: get rid of some cleanup leftovers Mauro Carvalho Chehab
2020-09-08 10:12   ` Mauro Carvalho Chehab
2020-09-03 13:57 ` [PATCH 2/5] media: atomisp: print a warning if error while setting downscaler Mauro Carvalho Chehab
2020-09-08 10:12   ` Mauro Carvalho Chehab
2020-09-03 13:57 ` [PATCH 3/5] media: atomisp: get rid of unused vars Mauro Carvalho Chehab
2020-09-08 10:12   ` Mauro Carvalho Chehab
2020-09-03 13:57 ` [PATCH 4/5] media: atomisp: move a static constant out of a header file Mauro Carvalho Chehab
2020-09-08 10:12   ` Mauro Carvalho Chehab
2020-09-03 13:57 ` [PATCH 5/5] media: atomisp: get rid of -Wsuggest-attribute=format warnings Mauro Carvalho Chehab
2020-09-03 14:07   ` Andy Shevchenko
2020-09-03 14:27     ` Mauro Carvalho Chehab [this message]
2020-09-03 17:02   ` kernel test robot
2020-09-08 10:12   ` Mauro Carvalho Chehab
2020-09-08 10:12 ` [PATCH 0/5] address W=1 warnings at staging/media/atomisp Mauro Carvalho Chehab
2020-09-08 10:27 ` Mauro Carvalho Chehab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200903162751.1dd13300@coco.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox