Quiets the following warnings that are a result of commit ("kbuild: rename
hostprogs-y/always to hostprogs/always-y"
5f2fb52fac15a8a8e10ce020dd532504a8abfc4e) [1]:
scripts/Makefile.lib:8: 'always' is deprecated. Please use 'always-y' instead
scripts/Makefile.lib:12: 'hostprogs-y' is deprecated. Please use 'hostprogs' instead
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5f2fb52fac15a8a8e10ce02
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
I am not aware of anyone who tests in this configuration, and I'm not
sure if it currently works. I'll remove any support for the time being
and can add it back in if someone comes forward needing support for it.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
gcc 10.x detected the following use of an uninitialized variable:
../drivers/dahdi/wctdm24xxp/xhfc.c: In function 'wctdm_init_b400m':
../drivers/dahdi/wctdm24xxp/xhfc.c:624:5: warning: 'x' may be used uninitialized in this function [-Wmaybe-uninitialized]
624 | if (*lastreg != (unsigned char)addr) {
| ^
../drivers/dahdi/wctdm24xxp/xhfc.c:2557:20: note: 'x' was declared here
2557 | unsigned char id, x;
|
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
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>
Found by GCC with -Wimplicit-fallthrough.
Also fix the log message to report that the mode was switched to J1 mode.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Quiets warnings like:
drivers/dahdi/dahdi-base.c:8494:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (chan->txstate != DAHDI_TXSTATE_OFFHOOK) break;
^
Needed since Linux 5.4 commit (a035d552a93bb9ef60487, "Makefile: Globally enable
fall-33bb9f2a0dc857ff869through warning") [1]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a035d552a93bb9ef6048733bb9f2a0dc857
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>
`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>
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>
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>
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.
* The variable eeprom_release_201 was added in the initialization
script of the FXS module to add a case where it is different from
101 mains.
* However, it tests for "201" and it should apply for any 20x.
* Remove the variable from the init script of module type 6 (new FXS)
as it was not used.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
The si32260 chip may enter a state of thermal alarm to avoid
overheating. This disables the channel.
This commit allows automatic restoring of the channel after a certain
timeout (poll_chan_linefeed, by default 30 seconds).
Adds a per-channel counter ("overheats") in
/proc/xpp/XBUS-<n>/XPD-<m>0/fxs_info to count such events.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
DAHDI gets notified of changes to battery status and hence to red alarm
on an FXO channel when the status changes. It thus needs to get notified
about it on "startup".
This startup was initially span registration. However following the
separation between device registration and span assignment, the
notification was sent after device registration, whereas it was ignored
if span was not assigned. It happened to work in most cases due to
delays.
This fix moves the startup notifications of battery status to the new
hook that is run on span assignment.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Add an phone device XPD method called 'span_assigned' that gets
called when the XPD's span is assigned.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
