pr_debug

[Tobin C. Harding]

On Thu, Mar 16, 2017 at 01:17:42PM +0200, Alexander Kapshuk wrote:
> On Wed, Mar 15, 2017 at 11:15 PM, Tobin C. Harding <me at tobin.cc> wrote:
> > On Wed, Mar 15, 2017 at 12:12:48PM +0100, Bjørn Mork wrote:
> >> Alexander Kapshuk <alexander.kapshuk at gmail.com> writes:
> >>
> >> >>> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding <me at tobin.cc> wrote:
> >> >>> > why does calling pr_debug() with more than one argument cause a sparse
> >> >>> > warning?
> >> >>> >
> >> >>> > drivers/mmc/core/sdio_io.c:70:9: error: unknown field name in initializer
> >> >>> >
> >> >>> > sdio_io.c:70:
> >> >>> > pr_debug("SDIO: Enabling device %s...\n", sdio_func_id(func));
> >> ..
> >> > 'sdio_func_id()' is a macro defined here:
> >> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/include/linux/mmc/sdio_func.h?id=refs/tags/v4.11-rc2
> >> > #define sdio_func_id(f) (dev_name(&(f)->dev))
> >>
> >>
> >> So the "func" in that debug call contains a 'struct device'.  Any
> >> reason why the pr_debug() shouldn't be converted to something like
> >>
> >>  dev_dbg(&func->dev, "SDIO: Enabling device...\n");
> >
> > Good point Bjørn, thanks. And thank you Alexander for your input. I
> > fear I may have sent you both on a wild goose chase with the example
> > that I chose. pr_debug() causes a sparse warning in many instances
> > when the format string includes format specifiers.
> >
> > /* this is fine */
> > pr_debug("some info string");
> >
> > /* this often causes Sparse warning */
> > pr_debug("string with specifier: %d", foo);
> >
> > A simple example can be seen by adding this function
> >
> > void foo(const char *baz)
> > {
> >         pr_debug("cause Sparse warning - %s\n", baz);
> > }
> >
> > To a random driver, and running `make C=2 M=drivers/staging/ks7010`
> >
> > drivers/staging/ks7010/ks_hostif.c:2702:9: error: unknown field name in initializer
> >
> > For more examples from the kernel tree, running:
> > $ make -j9 C=2 M=drivers/staging 2>sparse.out
> >
> > gives many such cases, for example:
> >
> > drivers/staging/fbtft/fbtft-core.c:472:17: error: unknown field name in initialize
> > drivers/staging/media/bcm2048/radio-bcm2048.c:2596:17: error: unknown field name in initializer
> > drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in initializer
> >
> > Also dev_debug causes the same sparse warning at times, for example:
> >
> > drivers/staging/comedi/comedi_fops.c:352:17: error: unknown field name in initialize
> >
> >         if (s->busy) {
> >                 dev_dbg(dev->class_dev,
> >                         "subdevice is busy, cannot resize buffer\n");
> >                 return -EBUSY;
> >         }
> >
> > And 2 more example instances of dev_debug:
> > drivers/staging/comedi/drivers/das16.c:578:25: error: unknown field name in initialize
> > drivers/staging/dgnc/dgnc_tty.c:1274:17: error: unknown field name in initializer
> >
> > thanks,
> > Tobin.
> 
> The pr_debug() manpage, https://www.kernel.org/doc/local/pr_debug.txt,
> states that:
> 
> Some files call pr_debug(), which is ordinarily an empty macro that discards
>     its arguments at compile time.  To enable debugging output, build the
>     appropriate file with -DDEBUG by adding
> 
>       CFLAGS_[filename].o := -DDEBUG
> 
>     to the makefile.
> 
> You did not mention whether you have compiling those modules with the
> DEBUG flag enabled, so, perhaps if you didn't, that could be the
> reason why you've been getting those errors.

Nice suggestion, thanks. I have DEBUG enabled.

thanks,
Tobin.