Re: [PATCH] ns16550: add "auto" to scan PCI only when the default base has no UART

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.10.2026 22:44, Benjamin Leggett wrote:
> Jan Beulich <jbeulich@xxxxxxxx> writes:
> 
>> On 09.10.2026 22:24, Benjamin Leggett wrote:
>>> On some systems the console UART is at the legacy I/O port, and on
>>> others, such as Amazon EC2 bare metal instances, the only UART is on
>>> PCI. "com1=...,pci" finds the PCI UART, but it prefers any PCI serial
>>> device to the legacy port, so it is not correct on a system that has
>>> both. No option today says "use the legacy port, and scan PCI only if
>>> it has no UART". A deployment that boots one command line on many
>>> kinds of machine needs exactly that.
>>>
>>> Add "auto" as a value in the <io-base> position. With it, Xen probes
>>> the default base as usual. Only if check_existence() fails there does
>>> it scan PCI, as "pci" does. Without "auto", nothing changes.
>>
>> I've always been considering check_existence() as somewhat fragile (it's
>> not very difficult for it to yield a false positive, especially when
>> HAS_IOPORTS=n), which means that I'm not really convinced it can (reliably)
>> be used for the purpose here.
> 
> How do you feel about making the retval for check_existence() work like so:
> - 1: a UART answered the probe at io_base.
> - 0: the probe ran, and no UART answered.
> - -1: the function cannot probe this base, so it did not test it.
> 
> and returning the -1 in cases that would spuriously return 1 and be
> "false positives" today, so we don't try to probe something we
> shouldn't?
> 
> That at least covers the cases I can see, including the HAS_IOPORTS one.
> 
> e.g. `if auto && -1` -> we bail with "can't probe"

Makes sense, yet I wonder: Why did you raise the question here if 5 min
later you send a new version of the patch anyway?

And btw - that patch can't possibly be v1 anymore, yet it neither says
which version it is, nor what has changed from the earlier version.

Jan