Re: [PATCH 3/3] drivers/char: Panic when the requested UART fails to initialise

["Halder, Ayan Kumar" <ayankuma@amd.com>]

On 02/09/2026 10:44, Halder, Ayan Kumar wrote:
> Hi,
>
> On 02/09/2026 08:36, Michal Orzel wrote:
>> uart_init() cannot tell its caller that the UART the user asked for did
>> not come up: every failure path only printks. Arm and RISC-V carry on
>> into console_init_preirq() and boot without a console, rather than
>> refusing to boot as they do elsewhere when a user request cannot be met.
> I just want to emphasize that from functional safety perspective, this 
> is the preferred approach. The user's request is given the priority 
> and whenever it cannot be satisfied, Xen should panic.
The patch does it, so we are good.
>>
>> Return an error from dt_uart_init() and panic in start_xen(). An
>> explicit request Xen cannot satisfy should stop the boot rather than
>> silently degrade it,
>
> If there is a silent degradation, then we need to document this 
> behavior somewhere. I am happy to keep this documented under docs/fusa.
>
> In the safety manual, we should mention all the instances when there 
> is a silent degradation observed, the underlying reason and how the 
> end user can detect it.
>
> Other FuSa experts can comment.
>
>>   which is what start_xen() already does for the rest
>> of the boot configuration.
>>
>> Only a path given on the command line counts as a request we have to
>> satisfy. Falling back to /chosen/stdout-path or acpi_uart_init()
>> therefore never fails. SPCR is firmware provided, the analogue of
>> stdout-path, and there is no ACPI equivalent of dtuart= to make an
>> explicit request with.
>>
>> While here, decide whether the SPCR table was found from the returned
>> acpi_status rather than from the table pointer, which was only NULL
>> because the caller initialised it - acpi_get_table() writes it solely
>> on success.
>>
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>

- Ayan