Messages in this thread | | | Date | Thu, 28 Jul 2022 14:13:58 +0200 | Subject | Re: [PATCH 4/4] dt-bindings: firmware: Add Qualcomm UEFI Secure Application client | From | Maximilian Luz <> |
| |
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
| |