From: Hugh Dickins <hugh@veritas.com>

This patch removes the long deprecated flush_page_to_ram.  We have
two different schemes for doing this cache flushing stuff, the old
flush_page_to_ram way and the not so old flush_dcache_page etc. way:
see DaveM's Documentation/cachetlb.txt.  Keeping flush_page_to_ram
around is confusing, and makes it harder to get this done right.

All architectures are updated, but the only ones where it amounts
to more than deleting a line or two are m68k, mips, mips64 and v850.

I followed a prescription from DaveM (though not to the letter), that
those arches with non-nop flush_page_to_ram need to do what it did
in their clear_user_page and copy_user_page and flush_dcache_page.

Dave is consterned that, in the v850 nb85e case, this patch leaves its
flush_dcache_page as was, uses it in clear_user_page and copy_user_page,
instead of making them all flush icache as well.  That may be wrong:
I'm just hesitant to add cruft blindly, changing a flush_dcache macro
to flush icache too; and naively hope that the necessary flush_icache
calls are already in place.  Miles, please let us know which way is
right for v850 nb85e - thanks.

I've had a warning in there for 4-5 months and it has never triggered.  I
think it's safe to remove this test.

From: Geert Uytterhoeven <geert@linux-m68k.org>

It updates include/asm-{generic,parisc}/rtc.h for the recent changes in
drivers/char/genrtc.c and include/asm-{m68k,ppc}/rtc.h.

get_rtc_time() now returns some RTC flags instead of a 0/-1 success/failure
indicator.  These flags include:

   - RTC_BATT_BAD: RTC battery is bad (can be detected on PA-RISC)
   - RTC_24H: Clock runs in 24 hour mode

Most of these flags are the same as drivers/char/rtc.c, but RTC_BATT_BAD is a
new one.

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.