Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3355603pxb; Mon, 17 Jan 2022 18:26:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQPWAHb/xQxlwXDuIxQLbg6r7Vh6hktqOUFLME8nPAaCc0YJhIJUN+9aPDgRUPFcVLuAzL X-Received: by 2002:a17:903:28e:b0:14a:192:e6ad with SMTP id j14-20020a170903028e00b0014a0192e6admr25694836plr.3.1642472795651; Mon, 17 Jan 2022 18:26:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642472795; cv=none; d=google.com; s=arc-20160816; b=Q3s68U6/xg0z85Fj2+w0hUIGaTtiHkAZE24XqpJxLTMZC0u9r6yCLGQPFS9UIuzEma MqqJT2ZLB46qj8NzSeHEPe4m8ZDGypkppI5zCG6JgKrZnKptReJJG1u09/14xyOsHyT2 pj7pWvQDByWwyeJucqgTKtdZqB7KcNlHpCM9TH1nbvl32DvG8Ol3Cpr1DHT5Dm1XEqM/ heVPY+iLMZiN4QVKG1iMIyBKDc8MC0Cv/A4BAx8zIAtZhACL23ekqFLM8nH+lCDG59Ws s/o9KyS9hDo8U2ITQcumXgeAIcB8WbeLG+kaKFJDTFiXdXmXJccXOs0d4DuTGqXX4VKa 37XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=FI5EDM6FnSm1FNwyDPXsaDnAwWbu0dkRdAyUi5Y7XRs=; b=Gt3zsE7VjZkKk9iLbd94MPiPeLt31S9qnROHWAJgUVswFFE+omPqQFYn7F1/Os1Dfj td7qQbshCZAjeeSRY19VruMU2oYlViyJAGDBIzesYdH059I5QeZdZW2XaBkxWYBKV/M9 R5egDJuHpxU4R6tsLO0dNM1wYSFVCSV0gg2ckAUTyVYJ7fkPowV3ESeQorm909oKe9ZY kOdg/MvgUnVBQd/NNvoGaNRstkABjaJXOM3RTG44MYcE5jVW8VMFQS6T4tRB0wMXy2n7 9hD9Dvomuq9farzudA++SJDTy4Mg2g1rMyy23b5GJ3B5jNphE51+8HGuG/TE6auAsveX zRrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v5si6023441plp.394.2022.01.17.18.26.24; Mon, 17 Jan 2022 18:26:35 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232941AbiAQNLD (ORCPT + 99 others); Mon, 17 Jan 2022 08:11:03 -0500 Received: from foss.arm.com ([217.140.110.172]:58158 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231894AbiAQNLB (ORCPT ); Mon, 17 Jan 2022 08:11:01 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DEFDA1FB; Mon, 17 Jan 2022 05:11:00 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.38.30]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 356003F774; Mon, 17 Jan 2022 05:10:59 -0800 (PST) Date: Mon, 17 Jan 2022 13:10:56 +0000 From: Mark Rutland To: Krzysztof Adamski Cc: Catalin Marinas , Will Deacon , Peter Collingbourne , Guenter Roeck , Wolfram Sang , Alexander Sverdlin , Matija Glavinic-Pecotic , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: move efi_reboot to restart handler Message-ID: <20220117131056.GC87485@C02TD0UTHF1T.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Mon, Jan 17, 2022 at 01:31:48PM +0100, Krzysztof Adamski wrote: > On EFI enabled arm64 systems, efi_reboot was called before > do_kernel_restart, completely omitting the reset_handlers functionality. > By registering efi_reboot as part of the chain with slightly elevated > priority, we make it run before the default handler but still allow > plugging in other handlers. > Thanks to that, things like gpio_restart, restart handlers in > watchdog_core, mmc or mtds are working on those platforms. > > The priority 129 should be high enough as we will likely be the first > one to register on this prio so we will be called before others, like > PSCI handler. I apprecaiate that this is kinda nice for consistency, but if adds more lines and reduces certainty down to "likely", neither of which seem ideal. What do we gain by changing this? e.g. does this enable some further rework? Do we actually need to change this? > > Signed-off-by: Krzysztof Adamski > --- > arch/arm64/kernel/process.c | 7 ------- > arch/arm64/kernel/setup.c | 21 +++++++++++++++++++++ > 2 files changed, 21 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 5369e649fa79..b86ef77bb0c8 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -130,13 +130,6 @@ void machine_restart(char *cmd) > local_irq_disable(); > smp_send_stop(); > > - /* > - * UpdateCapsule() depends on the system being reset via > - * ResetSystem(). > - */ > - if (efi_enabled(EFI_RUNTIME_SERVICES)) > - efi_reboot(reboot_mode, NULL); > - > /* Now call the architecture specific reboot code. */ > do_kernel_restart(cmd); > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c > index f70573928f1b..5fa95980ba73 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -298,6 +299,24 @@ u64 cpu_logical_map(unsigned int cpu) > return __cpu_logical_map[cpu]; > } > > +static int efi_restart(struct notifier_block *nb, unsigned long action, > + void *data) > +{ > + /* > + * UpdateCapsule() depends on the system being reset via > + * ResetSystem(). > + */ > + if (efi_enabled(EFI_RUNTIME_SERVICES)) > + efi_reboot(reboot_mode, NULL); > + > + return NOTIFY_DONE; > +} > + > +static struct notifier_block efi_restart_nb = { > + .notifier_call = efi_restart, > + .priority = 129, > +}; > + > void __init __no_sanitize_address setup_arch(char **cmdline_p) > { > setup_initial_init_mm(_stext, _etext, _edata, _end); > @@ -346,6 +365,8 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p) > > paging_init(); > > + register_restart_handler(&efi_restart_nb); If we're going to register this, it'd be nicer to register it conditionally in the EFI code when we probe EFI, rather than having the arch setup code unconditionally register a notifier that conditionally does something. Thanks, Mark. > + > acpi_table_upgrade(); > > /* Parse the ACPI tables for possible boot-time configuration */ > -- > 2.34.1 >