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 624BFC04A68 for ; Thu, 28 Jul 2022 12:25:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238394AbiG1MZA (ORCPT ); Thu, 28 Jul 2022 08:25:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238366AbiG1MYy (ORCPT ); Thu, 28 Jul 2022 08:24:54 -0400 Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B36566C108 for ; Thu, 28 Jul 2022 05:24:52 -0700 (PDT) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-31bf3656517so17135387b3.12 for ; Thu, 28 Jul 2022 05:24:52 -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=fPGazMImeq7ZTnaeZ4AGBk0ohlKyyO3QqrKwonvdhpM=; b=fvhONg60bsGwrIHA6bNhsT18PaJmu/2fNF1Lc/SzqBFyU6F7SX+QoTz7oJj0Eo+Bcp YK4p49P2pJjPF6JoiUeG6RQFeNk5awUnc8amp9wuZAJOeLBxqlIFnJtsnW8KKJnPKAlO HlEwteYdyw6ojA1RB10fyUenKWffwJimbpG5FHibao9UhPDS8OMTPBZrHur0hYfxxut+ o4+K0QCpXOfJfkn0u+VaAsk+CiaddG3CfVz13pCC2alc0np/Kt2D1N1hg8DGtFvigmwA 0tW0GV6TO88ORk1mwskI8ONAivniVnCEa9ZlXYUm2QnRLGkJZNWuxoZq4EwPUcXwoSZl KAyg== 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=fPGazMImeq7ZTnaeZ4AGBk0ohlKyyO3QqrKwonvdhpM=; b=maJ3Ezp1+bCEzshSPJwPLAtyRizL+2b7l/kGKXRLh3BqwDZBeYsKmdwxOcu1soVVjW jDPjYGq7fFmHPBeq9uNggCPFvnZkVm4E5n0J1TKv8OvhebtjFORcPe5quvLarnhNEqte 9bpD9+RiqXMI7FFTBbapGEMpYUILSgP2h3IWaq/RhehGf9QIUoX/MbHfo3UQ/k1T3boV 5FHEO5XZloOrxdRmKRhfuULWfvUCpjQZn5lsZp9/8PYnJytsT+5LW9r8vZx+F6pLJX6J BUu+ERbGvjHK8laNAArrvw4IJJNwALBFfB9wA7ApDdgkOIsy5XvFIPpAcWqvPAoUPVcn 1RNA== X-Gm-Message-State: AJIora9XlXWSPIdth3m1x0jflwxUMLBrliK7jDfznNGi4pBbOyQteuIz TT+4+wrXfFMgaXOtdwGmIIO7jjVsbmPLsr1RACjfow== X-Google-Smtp-Source: AGRyM1vI7wkmsv9IiuZ7uHDOT8/GD4OMIdM7ZmEHjlWiZkaeOZ1vzw9DdzMlOn/B2DaC5n+8y5yYKGlcs1IlnUMRpcQ= X-Received: by 2002:a81:e03:0:b0:31f:4e64:3e9e with SMTP id 3-20020a810e03000000b0031f4e643e9emr10513132ywo.128.1659011091852; Thu, 28 Jul 2022 05:24:51 -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: Ilias Apalodimas Date: Thu, 28 Jul 2022 15:24:15 +0300 Message-ID: Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client To: Sudeep Holla Cc: Maximilian Luz , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , Ard Biesheuvel , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Steev Klimaszewski , Shawn Guo , Cristian Marussi , Greg Kroah-Hartman , linux-arm-msm@vger.kernel.org, linux-efi@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Thu, 28 Jul 2022 at 14: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. This is not a special bootloader though. Quite the opposite. It's a standard UEFI compliant bootloader, which uses the fact that EFI is supposed to be extensible. It installs a linux specific config table, similar to how we install a linux specific protocol to load our initrd and it's certainly lot more scalable than adding new stuff to the device tree. > > > 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. > > -- > Regards, > Sudeep Regards /Ilias