wctc4xxp: Reload the firmware if a fatal alert was received.

The driver will now automatically reload the firmware when there are no open
channels if the firmware reports a fatal error. If the firmware reports an
error, but it was not fatal, it will leave things running and try to reload when
all channels are shut down. The driver will also halt channel processing and
reload the firmware if a channel ever failed to be created.

The thought is that if the DTE reports a non-fatal error, I cannot be certain
what the state is, and it should be reset when possible without impacting
otherwise functioning card.  If there are problems, presumably all users would
hang up and the driver will then reload the firmware.

If the error is fatal, then all processing is halted to encourage everyone to
hang up. The card is probably not working at this point anyway, so there is no
point in trying to communicate with it.

Also included in this change is a compile-time selectable debug sysfs attribute
that will allow forcing an alert condition for testing the recovery.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wctc4xxp: Constrain RTP payload to 500 bytes.

This is a limitation of the DTE firmware that normally would result in dropped
packets on the firmware. If the driver knows it is going to be dropped it should
drop it.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wctc4xxp: Trivial removal of unused structure members.

These were left over from recent developments and are not used by the driver.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wctc4xxp: Trivial reduction of indentation level in wctc4xxp_watchdog()

Now use a continue after the check for cmd->timeout. This change is because I
need to make another change but the deep indentation level would make it hard to
stay within the 80 column limit.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wctc4xxp: spin_lock() -> spin_lock_irqsave() in wctc4xxp_watchdog()

Since commit (e10f740 "wctc4xxp: Service tx ring in interrupt handler."), it
was possible to deadlock the system if the interrupt fires while the
watchdog function is running in the context of the system timer.

This was reported by lockdep.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
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>
wct4xxp: Report rx signalling bit changes after spanconfig.

This fixes a long standing issue where, for CAS signaling, the RX bits were
sometimes misreported after span configuration before the first detected state
change.

The logic in the wct4xxp driver now matches that in the wcte43x driver and
wcte13xp drivers. The wcte12xp driver always polls the sigbits due to how
voicebus works and is not affected by this.

Internal-Issue-ID: DAHDI-1081
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
dahdi: Stop tones on channel when updating tone zone.

If a channel is currently playing a tone when the tone zone is updated, the
existing tone zone could be freed while the channel keeps a reference to the
current tone (curtone) that points into the freed zone.

If the newly freed tone is then modified, there was a window where it was
possible to  corrupt 'struct dahdi_chan' (by overrunning swritechunk[])
resulting in a "BUG: unable to handle kernel paging request at virtual address"
panic in the context of __dahdi_transmit_chunk().

Reported-and-Tested-by: Matt Behrens <matt@zigg.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte13xp: Do not reconfigure framer when span lineconfig is not changed.

If dahdi_span_ops.spanconfig is called multiple times in a row (like when
running dahdi_cfg; dahdi_cfg ) the tx signaling bits would go through a spurious
state that some far side devices would respond to.

Now, if the dahdi_span_ops.spanconfig callback is called, and the configuration
matches the existing configuration, we will not touch the framer.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>