This solves lots of races when drivers hold a reference to the usb_device
after the device is physically removed from the system (like when a user
has a open handle.)  This now prevents any new urbs being submitted or
canceled for the device.

Grab bag of minor cleanups.

It's usually considered stupid to stuff-up like this. However,
for this once we'll just call it "inspired".

Use the kernel CRC routines rather than a do-it-yourself version.
By the way, I created a common USB Makefile.lib, rather than having
one for the class drivers, and one for speedtouch.

This patch updates the 2.5 ov511 driver to version 1.64. This fixes some
longstanding bugs and cleans the code up a bit.

Changes:
 - Eliminate remaining uses of sleep_on()
 - Remove unnecessary (and racy) calls to waitqueue_active()
 - Fix a memory leak in the open() error path
 - Remove some redundant and unused variables
 - Documentation fixes

This resolves a problem caused by "reboot" not actually
doing a clean shutdown of drivers.  It uses a reboot
notifier to make sure that typical BIOS code (using the
USB 1.1 companion controllers) will see keyboards even
without an EHCI driver being active.

An error check would wrongly fire after usb_sg_cancel().
This patch prevents the misfire, and also makes the
diagnostic (a) more useful, (b) less scarey.

Here are some trivial help texts for drivers/usb/serial/Kconfig.

Add some comments and debug info.

Differences: speedtouch 330 vs the older speedtouch USB:
Vendor and ProdID: no difference (!)
Rev: 2.00 vs 0.00
SerialNumber: 0090D0xxxxxx, xxxxxx larger for 330
Interface 1, Alt 2:
	E: Ad=06(O) Atr=02(Bulk) MxPS=64 Ivl=0ms
	E: Ad=07(O) Atr=02(Bulk) MxPS=64 Ivl=0ms
	E: Ad=87(I) Atr=01(Isoc) MxPS=640 Ivl=1ms
vs
	E: Ad=06(O) Atr=02(Bulk) MxPS=32 Ivl=0ms
	E: Ad=07(O) Atr=02(Bulk) MxPS=32 Ivl=0ms
	E: Ad=87(I) Atr=02(Bulk) MxPS=64 Ivl=0ms
Interface 1, Alt 3:
	E: Ad=06(O) Atr=02(Bulk) MxPS=64 Ivl=0ms
	E: Ad=07(O) Atr=02(Bulk) MxPS=64 Ivl=0ms
	E: Ad=87(I) Atr=01(Isoc) MxPS=960 Ivl=1ms
vs
	E: Ad=06(O) Atr=02(Bulk) MxPS=16 Ivl=0ms
	E: Ad=07(O) Atr=02(Bulk) MxPS=16 Ivl=0ms
	E: Ad=87(I) Atr=02(Bulk) MxPS=64 Ivl=0ms
The current driver works with the speedtouch 330 as long as we use alternate setting
1 on interface 1 rather than alternate 2 as we do now.  In fact it makes sense to use
alternate 1 for the speedtouch USB as well: the difference is in the max packet size
for the out bulk endpoint (0x07): 64 for Alt 1, 32 for Alt 2.  Since we send only
multiples of 53 bytes (ATM cell size), the potential lower latency for Alt 2 is not
really exploitable (think about it!).  My tests indicate no harm and perhaps a slight
gain by using Alt 1.  The manufacturer seems to think so too, since they chose to
keep the Alt 1 setting and threw out Alt 2 when designing the 330.  So just use Alt 1
for both modems.

Instead of trying to close all ATM connections in the USB disconnect routine,
just notify the ATM layer that the ATM device should go down when the last
connection is closed.  This should be the last big speedtouch stability fix.

The disconnect routine counts the completed_receivers/spare_senders list
to see if the completion handler has finished.  It then kills the tasklet.
However the tasklet was being scheduled after adding to the lists, creating
a micro race.  So schedule the tasklet before adding to the list.

Let's not forget to update the ATM transmission statistics!  And
let's not pretend to support AAL0 when we don't.

Eliminate a pile of code that isn't used anymore now the new send code
is in place, and make some cosmetic changes.

Finally, here is the new code for sending packets.  The ATM layer passes us a skb
containing the packet to be sent.  We need to encode that as AAL5, and then encapsulate
the result in a series of ATM cells.  Finally, the result has to be sent to the modem.
When we have finished with the skb, we need to pass it back to the ATM layer.

The old code did this as follows: (1) Try to do the AAL5 encoding in place in the skb.
This fattens the packet, so there is not always enough room.  Thus sometimes a new skb
is allocated.  (2) Try to form the frame of ATM cells in place.  This also fattens the
packet, so sometimes another skb is allocated here too.  (3) send the urb, using the
skb as buffer.

The main problems with this are: (1) in the urb completion handler, we need to pass
the skb back to the ATM layer, or free it ourselves if we allocated a new one.  The
driver was pretty confused about which to do.  Also, error conditions were not
always handled right.  (2) if the ATM layer wants to close the VCC (connection),
any urbs in flight using skbs from that VCC need to be shot down, otherwise the
skb may be returned to a VCC that no longer exists when the urb completes.  You
have to be careful to shoot down the right urb (beware of resubmission), and deal
with failures of usb_unlink_urb.  (3) There may need to be several memory allocations.

