[PATCH] s1d13xxxfb linkage fix
authorAndrew Morton <akpm@osdl.org>
Wed, 22 Jun 2005 00:16:55 +0000 (17:16 -0700)
committerLinus Torvalds <torvalds@ppc970.osdl.org>
Wed, 22 Jun 2005 02:07:39 +0000 (19:07 -0700)
commit27f931dac93057bbae691f66a49b11ff2f483bee
tree1b7692ed3b9c48048e89fd72bee5f6c45631263d
parente6afbe59710f65d92d00de1f3adb5514ef634110
[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>
drivers/video/s1d13xxxfb.c