This is a bugfix for setkeycode() in /drivers/char/keyboard.c.

If we change a keycode the corresponding bit should be cleared if and
only if this keycode is not defined any longer.  I believe that this
also was intended with the original code, but the implementation is
faulty.

First off all the first three changed lines are obviously erroneus:
oldkey == truekey is false or true, you do not need to inclose this in a
for().  I believe the author intended INPUT_KEYCODE(dev,i) == oldkey.
But fixing this alone is not enough.

If somebody wants to interchange the definition of two keys A and B, the
normal way is to use two setkeycode calls:

    setkeycode (scancode A, keycode B);
    setkeycode (scancode B, keycode A);

The old code does a clearbit(oldkey ..) call even in situations where
two keys have the same definition, and this situation arises commonly in
the situation mentioned above.

Both errors are fixed with this patch.

If somebody uses keyboard scancode set 3 it is necessary to explicitly
program the keyboard to send make/break codes for all keys and to set
autorepeat for all keys.

This is critical for some people.  One example is the LK461/46W series
of keyboards from Digital Equipment Corporations.  These are VMS
keyboards that are also usable on a normal PC.

These keyboards support Scancode Set 2, but for some keys this support
is screwed up -- some function keys (e.g.  F18/F20) report the same
scancode sequence combined with both alt and shift keys. 

Scancode Set 3 works perfectly if all keys are programmed to give
make/break codes. 

A lot of keyboards manufactured by Cherry only make/break for some (not all!)
modifyer keys in scancode set 3 without this fix.

into home.osdl.org:/home/torvalds/v2.5/linux

into home.osdl.org:/home/torvalds/v2.5/linux

This fixes resource conflicts due to IO decode that doesn't show
up with a normal PCI probe (we do similar quirks for most other
chipsets). Without it, the kernel doesn't know about some magic
IO decodes for the chips.

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

This resolves a bug that was recently reported to me by someone
enumerating a USB 1.1 modem through a high speed hub.  I'm a bit
surprised we never saw it before; I think cache/dma timings must
usually be strongly in our favor.

The problem was that the HC was still using the old ep0 maxpacket
value, so when it received an 18 byte device descriptor it would
report a packet overrun and enumeration would fail.  The fix is
straightforward:  invalidate the HC's old endpoint state when we
change the full speed maxpacket size.  (And eventually, we can
remove EHCI and OHCI code coping with usbcore not doing this.)

into kroah.com:/home/greg/linux/BK/usb-2.6

This fixes a problem that showed in usb-storage (osdl bugme 1310)
and could have shown in other drivers that used usb_reset_device()
when they already held dev->serialize:  a self-deadlock with some
devices.

There are some drivers that should likely change so that they grab
this lock themselves, since they don't call this during probe()
when the lock is already held.  The lock protects against config
changes by other tasks, which is currently quite rate.

An earlier patch caused trouble because it effectively removed the
US_FL_FIX_INQUIRY flag for devices with release number higher than
0x5009.  This one might cause problems because it explicitly goes
against the immediately preceding comment in unusual_devs.h.  That
comment says that these Casio digital cameras claim to use the CBI
transport when in fact they only use CB.  However, there have been two
reports in the last few weeks from people getting the "unneeded SubClass
and Protocol" log messages.  One of them was using a device with release
number 0x1000, right at the start of the range.  The other had a device
with release number 0x5010, just beyond the end of the current range.

Maybe Casio is marketing two different devices with different behaviors
but having the same Vendor, Product, and Release values -- I don't know.

its for the Jenoptik JD 5200 z3 Digicam, to enable it to work as a simple
storage device

more or less i took the values for the 0x0d96 vendor in the 2.6.0-test7
usb-storage and mixed them with my device id, which seems to work quite well

tested with 2.4.22 kernel

Patch by me (Ian Abbott).  Removed aliases of FTDI_VID define for
consistency.  Renamed FTDI_PERLE_PID to FTDI_PERLE_ULTRAPORT_PID.
Removed Matrix Orbital and Perle Systems devices from the 8U232AM
device table (but left them in the FT232BM device table) as they
are known to be FT232BM devices.

Scott Allen's patch to add vid/pid support for Perle Systems
UltraPort USB serial converter, merged up with minor whitespace
changes by myself (Ian Abbott).

