[PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER
From: Grant Likely <hidden>
Date: 2018-09-05 19:10:09
Also in:
lkml
On Wed, Sep 5, 2018 at 10:37 AM Ard Biesheuvel [off-list ref] wrote:
On 4 September 2018 at 12:13, Grant Likely [off-list ref] wrote:quoted
On Tue, Sep 4, 2018 at 7:24 AM Ard Biesheuvel [off-list ref] wrote:quoted
On 2 September 2018 at 04:54, Olof Johansson [off-list ref] wrote:quoted
On Thu, Aug 30, 2018 at 9:23 AM, Ard Biesheuvel [off-list ref] wrote:quoted
On 30 August 2018 at 17:06, Olof Johansson [off-list ref] wrote:quoted
On Wed, Aug 29, 2018 at 10:54 PM, Ard Biesheuvel [off-list ref] wrote:quoted
Don't be surprised if some future enhancements of the EFI stub code depend on !EFI_ARMSTUB_DTB_LOADER.That's an odd statement to make. The DTB loader code is well contained and with defined semantics... True, the semantics are "I DON'T BELIEVE FIRMWARE", but it is still well defined. What scenario are you envisioning where EFI_ARMSTUB_DTB_LOADER would be explicitly excluded?Well, to be honest, I don't have a real-world example at hand, but my concern is about cases where the firmware provided DTB and the override DTB diverge in a way that leaves it up to the EFI stub to reconcile them and/or to reason about which one it should prefer. One example could be OP-TEE support: currently, we put a /firmware/optee node in the DT to inform the OS that OP-TEE is running in the secure world. If we allow a DT to be provided via dtb= that provides such a node, we are blocking all future opportunities in future kernels to do any kind of preparatory OP-TEE related initialization in the EFI stub [while boot services are still available] unless we decide to make it the EFI stub's problem to reason about which version of the DT is the correct one to use. What if the firmware's DT has /firmware/optee/status = disabled and the dtb= one does not? Another trivial example is GRUB: passing dtb= via the command line will break initrds loaded via GRUB, since they are passed via the /chosen node.
Using 'dtb=' straight out means *I don't believe anything firmware tells me*, so of course nothing like OP-TEE integration, command line passing, dynamic configuration, or anything that firmware might want to tell the kernel is going to work. Anyone who uses dtb= gets to keep the pieces when they break stuff. That can be written down into policy in the dtb= documentation if you like. I've just posted a patch to do that. g.