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

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

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

when implementing ethtool media ioctls.

No behavior should change with this patch (except the ethtool media
ioctls now work, of course)

Also, re-format comments to the right of the private struct to line up.

to take 'struct net_device *' not 'long' as their first
argument.  This makes eepro100 compatible with the standard
MII ethtool API, preparing it for that support.

No functional changes should occur with this patch, if anything
changes at all it is a bug.  (and testing shows no changes...)

(kill more e100 compiler warnings)

* PCI write posting fixes, remove pa-specific code
* support 2.5.x kernels (synchronize_irq, cli/sti cleanups)

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

(no change in function).

into samba.org:/home/paulus/kernel/for-linus-ppc

The partition code registers a generic device for disks
which have a dev->driver non-NULL but whose dev->driver->remove
points into outer space.  So when reboot happens --> OOPS
in drivers/base/power.c:device_shutdown()

Ok, amusingly in my case dev->driver == &scsi_done(), hehe :-)

Two cases of uninitialized memory spotted, here is the patch.

(suggested by Donald Becker)

into mandrakesoft.com:/home/jgarzik/repo/net-drivers-2.5

* default to PIO (fixes bugs in some chips), but add CONFIG_xxx option
  for MMIO
* proper support for variable MTU sizes
* add missing unregister_netdev in an error path
(with a kudos to Jason Lunz for merging most of this)

* support bitmapped printk message levels
* don't hand-code ethtool media support, use standard API/lib

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

proc_bus_pci_dir had to be exported for this to work properly.

      
Patch based on work done by Irene Zubarev <zubarev@us.ibm.com>

it might be actively running on another CPU, so we still need to
do the synchronous wait.

I've been working on a userspace daemon to go with my CompactPCI driver,
and yesterday I discovered an oversight in pci_hp_change_slot_info - it
doesn't call dnotify_parent, so dnotify based clients basically don't
work against pcihpfs.  The following patch (against 2.5 BK) reworks
things to just update the mtime (since we're modifying the file after
all), and then call dnotify_parent.

        - Remove mii_preamble_required module parameter (Donald Becker)
        - Add per-interface mii_preamble_required (setting is autodetected)
          (Donald Becker)
        - Remove unnecessary cast from void pointer
        - Re-align comments in private struct

- Remove unused/constant members from struct pci_id_info
  (which then allows removal of 'drv_flags' from private struct)
- If no phy is found, fail to load that board
- Always start phy id scan at id 1 to avoid problems (Donald Becker)
- Autodetect where mii_preable_required is needed,
  default to not needed.  (Donald Becker)

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

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

These are the debated tty_io.c changes to use the session group lists to
maintain controlling tty information.

This is the latest version of the generic pidhash patch.  The biggest
change is the removal of separately allocated pid structures: they are
now part of the task structure and the first task that uses a PID will
provide the pid structure.  Task refcounting is used to avoid the
freeing of the task structure before every member of a process group or
session has exited.

This approach has a number of advantages besides the performance gains.
Besides simplifying the whole hashing code significantly, attach_pid()
is now fundamentally atomic and can be called during create_process()
without worrying about task-list side-effects.  It does not have to
re-search the pidhash to find out about raced PID-adding either, and
attach_pid() cannot fail due to OOM.  detach_pid() can do a simple
put_task_struct() instead of the kmem_cache_free().

The only minimal downside is the potential pending task structures after
session leaders or group leaders have exited - but the number of orphan
sessions and process groups is usually very low - and even if it's
higher, this can be regarded as a slow execution of the final
deallocation of the session leader, not some additional burden.