Add .gitignore file

Allows 'git status' command to better show untracked files which one may be
interested in.

Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
(cherry picked from commit d889fb39d317417756e66839b13364f0dd2c94be)
gitignore: Add README.html to git ignore list

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
(cherry picked from commit a8dfd61e534b7ba703cb39e84621dc1ed33ba833)
xpp: Do not typedef bool on RHEL 5.2 or later.

Without digging into the specifics, it looks like Red Hat Linux 5.9
removed the hex_asc definition that was previously used to determine
if the bool definition was backported.

We can simply use the RHEL_RELEASE_CODE now since we do not support any
releases before the 5 series now.

Reported-By: Vladimir Mikhelson
Internal-Issue-ID: DAHLIN-312
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
(cherry picked from commit da0aa6f231d39f6d12c97f16b439c65cb8d29254)

Conflicts:
	drivers/dahdi/xpp/xdefs.h
wctdm24xxp: Only two polarity reversals are needed to validate RING on FXO ports.

This fixes a regression introduced in commit r10186 "wctdm24xxp: Use time
interval for debouncing FXO ring detect." [1] which was first released in
DAHDI-Linux 2.6.0. This only affects users with analog trunks whose providers do
not present 4 polarity reversals on the ring signals. The reporter of this issue
is based in South Africa.

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10168

In prior versions, the ring detector did not check for polarity reversals, only
the presence of ringing voltage unless fwringdetect or neonmwi_monitor mode was
set, and even when one of those modes were set, the driver only needed two
reversals to validate a ring. This commit allows the driver to always stay in
fwringdetect mode but restores the requirement for only two reversals.

Also included in this commit is a change to ensure that ringing is not reported
when debouncing lost battery which can happen when voltage is swinging through
0.

Reported-and-Tested-by: Jaco Kroon <jaco@uls.co.za>
Internal-Issue-ID: DAHLIN-298
Signed-off-by: Shaun Ruffell <sruffell@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10719 a0bf4364-ded3-4de4-8d8a-66a801d63aff
(cherry picked from commit 84e70cdac5ca14a43f37cf083f241eb7eb952bc5)
wct4xxp: EC channel calculation in TONEDETECT assumes TE820.

Since r10290 "wct4xxp: Add support for TE820 and VPMOCT256." [1],
the TONEDETECT ioctl was not calculating the VPM channel correctly
on non TE820 cards. This fixes a regression first introduced in
2.6.0.

[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10290

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

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10733 a0bf4364-ded3-4de4-8d8a-66a801d63aff
(cherry picked from commit abad4b447960bf3059d6a08485defa91ae05cf14)
wct4xxp: t4_serial_setup() was called more often than necessary.

The driver iterates through all the spans on a given device during assignment,
checking for unassigned spans, but it was erroneously testing the span on which
assigned was called.

This just removes some unexpected behavior and provides a slight performance
increase on load and does not impact the functionality of the driver as far as
I'm aware.

Reported-by: Doug Bailey <dbailey@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 9de213b1044c5e005d714b9cf00a367120d42392)
wcb4xxp: Allocate memory in hfc_decode_st_state() with GFP_ATOMIC.

hfc_decode_st_state() will be called from interrupt context when the debug flag
is set to 32. Therefore, must use GFP_ATOMIC when allocating memory.

Only affects the wcb4xxp driver when called with particular debug flags set.

Internal-Issue-ID: DAHLIN-314
Reported-by: Gerald Schnabel
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 85e6cdde83c3edc2d2efd3dd29dfd9de1536a838)
wctdm24xxp: Use framecount and not jiffies when looking for battery present.

The logic to check for battery lost and battery present were using different
time bases. One was using jiffies and the other was using framecount. Since
framecount is always in milliseconds, let's use that to stay consistent.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit a6be60359012260610f616cda20118988529433c)
wctdm24xxp: Eliminate chance for channel to be stuck in RED alarm.

There was a code patch where it was possible to get stuck in RED ALARM on a
channel when debouncing the battery states. The state transitions would look
like this:

BATTERY_PRESENT -> BATTERY_DEBOUNCING_LOST -> BATTERY_DEBOUNCING_LOST_ALARM --
(send alarm up to asterisk) --> BATTERY_LOST -> BATTERY_DEBOUNCING_PRESENT ->
BATTERY_DEBOUNCING_PRESENT_ALARM -> BATTERY_DEBOUNCING_LOST -> BATTERY_PRESENT

In the above sequence there was never any transition from
BATTERY_DEBOUNCING_PRESENT_ALARM to BATTERY_PRESENT so the alarm to Asterisk was
never cleared and the channel stayed stuck.

Now when you loose battery when in the BATTERY_DEBOUNCING_PRESENT_ALARM go all
the way back to the BATTERY_LOST state instead of the BATTERY_DEBOUNCING_LOST
state so that all the events are properly sent up.

This fixes a regression introduced in 2.6.0 with commit (r10169 "wctdm24xxp: Use
interval for debouncing FXO battery." 874b76bd223313e22a773725be63c1b4b64cb274).

Internal-Issue-ID: DAHDI-1019
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
(cherry picked from commit 8bf04348963b440b57e308fdec6cc57c64fcdd3f)