Commit 27f931da authored by Andrew Morton's avatar Andrew Morton Committed by Linus Torvalds

[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

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 <>
Cc: Rusty Russell <>
Cc: Greg KH <>
Signed-off-by: default avatarAndrew Morton <>
Signed-off-by: default avatarLinus Torvalds <>
parent e6afbe59
......@@ -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);
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment