diff options
author | Andrew Morton <akpm@osdl.org> | 2005-06-21 17:16:55 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-06-21 19:07:39 -0700 |
commit | 27f931dac93057bbae691f66a49b11ff2f483bee (patch) | |
tree | 1b7692ed3b9c48048e89fd72bee5f6c45631263d /drivers/video | |
parent | e6afbe59710f65d92d00de1f3adb5514ef634110 (diff) |
[PATCH] s1d13xxxfb linkage fix
s1d13xxxfb_remove() is referenced from s1d13xxxfb_probe(), which is marked
__devinit(). So s1d13xxxfb_remove() cannot be marked __devexit.
Does this all make sense? Clearly the __devexit section will still be in
core when the __devinit code is run, if the driver was loaded as a module.
But I suppose that if the driver is statically linked, the __devexit section
might be dropped early in boot. Still, we wouldn't drop __devexit prior to
initcall completion, at which point the __devinit code has all been run
anyway.
verdict: this code was legal and made sense. Is this a generic problem, or an
arm-specific problem?
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
`.exit.text' referenced in section `.init.text' of drivers/built-in.o: defined in discarded section `.exit.text' of drivers/built-in.o
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'drivers/video')
-rw-r--r-- | drivers/video/s1d13xxxfb.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c index b637c389e4f..789de13f461 100644 --- a/drivers/video/s1d13xxxfb.c +++ b/drivers/video/s1d13xxxfb.c @@ -493,7 +493,7 @@ s1d13xxxfb_fetch_hw_state(struct fb_info *info) } -static int __devexit +static int s1d13xxxfb_remove(struct device *dev) { struct fb_info *info = dev_get_drvdata(dev); |