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
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
'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
The intent here is to flag to users that the maintenance counters are
not collected for spans exported by the wcte12xp driver.
dahdi_maint before this change:
# dahdi_maint -s 1
Span 1:
>Framing Errors : 0:
>CRC Errors : 0:
>Code Violations : 0:
>E-bit Count : 0:
>General Errored Seconds : 0:
And after:
# dahdi_maint -s 1
Span 1:
>Framing Errors : -1:
>CRC Errors : -1:
>Code Violations : -1:
>E-bit Count : -1:
>General Errored Seconds : -1:
This can be combined with a change to dahdi_maint to recognize that the
errors are -1 and print an even more explicit warning.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10212 a0bf4364-ded3-4de4-8d8a-66a801d63aff
A "(VPMADT032)" string is appended to the devicetype (as shown by
dahdi_scan) for the span if one is installed. Now append '(VPMOCT032)'
if one is installed as well.
Also, for the wcte12xp driver append the VPM name to the device type after
initially probing as opposed to only after the span is configured.
(Related to issue DAHDI-890)
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10203 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When the driver begins to initialize a device it conducts a read/write
test on one of the framer registers. The driver ignores the result of
that test and results in much output spammed to the kernel logs for a
failed card since the driver doesn't then try to unbind from the device.
What was getting spammed:
wcte12xp 0000:03:01.0: Timeout in t1_getreg
wcte12xp 0000:03:01.0: Wrote '0' but read 'fffffffb'
Now abort the bind if the read / write test fails.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10155 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The wcte12xp wasn't recognizing loopup/loopdown signals. The debounce was so
long that it was preventing the loopup/loopdown signals from being registered
properly. Removed the debounce entirely as it was unnecessary to the operation.
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@10064 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The shutdown logic requires that all CPUs see that the INITIALIZED bit
has been cleared. Otherwise it may be possible for the workqueue to run
after the hardware resources have been released.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10047 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The firmware load has been moved into a workqueue to prevent the module load
from blocking for the duration of the firmware upload. This could be up to 40
seconds. Driver prevents configuration until firmware load is finished and
is_initialized() returns true.
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@9998 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Support enabled for the vpmoct032 echo cancellation module for the wctdm24xxp
and wcte12xp drivers.
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@9997 a0bf4364-ded3-4de4-8d8a-66a801d63aff
r9946, "wcte12xp: Move the VPMADT032 test/configuration to module load
time." introduced a race condition where it was possible for the timer
that initiates the check for the alarms to fire before the board was
marked initialized. This would result in a board that would never again
check it's alarm state since the first time the timer runs INITIALIZED
may not be set and it will not reschedule a check since it believes the
driver is unloading.
This happened because the check for the VPM was moved between when the
timer was first setup and when INITIALIZED was then set.
Now we make sure INITIALIZED is set before the timer is first setup, and
move those two operations together.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9981 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Both limit the amount of junk in the kernel log and also prevent dahdi_cfg
from running indefinitely if there is a module with a hardware problem which
prevents it from completing the startup sequence.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9953 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Part of increasing system startup speed.
Splitting these two operations facilitate checking if there is a module
present synchronously on driver load from the actual load of the firmware and
configuration of the channels.
This will allow the presence of the VPM module to be flagged on the span
before registration, but load and configuration can happen in the background.
When the modules are eventually loaded via udev, there will be enough time
from the time the drivers are loaded to when dahdi_cfg will run to complete
the firmware load, eliminating the need to block the driver here.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9951 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In my opinion naming the VPM workqueues for each board is not worth the
extra complexity.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9950 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Ensures that a single run of the interrupt service routine is consistent
about whether there are VPMADT032 commands to process or not.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9949 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This message also duplicates what is in the /etc/dahdi/system.conf file
and should only be necessary when troubleshooting problems.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9948 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is trivial cleanup. Fixing up a couple of places that followed a
kmalloc with a memset to 0 and also sneaked in one ARRAY_SIZE usage
change.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9947 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The firmware load of the VPMADT032 was moved to startspan because a
quad-span card in the same system would would lock interrupts for
several seconds to load VPMOCT064/128 firmware. Now that the wct4xxp
driver no longer locks interrupts while loading its VPM module this
driver can move the VPMADT032 check/load back to module load time.
This is also required so that the presence of a hardware echo canceler
is marked on the span before it is registered with dahdi-base.c.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9946 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This is always true currently but will not necessarily be in the future.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9945 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This defines a NULL value for the name of an echocan as invalid. This
will allow dahdi_genconf to probe for the presence of a hardware echocan
on a channel by trying to attach one. If there is not a hardware echocan
available DAHDI_ATTACH_ECHOCAN ioctl will return -EINVAL if 'hwec' was
specified as the name of the echo canceler now.
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@9943 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
Commit r9781, "wcte12xp, wctdm24xxp: Remove unused support for booting
VPMADT032 from SPI", introduced a bug that would prevent the VPMADT032
from ever being able to complete its startup. This regression did not
make it to any releases.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9914 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Alexandre reported that on a particular server he would get a server
crash when loading the wcte12xp driver after receiving a line about a
timeout when trying to read the mode selection jumpers.
If the driver times out when trying to read the mode selection bits
there is a serious problem and it should not try to continue on with
configuration / registration.
Reported-and-Tested-by: Alexandre Abreu <alexandre.abreu@redt.com.br>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9902 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This change saves around 2.5 us from the interrupt handler.
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@9889 a0bf4364-ded3-4de4-8d8a-66a801d63aff
We are in hard-irq context already, so we do not need to disable all
local interrupts. On one 3.06GHz Xeon test machine, drops the average
time in the interrupt handler from 23.10 us to 21.87 us.
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@9886 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Reduces the number of locks that must be grabbed and released in interrupt
context. On one 3.06Ghz Intel Xeon test machine, drops the average time in
the interrupt handler from 29.83 us to 23.10 us.
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@9883 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
voicebus_quiesce is like voicebus_stop, except that it doesn't wait for any
information to come back from the card. This prevents kexec from blocking
waiting for information from a potentially dead card.
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@9880 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Since there never was a VPMADT032 module shipped with non-volatile
memory no need to check that bit contantly in interrupt context. Also
remove the unused VPM150M_DTMFDETECT bit.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9781 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Trival name change to increase readability in the transmitprep and
recieveprep functions. Now we clearly define if we are working with an
sframe or an eframe.
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@9768 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
Mostly linux/errno.h was included more than once.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9557 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Span registration is the last step in during initialization and it
should be the first on unregistration. I also was hit by this when
looking at adding other members to the span and made the assumption that
the span was in a consistent state during unregistration.
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@9536 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 loopup/loopdown T1 maintenance feature in the single through quad-span
drivers now function properly, according to AT&T TR54016, by sending a
full rate pattern down the line. T1.403 ESF/Data Link patterns are not
supported currently.
Also grouped all the maint reset register clears under a single irq lock
to crank the performance up past 11.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9516 a0bf4364-ded3-4de4-8d8a-66a801d63aff
DAHDI_MAINT_LOOPSTOP is being removed due to the redundancy with
DAHDI_MAINT_NONE. Also removing some timing logic, as amount of time a
loopup or loopdown signal is held on the line, is now defined in
userspace with dahdi_maint.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9515 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
The wcte12xp does all the checking for alarm in a user space workqueue.
Most of this time is spent sleeping waiting for reads from the framer to
complete. Tasks in uninterruptible sleeps are added to running tasks
for the purposes of calculating load average. This change makes the
sleeps interruptible so as to not affect the load average as much.
For example, the following command will load and configure the driver and
then print the load average every 10 seconds.
]# modprobe wcte12xp && dahdi_cfg && ((x=12)); while [[ $x -gt 0 ]]; do cat
/proc/loadavg; sleep 10; let x=$x-1; done
With this change:
0.29 0.10 0.02 1/101 29945
0.24 0.10 0.02 1/101 29967
0.20 0.09 0.02 1/101 30019
0.17 0.09 0.02 1/101 30041
0.15 0.09 0.02 1/101 30062
0.12 0.08 0.02 1/101 30085
0.10 0.08 0.02 1/101 30107
0.09 0.08 0.02 1/101 30129
0.07 0.08 0.02 1/101 30151
0.14 0.09 0.02 1/101 30173
0.12 0.09 0.02 1/101 30195
0.10 0.08 0.02 1/101 30217
(and I've seen it get down to 0.0)
Before this change:
0.57 0.22 0.07 1/101 31920
0.48 0.21 0.07 1/101 31942
0.48 0.22 0.07 1/101 31964
0.48 0.23 0.08 1/101 31986
0.41 0.22 0.07 1/101 32008
0.42 0.23 0.08 1/101 32030
0.43 0.24 0.08 1/101 32054
0.45 0.25 0.09 1/101 32076
0.45 0.25 0.09 1/101 32098
0.46 0.26 0.10 1/101 32120
0.47 0.27 0.10 1/101 32172
0.39 0.26 0.10 1/101 32194
(closes issue #18142)
Reported by: foxfire
Tested by: foxfire
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9512 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'cmd_dequeue_vpmadt032' in the wctdm24xxp and wcte12xp drivers no longer
care about which frame they are on. The command will be packed into the
eframe specified by "writechunk".
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@9446 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Push all tests for the DAHDI_FLAGBIT_NETDEV flag behind a
'dahdi_have_netdev' function so if CONFIG_DAHDI_NET is not defined the
compiler can just remove all the flag tests. Also, makes sure that the
bit is checked / set atomically.
(closes issue #9379)
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@9444 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The check for DEFINE_SPINLOCK was spread throughout the source tree. If
not defined we can just define it in inlucde/dahdi/kernel.h. Now
include/dahdi/kernel.h is the only place that references
SPIN_LOCK_UNLOCKED (which breaks lockdep checking if DEFINE_SPINLOCK is
otherwise defined in the kernel).
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Review: https://reviewboard.asterisk.org/r/940/
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9411 a0bf4364-ded3-4de4-8d8a-66a801d63aff
'open' and 'close' were already empty. 't1xxp_shutdown' only cleared
DAHDI_FLAGBIT_RUNNING which is already done in dahdi-base.c after calling
shutdown.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9318 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Upon shutdown, both drivers would attempt to power down external
interfaces, but never attempted to bring them back up when the span was
restarted. Removing that code allows the driver to work properly until
a better solution can be found.
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9316 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
