Fix remaining bits of u32 vs. pm_message confusion. Should not break
anything.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch is for supporting Epson s1d13xxx framebuffer device for m32r. #
Sorry, a little bigger.
The Epson s1d13806 is already supported by 2.6.12 kernel, and its driver is
placed as drivers/video/s1d13xxxfb.c.
For the m32r, a header file include/asm-m32r/s1d13806.h was prepared for
several m32r target platforms. It was originally generated by an Epson
tool S1D13806CFG.EXE, and modified manually for the m32r platforms.
Signed-off-by: Hayato Fujiwara <fujiwara@linux-m32r.org>
Signed-off-by: Hirokazu Takata <takata@linux-m32r.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
