'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
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 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
In the rare case where spanconfig is called while there is pending data
on the hdlc channel, the hdlc_getbuf interrupt could try to read from
the hdlc buffer before the channel was fully setup. This could
potentially result in a null pointer dereference. This condition has
existed since the creation of the wcb4xxp driver.
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@10079 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r9943 enabled the presence of hardware EC to be probed on a card. That
change did not account for wcb4xxp based cards that did not have a
hardware echocan on board.
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@10017 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change ensures that the dahdi_span_ops callbacks are not called
with any spinlocks held, and that the module is pinned in memory, and
also passes the struct file * pointer to the callbacks.
Passing the file pointer to the callbacks allows the board drivers to
check any flags on the file descriptor used to configure the
span/channel. The intent here is to allow dahdi_config to open the
/dev/dahdi/ctl file in a non-blocking mode in case there is a lengthy
processes that needs to happen as part of configuration.
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@9940 a0bf4364-ded3-4de4-8d8a-66a801d63aff
gcc-4.6 now warns about variables that are set but never used. Clean up
unused variables everywhere except the oct612x subdirectory.
The oct612x should go in a separate patch in case that needs to be
pulled out into a separate project again.
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@9929 a0bf4364-ded3-4de4-8d8a-66a801d63aff
These drivers (all DAHDI drivers) should explicitly block suspend if they are
loaded.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Michael Spiceland <mspiceland@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9882 a0bf4364-ded3-4de4-8d8a-66a801d63aff
There is already a safe string copying function in all the kernels DAHDI
currently supports.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9585 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2.6.25 added the DEFINE_PCI_DEVICE_TABLE macro to make sure that the
pci_device_id tables are put into the correct section in the binary.
Convert all the places where the tables were defined to use them.
This is linux-2.6 commit where the change went in along with the
rationale: 90a1ba0c5e39eeea278f263c28ae02166c5911c8
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9584 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi/wcb4xxp driver used with Digium Wildcard B410 quad-BRI PCI card
unable to communicate with another ISDN device (ISDN phone, another port
of B410). It appears that B-channels are capable to transport data, but
D-channel is not.
Debug output added into the driver shows that packets are transmitted to
the D-channel, but no packets are received. Further investigation shows
that no interrupts received from Rx FIFO associated with D-channel,
although packets are delivered to the FIFO. I've found that problem is
in improper usage of chan->chanpos while indexing the fifo index
(bspan->fifos): chanpos starts from 1 and fifos starts from 0.
Therefore, garbage read instead of fifo number.
(closes issue #14834)
Reported by: vvv
Patches:
dahdi-linux-complete-2.2.0-rc1.patch uploaded by vvv (license 741)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9555 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The 'pdev' member already contained a pointer to what 'dev' was pointing
to. Also ensure most of the changed lines are under 80 characters.
There are two lines that are were too deeply nested to do anything
sensible.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-By: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9540 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Changed the echocan factory name to a function (get_name) called to get the
name. This allows a factory to return a different name when being called in
reference to a channel such as in the case of hardware echo cancellers. To
further accommodate this change for HWEC, a new echocan_name function was
added to the span ops struct and is used in hwec_factory in dahdi-base for
all cards that support hardware echo cancellation.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9524 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This field was redundant and was only used in places where the factory's name could be used.
Signed-off-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9523 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The dahdi_span->maintq wait queue was very old and not being used so it
has been removed.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.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@9514 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This needs some more testing before it's on by default. If the card is
otherwise functioning, these messages may be confusing to the user. If
the card is not functioning, the driver can be reloaded with debug to
check for this condition.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9205 a0bf4364-ded3-4de4-8d8a-66a801d63aff
