src/sys/dev/uart/uart_dev_ns8250.c, branch releng/14.3 FreeBSD source tree dev/uart: Add APMC0D08 as found in the Intel E2100 2024-09-02T08:48:54+00:00 Andrew Turner andrew@FreeBSD.org 2024-07-23T09:18:36+00:00 75861a57b6fd721e47c8a7cb43c4882c200cca1d This uart has the requirement for 32-bit sized and aligned memory accesses. It is also described in the Serial Port Console Redirection Table (SPCR) with a different interface type value. Reviewed by: imp Sponsored by: Arm Ltd Differential Revision: https://reviews.freebsd.org/D45834 (cherry picked from commit 9840598aa31f2a89272f5bef6545e316f254f0c6) 
This uart has the requirement for 32-bit sized and aligned memory
accesses. It is also described in the Serial Port Console Redirection
Table (SPCR) with a different interface type value.

Reviewed by:	imp
Sponsored by:	Arm Ltd
Differential Revision:	https://reviews.freebsd.org/D45834

(cherry picked from commit 9840598aa31f2a89272f5bef6545e316f254f0c6)
uart(4): Honor hardware state of NS8250-class for tsw_busy 2024-01-18T20:14:46+00:00 Marius Strobl marius@FreeBSD.org 2024-01-12T22:27:07+00:00 8595e76a9f1a5bcf057afe6d28846099287a26b7 In 9750d9e5, I brought the equivalent of the TS_BUSY flag back in a mostly hardware-agnostic way in order to fix tty_drain() and, thus, TIOCDRAIN for UARTs with TX FIFOs. This proved to be sufficient for fixing the regression reported. So in light of the release cycle of FreeBSD 10.3, I decided that this change was be good enough for the time being and opted to go with the smallest possible yet generic (for all UARTs driven by uart(4)) solution addressing the problem at hand. However, at least for the NS8250-class the above isn't a complete fix as these UARTs only trigger an interrupt when the TX FIFO became empty. At this point, there still can be an outstanding character left in the transmit shift register as indicated via the LSR. Thus, this change adds the 3rd (besides the tty(4) and generic uart(4) bits) part I had in my tree ever since, adding a uart_txbusy method to be queried in addition for tsw_busy and hooking it up as appropriate for the NS8250-class. As it turns out, the exact equivalent of this 3rd part later on was implemented for uftdi(4) in 9ad221a5. While at it, explain the rational behind the deliberately missing locking in uart_tty_busy() (also applying to the generic sc_txbusy testing already present). (cherry picked from commit 353e4c5a068d06b0d6dcfa9eb736ecb16e9eae45) 
In 9750d9e5, I brought the equivalent of the TS_BUSY flag back in a
mostly hardware-agnostic way in order to fix tty_drain() and, thus,
TIOCDRAIN for UARTs with TX FIFOs. This proved to be sufficient for
fixing the regression reported. So in light of the release cycle of
FreeBSD 10.3, I decided that this change was be good enough for the
time being and opted to go with the smallest possible yet generic
(for all UARTs driven by uart(4)) solution addressing the problem at
hand.

However, at least for the NS8250-class the above isn't a complete
fix as these UARTs only trigger an interrupt when the TX FIFO became
empty. At this point, there still can be an outstanding character
left in the transmit shift register as indicated via the LSR. Thus,
this change adds the 3rd (besides the tty(4) and generic uart(4) bits)
part I had in my tree ever since, adding a uart_txbusy method to be
queried in addition for tsw_busy and hooking it up as appropriate
for the NS8250-class.

As it turns out, the exact equivalent of this 3rd part later on was
implemented for uftdi(4) in 9ad221a5.

While at it, explain the rational behind the deliberately missing
locking in uart_tty_busy() (also applying to the generic sc_txbusy
testing already present).

