Hi, > > > That > > > sounds like an arcane board file equivalent, and is counter to the > > > entire reason for using UEFI and ACPI -- having a well-defined > > > (excluding particular driver bindings, and I'm not arguing well-defined > > > means nice) stable standard that allows the kernel to boot on an > > > arbitrary platform without requiring arbitrary platform-specific code > > > everywhere in the boot path. > > > > > > It might not be pretty, and it will certainly require a lot of work, but > > > I'd prefer it at least for a semblance of uniformity. > > > > That is a red herring -- that booting standard has _nothing_ to do with > > ACPI. Once you've got a standard that is well-defined enough like that, > > you no longer need the runtime portions of ACPI to deal with it. You > > can just hardcode it. You need a way to probe _which_ type of standard > > is used, but from there on out you can assume that things are the same > > way. > > The UEFI spec pulls in portions of ACPI. I do not know the full extent > of the interaction between the two, but I know that they are not > completely decoupled. As you have pointed out we are not experienced > with ACPI or UEFI, so I don't think we can make statements that one is > perfectly fine without the other. Given Leif's comments it seems that they are decoupled sufficiently to be considered separately. Apologies for adding to the confusion here. Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
