[PATCH 06/13] x86: Allow locating UARTs by device ID

[Bin Meng]

+Andy

Hi Simon,

On Tue, Feb 21, 2023 at 3:49 AM Simon Glass <sjg at chromium.org> wrote:
>
> When coreboot does not pass a UART in its sysinfo struct, there is no
> easy way to find it out. Add a way to specify known UARTs so we can
> find them without needing help from coreboot.
>
> Since coreboot does not actually init the serial device when serial is
> disabled, it is not possible to make it add this information to the
> sysinfo table.
>
> Also, we cannot use the class information, since we don't know which
> UART is being used. For example, with Alder Lake there are two:
>
> 00.16.00   0x8086     0x51e0     Simple comm. controller 0x80
> 00.1e.00   0x8086     0x51a8     Simple comm. controller 0x80
>
> In our case the second one is the right one, but thre is no way to
> distinguish it from the first one without using the device ID.
>
> If we have Adler Lake hardware which uses a different UART, we could
> perhaps look at the ACPI tables, or the machine information passed in
> the SMBIOS tables.
>
> This was discussed previously before: [1]
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/
>   20210407163159.3.I967ea8c85e009f870c7aa944372d32c990f1b14a at changeid/
>
> Signed-off-by: Simon Glass <sjg at chromium.org>
> ---
>
>  arch/x86/dts/coreboot.dts        |  4 ++
>  drivers/serial/serial_coreboot.c | 69 ++++++++++++++++++++++++++++----
>  include/pci_ids.h                |  3 ++
>  3 files changed, 68 insertions(+), 8 deletions(-)
>

Last time we discussed this, both Andy and I thought this was a hack.
I cited Andy's point below:

"What coreboot should do is either provide serial information or SPCR
ACPI table. Otherwise if it does not provide it, I think it's on
purpose, and we have to respect this."

So maybe somehow we should parse the SPCR ACPI table instead?

Regards,
Bin