(cherry picked from commit 353e4c5a068d06b0d6dcfa9eb736ecb16e9eae45)
sys: Remove $FreeBSD$: one-line .c pattern 2023-08-16T17:54:36+00:00 Warner Losh imp@FreeBSD.org 2023-08-16T17:54:36+00:00 685dc743dc3b5645e34836464128e1c0558b404b Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ 
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD 2023-05-12T16:44:03+00:00 Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58+00:00 4d846d260e2b9a3d4d0a701462568268cbfe7a5b The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix 
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with:		pfg
MFC After:		3 days
Sponsored by:		Netflix
uart: Don't change settings or throttle putc for Hyper-V 2023-03-18T07:07:54+00:00 Wei Hu whu@FreeBSD.org 2023-03-14T15:49:33+00:00 8ea7fa16d9fe5acb7d42a223efbfa23627aa5e0c Azure setup does not like it when FreeBSD overrides the settings of the UART device. When Hyper-V is detected, don't do this and also don't throttle putc() output. This is a workaround for the early boot hang of FreeBSD on Azure. Tested on Azure, ESXi (VM with serial port), and SG-8200 PR: 264267 Reviewed by: kevans, whu Tested by: whu Obtained from: Rubicon Communications, LLC (Netgate) MFC after: 2 weeks Sponsored by: Rubicon Communications, LLC (Netgate) 
Azure setup does not like it when FreeBSD overrides the settings of the
UART device. When Hyper-V is detected, don't do this and also don't
throttle putc() output. This is a workaround for the early boot hang
of FreeBSD on Azure.

Tested on Azure, ESXi (VM with serial port), and SG-8200

PR:		264267
Reviewed by:	kevans, whu
Tested by:	whu
Obtained from:	Rubicon Communications, LLC (Netgate)
MFC after:	2 weeks
Sponsored by:	Rubicon Communications, LLC (Netgate)
ns8250: Fix sense of LSR_TEMT FCR check 2022-10-28T19:20:28+00:00 Colin Percival cperciva@FreeBSD.org 2022-10-28T04:42:44+00:00 5ad8c32c722b58da4c153f241201af51b11f3152 When flushing the UART, we need to drain manually if LSR_TEMT is *not* asserted, aka. if the transmit FIFO is not empty. Reported by: void <void@f-m.fm> Fixes: c4b68e7e53bb "ns8250: Check if flush via FCR succeeded" Differential Revision: https://reviews.freebsd.org/D37185 
When flushing the UART, we need to drain manually if LSR_TEMT is
*not* asserted, aka. if the transmit FIFO is not empty.

Reported by:	void <void@f-m.fm>
Fixes:		c4b68e7e53bb "ns8250: Check if flush via FCR succeeded"
Differential Revision:	https://reviews.freebsd.org/D37185
ns8250: Check if flush via FCR succeeded 2022-10-18T06:02:21+00:00 Colin Percival cperciva@FreeBSD.org 2022-10-13T18:01:03+00:00 c4b68e7e53bb352be3fa16995b99764c03097e66 The emulated UART in the Firecracker VMM (aka the implementation in the rust-vmm/vm-superio project) includes FIFOs but does not implement the FCR register, which is used by ns8250_flush to flush the FIFOs. Check the LSR to see if there is still data in the FIFOs and call ns8250_drain if necessary. Discussed with: emaste, imp, jrtc27 Sponsored by: https://patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D36979 
The emulated UART in the Firecracker VMM (aka the implementation in the
rust-vmm/vm-superio project) includes FIFOs but does not implement the
FCR register, which is used by ns8250_flush to flush the FIFOs.

Check the LSR to see if there is still data in the FIFOs and call
ns8250_drain if necessary.

