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.
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]
This works around build failures with kernel >= v6.4-rc1 where
the DEFINE_SEMAPHORE macro is adjusted in upstream kernel commit
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.
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.
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.
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.
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.
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
Thanks to Christoph Lauter for pointing this out.
pseudo channels are characterized by the fact that they have their span
member set to NULL. This is illustrated by the is_pseudo_chan()
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
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)
* 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
Build the kernel module against a given linux tree. This script will be
used in CI at jenkins.osmocom.org.
Depends: docker-playground Id72d19ad08681cd7cb3194de2226292f19e96df5
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
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.
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.
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
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
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
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
I wish there was more of a community maitaining the DAHDI drivers.