aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/vesafb.c
diff options
context:
space:
mode:
authorAndrew Morton <akpm@osdl.org>2005-06-21 17:16:55 -0700
committerLinus Torvalds <torvalds@ppc970.osdl.org>2005-06-21 19:07:39 -0700
commit27f931dac93057bbae691f66a49b11ff2f483bee (patch)
tree1b7692ed3b9c48048e89fd72bee5f6c45631263d /drivers/video/vesafb.c
parent[PATCH] Bring back Tux on Chips 65550 framebuffer (diff)
downloadlinux-dev-27f931dac93057bbae691f66a49b11ff2f483bee.tar.xz
linux-dev-27f931dac93057bbae691f66a49b11ff2f483bee.zip
[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/vesafb.c')
0 files changed, 0 insertions, 0 deletions