Using those maintenance modes we can test the local (DAHDI channel)
and remote (trunkdev) sides indepdendent from each other.
Change-Id: I12cf9647fb6def38865aaac8ad6bbb58ebf7b5fd
If we don't do this, we always have a full FIFO at the time userspace
opens the trunkdev, adding latency for no good reason.
Change-Id: Ifbda3766309cc7d6be485073e36607bdd6742f3a
This virtual trunk device is a new character device. Contrary to
the per-channel devices, this is a per-span device for virtual E1
spans. Userspace reads and writes 32-byte E1 frames on it.
ioctl's are added to create and delete such virtual trunk devices
at runtime. Each virtual trunk device is limited to one span.
Opening trunkdev is similar to opening channels via /dev/dahdi/chan
works: All users open the same generic device node but then issue
an ioctl to specify which (named) trundev they actually want to open.
This avoids having to dynamically register minor device ids, creating
device nodes, etc.
The trunkdev is in RED + LOS alarm after creation. Only once a userspace
process opens the E1 frame side, those alarms cease.
Change-Id: Iffd9a1a09d835b29927acd374364cab56745fb74
After changing our CI environment to build with Debian 12,
GCC 12.2.0-14 fails to build linux-dahdi with Werror (default since
linux 5.15). Set -Wno-error=address to not fail the build.
/build/drivers/dahdi/xpp/xbus-core.c:116:13: error: the comparison will always evaluate as 'true' for the address of 'label' will never be NULL [-Werror=address]
/build/drivers/dahdi/dahdi_dynamic_ethmf.c:538:34: error: the comparison will always evaluate as 'true' for the address of 'name' will never be NULL [-Werror=address]
/build/drivers/dahdi/wcte13xp-base.c:2704:13: error: the comparison will always evaluate as 'true' for the address of 'xb' will never be NULL [-Werror=address]
Fixes: OS#6098
Change-Id: Ifc8fb605cb8e0de70e5556b127e22533cbe24c37
Linux kernel 6.4-rc1 has an API change for the class_create() function.
See upstream kernel git commit 1aaba11da9aa7d7d6b52a74d45b31cac118295a1
Change-Id: I5f7d25aa7516c470b943b9e8dfba20ca4206e378
This works around build failures with kernel >= v6.4-rc1 where
the DEFINE_SEMAPHORE macro is adjusted in upstream kernel commit
48380368dec14859723b9e3fbd43e042638d9a76
Change-Id: I752c903c8a0345af6e51a996d064c9d629578ab4
In >= 6.3.0 the default for how modules are built in absence of
vmlinux.o or Module.symvers due to a change of the modpost execution.
See linux kernel git commit 5573b4daa26a0cf15aa0fecd7f1be16e0b6157bc
As our build verification *just* builds the dahdi modules without
building the entire kernel, we need to enforce the legacy behaviour
by adding KBUILD_MODPOST_WARN=1 to the command line.
Change-Id: I7206f1daed8ff1e7fcd4894bc24e5ef4d4590358
linux kernel commit 2a81ada32f0e584fc0c943e0d3a8c9f4fae411d6 modifies
the struct bus_type.uevent() argument from 'struct device *' to
'const struct device *'. Let's adjust our code to support that.
Change-Id: I0c416d8fa8d7d0081fdfec6325971d6de9f8d239
Sometimes it is useful to look at compiler warnings:
dahdi-sysfs-chan.c:384:17: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
And indeed, we could have de-referenced a NULL pointer here.
Change-Id: I4274e7a92ca6ee7e92c6adb713fb89ffe31b4c72
The address list has been converted to a tree, so netdev->dev_addr
is now const and must not be written directly. The __dev_addr_set
helper can be used for this.
Change-Id: Id7b71164dfe7772b68e86cb12ac0e0974fec1498
Modern Linux (since 5.4) builds with -Wimplicit-fallthrough=5. On some
environments (notably Debian buster) this is even an error, so building
dahdi-linux will fail.
Let's add the proper 'fallthrough' annotation of
linux/compiler_attributes.h and add a backwards-compatibility definition
for older kernels.
Change-Id: I3507876d90dd882b95c22ece51e8620ad6f0bd08
The 'struct dahdi_lineconfig.sync' parameter originates from the
'timing' field of system.conf. dahdi_cfg passes it via the SPANCONFIG
ioctl into the kernel.
The DAHDI docs say:
> source of the master clock. If you choose 0, the port will never
> be used as a source of timing. This is appropriate when you know the
> far end should always be a slave to you.
So if '0' we should use the local clock, and if > 0, the recovered
remote clock.
Thanks to Christoph Lauter for pointing this out.
Change-Id: If35a5a52c094129c342d0f658f496b488d1826ad
pseudo channels are characterized by the fact that they have their span
member set to NULL. This is illustrated by the is_pseudo_chan()
function.
However, when using RXMIRROR/TXMIRROR, __putbuf_chunk() is called not
just on the real channel, but also on the mirror (pseudo) channel.
Hence, __putbuf_chunk() and friends must not dereference the ->span
member without first checking that this channel actually does have
a non-NULL span assigned.
I originally thought that those unconditional de-references must have
been introduced after the RXMIRROR/TXMIRROR was merged - but checked the
git history and it seems like the bug has been present ever sicne
this functionality was merged in 2010 in commit
9090c6fcd2
Change-Id: I747a696c9a5865c11461b6357a10346a8d0d1621
Closes: OS#5531
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
* 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
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
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.
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.
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 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.
Harald Welte
Jaco Kroon
Oliver Smith
Martin Hauke
Manawyrm