Is it necessary that FdtBusPkg depends on gEdkiiPlatformHasDeviceTreeGuid hardly?

[ChaiEvan]

For installing gFdtTableGuid to ConfigurationTable, FdtBusDxe registered a callback function and determined to install it or not by whether gEdkiiPlatformHasDeviceTreeGuid was installed

The logic sounds reasonable, but there is a scenario where this logic may not be suitable. When an SOC vendor intends to implement their platform firmware through FdtBusPkg, they would ideally want to implement ACPI through firmware code and not include PlatformHasAcpiDtDxe in their product code. However, FdtBusPkg has a strong dependency on PlatformHasAcpiDtDxe, which seems to be counterintuitive.

Consider that FdtBusDxe already checks gFdtHobGuid in its entry point, can we be confident that the current codebase adheres to the device tree-compatible hardware initialization mode? Also, is it possible to simplify the code, such as removing callbacks(mainly remove gEdkiiPlatformHasDeviceTreeGuid dependency ) from the entry point?

[andreiw]

As you point out, FdtBusDxe has logic to install the same FDT its using into the EFI Configuration Table. This logic mirrors the logic in FdtClientDxe - if the platform wants to expose DT to the OS, FdtBusDxe would be the agent to do it.

One of the goals of FdtBusDxe is to replace existing FdtClientDxe use. And if you look at FdtClientDxe, exposing the DT is one of the things it does. And curiously enough, when you do that, you may need to patch some values out depending on firmware configuration (which is why #9 is opened). And if you get that far, you realize that in a DT environment, the OS-visible DT is likely OS provided, not the firmware internal one, so what's really missing in FdtBusDxe today is something like EFI_DT_FIXUP_PROTOCOL, where existing DT drivers patch some DT blob. This probably means adding another callback in EFI_DT_IO_PROTOCOL_CB and figuring out how hide most of the complexity in the bus driver.

Yes, I get it, internal use of FDT has by itself nothing to do with potentially exposing the DT to an OS, which yes tangentially we don't really want to encourage because it makes more sense to embrace ACPI on non-embedded systems. But. It turns out that FdtBusDxe, as the mediator of all things DT in UEFI, really is the best place to figure this out. And sure, you can design it so that it is compiled out by default.

I disagree with your statement that this incurs a dependency on PlatformHasAcpiDtDxe. All this has is a dependency on gEdkiiPlatformHasDeviceTreeGuid. Anything can publish that GUID. For example, ArmVirtPkg/KvmtoolPlatformDxe/KvmtoolPlatformDxe.c (not PlatformHasAcpiDtDxe). Even BDS could be publishing that GUID, or a special loader. Literally anything.

I'm not sure I get the last part of your question. FdtBusDxe gets the FDT via gFdtHobGuid, which is the de facto standard way of doing so. What do you mean by "device tree-compatible hardware initialization mode"?