[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/3] drivers/char: Panic when the requested UART fails to initialise
- To: Michal Orzel <michal.orzel@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Halder, Ayan Kumar" <ayankuma@xxxxxxx>
- Date: Tue, 8 Sep 2026 11:15:46 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CL0RqkCcFHvzY0x/FMtT+wm5AEKe2Jhg4P6VvBd5Aq8=; b=W4lhjvaeQTPvG8DHZdqvvETwp48D+G3ZgF7KehhBdA37FHv45u0lQFM1WmY0Cjox/gFKxzNYuvAVZXliLPUNtwk5TMkxV1ex3KxG6IxY2pI5iIjXCMw5/qL+CN40CV/QMZmuk+8hal4OY7OHjmurz7WxZJpo3Zw5FX/Xg3dYkr7SWwjwlJmhD9HNKAcoc214xgjOoIC054LYQVqU4vx5iFzC/khtCdhgTOr1awHo9gPlceyrdmwqiieno2F5GFaqJIi2OLf6qiRGuax5Gk3q1m8WB4u364be2VjvdS6xFYEc3eZxIz7orDL65aZirN4ASvMEZpDvuW6v+vS6MNTSMA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=acQdO/Oep2Y81sWePjSaARO498RepWQaoKpCpor90ZyLD7SBVNC/fBmzUVLlaA8QgMreahO3hqWVCVu74WP0KB0nq9tOJYeqHKNP+InVnM9iHHi+v6fWlg1dzp4l8SSO5/9YV+FWJ9k7TH2tiUwkPTt40MHfvcbcGNs8/OXVTfG6CMqGcmdncrktTevkP+yAoeUyjyus3XYuowev+xeLii1H1DAdQALdslOAUtrrDuspBT2w8+IroD6QB3ZjNzwPcyz62EyOMVtKihFZxkydffsLvsbNgbG8Rkx7pw6BxhVRVbb7IOEwnSOk1P1P53+KaetRs972LsrCwCuqu8CYsA==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=amd.com header.i="@amd.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Alistair Francis <alistair.francis@xxxxxxx>, "Connor Davis" <connojdavis@xxxxxxxxx>, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>, <matthew.l.weber3@xxxxxxxxxx>, Andrei Buzdugan <andrei_buzdugan@xxxxxxxx>, Simone Weiss <simone.weiss@xxxxxxxxxxxxx>, <uwendi@xxxxxxxxx>, <harunobu.kurokawa.dn@xxxxxxxxxxx>
- Delivery-date: Tue, 08 Sep 2026 10:16:01 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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@xxxxxxx>
Reviewed-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
- Ayan
|
