[dahdi-commits] dahdi/linux.git branch "2.6.y" updated.
SVN commits to the DAHDI project
dahdi-commits at lists.digium.com
Fri Jan 25 15:21:00 CST 2013
branch "2.6.y" has been updated
via 41639330a59ea683cca0f6215a207a59a93f95bd (commit)
via e3931e5d5fc07d2fd90f0c6c663e050fe15ba676 (commit)
via 33b4edf463c19b2ca9bc375a0d292bf1313d6858 (commit)
via 46cfdca5d54ee1154045553c420cb64b45debe0f (commit)
via 42be50ca2819af66648f14a32990bb7044712200 (commit)
via f6511b1040d25b7a000f485834c17f0e30b770f2 (commit)
via 179a48862daf35d022f6fecaf7e5c8195f9d4921 (commit)
via f9632cdeb3cd260ab9583eacbd2473d6050d78e4 (commit)
via 161698087d4e6e7fc3a5d68f1093230a1471fe47 (commit)
from 6262abb53c8c2029210b3c5efcda50ab908e7034 (commit)
Summary of changes:
.gitignore | 41 +++++++++++++++++++++++++++++++++++++
drivers/dahdi/wcb4xxp/base.c | 3 ++-
drivers/dahdi/wct4xxp/base.c | 10 +++++----
drivers/dahdi/wctdm24xxp/base.c | 43 ++++++++++++++++++++++-----------------
drivers/dahdi/xpp/xdefs.h | 14 +++++++------
5 files changed, 81 insertions(+), 30 deletions(-)
create mode 100644 .gitignore
- Log -----------------------------------------------------------------
commit 41639330a59ea683cca0f6215a207a59a93f95bd
Author: Shaun Ruffell <sruffell at digium.com>
Date: Thu Jan 24 11:37:29 2013 -0600
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 at digium.com>
(cherry picked from commit 8bf04348963b440b57e308fdec6cc57c64fcdd3f)
diff --git a/drivers/dahdi/wctdm24xxp/base.c b/drivers/dahdi/wctdm24xxp/base.c
index 1003448..b89e66d 100644
--- a/drivers/dahdi/wctdm24xxp/base.c
+++ b/drivers/dahdi/wctdm24xxp/base.c
@@ -1962,13 +1962,13 @@ wctdm_check_battery_lost(struct wctdm *wc, struct wctdm_module *const mod)
*/
switch (fxo->battery_state) {
case BATTERY_DEBOUNCING_PRESENT:
+ case BATTERY_DEBOUNCING_PRESENT_ALARM: /* intentional drop through */
/* we were going to BATTERY_PRESENT, but
* battery was lost again. */
fxo->battery_state = BATTERY_LOST;
break;
case BATTERY_UNKNOWN:
mod_hooksig(wc, mod, DAHDI_RXSIG_ONHOOK);
- case BATTERY_DEBOUNCING_PRESENT_ALARM: /* intentional drop through */
case BATTERY_PRESENT:
fxo->battery_state = BATTERY_DEBOUNCING_LOST;
fxo->battdebounce_timer = wc->framecount + battdebounce;
@@ -2062,6 +2062,7 @@ wctdm_check_battery_present(struct wctdm *wc, struct wctdm_module *const mod)
case BATTERY_PRESENT:
break;
case BATTERY_DEBOUNCING_LOST:
+ case BATTERY_DEBOUNCING_LOST_ALARM:
/* we were going to BATTERY_LOST, but battery appeared again,
* so clear the debounce timer */
fxo->battery_state = BATTERY_PRESENT;
@@ -2069,7 +2070,6 @@ wctdm_check_battery_present(struct wctdm *wc, struct wctdm_module *const mod)
case BATTERY_UNKNOWN:
mod_hooksig(wc, mod, DAHDI_RXSIG_OFFHOOK);
case BATTERY_LOST: /* intentional drop through */
- case BATTERY_DEBOUNCING_LOST_ALARM:
fxo->battery_state = BATTERY_DEBOUNCING_PRESENT;
fxo->battdebounce_timer = wc->framecount + battdebounce;
break;
commit e3931e5d5fc07d2fd90f0c6c663e050fe15ba676
Author: Shaun Ruffell <sruffell at digium.com>
Date: Wed Jan 23 17:16:07 2013 -0600
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 at digium.com>
(cherry picked from commit a6be60359012260610f616cda20118988529433c)
diff --git a/drivers/dahdi/wctdm24xxp/base.c b/drivers/dahdi/wctdm24xxp/base.c
index ddf45ef..1003448 100644
--- a/drivers/dahdi/wctdm24xxp/base.c
+++ b/drivers/dahdi/wctdm24xxp/base.c
@@ -2023,7 +2023,7 @@ wctdm_check_battery_present(struct wctdm *wc, struct wctdm_module *const mod)
switch (fxo->battery_state) {
case BATTERY_DEBOUNCING_PRESENT:
- if (time_after(jiffies, fxo->battdebounce_timer)) {
+ if (time_after(wc->framecount, fxo->battdebounce_timer)) {
if (debug) {
dev_info(&wc->vb.pdev->dev,
"BATTERY on %d/%d (%s)!\n",
@@ -2048,12 +2048,12 @@ wctdm_check_battery_present(struct wctdm *wc, struct wctdm_module *const mod)
* of its time period has already passed while
* debouncing occurred */
fxo->battery_state = BATTERY_DEBOUNCING_PRESENT_ALARM;
- fxo->battdebounce_timer = jiffies +
- msecs_to_jiffies(battalarm - battdebounce);
+ fxo->battdebounce_timer = wc->framecount +
+ battalarm - battdebounce;
}
break;
case BATTERY_DEBOUNCING_PRESENT_ALARM:
- if (time_after(jiffies, fxo->battdebounce_timer)) {
+ if (time_after(wc->framecount, fxo->battdebounce_timer)) {
fxo->battery_state = BATTERY_PRESENT;
dahdi_alarm_channel(get_dahdi_chan(wc, mod),
DAHDI_ALARM_NONE);
@@ -2071,8 +2071,7 @@ wctdm_check_battery_present(struct wctdm *wc, struct wctdm_module *const mod)
case BATTERY_LOST: /* intentional drop through */
case BATTERY_DEBOUNCING_LOST_ALARM:
fxo->battery_state = BATTERY_DEBOUNCING_PRESENT;
- fxo->battdebounce_timer = jiffies +
- msecs_to_jiffies(battdebounce);
+ fxo->battdebounce_timer = wc->framecount + battdebounce;
break;
}
}
commit 33b4edf463c19b2ca9bc375a0d292bf1313d6858
Author: Shaun Ruffell <sruffell at digium.com>
Date: Wed Jan 23 16:14:07 2013 -0600
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 at digium.com>
(cherry picked from commit 85e6cdde83c3edc2d2efd3dd29dfd9de1536a838)
diff --git a/drivers/dahdi/wcb4xxp/base.c b/drivers/dahdi/wcb4xxp/base.c
index 1296006..74b91bb 100644
--- a/drivers/dahdi/wcb4xxp/base.c
+++ b/drivers/dahdi/wcb4xxp/base.c
@@ -1249,7 +1249,8 @@ static char *hfc_decode_st_state(struct b4xxp *b4, int port, unsigned char state
"?", "?", "?", "?", "?", "?", "?", "?" }
};
- if (!(str = kmalloc(256, GFP_KERNEL))) {
+ str = kmalloc(256, GFP_ATOMIC);
+ if (!str) {
dev_warn(&b4->pdev->dev, "could not allocate mem for ST state decode string!\n");
return NULL;
}
commit 46cfdca5d54ee1154045553c420cb64b45debe0f
Author: Shaun Ruffell <sruffell at digium.com>
Date: Mon Dec 17 13:00:18 2012 -0600
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 at digium.com>
Signed-off-by: Shaun Ruffell <sruffell at digium.com>
(cherry picked from commit 9de213b1044c5e005d714b9cf00a367120d42392)
diff --git a/drivers/dahdi/wct4xxp/base.c b/drivers/dahdi/wct4xxp/base.c
index a17fab5..da86eca 100644
--- a/drivers/dahdi/wct4xxp/base.c
+++ b/drivers/dahdi/wct4xxp/base.c
@@ -2039,7 +2039,7 @@ static void t4_span_assigned(struct dahdi_span *span)
/* We use this to make sure all the spans are assigned before
* running the serial setup. */
list_for_each_entry(pos, &wc->ddev->spans, device_node) {
- if (!test_bit(DAHDI_FLAGBIT_REGISTERED, &span->flags))
+ if (!test_bit(DAHDI_FLAGBIT_REGISTERED, &pos->flags))
++unassigned_spans;
}
commit 42be50ca2819af66648f14a32990bb7044712200
Author: Shaun Ruffell <sruffell at digium.com>
Date: Thu Oct 4 20:24:55 2012 +0000
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 at digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks at digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10733 a0bf4364-ded3-4de4-8d8a-66a801d63aff
(cherry picked from commit abad4b447960bf3059d6a08485defa91ae05cf14)
diff --git a/drivers/dahdi/wct4xxp/base.c b/drivers/dahdi/wct4xxp/base.c
index 8bdd2f0..a17fab5 100644
--- a/drivers/dahdi/wct4xxp/base.c
+++ b/drivers/dahdi/wct4xxp/base.c
@@ -1239,9 +1239,11 @@ static int t4_ioctl(struct dahdi_chan *chan, unsigned int cmd, unsigned long dat
else
clear_bit(chan->chanpos - 1, &ts->dtmfmutemask);
- channel = (chan->chanpos) << 3;
- if (!has_e1_span(wc))
- channel += (4 << 3);
+ channel = has_e1_span(wc) ? chan->chanpos : chan->chanpos + 4;
+ if (is_octal(wc))
+ channel = channel << 3;
+ else
+ channel = channel << 2;
channel |= chan->span->offset;
vpm450m_setdtmf(wc->vpm, channel, j & DAHDI_TONEDETECT_ON,
j & DAHDI_TONEDETECT_MUTE);
commit f6511b1040d25b7a000f485834c17f0e30b770f2
Author: Shaun Ruffell <sruffell at digium.com>
Date: Fri Sep 21 18:16:35 2012 +0000
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 at uls.co.za>
Internal-Issue-ID: DAHLIN-298
Signed-off-by: Shaun Ruffell <sruffell at digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10719 a0bf4364-ded3-4de4-8d8a-66a801d63aff
(cherry picked from commit 84e70cdac5ca14a43f37cf083f241eb7eb952bc5)
diff --git a/drivers/dahdi/wctdm24xxp/base.c b/drivers/dahdi/wctdm24xxp/base.c
index 0f36ef1..ddf45ef 100644
--- a/drivers/dahdi/wctdm24xxp/base.c
+++ b/drivers/dahdi/wctdm24xxp/base.c
@@ -1833,19 +1833,22 @@ static void wctdm_qrvdri_check_hook(struct wctdm *wc, int card)
static inline bool is_fxo_ringing(const struct fxo *const fxo)
{
return ((fxo->hook_ring_shadow & 0x60) &&
- (fxo->battery_state == BATTERY_PRESENT));
+ ((fxo->battery_state == BATTERY_PRESENT) ||
+ (fxo->battery_state == BATTERY_DEBOUNCING_LOST)));
}
static inline bool is_fxo_ringing_positive(const struct fxo *const fxo)
{
return (((fxo->hook_ring_shadow & 0x60) == 0x20) &&
- (fxo->battery_state == BATTERY_PRESENT));
+ ((fxo->battery_state == BATTERY_PRESENT) ||
+ (fxo->battery_state == BATTERY_DEBOUNCING_LOST)));
}
static inline bool is_fxo_ringing_negative(const struct fxo *const fxo)
{
return (((fxo->hook_ring_shadow & 0x60) == 0x40) &&
- (fxo->battery_state == BATTERY_PRESENT));
+ ((fxo->battery_state == BATTERY_PRESENT) ||
+ (fxo->battery_state == BATTERY_DEBOUNCING_LOST)));
}
static inline void set_ring(struct fxo *fxo, enum ring_detector_state new)
@@ -1856,19 +1859,21 @@ static inline void set_ring(struct fxo *fxo, enum ring_detector_state new)
static void wctdm_fxo_ring_detect(struct wctdm *wc, struct wctdm_module *mod)
{
struct fxo *const fxo = &mod->mod.fxo;
+ static const unsigned int POLARITY_CHANGES_NEEDED = 2;
/* Look for ring status bits (Ring Detect Signal Negative and Ring
- * Detect Signal Positive) to transition back and forth some number of
- * times to indicate that a ring is occurring. Provide some number of
- * samples to allow for the transitions to occur before giving up.
- * NOTE: neon mwi voltages will trigger one of these bits to go active
- * but not to have transitions between the two bits (i.e. no negative
- * to positive or positive to negative traversals) */
+ * Detect Signal Positive) to transition back and forth
+ * POLARITY_CHANGES_NEEDED times to indicate that a ring is occurring.
+ * Provide some number of samples to allow for the transitions to occur
+ * before giving up. NOTE: neon mwi voltages will trigger one of these
+ * bits to go active but not to have transitions between the two bits
+ * (i.e. no negative to positive or positive to negative traversals) */
switch (fxo->ring_state) {
case DEBOUNCING_RINGING_POSITIVE:
if (is_fxo_ringing_negative(fxo)) {
- if (++fxo->ring_polarity_change_count > 4) {
+ if (++fxo->ring_polarity_change_count >
+ POLARITY_CHANGES_NEEDED) {
mod_hooksig(wc, mod, DAHDI_RXSIG_RING);
set_ring(fxo, RINGING);
if (debug) {
@@ -1886,7 +1891,8 @@ static void wctdm_fxo_ring_detect(struct wctdm *wc, struct wctdm_module *mod)
break;
case DEBOUNCING_RINGING_NEGATIVE:
if (is_fxo_ringing_positive(fxo)) {
- if (++fxo->ring_polarity_change_count > 4) {
+ if (++fxo->ring_polarity_change_count >
+ POLARITY_CHANGES_NEEDED) {
mod_hooksig(wc, mod, DAHDI_RXSIG_RING);
set_ring(fxo, RINGING);
if (debug) {
commit 179a48862daf35d022f6fecaf7e5c8195f9d4921
Author: Shaun Ruffell <sruffell at digium.com>
Date: Sat Jan 19 17:02:41 2013 -0600
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 at digium.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
(cherry picked from commit da0aa6f231d39f6d12c97f16b439c65cb8d29254)
Conflicts:
drivers/dahdi/xpp/xdefs.h
diff --git a/drivers/dahdi/xpp/xdefs.h b/drivers/dahdi/xpp/xdefs.h
index c296698..9ae940b 100644
--- a/drivers/dahdi/xpp/xdefs.h
+++ b/drivers/dahdi/xpp/xdefs.h
@@ -144,12 +144,14 @@ typedef unsigned char byte;
#define SET_PROC_DIRENTRY_OWNER(p) do { } while(0);
#endif
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)
-/* Also don't define this for later RHEL >= 5.2 . hex_asc is from the
- * same linux-2.6-net-infrastructure-updates-to-mac80211-iwl4965.patch
- * as is the bool typedef. */
-#if LINUX_VERSION_CODE != KERNEL_VERSION(2,6,18) || ! defined(hex_asc)
-typedef int bool;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 19)
+/* Also don't define this for later RHEL >= 5.2. */
+#if defined(RHEL_RELEASE_CODE) && defined(RHEL_RELEASE_VERSION)
+#if RHEL_RELEASE_CODE < RHEL_RELEASE_VERSION(5, 3)
+typedef int bool;
+#endif
+#else
+typedef int bool;
#endif
#endif
#else
commit f9632cdeb3cd260ab9583eacbd2473d6050d78e4
Author: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
Date: Wed Dec 12 16:57:15 2012 +0200
gitignore: Add README.html to git ignore list
Signed-off-by: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks at digium.com>
(cherry picked from commit a8dfd61e534b7ba703cb39e84621dc1ed33ba833)
diff --git a/.gitignore b/.gitignore
index ac7b51c..11a65e1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,6 +14,7 @@ cscope.*
*.markers
.*.o.d
+README.html
modules.order
Module.markers
build_tools/checkpatch.pl
commit 161698087d4e6e7fc3a5d68f1093230a1471fe47
Author: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
Date: Thu Dec 6 23:49:54 2012 +0200
Add .gitignore file
Allows 'git status' command to better show untracked files which one may be
interested in.
Signed-off-by: Russ Meyerriecks <rmeyerriecks at digium.com>
Acked-by: Shaun Ruffell <sruffell at digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
(cherry picked from commit d889fb39d317417756e66839b13364f0dd2c94be)
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..ac7b51c
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,40 @@
+# Files that are generated as part of the build process which we do not want git
+# to track.
+
+*.[oa]
+*.mod
+*.mod.[oc]
+*.ko
+*.cmd
+*.order
+*.tar.gz
+tags
+cscope.*
+*.symvers
+*.markers
+.*.o.d
+
+modules.order
+Module.markers
+build_tools/checkpatch.pl
+drivers/dahdi/xpp/*.verified
+drivers/dahdi/.tmp_versions/
+drivers/dahdi/Module.symvers
+drivers/dahdi/makefw
+drivers/dahdi/radfw.h
+drivers/dahdi/tor2fw.h
+drivers/dahdi/xpp/init_fxo_modes
+drivers/dahdi/xpp/print_fxo_modes
+drivers/dahdi/xpp/xpp_version.h
+include/dahdi/version.h
+drivers/dahdi/vpmadt032_loader/vpmadt032_loader.h
+drivers/dahdi/vpmadt032_loader/vpmadt032_x86_32.o_shipped
+drivers/dahdi/vpmadt032_loader/vpmadt032_x86_64.o_shipped
+drivers/dahdi/firmware/dahdi-fw-hx8.bin
+drivers/dahdi/firmware/dahdi-fw-oct6114-064.bin
+drivers/dahdi/firmware/dahdi-fw-oct6114-128.bin
+drivers/dahdi/firmware/dahdi-fw-oct6114-256.bin
+drivers/dahdi/firmware/dahdi-fw-tc400m.bin
+drivers/dahdi/firmware/dahdi-fw-te820.bin
+drivers/dahdi/firmware/dahdi-fw-vpmoct032.bin
+drivers/dahdi/firmware/make_firmware_object
-----------------------------------------------------------------------
--
dahdi/linux.git
More information about the dahdi-commits
mailing list