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

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

As requested by Andrew, this moves the hugetlbfs config option
into the Pseudo filesystems section near tmpfs.

Also fix some spelling.

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

Patch from Ivan Kokshaysky

This fixes long standing typo ('size' instead of 'r_size') which causes
overestimate of the bridge memory ranges calculated in pbus_size_mem().
For example, if we have a device with one 1Mb and one 2Mb memory ranges
behind the bridge, calculated size and alignment of the bridge memory
window will be 4Mb and 2Mb respectively, while the correct values are
3Mb and 1Mb.

In an attempt to "unuse" pci_do_scan_bus() so it can be eventually
killed, make pci_scan_bus_parented() call the new pci_scan_child_bus()
and pci_bus_add_devices().  The only remaining callers are the
hotplug drivers.

Eventually, pci_bus_add_devices() will be removed from this function -
it is intended that architectures should call this after they have
done any setups and fixups to the scanned bus.

It is legal to call pci_bus_add_devices() on a bus which has already
had this function called, so architectures could update today.

Pull out the bits of cardbus configuration - the secondary latency
timer, and the number of bus numbers we reserve.

pci_read_config_dword() takes a u32 pointer, not unsigned long.

Miscellaneous cleanups to probe.c:
        - make code/comments wrap before column 80.
        - remove extraneous space.

Kill pcibios_update_resource(), replacing it with pci_update_resource().
pci_update_resource() uses pcibios_resource_to_bus() to convert a
resource to a device BAR - the transformation should be exactly the
same as the transformation used for the PCI bridges.

pci_update_resource "knows" about 64-bit BARs, but doesn't attempt to
set the high 32-bits to anything non-zero - currently no architecture
attempts to do something different.  If anyone cares, please fix; I'm
going to reflect current behaviour for the time being.

Ivan pointed out the following architectures need to examine their
pcibios_update_resource() implementation - they should make sure that
this new implementation does the right thing.  #warning's have been
added where appropriate.

	ia64
	mips
	mips64

This cset also includes a fix for the problem reported by AKPM where
64-bit arch compilers complain about the resource mask being placed
in a u32.

Convert pcibios_fixup_pbus_ranges() into something more generic, namely
pcibios_resource_to_bus() - we are really trying to convert resources
to something to program into bus registers for bridge windows, and in
fact, PCI device BARs.

This is necessary since some architectures, namely Alpha, ARM and PARISC
have an offset between PCI addressing and host-based addressing, so
resources need to be adjusted when read or when written back to the bus.

We provide a generic version in asm-generic/pci.h, which most
architectures use.

This patch finds the following architectures with something to think
consider:

        - ppc, ppc64
                adjusts resources for devices, but not buses.
		This is inconsistent, and leads to improperly
		programmed windows/BARs.

PPC people (Anton) has a replacement PCI resource implementation
which should do the right thing.

Patch from Ivan Kokshaysky

remove the "parent" or "root" second argument to
pcibios_update_resource().  This highlights the following
architectures doing something wrong in their implementation:

        - ia64
        - mips it8172
        - mips "generic mips boards"
        - mips64 "generic mips boards"
        - mips64 IP27

Fix breakage in pci-3 - we scanned all functions if function 0 was not
present.  This causes some host bridges to lock up when scanning devfn
255 on PPC machines.

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

This removes/fixes a few whitespaces and removes the MAX_PRIO setting in
the init task path which is unnecessary and which might even lead to
bugs - MAX_PRIO is outside the valid range and technically the init
thread is not an idle thread yet at this point.

This fixes a fundamental (and long-standing) bug in the sleep-average
estimator which is the root cause of the "contest process_load" problems
reported by Mike Galbraith and Andrew Morton, and which problem is
addressed by Mike's patch.

The bug is the following: the sleep_time code in activate_task()
over-estimates the true sleep time by 0.5 jiffies on average (0.5 msecs
on recent 2.5 kernels).  Furthermore, for highly context-switch
intensive and CPU-intensive workloads it means a constant 1 jiffy
over-estimation.  This turns the balance of giving and removing ticks
and nils the effect of the CPU busy-tick, catapulting the task(s) to
highly interactive status - while in reality they are constantly burning
CPU time.

The fix is to round down sleep_time, not to round it up.  This slightly
under-estimates the sleep time, but this is not a real problem, any task
with a sleep time in the 1 jiffy range will see timekeeping granularity
artifacts from various parts of the kernel anyway.  We could use rdtsc
to estimate the sleep time, but i think that's unnecessary overhead.

The fixups in Mike's scheduler patch (which is in -mm8) basically work
around this bug.  The patch below definitely fixes the contest-load
starvation bug, but it remains to be seen what other effects it has on
interactivity.  In any case, this bug in the estimator is real and if
there's any other interactivity problem around then we need to deal with
it ontop of this patch.

This bug has been in the O(1) scheduler from day 1 on basically, so i'm
quite hopeful that a number of interactivity complaints are fixed by
this patch.

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

Changelog since version 1.68 mark II:
  - merge Mike Anderson's probe() cleanup
     - num_devs is now "per host"
     - num_devs is sysfs writeable
  - add slave_alloc skeleton code

So to simulate 154 disks (for example) one might use:
  # modprobe scsi_debug add_host=11 num_devs=14

With max_luns at its default value of 2, 14 is the
maximum number of devices per host scsi_debug will
respond to (i.e. 7 targets, each with 2 lus).

Documentation updated at:
http://www.torque.net/sg/sdebug25.html

make's line continuation without explicit backslashes is a mystery
to me, and in this case, vmlinux got linked, but the linker command
was not written to the screen. Works again now.

into vaio.(none):/home/kai/kernel/v2.5/linux-2.5.make

into kroah.com:/home/linux/linux/BK/lsm-2.5

No code changes; still builds OK.

This is Robert PJ Day's patch that updates the filesystems
config menu.  It had become a bit ad hoc (jumbled:) and this
patch attempts to arrange it more logically.

This adds the gtk front end by Romain Liévin <roms@tilp.info>

This adds the support for the menuconfig to the front ends.
qconf also has now an ".." entry to make it more obvious
how to get to a parent menu.

This adds the support for the menuconfig keyword, which allows to define
a config symbol and a submenu with a single step, e.g. instead of

	menu "SCSI device support"

	config SCSI
		tristate "SCSI device support"

this is now enough:

	menuconfig SCSI
		tristate "SCSI device support"

A menu entry was possibly inserted to high in the menu hierarchie if
the previous entry was a derived config symbol.

This restores the old config behaviour for dependencies on 'm',
such entries are only activ if CONFIG_MODULES is enabled as well.

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

Register the tty devclass with sysfs before tty drivers initialise -
sysfs requires structures to be registered before use.  This is
required for the previous serial csets, as well as any drivers which
are initialising using __initcall() or module_init().

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

into samba.org:/home/anton/ppc64/for-linus-ppc64

into samba.org:/scratch/anton/linux-2.5_ppc64

into samba.org:/home/anton/ppc64/for-linus-ppc64