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

Got it.  Breakage happened when Jens was switching to partial
completions - !uptodate is not quite the same as !err ;-)

With this fixed everything seems to work nicely.

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

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

This mentions the web page with information about how to use
the 'usbtest' driver.

This is a version of a patch I sent out last Friday to help
address some of the "bad entry" errors that some folk
were seeing, seemingly only with control requests.  The fix
is just to not try being clever: remove one TD at a time and
patch the ED as if that TD had completed normally, then do
the next ... don't try to patch just once in this fault case.
(And it nukes some debug info I accidently submitted.)

I've gotten preliminary feedback that this helps.

This patch splits up the usb structures to have two structs,
"usb_XXX_descriptor" with just the descriptor, and "usb_host_XXX" (or
something similar) to wrap it and add the "extra" pointers plus the
array of related descriptors that the host parsed during enumeration.
(2 or 3 words extra in each"usb_host_XXX".)  This further matches the
"on the wire" data and enables the gadget drivers to share the same
header file.

Covers all the linux/drivers/usb/* and linux/sound/usb/* stuff, but
not a handful of other drivers (bluetooth, iforce, hisax, irda) that
are out of the usb tree and will likely be affected.

into tp1.ruhr-uni-bochum.de:/home/kai/src/kernel/v2.5/linux-2.5.isdn

We used to lock (ind mod use count) all drivers just in case, but
it makes more sense to only lock the one we're just using, in
particular since the old scheme was rather broken when insmod'ing
a new driver later.

Now that ttyI's take care of their own business, some cross links
between isdn_common and isdn_tty can finally go away.

Again, use a per ttyI timer handler to feed arrived data into the
ttyI. Really, there shouldn't be the need for any timer at all,
rather working flow control, but that'll take a bit to fix.

There's really no good reason to delay sending out data on a ttyI, ISDN
is slow enough anyway ;)
  
(There is one reason, i.e. allowing to coalesce multiple chars, but
that is better fixed by having the upper levels (tty) send larger
buffers)

Again, use a per ttyI timer handler for NO CARRIER messages, only
activated when used.

Again, use a per ttyI timer handler for RING messages, only activated
when used.

Instead of having one common timer and walking the list of
all ISDN channels, which might be possibly associated with a
ttyI and even more possibly so waiting for the silence period
after "+++", just use a per ttyI timer, which only gets activated
when necessary.

The common way in the kernel is to pass around the struct (e.g.
struct net_device), and leave the user the possibility to add
its private data using ::priv, so do it the same way when accessing
an ISDN channel.

Merge the two different types of callbacks into just one, there's no
good reasons for the receive callback to be different, in particular since
we pass things through the same state machine later anyway.

The internal driver/channel relations shouldn't leak out to users
of the ISDN code, and isdn_slot_all_eaz() can be taken over by common
code as well.

For some reason, isdnloop didn't support the transparent encoding,
which is necessary for testing V.110. Testing also found a typo
causing an oops in isdn_common.c. Fixed.

It'd probably make more sense to provide it in library form
to the hardware drivers which don't support V.110 natively, but for
now it's at least collected in one place.

Remove the legacy functions
  
    isdn_slot_readbchan(int slot, u_char *, u_char *, int);
    isdn_slot_driver(int slot);
    isdn_slot_channel(int slot);
    isdn_slot_set_usage(int slot, int usage);
    isdn_drv_writebuf_skb(int di, int ch, int x, struct sk_buff *skb);
    isdn_drv_hdrlen(int di);
  
Most of their tasks have been taken over by isdn_common.c, or are
obsoleted by using the isdn_slot based approach.

Moving the tty receive queue into the tty-specific data in fact
simplifies the common code (which doesn't need to know it at all, now),
and the tty code, which can access the queue more directly.

We used to intercept status callbacks which were for specific channels
instead of the driver before passing them to the driver and short-cutting
to them to the per-channel state machine. Do it correctly for now,
i.e. callback -> driver -> channel, even though that might have a small
performance hit. Correctness first.

ISDN still has a huge global struct called "dev", which is a mess
of parts which should be private to their respective subsystem.
It's supposed to die, this is another step in making that happen.

Change the incoming call logic: Incoming calls are signalled to
the net interface code first, then the tty code. It's the lower level's
responsibility to claim the call by issueing ISDN_CMD_ACCEPTD now.
  
Remove some crud which is handled by isdn_common state machines now.

They were never used except for passing the state to userspace,
but not used in any application I know of. If necessary, the information
can easily be recovered by looking at fi.state == ST_ACTIVE

It wasn't used in any actual hardware driver, nor did it cause any
action at all.

It was never used anywhere (except for debugging output).
  
Also, fix some compiler warnings.

Since we unfortunately cannot rely on the hardware drivers to get
their states always correct, have the common layer keep track of the
states and sanitize them before passing them on to applications
as network interfaces / ttyIs.

We know the driver ids via drivers[]->interface->id already, no need
to keep them around a second time.