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
MFC notes:
- All changes to nvme/nvd were dropped as they didn't apply.
- Change to ufshci_pci.c was adjusted to match code in branch.
Conflicts:
sys/dev/nvd/nvd.c
sys/dev/nvme/nvme_sim.c
sys/dev/ufshci/ufshci_pci.c
(cherry picked from commit 0fc6c3f731a2cca3120798806c330a3081c9424b)
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
(cherry picked from commit ed3a2469a71e0ef48cf8e636c35e64a011756da3)
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
(cherry picked from commit 6de1c50e78a826abc08660e4c3ac10f1ddba9ba2)
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 <jashank@rulingia.com.au>
Obtained from: Jashank Jeremy <jashank@rulingia.com.au>
MFC after: 1 week
Differential Revision: <https://reviews.freebsd.org/D52150
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
This is now unused. It was used for the SPCR interface type, but that
has now been split out into a new struct.
Reviewed by: imp, jhibbits
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D51879
We don't care about most of acpi_uart_compat_data in the spcr code.
Split out the mapping from the SPCR interface type to uart class into
a new struct. This allows new SPCR interface types to be added that
don't have an entry in the DSDT, e.g. some PCI uarts may not.
Reviewed by: imp, jhibbits
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D51878
Switch to using sys/stdarg.h for va_list type and va_* builtins.
Make an attempt to insert the include in a sensible place. Where
style(9) was followed this is easy, where it was ignored, aim for the
first block of sys/*.h headers and don't get too fussy or try to fix
other style bugs.
Reviewed by: imp
Exp-run by: antoine (PR 286274)
Pull Request: https://github.com/freebsd/freebsd-src/pull/1595
LSR_TEMT bit is set if both transmit hold and shift registers are
empty, but the flush command flushes only the hold register.
While here, update the diagnostic message to report which registers
could not be flushed.
MFC after: 2 weeks
This is a revival of the old exynos4210 driver, with some additional
bits to configure the apple "s5l" uart (which is actually slightly
different to operate).
This hasn't been tested on anything that would hit the non-s5l path, so
banish it off to the apple/ domain until someone cares to confirm that
none of the other hardware is broken -- it may be that nobody does, but
the complexity isn't too bad: mostly the driver1 construct added to the
uart_bas that we use to avoid having a whole bunch of shims for uart
driver methods and hardcoded references to the cfg structs.
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D48120
This flag was introduced to ignore bad firmware values. These were
present in older versions of EDK-II that many devices (both Ampere and
Amazon) used. QEMU also used this value, but fixed it. But since it's
tied to the firmware bug not the device name ID it doesn't make sense to
have it flagged there.
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47947
Some veresions of EDK-II and QEMU reported the wrong values for the
register shift and the region I/O size. Detect those and set it to the
correct values. In general, anything other than a shift of 2 and a
regio width of 4 (bytes, or 32 bits) is a mistake. However, allow
for overrides in the future by only overriding the buggy values.
Otherwise, we will fail to boot.
PR: 282936
Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D47946
A long cable attached to the UART can act as an antenna if disconnected
from the other end. This can cause noise on the receive side, possibly
as reflections from the transmit side, leading to an interrupt storm.
Filter this by adding a threshold of received characters without TX
ready, above which characters are dropped. This is disabled by default,
but has been tested with a threshold of 1000+. A high threshold is
recommended to avoid dropping characters during, for instance, a large
copy/paste from the other end.
Sponsored by: Juniper Networks, Inc.
If we have a new enough SPCR, then use it when it provides a
PreciseBaudrate and/or a UartClkFreq.
Sponsored by: Netflix
Reviewed by: andrew,adrian
Differential Revision: https://reviews.freebsd.org/D47097
Two reasons for this: we know it's a uart after we call probe and it
returns successfully. Second, uart passes data between probe and attach
with softc. As it is now, we call probe twice, once in the bidding
process and once after bidding id done. However, the probe process for
uart isn't completely idempotent (we change state of the uart
sometimes). The second call can result in odd behavior (though so far
only in buggy version of other code I've not committed). The bigger
problem is the softc: newbus creates it, we populate it, then frees it
when we don't return 0 to claim the device. It then calls us again, we
repopulate it, and this time it doesn't free it before calling attach.
Returning 0 avoids both of these issues. The justification for doing it
in the commit that changed it was 'while I'm here', so there doesn't
seem to be a use case for it.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47095
When instructed to do so, compute the rclk (baud rate generator clock)
based on the currently programmed divisor and the communicated baud
rate. We only do this once and only for consoles that tell us the
configured rate and flag we can likely safely compute rclk.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47077
This allows one to specify dt:XXXX when the default class isn't compiled
into the kernel. It's not an error to not have a class until we're done
parsing the spec, so defer checking until then.
Sponsored by: Netflix
Reviewed by: adrian, andrew, markj
Differential Revision: https://reviews.freebsd.org/D47078
When instructed to do so, compute the rclk (baud rate generator clock)
based on the currently programmed divisor and the communicated baud
rate. We only do this once and only for consoles that tell us the
configured rate and flag we can likely safely compute rclk.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47076
Disable interrupts before we set the parameters for the UART. Usually,
it makes no difference, but it's possible that setting the baud rate, etc
could create problems if there's data pending, so move the interrupt
disabling ealier.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47075
We have two copies (soon to be three) of reading the divisor. Since it's
a complicated tricky process, abstract it to its own routine.
Sponsored by: Netflix
Reviewed by: andrew, markj
Differential Revision: https://reviews.freebsd.org/D47074
It can be confusing when the ns8250 driver prints error messages with
just ns8250 as the prefix. Add uart: to the live and commented out
printfs.
Sponsored by: Netflix
Reviewed by: andrew, markj
Differential Revision: https://reviews.freebsd.org/D47073
With newer, more diverse hardware designs, the rclk can be
unknown. Currently deployed systems have no standard way to discover the
baud-clock generator frequency. However, sometimes we have a fairly good
idea that the firmware programmed the UART to be the baud rate that it's
telling us it's at. Create a way to instruct the uart class drivers to
compute the baud clock frequency the first time their init routines are
called. Usually the 'divisors' are relatively small, meaning we will
likely have a fairly large error (goes as 1 / (divisor + 1). However,
we also know that the baud-generator clock needs to be divided down
to the baud-rate +/- about 5% (so while the error could be large for
an arbitrary baud-clock, standard baud rates generally will give
an error of 5% or less).
Often, the console speed and the getty-configured speed are the same, so
this heuristic allows boot messages and login sessions to work.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47072
To help debugging, export the rclk a uart is using as
dev.uart.X.rclk. It can be opaque when it is wrong since any error
messages printed to the system console using the wrong rclk aren't
informative.
Sponsored by: Netflix
Reviewed by: andrew, markj
Differential Revision: https://reviews.freebsd.org/D47070
If rclk is set in sysdev, then it was set during the boot process and is
intended to override the defaults. By prefering the sysdev one over the
class, xo=XXXX in hw.uart.console can give the user a usable console for
non-traditional UARTs, especially on !x86 platforms. The default rclk
generally only is good for I/O mapped UARTS or PCI ones that we can do a
table lookup on. Other times, it can be hard to know what a good default
is without more information.
Sponsored by: Netflix
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D47069
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
The Debug Port Table 2 (DBG2) contains information on which devices
can be used for debugging purposes.
Add support to the uart driver to use the DBG2 table when enabled from
loader.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44359
The StarFive VisionFive 2 has a Synopsys DesignWare ABP UART, whose
driver uses UART_FDT_CLASS rather than UART_FDT_CLASS_AND_DEVICE as it
has its own separate newbus driver. This UART is driven by a 24MHz clock
as specified in the FDT, but we don't currently look at the property
here, instead passing down 0 and letting the default value be used in
the 8250 driver (~1.8MHz). As a result the divisor is misconfigured for
the current baud rate for the entire kernel boot process. Once the
newbus driver attaches the correct frequency is saved in the softc, but
that does not take effect until the next time ns8250_param is called and
the divisor is recalculated, namely when userspace runs and /dev/console
is opened (note that ns8250_init does not get called when the newbus
device corresponding to the current console attaches).
Fix this issue by attemmpting to get the current clock frequency as for
the UART_FDT_CLASS_AND_DEVICE_CASE, but falling back to 0 rather than
failing on error.
Reviewed by: imp, mhorne
Differential Revision: https://reviews.freebsd.org/D45159
This is useful for other drivers to be able to find the UART (such as
the case of UARTs where hardware flow control lines are handled by
another device.)
Sponsored by: Juniper Networks, Inc.
MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D44532
In preperation for adding debug port support add a generic function
to setup the uart from ACPI tables.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44358
Split out the common parts of building the uart devinfo from ACPI
tables from the SPCR parser. This will be used when we support the DBG2
table to find the debug uart to be used by the kernel gdb stub.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D44357
Use the macro "UART_CLASS()" for the newly created data set
'uart_class_set' as we do for other data sets.
This further hides the data set name.
Also add UART_CLASS for quicc, which was previously not done.
MFC after: 1 week
Improves: 949670f8f4 dev/uart: Use a linker set to find uart classes
Obtained from: jhb, 269e99ac86
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D43981
While we only support 4-byte registers in the uart code the physical
access may be to an 8-byte register. Support this as an option on
non-i386. On i386 we lack the needed 8-byte bus_space functions.
ACPI has an option for 8-byte register io width, and FDT can be given
any size. Support these sizes, even if we don't expect to see hardware
with an 8-byte io width.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43374
Add the pl011 uart to the list of supported uarts for use by
hw.uart.console. This is commonly found in Arm based devices, and a
variant is standardised in the Arm SBSA.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43363
Some uarts require a specific register width. Support setting this in
the kernel environment.
Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43362
When the uart is configured via the environment we need to find the
uart class with a specified name. Currently to do this with an
incomplete list of uarts. As we may not have included all uarts in the
kernel each class is defined as weak.
Switch to a linker set so the list is always up to date based on what
is included in the kernel, and the class can be static.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43361
Support selecting the early uart with "options EARLY_PRINTF=foo" in
the kernel configuration file. This allows us to not have to change
source files when enabling EARLY_PRINTF, simplifying enabling it.
New uart drivers can be enabled by defining a new early_printf_foo
value to be unique, then using "#if CHECK_EARLY_PRINTF(foo)" to decide
when to enable the uart.
While here add pl011 early printf support.
Reviewed by: imp (earlier version)
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D43360
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).
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: imp
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43192
We've removed kernel option EXT_RESOURCES almost two years ago.
While it was ok to have some code under a common 'extres' subdirectory
at first, we now have a lot of consumer of it and we made it mandatory
so no need to have it under a cryptic name.
Reviewed by: mhorne
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D43191
Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.
Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/
Sponsored by: Netflix
Since ingenic JZ4780 SOC support has been removed there is no need
to support ingenic quirks in the UART driver.
Invert of commit b192bae67e
Reviewed by: imp, manu
Approved by: imp, manu (mentor)
Differential Revision: https://reviews.freebsd.org/D42497
