[PATCH 0/3] dtuart fixes

[PATCH 0/3] dtuart fixes

[Michal Orzel]

Michal Orzel (3):
  cmdline: Document console=dtuart option
  drivers/char: Check if console=dtuart for ACPI SPCR serial bring up
  drivers/char: Panic when the requested UART fails to initialise

 docs/misc/xen-command-line.pandoc | 13 +++++--
 xen/arch/arm/setup.c              |  5 ++-
 xen/arch/riscv/setup.c            |  6 +++-
 xen/drivers/char/uart-init.c      | 56 ++++++++++++++++++-------------
 xen/include/xen/serial.h          |  6 +++-
 5 files changed, 56 insertions(+), 30 deletions(-)

-- 
2.43.0

[PATCH 1/3] cmdline: Document console=dtuart option

[Michal Orzel]

Document the default console= option on Arm and RISC-V that is
"dtuart" indicating a generic UART parsed from a device tree or
ACPI SPCR table. This serial utilizes SERHND_DTUART handle.

Take the opportunity to:
 - fix documented x86 default to vga to match OPT_CONSOLE_STR,
 - mark dtuart option as available on RISC-V,
 - document fall back to /chosen/stdout-path.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 docs/misc/xen-command-line.pandoc | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
index 1c711fa98086..3a416a38b74c 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -430,9 +430,10 @@ The following are examples of correct specifications:
 Specify the size of the console ring buffer.
 
 ### console
-> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
+> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | dtuart | none ]`
 
-> Default: `console=com1,vga`
+> Default (x86): `console=vga`
+> Default (Arm, RISC-V): `console=dtuart`
 
 Specify which console(s) Xen should use.
 
@@ -454,6 +455,10 @@ compiled with `CONFIG_XEN_GUEST` enabled.
 
 `xhci` indicates that Xen should use a USB3 debug port.
 
+`dtuart` indicates that Xen should use a generic UART (parsed from a device
+tree or ACPI SPCR table). Only available if Xen was compiled with
+`CONFIG_GENERIC_UART_INIT` enabled.
+
 `none` indicates that Xen should not use a console.  This option only
 makes sense on its own.
 
@@ -1069,13 +1074,15 @@ affinities to prefer but be not limited to the specified node(s).
 
 Pin dom0 vcpus to their respective pcpus
 
-### dtuart (ARM)
+### dtuart (ARM, RISC-V)
 > `= path [:options]`
 
 > Default: `""`
 
 Specify the full path in the device tree for the UART.  If the path doesn't
 start with `/`, it is assumed to be an alias.  The options are device specific.
+If the option is left empty, Xen will try to probe the device from the DT
+property /chosen/stdout-path if present.
 
 ### e820-mtrr-clip (x86)
 > `= <boolean>`
-- 
2.43.0

Re: [PATCH 1/3] cmdline: Document console=dtuart option

[Jan Beulich]

On 02.09.2026 09:36, Michal Orzel wrote:
> Document the default console= option on Arm and RISC-V that is
> "dtuart" indicating a generic UART parsed from a device tree or
> ACPI SPCR table. This serial utilizes SERHND_DTUART handle.
> 
> Take the opportunity to:
>  - fix documented x86 default to vga to match OPT_CONSOLE_STR,

I first wanted to object to this part, as I was sure this used to be
"com1,vga". Yet indeed it's been almost 19 years ago when this was
changed (92877a1f9ab2 ["x86: Auto-probe the serial port baud rate if
'com1' or 'com2' is"]).

>  - mark dtuart option as available on RISC-V,
>  - document fall back to /chosen/stdout-path.
> 
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Acked-by: Jan Beulich <jbeulich@suse.com>

> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -430,9 +430,10 @@ The following are examples of correct specifications:
>  Specify the size of the console ring buffer.
>  
>  ### console
> -> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
> +> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | dtuart | none ]`
>  
> -> Default: `console=com1,vga`
> +> Default (x86): `console=vga`
> +> Default (Arm, RISC-V): `console=dtuart`

