From: Andrew Morton Date: Wed, 22 Jun 2005 00:16:55 +0000 (-0700) Subject: [PATCH] s1d13xxxfb linkage fix X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=27f931dac93057bbae691f66a49b11ff2f483bee;p=GitHub%2Fexynos8895%2Fandroid_kernel_samsung_universal8895.git [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 Cc: Rusty Russell Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- diff --git a/drivers/video/s1d13xxxfb.c b/drivers/video/s1d13xxxfb.c index b637c389e4f4..789de13f461f 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);