- 29 Nov, 2021 6 commits
-
-
Harald Welte authored
-
Harald Welte authored
Especially for automatic testing it is quite useful to have virtual DAHDI spans with a loopback between them.
-
Harald Welte authored
-
Harald Welte authored
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>
-
Alexei A. Smekalkine authored
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
-
Alexander Couzens authored
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.
-
- 11 Sep, 2020 3 commits
-
-
Harald Welte authored
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>
-
Harald Welte authored
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.
-
Harald Welte authored
Since kernel commit 7ce2e76a0420801fb4b53b9e6850940e6b326433, ASPM definitions have moved from linux/pci-aspm.h to linux/pci.h
-
- 08 May, 2019 15 commits
-
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
`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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
The SUBDIRS environment variable is scheduled to be removed in version 5.0 of the Linux Kernel. Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
All supported kernels now use the same signature for the IRQ handler. Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
-
Shaun Ruffell authored
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>
-
Shaun Ruffell authored
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>
-
- 27 Nov, 2018 1 commit
-
-
Keith Morgan authored
-
- 05 Oct, 2018 1 commit
-
-
Keith Morgan authored
-
- 04 Oct, 2018 3 commits
-
-
Keith Morgan authored
-
Keith Morgan authored
add them back. This reverts commit a36d2662.
-
Keith Morgan authored
-
- 03 Oct, 2018 9 commits
-
-
Keith Morgan authored
-
Keith Morgan authored
-
Keith Morgan authored
-
Keith Morgan authored
-
Keith Morgan authored
-
Keith Morgan authored
-
Keith Morgan authored
-
Keith Morgan authored
-
Keith Morgan authored
-
- 01 Oct, 2018 1 commit
-
-
Keith Morgan authored
Author: Tzafrir Cohen <tzafrir.cohen@xorcom.com> Bug: https://issues.asterisk.org/jira/browse/DAHLIN-364
-
- 03 Sep, 2018 1 commit
-
-
Shaun Ruffell authored
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
-