* [PATCH v2 0/2] serial: 8250_of: RS-485 on Microchip Core16550
@ 2026-11-09 2:55 Kohei Otsuka via B4 Relay
2026-11-09 2:55 ` [PATCH v2 1/2] dt-bindings: serial: 8250: add " Kohei Otsuka via B4 Relay
2026-11-09 2:55 ` [PATCH v2 2/2] serial: 8250_of: drop RS-485 RTS on " Kohei Otsuka via B4 Relay
0 siblings, 2 replies; 5+ messages in thread
From: Kohei Otsuka via B4 Relay @ 2026-11-09 2:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lubomir Rintel, devicetree
Cc: linux-kernel, linux-serial, conor.dooley, Kohei Otsuka
Core16550 is a 16550-compatible UART soft IP for Microchip FPGAs. We use
four of them in the fabric of a PolarFire SoC Icicle Kit as RS-485
ports, described as "ns16550a" with linux,rs485-enabled-at-boot-time.
With RS-485 enabled, RTS (the transceiver's driver enable) goes high at
the start of the first transmission and never drops, and the port stops
receiving. Core16550, like the original 16550A, raises no interrupt on
TEMT, so __stop_tx() waits for one forever unless the port has
UART_CAP_NOTEMT, which 8250_of never sets.
Testing, on a PolarFire SoC Icicle Kit with four Core16550 instances
on FIC3 (PCLK 50 MHz), linux-mchp 6.18.17 with this series applied
and the ports described as "microchip,core16550-rtl-v3", "ns16550a",
115200 8N1, against USB-RS485 (2-wire, half duplex) and USB-RS422
(4-wire) converters:
- All four ports transmit and receive correctly with both converters.
- On RS-485, each port keeps receiving after transmitting, across
repeated request/response exchanges in both directions.
- Without the series, RTS stays high after the first transmission and
nothing more is received.
This series was prepared with the help of an AI coding assistant
(Claude, Anthropic): the analysis of __stop_tx(), both patches and
these messages. I reviewed and tested the result and take
responsibility for it.
Link: https://github.com/linux4microchip/meta-mchp/issues/5
Signed-off-by: Kohei Otsuka <kohei@spacemachines.com>
---
Changes in v2:
- dt-bindings: rename the compatible to microchip,core16550-rtl-v3,
following the -rtl-vN convention of Microchip's other fabric cores
(Conor)
- dt-bindings: explain in the commit message why ns16550a remains a
valid fallback (Conor)
- 8250_of: match microchip,core16550-rtl-v3
- Dropped Krzysztof's Acked-by on 1/2, as the compatible changed
- Link to v1: https://patch.msgid.link/20261103-core16550-rs485-v1-0-6d15ebe1e5b9@spacemachines.com
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jiri Slaby <jirislaby@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Lubomir Rintel <lkundrak@v3.sk>
To: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-serial@vger.kernel.org
---
Kohei Otsuka (2):
dt-bindings: serial: 8250: add Microchip Core16550
serial: 8250_of: drop RS-485 RTS on Microchip Core16550
Documentation/devicetree/bindings/serial/8250.yaml | 1 +
drivers/tty/serial/8250/8250_of.c | 10 ++++++++++
2 files changed, 11 insertions(+)
---
base-commit: c339f4010dea8b0d754f84ace70cd1b089878ef8
change-id: 20261103-core16550-rs485-505af0ffaeeb
Best regards,
--
Kohei Otsuka <kohei@spacemachines.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH v2 1/2] dt-bindings: serial: 8250: add Microchip Core16550
2026-11-09 2:55 [PATCH v2 0/2] serial: 8250_of: RS-485 on Microchip Core16550 Kohei Otsuka via B4 Relay
@ 2026-11-09 2:55 ` Kohei Otsuka via B4 Relay
2026-11-09 2:59 ` sashiko-bot
2026-11-09 2:55 ` [PATCH v2 2/2] serial: 8250_of: drop RS-485 RTS on " Kohei Otsuka via B4 Relay
1 sibling, 1 reply; 5+ messages in thread
From: Kohei Otsuka via B4 Relay @ 2026-11-09 2:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lubomir Rintel, devicetree
Cc: linux-kernel, linux-serial, conor.dooley, Kohei Otsuka
From: Kohei Otsuka <kohei@spacemachines.com>
Core16550 is a 16550-compatible UART soft IP core for Microchip FPGAs,
including the fabric of PolarFire SoC. Its registers, interrupts and
baud rate divisor follow the 16550A, so a driver that knows only
ns16550a operates it fully: transmit, receive, FIFOs and modem control
all work. What the generic driver cannot know is that the core raises
no interrupt on TEMT, which it needs to drop RTS after a frame in
software RS-485 mode (em485). ns16550a therefore stays a valid
fallback, with RS-485 RTS control the one feature that needs the
specific compatible.
Add microchip,core16550-rtl-v3 with ns16550a as the fallback. As for
Microchip's other FPGA fabric cores, the -rtl-v3 suffix is the major
RTL version of the IP, Core16550 3.x.
Link: https://github.com/linux4microchip/meta-mchp/issues/5
Signed-off-by: Kohei Otsuka <kohei@spacemachines.com>
---
Documentation/devicetree/bindings/serial/8250.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml
index 50d5c977afa3..6f806b972f5c 100644
--- a/Documentation/devicetree/bindings/serial/8250.yaml
+++ b/Documentation/devicetree/bindings/serial/8250.yaml
@@ -137,6 +137,7 @@ properties:
- ti,da830-uart
- loongson,ls2k0500-uart
- loongson,ls2k1500-uart
+ - microchip,core16550-rtl-v3
- const: ns16550a
- items:
- enum:
--
2.53.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH v2 2/2] serial: 8250_of: drop RS-485 RTS on Microchip Core16550
2026-11-09 2:55 [PATCH v2 0/2] serial: 8250_of: RS-485 on Microchip Core16550 Kohei Otsuka via B4 Relay
2026-11-09 2:55 ` [PATCH v2 1/2] dt-bindings: serial: 8250: add " Kohei Otsuka via B4 Relay
@ 2026-11-09 2:55 ` Kohei Otsuka via B4 Relay
2026-11-09 3:03 ` sashiko-bot
1 sibling, 1 reply; 5+ messages in thread
From: Kohei Otsuka via B4 Relay @ 2026-11-09 2:55 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lubomir Rintel, devicetree
Cc: linux-kernel, linux-serial, conor.dooley, Kohei Otsuka
From: Kohei Otsuka <kohei@spacemachines.com>
Core16550, a 16550-compatible UART for Microchip FPGAs, interrupts on
THRE but not on TEMT. When the last character moves from the FIFO into
the shift register, the THRE interrupt calls __stop_tx(), which finds
TEMT clear and, without UART_CAP_NOTEMT, returns to wait for a TEMT
interrupt that never comes. RTS, and with it the RS-485 driver enable,
then stays asserted after the frame, and receive interrupts, disabled
for the half-duplex transmission, stay off.
Set UART_CAP_NOTEMT for nodes compatible with
"microchip,core16550-rtl-v3", so em485 drops RTS from its stop timer
one frame time (plus 1/7) after THRE, as it does for DesignWare UARTs.
Set UART_CAP_FIFO as well: with the capabilities already non-zero,
serial8250_do_startup() no longer fills in the PORT_16550A default,
and without UART_CAP_FIFO serial8250_clear_fifos() does nothing, so
the RX FIFO is not flushed at the end of a half-duplex transmission.
Link: https://github.com/linux4microchip/meta-mchp/issues/5
Signed-off-by: Kohei Otsuka <kohei@spacemachines.com>
---
drivers/tty/serial/8250/8250_of.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index b41ca604083f..e23539b2fda3 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -278,6 +278,16 @@ static int of_platform_serial_probe(struct platform_device *ofdev)
if (port8250.port.fifosize)
port8250.capabilities = UART_CAP_FIFO;
+ /*
+ * Core16550 has no TEMT interrupt: without UART_CAP_NOTEMT the em485
+ * code waits for one after the last THRE interrupt and never drops RTS.
+ * Set UART_CAP_FIFO too, because a non-zero value stops
+ * serial8250_do_startup() filling in the PORT_16550A default.
+ */
+ if (of_device_is_compatible(ofdev->dev.of_node,
+ "microchip,core16550-rtl-v3"))
+ port8250.capabilities |= UART_CAP_FIFO | UART_CAP_NOTEMT;
+
/* Check for TX FIFO threshold & set tx_loadsz */
if ((of_property_read_u32(ofdev->dev.of_node, "tx-threshold",
&tx_threshold) == 0) &&
--
2.53.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: serial: 8250: add Microchip Core16550
2026-11-09 2:55 ` [PATCH v2 1/2] dt-bindings: serial: 8250: add " Kohei Otsuka via B4 Relay
@ 2026-11-09 2:59 ` sashiko-bot
0 siblings, 0 replies; 5+ messages in thread
From: sashiko-bot @ 2026-11-09 2:59 UTC (permalink / raw)
To: Kohei Otsuka; +Cc: linux-serial
> From: Kohei Otsuka <kohei@spacemachines.com>
>
> Core16550 is a 16550-compatible UART soft IP core for Microchip FPGAs,
> including the fabric of PolarFire SoC. Its registers, interrupts and
> baud rate divisor follow the 16550A, so a driver that knows only
> ns16550a operates it fully: transmit, receive, FIFOs and modem control
> all work. What the generic driver cannot know is that the core raises
> no interrupt on TEMT, which it needs to drop RTS after a frame in
> software RS-485 mode (em485). ns16550a therefore stays a valid
> fallback, with RS-485 RTS control the one feature that needs the
> specific compatible.
>
> Add microchip,core16550-rtl-v3 with ns16550a as the fallback. As for
> Microchip's other FPGA fabric cores, the -rtl-v3 suffix is the major
> RTL version of the IP, Core16550 3.x.
>
> Link: https://github.com/linux4microchip/meta-mchp/issues/5
> Signed-off-by: Kohei Otsuka <kohei@spacemachines.com>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-core16550-rs485-v2-0-a15933c7b907@spacemachines.com?part=1
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2 2/2] serial: 8250_of: drop RS-485 RTS on Microchip Core16550
2026-11-09 2:55 ` [PATCH v2 2/2] serial: 8250_of: drop RS-485 RTS on " Kohei Otsuka via B4 Relay
@ 2026-11-09 3:03 ` sashiko-bot
0 siblings, 0 replies; 5+ messages in thread
From: sashiko-bot @ 2026-11-09 3:03 UTC (permalink / raw)
To: Kohei Otsuka; +Cc: linux-serial
> From: Kohei Otsuka <kohei@spacemachines.com>
>
> Core16550, a 16550-compatible UART for Microchip FPGAs, interrupts on
> THRE but not on TEMT. When the last character moves from the FIFO into
> the shift register, the THRE interrupt calls __stop_tx(), which finds
> TEMT clear and, without UART_CAP_NOTEMT, returns to wait for a TEMT
> interrupt that never comes. RTS, and with it the RS-485 driver enable,
> then stays asserted after the frame, and receive interrupts, disabled
> for the half-duplex transmission, stay off.
>
> Set UART_CAP_NOTEMT for nodes compatible with
> "microchip,core16550-rtl-v3", so em485 drops RTS from its stop timer
> one frame time (plus 1/7) after THRE, as it does for DesignWare UARTs.
>
> Set UART_CAP_FIFO as well: with the capabilities already non-zero,
> serial8250_do_startup() no longer fills in the PORT_16550A default,
> and without UART_CAP_FIFO serial8250_clear_fifos() does nothing, so
> the RX FIFO is not flushed at the end of a half-duplex transmission.
>
> Link: https://github.com/linux4microchip/meta-mchp/issues/5
> Signed-off-by: Kohei Otsuka <kohei@spacemachines.com>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-core16550-rs485-v2-0-a15933c7b907@spacemachines.com?part=2
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-11-09 3:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-09 2:55 [PATCH v2 0/2] serial: 8250_of: RS-485 on Microchip Core16550 Kohei Otsuka via B4 Relay
2026-11-09 2:55 ` [PATCH v2 1/2] dt-bindings: serial: 8250: add " Kohei Otsuka via B4 Relay
2026-11-09 2:59 ` sashiko-bot
2026-11-09 2:55 ` [PATCH v2 2/2] serial: 8250_of: drop RS-485 RTS on " Kohei Otsuka via B4 Relay
2026-11-09 3:03 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox