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

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

Sponsored by:		Netflix

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

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

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

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

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

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

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

Switch from the long obsolete hint.0.acpi.rsdp to acpi.rsdp to get the
root of the ACPI tables.

MFC After:	1 week
Sponsored by:	Netflix

In a couple of places, we use 4 instead of ACPI_NAMESEG_SIZE. Use the

Sponsored by:		Netflix

Clarify what's reported with -t (it's all the fixed acpi tables,
not just the listed ones). The listed tables are more fully decoded,
while all other tables just have their headers decoded.

Sponsored by:		Netflix

Sort the ACPI signatures alphabetically and move it into a table we can iterate through

Sponsored by:		Netflix

Add the ability to dump a specific ACPI table rather than all of them.

Sponsored by:		Netflix

Make rsdp pointer to the RSDP global so we can look up other tables.

Sponsored by:		Netflix

how is assumed to be 0, so we directly assign to it. It might not always
be 0, so or-in these bits.

Sponsored by:		Netflix

If there's a SPCR, then use it to create and pass the right values to
the uart.

Ideally, I'd just pass this all in hw.uart.console, but old kernels
completely ignore the value if there's any extra entries. So I have to
pass newly invented values to replace kernel values in a new kenv
hw.uart.console.extra. so we pass xo=-1 in to calcuate the xo from the
baud rate, and pv and pd for PCI Vendor ID and PCI Device ID of the
serial console to use. Old kernels will ignore this and completely get
this data from parsing SPCR itself. New kernels will dig it our of here
w/o needing to parse it.

We don't support Rev3 or Rev4 SPCR yet. It's too new to be in real
hardware yet.

Sponsored by:		Netflix

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

We can get the UART clock from v3 SPCR, and a precise baudrate from
v4. Some precise baudrates will currently be rejected by the kernel.

Sponsored by:		Netflix

If we have a new enough SPCR, then use it when it provides a
PreciseBaudrate and/or a UartClkFreq.

Sponsored by:		Netflix

Sponsored by:		Netflix