pr_debug

DISCUSSION Tobin C. Harding 3 participants 8 messages Mar 15, 2017 – Mar 16, 2017

lore

Share & tools

lore

Tobin C. Harding

author

2017-03-15 08:31 UTC #0 lore raw

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));

What can we do about this?

thanks,
Tobin.

Alexander Kapshuk

2017-03-15 10:01 UTC #1 lore raw

Quoted 10 lines · Tobin C. Harding

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));
What can we do about this?

Quoted 7 lines

thanks,
Tobin.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

What is the version of the sources you are using?

Tobin C. Harding

author

2017-03-15 10:40 UTC #2 lore raw

Quoted 14 lines · Alexander Kapshuk

Quoted 13 lines · Tobin C. Harding
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));
What can we do about this?
thanks,
Tobin.

Quoted 6 lines

Quoted 4 lines
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
What is the version of the sources you are using?

I'm usually working of gregKH's staging tree using branch staging-next and/or staging-testing

thanks,
Tobin.

Alexander Kapshuk

2017-03-15 10:55 UTC #3 lore raw

Quoted 20 lines · Tobin C. Harding

Quoted 19 lines · Alexander Kapshuk
Quoted 17 lines · Tobin C. Harding
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));
What can we do about this?
thanks,
Tobin.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Quoted 7 lines

Quoted 1 line
What is the version of the sources you are using?
I'm usually working of gregKH's staging tree using branch staging-next and/or staging-testing
thanks,
Tobin.

'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))

The 'func' parameter passed into 'sdio_func_id()' is a pointer to 'struct device dev', which is a member of 'struct sdio_func' 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

Based on my understanding of the error message you got, the error must lie in code that initialises 'func' to a field name of a struct that isn't known at compile time.

At this stage, I'm not sure how to identify the code where the faulty initialisation takes place.

Bjørn Mork

2017-03-15 11:12 UTC #4 lore raw

Quoted 8 lines · Alexander Kapshuk

Quoted 8 lines
Quoted 8 lines · Tobin C. Harding
Quoted 7 lines
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));

Quoted 3 lines

'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");

Bj?rn

Tobin C. Harding

author

2017-03-15 21:15 UTC #5 lore raw

Quoted 16 lines · Bj?rn Mork

Quoted 8 lines · Alexander Kapshuk
Quoted 8 lines
Quoted 8 lines · Tobin C. Harding
Quoted 7 lines
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));
..
Quoted 3 lines
'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))

Quoted 4 lines

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.

Alexander Kapshuk

2017-03-16 11:17 UTC #6 lore raw

Quoted 63 lines · Tobin C. Harding

Quoted 16 lines · Bj?rn Mork
Quoted 8 lines · Alexander Kapshuk
Quoted 8 lines
Quoted 8 lines · Tobin C. Harding
Quoted 7 lines
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));
..
Quoted 3 lines
'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))
Quoted 4 lines
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;
        }

Quoted 6 lines

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.

Tobin C. Harding

author

2017-03-16 12:40 UTC #7 lore raw

Quoted 78 lines · Alexander Kapshuk

Quoted 63 lines · Tobin C. Harding
Quoted 16 lines · Bj?rn Mork
Quoted 8 lines · Alexander Kapshuk
Quoted 8 lines
Quoted 8 lines · Tobin C. Harding
Quoted 7 lines
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));
..
Quoted 3 lines
'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))
Quoted 4 lines
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;
        }
Quoted 6 lines
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

Quoted 7 lines

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.