it turns out the tulip driver is a much better driver for the integrated
ali1563 ethernet than the dmfe driver... the dmfe driver gets tx timeouts
every ~15s and can't receive over 5MB/s.  but with the small tulip patch
below i'm seeing 11MB/s+ in both directions without problems.

This patch updates the bmac and mace ethernet drivers so that their
interrupt routines return an irqreturn_t, and updates the bmac driver
to use a spinlock rather than global cli/sti.

        This patch update the Wavelan Pcmcia driver for Wireless
Extensions 16, and also remove all the backward compatibility cruft
that is broken anyway.

        This update the Wavelan ISA driver for Wireless Extension 16
(going with my previous patch).

        This patch for 2.5.68-bk11 will update Wireless Extension to
version 16 :
        o increase bitrate and frequency number for 802.11g/802.11a
        o enhanced iwspy support
        o minor tweaks and cleanups

        This patch is only for the core of WE. The patches for the
individual drivers have been sent to their respective maintainers.
	Compared to the previous version I sent you a few weeks ago,
I've just updated to the latest kernel.

        This patch for 2.5.68-bk11 will fix the irq handler of some
obsolete wireless drivers (wavelan, wavelan_cs and netwave_cs) plus
assorted fixes. All those drivers have been tested on a SMP box.

This cleans up the driver big time and gets rid of a big ugly wart
in setup.c.  Note that I don't have the hardware so this is only
compile-tested.

This patch adds dynamic allocation of request structures. Right now we
are reserving 256 requests per initialized queue, which adds up to quite
a lot of memory for even a modest number of queues. For the quoted 4000
disk systems, it's a disaster.

Instead, we mempool 4 requests per queue and put an upper limit on the
number of requests that we will put in-flight as well. I've kept the 128
read/write max in-flight limit for now. It is trivial to experiement
with larger queue sizes now, but I want to change one thing at the time
(the truncate scenario doesn't look all that good with a huge number of
requests, for instance).

Patch has been in -mm for a while, I'm running it here against stock 2.5
as well. Additionally, it actually kills quite a bit of code as well

Limit deadline hash to 32 entries instead of 1024. This has been benched
and profiled extensively and shows no increased system time.

Also, move "hot" entries to the front of the list.

Resend of the ide-cd buggy debug check removal.

From der.eremit@email.de.

increment bi_sector in bio_endio() so make_request_fn drivers don't
have to do this accounting themselves.

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

into kroah.com:/home/greg/linux/BK/gadget-2.5

into kroah.com:/home/greg/linux/BK/class-2.5

into kroah.com:/home/greg/linux/BK/i2c-2.5

send_sig_info() has been broken since 2.5.60.

The function can be invoked from a the time interrupt (timer_interrpt ->
do_timer -> update_process_times -> -> update_one_process -> (
do_process_times, do_it_prof, do_it_virt ) -> -> send_sig ->
send_sig_info) but it uses spin_unlock_irq instead of the correct
spin_unlock_irqrestore. 

This enables interrupts, and later scheduler_tick() locks runqueue
(without disabling interrupts).  And if we are unlucky, a new interrupt
comes at this point.  And if this interrupt tries to do wake_up() (like
RTC interrupt does), we will deadlock on runqueue lock :-(

The bug was introduced by signal-fixes-2.5.59-A4, which split the
original send_sig_info into two functions, and in one branch it started
using these unsafe spinlock variants (while the "group" variant uses
irqsave/restore correctly). 

Thanks to Jonathan Corbet for pointing this out.

Thanks to Mike Anderson for the idea for this.

into kroah.com:/home/greg/linux/BK/i2c-2.5

Don't provide min/max for in8, which allowed one to scribble on
registers one should not be messing with. (My fault, oops.)

The setting of the temp high/low registers was off by one, not mine this
time.  While I was at it, I reordered a few other register accesses to
be base 0 instead of base 1.

The temp interface was slightly incorrect, degrees * 100 instead of
degrees * 1000, also fixed.

And lastly, when changing the fan count divisor, fix up the min setting
to still be roughly the same. (Previously the meaning of the value in
the register changed, but not the value itself, resulting in, undesired
surprises.)

Ok, after writing up something in the way of a perl script to make some
sense of the data for voltages, and finding that there is no sense to
make, I took a longer look at things.

The it87 driver in 2.5.x is doing some, down right /odd/ math on the
numbers for the in_input* readings, and the 2.4.x driver is doing
something quite different.

And while it might be possible to get sane numbers out of the 2.5.x
driver, people /expect/ to get the numbers that they were getting from
2.4.x.

So this patch puts things back to the simpler calculations done by the
2.4.x lm-sensors drivers, and my script confirms that the numbers come
out right.

This is against my last.

While the old code most definitely did /something/ to the register for
setting the fan div, the 'what' is a more interesting question.

To be honest I could not figure out what it was trying to do, because
the way it was inserting values disagreed with not only the data sheet,
but how it parsed the very same register.

This corrects the issue, and allows one to properly control the divisor
on all 3 fans, including the (much more limited) 3rd fan.

definition.

Add I2C classes for analog and digital cameras, and fix a typo.