All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maximilian Luz <luzmaximilian@gmail.com>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Konrad Dybcio <konrad.dybcio@somainline.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Steev Klimaszewski <steev@kali.org>,
	Shawn Guo <shawn.guo@linaro.org>,
	Cristian Marussi <cristian.marussi@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-arm-msm@vger.kernel.org, linux-efi@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client
Date: Thu, 28 Jul 2022 14:13:58 +0200	[thread overview]
Message-ID: <e9c6e5dd-928c-c227-eb03-708e6b3e1a26@gmail.com> (raw)
In-Reply-To: <20220728113347.ver6argevzmlsc2c@bogus>

On 7/28/22 13: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 ?

Again, I'm not a Qualcomm employee. I would prefer it they'd use
standard methods in the future. Rewriting the ACPI tables based on the
information that we have is probably possible, but we'd again have to do
this on a device-by-device basis, so why not just write a DT instead?

Again, I'm not a Qualcomm employee. I would prefer it they'd use
standard methods in the future. I cannot say why they are using PEPs and
whether they can't just use something "normal". Rewriting the ACPI
tables based on the information that we have is probably possible, but
we'd again have to do this manually, on a device-by-device basis. So why
not just write a DT instead?

Apart from that they also unfortunately hard-code a lot of SoC specific
MMIO addresses into their drivers, so, for each SoC, they essentially
have their own ACPI HID even if the specific hardware interface hasn't
changed. It's bad all around... and I don't like it one bit either.

> 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.

I fully agree with that. And that is also something that I fear.

Unfortunately, the only way out that I can see is either Qualcomm
changing its ways or us supporting ACPI PEPs, doing hard-coded register
addresses based on ACPI HIDs, and converting a lot of existing drivers
written for DT/OF to support ACPI. I personally would prefer if we'd do
all that and hope that we can one day support PEPs.

Once we do, we'd at least "only" have to add the needed MMIO definitions
for drivers via HID matches and write a PEP driver for that specific SoC
(which would then be similar to regulator or clock controllers). Still
some work but a lot less than having to write DTs for each and every
possible model.

As much as I'd like to support and work on that, I'm doing this in my
free time, and this sounds like a big undertaking. At the moment, my
efforts are focused on making the Surface Pro X play (relatively) nice
with Linux (via DT). I had thought about this, but my time to work on
this is unfortunately limited. You'd probably have to ask e.g. the
Linaro folks for help and input (some of which, e.g. Bjorn Andersson
are currently working on DTs for WoA devices), and also convince the
ACPI maintainers.

Regards,
Max

  reply	other threads:[~2022-07-28 12:14 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-23 22:49 [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application Maximilian Luz
2022-07-23 22:49 ` [PATCH 1/4] firmware: qcom_scm: Export SCM call functions Maximilian Luz
2022-07-23 22:49 ` [PATCH 2/4] firmware: Add support for Qualcomm Trusted Execution Environment SCM calls Maximilian Luz
2022-07-23 22:49 ` [PATCH 3/4] firmware: Add support for Qualcomm UEFI Secure Application Maximilian Luz
2023-01-17  8:24   ` Johan Hovold
2023-01-17  8:42     ` Maximilian Luz
2023-01-18 20:45     ` Maximilian Luz
2023-01-19 16:47       ` Johan Hovold
2023-01-19 17:19         ` Maximilian Luz
2023-01-17 11:05   ` Johan Hovold
2023-01-17 12:07     ` Maximilian Luz
2022-07-23 22:49 ` [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client Maximilian Luz
2022-07-25  1:06   ` Rob Herring
2022-07-26 10:17   ` Krzysztof Kozlowski
2022-07-26 11:15     ` Maximilian Luz
2022-07-26 13:25       ` Krzysztof Kozlowski
2022-07-26 15:00         ` Maximilian Luz
2022-07-27 11:24           ` Krzysztof Kozlowski
2022-07-27 13:00             ` Maximilian Luz
2022-07-28  7:48               ` Krzysztof Kozlowski
2022-07-28 10:25                 ` Maximilian Luz
2022-07-28 10:38                   ` Krzysztof Kozlowski
2022-07-28 10:49                     ` Maximilian Luz
2022-07-26 14:30   ` Sudeep Holla
2022-07-26 15:15     ` Maximilian Luz
2022-07-26 15:41       ` Sudeep Holla
2022-07-26 17:01         ` Maximilian Luz
2022-07-27 11:38           ` Krzysztof Kozlowski
2022-07-27 13:03             ` Maximilian Luz
2022-07-27 13:24               ` Sudeep Holla
2022-07-27 14:49                 ` Maximilian Luz
2022-07-28  6:03                 ` Ilias Apalodimas
2022-07-28 10:48                   ` Maximilian Luz
2022-07-28 11:33                     ` Sudeep Holla
2022-07-28 12:13                       ` Maximilian Luz [this message]
2022-07-28 12:24                       ` Ilias Apalodimas
2022-07-28 15:05                       ` Ard Biesheuvel
2022-07-28 15:16                         ` Ilias Apalodimas
2022-07-28 16:16                         ` Sudeep Holla
2022-07-28 16:24                           ` Konrad Dybcio
2022-07-28 12:35                     ` Ilias Apalodimas
2022-07-28 12:49                       ` Maximilian Luz
2022-07-28 16:56                         ` Ilias Apalodimas
2022-07-28 17:27                           ` Maximilian Luz
2022-07-29  8:52                             ` Sudeep Holla
2022-07-29 15:11                               ` Maximilian Luz
2022-07-31  9:54                             ` Ilias Apalodimas
2022-07-31 22:48                               ` Maximilian Luz
2022-07-28  8:23           ` Sudeep Holla
2022-07-28 10:05             ` Maximilian Luz
2022-07-28 11:21               ` Sudeep Holla
2022-07-28 11:45                 ` Maximilian Luz
2022-07-28 13:42                   ` Sudeep Holla
2022-07-28 14:09                     ` Maximilian Luz
2022-07-25 19:27 ` [PATCH 0/4] firmware: Add support for Qualcomm UEFI Secure Application Rob Herring
2022-07-25 20:16   ` Maximilian Luz
2022-08-02 11:51 ` Srinivas Kandagatla
2022-08-02 13:22   ` Maximilian Luz
2022-08-02 14:02     ` Ard Biesheuvel
2022-08-02 19:11       ` Maximilian Luz
2022-09-02  7:26     ` Sumit Garg
2022-09-02 13:18       ` Maximilian Luz
2022-09-05  6:50         ` Sumit Garg
2022-11-23 11:22     ` Srinivas Kandagatla
2022-11-23 12:05       ` Maximilian Luz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9c6e5dd-928c-c227-eb03-708e6b3e1a26@gmail.com \
    --to=luzmaximilian@gmail.com \
    --cc=agross@kernel.org \
    --cc=ardb@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=cristian.marussi@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=konrad.dybcio@somainline.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shawn.guo@linaro.org \
    --cc=steev@kali.org \
    --cc=sudeep.holla@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.