On 2015年02月07日 13:03, Ard Biesheuvel wrote:
On 7 February 2015 at 03:36, Hanjun Guo <hanjun.guo@xxxxxxxxxx> wrote:
On 2015年02月06日 18:34, G Gregory wrote:
[...]
--------------------------------------------------------------------------------
linux,uefi-stub-kern-ver | string | Copy of linux_banner from
build.
--------------------------------------------------------------------------------
+linux,uefi-stub-generated-dtb | bool | Indication for no DTB
provided by
+ | | firmware.
+--------------------------------------------------------------------------------
Apologies for the late bikeshedding, but the discussion on this topic
previsously was lively enough that I thought I'd let it die down a bit
before seeing if I had anything to add.
That, and I just realised something:
One alternative to this added DT entry is that we could treat the
absence of a registered UEFI configuration table as the indication
that no HW description was provided from firmware, since the stub does
not call InstallConfigurationTable() on the DT it generates. This does
move the ability to detect to after efi_init(), but this should be
fine for ACPI-purposes.
That would not work as expected in the kexec/Xen use case though as they
may genuinely boot with DT from an ACPI host without UEFI.
I'm a little concerned by this case. How do we intend to pass stuff from
Xen to the kernel in this case? When we initially discussed the stub
prior to merging, we weren't quite sure if ACPI without UEFI was
entirely safe.
The linux,uefi-stub-kern-ver property was originally intended as a
sanity-check feature to ensure nothing (including Xen) masqueraded as
the stub, but for some reason the actual sanity check was never
implemented.
If that is deemed undesirable, I would still prefer Catalin's
suggested name ("linux,bare-dtb"), which describes the state rather
than the route we took to get there.
I agree.
I guess this would be ok, though it would be nice to know which agent
generated the DTB.
The most obvious scheme then is
linux,bare-dtb = "uefi-stub";
otherwise we generate a new binding for every component in the boot path.
Leif, Mark, any comments on this?
As far as I remember, we did not finalize the decision to go with a
stub generated property instead of some other means to infer that the
device tree is not suitable for booting and ACPI should be preferred.
We will be discussing the 'stub<->kernel interface as a boot protocol'
topic this week at Connect, so let's discuss it in that context before
signing off on patches like these.
OK, see you guys in Hongkong.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
