This is a driver for the new line of analog cards that shares a common interface
with the TE133/TE134 and the TE435.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The octasic library is relatively large and is currently separately linked into
both the wcte13xp and wct4xxp libraries. This change moves it out into a
separate loadable module.
The bigest change from the drivers perspectives is that they must provide a
table of callbacks instead of using statically linked Oct6100UserXxxxx functions
to allow the library to communicate with actual parts on the cards.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This works around some issues with older versions of the firmware not
working properly after the linemode is changed via sysfs. Basically the
intent is to simulate redoing a complete driver reload with a new
linemode.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This print happened when the linemode was changed via sysfs, but it didn't
really add much extra information that a user could act on.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
dahdi_genconf currently does not take into account the number of spans
configured for a particular board. Therefore if you have two dual span cards
installed in the system, it could be possible to have something like this in
/etc/dahdi/system.conf:
spans=1,1,...
spans=2,2,...
spans=3,3,...
spans=4,4,...
When what you really want is something like this:
spans=1,1,...
spans=2,2,...
spans=3,1,...
spans=4,2,...
Otherwise, spans 3 and 4 will be configured to not recover the clock from the
span which is most likely NOT what you want.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This eliminates the need for board drivers to always re-report their alarm
states when spans are unassigned and then reassigned.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The driver assumes that the first slot is not empty. If this is not the
case, synchronization will not work.
Fail loading if this assertion does not hold.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Astribank 2.02: a newer model: slight variation of 2.01 (both use E-Main
4). Uses the same USB firmware, has to use a different FPGA firmware as
newer devices cannot be made to work with older 2.01 firmware.
FPGA rev. 11307.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Our user-space previously used the implicit location from the sysfs
device path of the "dahdi_device".
* However:
- Sysfs paths are very limited in length.
- Low-level driver need more control on the location field.
- For example, it need to be persistant for span_assignments.
* We now export explicitly the 'location' field which is managed by
low-level drivers.
* We will use this field as the location in span_assignments.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
init_card_1_30 (FXS modules init script) can now use the new sysfs
interface to set ring settings.
Currently it only overwrite a single register
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
A new SysFS interface for FXS modules (XPDs):
* In /sys/bus/xpds/devices/<ll>:<m>:<n>/fxs_ring_registers
* Reading show current register values for NEON/TRAPEZ/NORMAL
* Modify the table via writing: "<column> <reg> <byte> [<byte>]"
* Example:
echo "NEON 0x33 0x12" > \
'/sys/bus/xpds/devices/00:0:0/fxs_ring_registers'
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
xpp: refactor the FXS module ring settings into separate data structure:
* Update High VBAT initialization in init_card_1_30:
- Take the value used in set_vm_led_mode() (0x34)
- Now we don't need to set it over and over again in set_vm_led_mode()
* Create a unified ring_parameters[] array for all ring registers:
- Columns for 3 ring types (NEON, TRAPEZ, NORMAL)
- Used by new send_ring_parameters() function
* Now the set_vm_led_mode() simply calls send_ring_parameters()
* This cleanup would allow us to change ring parameters at runtime (by
updating the values in these tables).
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
With certain pci controllers that support pci hotplug, during the reset
sequence of the fpga, the host controller can get confused about the state of
the card and throw an nmi.
Known affected systems:
HP proliant DL160 & DL360p
Dell poweredge R520
Super Micro X7SPA-HF
This patch attempts to work around that by removing the fpga reset sequence
from the driver startup, then setting various control registers to known
starting state values.
This patch removes the field upgradeable firmware logic temporarily for the
te133 card to prevent fpga reset.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* If userspace would run
modprobe xpp_usb && cat /sys/bus/astribanks/devices/xbus-00/waitfor_xpds
it would return immediately rather than wait for the Astribank to
initialize.
* We sometimes managed to read before getting the reply from the
astribank.
* Now we don't trust unit count at such an early stage.
* Instread we wait for the Astribank to reach a stable state (READY or FAIL)
before finish waiting for this astribank.
Internal-Issue-ID: Xorcom-1502
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* In old kernels (e.g: 2.6.18) sysfs file names must be shorter
then KOBJ_NAME_LEN.
* Longer names are truncated and this leads to duplicate names
which fails device_register()
Examples: "dahdi!channels!10!10" is truncated to "dahdi!channels!10!1"
* The fix shorten the names and make them fixed length. Example:
"dahdi!chan!010!010"
* It seems no current userspace tools rely on that name or on
/dev/dahdi/channels .
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
This was causing inconsistancies with dahdi_scan showing an "UNCONFIGURED" span
in the "RED" state.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This fixes a regression introduced in 2.7.0 in commit
(da8b96d725 "dahdi: Remove unused 'rxbufpolicy'
and 'rxdisable' from dahdi_chan.") when CONFIG_DAHDI_NET is defined in
include/dahdi/dahdi_config.h.
rxbufpolicy was always hardcoded to immediate policy and was removed from the
channel structure. There is no longer any need to set it in dahdi_net_open.
Reported-by: Dave Fullerton <dfullertasterisk@shorelinecontainer.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If system conditions prevent the card from loading the firmware without
touching all the descriptors in the ring, it's possible for
wctc4xxp_cleanup_descriptor_ring to attempt cleanup of a command that was never
submitted resulting in the following BUG.
wctc4xxp 0000:02:0a.0: Failed to load firmware.
BUG: unable to handle kernel paging request at c109556c
IP: [<f9faa83e>] wctc4xxp_cleanup_descriptor_ring+0x8c/0x148 [wctc4xxp]
Reported-by: Xavier Carcelle <xcarcelle@avencall.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
This is needed to compile against Linux 3.10.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
[tzafrir.cohen@xorcom.com: fixed passing /proc/xpp/XPD/summary xbus number]
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Cc: Russ Meyerriecks <rmeyerriecks@digium.com>
Cc: Oron Peled <oron.peled@xorcom.com>
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
This is needed to compile against Linux 3.10.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Cc: Russ Meyerriecks <rmeyerriecks@digium.com>
Cc: Oron Peled <oron.peled@xorcom.com>
create_proc_entry() was deprecated and replace with proc_create_data() since
it's open to a race condition where the proc entry is visible before the file
operations have been set for it.
The PDE() macro also is no longer available as of Linux 3.10 and is replaced
with PDE_DATA() to get the data member from a proc entry. This is due to the
fact that 'struct proc_dir_entry' is now private to the proc_fs.
This commit changes the core of DAHDI and also introduces proc_create_data() and
PDE_DATA() for older kernels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Cc: Russ Meyerriecks <rmeyerriecks@digium.com>
Cc: Oron Peled <oron.peled@xorcom.com>
* This will prevent *ANY* polarity reversal reporting to DAHDI.
* False by default.
* Used in some rare sites with really bad line quality.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
If a span was fully configured before unassigning and reassigning to a new span
type it was possible for stale values to be present in the register. When
switching from T1 to E1 via the spantype sysfs attribute this could result in a
test pattern being written.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If a card stops generating interrupts for any reason, it can take awhile to
unload the driver while waiting for the commands to timeout. Now if there is a
problem, immediately set a bit that the card is failed so that no new commands
will be submitted.
Also, do not free and commands in submit since all commands are freed in get
results now. This prevents list/memory corruption when commands time out.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
When spans are unassigned, dahdi_span_ops.shutdown was called, but the RUNNING
flag was never cleared. Now make sure all calls to the shutdown span ops
callback are the same.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If you have a multiple span system configured for t1 mode, and you try to change
only the first span from t1 to e1 via sysfs, you could get an error in the
kernel log about trying to create duplicate channel.
The problem is that the check for whether there was enough room for the all the
channels of the switched span was wrong.
Reported-by: James Brown <jbrown@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This brings the wcte12xp driver in line with the wct4xxp driver. It also
eliminates the chance that the local side will errouneously go into loopup when
switched from E1 to T1 mode via the spantype sysfs attribute.
Internal-Issue-ID: DAHDI-1038
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This adds definitions for bool and pr_fmt which are needed when compiling
against vanilla 2.6.18.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
In 2.6.2 I introduced an error in (41639330a "wctdm24xxp: Eliminate chance for
channel to be stuck in RED alarm.") which would get an FXO stuck in detecting an
ONHOOK event from the remote side. An FXO port could go into the
BATTERY_DEBOUNCING_LOST_ALARM state and then back to the BATTERY_PRESENT state
without sending the dahdi_hooksig up to Asterisk. Therefore, Asterisk would
never detect the state changes needed for a remote side disconnect.
This change adds two more states, BATTERY_DEBOUNCING_PRESENT_FROM_LOST_ALARM and
BATTERY_DEBOUNCING_LOST_FROM_PRESENT_ALARM so that the state machine does not
miss any needed transitions when going back to BATTERY_PRESENT or BATTERY_LOST
regardless of why the debounce was started.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The channels now have embedded 'struct devices' that contain a device_private
pointer in which to store the device private data. When a device is
unregistered in the system the device privata data is freed by the device core,
even though the chan_release function doesn't free the memory
associated with the device, So when dev_set_drvdata() is called,
it's writing into freed memory.
We also need zero out the embedded struct device before registration,
since we do not have any guarantee that it points to valid memory (or, if a
channel was unregisterd with sysfs, and then reregistered without being cleared
out). Otherwise the core could try to use the previously freed private
data again.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If a user switches linemode with sysfs, the VPM would never switch the
companding mode to alaw, and the result would be extreme static on all channels
of the span when the VPM is enabeld.
Now if the deflaw of the span has changed when an echocan is created, the
companding mode of the VPM channel is changed.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Soon there will be more than one driver in the source tree that will want to use
these files. Compiling it as a library speeds the build since it won't have to
be built for each driver that wants to link it in.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Some of the card callbacks needed maintstat set when processing loopup codes
from the remote side. This change is a modification of commit: (6c02c3c
"dahdi-base: Minor maint mode error")
Without this change cetain cards would not properly process the loopup /
loopdown codes (I know I should have more specific information here but the
details escape me at the moment).
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
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
Previous commit (r10649) included an incorrect version. Including full message
from that commit for the description.
rev. 10502 of the FPGA firmware for the new E-Main rev. 4 fixes a potential
issue when used on Xorcom XR1000 systems: an issue with the power supply may
cause the unit to reset.
Note that there is no issue with previous models, with a normal setup of an
Astribank, or other XRx000 systems.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10652 a0bf4364-ded3-4de4-8d8a-66a801d63aff
rev. 10502 of the FPGA firmware for the new E-Main rev. 4 fixes a potential
issue when used on Xorcom XR1000 systems: an issue with the power supply may
cause the unit to reset.
Note that there is no issue with previous models, with a normal setup of an
Astribank, or other XRx000 systems.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10649 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Print a warning message that it may be a GPL violation to redistribute these
binaries if the firmware for the VPMOCT032/64/128/256 is compiled in.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10646 a0bf4364-ded3-4de4-8d8a-66a801d63aff
It appears that some kernel configurations do not include timer.h in any of
the include files that are included by dahdi_dummy. The timer_structs are
defined in timer.h and not time.h, so this change is correct even though I
never could find a configuation myself that actually failed to compile.
This has negligible impact since dahdi_dummy is not compiled by default.
Internal-Issue-ID: DAHLIN-185
Reported-by: Steve Murphy
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10640 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'irq' field was removed from dahdi_span in r10276 "dahdi: Remove
dahdi_span.irq and move dahdi_span.irqmisses into dahdi_device." [1]
which was first released in dahdi-linux 2.6.0.
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10276
Reported-by: Pavel Selivanov
Internal-Issue-ID: DAHLIN-278
Patches: hdlc.patch by Pavel Selivanov (license #5420)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10634 a0bf4364-ded3-4de4-8d8a-66a801d63aff
