On Mon, 25 Nov 2024 at 18:46, Levi Yun <yeoreum.yun@xxxxxxx> wrote: > > Hi Ard. > > > I take it this is working around buggy firmware that passes both a DT > > and ACPI tables, and the DT in question is broken? > > > > If so, this should be fixed in the firmware. The EFI stub does not > > reason at all about ACPI boot vs DT boot, and I would prefer to keep > > it that way, especially because this code is shared with other > > architectures. For instance, the meaning of acpi= could differ between > > architectures, or they may not implement ACPI in the first place. > > What I concern is that It doesntt necessary to check DT > otherwise if the FDT variable in variable storage's contents is > corrupted, it would complain while it check in early_init_dt_scan() > thou the dt isn't used in boot process. > The DT is not stored in a variable. If CONFIG_EFI_ARMSTUB_DTB_LOADER is enabled, it may be provided via dtb= on the command line, but I have little sympathy for a user that passes both dtb= *and* acpi=force, so this is a scenario that we can ignore. Otherwise, it is taken from a EFI config table, which is just a <guid,addr> tuple describing a location in physical memory where the firmware has placed a DT. If the firmware puts a corrupted DT there, the firmware should be fixed instead. acpi=force is intended to force the use of ACPI tables on a system that provides both. > also, although acpi= could differ from architecture, the force option's menaing > seems the same over architecture (ignore DT boot with ACPI tables). > > So I think the check the "acpi=force" option to prevent loading DT seems > good. > The EFI stub does not care about ACPI vs DT boot, and I'd prefer to keep it that way unless there is a good reason. Which real-world problem does this patch aim to solve?
