into home.transmeta.com:/home/torvalds/v2.5/linux

into redhat.com:/home/jgarzik/repo/misc-2.5

Badness results.

to declare things on your own!

This implements the mmu stuff for the mmuless cpus - a lot of it stubs
to avoid ifdefs in core code

Basically a nop for MMU based systems

Primarily adds Nvidia + some i845G

Add Zwane
Remove soundmodem stuff
Update snapgear

By Kai Germaschewski:

 "Well, I have another solution, which doesn't need additional Makefile
  magic or anything.

  I just put the module name into each .o file where <linux/module.h> is
  included. Putting it into the section .gnu.linkonce.modname has the effect
  that even for multi-part modules, we only end up with one copy of the
  name.

  Caveat: I'm using the preprocessor macro KBUILD_MODNAME to know what to
  put into .gnu.linkonce.modname. The following used to happen:

  (drivers/isdn/eicon/Makefile)

  divas-objs := common.o Divas_mod.o ...
  eicon-objs := common.o eicon_mod.o ...

  Divas_mod.o is compiled with -DKBUILD_MODNAME=divas
  eicon_mod.o is compiled with -DKBUILD_MODNAME=eicon
  common.o is compiled with -DKBUILD_MODNAME=divas_eicon

  So in the case above, both divas.o and eicon.o would end up with
  a .gnu.linkonce.modname section containing "divas_eicon"

  My fix to this is to not define KBUILD_MODNAME when compiling an object
  whilch will be linked into more than one module - so common.o gets no
  .gnu.linkonce.modname section at all. Works fine here.

  Now, doing this I remove one of the reasons why we would need modules
  linked as '.ko' ;), but it seems much cleaner than generating a temporary
  file, using objcopy etc."

On the v850, the elf toolchain uses a `_' prefix for all user symbols
(I'm not sure why, since most toolchains seem to have dropped this sort
of thing).

The attached patch adds the ability to deal with this, if the macro
MODULE_SYMBOL_PREFIX is defined by <asm/module.h>.  This only affects
places where symbol names come from the user, e.g., EXPORT_SYMBOL, or
the explicit symbol-names used in kernel/module.c itself.

[Tweaked a little by Rusty, original by Miles Bader]

This patch allows the new depmod to generate the USB & PCI hotplug
tables.  Greg Banks and I are (slowly) working on a better solution, but
allows the old-style "modules.pcimap" etc.  to be generated in the short
term.

This patch adds a "__mod_XXX_table" symbol which is an alias to the
module table, rather than a pointer.  This makes it relatively trivial
to extract the table.  Previously, it required a pointer dereference,
which means the relocations must be applied, which is why the old depmod
needs so much of modutils (ie.  it basically links the whole module in
order to find the table).

The old depmod can still be invoked using "-F System.map" to generate
the tables (there'll be lots of other warnings, and it will generate a
completely bogus modules.dep, but the tables should be OK.)

Two fixes.  Firstly, set ALLOC on the right section so we actually
keep the symbol names and don't deref a freed section, and secondly
get the symbol size (more) correct.

From Andrew Morton

into raven.il.steeleye.com:/home/jejb/BK/scsi-for-linus-2.5

Currently, uart_get_divisor() and uart_get_baud_rate() take a tty
structure.  We really want them to take a termios structure so we
can avoid passing a tty structure all  the way down to the low level
drivers.

In order to do this, we need to be able to convert a termios
structure to a numeric baud rate - we provide tty_termios_baud_rate() in
tty_io.c for this purpose.  It performs a subset of the
tty_get_baud_rate() functionality, but without any "alt_speed"
kludge.

We finally export uart_get_baud_rate() and uart_get_divisor() to for
low level drivers to use.  We now have all the functions in place
to support ports which want to have access to the real baud rate
rather than a divisor value.

uart_get_divisor() calculates the divisor for standard uarts, and
will eventually become a helper function for low level port drivers.

This is another step towards moving the divisor calculations into
the low level drivers, thereby allowing the faster baud rates
mentioned in the previous cset.  Moving this field to uart_port
means that the low level drivers do not have to know about the
uart_state structure.

We provide a new function, uart_get_baud_rate(), to return the
desired numeric baud rate from the uart_port and tty structures.
This allows us to:

1. localise the 38400 alternate speed kludge to one area.
2. support faster baud rates than the usual baud_base / desired_rate
   calculations in the future (eventually allowing the use of the
   magic divisors in 8250.c.)

We originally checked for failure by checking if the returned code
was non-zero.  Strictly, it should be a negative value.