This reverts commit 3748456d22,
which removed a driver simply becuase Digium proclaimed they didn't
sell a card in 10 years. That does *not* mean nobody is using those
anymore.
I wish there was more of a community maitaining the DAHDI drivers.
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
Ever since commit ad7eab2ab014748b062507b7ac69f8e856057717
"net: split out ndo_siowandev ioctl" has been merged in 5.15-rc1,
DAHDI failed to compile with DAHDI_NET enabled due to slight differences
in handling the HDLC/WAN device related ioctl.
Signed-off-by: Harald Welte <laforge@gnumonks.org>
The HDLC encapsulation module can add its own headers and trailers to
the packet. For correct operation in this case, it is necessary to send
a packet from DAHDI to the appropriate HDLC handler. The HDLC handler,
in turn, should call the device driver procedure to transfer the packet.
Thus, for correct processing of outgoing packets, we should use function
hdlc_start_xmit from Linux HDLC stack as a ndo_start_xmit procedure.
(Note that if the protocol handler does not provide a xmit procedure,
then function hdlc_start_xmit will call the hardware driver directly.)
In the case of DAHDI, the packet transfer procedure (device driver xmit
procedure) is set in function dahdi_ioctl_chanconfig to dahdi_xmit:
dev_to_hdlc(chan->hdlcnetdev->netdev)->xmit = dahdi_xmit;
Asterisk-Issue: DAHLIN-381
With 5.9 the macros HAVE_UNLOCKED_IOCTL and HAVE_COMPAT_IOCTL are gone.
I didn't figured out when they were added because it predates git (2.6.12).
I don't know if there are any user or if the current dahdi driver even builds with such an old
linux kernel version.
In linux kernel commit 4d659fcb20d3d3302b429c889a73a92ff2804b9a
in May 2016, netdev->trans_start was removed and write accesses
are replaced with this helper: netif_trans_update(dev)
This makes dahdi-base.c compile against kernels >= 4.7
when CONFIG_DAHDI_NET is enabled.
Signed-off-by: Harald Welte <laforge@osmocom.org>
In kernel commit d56c0d45f0e27f814e87a1676b6bdccccbc252e9, procfs
switched from 'struct file_operations' to 'struct proc_ops'; we need
to change DAHDI to build with those more recent kernels.
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>
`struct timeval` has been removed from the kernel interface in 5.0 as
part of fixing the 2038 problem. ktime_t is the preferred kernel time
interface now.
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>
Use the new ktime_t based interface for dahdi_dummy as well. dahdi_dummy
is still useful to keep around for testing purposes.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
It looked like the recent change to add support for timer_setup was not
completely implemented / tested with dahdi_dummy. I was using it to
check some changes to the timekeeping API when I noticed this.
This does not really affect anyone since, by default, dahdi_dummy is no
longer built and even if it was built, it would not use the standard
timer interface by default on newer kernels.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Since this is only used internally, and ktime is the basis for
timekeeping in the kernel, this allows this interface to be validated,
before converting the other internal timekeeping to it.
This is part of the changes necessary to remove the use of 'struct
timeval' from the driver suite for compatibility with Linux 5.0, which
is updating the internal timekeeping interfaces to fix the 2038 problem.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
The timeval structure is removed in Linux kernel 5.0 since it is not
year 2038 safe. Standardize on 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 versions use the same signature for device_create /
device_destroy so we no longer need these macros.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
ENABLE_WORKQUEUE was only defined for kernels that were older than the
currently supported kernels. Instead of forward porting support for
workqueues in the wct4xxp driver, I think it better just to remove
support for them since they are not longer used.
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
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.
Quiets the following (valid) warning from gcc 7.3.0:
drivers/dahdi/voicebus/GpakApi.c:1648:22: warning: ‘MsgBuffer[1]’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
MsgBuffer[1] |= DTMF_UPDATE_MASK;
This fixes an error and quiets the following warning pointed out by gcc 7.3.0:
warning: ‘memset’ used with length equal to number of elements without
multiplication by element size [-Wmemset-elt-size] memset(chan->conflast, 0,
DAHDI_MAX_CHUNKSIZE);
Previously only the first half of the conference buffers were cleared out.
Harald Welte
Alexei A. Smekalkine