The OpenVox A1610P/A1610E/A2410P/A2410E series cards all appear to share
a design flaw, where wild DMA reads are occassionally emitted from the card.
We suspect this design flaw is related to setup timing for the address bus
inside the FPGA PCI controller not being met, as it seems temperature dependent
and is largely, if not completely, eliminated by ensuring the upper 14 address
bits of the PCI bus are never set and forcing the link speed to 2.5GT/s.

As all wild DMA, even wild DMA read, is caught by the advanced PCIe controllers
on high availability platforms (mostly OpenPOWER, such as Talos II / Blackbird),
these cards will regularly drop offline due to the PCIe interface freezing and
invoking the EEH handler.  Since recovery from this state without a full reload
of Asterisk and DAHDI, along with the driver module, is not guaranteed, the wild
DMA presents a significant problem for high availability analog PBX servers.

For now, work around the broken hardware by setting a DMA mask of 14 bits.
Should OpenVox fix the problem in future hardware / firmware revisions,
the DMA mask can be reset to the standard 32 bits for this type of PCI device.

The voice card generates an interrupt every 1ms, effectively operating
in real time.  Since migrating the IRQ between CPUs can, in some cases,
cause the card to lose sync due to the added delay from migration,
lock the interrupt to CPU0 for now.

Add initial EEH fast recovery support

This is required to work around presumably bad card-side firmware
randomly (hours/days/weeks) performing bad DMA writes to the host (!)

Example PHB fence event:

[53811.103878] EEH: Recovering PHB#1-PE#fc
[53811.103904] EEH: PE location: UOPWR.D100022-Node0-SLOT1 PCIE 4.0 X16, PHB location: N/A
[53811.103917] EEH: Frozen PHB#1-PE#fc detected
[53811.103942] EEH: Call Trace:
[53811.103968] EEH: [000000009c27f02d] __eeh_send_failure_event+0x78/0x150
[53811.103997] EEH: [000000009006781a] eeh_dev_check_failure+0x380/0x670
[53811.104030] EEH: [00000000ebe9b5df] __opvx_a24xx_getcreg+0x7c/0xb0 [opvxa24xx]
[53811.104073] EEH: [000000005a792683] interrupt_onecard_handler+0x80/0xdc0 [opvxa24xx]
[53811.104115] EEH: [00000000903815aa] a24xx_interrupt+0xe8/0x120 [opvxa24xx]
[53811.104159] EEH: [0000000061324081] __handle_irq_event_percpu+0x11c/0x4b0
[53811.104203] EEH: [000000008d7d81ec] handle_irq_event_percpu+0x38/0x90
[53811.104244] EEH: [0000000078120288] handle_irq_event+0x60/0xa0
[53811.104286] EEH: [000000008b3623f1] handle_fasteoi_irq+0xd4/0x270
[53811.104318] EEH: [0000000042e6cb54] generic_handle_irq+0x54/0x80
[53811.104366] EEH: [0000000071e8585e] __do_irq+0xa0/0x380
[53811.104399] EEH: [00000000b76ddee5] __do_IRQ+0x9c/0x130
[53811.104440] EEH: [00000000aa5e1b3f] 0xc000000004373b10
[53811.104474] EEH: [000000006d701fc8] do_IRQ+0xfc/0x1d0
[53811.104524] EEH: [0000000070ff629f] replay_soft_interrupts+0x1c4/0x320
[53811.104555] EEH: [0000000095e31904] arch_local_irq_restore+0x1e4/0x250
[53811.104597] EEH: [0000000047c9e272] cpuidle_enter_state+0x158/0x720
[53811.104639] EEH: [00000000904e539f] cpuidle_enter+0x50/0x70
[53811.104680] EEH: [00000000b5de9adb] call_cpuidle+0x4c/0x90
[53811.104721] EEH: [000000008d8e2164] do_idle+0x320/0x3a0
[53811.104761] EEH: [00000000d680deba] cpu_startup_entry+0x3c/0x50
[53811.104784] EEH: [000000006146f980] start_secondary+0x27c/0x2d0
[53811.104820] EEH: [00000000cb4eb9c4] start_secondary_prolog+0x10/0x14
[53811.104849] EEH: This PCI device has failed 2 times in the last hour and will be permanently disabled after 5 failures.
[53811.104902] EEH: Notify device drivers to shutdown
[53811.104918] EEH: Beginning: 'error_detected(IO frozen)'
[53811.104931] PCI 0001:02:00.0#00fc: EEH: driver not EEH aware
[53811.104935] EEH: Finished:'error_detected(IO frozen)' with aggregate recovery state:'none'
[53811.104958] EEH: Collect temporary log
[53811.104988] EEH: of node=0001:02:00.0
[53811.104999] EEH: PCI device/vendor: 16101b74
[53811.105011] EEH: PCI cmd/status register: 04080146
[53811.105020] PHB4 PHB#1 Diag-data (Version: 1)
[53811.105030] brdgCtl:    00000002
[53811.105038] RootSts:    00060000 00402000 20110008 00100107 00000800
[53811.105049] PhbSts:     0000001c00000000 0000001c00000000
[53811.105059] Lem:        0000000100000080 0000000000000000 0000000000000080
[53811.105070] PhbErr:     0000028000000000 0000020000000000 2148000098000240 a008400000000000
[53811.105082] RxeTceErr:  6000000000000000 2000000000000000 c0000000000000fc 0000000000000000
[53811.105095] PblErr:     0000000000020000 0000000000020000 0000000000000000 0000000000000000
[53811.105107] RegbErr:    0000004000000000 0000004000000000 8800003c00000000 0000000000000000
[53811.105120] PE[0fc] A/B: 8300b03800000000 8000000000000000
[53811.105130] EEH: Reset with hotplug activity

