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.
The cards affected include the TE131/3, TE235/435, A4B, and A8B.
Update all PCIe cards' firmware to increase the incoming and outgoing TDM FIFOs
to 16ms. The FIFOs will only be filled to a depth equal to the driver's latency
setting (ie. 3ms default). The total system latency is not effected. The
firmware and driver now also report the maximum DMA transaction time when in
DEBUG mode to aid in determining if the system is experiencing long PCIe
transactions (ie. TLP completion timeouts).
Decreased the maximum latency to from 20 to 12ms
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
A fresh modprobe and dahdi_cfg would cause a temporary green alarm state on the
driver for a second while the alarm debounced into RED. New logic keeps the
spans alarm state as NONE during the unconfigured state, but sets the alarm
state to RED after the framer reset in the startup logic.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
If dahdi_span_ops.spanconfig is called multiple times in a row (like when
running dahdi_cfg; dahdi_cfg ) the tx signaling bits would go through a spurious
state that some far side devices would respond to.
Now, if the dahdi_span_ops.spanconfig callback is called, and the configuration
matches the existing configuration, we will not touch the framer.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
If dahdi_cfg set the DAHDI_CONFIG_NOTOPEN setting on the span, which it does
when the "yellow" flag is added to the span config line, then it was possible
for the span to get stuck with DAHDI_ALARM_NOTOPEN (NOP).
This is because the wcte13xp driver only updates the alarm state when the framer
reports that the span alarm has changed. Therefore, unless the framer goes
through an alarm transition, the fact that channels are opened was never noticed
by alarm handling routine.
Now check the alarm state directly when the first channel is opened, and the
last channel is closed.
Internal-Issue-ID: DAHDI-1103
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This firmware image is able to handle system conditions that would result in
spans going down and then coming back intermittently.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Allow certain older firmwares to delay the hard reset until a full power cycle.
This way we can "preload" newer firmware images, without requiring the user to
physically power off/on their machine.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
This makes the behavior of IRQ misses for these drivers behave the same as the
wcte12xp, wctdm24xxp, and wct4xxp drivers.
Previously irqmisses would never increase. The presence of underruns would still
show up in dmesg as latency bumps.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This was a legacy compile time option that is no longer necessary with the new
series of cards.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
struct dahdi_device.devicetype was set incorrectly in both drivers. This caused
the vpm module to not show up after the device name when reading this field
from a spanstat.
Reported-by: Charles Moye <cmoye@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
It was an oversight to prevent the wcte43x and wcte13xp drivers from using
Message Signaled interrupts during the switch to the wcxb library.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
wcte13xp now has a max_latency module parameter like the wcaxx and wcte43x
drivers.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
A bug introduced in v2.8.0 prevented the recover timing configuration from
being set properly on the hardware. This caused the card to never go into
recovered timing mode.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Rus Meyerriecks <rmeyerriecks@digium.com>
* Removed work queue for maint interface as it is not needed in this driver
* Error counters are now accessible through the maint interface
* Consolidated and revised the big maint switch case
* Added loopup/loopdown code transmit logic to E1
* Now supports error/defect insersion
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Russ Meyerriecks <rmeyerriecks@digium.com>
The framer appears to continue transmitting a signal after modprobe -r. This
patch will leave the physical framer reset pin asserted to force the chip to
stop transmitting a signal when there is no driver attached.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Russ Meyerriecks <rmeyerriecks@digium.com>
Removed all the custom logic and replaced with the common platform wcxb stuff.
There are also changes in here to standardize the function prefix in this
driver to t13x_.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
From: Wendell Thompson <wthompson@digium.com>
Now uses framer interrupt vector polling (in the FPGA interrupt) for
alarm, loopcode, and signaling events eliminating continuous polling.
Now uses timer function for alarm and loopcode debouce, which only
executes during exception conditions.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The octasic library is relatively large and is currently separately linked into
both the wcte13xp and wct4xxp libraries. This change moves it out into a
separate loadable module.
The bigest change from the drivers perspectives is that they must provide a
table of callbacks instead of using statically linked Oct6100UserXxxxx functions
to allow the library to communicate with actual parts on the cards.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
With certain pci controllers that support pci hotplug, during the reset
sequence of the fpga, the host controller can get confused about the state of
the card and throw an nmi.
Known affected systems:
HP proliant DL160 & DL360p
Dell poweredge R520
Super Micro X7SPA-HF
This patch attempts to work around that by removing the fpga reset sequence
from the driver startup, then setting various control registers to known
starting state values.
This patch removes the field upgradeable firmware logic temporarily for the
te133 card to prevent fpga reset.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
This was causing inconsistancies with dahdi_scan showing an "UNCONFIGURED" span
in the "RED" state.
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
