[Regression] "serial: 8250: use THRE & __stop_tx also with DMA" breaks DMA rx

From: Hans de Goede <hdegoede@redhat.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>
Cc: "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
	"regressions@lists.linux.dev" <regressions@lists.linux.dev>
Subject: [Regression] "serial: 8250: use THRE & __stop_tx also with DMA" breaks DMA rx
Date: Tue, 14 Mar 2023 11:20:12 +0100	[thread overview]
Message-ID: <7f18e19d-4072-0609-afd0-244b06103b9c@redhat.com> (raw)

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 ?