Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp536986imn; Thu, 28 Jul 2022 08:13:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uUR/0rKeAJfdplJa/WXuHuV3v7Mkx0mbe39fHotSTcMExBV5RrWQbUx0c90wtvWQlAipim X-Received: by 2002:a63:b56:0:b0:41a:495a:2a26 with SMTP id a22-20020a630b56000000b0041a495a2a26mr23516773pgl.411.1659021204461; Thu, 28 Jul 2022 08:13:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659021204; cv=none; d=google.com; s=arc-20160816; b=FgO8uwVQZmaLRYq4E60XNbX/cVHpd4JukqTEschVzj6k/3IfpwYjtv9IkUssJWlOe+ 7mmCb4e38JEjJQTYsALV84/B8pG5Z/XkBZSFhf+UhlfxJz9ouI99xrPZSabthg3sN1ra Bduescb0pFhPz0ix2ep+AJxsCYvLVEeJjRwcgXjKIrHyvC63y2kGqo6DKQfLXHSLKTaY jCmcL1ZrqMORS1rwcvS0aNUqWn9IgTN0qfplVaM+GtibYc7v6QseBCh0w0rjLKi9Ajkp W5pkPaZxsJkNiB/gTUrGlUke/UceKMjY4oMwRMUpJu3XhHnUWQbUPHaE6VmX7duQSaD9 uU/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=NM84GNzQ51TWu6N75z7AX4sq36naZosL0siQUhNUFBQ=; b=gujgDPcuC/Yyx/Vff7vLDXeAlh4I4q63LoChzQvPYbZK/ZluDYalfFPb3tdqdVWGrp MLJ/tX/mWZLo5YCbzuRxaqxh3tt5AtUheagCoTeOxks2OHQAgcQrt6xf1kcAS+RgcYSL HDftNakATPOQYbcTUXudOHbqZD8uO46rK8I4eMqxunEGxk6hQMjpXDu5x6tBLXP9+JMG PcuWhd1rXfenLlhradzus2QgQ1c6fwarVupjkHG6bv73aofc3yQEJ8IA8T2XBu0LMS4f NZfr/ZdIAmRwTdzdgWvAhch0FfwBsaRwtjeX8R/vvz+tCoaryZEJVSLtg0MlmO96x8+P o7ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SmVf177Y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id k23-20020a63ba17000000b003fe4da82aa6si1451500pgf.744.2022.07.28.08.13.08; Thu, 28 Jul 2022 08:13:24 -0700 (PDT) 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=@kernel.org header.s=k20201202 header.b=SmVf177Y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231310AbiG1PGS (ORCPT + 99 others); Thu, 28 Jul 2022 11:06:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230098AbiG1PGP (ORCPT ); Thu, 28 Jul 2022 11:06:15 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37464AE75; Thu, 28 Jul 2022 08:06:14 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EE40AB82491; Thu, 28 Jul 2022 15:06:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9E41C43141; Thu, 28 Jul 2022 15:06:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659020771; bh=NM84GNzQ51TWu6N75z7AX4sq36naZosL0siQUhNUFBQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SmVf177Y7g4o3fC3EZeRmI6afB70te8Box9vOzakNHqGCbxMa8278+LisvG7Ep2r+ gQQiueN8gA7JQq+j/vOdh+elKs24LHuD5WX4/zq2MDb3fN7e3TmXE6PcRUv7kCakKr RCtf2L7+HNRg+g1w4NTWwPPngaQZLIQjcNJT8j9f0JwLnliGxSYdkQqHBUx+yrBeDW m8pwQtmYANkg0P+qil/emW0hqqgdy5jSsSp+130n2AqywFtZYHfvn/r5WbN+3xDEQC MoJ4qCq1WL+z1L2c7OuoUur0hIykP56dspQNKSPezSUyGXhiOP7FtpF3qkGQGurJ3r tO3Hq01I/7Bvw== Received: by mail-oo1-f44.google.com with SMTP id u7-20020a4a8c07000000b00435ac1584a6so335212ooj.1; Thu, 28 Jul 2022 08:06:11 -0700 (PDT) X-Gm-Message-State: AJIora8hQ6WXO6HnRAlKjt+cbGDiQ656MY4+r2wFywMYZwB2NlQCv42E wJDjSsg+HoFoLmENc0sPppzogUsGZ98+xIJg7Qk= X-Received: by 2002:a4a:cb10:0:b0:435:9075:a86b with SMTP id r16-20020a4acb10000000b004359075a86bmr9416019ooq.98.1659020770744; Thu, 28 Jul 2022 08:06:10 -0700 (PDT) MIME-Version: 1.0 References: <20220723224949.1089973-5-luzmaximilian@gmail.com> <20220726143005.wt4be7yo7sbd3xut@bogus> <829c8fee-cae5-597d-933d-784b4b57bd73@gmail.com> <20220726154138.74avqs6iqlzqpzjk@bogus> <7284953b-52bb-37ac-fbe1-1fa845c44ff9@linaro.org> <3d752603-365d-3a33-e13e-ca241cee9a11@gmail.com> <20220727132437.pjob3z2nyxsuxgam@bogus> <20220728113347.ver6argevzmlsc2c@bogus> In-Reply-To: <20220728113347.ver6argevzmlsc2c@bogus> From: Ard Biesheuvel Date: Thu, 28 Jul 2022 08:05:58 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client To: Sudeep Holla Cc: Maximilian Luz , Ilias Apalodimas , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Steev Klimaszewski , Shawn Guo , Cristian Marussi , Greg Kroah-Hartman , linux-arm-msm , linux-efi , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 Thu, 28 Jul 2022 at 04:33, Sudeep Holla wrote: > > On Thu, Jul 28, 2022 at 12:48:19PM +0200, Maximilian Luz wrote: > > [...] > > > > > I would very much like to avoid the need for special bootloaders. The > > devices we're talking about are WoA devices, meaning they _should_ > > ideally boot just fine with EFI and ACPI. > > > > Completely agreed. > > > From an end-user perspective, it's annoying enough that we'll have to > > stick with DTs for the time being due to the use of PEPs in ACPI. > > But have we explored or investigated what it takes to rewrite ACPI f/w > to just use standard methods ? Does it require more firmware changes or > new firmware entities or impossible at any cost ? > > For me that is more important than just getting this one on DT. Because > if you take that path, we will have to keep doing that, with loads of > unnecessary drivers if they are not shared with any other SoC with DT > support upstream. We might also miss chance to get things added to the ACPI > spec as we don't care which means that we never be able to use ACPI on > similar future platforms even though they get shipped with ACPI. > > It will be a loop where we constantly keep converting this ACPI shipped > platform into DT upstream. IMHO we don't want to be there. > Supporting these devices in Linux in ACPI mode would involve reimplementing the PEP subsystem, and reimplementing PEP drivers for all these QCOM peripherals to manage the probing and the power states. I don't think this is realistic at all, and a huge waste of engineering effort otherwise. It is also orthogonal to the discussion, as far as I understand: ACPI is not telling the system whether or not these TZ services should be used instead of EFI runtime calls. So I think this is a reasonable way to expose these EFI services, although I am not thrilled about the fact that it is needed. Surprisingly, Microsoft also supports this model both on x86 and arm64 for platforms that keep their variables on eMMC (or any other kind of storage that sits behind a controller that cannot be shared between the OS and the firmware). So if we agree that we will support these systems as best we can, supporting EFI variables at runtime is something that we should support as well. (Note that I am not convinced about the latter point myself: on many systems, the EFI variable store is used precisely once, when GRUB gets installed and its path added to the boot order, so if we could find a way to streamline that without EFI runtime services, the story around why EFI runtime services are important becomes quite weak) As for the use of efivars_register(): I think this is reasonable, and the way these patches use it is exactly why it exists in the first place. Do not that a substantial overhaul of efivars is queued up in efi/next, although I suspect those changes do not conflict with this series.