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.

It's useless information, we need to iterate over all potential
drivers anyway, since possibly the first one has unregistered before
the second, leaving a hole.

... and move up the function register_isdn().

Currently, we need to provide a couple of helper functions to avoid
breaking isdn_tty with this change, as that gets cleaned up, the need
for those helpers should vanish as well.

read() should be safe against missed wake-ups now. These devices
should actually be implemented by the hardware drivers directly, would
make for much cleaner code. Unfortunately, isdnctrl is
using /dev/isdnctrl for the common ioctls, which are handled by the link
layer, so that's not easily possible. Too bad.

This was broken by removing the CVS revision strings.

The arrays were only allocated and initialized, never used.

Interface type specific stuff is now gone from isdn_net_lib and
taken care of in the individual interface type modules.

This is just simple renaming. However, ISDN/X.25 looks currently
rather badly broken, don't expect it to compile ;(

There's really no need to allocate private storage for all possible
interface types, just leave it to the interface type to alloc the memory
it needs.
  
CISCO HDLC does that, now.

isdn_net_dev and isdn_net_local logically are used by isdn_net_lib,
so let's move them there.

They'll still get compiled all into one module, but now you can choose
what you need - it's not hard to go from here to individual modules,
but most protocol-specific code is so small that it's probably not worth
it.

Though I've been mostly moving stuff out of include/linux and into
drivers/isdn/i4l, the finite state machine definitions actually need
to be more wildly accessible, so they go the opposite way.

Just add the protocol number header to the frame and have MPPP deal with
the entire frame, separating these layers more cleanly.

The revision numbers didn't get updated in ages, so they don't really
make sense anymore.