into suse.cz:/home/vojtech/bk/pat

by input merge

into 2.5 - kbd0 init, sysrq support, show_regs, show_mem, show_state
support, correct handling of shifts across vt switches, console
blanking, console callback. Hope that's all.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

Talking to Vojtech about nicer config interfaces

highmem enabled, but not otherwise, and was always required).

into osdl.org:/home/mochel/src/kernel/devel/linux-2.5-input

them with the input device class when started up. 

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

   (Noticed by DaveM)

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

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

For some reason, quota.h was derrived from BSD 4 clause code.  Thankfully,
UCB gave permission to remove the advert clause a couple of years ago, so
it's now okay for us to actually distribute this code.  The following patch
updates the header in quota.h.

this eliminates an infinite loop in rpciod if an RPC client's reference
counter accidentally goes negative.  i've been running this under load
since 2.5.30 with no ill effects.

This adds direct write and read from/to the user space to/from the SCSI
adapter.  If something (e.g., too high address) prevents direct
transfer, the existing driver buffer code is used.  The patch contains
functions to map and pin the user buffer pages so that this patch is not
dependent on kiobufs.  Similar functions are already used in sg.c.

into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux

Please import this patch. It updates the Config.help entry (which some
people requested) and cleans up coding a bit. No functional changes.

GCC can only inline functions when the function definition comes before
its use.

Recompute keybit when keycode table changes.
Stricter checks on input keycode/scancode values.

Device interfaces are the logical interfaces of device classes that correlate
directly to userspace interfaces, like device nodes. 

Device interfaces are registered with the class they belong to. As devices
are added to the class, they are added to each interface registered with
the class. The interface is responsible for determining whether the device
supports the interface or not. 

The interface is responsible for allocating and initializing a struct 
intf_data and calling interface_add_data() to add it to the device's list
of interfaces it belongs to. This list will be iterated over when the device
is removed from the class (instead of all possible interfaces for a class).
This structure should probably be embedded in whatever per-device data 
structure the interface is allocating anyway.

Devices are enumerated within the interface. This happens in interface_add_data()
and the enumerated value is stored in the struct intf_data for that device. 

Interfaces get a directory in driverfs under their class's directory. Each
time a device is added to the interface, a symlink is created in that 
directory that points to the device's directory in the physical hierarchy.
The name of this symlink is the interface-enumerated value of the device.

Device classes describe a type (or class) of device, like an input device
or network device, etc. This changeset defines a struct device_class that 
each subsystem is expected to implement and register with the core.

struct device_driver gains a devclass pointer which points to the class it
belongs to. When the driver is registered, it is added to the class's list
of drivers. Whenever a device is bound to that driver, it is added to the
class by calling the class's add_device callback. 

struct device gains a class_num field which is the per-class enumerated value
of the device. It is incremented each time a device is registered with the
class.

Each device class gets a driverfs directory in class/<class name> and two
subdirectories: 'devices' and 'drivers'. For each device added to the class,
a symlink is created in the devices/ directory that points to the device's
directory in the physical hierarchy. The name of the symlink is the enumerated
number the device got when it was registered with the class.

For each driver that's added to the class, a symlink is created in the class's
drivers/ directory that points to the driver's directory. The name of this 
symlink is a concatenation of <bus name>:<driver name> (to prevent namespace
conflicts of drivers with the same name on different buses).
 

as functions interfacing to the input core. PC-Speaker handling is
moved to a separate file. Uinput is moved to a input/misc directory.

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

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

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