Decoded PEST A/B:

Transaction type: DMA Read Response
Invalid MMIO Address
TCE Page Fault
TCE Access Fault
LEM Bit Number 56
Requestor 00:0.0
MSI Data 0x0000
Fault Address = 0x0000000000000000

From GIT hash 1129c666

If one of the isochronous or the interrupt EP URB cannot be submitted,
we should clean-up properly and avoid hanging the dahdi_cfg process
at 100% CPU itilization in an un-killable state.

Closes: OS#5477 (https://osmocom.org/issues/5477)
Change-Id: Ie6f7f11a64fae0d8c2b7c8ae90df886f2eb8f0c2

There's not really any reason to disable those, from what I can tell.

Change-Id: Ib03074062ada7b6da485afac53b1550d31f1a5ca

Change-Id: I54d3000d4535b9279f53a8c30870e897bdcf0f91

This ports the current zaphfc driver from the Debian bullseye patchset.

Change-Id: Ifd09d82ea2b6d6245207609da849350db45d91f6

* ability to read GPSDO related bits via sysfs and ioctl
* ability to set GPSDO mode via sysfs
* show firmware build during driver start and expose it to sysfs

Change-Id: I7bc7daa4738b1db37fdd67945d7e976e2581b417

git revision cac342af6bccc9820a8617f900afaf663ad608ed of
https://git.osmocom.org/osmo-e1-hardware

Change-Id: I1423531470a1c9165d713108fb6a87ff47ff6e29

Build the kernel module against a given linux tree. This script will be
used in CI at jenkins.osmocom.org.

Related: OS#5407
Depends: docker-playground Id72d19ad08681cd7cb3194de2226292f19e96df5
Change-Id: I904ab66a1ecd72492642ac2cc4cb102c7283c590

Kernel version 5.8, in commit "modpost: use read_text_file() and
get_line() for reading text files" [1] made it an error if the .o.cmd
file is missing. However, this file is not generated for shipped .o
files.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70f30cfe5b892fcb7f98e7df72ed6ccfe3225628Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Change-Id: I06d201bcd07b35cb41c8c4a8467bcad6471c431a

This seems to be the kernel default for CTRL request timeout,
let's use it here.

Change-Id: I7b7c1a2b13f61372e839e34a376e66c91190bdb3

Change-Id: I36438e35bb99325e1ac86b68c1746670a9851e4a

If an already-active line gets reconfigured, we implement this by
a shutdown followed by a startup.  However, the startup could fail,
which should make the spanconfig return the error code.

This is what happens if there is insufficient isochronous USB bandwidth
to open a port: The STARTUP ioctl fails.  However, as the prior
SPANCONFIG ioctl succeeds, the line apears up with no alarms.

So let's set the NOTOPEN alarm whenever there are errors in STARTUP,
to give a clear indication to the user the port could not be opened.

find_altsetting_on() must not only find an altsetting with no
zero-sized endpoints, but must also make sure there actually
are endpoints.

This enables compatibility with icE1usb firmware >= 0.1-43-g9674436

The XAIS bit to check in the FRS0 register is at 0x40, and not 0x4.

If only the original authors had the wisdom to use #defines for those
bits, and re-used those bits across the drivers (wct4xxp, wcte43x
and wcte13xp get this right!).

In osmo-e1-hardware.git Change-Id Ic4f57cf79bd32cf75f81ef3073cb8d4a2d1857d8
the icE1usb firmware gained support for reporting the E1_ERR_F_RAI flag
via USB interrupt transfers.  Make use of that to report YELLOW alarm
via the usual DAHDI alarms infrastructure.

This adds support of configuring the icE1usb TX configuration via the
standard DAHDI mechanisms.

We get loss-of-framing and loss-of-signal notification via USB interrupt
transfers.  Let's make use of this information to tell the DAHDI core
[and ultimately the user] about this.

Copy from firmware source code repo at
https://git.osmocom.org/osmo-e1-hardware/tree/firmware/ice40-riscv/icE1usb/ice1usb_proto.h
as of d376b2e852fbf26a60ac4d6f66e54bb85f0b7204

Before this commit, we used to "lock up" the E1 span on every subsequent
span re-configuration from userspace.  This typically happens when the
user calls the `dahdi_cfg` userspace utility.  As normally this only
happens once at system start-up, this bug was only discovered now.

Closes: OS#5379

The Osmocom icE1usb is a modern, software-defined open hardware and
open source firmware design for a USB E1 interface.  You can find more
information at https://osmocom.org/projects/e1-t1-adapter/wiki/IcE1usb

The hardware design can be found at https://git.osmocom.org/osmo-e1-hardware

The FPGA gateware and associated embedded firmware is hosted in the same
git repository. Some parts are in submodules (be sure to use recursive
clone)

This DAHDI driver allows t lothe use of the icE1usb just like any other
E1/PRI interface device supported by DAHDI.  When using this DAHDI
driver, osmo-e1d most not be used.  The DAHDI driver is a replacement /
alternative for osmo-e1d.

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.

It recently occurre to me that for some strange reason the line/link
status of the E1 span was not reflected in the network device link
status.  This is odd and leads to strange behavior.

In general, it is assumed that a net_device only exhibits LOWER_UP
if there actually is a physical connection.  If you disconnect an
ethernet cable, LOWER_UP will be gone.  Same should happen on
DAHDI_NET devices.

This reverts commit 36974503.

This reverts commit 3748456d,
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.

Especially for automatic testing it is quite useful to have virtual
DAHDI spans with a loopback between them.