Re: [BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.12.2023 12:09, Sébastien Chaumat wrote:
> Le lun. 11 déc. 2023 à 10:18, Sébastien Chaumat <euidzero@xxxxxxxxx> a écrit :
>>
>>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
>>>>> [    2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
>>>>
>>>> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
>>>> ioapic-edge and IRQ9 to ioapic-level ?
>>>>
>>>> IR-IO-APIC    7-fasteoi   pinctrl_amd
>>>> IR-IO-APIC    9-fasteoi   acpi
>>>>
>>>> to (xen 4.18.0)
>>>>
>>>> xen-pirq     -ioapic-edge  pinctrl_amd
>>>> xen-pirq     -ioapic-level  acpi
>>>>
>>>> ?
> 
> This look similar to
> https://yhbt.net/lore/all/20201006044941.fdjsp346kc5thyzy@Rk/t/
> 
> This issue seems that IRQ 7 (the GPIO controller) is natively fasteoi
> (so level type) while in xen it  is mapped to oapic-edge  instead of
> oapic-level
> as the SSDT indicates :
> 
>  Device (GPIO)
> 
>      {
>          Name (_HID, "AMDI0030")  // _HID: Hardware ID
>          Name (_CID, "AMDI0030")  // _CID: Compatible ID
>          Name (_UID, Zero)  // _UID: Unique ID
>          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
>          {
>              Name (RBUF, ResourceTemplate ()
>              {
>                  Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
>                  {
>                      0x00000007,
>            }
> Any idea why ?

Information coming from AML is required to be handed down by Dom0 to Xen.
May want checking that (a) Dom0 properly does so and (b) Xen doesn't screw
up in consuming that data. See PHYSDEVOP_setup_gsi. I wonder if this is
specific to it being IRQ7 which GPIO uses, as at the (master) PIC IRQ7 is
also the spurious vector. You may want to retry with the tip of the 4.17
branch (soon to become 4.17.3) - while it doesn't look very likely to me
that recent backports there were related, it may still be that they make
a difference.

Jan