Previously this was in __dahdi_init_span(). The problem was that
__dahdi_init_span() was only called when a spans' line mode was being changed.
Therefore it was possible to unassign and resassign an analog span and leave it
stuck in the 'NOP' alarm state.
It also make the setting / clearing of DAHDI_ALARM_NOTOPEN symetrical about span
unassignment / assignment in addition to updating the alarm states on all the
channels on the span via the dahdi_alarm_notify() function.
This is a better version of commit 496f817773.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Fixes the following warning when loading the driver:
dahdi: Warning: Span DYN/eth/eth1/00:50:c2:97:92:1d/1 didn't specify a spantype. Please fix driver!
The spantype is intended to be used by the auto configuration tools
(dahdi_genconf, pinned spans, etc..) but dynamic spans, since they are created
directly by dahdi_cfg, never take part in the pre-registration auto
configuration, therefore the span type was never used.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
* This changeset adds master_span as an attribute of the span's driver:
/sys/bus/dahdi_spans/drivers/generic_lowlevel/master_span
* This is mainly used for debugging.
* Reading from it the master span number (or 0 if there is no master
span).
* Writing a number to it, force specified span to be master
* Existing Alternatives:
- grep "MASTER" from /proc/dahdi/*
- cat /sys/bus/dahdi_spans/devices/span-*/is_sync_master
(Note: commit d8fe2af23d is also Acked-By
Tzafrir Cohen <tzafrir.cohen@xorcom.com>)
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* No functional changes.
* Rename the span 'master' to 'master_span' to avoid ambiguity with the
'master' channel.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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
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 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
'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
Instead of registering a function pointer, register a dahdi_dynamic_ops
structure that contains the owner as well as the ioctl callback. This way
dahdi.ko can bump up the reference count on dahdi_dynamic.ko before calling
the ioctl callback.
Also, use the registration mutex to guard against the module being unloaded
between the time the structure pointer was checked, and the module reference
is taken.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10623 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In addition to updating the year, this also adds some boilerplate to
dahdi-sysfs.c and dahdi-sysfs-chan.c that wasn't there previously.
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@10560 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Will allow the ASPM (Active State Power Management) state to be disabled on
PCIe devices before kernel version 2.6.25.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10556 a0bf4364-ded3-4de4-8d8a-66a801d63aff
DAHDI internal timing currently uses the "wall clock" to determine how much
time is passing for mixing and timers. When the wall time changes, like when
the system time is set via ntp or date, DAHDI currently will display a
"Detected time shift" message since it believes there is too much audio to
mix. There may also be audio problems if the wall time is shifting
occasionally due to slewing of the clock.
Now use a monotonic clock to determine how much real-time has passed for
timing purposes. This makes DAHDI insensitive to any changes in the wall time
on the system.
This only applies when using DAHDI's internal timer like when there are not
any telphony cards installed. There are still potential audio problems if the
platform is unable to accurately determine the passage of time.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10482 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This patch removes support for kernel versions < 2.6.18, as those are
not actively supported in any major Linux distribution (except RHEL4,
which is in the "extended" support level of the product life cycle).
This removes much of the more #ifdef-rich parts of the code.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Acked-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@10472 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Shortcut CLASS_DEV_CREATE/CLASS_DEV_DESTROY. No need to pass repetitive
data (and NULL) on every call.
* Create/remove fixed device files (ctl, timer, channel, pseudo) via
generic code (fixed_devfiles_create()/fixed_devfiles_remove()) instead
of repetitive code and flags.
* Try to make all removal/cleanup functions idempotent, so we can
safely call them on any failure without the need for multiple goto
destinations.
* Rename 'device_state_flags' to 'should_cleanup' and its member
flags to a better/consistent naming.
* Rename dahdi_sysfs_exit() to dahdi_sysfs_cleanup() and call it from
a new proper dahdi_sysfs_exit()
* In dahdi_sysfs_init(), handle dahdi_sysfs_chan_init() failures
* Add dahdi_dbg() message before creating/removing all DEVICES
objects.
* Also move two KERN_INFO messages to a more correct locations:
- The version reporting should be first (in dahdi-base.c)
- The "Telephony... on major" reporting should be at the end
of dahdi_sysfs_init()
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-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@10464 a0bf4364-ded3-4de4-8d8a-66a801d63aff
show Master change to/from core timer if DEBUG_MAIN (GENERAL) flag is on.
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@10451 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* A parent-less device should not crash dahdi:
- Access span->parent->dev instead of span->parent-dev.parent
in soem cases.
- Access span->parent->dev via new inline span_device()
- Use span_device() in all dahdi_dev_{dbg,info}()
* Allow low-level drivers to set their device name.
- Drivers that don't use this feature get the default name
based on the parent device name
- Parent-less devices which don't set their name, fails
to register with -EINVAL
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@10449 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allows dahdi_cfg to return an error code if a board driver fails it's startup
call for any reason.
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@10379 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Otherwise, if the _dahdi_assign_span call fails, the dahdi_device will never
be removed from the dahdi_devices virtual bus and the board drivers will not
be reloadable.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10331 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I misssed a small typo in r10328 "Extra debugging aids and messages" that
would force any span that supports a hardware preechocan to always fail
assignment with -EFAULT.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10330 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Added dahdi_dev_dbg() macro to print when we don't (yet)
have a span number.
* Added a new debug category: DAHDI_DBG_ASSIGN
* Made sure error return code paths prints helpfull messages
* Promote error messages from INFO to NOTICE
* Change some errno values from EINVAL to EFAULT (internal
errors not caused by user input)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10328 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The test in _check_spanno_and_basechan() was off by one
(used '<' instead of '<=')
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10327 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r10205 "dahdi: Check for master in DAHDI_STARTUP / resolves MeetMe
regression." did not handle the case for the wcb4xxp driver since it
would set DAHDI_FLAG_RUNNING as part of the probe. Therefore, the
DAHDI_STARTUP ioctl was never processed for it, creating a situation
where audio is missing on channels that are conferenced with channels on
the BRI spans.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10304 a0bf4364-ded3-4de4-8d8a-66a801d63aff
