Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp238327pxb; Tue, 15 Feb 2022 12:11:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJygqUUVNNk21nDNXUH/jEi9uJpEuNdRRsgV1+Vu7dEzrs6k60E22WcVYnrDov4FImzLYn8N X-Received: by 2002:a17:902:cf07:: with SMTP id i7mr661862plg.137.1644955878758; Tue, 15 Feb 2022 12:11:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644955878; cv=none; d=google.com; s=arc-20160816; b=dyLPN3gL622zzaHgX/nS2Kxlqj9ypoxqFPvRPqjP6YjXvaj2TJuri3Ye2n1/1opPFN RR7VEzQiuKsyGF4Ko2x7t4xRdn6nORChtH00hOll9nFcN4u25qDdOmk7ItUHEESD1esx E7jQfroUYE3xwAMYua5C23Rs5k62eAh3opTf2lAb/A4PBNE4VyJT3GzJwclBxAgg2lqo uJTjh+zliproAqCFYe/AQVA+27XJ0sL0h5v3zO3ABSLTXB6/oR+ygm6WZN997TGLO6gY 61UalXGWJyccnGGBchsrzsFoR0nprbs3KOwXKPrVcdfO8gzzem9G5/QH4e/jGA98PF/u xq4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:sender:dkim-signature; bh=o8JsroBWHtIyrUhOn7dBaIXgVTUEl2NPmoZI9J5M7E4=; b=RD5/bCjhTVEamL4lVaUKE8ek7t7EMQjRumwkYsrraG9H08V4anE0W+oL0JavfK9Zho F2WE/ys/KZEZ1qvglfbuZ2gOpggE7X75HMdS7XxqZ0WJU4wZf1AYoD3z0o/cyYBP2FNX jkR4la8K4eVttahsGnWg+0VcFJOzGLwv2ge9weDHlx6NPuuaQWK4YbTMtxB9x82A/b03 07dwJeTL5ULGzGT4aWQMlXNmSsEBSIj3YPqYkKu42Lpg9TgqZA+bi1M1wBjl4/KuXd9x Hl32bcdg6JrRh1XVf5HckkY7nvduVfVjbytkMwNBErjyt0kwixb/jr9n+mxjqgR60eH/ fSDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ifEIW3Qy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c3si15188239pls.81.2022.02.15.12.11.00; Tue, 15 Feb 2022 12:11:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ifEIW3Qy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238641AbiBOOap (ORCPT + 99 others); Tue, 15 Feb 2022 09:30:45 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:51666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238656AbiBOOam (ORCPT ); Tue, 15 Feb 2022 09:30:42 -0500 Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7835EEA73; Tue, 15 Feb 2022 06:30:30 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id o23so1450384oie.10; Tue, 15 Feb 2022 06:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:content-language:to :cc:references:from:subject:in-reply-to:content-transfer-encoding; bh=o8JsroBWHtIyrUhOn7dBaIXgVTUEl2NPmoZI9J5M7E4=; b=ifEIW3QyLIEZKOFGn1FWXIry5z0Qay9I8omD8m3/vwpHfFyn/gHzJv/UwFDjNCbHOy VO3/TxAvNOcLKNwOW0g44qaSAg/Y0X5hIzOy7p7RUsGHVxqxXpvGFhUpuCLGL7Ikt5kO hEfNdVggmT/piyRxBhNbeFU5rcnpi/lJyv2rpYOPfmCLvd1ECK58o9Xb1bQnNW4aAg7P 494In7Sosgo8F9jjLzFOZ712RSjGjA1/FgazyRROU/nZMfqB+/0rNDUcFqwjFZWZEG4W jCfhjvBgm6/lCZrdin3d84fC/Py4V3LOgv8HO0S/0r4087uvBxOidGkL7nTntuywYh9Q N+QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to :content-transfer-encoding; bh=o8JsroBWHtIyrUhOn7dBaIXgVTUEl2NPmoZI9J5M7E4=; b=2Nj5K7/8asei1ur660gNBe2kKEc21hMwTk9k7wQhGLqhLjacXU7hQ9/C4FjlRay2hp OqEDB5Jr5xh62nYhKOR53FKn74aaBTWK2/Biid8vpzLFgC/bYUnBSLsp8hotVYk2kbUZ ZTglIojYxXn0n55cl5BQxtPCsZ0ed85V+nognISragvX9z1cVrHDGct1xzxD69DrfirC 4iKI8ptRWxQbpb0A5c2U+kpBaWZ4f7s2UhfuT5Ksa1FwzZfJL1SFJ3ehS134ryW2O1Ci 8NR2cjqqFpsOGT6ulB2vQTSSyzybHJHxg9DhbiqfqG0jvFc5CkzwgYdksyBFhQf2ZJg7 1tDw== X-Gm-Message-State: AOAM531oxvgv97kjVNkgrM+saIvxXOD+4Bl930RBc5tacmv+ezvhUGDM V3F6U6hXwxlX0sgWGgYb6ns= X-Received: by 2002:a05:6808:1644:b0:2cd:6d80:9af1 with SMTP id az4-20020a056808164400b002cd6d809af1mr1709630oib.138.1644935429995; Tue, 15 Feb 2022 06:30:29 -0800 (PST) Received: from ?IPV6:2600:1700:e321:62f0:329c:23ff:fee3:9d7c? ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id l1sm13761263otd.18.2022.02.15.06.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Feb 2022 06:30:29 -0800 (PST) Sender: Guenter Roeck Message-ID: <489b76f9-fbaf-dae0-c90d-c52ee0de92a4@roeck-us.net> Date: Tue, 15 Feb 2022 06:30:26 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Alexander Sverdlin , Mark Rutland , Ard Biesheuvel Cc: Catalin Marinas , Will Deacon , Peter Collingbourne , Wolfram Sang , Matija Glavinic-Pecotic , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Krzysztof Adamski , linux-efi@vger.kernel.org References: <79bcce92-abb2-4c3e-7193-d18e144da8a0@nokia.com> From: Guenter Roeck Subject: Re: [PATCH v2] arm64: move efi_reboot to restart handler In-Reply-To: <79bcce92-abb2-4c3e-7193-d18e144da8a0@nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/15/22 00:44, Alexander Sverdlin wrote: > Hello Mark, Ard, > > On 01/02/2022 14:58, Mark Rutland wrote: >>> You could argue that restart handlers were not created for that but they >>> suit this purpose ideally and it wouldn't make much sense (in my >>> opinion) to add yet another notifier chain that would run before reset >>> notifiers, for code that is not supposed to reset the whole system and >>> this is exacly what I would have to do if efi_reboot() is forced to be >>> called before all handlers. >> >> As above, I think that's just using the wrong interface, and the reboot >> notifier mechanism *already* exists, so I'm really confused here. >> >> Have I misunderstood what you're trying to achieve? >> >> Is there some problem with the reboot notifier mechanism that I am unaware of? >> e.g. do we bypass them in some case where you think they're needed? >> >> Are you simply unaware of reboot notifiers? > > Could you please check the simple case of pwrseq_emmc.c? > > While that's currently the only example of this kind upstream I can imagine > further use-cases, especially in storage area like above. > > Would you suggest it's illegal usage of register_restart_handler()? > Do we need to fix pwrseq_emmc.c by introducing new atomic notifier chain > which will be called before restart handlers, so that it works on > emergency_restart()? > Abuse isn't just about using an API for something it isn't originally intended for, abuse is also to intentionally _not_ use an API, as it is currently done by the EFI restart code for arm64. Also, keep in mind that the same argument (our restart handler _must_ be executed under all circumstances and does therefore not use the restart API) is likely going to be used again in the future. All it takes is for some other standard (or chip vendor, for that matter) to declare their restart handler mandatory if present. That means there will be other non-users of the restart API in the future, and you simply can not rely on it being used. That was clearly not the intention of the restart API - quite the opposite - but it is what it is. Given that, I'd suggest to cut your losses and try to find another solution for your problem. That may be to introduce yet another API, one that is called before the EFI restart handling but that is always called, unlike reboot notifiers, or simply stick with out-of-tree code. Guenter