Upstream kernel 4.14, in commit (686fef928bba6b "timer: Prepare to change timer
callback argument type") [1], introduced the timer_setup interface to replace
the init_timer/setup_timer interfaces. The primary change is that the timer
callback functions now follow the standard kernel pattern where the structure
the callback sits in is passed to the callback instead of storing a pointer to
an unassociated data type.
The setup_timer functions were removed in upstream kernel v4.15, and therefore
this change is needed in order to compile DAHDI for kernels >= 4.15.
This change follows the same strategy that was done in the kernel to while the
existing users of setup_timer were migrated to the new interface.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=686fef928bba6b
GCC 7.3.0 complained about the potential to overflow the fixed size span and
channel names and descriptions. It also flagged potential truncations of the
strings.
The sprintf calls are now changed to snprintf to prevent the potential
overflows, but the warning about truncations are now disabled globally.
The upstream 4.11 kernel, in commit (10383aea2f445bce9b2a2b308def08134b438c8e
"kref: Implement 'struct kref' using refcount_t"), changed refcount type on kref
objects. We now need to use refcount_read to read them.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The logic on ENABLE_TASKELETS compiler flag was inverted causing an oops on
normal dahdi_cfg of a dynamic span.
Issue-id: https://issues.asterisk.org/jira/browse/DAHLIN-328
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-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>
I saw a kernel oops that was the result of the timer running after the
dahdi_dynamic module was unloaded. Now we wait for the timer to complete, and
then delete it again in case it reactivated itself.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10625 a0bf4364-ded3-4de4-8d8a-66a801d63aff
The board drivers are the ones calling the unregister function, and
therefore we do not need to worry about them unloading while calling the
destroy callback.
When destroying spans with the ioctl, replace __module_get() with
try_module_get. This avoids hitting a BUG in module_get on kernel versions <
2.6.29.
ALSO move the call to try_module_get out of the dahdi_dynamic_release function
and into destroy. This way if the destroy callback isn't called because the
dynamic driver is unloading the dynamic device can be left on the list to be
cleaned up by the dahdi_dynamic_unregister_driver function().
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10624 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
This in conjunction with r10449 "A parent-less device should not crash dahdi",
this allows dahdi_dynamic spans to work post the dahdi_devices changes in
2.6.0.
The full address of the device is not used since kernels prior to 2.6.31 limit
the length of a devicename to 20 characters. The full address of the device
can be pulled out of the "hardware_id" and "type" fields of the span.
This patch is just to get things working again. dahdi_dynamic devices *may*
still have issues if the auto_assign_spans module parameter is 0.
Internal-Issue-ID: DAHLIN-280
Reported-by: Pavel Selivanov
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10563 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
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
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
Currently dahdi_receive is called on all channels in the context of the
master dynamic span. If one span (not the master) receive two packets
before the master span received a packet, the older packet on the
dynamic span would end up lost because the "readchunk" for the
channels would be overwritten by the new packet. DAHLIN-245
Signed-off-by: Wagner Gegler <wagner@aligera.com.br> (License #6268)
Changed dahdi_ec_chunk to dahdi_ec_span.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10110 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
Since the return value is not defined/used just return void.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Kinsey Moore <kmoore@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9587 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
Also makes it safe to unregister a dynamic driver when there aren't any
open channels on the dynamic spans.
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@9580 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This allows the pvt member to be set under lock without holding the lock
through the call to create destroy.
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@9578 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Running in tasklets does not work well when dahdi doesn't have a span that is
acting as the master. In this case, process_masterspan is being called in
system timer that may not be running at 1ms intervals. The end result is that
the dynamic_run function isn't called for every chunk processed, and there is
data loss.
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@9577 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Dynamic spans that are unable to provide their own timing, like dahdi
local spans, typically derived their timing source from
dahdi_dynamic_ioctl(0,0) call in process_masterspan.
This change uses the sync_tick member of dahdi_span_ops instead so that
dynamic operations do not happen on a span until it is fully registered.
Also removes the check for dahdi_dynamic_ioctl in process masterspan for
those users that never load a dynamic span.
This was originally suggested in a comment on:
(issue #13205)
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@9576 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2.6.9 is the earliest kernel version currently supported by DAHDI.
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@9575 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Move the try_module_get/module_put calls from the various dynamic
drivers into the "core" dahdi_dynamic.c file itself. This way, a
reference count can always be held while calling through the function
pointers. This is enabled by adding an .owner field to 'struct
dahdi_dynamic_driver'.
Dynamic spans are also unique in dahdi in that they require a "dahdi_cfg
-s" to stop them and release the references on the modules. This is
counterintuitive. This change makes sure they are reference counted just
like other spans and on driver unload, if there aren't any open handles
from userspace, they will take care of unwinding themselves.
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@9573 a0bf4364-ded3-4de4-8d8a-66a801d63aff
dahdi_dynamic can be converted to use kernel idiomatic reference
counting since DAHDI only supports 2.6.9+ kernels now.
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@9571 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Replaces all the 'z' references to 'd' as appropriate and cleans up any
formatting problems that popped up as a result. The intent here is to
reduce confusion in the future as someone may wonder what the 'Z's refer
to.
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@9567 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
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
