As far as I can tell, the expectation of switching further TAD implementation HW accesses to go through an OS-supplied SPI or I2C driver is entirely fanciful. What am I missing?

[andreiw]

I cannot find any mention in the ACPI documentation that an OS can substitute the functions that AML code uses to access a generic serial bus.

[andreiw]

The OS has an AML interpreter that runs the AML byte code. So every HW access made by an AML method is actually done by the OS. These accesses go through what is known as an "operation region". Regardless of how the AML code accesses the device, AML always goes through an Operation Region. It's the OS AML interpreter that handles any OpReg access from AML code. Examples of "default" ones always available are MMIO, PCI Config Space. Special things like SPI/I2C, Embedded Controller, etc are available only if the OS has a matching driver - e.g. I2C-backed OpRegs won't work if there is no I2C host drivers. The mechanism how a device driver registers itself as an OpReg handler is obviously OS specific. You won't find it in the spec, because it is an implementation detail for the AML interpreter. For Linux, here's the first link I saw, when I googled "Linux acpica operation region" - https://lore.kernel.org/lkml/20140422112121.GE30677@intel.com/T/. ACPI-CA is probably a good place to look. It may even have some docs...

It's pretty typical for AML code to access device registers or firmware data exchange buffers via OpRegs. It's core functionality.

The OS runs _REG control methods to inform AML code of a change in the availability of an operation region. The first argument (arg0) is the operation region address space ID, and the second argument (arg1) is 1 when the operation region becomes available and 0 when it goes away.

In the case of a TAD implementation, say, on an I2C bus, the I2C OpReg will be made available when the I2C stack is loaded if there's a i2c controller driver. In that case the REGC variable will be set and the AML methods in the TAD device will use it. Otherwise, the TAD AML methods will know to use some other mechanism (MMIO OpReg, RISCV FFH when that's defined to handle ecalls, etc). So it's not that the OS is substituting, more like correctly informing the AML what access methods exist - but the AML of course needs to be written to deal with the sad fact of missing the clean I2C accesses and having to cobble something together. That last part isn't that fanciful - I've seen some hand-rolled horrors that bit-banged RTC chips over MMIO in the Arm world (and IMO this is exactly why we need FFH to allow ecalls from ACPI!).

The AML would like something like this... omitting everything that's not really interesting to this example.

Scope (\_SB.I2C)
{
	Name (REGC, Ones)
	Method (_REG, 2)
	{
		If (Arg0 == 3)
		{
			REGC = Arg1
		}
	}
	Name (SDB0, ResourceTemplate()
	{
	I2CSerialBusV2(0x4a,,100000,,"
	\\_SB.I2C",,,,,RawDataBuffer(){1,2,3,4,5,6})
	})
	OperationRegion(TOP1, GenericSerialBus, 0x00, 0x100)
	Field (TOP1, BufferAcc, NoLock, Preserve)
	{
		Connection (I2CSerialBusV2 (0x5a,,100000,,"\\_SB.I2C",,,,,RawDataBuffer (){1,6})),
		AccessAs(BufferAcc, AttribByte),
		FLD0, 8, // Virtual register at command value 0.
		FLD1, 8, // Virtual register at command value 1.
		FLD2, 8 // Virtual register at command value 2.
	}
	...
}

Scope (\_SB.TAD)
{
	Method (_STP, 2) {
		...
		If (\_SB.I2C.REGC) {
			// Use access via the GenericSerialBus operation region.
		} else {
			// Do painful IO via MMIO OpReg
		}
		...
	}
}