Please merge this patch.  I've had two success reports from it.
Putback comment can be:

  Fixes some long-standing cdc-acm bugs including:
  - Oopsing
  - Probe messages not so excessive
  - Makes /proc/bus/usb/devices show both interface claims
  - Now cdc_acm won't hotplug for Ethernet devices (or RNDIS)

* ax8817x_set_multicast - use address of dev->data, not contents
* ax8817x_write_async_cmd - free request and urb if submit fails

I'm doing an audit wrt copy_to_user leaking info to userspace, started
with drivers/usb, please apply.

into home.osdl.org:/home/torvalds/v2.5/linux

into jen.americas.sgi.com:/src/lord/bitkeeper/xfs-2.6

SGI Modid: 2.5.x-xfs:slinx:160507a

algorithm in it.  The old algorithm appeared to look for the first
place to put a new data block, and thus a new freespace block (this is
where the 'foundindex' variable came from).  However, new space in a
directory is always added at the lowest file offset as determined by
the extent list.  So this stuff is never used.

I completely ripped out the reminants of the old algorithm, and
(again) moved the freespace block add code inside the conditional
where a data block is added.

SGI Modid: 2.5.x-xfs:slinx:159751a

[XFS] Use an xfs_ino_t to hold the result of inode extraction from a handle, not a possibly 32-bit number

SGI Modid: 2.5.x-xfs:slinx:159943a

SGI Modid: 2.5.x-xfs:slinx:159997a

into home.osdl.org:/home/torvalds/v2.5/linux

If you have a 4gig or greater system, some versions of aacraid firmware
have problems if you set HostPhysMemPages >= 0x100000.  This can
potentially cause data corruption.  If you have 4gig or greater memory,
this patch sets the HostPhysMemPages to something that the firmware can
deal with.

I propose the 2.6.0-test8 two-line patch below to teach
SG_SET_RESERVED_SIZE to reject a negative size, rather than oops-ing.

This patch removes the delay in calling device_del on the sdev struct
device during a surprise removal event. Reference counting functions for
sd's scsi_disk structure where also added to fix issues of unregistering
when a sd is open.

I have tested this patch using scsi_debug with differnt combinations of
adds / removes. I mounted both partitioned and un-partitioned sd disks,
remove the host, and then did a umount. The ref count debug output shows
the objects staying in place prior to the umount and cleaning up once
the umount is called.

This patch fixes an issue with a delayed call of device_del on the
sdev_gendev struct device.
	- Remove the delayed call to device_del.
	- Add kobject to sd scsi_disk structure.
	- Add release function for scsi_disk kobject.
	- Add get / put functions for scsi_disk and calls to these
	  functions.

 drivers/scsi/scsi.c       |    4 --
 drivers/scsi/scsi_sysfs.c |    3 --
 drivers/scsi/sd.c         |   63 ++++++++++++++++++++++++++++++++++++++++------
 3 files changed, 57 insertions(+), 13 deletions(-)

Apparently some laptops (Compaq EVO N620c for one) have something
hidden at IO port range 0x1000, and the 2.4.x default of allocating
IO starting at 0x4000 is safer.

into kernel.bkbits.net:/home/lord/xfs-2.6

It's incorrect for any user of the non-synchronizing irq_disable_nosync().

Cset exclude: torvalds@home.osdl.org|ChangeSet|20031013020955|28777

into home.osdl.org:/home/torvalds/v2.5/linux

I stumbled on a couple trivial bugs in ia64 numa/discontig support.
The first just sets the default number of nodes to something reasonable
for a generic kernel, otherwise it's really easy to start walking over
your initdata (more error checking should probably be added).  The
second fixes a memcpy to a physical address.

Without this patch, if a signal handler tried to access TLS data (via %gs), things break, because the GS descriptor is zero.

To be compatible with i386, we shouldn't be touching the segment descriptors
before getting into signal handlers.

into jen.americas.sgi.com:/src/lord/bitkeeper/xfs-2.6

their NR_IRQ_VECTORS.

	do_tty_hangup() does fput() on redirect struct file too early -
it could've been the only holder of tty_struct we are working with and in
that case we'll end up freeing it from fput() and then both reading and
modifying kfreed memory.

into home.osdl.org:/home/torvalds/v2.5/linux

From: Bjorn Helgaas <bjorn.helgaas@hp.com>

early_serial_setup() doesn't validate the array index, so a caller could
corrupt memory after serial8250_ports[] by supplying a value of port->line
that's too large.

I haven't seen a failure related to this, but it seems fragile to rely on
callers to know how many ports the driver supports.