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
USB_FW rev 9964: includes a few stability bugfixes.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10323 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Removed a couple prints of instrumentation that was cluttering up the log output.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10310 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
The NOTOPEN span alarm flag is set at span unassignment time.
* It needs to be cleared when the span is reassigned.
* That is: only if the span is actually connected.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10302 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* An xbus transport now have a "model_string" member
* The xpp_usb driver fills this with "usb:<idVendor>/<idProduct>/<bcdDevice>"
* It is passed via environment to the "init_card_<type>_<protocol>" scripts
* The FXS script uses this to condition two registers according to
the power supply model.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10300 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since "wctdm24xxp: Probe for and configure modules in parallel." the
check for the VPMADT032 module was moved closer to after when the
interface was initialized. The 200ms timeout did not provide enough
time for the system to settle out after initial start. The result
was that sometimes after a cold boot the driver would fail to detect
any VPMADT032 modules.
This fixes a race condition that is not in any released branches.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10296 a0bf4364-ded3-4de4-8d8a-66a801d63aff
- Cleaned up the OCT6114 interface .
- Relaxed the timeout waiting for OCT6114 bus cycle completion to 100 mS
and added a 2 mS delay time from OCT6114 reset to initialization.
This change only addresses issues that were created in the lab and not in the
field.
Signed-off-by: Doug Bailey <dbailey@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10295 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This will allow the serial number to be exposed in sysfs and also
allow span assignment rules to use the serial number.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10292 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This commit adds field upgradeable support for the TE820 firmware.
Firmware can now be silently upgraded as part of updating drivers
like most of the existing DAHDI firmware. Previous versions of dual
and quad span cards did not support upgrading firmware in the field.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Fixed up some checkpatch issues:
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10291 a0bf4364-ded3-4de4-8d8a-66a801d63aff
TE820 is an 8-span PCI-express digital interface card. VPMOCT256 is a hardware
echo canceler that is able to provide echo cancelation on all 8-spans.
From: Matthew Fredrickson <creslin@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10290 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* So we can:
- Generate 'pinned-spans.conf' from existing state
- Run dahdi_cfg from udev (on specific span + its channels)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10286 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* We try very hard to help asterisk understand that we unassign spans.
* Implement disable_span():
- Set span + channels to DAHDI_ALARM_NOTOPEN
- qevent DAHDI_EVENT_REMOVED
* Use disable_span():
- in dahdi_unassign_span() and dahdi_unregister_device()
- with long msleep() so asterisk has a chance to get the message
- Out of the registration_mutex so we actually context switch.
* Also return more POLLERR variants (POLLRDHUP is not portable,
should be tested).
* Also improve printk(), fix rate_limit increment (was missing)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10285 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* With pinned-spans all spans are registered to dahdi with the
device (and assigned later)
* So this parameter cannot function anymore
* Also remove the (now) empty xpd_post_init() function.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10284 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Otherwise, a failed unit initialization (e.g: when init_card_?_?? fails)
causes a panic
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10282 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Reparent astribanks below their USB transport
* This way their location can be derived from their hardware
hierarchy.
* The tradeoff is that once USB hardware is disconnected, there
is no sysfs visibility of the astribank object even if it
cannot be release yet due to open channels by asterisk
* Thus, we'll need to migrate to "surprise removal" of dahdi
devices...
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10281 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Implement pri_set_spantype() method
* Refactor code from PRI_card_dahdi_preregistration() into
a new apply_pri_protocol().
- It is now called from both PRI_card_dahdi_preregistration()
and set_pri_proto()
- It now also sets span name + description
* Remove old pri_protocol_store() method (pri_protocol is now RO)
* Added pri_protocol_bystr() method (maybe promote it to DAHDI?)
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10280 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allowing the linemode to be configured with sysfs before the spans are
assigned opens the eventualy capability for line mode to be configured
with the other physical layer settings per card. Currently linemode is
set with either physical jumpers or with a module parameter to the
wct4xxp driver that is global for all cards.
Default behavior is not changed with this commit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10279 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allowing the linemode to be configured with sysfs before the spans are
assigned opens the eventualy capability for line mode to be configured
with the other physical layer settings per card. Currently linemode is
set with either physical jumpers or with a module parameter to the
wcte12xp driver that is global for all cards.
Default behavior is not changed with this commit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10278 a0bf4364-ded3-4de4-8d8a-66a801d63aff
For some boards, the linemode (E1/T1/J1) is software selectable but
needs to be configured before the spans were historically registered
since the line mode determines the channel count available on the span.
This change exports a "spantype" attribute from the dahdi_device that
can be used to set E1/T1/J1 before the spans are assigned. When
userspace writes to this attribute (in a <span offset>:<span type
string> format), and if the board driver has implemented a set_spantype
function in it's dahdi_span_ops, then the board driver can optionally
change it's mode before registration.
Also part of this change is breaking out the raw data structure
initialization of the spans / channels via the dahdi_init_device_spans
function since the board drivers may need to reallocate channels / spans
as part of this callback. For example, changing from T1 to E1 mode will
require allocating 7 new channels.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10277 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'irqmisses' is more a function of the device and there are better ways
to get to IRQ for a device than storing it in any DAHDI structures.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10276 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This exposes dahdi devices in sysfs and also exposes attributes that
will allow user space to control the registration order in spans. This
facilitates loading drivers out of order yet keeping consistent
span/channel numbering, which in turn will eventually allow the
blacklist for DAHDI drivers to be removed. The default behavior,
controlled with the auto_register module parameter on dahdi is to number
the spans / channels in order like is currently done. So this change
does not introduce any new behavior by default.
* Writing (anything) to this attribute returns the span to its
unassigned state
* Fix dahdi_chan_unreg() echocan refcount
* Add safeguard against duplicate unassignment to _dahdi_unregister_span()
* Remove the span from device_node list, only in dahdi_unregister_device()
and not in dahdi_unregister_span()
* Free allocated span->span_device in span_sysfs_remove()
[is it safe?, didn't cause problem so far...]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi: Add "hardware_id" dahdi_device attribute.
- The "hardware_id" does not change with device location (e.g: when a PCI
card is moved from one slot to another).
- Not all devices have this attribute. It is legal for it to be NULL (that
is the default for all low-level drivers that do not set it explicitly).
- When "hardware_id" is NULL, the sysfs attribute value is "\n"
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10275 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change will facilitate creating rules that will allow spans and channels
to be accessed by named device files instead of by numbers.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10274 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Increasingly, spans are implemented by devices that support more than a
single span. Introduce a 'struct dahdi_device' object which explicitly
contains multiple spans. This will allow a cleaner representation of
spans and devices in sysfs since order of arrival will not determine the
layout of the devices. This also gives the core of dahdi a way to know
the relationship between spans.
This generalizes similar concepts that were previously xpp specific. The
conversion of the xpp code was almost entirely done by Oron and Tzafrir.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10273 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This patch contains interim results while trying to make
device removal work correctly:
* XPP has protections to prevent dahdi unregistration while
channels are open -- they are now removed, so we can
unregister immediately.
* Handle processes in poll_wait():
- Wake them during dahdi_chan_unreg() after the channel
is gone (chan->channo = -1 or chan->file->private_data == NULL)
- Test in every wait_event_interruptible() that the channel
was not gone (chan->file->private_data)
- Return correct values (POLLERR | POLLHUP) instead of
some errno (would be important in the future if we
modify asterisk to respond correctly to this condition.
* Other issues:
- If unregistered channel is being polled, than call msleep() before
returning, to give other processes a chance (normally, asterisk
has RT priority)
- Call close_channel() from dahdi_chan_unreg() so it releases
related tonezone
* There is still a horrible race hidden by msleep(20) in
dahdi_chan_unreg()
force close channels from dahdi_chan_unreg():
* Mark them via DAHDI_FLAGBIT_OPEN
* Call low-level driver close() method if available
* What about other closing activities?
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10270 a0bf4364-ded3-4de4-8d8a-66a801d63aff
't1e1override' isn't immediately apparent what it is supposed to do by the
name. Instead 'default_linemode' module parameter can be set to "auto", "t1",
or "e1" to make it clear.
This change was introduced earlier in the wcte12xp driver.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10269 a0bf4364-ded3-4de4-8d8a-66a801d63aff
I only generally test on RHEL 4 when testing against kernels older
than 2.6.18. Apparently OpenSUSE 10.1 runs with 2.6.16 and doesn't
have WARN_ON_ONCE backported. I took the patch Richard Miller
originally attached to the issue and moved it to
include/dahdi/kernel.h so it would be available for all the board
drivers in the future.
Internal-Issue-ID: DAHLIN-260
Reported-by: Richard Miller
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10252 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This fixes an issue where "EC: LASVEGAS2" was displayed in /proc/dahdi/x
for a B410P span even though vpmsupport was disabled with the module
parameter.
Internal-Issue-ID: DAHLIN-247
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10251 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Allows the globalconfig member to be removed from the struct t4 and not
carried around for the life of the card. Also holds the reglock a little
longer for all the framer writes but I realize the startup of the
wct4xxp based cards does not need to be optimized.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10250 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Reduces the amount of code to read in the two functions and fixes
checkpatch.pl warnings.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10249 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There are read/modify/write operations on the framer that were not
protected by any locks. While I didn't notice any code paths that would
result in simultaneous accesses to these registers, this change will
hopefully save someone else some time in the future verifying that the
accesses are safe. A side effect is that the reglock is acquired only
once for each read/modify/write cycle as opposed to twice previously.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10248 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since 'linemode' more accurately describes what spantype is specifying.
We can also use an enumeration for the linemode to make it explicit that
linemode is only set to one of three possible values.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10246 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Use some convenience pointers to make the function easier to read as opposed
to indexing into the arrays.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10245 a0bf4364-ded3-4de4-8d8a-66a801d63aff
All those checks for wc->t1e1 span appear to basically be there to
determine if there are *any* E1 spans exported by the card. We can make
that explicit by wrapping those tests with a has_e1_span() inline
function to help with readability.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10244 a0bf4364-ded3-4de4-8d8a-66a801d63aff
't1e1override' isn't immediately apparent what it is supposed to do by the
name. Instead 'default_linemode' module parameter can be set to "auto", "t1",
or "e1" to make it clear.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10243 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since removal of the VPM400 support the 'vpm' member of struct t4 is
now redundant with the 'vpm450m' member.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10242 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The VPM400 module is no longer supported by the wct4xxp driver. The
VPMOCT064 and VPMOCT128 are.
Signed-off-by: Russ Meyerreicks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10241 a0bf4364-ded3-4de4-8d8a-66a801d63aff