Any reason to not also cover PPC here?

Jan

Re: [PATCH 1/3] cmdline: Document console=dtuart option

[Orzel, Michal]

On 02-Sep-26 10:55, Jan Beulich wrote:
> On 02.09.2026 09:36, Michal Orzel wrote:
>> Document the default console= option on Arm and RISC-V that is
>> "dtuart" indicating a generic UART parsed from a device tree or
>> ACPI SPCR table. This serial utilizes SERHND_DTUART handle.
>>
>> Take the opportunity to:
>>  - fix documented x86 default to vga to match OPT_CONSOLE_STR,
> 
> I first wanted to object to this part, as I was sure this used to be
> "com1,vga". Yet indeed it's been almost 19 years ago when this was
> changed (92877a1f9ab2 ["x86: Auto-probe the serial port baud rate if
> 'com1' or 'com2' is"]).
> 
>>  - mark dtuart option as available on RISC-V,
>>  - document fall back to /chosen/stdout-path.
>>
>> Signed-off-by: Michal Orzel <michal.orzel@amd.com>
> 
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -430,9 +430,10 @@ The following are examples of correct specifications:
>>  Specify the size of the console ring buffer.
>>  
>>  ### console
>> -> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | none ]`
>> +> `= List of [ vga | com1[H,L] | com2[H,L] | pv | dbgp | ehci | xhci | dtuart | none ]`
>>  
>> -> Default: `console=com1,vga`
>> +> Default (x86): `console=vga`
>> +> Default (Arm, RISC-V): `console=dtuart`
> 
> Any reason to not also cover PPC here?
While PPC sets OPT_CONSOLE_STR to "dtuart", it does not select
CONFIG_GENERIC_UART_INIT that compiles in the uart-init.c which is what really
matters to decide whether dtuart is supported or not.

~Michal

[PATCH 2/3] drivers/char: Check if console=dtuart for ACPI SPCR serial bring up

[Michal Orzel]

dtuart denotes a generic UART parsed from a device tree (back then it
was the only method, hence dt prefix) or ACPI SPCR table (they all use
the SERHND_DTUART serial handle). Currently we only check if console= is
set to dtuart in the DT flow and not in the ACPI flow. This means that
even if we set console=none we would still bring up ACPI parsed
serial device for nothing. Move the check to uart_init() to cover both
paths.

Signed-off-by: Michal Orzel <michal.orzel@amd.com>
---
 xen/drivers/char/uart-init.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/char/uart-init.c b/xen/drivers/char/uart-init.c
index a2181399389f..eb7f85549593 100644
--- a/xen/drivers/char/uart-init.c
+++ b/xen/drivers/char/uart-init.c
@@ -38,9 +38,6 @@ static void __init dt_uart_init(void)
     const char *options;
     char *split;
 
-    if ( !console_has("dtuart") )
-        return; /* Not for us */
-
     if ( !strcmp(opt_dtuart, "") )
     {
         const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
@@ -121,6 +118,9 @@ static void __init acpi_uart_init(void) { }
 
 void __init uart_init(void)
 {
+    if ( !console_has("dtuart") )
+        return; /* Not for us */
+
     if ( acpi_disabled )
         dt_uart_init();
     else
-- 
2.43.0

Re: [PATCH 2/3] drivers/char: Check if console=dtuart for ACPI SPCR serial bring up

[Jan Beulich]

On 02.09.2026 09:36, Michal Orzel wrote:
> dtuart denotes a generic UART parsed from a device tree (back then it
> was the only method, hence dt prefix) or ACPI SPCR table (they all use
> the SERHND_DTUART serial handle). Currently we only check if console= is
> set to dtuart in the DT flow and not in the ACPI flow. This means that
> even if we set console=none we would still bring up ACPI parsed
> serial device for nothing. Move the check to uart_init() to cover both
> paths.
> 
> Signed-off-by: Michal Orzel <michal.orzel@amd.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

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

[Michal Orzel]

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.

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, 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>
---
With this change diagnosibility decreases only for a single scenario:
when dom0 is reachable not via console (e.g. network) and you'd have used xl
dmesg to read messages from the conring.

On Arm (I suppose RISC-V is similar), given that safety becomes the major
use-case and we need to satisfy all the user/guest-xen contracts, I think the
patch moves us in a direction we already chose (i.e. we panic on every boot
failure where we cannot meet the requests).
---
 xen/arch/arm/setup.c         |  5 +++-
 xen/arch/riscv/setup.c       |  6 ++++-
 xen/drivers/char/uart-init.c | 52 +++++++++++++++++++++---------------
 xen/include/xen/serial.h     |  6 ++++-
 4 files changed, 44 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6310a47d68b6..d0066db42e7c 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -379,7 +379,10 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr)
 
     gic_preinit();
 
-    uart_init();
+    rc = uart_init();
+    if ( rc )
+        panic("Failed to initialize the requested UART (%d)\n", rc);
+
     console_init_preirq();
     console_init_ring();
 
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
index 56a0907a855f..07f46ac3ce27 100644
--- a/xen/arch/riscv/setup.c
+++ b/xen/arch/riscv/setup.c
@@ -77,6 +77,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 {
     const char *cmdline;
     size_t fdt_size;
+    int rc;
 
     remove_identity_mapping();
 
@@ -149,7 +150,10 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
 
     intc_preinit();
 
-    uart_init();
+    rc = uart_init();
+    if ( rc )
+        panic("Failed to initialize the requested UART (%d)\n", rc);
+
     console_init_preirq();
 
     intc_init();
diff --git a/xen/drivers/char/uart-init.c b/xen/drivers/char/uart-init.c
index eb7f85549593..b79135be9620 100644
--- a/xen/drivers/char/uart-init.c
+++ b/xen/drivers/char/uart-init.c
@@ -30,15 +30,17 @@
 static char __initdata opt_dtuart[256] = "";
 string_param("dtuart", opt_dtuart);
 
-static void __init dt_uart_init(void)
+static int __init dt_uart_init(void)
 {
     struct dt_device_node *dev;
     int ret;
     const char *devpath = opt_dtuart;
     const char *options;
     char *split;
+    /* Set on the command line, as opposed to inherited from /chosen */
+    bool explicit_request = strcmp(opt_dtuart, "") != 0;
 
-    if ( !strcmp(opt_dtuart, "") )
+    if ( !explicit_request )
     {
         const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
 
@@ -62,7 +64,12 @@ static void __init dt_uart_init(void)
     if ( !strcmp(opt_dtuart, "") )
     {
         printk("No dtuart path configured\n");
-        return;
+
+        /*
+         * console=dtuart is the compiled-in default, so an absent dtuart= is
+         * not a failed user request.
+         */
+        return 0;
     }
 
     split = strchr(opt_dtuart, ':');
@@ -83,48 +90,49 @@ static void __init dt_uart_init(void)
     if ( !dev )
     {
         printk("Unable to find device \"%s\"\n", devpath);
-        return;
+        return explicit_request ? -ENODEV : 0;
     }
 
     ret = device_init(dev, DEVICE_SERIAL, options);
-
     if ( ret )
         printk("Unable to initialize dtuart: %d\n", ret);
+
+    return explicit_request ? ret : 0;
 }
 
 #ifdef CONFIG_ACPI
-static void __init acpi_uart_init(void)
+static int __init acpi_uart_init(void)
 {
-    struct acpi_table_spcr *spcr = NULL;
+    struct acpi_table_spcr *spcr;
+    acpi_status status;
     int ret;
 
-    acpi_get_table(ACPI_SIG_SPCR, 0, (struct acpi_table_header **)&spcr);
+    /* SPCR is firmware provided, so nothing here is a failed user request */
+    status = acpi_get_table(ACPI_SIG_SPCR, 0,
+                            (struct acpi_table_header **)&spcr);
 
-    if ( spcr == NULL )
+    if ( ACPI_FAILURE(status) )
     {
         printk("Unable to get spcr table\n");
+        return 0;
     }
-    else
-    {
-        ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type);
 
-        if ( ret )
-            printk("Unable to initialize acpi uart: %d\n", ret);
-    }
+    ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type);
+    if ( ret )
+        printk("Unable to initialize acpi uart: %d\n", ret);
+
+    return 0;
 }
 #else
-static void __init acpi_uart_init(void) { }
+static int __init acpi_uart_init(void) { return 0; }
 #endif
 
-void __init uart_init(void)
+int __init uart_init(void)
 {
     if ( !console_has("dtuart") )
-        return; /* Not for us */
+        return 0; /* Not for us */
 
-    if ( acpi_disabled )
-        dt_uart_init();
-    else
-        acpi_uart_init();
+    return acpi_disabled ? dt_uart_init() : acpi_uart_init();
 }
 
 /*
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 8e1844555208..3a71da767dd7 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -170,7 +170,11 @@ void xhci_dbc_uart_init(void);
 static void inline xhci_dbc_uart_init(void) {}
 #endif
 
-void uart_init(void);
+/*
+ * Returns 0 unless a UART explicitly requested via dtuart= failed to
+ * initialise.
+ */
+int uart_init(void);
 
 struct physdev_dbgp_op;
 int dbgp_op(const struct physdev_dbgp_op *op);
-- 
2.43.0

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

[Halder, Ayan Kumar]

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.
>
> 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>
> ---
> With this change diagnosibility decreases only for a single scenario:
> when dom0 is reachable not via console (e.g. network) and you'd have used xl
> dmesg to read messages from the conring.
>
> On Arm (I suppose RISC-V is similar), given that safety becomes the major
> use-case and we need to satisfy all the user/guest-xen contracts, I think the
> patch moves us in a direction we already chose (i.e. we panic on every boot
> failure where we cannot meet the requests).
> ---
>   xen/arch/arm/setup.c         |  5 +++-
>   xen/arch/riscv/setup.c       |  6 ++++-
>   xen/drivers/char/uart-init.c | 52 +++++++++++++++++++++---------------
>   xen/include/xen/serial.h     |  6 ++++-
>   4 files changed, 44 insertions(+), 25 deletions(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 6310a47d68b6..d0066db42e7c 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -379,7 +379,10 @@ void asmlinkage __init noreturn start_xen(unsigned long fdt_paddr)
>   
>       gic_preinit();
>   
> -    uart_init();
> +    rc = uart_init();
> +    if ( rc )
> +        panic("Failed to initialize the requested UART (%d)\n", rc);
> +
>       console_init_preirq();
>       console_init_ring();
>   
> diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/setup.c
> index 56a0907a855f..07f46ac3ce27 100644
> --- a/xen/arch/riscv/setup.c
> +++ b/xen/arch/riscv/setup.c
> @@ -77,6 +77,7 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>   {
>       const char *cmdline;
>       size_t fdt_size;
> +    int rc;
>   
>       remove_identity_mapping();
>   
> @@ -149,7 +150,10 @@ void __init noreturn start_xen(unsigned long bootcpu_id,
>   
>       intc_preinit();
>   
> -    uart_init();
> +    rc = uart_init();
> +    if ( rc )
> +        panic("Failed to initialize the requested UART (%d)\n", rc);
> +
>       console_init_preirq();
>   
>       intc_init();
> diff --git a/xen/drivers/char/uart-init.c b/xen/drivers/char/uart-init.c
> index eb7f85549593..b79135be9620 100644
> --- a/xen/drivers/char/uart-init.c
> +++ b/xen/drivers/char/uart-init.c
> @@ -30,15 +30,17 @@
>   static char __initdata opt_dtuart[256] = "";
>   string_param("dtuart", opt_dtuart);
>   
> -static void __init dt_uart_init(void)
> +static int __init dt_uart_init(void)
>   {
>       struct dt_device_node *dev;
>       int ret;
>       const char *devpath = opt_dtuart;
>       const char *options;
>       char *split;
> +    /* Set on the command line, as opposed to inherited from /chosen */
> +    bool explicit_request = strcmp(opt_dtuart, "") != 0;
>   
> -    if ( !strcmp(opt_dtuart, "") )
> +    if ( !explicit_request )
>       {
>           const struct dt_device_node *chosen = dt_find_node_by_path("/chosen");
>   
> @@ -62,7 +64,12 @@ static void __init dt_uart_init(void)
>       if ( !strcmp(opt_dtuart, "") )
>       {
>           printk("No dtuart path configured\n");
> -        return;
> +
> +        /*
> +         * console=dtuart is the compiled-in default, so an absent dtuart= is
> +         * not a failed user request.
> +         */
> +        return 0;
>       }
>   
>       split = strchr(opt_dtuart, ':');
> @@ -83,48 +90,49 @@ static void __init dt_uart_init(void)
>       if ( !dev )
>       {
>           printk("Unable to find device \"%s\"\n", devpath);
> -        return;
> +        return explicit_request ? -ENODEV : 0;
>       }
>   
>       ret = device_init(dev, DEVICE_SERIAL, options);
> -
>       if ( ret )
>           printk("Unable to initialize dtuart: %d\n", ret);
> +
> +    return explicit_request ? ret : 0;
>   }
>   
>   #ifdef CONFIG_ACPI
> -static void __init acpi_uart_init(void)
> +static int __init acpi_uart_init(void)
>   {
> -    struct acpi_table_spcr *spcr = NULL;
> +    struct acpi_table_spcr *spcr;
> +    acpi_status status;
>       int ret;
>   
> -    acpi_get_table(ACPI_SIG_SPCR, 0, (struct acpi_table_header **)&spcr);
> +    /* SPCR is firmware provided, so nothing here is a failed user request */
> +    status = acpi_get_table(ACPI_SIG_SPCR, 0,
> +                            (struct acpi_table_header **)&spcr);
>   
> -    if ( spcr == NULL )
> +    if ( ACPI_FAILURE(status) )
>       {
>           printk("Unable to get spcr table\n");
> +        return 0;
>       }
> -    else
> -    {
> -        ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type);
>   
> -        if ( ret )
> -            printk("Unable to initialize acpi uart: %d\n", ret);
> -    }
> +    ret = acpi_device_init(DEVICE_SERIAL, NULL, spcr->interface_type);
> +    if ( ret )
> +        printk("Unable to initialize acpi uart: %d\n", ret);
> +
> +    return 0;
>   }
>   #else
> -static void __init acpi_uart_init(void) { }
> +static int __init acpi_uart_init(void) { return 0; }
>   #endif
>   
> -void __init uart_init(void)
> +int __init uart_init(void)
>   {
>       if ( !console_has("dtuart") )
> -        return; /* Not for us */
> +        return 0; /* Not for us */
>   
> -    if ( acpi_disabled )
> -        dt_uart_init();
> -    else
> -        acpi_uart_init();
> +    return acpi_disabled ? dt_uart_init() : acpi_uart_init();
>   }
>   
>   /*
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 8e1844555208..3a71da767dd7 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -170,7 +170,11 @@ void xhci_dbc_uart_init(void);
>   static void inline xhci_dbc_uart_init(void) {}
>   #endif
>   
> -void uart_init(void);
> +/*
> + * Returns 0 unless a UART explicitly requested via dtuart= failed to
> + * initialise.
> + */
> +int uart_init(void);
>   
>   struct physdev_dbgp_op;
>   int dbgp_op(const struct physdev_dbgp_op *op);

LGTM

- Ayan

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

[Halder, Ayan Kumar]

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