This virtual trunk device is a new character device. Contrary to
the per-channel devices, this is a per-span device for virtual E1
spans. Userspace reads and writes 32-byte E1 frames on it.
ioctl's are added to create and delete such virtual trunk devices
at runtime. Each virtual trunk device is limited to one span.
Opening trunkdev is similar to opening channels via /dev/dahdi/chan
works: All users open the same generic device node but then issue
an ioctl to specify which (named) trundev they actually want to open.
This avoids having to dynamically register minor device ids, creating
device nodes, etc.
The trunkdev is in RED + LOS alarm after creation. Only once a userspace
process opens the E1 frame side, those alarms cease.
Change-Id: Iffd9a1a09d835b29927acd374364cab56745fb74
This works around build failures with kernel >= v6.4-rc1 where
the DEFINE_SEMAPHORE macro is adjusted in upstream kernel commit
48380368dec14859723b9e3fbd43e042638d9a76
Change-Id: I752c903c8a0345af6e51a996d064c9d629578ab4
linux kernel commit 2a81ada32f0e584fc0c943e0d3a8c9f4fae411d6 modifies
the struct bus_type.uevent() argument from 'struct device *' to
'const struct device *'. Let's adjust our code to support that.
Change-Id: I0c416d8fa8d7d0081fdfec6325971d6de9f8d239
Modern Linux (since 5.4) builds with -Wimplicit-fallthrough=5. On some
environments (notably Debian buster) this is even an error, so building
dahdi-linux will fail.
Let's add the proper 'fallthrough' annotation of
linux/compiler_attributes.h and add a backwards-compatibility definition
for older kernels.
Change-Id: I3507876d90dd882b95c22ece51e8620ad6f0bd08
For automatic testing scenarios, it is very useful to be able to
artificially create line alarms. This allows testing of the whole
stack through DAHDI itself, DAHDI-interfaces in applications and
actual applications.
It introduces a new DAHDI_SIMULATE_ALARM ioctl() whcih has to be
issued on /dev/dahdi/ctl and which can be used to set or remove
any simulated alarms on the given span.
This fixes the build against kernels >= 5.18.0 which contain the
following commit removing teh pci-dma-compat API:
commit 7968778914e53788a01c2dee2692cab157de9ac0
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed Mar 9 20:50:39 2022 +0100
PCI: Remove the deprecated "pci-dma-compat.h" API
Change-Id: Ie05e5f42a5eef2dd0377fdc2c22b4a731619e372
This fixes the build against kernels >= 5.17.0 which contain the
following commit removing the PDE_DATA() macro:
commit 359745d78351c6f5442435f81549f0207ece28aa
Author: Muchun Song <songmuchun@bytedance.com>
Date: Fri Jan 21 22:14:23 2022 -0800
proc: remove PDE_DATA() completely
Change-Id: I5019aa36b76ae1ba4f56f6d15eef4b2f4c755405
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>
There are not any drivers in the tree that make reference to this definition
anymore, so it can be removed.
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>
This is mostly a revert of commit r9463. If you need to use DAHDI_CONFLINK
ioctl, make sure to define CONFIG_DAHDI_CONFLINK in
include/dahdi/dahdi_config.h. Apparently there were some users of CONFLINK out
there still.
It's a compile time option now since most users won't need to run the test for
conflinks in the hot-path that is the process_masterspan function.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Tested-by: Ted Gerold <ted@twg.org>
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
Martin Hauke
Harald Welte
Shaun Ruffell