From: Al Stone al.stone@linaro.org
These patches are experimental; they do actually compile and they even seem to execute correctly. They are by no means complete. The reason for posting them is really just to stir some discussion and see if this is a truly crazy idea or if it has some potential for easing the ACPI transition.
These patches introduce GUFI: the Grand Unified Firmware Interface. Okay, yes, it is a silly name. I didn't spend a lot of time on it. What I'm most interested in is the idea and whether it is worth pursuing further, and whether or not there are better ways to do this if it does make sense.
The idea is very simple: introduce a shim layer that looks like a merge of some sort between ACPI and FDT functionality in the kernel. In that shim layer, make it possible for a driver to make a single call to a function, and with that call, retrieve configuration information stored in either ACPI tables or a DT. Further, allow the kernel to specify which has priority -- i.e., search through ACPI tables, and then through FDT if data is not found, or vice versa -- or which is exclusive, either ACPI or FDT only.
Why would I do this? As a kernel developer, this allows me to make changes in the direction of either FDT or ACPI as quickly or as slowly as I want to. Most of my config can be in FDT and I can then piecemeal convert to ACPI as I figure out ASL and/or any driver changes that may be needed. Secondly, if I do this well, the changes to convert from FDT to ACPI *should* be very small; from ACPI to FDT may be more difficult but over time that can likely be improved as well. If someone was clever, they could even add support for a specific board file and gradually convert that to FDT or ACPI. Third, in the really, really long term, maybe someone comes up with yet another hardware configuration description format that is so cool it provides sharks with laser beams on their heads and *everyone* wants to convert to it. With this layer in place, perhaps we can smooth even that transition by abstracting out the config info that's needed and the API to retrieve it.
So, what do you think?
Changes in v2: -- Took a completely different approach to the overall structure based on feedback from Tomasz Nowicki. -- Changed an assumption: originally, I wanted to absolutely minimize the changes in API between OF and GUFI. That assumption has been dropped in favor of defining a more general API that will attempt to merge the best of ACPI and OF. -- The changes to vexpress-sysreg are for only one OF call for now. The previous version was more complete, but this version works. Over time, further changes will be made as each call is converted to this newer API.
Al Stone (4): GUFI: add kernel config options for GUFI GUFI: introduce the basic framework ARM64: GUFI: add setup_arch() call to gufi_init() GUFI: MFD: initial change to use one GUFI API call in vexpress-sysreg
arch/arm64/Kconfig | 6 - arch/arm64/kernel/setup.c | 5 + drivers/Kconfig | 2 + drivers/gufi/Kconfig | 44 +++++++ drivers/gufi/Makefile | 11 ++ drivers/gufi/acpi_protocol.c | 35 +++++ drivers/gufi/acpi_protocol.h | 37 ++++++ drivers/gufi/core.c | 296 ++++++++++++++++++++++++++++++++++++++++++ drivers/gufi/of_protocol.c | 44 +++++++ drivers/gufi/of_protocol.h | 37 ++++++ drivers/mfd/vexpress-sysreg.c | 5 +- include/linux/gufi.h | 62 +++++++++ 12 files changed, 577 insertions(+), 7 deletions(-) create mode 100644 drivers/gufi/Kconfig create mode 100644 drivers/gufi/Makefile create mode 100644 drivers/gufi/acpi_protocol.c create mode 100644 drivers/gufi/acpi_protocol.h create mode 100644 drivers/gufi/core.c create mode 100644 drivers/gufi/of_protocol.c create mode 100644 drivers/gufi/of_protocol.h create mode 100644 include/linux/gufi.h