radix_tree_delete() currently returns 0 on success, -ENOENT if there was
nothing to delete.

But it is more useful to return the address of the deleted item on success
and NULL if there was no matching item.  It can potentially save a
lookup+delete operation.

- allocated storage `envp' was being leaked on an error path

- kmalloc() returns void*, no need to cast it

- don't return 0 from a void-returning function

Greg has acked this patch.

into kernel.bkbits.net:/home/davem/net-2.5

Noted by David Mosberger:

 "If someone happens to arm a periodic timer at exactly 256 jiffies (as
  ohci happens to do on platforms with HZ=1024), then you end up getting
  an endless loop of timer activations, causing a machine hang.

  The problem is that __run_timers updates base->timer_jiffies _before_
  running the callback routines.  If a callback re-arms the timer at
  exactly 256 jiffies, add_timers() will reinsert the timer into the list
  that we're currently processing, which of course will cause the timer to
  expire immediately again, etc., etc., ad naseum... "

The answer here is to move the whole expired list to a local header and
to not look back.

- Convert nodemgr to new driver model.
- Convert to new module_param() calls.
- Merged fixes for devfs mkdir and some sleep-in-atomic fixes from
  mainline 2.5-bk
- Fix possible memory corruption on highlevel local read/write.
- Fix bitmap usage for some bitops.
- Fix bug in closing ISO stream.
- Fixes for nodemgr probing in the event of a reset storm.
- Workaround for nForce2 firewire chipset. This is preliminary.
- Conversion of SBP-2 to use new driver model in nodemgr, including
  providing a driver for firewire unit directories and registering
  proper callbacks.

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

into kroah.com:/home/greg/linux/BK/gregkh-2.5

into kroah.com:/home/greg/linux/BK/i2c-2.5

the driver should not mess with configurations here.

there's no reason this driver should mess with configurations.

Found by Rik van Riel:

 "There's a serious bug in the handling of the pointer returned
  by kmap_atomic() in nfs/dir.c.   The pointer (part of desc) is
  passed into find_dirent_name and from there into dir_decode,
  which modifies the pointer.

  That means you end up passing a wrong address to kunmap_atomic()."

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

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

into kernel.bkbits.net:/home/davem/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

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

If we build >1 DRM driver into the kernel, we get this lovely output..

[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized r128 2.3.0 20021029 on minor 1
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized radeon 1.8.0 20020828 on minor 2
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized mga 3.1.0 20021029 on minor 3
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized i810 1.2.1 20020211 on minor 4
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized i830 1.3.2 20021108 on minor 5

agpgart already outputs the info about the aperture address & size
before drm initialises, so its just repetition for no purpose.

Spotted by Andi Kleen. AMD64 is the architecture, not the CPU.

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

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