kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: me@tobin.cc (Tobin C. Harding)
To: kernelnewbies@lists.kernelnewbies.org
Subject: pr_debug
Date: Thu, 16 Mar 2017 23:40:17 +1100	[thread overview]
Message-ID: <20170316124017.GB24260@eros> (raw)
In-Reply-To: <CAJ1xhMVBBEQWx1pjx03qVhM7sdxEgAwc0ZcCkXtA_G3G_+rFyg@mail.gmail.com>

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@tobin.cc> wrote:
> > On Wed, Mar 15, 2017 at 12:12:48PM +0100, Bj?rn Mork wrote:
> >> Alexander Kapshuk <alexander.kapshuk@gmail.com> writes:
> >>
> >> >>> On Wed, Mar 15, 2017 at 10:31 AM, Tobin C. Harding <me@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.

  reply	other threads:[~2017-03-16 12:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-15  8:31 pr_debug Tobin C. Harding
2017-03-15 10:01 ` pr_debug Alexander Kapshuk
2017-03-15 10:40   ` pr_debug Tobin C. Harding
2017-03-15 10:55     ` pr_debug Alexander Kapshuk
2017-03-15 11:12       ` pr_debug Bjørn Mork
2017-03-15 21:15         ` pr_debug Tobin C. Harding
2017-03-16 11:17           ` pr_debug Alexander Kapshuk
2017-03-16 12:40             ` Tobin C. Harding [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-05-10  7:21 pr_debug Tobin Harding
2016-05-10  7:33 ` pr_debug Greg KH
2016-05-10  7:36   ` pr_debug Tobin Harding

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=20170316124017.GB24260@eros \
    --to=me@tobin.cc \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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;
as well as URLs for NNTP newsgroup(s).