- 26 3月, 2006 1 次提交
-
-
由 Bjorn Helgaas 提交于
With the combination of PNPACPI and 8250_pnp, we no longer need 8250_acpi. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 20 3月, 2006 2 次提交
-
-
由 David S. Miller 提交于
So that it will show up as /dev/ttyS0. Otherwise things like installers will try to run on whatever serial port gets probed first. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 David S. Miller 提交于
Since it can do things like BREAK and HUP, we implement this as a serial uart driver. This still needs interrupt probing code, as I haven't figured out how interrupts will work or be probed for on SUN4V yet. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 15 1月, 2006 1 次提交
-
-
由 Patrick Gefre 提交于
Add driver support for a 2 port PCI IOC3-based serial card on Altix boxes: This is a re-submission. On the original submission I was asked to organize the code so that the MIPS ioc3 ethernet and serial parts could be used with this driver. Stanislaw Skowronek was kind enough to provide the shim layer for this - thanks Stanislaw. This patch includes the shim layer and the Altix PCI ioc3 serial driver. The MIPS merged ioc3 ethernet and serial support is forthcoming. Signed-off-by: NPatrick Gefre <pfg@sgi.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 11 1月, 2006 1 次提交
-
-
由 Andrew Victor 提交于
Patch from Andrew Victor This patch adds support to the 2.6 kernel series for the Atmel AT91RM9200 processor. This patch is the Serial driver. This version uses the newly re-written GPL'ed hardware headers. Signed-off-by: NAndrew Victor <andrew@sanpeople.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 09 1月, 2006 1 次提交
-
-
由 Russell King 提交于
EPXA10DB seems to be uncared for: - the "PLD" code has never been merged - no one has reported that this platform has been broken since at least 2.6.10 - interest seems to have dried up around March 2003. Therefore, remove EPXA10DB support. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 06 11月, 2005 1 次提交
-
-
由 Pantelis Antoniou 提交于
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: NPantelis Antoniou <pantelis@embeddedalley.ocm> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 18 7月, 2005 1 次提交
-
-
由 Ben Dooks 提交于
Patch from Ben Dooks Use platform device for the 16500 UARTs in the onboard SuperIO controller. Signed-off-by: NBen Dooks <ben-linux@fluff.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 27 6月, 2005 1 次提交
-
-
由 Russell King 提交于
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: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 22 6月, 2005 1 次提交
-
-
由 Brent Casavant 提交于
The SGI IOC4 I/O controller chip drivers are currently all configured by CONFIG_BLK_DEV_SGIIOC4. This is undesirable as not all IOC4 hardware features are needed by all systems. This patch adds two configuration variables, CONFIG_SGI_IOC4 for core IOC4 driver support (see patch 1/3 in this series for further explanation) and CONFIG_SERIAL_SGI_IOC4 to independently enable serial port support. Signed-off-by: NBrent Casavant <bcasavan@sgi.com> Acked-by: NPat Gefre <pfg@sgi.com> Acked-by: NJeremy Higdon <jeremy@sgi.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus 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!
-