uSB: uslcom: CP2102 weirdness when serial communication via cu/tip/cutecom

Hello,

I'm facing some strange behaviour when connecting to a CP2102 USB-UART bridge built-in into
a I2C-USB device (I2C is handled by an Amtel88, USB-UART is handled by an CP2102, see here:

https://de.elv.com/pc-usb-i2c-interface-200958 

for an sketch/overview. The device is recognised as
 
uslcom0 on uhub6
uslcom0: <ELV USB-I2C-Interface> on usbus0

for more details via usbconfig see below.

Using FreeBSD CURRENT and 14-STABLE (both most recent) connecting to the device via 

cu -l /dev/cuaUX -s 115200

results in most cases in a stuck connection. The LED of the device is responding to every
keystroke made in the terminal, but I never see any output (which should).
In some rare cases disconneting and reconnecting the USB link and connecting via "cu" gives
the opportunity for a couple of seconds to enter "?" in the terminal which provides some
firmware data on the device - then the communications goes dark. This behaviour is erratic and
non predictable.

I tried several platforms (hardware), all USB 3, tried FreeBSD 14-STABLE and CURRENT. On a
notebook (Lenovo T560) running 14-STABLE the very same situation, but trying the Lenovo with
Xubuntu 23.10 gives me a working "cu" and I'm able reading environmental data from the device.

Using the methusalem USB 2 port of a computer were available gives me a few seconds more on
FreeBSD, before the serial connection goes mute.

In cases were possible I tried the same hardware with FreeBSD and Linux Xubuntu, FreeBSD
fails, Xubuntu prevails the task. At this point I was quite sure that FreeBSD's uslcom-driver
might be the culprit.

Out of couriosity I tried a FSBD-13.2RELENG image for AARCH64 (PINE64 I have at hand) and
connected the same way, the same device acts as normal as I see under Linux Xubuntu. I'm able
to take environmental data as long as I please without a problem so far.

Can someone hint me how to debug such a situation? I'm unwilling to use Linux since our
infrastructure is based on FreeBSD and ... well, no further explanation on that subject ;-)

Thanks in advance,

O. Hartmann
-- 
O. Hartmann