From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14A53C19F29 for ; Thu, 28 Jul 2022 15:16:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231228AbiG1PQo (ORCPT ); Thu, 28 Jul 2022 11:16:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230410AbiG1PQl (ORCPT ); Thu, 28 Jul 2022 11:16:41 -0400 Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 281A046D93 for ; Thu, 28 Jul 2022 08:16:40 -0700 (PDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-31f41584236so22850087b3.5 for ; Thu, 28 Jul 2022 08:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I/V7r/JjnXzUGcT6ui2gSCucu1LvJKddLujQ+JW0ayQ=; b=gtAegM1F7Ga+mua1tY0e5tEW6tISaVKUX4kBorZeA23I7ZxrtAHlX6MMeI7VPUS7Z8 JasOmqNpNBjQV13JSpTdrN/pR7yns90gilE4ACtbhzDK/p/HW6ySpgJ7CJZsLZNu2zNL CILNfwTlct/Rnd7xJdyp89hoOw+7XyPFNRCmIAzftsNXvDbdfKx3lCmeiCdfpMyMZKFu HYqcjJNSLeh7uKHSlcifaPueU54vOp10O3VVMNmFXGnlbYw61STJ0H+f1p0nssrlj7U5 J5cNHKjJ1RyN9kDYIkTS3HSMcSDpTeVIFGPLgotsQ/pyJ6a3VvKsvzPZ3J147/XOnS+U WvnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I/V7r/JjnXzUGcT6ui2gSCucu1LvJKddLujQ+JW0ayQ=; b=uuD+vvmoOCTSxIjcBuzyz6wwUix8c3L5ZYgmrLmukb4YhQ8MAQc6hivdmssinU/I1I kmahWTq0b0gIwchdpTDgIIAtC9kYhyhyQ5GtACBQWMDuUeyi+Vq4jQNpgWWmrZGvogoC 0HaX2P++x/15F3U+L0YUw/p6Bl4EM8pxSrwBSjpXOD1+ISYJZl5CeNqWauRNwKjBke6t zj9jzjnd5YXfZKH1OZz21WIhOchAcWY6EjVPCWQ71ifNaOZy8jlz/bB1GSsN/rqImavr tVbpQKIMewK8GZQ+Kg+OYWubfuJXJo0cGCzCBduBqyJLwUGKzODEVNE2xO5RySlm6h1g j/SA== X-Gm-Message-State: AJIora+umke44X5aaq1djSBcQ0zowh0sNmJTc+j3jLW9CTdBSs/hSE9f xIh6lVfhTtSa8V0joMZ0ZisNWp+jffb8ArE0hsnz4g== X-Google-Smtp-Source: AGRyM1vcmGJ+mmue/tBswMy79EHyowZgJFZhNzrIrwc9P7sgN6Pu3ui4GIF00O3/ldF3QTLG8lR4xHsP9ul10IGd220= X-Received: by 2002:a81:a149:0:b0:31f:fded:b121 with SMTP id y70-20020a81a149000000b0031ffdedb121mr5995007ywg.122.1659021399305; Thu, 28 Jul 2022 08:16:39 -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: From: Ilias Apalodimas Date: Thu, 28 Jul 2022 18:16:03 +0300 Message-ID: Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client To: Ard Biesheuvel Cc: Sudeep Holla , Maximilian Luz , 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Ard, [...] > > > 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) Unfortunately this is not entirely true. Yes the majority of use cases is what you describe, however we also need SetVariable for capsule update on disk. [...]