summaryrefslogtreecommitdiffstats
path: root/include/linux/serial_8250.h
Commit message (Collapse)AuthorAgeFilesLines
* [PATCH] Exar quad port serialPaul B Schroeder2006-12-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | This is on our "Envoy" boxes which we have, according to the documentation, an "Exar ST16C554/554D Quad UART with 16-byte Fifo's". The box also has two other "on-board" serial ports and a modem chip. The two on-board serial UARTs were being detected along with the first two Exar UARTs. The last two Exar UARTs were not showing up and neither was the modem. This patch was the only way I could the kernel to see beyond the standard four serial ports and get all four of the Exar UARTs to show up. [akpm@osdl.org: build fix] Signed-off-by: Paul B Schroeder <pschroeder@uplogix.com> Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [ARM] 3383/3: ixp2000: ixdp2x01 platform serial conversionLennert Buytenhek2006-03-251-0/+1
| | | | | | | | | | | Patch from Lennert Buytenhek Add a PLAT8250_DEV_PLATFORM2, and convert the two ixdp2x01 CPLD serial ports to use platform serial devices with ids PLAT8250_DEV_PLATFORM[12]. (The on-chip xscale UART is PLAT8250_DEV_PLATFORM, id #0.) Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [SERIAL] Make uart_port flags a bitwise typeRussell King2006-01-211-1/+1
| | | | | | | | | | Same reasoning as commit 747c8a55946ed037bf7d62454c3c599c02af2262 but this time we're making uart_port flags a bitwise type - not all of these flags correspond with the old ASYNC_ flags, so there is the possibility for bugs if the wrong ASYNC_* constants are used. Always use UPF_* constants for uart_port->flags. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [SERIAL] Support Au1x00 8250 UARTs using the generic 8250 driver.Pantelis Antoniou2005-11-061-0/+1
| | | | | | | | The offsets of the registers are in a different place, and some parts cannot handle a full set of modem control signals. Signed-off-by: Pantelis Antoniou <pantelis@embeddedalley.ocm> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Create platform_device.h to contain all the platform device details.Russell King2005-10-291-1/+1
| | | | | | | | Convert everyone who uses platform_bus_type to include linux/platform_device.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
* [SERIAL] Use an enum for serial8250 platform device IDsRussell King2005-09-081-0/+15
| | | | | | | | Rather than hard-coding the platform device IDs, enumerate them. We don't particularly care about the actual ID we get, just as long as they're unique. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [SERIAL] Move serial8250_*_port prototypes to linux/serial_8250.hRussell King2005-09-011-0/+16
| | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] Serial: Split 8250 port tableRussell King2005-06-271-0/+1
| | | | | | | | | | | | | | Add separate files for the different 8250 ISA-based serial boards. Looking across all the various architectures, it seems reasonable that we can key the availability of the configuration options for these beasts to the bus-related symbols (iow, CONFIG_ISA). We also standardise the base baud/uart clock rate for these boards - I'm sure that isn't architecture specific, but is solely dependent on the crystal fitted on the board (which should be the same no matter what type of machine its fitted into.) Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-161-0/+28
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!