Discussed with:	emaste, imp, jrtc27
Sponsored by:	https://patreon.com/cperciva
Differential Revision:	https://reviews.freebsd.org/D36979
ns8250_drain: Drain without DELAY first 2022-10-08T00:51:54+00:00 Colin Percival cperciva@FreeBSD.org 2022-08-12T23:45:17+00:00 39d6144dcd94e9d07f07cb554aecb1f2d4089f6d In virtual machines with virtual UARTs which have fictitious baud rates, it may be possible to drain the receive queue very quickly, without needing to DELAY after each character. Attempt to read (and discard) the receive queue as fast as possible, stopping for a DELAY only when LSR_RXRDY is no longer asserted; assume that we have finished draining the queue when LSR_RXRDY is asserted both before and after a DELAY. This speeds up the boot process in FreeBSD/Firecracker by 27 ms. Reviewed by: imp, jrtc27 Sponsored by: https://www.patreon.com/cperciva Differential Revision: https://reviews.freebsd.org/D36184 
In virtual machines with virtual UARTs which have fictitious baud
rates, it may be possible to drain the receive queue very quickly,
without needing to DELAY after each character.  Attempt to read
(and discard) the receive queue as fast as possible, stopping for
a DELAY only when LSR_RXRDY is no longer asserted; assume that we
have finished draining the queue when LSR_RXRDY is asserted both
before and after a DELAY.

This speeds up the boot process in FreeBSD/Firecracker by 27 ms.

Reviewed by:	imp, jrtc27
Sponsored by:	https://www.patreon.com/cperciva
Differential Revision:	https://reviews.freebsd.org/D36184
uart: Add ACPI entry for LS1046A UART 2022-08-22T07:16:08+00:00 Mateusz Kozyra mkoz@semihalf.com 2022-08-22T07:07:15+00:00 7cb73f654ff4fe55a366cd3a96c0c2f640d05cb1 NXP defines unique name for LS1046A UART - "NXP0018". It is ns8250 compatible, adding a new uart compat data entry is enough to make it work. Tested on LS1046ARDB. Approved by: mw(mentor) Reviewed by: mw, kd Obtained from: Semihalf Differential Revision: https://reviews.freebsd.org/D36260 
NXP defines unique name for LS1046A UART - "NXP0018".
It is ns8250 compatible, adding a new uart compat data entry is enough
to make it work.
Tested on LS1046ARDB.

Approved by:	mw(mentor)
Reviewed by:	mw, kd
Obtained from:	Semihalf
Differential Revision:	https://reviews.freebsd.org/D36260
uart: Fix an out-of-bounds read in ns8250_bus_probe() 2021-07-13T21:49:39+00:00 Mark Johnston markj@FreeBSD.org 2021-07-13T21:49:39+00:00 4a9a41650c909706bc0b9a3f29817c11b262b0a0 The problem is that ns8250_bus_probe() accesses a field from the ns8250_softc, which embeds the generic UART softc, but the ns8250_softc hasn't yet been allocated because we're still probing. This is a regression from commit 0aefb0a63c50. This fixed a problem where one of the upper four IER bits, which are usually reserved, needs to be set in order to get RX interrupts before the RX FIFO is full. At the same time, we avoid clearing those reserved bits (see commit 58957d87173, though other UART drivers I looked at do not bother with this). So, copy what ns8250_init() does to disable interrupts, since we don't know what the "right" mask is at this point. Reported by: syzbot+f256beefd0df9eb796e7@syzkaller.appspotmail.com Reviewed by: imp MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D31124 
The problem is that ns8250_bus_probe() accesses a field from the
ns8250_softc, which embeds the generic UART softc, but the ns8250_softc
hasn't yet been allocated because we're still probing.

This is a regression from commit 0aefb0a63c50.  This fixed a problem
where one of the upper four IER bits, which are usually reserved, needs
to be set in order to get RX interrupts before the RX FIFO is full.  At
the same time, we avoid clearing those reserved bits (see commit
58957d87173, though other UART drivers I looked at do not bother with
this).

So, copy what ns8250_init() does to disable interrupts, since we don't
know what the "right" mask is at this point.

Reported by:	syzbot+f256beefd0df9eb796e7@syzkaller.appspotmail.com
Reviewed by:	imp
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D31124