src/sys/dev/uart, branch main

uart/pci: use different probe return values

2026-04-17T19:37:26Z

For PCI devices listed in pci_ns8250_ids return BUS_PROBE_SPECIFIC, while for generic UART devices not explicitly listed in pci_ns8250_ids return BUS_PROBE_GENERIC. This allows more specific drivers to take over those devices, and the generic UART PCI driver will only be used as a fallback. This fixes an issue where the UART PCI driver would attach to multiport PCI UART devices, that instead need to use the puc(4) driver to multiplex the device. Reported by: markj Sponsored by: Citrix Systems R&D Differential revision: https://reviews.freebsd.org/D56467 Reviewed by: markj imp

uart/pci: recover ADL AMT device after FIFO size probing

2026-04-17T19:37:26Z

When the Alder Lake Serial-over-LAN device is put into loopback mode and repeated writes are performed to the data register it results in the device ending up in a non-functional state afterwards. Recovering the device to a working state requires re-writing the LCR register with it's current value (no effective change). This should be harmless on all other devices. Sponsored by: Citrix Systems R&D Differential revision: https://reviews.freebsd.org/D56107 Reviewed by: imp

uart/pci: always disable MSI for generic devices

2026-03-27T08:26:32Z

The generic device pci_id structure in uart_pci_probe() already has PCI_NO_MSI appended to it's flags, however that information is not propagated into uart_pci_attach(). Assume that any device that doesn't match the known IDs is a generic UART device, and hence prevent the usage of MSIs. MFC: 2 weeks Reviewed by: imp Differential revision: https://reviews.freebsd.org/D56097

uart/pci: support 16550A PCI serial devices

2026-03-27T08:26:32Z

Expand the current check to also attach the ns8250 driver to devices reporting as 16550A. This has been tested to work on a real device. From an inspection of the code in the ns8250 driver it seems like it should support up to 16950A devices, but I don't have hardware to ensure that, hence be conservative with the change. MFC: 2 weeks Reviewed by: imp Differential revision: https://reviews.freebsd.org/D56095

chore: replace {0, 0} with {DEV,KOBJ}METHOD_END

2026-02-25T05:59:34Z

Both of the aforementioned macros have been present in FreeBSD for well over a decade: 2009 for `KOBJMETHOD_END`; 2011 for `DEVMETHOD_END`. Adapt all hardcoded references of `{0, 0}` with `DEVMETHOD_END` and `KOBJMETHOD_END` as appropriate. This helps ensure that future adaptations to drivers following patterns documented in driver(9) can be made more easily/without issue. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D55414

arm: Add EARLY_PRINTF for ns8250 on arm/aarch64 platforms.

2026-02-22T21:13:33Z

Reviewed by: adrian (previous version) MFC after: 3 weeks

uart: fix sleeping while holding mutex in uart_tty_detach()

2026-02-03T03:21:43Z

Move swi_remove() call before acquiring the tty lock. swi_remove() calls intr_event_remove_handler() which may sleep via msleep(), causing a lock order violation when called with the tty mutex held. The software interrupt handler removal operates on the interrupt event structure independently and does not require the tty lock. This matches the pattern used in other drivers such as tcp_hpts.c where swi_remove() is called without holding other locks. Reviewed by: imp, kevans MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D54953

uart: provide and use default rclk for JH7110 UART

2025-10-31T15:30:02Z

A regression in the u-boot-provided JH7110 device tree leaves the uart incorrectly configured. The issue arises when a baud rate is specified ('current-speed' property), but the rclk value is not ('clock-frequency'). Previous releases, e.g. v2025.04, provided both. The alternative way to retrieve this value is to query the parent clock, but our clk framework is not available during early console probing and configuration. In this instance, we end up defaulting to DEFAULT_RCLK in ns8250_init(), which is the wrong value. The relevant uart class (uart_snps) should provide a default rclk in its definition, but it does not. Add a new variant class with the correct default rclk of 24000000. Finally, uart_cpu_fdt_probe() needs to be updated to actually query this default value when it does not find a 'clock-frequency' property. This was simply missing; the ACPI uart bus behaves identically, see uart_acpi_probe(). PR: 289978 Reported by: rdunkle@smallcatbrain.com MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D53119

puc: Add support for Systembase SB16C1054, SB16C1058.

2025-08-26T11:09:15Z

The Systembase SB16C1054 and SB16C1058 are PCI quad- and octal-UART complexes, based on multiple Systembase SB16C1050 cores, which appear to be compatible with the NS8250 family (except for the "enable interrupts" bit in the other BAR). The SB16C105x family are one of two families of PCIe UART complexes on cards by StarTech.com, such as the PEX4S1050 and PEX8S1050. (Other StarTech.com serial offerings use the ASIX AX99100 or ASIX MCS990x.) This is derived from the NetBSD driver. Reviewed by: imp Tested by: Jashank Jeremy Obtained from: Jashank Jeremy MFC after: 1 week Differential Revision:

uart: Add ns8250 ACPI entry for SPCR rev 2

2025-08-13T14:02:14Z

Summary: SPCR rev 2 adds a series of new device types, with 0x12 being "16550-compatible with parameters defined in the Generic Address Structure". Since we look for the parameters already in the GAS there's nothing extra for us to do beyond adding the entry so that it probes successfully. Reviewed by: imp, andrew Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D51771