- 30 Oct, 2002 2 commits
-
-
Alexander Viro authored
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.
-
http://linux-isdn.bkbits.net/linux-2.5.isdnLinus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
- 29 Oct, 2002 38 commits
-
-
Kai Germaschewski authored
into tp1.ruhr-uni-bochum.de:/home/kai/src/kernel/v2.5/linux-2.5.isdn
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
Now that ttyI's take care of their own business, some cross links between isdn_common and isdn_tty can finally go away.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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)
-
Kai Germaschewski authored
Again, use a per ttyI timer handler for NO CARRIER messages, only activated when used.
-
Kai Germaschewski authored
Again, use a per ttyI timer handler for RING messages, only activated when used.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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
-
Kai Germaschewski authored
-
Kai Germaschewski authored
It wasn't used in any actual hardware driver, nor did it cause any action at all.
-
Kai Germaschewski authored
-
Kai Germaschewski authored
It was never used anywhere (except for debugging output). Also, fix some compiler warnings.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
We know the driver ids via drivers[]->interface->id already, no need to keep them around a second time.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
... and move up the function register_isdn().
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
This was broken by removing the CVS revision strings.
-
Kai Germaschewski authored
The arrays were only allocated and initialized, never used.
-
Kai Germaschewski authored
Interface type specific stuff is now gone from isdn_net_lib and taken care of in the individual interface type modules.
-
Kai Germaschewski authored
This is just simple renaming. However, ISDN/X.25 looks currently rather badly broken, don't expect it to compile ;(
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
-
Kai Germaschewski authored
isdn_net_dev and isdn_net_local logically are used by isdn_net_lib, so let's move them there.
-
Kai Germaschewski authored
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.
-
Kai Germaschewski authored
-