Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp583880imn; Thu, 28 Jul 2022 09:35:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vbk6kvZRM6Xpln6xoSI2xOqvlQIDRkl+5FK6Hj2zA5BfDs2c16Fq1/MOzts3kFD8Zoco9q X-Received: by 2002:a63:1a4c:0:b0:416:1821:733d with SMTP id a12-20020a631a4c000000b004161821733dmr23180410pgm.444.1659026110881; Thu, 28 Jul 2022 09:35:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659026110; cv=none; d=google.com; s=arc-20160816; b=lO27d+6bP3bdVTGqjiQyNjcJRaMBwaQaIHr0A8vLFi1v/b5/MN4ZplIXCqwAPOS/2J 1X68PwV/xGF35VAqr2ncadTiZHe0fNMOI3/RnvXMrbXG2Cr4q9kbPqIZ8n+x+Ca4FBrH zU2Snf0b7petssHVZ82HycDAnYU7gY6JumiVbJCDgbGqOCDQqYMu7BB3kJ8TpQ7dOSIi Qi9dtmfCG64ob7bEUMpov2u2EgQLwv1EC5AfKfa1Nw42wuEZwwnUU0/EbQw6qoK2Q1kF JwBjvJkaRa8SOTdyZJahEaLKpkCJld4yO5aoDyFjf3Hoy5kBbh5czrNv96kUuRWP6XeA iB2g== 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:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=Ke+C3RPmDmku6IT0wWFBkXIvB3T6JSGDoWTUHaGgLcQ=; b=HP6mMBDWi111C7KmE+ele/orXQQv3Dl5EmNdxHiHhypD9aw49T/C7An/D+zTF1XxD0 NhTYmujbnf4CJZNu3DLxvhlhD+MkEoBmvmFFtD0Qxawq2Bw2KG93x9E+xiMO9LAPcwWJ svCcXEjiTavvEgDEgvsNmLt+0dlOciTLuiI8NGzmK7G8J0uloe+KCoHWcaWk1Qy3qEe8 VYd+FVlyEsF269XwmC6sqom88lgYjru2rCC0qrAd/AzZ4j7+ROlStdIMTIW53g8B5zpH WP/946T3fkNoE4cSwjMZ3owFrTreENwvN07ZGrkyVkACInImSSFGVfPdkH46oLM169TG 49CA== ARC-Authentication-Results: i=1; mx.google.com; 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 c2-20020a170902c1c200b0016d12d40615si1223068plc.544.2022.07.28.09.34.54; Thu, 28 Jul 2022 09:35:10 -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; 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 S231659AbiG1QZC (ORCPT + 99 others); Thu, 28 Jul 2022 12:25:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231358AbiG1QZA (ORCPT ); Thu, 28 Jul 2022 12:25:00 -0400 Received: from relay02.th.seeweb.it (relay02.th.seeweb.it [IPv6:2001:4b7a:2000:18::163]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4FE370E58 for ; Thu, 28 Jul 2022 09:24:59 -0700 (PDT) Received: from [192.168.1.101] (abxi232.neoplus.adsl.tpnet.pl [83.9.2.232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id E13361F888; Thu, 28 Jul 2022 18:24:55 +0200 (CEST) Message-ID: Date: Thu, 28 Jul 2022 18:24:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client Content-Language: en-US To: Sudeep Holla , Ard Biesheuvel Cc: Maximilian Luz , Ilias Apalodimas , Krzysztof Kozlowski , Andy Gross , Bjorn Andersson , 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 References: <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> <20220728161611.qc6ksoecg64rkov5@bogus> From: Konrad Dybcio In-Reply-To: <20220728161611.qc6ksoecg64rkov5@bogus> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 28.07.2022 18:16, Sudeep Holla wrote: > On Thu, Jul 28, 2022 at 08:05:58AM -0700, Ard Biesheuvel wrote: >> 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. >> > > I am aware of that and hence I am happy to see these as one off drivers > if needed. But if we don't stop that or keep converting them to DT, > IMO we will be in vicious circle of this conversion and will never be > able to support ACPI natively on these platforms. I think that people have given up on ACPI on Snapdragon, as it was not providing enough information in some cases (such as TLMM pins that are not accessible from the AP due to being marked 'secure') that needed to be hardcoded. New WoA laptop support is added using FDT and I haven't seen any patches even adding ACPI matchlists for a long long time. Konrad I know it is huge > effort and not expecting that to be done here, but we need to convey the > message to use ACPI standards or improve it if there is a need. Using > PEP is not helpful to run Linux in the long run. Also we may hit a point > when it may not be trivial to do that ACPI<->DT conversion. > >> 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. >> > > Agreed and I don't want to block any such discussions. Sorry if I derailed > the discussion, that was not my intentions. > > -- > Regards, > Sudeep