ACPI vs Device Tree - moving forward

This conversation seems to have pretty much entirely ended up happening on ksummit-discuss, which doesn't seem that useful. So let's have another go with a wider audience (and where I don't have to sign up for yet another mailing list...)

ACPI and DT overlap in that they both provide a mechanism for enumerating non-enumerable devices, and both also provide a mechanism for attaching additional configuration data to devices (which may or may not be otherwise enumerable). There's a sufficient overlap in functionality that at least one platform that's traditionally been Device Tree (arm) is also adding support for ACPI - there's even ACPI-based arm hardware on the market already.

Right now that's a problem for us. The same hardware may end up shipped with either ACPI or DT-based firmware, and at the moment we'd need to either write two drivers or one driver with two glue layers. This is somewhat suboptimal.

The biggest difference between DT and ACPI is that DT is effectively a somewhat structured mechanism for passing arbitrary data, while ACPI tends (with exceptions) to provide standardised data. For instance, in DT we might have:

        sdhci@c8000000 {
                status = "okay";
                power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
                bus-width = <4>;
                keep-power-in-suspend;
        };

In ACPI the normal way to handle this would be to have a GPIO operation region that listed the GPIOs:

OperationRegion(GPO1, GeneralPurposeIO, 0, 1)
Field(GP01, ByteAcc, NoLock, Preserve)
{
Connection (GpioIo(Exclusive, PullUp,,,,,)
TG06, 1
}

And then an ACPI device:

Device (\_SB.SDHC)

{
	Method (_PS0, 0, NotSerialized)
	{
		Store (1, TG06)
	}
	Method (_PS3, 0, NotSerialized)
	{
		Store (0, TG06)
	}
}

with the ACPI core then executing these methods whenever a device is powered up or down.

How can we unify these two different representations? The only terribly plausible way of doing so seems to be to push that out to a helper function and then have it handled as part of device runtime power management, and just have the driver make pm_runtime_get() and _put() calls.

So we can theoretically handle cases like power lines without /too/ much trouble, while representing the same thing in either ACPI or DT. But we have plenty of other data - in the case of SDHCI alone, there's the bus width and potentially card detect and write protect gpio lines. These can easily be represented in ACPI, but not in a terribly generic way. We could easily add new functions to retrieve this information, but doing this through the standards body is likely to prove tedious, especially when new hardware types appear and we want to be able to ship support pretty much immediately.

The other choice is to ignore most of the existing ACPI functionality and just use it as a mechanism for providing additional metadata. Apple already do this using the _DSM methods:

Method (_DSM, 4, NotSerialized)

{
	Store (Package (0x07)
        {
        	"refnum", 
                0x00, 
		"address",
		0x39,
		"device-id",
		0x0cc8,
                Buffer (0x01)
                {
                	0x00
                }
        }, Local0)
        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
        Return (Local0)
}

where the DTGP() method verifies that the caller passed in an appropriate UUID and then hands back this buffer.

Putting all our existing DT metadata in there would be straightforward, but we would then effectively just be using ACPI to repackage DT - drivers would continue to make DT-specific calls in order to obtain the information they need.

This seems like the least-effort approach, but it doesn't really solve much. Any other OS on the same hardware is unlikely to use the DT data, and if someone wants to run Linux on hardware that was intended for another OS they're unlikely to have any DT data to use.

So while unifying this seems hugely desirable, right now it's not incredibly obvious how we can actually achieve that. In some cases it's easy to take DT information and rewrite it the ACPI way, but in others we just don't seem to have the primitives we need for that. One approach would be to work through the existing DT bindings documentation and see what's missing from ACPI and work on adding it, but we'll still then need helper functions that are able to obtain the same information from either source.

In any case, it seems like this is something that should be discussed. A bunch of people in the earlier discussion mentioned that they were going to be in New Orleans, so I'd suggest that we arrange a time for in-person discussion there. That should give us a solid basis for further mailing list discussion, and then there'll be another opportunity for discussion in Edinburgh.

It seems to me that the only way to end up in a situation where the data is reused by other OSes, is to go through a standards body. What about attempting to standardize the _DSM method? I suppose the challenge then is how do we standardize arbitrary data (which, of course, is an oxymoron)...

The interesting thing about this to me is that many of these devices are added after-the-fact (as add-on boards, for example). With the MinnowBoard we are looking to provide this configuration data in an EEPROM. Would it make sense for the device manufacturer (rather than the base-board manufacturer) to define the key-value pairs for their hardware?

Sadly, I will not be in New Orleans and am unlikely to receive a Kernel Summit invite, but I am planning be in Edinburgh and would like the opportunity to participate in this discussion.

Quoted 5 lines · Darren Hart

It seems to me that the only way to end up in a situation where the data is reused by other OSes, is to go through a standards body. What about attempting to standardize the _DSM method? I suppose the challenge then is how do we standardize arbitrary data (which, of course, is an oxymoron)...

Right. We could certainly spec the DT bindings that currently exist, but the obvious pushback is that large chunks of it *are* already in ACPI - a _PS0 method (which is ACPI for "Power up the device") that toggles a GPIO pin, and then provides a different GPIO pin in the DT data, which would we believe?

Quoted 6 lines

The interesting thing about this to me is that many of these devices are added after-the-fact (as add-on boards, for example). With the MinnowBoard we are looking to provide this configuration data in an EEPROM. Would it make sense for the device manufacturer (rather than the base-board manufacturer) to define the key-value pairs for their hardware?

Yes, hardware information that's on add-in boards should probably be provided by the add-in board if it carries a ROM. This is trivial on UEFI systems - you just need a UEFI driver for the board that can construct an appropriate SSDT. It's more of a problem for non-UEFI ACPI systems.

Quoted 3 lines

Sadly, I will not be in New Orleans and am unlikely to receive a Kernel Summit invite, but I am planning be in Edinburgh and would like the opportunity to participate in this discussion.

I'm not planning on being at kernel summit this year, so I think we'll try to arrange something around that time but outside the event.

Quoted 5 lines · Darren Hart

It seems to me that the only way to end up in a situation where the data is reused by other OSes, is to go through a standards body. What about attempting to standardize the _DSM method? I suppose the challenge then is how do we standardize arbitrary data (which, of course, is an oxymoron)...

Right. We could certainly spec the DT bindings that currently exist, but the obvious pushback is that large chunks of it *are* already in ACPI - a _PS0 method (which is ACPI for "Power up the device") that toggles a GPIO pin, and then provides a different GPIO pin in the DT data, which would we believe?

Quoted 6 lines

The interesting thing about this to me is that many of these devices are added after-the-fact (as add-on boards, for example). With the MinnowBoard we are looking to provide this configuration data in an EEPROM. Would it make sense for the device manufacturer (rather than the base-board manufacturer) to define the key-value pairs for their hardware?

Yes, hardware information that's on add-in boards should probably be provided by the add-in board if it carries a ROM. This is trivial on UEFI systems - you just need a UEFI driver for the board that can construct an appropriate SSDT. It's more of a problem for non-UEFI ACPI systems.

Quoted 4 lines

Sadly, I will not be in New Orleans and am unlikely to receive a Kernel Summit invite, but I am planning be in Edinburgh and would like the opportunity to participate in this discussion.

I'm not planning on being at kernel summit this year, so I think we'll try to arrange something around that time but outside the event.

Quoted 5 lines · Darren Hart

It seems to me that the only way to end up in a situation where the data is reused by other OSes, is to go through a standards body. What about attempting to standardize the _DSM method? I suppose the challenge then is how do we standardize arbitrary data (which, of course, is an oxymoron)...

Right. We could certainly spec the DT bindings that currently exist, but the obvious pushback is that large chunks of it *are* already in ACPI - a _PS0 method (which is ACPI for "Power up the device") that toggles a GPIO pin, and then provides a different GPIO pin in the DT data, which would we believe?

Quoted 6 lines

The interesting thing about this to me is that many of these devices are added after-the-fact (as add-on boards, for example). With the MinnowBoard we are looking to provide this configuration data in an EEPROM. Would it make sense for the device manufacturer (rather than the base-board manufacturer) to define the key-value pairs for their hardware?

Yes, hardware information that's on add-in boards should probably be provided by the add-in board if it carries a ROM. This is trivial on UEFI systems - you just need a UEFI driver for the board that can construct an appropriate SSDT. It's more of a problem for non-UEFI ACPI systems.

Quoted 3 lines

Sadly, I will not be in New Orleans and am unlikely to receive a Kernel Summit invite, but I am planning be in Edinburgh and would like the opportunity to participate in this discussion.

I'm not planning on being at kernel summit this year, so I think we'll try to arrange something around that time but outside the event.

This conversation seems to have pretty much entirely ended up happening on ksummit-discuss, which doesn't seem that useful. So let's have another go with a wider audience (and where I don't have to sign up for yet another mailing list...)

ACPI and DT overlap in that they both provide a mechanism for enumerating non-enumerable devices, and both also provide a mechanism for attaching additional configuration data to devices (which may or may not be otherwise enumerable). There's a sufficient overlap in functionality that at least one platform that's traditionally been Device Tree (arm) is also adding support for ACPI - there's even ACPI-based arm hardware on the market already.

Right now that's a problem for us. The same hardware may end up shipped with either ACPI or DT-based firmware, and at the moment we'd need to either write two drivers or one driver with two glue layers. This is somewhat suboptimal.

The biggest difference between DT and ACPI is that DT is effectively a somewhat structured mechanism for passing arbitrary data, while ACPI tends (with exceptions) to provide standardised data. For instance, in DT we might have:

        sdhci@c8000000 {
                status = "okay";
                power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>;
                bus-width = <4>;
                keep-power-in-suspend;
        };

In ACPI the normal way to handle this would be to have a GPIO operation region that listed the GPIOs:

OperationRegion(GPO1, GeneralPurposeIO, 0, 1)
Field(GP01, ByteAcc, NoLock, Preserve)
{
Connection (GpioIo(Exclusive, PullUp,,,,,)
TG06, 1
}

And then an ACPI device:

Device (\_SB.SDHC)

{
	Method (_PS0, 0, NotSerialized)
	{
		Store (1, TG06)
	}
	Method (_PS3, 0, NotSerialized)
	{
		Store (0, TG06)
	}
}

with the ACPI core then executing these methods whenever a device is powered up or down.

How can we unify these two different representations? The only terribly plausible way of doing so seems to be to push that out to a helper function and then have it handled as part of device runtime power management, and just have the driver make pm_runtime_get() and _put() calls.

So we can theoretically handle cases like power lines without /too/ much trouble, while representing the same thing in either ACPI or DT. But we have plenty of other data - in the case of SDHCI alone, there's the bus width and potentially card detect and write protect gpio lines. These can easily be represented in ACPI, but not in a terribly generic way. We could easily add new functions to retrieve this information, but doing this through the standards body is likely to prove tedious, especially when new hardware types appear and we want to be able to ship support pretty much immediately.

The other choice is to ignore most of the existing ACPI functionality and just use it as a mechanism for providing additional metadata. Apple already do this using the _DSM methods:

Method (_DSM, 4, NotSerialized)

{
	Store (Package (0x07)
        {
        	"refnum", 
                0x00, 
		"address",
		0x39,
		"device-id",
		0x0cc8,
                Buffer (0x01)
                {
                	0x00
                }
        }, Local0)
        DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
        Return (Local0)
}

where the DTGP() method verifies that the caller passed in an appropriate UUID and then hands back this buffer.

Putting all our existing DT metadata in there would be straightforward, but we would then effectively just be using ACPI to repackage DT - drivers would continue to make DT-specific calls in order to obtain the information they need.

This seems like the least-effort approach, but it doesn't really solve much. Any other OS on the same hardware is unlikely to use the DT data, and if someone wants to run Linux on hardware that was intended for another OS they're unlikely to have any DT data to use.

So while unifying this seems hugely desirable, right now it's not incredibly obvious how we can actually achieve that. In some cases it's easy to take DT information and rewrite it the ACPI way, but in others we just don't seem to have the primitives we need for that. One approach would be to work through the existing DT bindings documentation and see what's missing from ACPI and work on adding it, but we'll still then need helper functions that are able to obtain the same information from either source.

In any case, it seems like this is something that should be discussed. A bunch of people in the earlier discussion mentioned that they were going to be in New Orleans, so I'd suggest that we arrange a time for in-person discussion there. That should give us a solid basis for further mailing list discussion, and then there'll be another opportunity for discussion in Edinburgh.

Quoted 4 lines · Matthew Garrett

This conversation seems to have pretty much entirely ended up happening on ksummit-discuss, which doesn't seem that useful. So let's have another go with a wider audience (and where I don't have to sign up for yet another mailing list...)

Quoted 6 lines

In any case, it seems like this is something that should be discussed. A bunch of people in the earlier discussion mentioned that they were going to be in New Orleans, so I'd suggest that we arrange a time for in-person discussion there. That should give us a solid basis for further mailing list discussion, and then there'll be another opportunity for discussion in Edinburgh.

There is a time slot reserved for the second part of the ACPI/PM+PCI uconf that may be used for this purpose if it's suitable for all of the interested people. It is scheduled at 2 PM on Thursday, September 19 at the moment (concurrently with the containers uconf).

There's one more problematic case which is that some systems ship with ACPI tables that don't contain all of the information necessary to enumerate hardware appropriately and it's difficult, if not impossible, to convince the vendors of those systems to fix their ACPI firmware after the fact. However, at least in some cases there are well defined DT bindings for the hardware in question.

- The I2C address is specified in "reg" - maybe ACPI have some other way to assign I2C addresses to I2C devices? In any case, it *must* reference the parent I2C controller, here that is done implicitly by placing this DT node inside the I2C controllers DT node.

- Then it is using a GPIO line as interrupt, and specify that this shall be configured as a falling edge IRQ.

- It then tells the interrupt controller parent. So it needs to have a reference to whatever interrupt chip device will handle that IRQ.

- Further it *is* an interrupt controller, so devices connected to the GPIO lines may generate IRQs and then this device should service them. Is it possible that the devices connected to this expander in turn use ACPI to describe themselves? Then we need a reference in the other direction.

- Further it is a wakeup source, so each IRQ it provides on its GPIO lines can be set as a wakeup. I wonder how this plays with D-states and ACPI.

I did present the above as an extreme example, but if we start to combine DT and ACPI we have to have that kind of hardware in mind. GPIO expanders with IRQs and all are maybe rare on desktops and laptops but very common on embedded systems.

Quoted 5 lines · Linus Walleij

- The I2C address is specified in "reg" - maybe ACPI have some other way to assign I2C addresses to I2C devices? In any case, it *must* reference the parent I2C controller, here that is done implicitly by placing this DT node inside the I2C controllers DT node.

That's fine. You put the child device inside the I2C contorller's scope, which can be done from a separate ACPI table if you want. The address can be provided via _ADR().

Quoted 2 lines

- Then it is using a GPIO line as interrupt, and specify that this shall be configured as a falling edge IRQ.

ACPI 5 permits this.

Quoted 3 lines

- It then tells the interrupt controller parent. So it needs to have a reference to whatever interrupt chip device will handle that IRQ.

By interrupt controller, do you mean the GPIO controller? ACPI GPIO definitions include the parent device.

Quoted 6 lines

- Further it *is* an interrupt controller, so devices connected to the GPIO lines may generate IRQs and then this device should service them. Is it possible that the devices connected to this expander in turn use ACPI to describe themselves? Then we need a reference in the other direction.

I think that's also doable.

Quoted 3 lines

- Further it is a wakeup source, so each IRQ it provides on its GPIO lines can be set as a wakeup. I wonder how this plays with D-states and ACPI.

That's fine. GPIO lines can be described as causing ACPI events and then that simply referenced as a wakeup event.

Quoted 5 lines

I did present the above as an extreme example, but if we start to combine DT and ACPI we have to have that kind of hardware in mind. GPIO expanders with IRQs and all are maybe rare on desktops and laptops but very common on embedded systems.

Yeah, describing complicated device topology isn't really the problem I think we'll end up facing - it's the wider range of device configuration data that worries me.

Moreover, even if we are able to instruct everyone interested how to create the requisite ACPI tables, there is the little problem of shipping them somehow so that they actually can be used by the kernel that needs to be addressed too.

Quoted 4 lines · Rafael J. Wysocki

Moreover, even if we are able to instruct everyone interested how to create the requisite ACPI tables, there is the little problem of shipping them somehow so that they actually can be used by the kernel that needs to be addressed too.

I think the expectation in the ACPI ecosystem has to be that devices ship their own ACPI tables. I can't see any benefit in using ACPI if the aim is to just carry on shipping files with the kernel or install media
- in that case, just use DT.

And now the practice appears to be that vendors actually ship some ACPI tables with their systems, but those ACPI tables do not contain information needed to enumerate all devices. On the other hand, it is known what the DT bindings for the missing part should be. How can we address this?

Next, say we have a driver written with DT bindings in mind and there's an ACPI-based system with identical hardware, although wired up slightly differently. Say that all of the information needed by that driver is there in the ACPI tables (Q: How the vendor is supposed to know what information the driver expects?). Who is supposed to take care of updating the driver to be able to use ACPI in addition to DTs?

I don't honestly think that the "ask vendors to ship their systems with correct ACPI tables" approach will take us anywhere.

Quoted 4 lines · Rafael J. Wysocki

And now the practice appears to be that vendors actually ship some ACPI tables with their systems, but those ACPI tables do not contain information needed to enumerate all devices. On the other hand, it is known what the DT bindings for the missing part should be. How can we address this?

On ARM? I know that this is true on x86, but that's because x86 vendors have never intended i2c hardware monitoring devices be driven by a general purpoes OS - they're there for the benefit of the firmware, not anything above that.

Quoted 6 lines

Next, say we have a driver written with DT bindings in mind and there's an ACPI-based system with identical hardware, although wired up slightly differently. Say that all of the information needed by that driver is there in the ACPI tables (Q: How the vendor is supposed to know what information the driver expects?). Who is supposed to take care of updating the driver to be able to use ACPI in addition to DTs?

Ideally we have a consistent in-kernel representation of this information and drivers don't need to care about whether it came from DT or ACPI, but like I said, that's going to be tricky.

Quoted 2 lines

I don't honestly think that the "ask vendors to ship their systems with correct ACPI tables" approach will take us anywhere.

It's worked well enough on x86. If hardware vendors don't actually test that their hardware is able to boot the OS it's intended to run then there's very little we can do about that - and the worst case outcome is that people just ignore the shipped ACPI and use FDT.

It had been my hope at the start of this project to open the creation of SSDTs up to inventors and hackers who want to create Lures for the MinnowBoard in such a way that they could write these SSDTs and load them from a file at boot time, modify, rebuild, iterate, etc. When/if the Lure goes to production, the SSDT could either be stored on an EEPROM, or for very low volume boards, possibly just shipped as a binary to be loaded (with source available of course).

It appears that Matthew, at least, would prefer this latter scenario just used DT instead. However, that seems to leave a gap in the transition to incorporating the table into the board firmware should a derivative product be made. e.g. no good way to prototype with ACPI. It also seems to have all the same problems raised regarding mixing ACPI and DT on the same system.

Quoted 7 lines · Darren Hart

It had been my hope at the start of this project to open the creation of SSDTs up to inventors and hackers who want to create Lures for the MinnowBoard in such a way that they could write these SSDTs and load them from a file at boot time, modify, rebuild, iterate, etc. When/if the Lure goes to production, the SSDT could either be stored on an EEPROM, or for very low volume boards, possibly just shipped as a binary to be loaded (with source available of course).

There's no fundamental problem with doing this, especially on UEFI systems. As long as you know the host ACPI code, it's trivial to merge an SSDT in from a UEFI option ROM.

Quoted 6 lines

It appears that Matthew, at least, would prefer this latter scenario just used DT instead. However, that seems to leave a gap in the transition to incorporating the table into the board firmware should a derivative product be made. e.g. no good way to prototype with ACPI. It also seems to have all the same problems raised regarding mixing ACPI and DT on the same system.

I've no problem with additional hardware shipping with ACPI support - my position was more that if a vendor ships a system with ACPI that fails to describe the integrated hardware (or does so incorrectly), it's probably easier to replace it with DT than a fixed ACPI table. Still, if people *do* want to replace shipped ACPI tables, it's probably preferable to do that at the bootloader level than the kernel level.

Quoted 21 lines · Matthew Garrett

Quoted 7 lines · Darren Hart

It had been my hope at the start of this project to open the creation of SSDTs up to inventors and hackers who want to create Lures for the MinnowBoard in such a way that they could write these SSDTs and load them from a file at boot time, modify, rebuild, iterate, etc. When/if the Lure goes to production, the SSDT could either be stored on an EEPROM, or for very low volume boards, possibly just shipped as a binary to be loaded (with source available of course).

There's no fundamental problem with doing this, especially on UEFI systems. As long as you know the host ACPI code, it's trivial to merge an SSDT in from a UEFI option ROM.

Quoted 6 lines

It appears that Matthew, at least, would prefer this latter scenario just used DT instead. However, that seems to leave a gap in the transition to incorporating the table into the board firmware should a derivative product be made. e.g. no good way to prototype with ACPI. It also seems to have all the same problems raised regarding mixing ACPI and DT on the same system.

Quoted 7 lines

I've no problem with additional hardware shipping with ACPI support - my position was more that if a vendor ships a system with ACPI that fails to describe the integrated hardware (or does so incorrectly), it's probably easier to replace it with DT than a fixed ACPI table. Still, if people *do* want to replace shipped ACPI tables, it's probably preferable to do that at the bootloader level than the kernel level.

OK. Thanks for elaborating.

It seems to me that in order to fully support this, we are back to the problem of how do we provide arbitrary configuration data via ACPI (the DSM being the only current means, but there is no standard there). Is that still the hard problem we are looking to solve as a group?

Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

Quoted 1 line · Guenter Roeck

Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

I think expressing FDT in ACPI is feasible, I'm just not sure it's desirable. We'd still end up with duplicate information and no mechanism for drivers to handle both.

Quoted 4 lines · Matthew Garrett

Quoted 1 line · Guenter Roeck

Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

Quoted 4 lines

I think expressing FDT in ACPI is feasible, I'm just not sure it's desirable. We'd still end up with duplicate information and no mechanism for drivers to handle both.

Not sure I understand what you are saying. My understanding of "augment" would be that there is ACPI information, and there is a separate FDT (or an FDT overlay) providing additional information. There should be no duplicate information in this model.

Quoted 9 lines · Guenter Roeck

Quoted 8 lines · Matthew Garrett

Quoted 1 line · Guenter Roeck

Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

I think expressing FDT in ACPI is feasible, I'm just not sure it's desirable. We'd still end up with duplicate information and no mechanism for drivers to handle both.

Quoted 4 lines

Not sure I understand what you are saying. My understanding of "augment" would be that there is ACPI information, and there is a separate FDT (or an FDT overlay) providing additional information. There should be no duplicate information in this model.

What happens when you have an ACPI device that contains an interrupt in _CRS and contains a different interrupt in an embedded FDT block?

Question is: Does this work _today_ with any existing driver, where one interrupt is served through ACPI and another as 'standard' Linux interrupt ? If yes, it must be working, and using fdt to describe the interrupt mapping for the non-ACPI interrupt should not make a difference. If no, the problem does not really have anything to do with fdt.

Quoted 6 lines · Guenter Roeck

Question is: Does this work _today_ with any existing driver, where one interrupt is served through ACPI and another as 'standard' Linux interrupt ? If yes, it must be working, and using fdt to describe the interrupt mapping for the non-ACPI interrupt should not make a difference. If no, the problem does not really have anything to do with fdt.

There's no such thing as an ACPI interrupt, it's just a data source in the same way that PnP used to be. _CRS refers to platform interrupts.

"What happens when you have an ACPI device that contains an interrupt in
_CRS and contains a different interrupt in an embedded FDT block?"

Does the situation occur today, ie does it ever happen that one interrupt for a device is specified (if that is the correct term) in _CRS and another by some other means ?

Quoted 6 lines · Guenter Roeck

"What happens when you have an ACPI device that contains an interrupt in
_CRS and contains a different interrupt in an embedded FDT block?"

Does the situation occur today, ie does it ever happen that one interrupt for a device is specified (if that is the correct term) in _CRS and another by some other means ?

The only case I can think of is PCI, where we ignored the ACPI-provided resources until fairly recently. That was a somewhat reasonable thing to do, since the hardware still had to support pre-ACPI operating systems and so the non-ACPI information sources were typically correct.

Other than that, I think we always trust the ACPI data.

Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

If not, the key question for me is how to implement it, and how to handle all its little problems.

If yes, the key question for me is how to handle all the drivers which assume fdt-style properties, and how to express all that information in ACPI in a way which does not require a substantial driver rewrite (and, as you point out, how that data would be described in ACPI consistently across multiple vendors).

Quoted 1 line · Guenter Roeck

Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

I don't think anyone really knows. For example: how to specify a few config options through a FDT augmented ACPI system is trivial. Passing system-wide resources such as clocks, regulators, pin control handles, GPIOs, interrupts and DMA channels is a criss-cross operation and nobody knows if that will work because nobody tried to hash out the details of.

Quoted 2 lines

If not, the key question for me is how to implement it, and how to handle all its little problems.

It seems like we are in the "teenagers talking about sex" situation, everybody is talking about it but nobody is really doing it. Which makes it all pretty theoretical.

Quoted 5 lines

If yes, the key question for me is how to handle all the drivers which assume fdt-style properties, and how to express all that information in ACPI in a way which does not require a substantial driver rewrite (and, as you point out, how that data would be described in ACPI consistently across multiple vendors).

For GPIO we have this:

drivers/gpio/gpiolib-of.c
drivers/gpio/gpiolib-acpi.c

So one thing is clear: for this resource we're going to have two implementations.