Re: [PATCH] misc/cs5535: Fix section mismatch derived fromcs5535_mfgpt_drv variable

From: Sam Ravnborg
Date: Mon Jan 03 2011 - 15:50:25 EST


On Mon, Jan 03, 2011 at 12:34:31PM -0800, Andres Salomon wrote:
> On Mon, 3 Jan 2011 20:51:31 +0100
> Sam Ravnborg <sam@xxxxxxxxxxxx> wrote:
>
> > On Mon, Jan 03, 2011 at 11:43:10AM -0800, Andrew Morton wrote:
> > > On Mon, 3 Jan 2011 03:51:28 +0100
> > > Sedat Dilek <sedat.dilek@xxxxxxxxxxxxxx> wrote:
> > >
> > > > >From my build.log:
> > > >
> > > > WARNING: drivers/misc/cs5535-mfgpt.o(.data+0x0): Section mismatch
> > > > in reference from the variable cs5535_mfgpt_drv to the
> > > > function .devinit.text:cs5535_mfgpt_probe() The variable
> > > > cs5535_mfgpt_drv references the function __devinit
> > > > cs5535_mfgpt_probe() If the reference is valid then annotate the
> > > > variable with __init* or __refdata (see linux/init.h) or name the
> > > > variable: *driver, *_template, *_timer, *_sht, *_ops, *_probe,
> > > > *_probe_one, *_console,
> > >
> > > Confused. cs5535_mfgpt_probe() _does_ have a name of the form
> > > "*_probe", so why did it warn?
> >
> > The varibale need to follow the naming scheme.
> > In this case the function was named *_probe - which has no
> > significance in the section mismatch checks.
> >
> > > > variable with __init* or __refdata (see linux/init.h) or name the
> > > > variable:
> > ^^^^^^^^
> > ^^^^^^^^^
> >
> > Sam
>
> I see. So it should really be renamed cs5535_mfgpt_driver, or _drv
> added to the whitelist. Or the whitelist dropped, and all drivers
> changed to explicitly mark the structs with __devinitdata.

It is preferred that the variables are annotated __refdata.
>
> It's kind of bizarre that we have variable names signifying whether or
> not warnings get issued..

It really helped to remove a lot of nosie when we introduced this check.

Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/