Adds support for setting a value of 3 to the module parameter
caller_id_style: passthrough - always pass and don't try to emulate
DTMFs.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
An unset conditional compile flag was triggering the unused variable compile
warning. Added the condition around the variable define.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixes up the kbuild to work with compiling OSLEC from the kernel source. See
HOWTO here: http://forums.digium.com/viewtopic.php?t=67164
Internal-Issue-ID: DAHLIN-317
Reported-By: Vladimir Mikhelson
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Otherwise, it's possible for a link to remain in use if a process quits without
unlinking the conferences. Now when all the channels are removed from the
conference, any links are also cleaned up.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This is mostly a revert of commit r9463. If you need to use DAHDI_CONFLINK
ioctl, make sure to define CONFIG_DAHDI_CONFLINK in
include/dahdi/dahdi_config.h. Apparently there were some users of CONFLINK out
there still.
It's a compile time option now since most users won't need to run the test for
conflinks in the hot-path that is the process_masterspan function.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Tested-by: Ted Gerold <ted@twg.org>
Trades the memory of a file_operations structure to eliminate some tests in the
timer operations.
Internal-Issue-ID: ABE-2904
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
On SMP systems there isn't a need for all dahdi timers to
synchronize on dahdi_timer_lock. Instead give each timer it's own
lock to synchronize with process_timers and use dahdi_timer_lock to
protect the global list of locks.
Also, the dahdi_timers list now only contains timers that are set to
fire. This eliminates a test for each timer in the hot path of the
process_masterspan context.
Reduces system load on many-core systems which are heavy users of
DAHDI timers.
Internal-Issue-ID: ABE-2904
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The Big Kernel Lock removal is no longer experimental so we can eliminate the
call to lock_kernel when calling unlock_ioctl.
Internal-Issue-ID: ABE-2904
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
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." 874b76bd22).
Internal-Issue-ID: DAHDI-1019
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
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>
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>
This is necessary to prevent a crash when opening files by the new
device files, which do not have a valid file_operations structure.
This fixes a problem does not exist in any releases of DAHDI.
Since none of the existing tools or applications open files from the
new location of /dev/dahdi/channels/<span>/<offset>, this wasn't
seen until just recently.
Reported-by: Ted Gerold <ted@twg.org>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
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>
It's wrong (and explicit oops with kernel >= 2.6.19) to set both
bus and class for the same device. But setting the class is not needed
in order to create a device. So just remove our dynamic devices from the
dahdi_class. It will only contain the fixed-named devices.
This fixes regression from cb4e4d0068.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
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>
Eliminates the following warning from sparse:
drivers/dahdi/dahdi-sysfs-chan.c:50:29: error: dubious one-bit signed bitfield
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This allows timingslips to be reset along with the other counters and clarifies
the intended use.
This came up when Doug Bailey asked why he couldn't use dahdi_maint to clear
timing slips in addition to the other counters.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* Channels have their own dynamically allocated major number
* No arbitrary limit of minor < 250 (no collision with /dev/timer, etc)
* We still have arbitrary limit of channo < DAHDI_MAX_CHANNELS
(should be raised?)
* FIXME: need to check to FIXME's
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
* Added minimal infrastructure:
- A 'chan_device' member to struct dahdi_chan
- An empty 'device_attribute' array
- A 'bus_type' with its methods
- A 'device_driver' with its methods
- Initialization/Cleanup code
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
This resolves an issue with a Glenayre GL3000 Paging Terminal with v8.000
software. The Glenayre would change both A and B bits to signal on/off hook
states, but there were a couple of milliseconds between when those bits changed.
This resulted in DAHDI generating an on-hook event to Asterisk before generating
the off-hook event and therefore Asterisk terminated the call prematurely.
Looking the A and B bits before this patch:
Asterisk (AB) Glenayre (AB)
00 00 Both sides on-hook
11 00 Asterisk goes off hook to sieze line.
11 01 Glenayre starts going-offhook. On-hook event
sent to Asterisk from drivers since bits
changed but ABIT was still 0.
11 11 Glenayre finishes going off-hook. Off-hook
event sent to Asterisk since ABIT changed
from 0 to 1.
00 11 Asterisk, processes on-hook event and goes
on-hook itself to release line.
00 00 Glenayre releases line. Call fails.
After this patch:
Asterisk (AB) Glenayre (AB)
00 00 Both sides on-hook
11 00 Asterisk initiates call
11 01 Glenayre starts handling call. No event is
sent to Asterisk since only ABIT is checked.
11 11 Glanayre finishes going off-hook. Call
proceeds normally.
Internal-Issue-ID: DAHDI-1009
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
dahdi_dynamic now always calls the flush function in softirq context so packet
flushing no longer needs to be pushed off to process context since interrupts
are enabled.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Don't run the pre- and post-unregister hooks on a non-phone XPD
(practically: the echo canceller). This fixes a panic with manual
'dahdi_registertion off' as it is now called for the whole device
(regression of 2.6.x).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10735 a0bf4364-ded3-4de4-8d8a-66a801d63aff
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
Since r5021 [1], first released in DAHDI-Linux 2.2.0, it's been impossible for
user space to change the rxbufpolicy. This hasn't caused any problems and it's
safe to remove a few more of the vestiges of the rxbufpolicy from the driver.
This streamlines the code path in a few places and saves 8 bytes from the size
of struct dahdi_chan.
The user visible parts are maintained and will indicate
DAHDI_POLICY_IMMEDIATE, like it has since 2.2.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=5021
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@10730 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since r10683 "convert span->spantype to enumerated type" [1] the spantype was
changed from a string provided by the board drivers to an enumerated type that
is handled by the core of DAHDI. This was done to simplify the task of
dahdi_genconf since there is only one place to look for the valid strings that
can be exported in sysfs.
This eliminates the following warning on driver load:
Warning: Span %s didn't specify a spantype. Please fix driver!
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10683
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@10729 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Not configuring all the spans on an octal card can result in some of the
spans not working in clear channel modes.
Now ensure that all spans receive a default configuration regardless how
they are configured from user space.
Internal-Issue-ID: DAHLIN-289
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@10728 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Internally in DAHDI there is always a hardware echocan factory registered and
available. Having this factory always registered allows for DAHDI to work in a
backward compatible fashion. Namely, by default DAHDI will always use a hardware
echocan if one is available unless 'hwec_overrides_swec' dahdi module parameter
is set to 0 on load. However, if there were no real hardware echocans available
in the system dahdi would still report "Echo Canceller(s): HWEC" in the
dahdi_cfg -v output since the hwec factory is always there.
After this change dahdi_cfg will no longer report HWEC as one of the available
echocans if there isn't a physical span present that actually has a hardware
echocan.
Internal-Issue-ID: DAHLIN-300
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@10727 a0bf4364-ded3-4de4-8d8a-66a801d63aff
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
The previous maint state was saved regardless if the base driver returned an
error or not. This caused strange behavior in dahdi tools. Moved the maint
state save to after the switch case to reflect this.
https://issues.asterisk.org/jira/browse/DAHDI-984
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10718 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes an (embarrassing) error in t1_check_sigbits in the previous commit
where I was writing pass the end of an array on the stack.
Now instead of using an array on the stack, of which all elements were not used,
the pending commands are now stored on a list. I also removed the automatic free
of commands from __t1_getresults and now the function that allocated the command
now frees them.
I believe this will be less error-prone going forward.
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@10700 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The frequency that the RBS registers were polled was too slow to catch the pulse
dialing digits. The result was that often times dahdi would generate WINK events
instead of PULSEDIGIT events.
This speeds up the rate at which the registers are checked from 100ms to 33ms
and also makes the process of checking the registers quicker by queing up all
the reads at once.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10699 a0bf4364-ded3-4de4-8d8a-66a801d63aff
To enable J1 mode previously one would configure the card in T1 mode and then
set the j1mode module parameter. Now "modprobe wcte12xp default_linemode=j1"
will work like the other linemodes globally for all cards manged by this driver.
J1 can also be set on a card-by-card basis in sysfs.
Also move pr_fmt to top of file so pr_xxx macros print the module name as
intended.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10696 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* UMH_WAIT_PROC semantics (and value) was changed from enum to
a bitmask (via #define)
* This constant was missing from kernels older than 2.6.23
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10692 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* This is a minimal convertion -- everything compiles and looks OK.
* We print a warning for spans registering without a spantype.
* Low-level drivers may later want (but not required)
to fold their internal representations to this canonical
representation -- it will save code and make it more readable.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10683 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I failed to compile test r10661 and introduced a typo when fixing a
checkpatch.pl warning.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10662 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is a port of the functionality in the wctdm24xxp driver to support power
savings modes. Specifically, if the the network side of a BRI spans deactivates
the span to save power, the B410P previously automatically activated it again.
Now, if persistentlayer1=0 module parameter is set, the span will be allowed to
stay deactivated until layer two has a message to send on the dchannel.
This patch does not change any of the default behavior of the B410P driver and
the defaults for the persistentlayer1 option is inconsistent with that of the
B400M modules in the wctdm24xxp driver.
Internal-Issue-ID: ABE-2845
From: Matthew Fredrickson <creslin@digium.com>
[ Minor formatting, exposed the persistentlayer1 as module parameter, changed
defaults for teignorered, alarmdebounce, and persistentlayer1 to match current
defaults in wcb4xxp driver ]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10661 a0bf4364-ded3-4de4-8d8a-66a801d63aff
