In commit (d56c0d45f0e27 "proc: decouple proc from VFS with "struct proc_ops"")
[1], proc_create_data no longer takes a file_operations structure, but instead
takes a struct proc_ops in order to conserve memory in the kernel.
This change is necessary for DAHDI to work with kernels >= 5.6
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d56c0d45f0e27f814e87a1676b6bd
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Linux 5.4, in commit (7ce2e76a0420801fb4b53b9e685094 "PCI: Move ASPM
declarations to linux/pci.h") [1], removed pci-aspm.h.
This commit removes the global include of pci-aspm.h in include/dahdi/kernel.h
(because it only pertains to certain drivers), and moves the conditional include
into only the drivers that need it.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7ce2e76a0420801fb4b53b9e685094
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Ideally we want to standardize on storing all timestamps derivied from the
system clock as ktime_t values.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Older kernels (2.6.32) are unable to do a direct comparison of ktime
values, while kernels post 4.10 have removed the comparison function.
Therefore we need to make our own compatibility interface for comparing
the ktime values.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
This function will return the number of milliseconds between two ktime
values, but it was only introduced in kernel version 4.0
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
All supported kernel variations support the same signature for
registering a PCI module, so we can eliminate the macro.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
There are not any major distributions that are still supporting kernels
older than 2.6.27 so we can remove many typedefs. The primary motivator
for this change is that kernel 5.0 is dropping support for timeval and
it would be ideal if the in-kernel time representation can
standardize on ktime_t, but 2.6.18 did not support the ktime
interface that was needed.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Since Red Hat Linux backported the new timer_setup definition in 7.6, we
need to make sure to not define it ourselves when building against this
kernel.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
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
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>
These flags are direct mappings to the IRQF_[SHARED|DISABLED] flags and no
longer need to be kept separate.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
With commit (af3cd13501 "lib/string.c: remove strnicmp()") [1] dahdi can no
longer call strnicmp directly. strncasecmp was added into lib/string.c in kernel
version 2.6.22 so we'll map calls to strncasecmp to strnicmp for any kernel
before that.
This is necessary to compile against kernels >= 4.0.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=af3cd13501
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
With commit (d1f1052c52 "device: Change dev_<level> logging functions to return
void") [1] in kernel version 4.0, DAHDI would fail to compile with the following
error:
.../drivers/dahdi/dahdi-base.c:7150:2: error: void value not ignored as it ought to be
dahdi_dev_dbg(ASSIGN, span_device(span),
^
Now ignore the dev_printk return value.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1f1052c5204524
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
This closes a reference and memory leak when multiple CPUs are enabling echocan
on a single channel in parallel.
The essential problem is that the call to try_module_get() is not serialized.
Two separate threads can come into ioctl_echocan() on the same channel, they
coordinate via the dahdi_chan.lock to release any current echocan, but then both
create a new echocan state, bump the reference on the module, and the last one
through will actually attach the new state to the channel. The earlier reference
/ memory is leaked.
I tried to conceive of a way to fix this leak without adding a new lock, but the
choices where calling throught the function pointers with dahdi_chan.lock.
Otherwise I needed to change the semantics of echocan_create /free which would
ripple through the hardware echocan modules.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Normally the board drivers should define this, but if they do not we will
provide a suitable default. This allows compilation with vanilla Linux 2.6.18.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Commit 74e949c33a exported the module
variable dahdi.auto_assigned_spans. However this is not a good name.
This commit reverts the export and replaces it with a new function to
get the value of the variable.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Add a new sysfs attribute to dahdi_device: registration_time
* Records the time of the device's registration with DAHDI.
* Used by dahdi_auto_assign_compat to assign spans by device
registration order when backward compatibility needed.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Instead, use the inverse of dahdi.auto_assign_spans value.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
The previous commit from earlier today to fix the backport of PDE_DATA was
wrong in that it would not then process the other defines for older kernels if
it detected it was running on a redhat release.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
This will fix the "error: redefinition of 'PDE_DATA'" error when compiling.
Internal-Issue-ID: DAHLIN-330
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>
Rename as terminology has changed. No change in kernel interface.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Some older versions of Kbuild will not pass KBUILD_MODNAME to a
compilation unit that is linked to multiple drivers. This change works
around this issue by globally modifing dev_dbg in this case.
Signed-off-by: Shaun Ruffell <sruffell@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>
This was an accidental commit that slipped in as part of (a682401 "dahdi: Expose
dahdi devices in sysfs.")
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The __dev* directives and functions were removed in 3.8, as they
are no-ops. We still have use of them for older versions, thus
we should define them (as noops) if they don't exist.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
struct dahdi_count is not directly exposed to user space, so we can use the
native u32 type instead of __u32 to clarify that.
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>
* Added minimal infrastructure:
- A 'chan_device' member to struct dahdi_chan
- An empty 'device_attribute' array
- A 'bus_type' with its methods
- A 'device_driver' with its methods
- Initialization/Cleanup code
Signed-off-by: Oron Peled <oron.peled@xorcom.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
When DAHDI is bridging channels between two different cards, or a user is trying
to record from a channel on a card that is not using the same timing source as
the master span, it is possible to miss audio.
For example, given the following scenario:
<T1 Span> <---> <ISDN CARD> <---> <ANALOG CARD> <---> <local handset>
If DAHDI was set to natively bridge the call from the T1 span to the local
handset it is possible that system conditions could result in one of the cards
servicing their interrupt three times before the other card has a chance to.
Since there are currently only two conference buffers to pass audio between the
cards, one chunk (1ms) of audio will be dropped since the card servicing it's
interrupt more frequently will run out of space to copy audio for the other card
and will have emptied the audio buffer from the other card.
Increasing the number of conference buffers to eight greatly reduces the
probability of audio from being dropped under these conditions at cost of an
additional 72 (32-bit) or 96 (64-bit) bytes per DAHDI channel.
Internal-Issue-ID: DAHLIN-159, DAHDI-976
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@10726 a0bf4364-ded3-4de4-8d8a-66a801d63aff
When compiling against kernels 2.6.25, you could get the following error.
error: linux/pci-aspm.h: No such file or directory
This fixes a build regression introduced in r10556 "dahdi: Add
dahdi_pci_disable_link_state for kernel < 2.6.25." [1]
[1] http://svnview.digium.com/svn/dahdi?view=revision&revision=10556
Reported-by: Jean-Philippe Lord
Internal-Issue-ID: DAHLIN-299
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10705 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
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
This is needed because dev_name() is mapped to kobject_name() in a backport,
but the kobject name isn't set until after device_add(). The result would be
parentless devices would fail since dahdi would not think a name was set for
these devices.
For these systems, we'll set both the bus_id string and the underlying
kobject_name.
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@10561 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
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
