Hey guys, I really want to kill this thing.

The only way to do that is to actually pass the pt_regs
all the way down from the interrupt source.  It would be
a three step process:

1) Add pt_regs arg to serio_interrupt and serio->dev->interrupt()
   Update all serio->dev drivers and serio_interrupt() invokers.

   I've done this in the patch below.  We must handle pt_regs being
   NULL, f.e. when the event is via a tty ldisc or a timer for which
   there is no "pt_regs" context to obtain.

2) At the input layer, push 'regs' down via input_event() into the
   handlers.

   Patch below does this as well.

3) Final step to complete this, convert USB to pass the pt_regs that
   the host controller interrupt receives down to the URB callbacks.

   This itself was also a multistep process:

	a) pass regs down from generic host controller
	   layer to hcd driver

	b) pass regs from hcd driver into urb handler

	   EHCI is problematic here, as it does the URB
	   work in a tasklet :(  we need to decide whether
	   we can move the normal URB completion back into
	   the hw interrupt handler or not

	   I think it should be done, I'd basically have my
	   thumbs up my butt if I didn't have Alt-SYSRQ-p
	   register dumps available and that is what EHCI+usbkbd
	   is currently.

	   UHCI and OHCI both complete urbs in hw IRQ context
	   so they are just fine.

	c) update urb handlers to take the regs arg, make hcd
	   drivers pass it on in

   I was really bored, so this was also done in the patch below :)

   We get a USB cleanup for free because of this, a lot of people
   were defining their own ugly typedefs for what should be
   usb_complete_t so I fixed that up :-)

   I also caught a lot of usb_fill_*() call sites casting the
   completion function pointer to usb_complete_t so the compiler
   wouldn't help us find necessary fixup if we changed the
   args again :-(  I think I got them all, someone bored should
   grep the tree for usb_complete_t and fixup any remaining spots
   where it is used in a cast.

   I tried to enable as many drivers as possible in a test build
   but it is possible I did miss a few obscure USB configs.

So why do I want to kill kbd_pt_regs so badly?  Well, first of all I
have to walk through all kinds of hoops on sparc64 to update
kbd_pt_regs properly on the USB controller interrupt and I've had
a few cases where I had trouble tracking down some kernel bug
because kbd_pt_regs could easily be inaccurate if another interrupt
came in right after the keyboard USB one.

Right now, kbd_pt_regs is not updated at all for USB keyboards on x86
rendering SYSRQ register dumps non-existent in such configurations.
This forces it to happen, and because the regs are passed in the
context in which the URB completes, it will always be accurate (it
will even work properly if I have 5 USB keyboards :-)

While doing this, I also noticed a bunch of ancient keyboard drivers
in 2.5.x under drivers/char that need to be converted or deleted.
They were still calling handle_scancode() !!! :-)  drivers/tc
has few as well.  There is also a stray handle_scancode() reference
in a include/asm-parisc/keyboard.h comment

I tested this on sparc64 with an OHCI attached USB keyboard,
and register dumping works fine etc.

Here is just the USB bits.

From Pengcheng Zou <pczou@redflag-linux.com>:
>
> Orignally DN_MODIFY is issued on readv while DN_ACCESS is issued on writev,
> which is obviously wrong. This patch fixes such problem.

This is the equivalent patch for 2.5.50+.

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

This fixes the umask/fmask/dmask confusion in vfat.

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]