The new code sidesteps all this by (1) not sending the skb off with the urb, and
(2) not reallocating the skb at all.  It simply has a couple of buffers of fixed
size: the encoded and encapsulated content of the skb is placed in a buffer.  The
skb is sent back down to the ATM layer and the buffer is sent off with the urb.
Et voila, as they say around here.

Now for the complicating factors: (1) if there are no spare buffers, the incoming
skb needs to be queued (this was already the case if there were no free urbs).  If
the VCC is closed, the skbs from that VCC need to be removed from the queue.  This
is trivial and is done in udsl_usb_cancelsends.  (2) The skbs can be quite big.  In
practice, with the default configuration for pppd, they contain at most 1502 bytes.
However pppd can be configured to send up to 16k packets, and who says everyone
is using pppd? - the ATM layer allows up to 64k packets.  So how big should the
buffers be?  Not 64k, that's for sure - I've set them to about 6k (128 ATM cells).
So there needs to be a way to encode/encapsulate and transfer only part of the skb's
payload into a buffer.  This is done by udsl_write_cell, which extracts one ATM
cell from the skb.  The data needed is precalculated by udsl_groom_skb and stored
in the skb's cb field.  This also means that if there is only a little room left
in a buffer, it can still be filled by extracting part of a skb.  A nice consequence
is that under heavy load (many packets being sent), the driver starts streaming the
data to the USB subsystem: every time a send urb completes, there is a completely
filled buffer waiting to be sent, so not only is the time between urb completion and
resubmission essentially zero, but the amount of data sent in each USB transaction is
as big as possible, each buffer containing the contents of several skbs (typically 4).

And the best thing is: it actually works!

Add a new encoding routine, udsl_write_cell, which extracts one ATM cell from a skb
and writes it, doing the AAL5/ATM encoding on the fly.  To make this possible, various
bits of info about the AAL5/ATM structure need to be stored beforehand in the skb.
This is done by udsl_groom_skb using the udsl_control structure introduced in the
previous patch.

Add a new structure, udsl_control.  It will live in the sk_buff cb field,
so check there is room for it and bail out during module init if not.

Expose some CRC definitions in atmsar.h (for use by speedtouch.c).

Put in infrastructure for the new send code.  The only code changes are in the
udsl_usb_probe and udsl_usb_disconnect functions, changed to initialize/finalize the
new fields (plus cleaned up a bit).  I couldn't resist a real code change while I was
there: freeing the memory used by the ATM after shutting it down, rather than before!
This doesn't make any difference since the shutdown routine doesn't work - so it still
oopses.  I will fix the shutdown routine later.

Measure the receive buffer size in ATM cells (53 bytes).

Rename UDSL_RECEIVE_BUFFER_SIZE to UDSL_RCV_BUFFER_SIZE.

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

Remove unneeded function declarations and correct /proc-directory name
for > 1 pcmcia_socket_class devices.

here's the compile fix for this breakage which appears if CONFIG_ACPI &&
!(CONFIG_CPU_FREQ_TABLE || CONFIG_CPU_FREQ_TABLE_MODULE).

This morning's fix for elv_former_request() is causing oopses all over the
place in the IO scheduler.

Jens, remember that I did try that fix a while ago, and the same happened.

I believe it has exposed a new problem at the __make_request/attempt_front_merge
level: if attempt_front_merge() actually succeeds, the wrong request gets freed
up in elv_merged_request().

It may be best to back this change out until it can be fixed up for real.

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

into tp1.ruhr-uni-bochum.de:/scratch/kai/kernel/v2.5/linux-2.5.make

modpost did not warn on symbols which are exported but not defined
in the current module, but it should.

Also, fix a compile time warning, and have bk ignore *.mod.c files.

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

 - pci_disable_device() added in rr_remove_one() to balance
   pci_enable_device() in rr_init_one()
 - rr_timer() and rr_close() are leaking pci_map'ed memory: make them
   use rr_raz_{rx/tx}
 - error exiting path in rr_open() was balancing pci_alloc_consistent()
   with kfree().

The new reset function only waits up to 0.1 ms for the reset to complete,
instead of 10 ms. However, it introduces the use of a forced reset flag if
a chip doesn't seem cooperative. This fixes cases where until now only
reloading the driver or even rebooting the machine would bring the chip
back.

Fix the following bugs:
- after a watchdog timeout (still a common thing with the Rhine), the
  driver will fall back to half-duplex, ignoring the auto-negotiation
  results, killing performance completely until the driver is reloaded;
  fixed by clearing full_duplex in init_registers()
- driver considers only 0x200 for full-duplex option; now 0x220
- duplex code used dev->name before it's initialized; code section moved

The full_duplex and force_media related code is quite a mess, but this
minimal fix will make the most annoying problems go away. Looking at some
other code (e.g. mii.c) it seems to me the interaction between user force,
autoneg results and full_duplex/force_media is amazingly complex, so I'll
leave it at this for now.

The Tx underrun handling in the current driver is broken. The details have
been explained in a posting "VIA Rhine 1.15exp1, patch for
testing/discussion" a couple of months ago.