Problems interpreting INT3472 GPIO DSM GPIO-pin-number when not using LJCA or iVSC

Some designs (1) use I2C busses and GPIOs coming directly from the main CPU / SoC, instead of using an IO-expander like the LJCA chip or having the GPIOs connected to a video-processing chip like the iVSC.

On these designs the INT3472 driver currently logs e.g. the following warnings:

[ 8.902024] int3472-discrete INT3472:02: reset \_SB.GPI0 pin number mismatch _DSM 101 resource 357

and it looks like things are not working since the ov2740 sensor does not respond when probed:

[ 9.115398] ov2740 i2c-INT3474:02: error -EREMOTEIO: failed to find sensor

Can someone from Intel provide information on how the GPIO-pin-number (bits 8-15) of the GPIO DSM on the INT3472 ACPI devices:

```
static const guid_t int3472_gpio_guid =
GUID_INIT(0x79234640, 0x9e10, 0x4fea, 0xa5, 0xc1, 0xb5, 0xaa, 0x8b, 0x19, 0x75, 0x6f);
```

should be interpreted / mapped to a GPIO controller + pin number on that controller ?

ATM the drivers/platform/x86/intel/int3472/discrete.c simply takes the nth ACPI GPIO resource from (CRS) on the INT3472 ACPI device for the nth GPIO returned by the DSM but I would like to be able to double check that that is correct.

1) For example tablets where the mainboard is directly behind the display rather then in the keyboard half of a clamshell design. One example of this is the TerraPAD 1263v2 with an Intel i5-1230U chip.