I do not think that this change makes sense, and probably would just drop it.

First, FFH cannot be treated generically in any way. Even on x86, FFH *does not* equate MSR access (e.g., see Intel spec for _CST).

Second, FFH is not a mode of access on x86 (nor any other platform). There are only I/O and MEM. We could probably contend that using MSR is a mode of its own, but again, that is not FFH.

Third, logically a resource manager for FFH does not make any sense, at least for the simple reason that the same values can be aliases and mean something different depending on the context (e.g., see _PCT and _PTC in the Intel spec, both of which use a FFH address of 0). Also, even when some FFH GAS references a MSR, there's nothing preventing that MSR from being reused in different fields when that makes sense.

So, the only generic thing we can do for FFH is to enable parsing them and returning their content, possibly applying Intel's interpretation (Register_Bit_Width => Vendor Code, Register_Bit_Offset => Class Code, Access Size => Arg1, Address => Arg0), provided AMD obeys it (there's no AMD doc, and I haven't read Linux code to try to reverse-engineer it). This is basically what the existing acpi_PkgFFH_IntelCpu() function in acpi_package.c does, but it also extracts the GAS from a package; just the FFH interpretation should be factored out in its own function (and nowhere acpi_bus_alloc_gas() should be called).

I'll try to indicate what to do instead on other revisions in this stack.