Hi Ilpo,
I have spend the last couple of days debugging a problem with Bluetooth
adapters (HCIs) connected over an UART connection on Intel Bay Trail
and Cherry Trail devices.
After much debugging I found out that sometimes the first byte of
a received packet (data[0]) would be overwritten with a 0 byte.
E.g. this packet received during init of a BCM4324B3 (1) Bluetooth HCI:
04 0e 0a 01 79 fc 00 54 fe ff ff 00 00
would sometimes turn into:
00 0e 0a 01 79 fc 00 54 fe ff ff 00 00
Further investigation revealed that this goes away if I stop
the dw_dmac module from loading, leading to:
"dw-apb-uart 80860F0A:00: failed to request DMA"
and the UART working without DMA support.
Testing various kernels showed that this problem was introduced
in v5.19, v5.18 - v5.18.19 are fine. An a git bisect points to:
e8ffbb71f783 ("serial: 8250: use THRE & __stop_tx also with DMA")
And reverting that on top of v6.3-rc2 indeed solves the problem.
So it seems that that commit somehow interferes with DMA based
data receiving, causing the first byte of a received data transfer
to get replaced by 0.
The issue has been seen on and the revert has been tested on
the following HW:
Asus T100TA
SoC: Bay Trail UART: 80860F0A WIFI: brcmfmac43241b4-sdio BT: BCM4324B3
Lenovo Yoga Tablet 2 1051L
SoC: Bay Trail UART: 80860F0A WIFI: brcmfmac43241b4-sdio BT: BCM4324B3
Lenovo Yoga Book X91F
Soc: Cherry Trail UART: 8086228A WIFI: brcmfmac4356-pcie BT: BCM4356A2
I have more hw which I believe is affected but these are the models
where I have done detailed testing.
I would be happy to test any patches, or run a kernel with some extra
debugging added, just let me know what you need to help fixing this.
Regards,
Hans
p.s.
I believe that these changes were made to improve the timing of
disabling the transmitter on tx completion when the UART is used
for a RS485 bus. So one option to workaround this might be to only
enable the new behavior when RS485 mode is used ?
