dahdi: Protect echocan creation/destruction with mutex.

This closes a reference and memory leak when multiple CPUs are enabling echocan
on a single channel in parallel.

The essential problem is that the call to try_module_get() is not serialized.
Two separate threads can come into ioctl_echocan() on the same channel, they
coordinate via the dahdi_chan.lock to release any current echocan, but then both
create a new echocan state, bump the reference on the module, and the last one
through will actually attach the new state to the channel. The earlier reference
/ memory is leaked.

I tried to conceive of a way to fix this leak without adding a new lock, but the
choices where calling throught the function pointers with dahdi_chan.lock.
Otherwise I needed to change the semantics of echocan_create /free which would
ripple through the hardware echocan modules.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
dahdi: dahdi_chan.ec_factory can be protected with the mutex.

This is never accessed or modified in interrupt context. This closes a potential
race if the echocan is being changed on a channel while enabling disabling is
hapening on another thread.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wct4xxp: Move bottom half processing from tasklet to workqueue.

I am primarily making this change in order that the oct612x API can use a mutex as
a synchronization primitive. Mutexes can only be aquired in process context and
the wct4xxp driver calls the Oct61000InterruptServiceRoutine (which grabs a
serialization object) when tone detection is enabled.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
oct612x: Implement the SerializationObject callbacks.

When originally implemented, the octasic calls where protected by the big kernel
lock. This change now allows the octasic library to control it's synchronization
as originally intended.

It would still be worthwhile to completely make the oct612x library
kernel-compliant.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wct4xxp: Trivial kmalloc + memset -> kzalloc.

Just a minor cleanup.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wct4xxp: AMI w/CAS errata applies to octal card as well.

Fixes inability to reliably get CAS (robbed-bits) when using AMI line encoding
on the TE820 card.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wct4xxp: Remove unused open/close span_ops callbacks.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
tor2: Remove unused open/close callbacks.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Do not call dahdi_span_ops.open with spinlock held.

This makes the open symmetrical with the close. It is also considered good
practice to not call through callbacks with spinlocks held.

I modified all the drivers where I could not tell whether it was necessary to
hold the chan->lock with interrupts disabled to simply take the lock inside the
callback.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte13xp: Do not get stuck in "Not Open" state when DAHDI_CONFIG_NOTOPEN is set.

If dahdi_cfg set the DAHDI_CONFIG_NOTOPEN setting on the span, which it does
when the "yellow" flag is added to the span config line, then it was possible
for the span to get stuck with DAHDI_ALARM_NOTOPEN (NOP).

This is because the wcte13xp driver only updates the alarm state when the framer
reports that the span alarm has changed. Therefore, unless the framer goes
through an alarm transition, the fact that channels are opened was never noticed
by alarm handling routine.

Now check the alarm state directly when the first channel is opened, and the
last channel is closed.

Internal-Issue-ID: DAHDI-1103
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte43x: Change span flags to atomic bitfield.

This will facilitate adding another flag for open channels on a span without
needing to add a lock on the span, or taking the global lock. Currently the span
flags are protected by the global reglock. This is not longer required.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte43x: Do not get stuck in "Not Open" state when DAHDI_CONFIG_NOTOPEN is set.

This is the same change for the wcte13xp driver but applied to the other
xbus-based digital card.

If dahdi_cfg set the DAHDI_CONFIG_NOTOPEN setting on the span, which it does
when the "yellow" flag is added to the span config line, then it was possible
for the span to get stuck with DAHDI_ALARM_NOTOPEN (NOP).

This is because the driver only updates the alarm state when the framer reports
that the span alarm has changed. Therefore, unless the framer goes through an
alarm transition, the fact that channels are opened was never noticed by alarm
handling routine.

Now check the alarm state directly when the first channel is opened, and the
last channel is closed.

Internal-Issue-ID: DAHDI-1103
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>