aboutsummaryrefslogtreecommitdiff
path: root/drivers/serial/8250_early.c
AgeCommit message (Collapse)Author
2008-02-088250_early: coding styleAlan Cox
Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-05serial: fix compile warning about putcYinghai Lu
drivers/serial/8250_early.c:80: warning: conflicting types for built-in function `putc' Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-08-03serial: fix 8250 early console setupDaniel Ritz
the early setup function serial8250_console_early_setup() can be called from non __init code (eg. hotpluggable serial ports like serial_cs) so remove the __init from the call chain to avoid crashes. Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Yinghai Lu <yinghai.lu@sun.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-24Use resource_size_t for serial port IO addressesJosh Boyer
At present, various parts of the serial code use unsigned long to define resource addresses. This is a problem, because some 32-bit platforms have physical addresses larger than 32-bits, and have mmio serial uarts located above the 4GB point. This patch changes the type of mapbase in both struct uart_port and struct plat_serial8250_port to resource_size_t, which can be configured to be 64 bits on such platforms. The mapbase in serial_struct can't safely be changed, because that structure is user visible. Signed-off-by: David Gibson <dwg@au1.ibm.com> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Paul Mackerras <paulus@samba.org> Cc: Jason Wessel <jason.wessel@windriver.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-16serial: convert early_uart to earlycon for 8250Yinghai Lu
Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and include/asm-x86_64/serial.h. the serial8250_ports need to be probed late in serial initializing stage. the console_init=>serial8250_console_init=> register_console=>serial8250_console_setup will return -ENDEV, and console ttyS0 can not be enabled at that time. need to wait till uart_add_one_port in drivers/serial/serial_core.c to call register_console to get console ttyS0. that is too late. Make early_uart to use early_param, so uart console can be used earlier. Make it to be bootconsole with CON_BOOT flag, so can use console handover feature. and it will switch to corresponding normal serial console automatically. new command line will be: console=uart8250,io,0x3f8,9600n8 console=uart8250,mmio,0xff5e0000,115200n8 or earlycon=uart8250,io,0x3f8,9600n8 earlycon=uart8250,mmio,0xff5e0000,115200n8 it will print in very early stage: Early serial console at I/O port 0x3f8 (options '9600n8') console [uart0] enabled later for console it will print: console handover: boot [uart0] -> real [ttyS0] Signed-off-by: <yinghai.lu@sun.com> Cc: Andi Kleen <ak@suse.de> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Gerd Hoffmann <kraxel@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-03-20[SERIAL] kernel console should send CRLF not LFCRRussell King
Glen Turner reported that writing LFCR rather than the more traditional CRLF causes issues with some terminals. Since this aflicts many serial drivers, extract the common code to a library function (uart_console_write) and arrange for each driver to supply a "putchar" function. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-11-03[SERIAL] 8250_early.c passing 0 instead of NULLBen Dooks
Fix sparse warning about passing `0` to simple_strtoul() Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!