uart: Split out initilisation of the acpi devinfo

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 f

uart: Split out initilisation of the acpi devinfo

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

(cherry picked from commit 473c0b44ae8c51b2aebc51887714b2ed14de50bf)

show more ...

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

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

show more ...

uart(4): Add a concept of "unique" serial devices

FreeBSD detects serial ports twice: First, very early in the boot
process, in order to obtain a usable console; and second, during
the device probe/

uart(4): Add a concept of "unique" serial devices

FreeBSD detects serial ports twice: First, very early in the boot
process, in order to obtain a usable console; and second, during
the device probe/attach process. When a UART is discovered during
device probing, FreeBSD attempts to determine whether it is a
device which was already being used as a console; without this,
the console doesn't work in userland.

Unfortunately it's possible for a UART to be mapped to a different
location in memory when it is discovered on a bus than it has when
it is announced via the ACPI SPCR table; this breaks the matching
process, which relies on comparing bus addresses.

To address this, we introduce a concept of "unique" serial devices,
i.e. devices which are guaranteed to be present *only once* on any
system. If we discover one of these during device probing, we can
match it to a same-PCI-vendor-and-device-numbers console which was
announced via the ACPI SPCR table, regardless of the differing bus
addresses.

At present, the only unique serial device is the "Amazon PCI serial
device" (vendor 0x1d0f, device 0x8250) found in some EC2 instances.
This unbreaks the serial console on those systems.

Reviewed by: imp
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D34703

show more ...

Fix AccessWidth and BitWidth parsing in SPCR table

The ACPI Specification defines a Generic Address Structure (GAS),
which is used to describe UART controller register layout in the
SPCR table. The

Fix AccessWidth and BitWidth parsing in SPCR table

The ACPI Specification defines a Generic Address Structure (GAS),
which is used to describe UART controller register layout in the
SPCR table. The driver responsible for parsing it (uart_cpu_acpi)
wrongly associates the Access Size field to the uart_bas's regshft
and the register BitWidth to the regiowidth - according to
the definitions it should be opposite.

This problem remained hidden most likely because the majority of platforms
use 32-bit registers (BitWidth) which are accessed with the according
size (Dword). However on Marvell Armada 8k / Cn913x platforms,
the 32-bit registers should be accessed with Byte granulity, which
unveiled the issue.

This patch fixes above by proper values assignment and slightly improved
parsing.

Note that handling of the AccessWidth set to EFI_ACPI_6_0_UNDEFINED is
needed to work around a buggy SPCR table on EC2 x86 "bare metal" instances.

Reviewed by: manu, imp, cperciva, greg_unrelenting.technology
Obtained from: Semihalf
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D25373

show more ...

uart_cpu_acpi: Fix GCC build break from r348195

extern declarations are redundant with those in uart_cpu.h, which this file
includes.

X-MFC-with: r348195

Use ACPI SPCR on x86

This takes the SPCR code currently in uart_cpu_arm64.c, moves it into
a new uart_cpu_acpi.c (with some associated refactoring), and uses it
from both arm64 and x86.

An SPCR ser

Use ACPI SPCR on x86

This takes the SPCR code currently in uart_cpu_arm64.c, moves it into
a new uart_cpu_acpi.c (with some associated refactoring), and uses it
from both arm64 and x86.

An SPCR serial port address AccessWidth field value of 0 ("reserved")
is now treated as 1 ("byte access") in order to work around a buggy
SPCR table on Amazon EC2 i3.metal instances.

Reviewed by: manu, Greg V
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D20357

show more ...