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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.12.2023 17:21, Sébastien Chaumat wrote:
>>>>> 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.
>>
> 
> testing with 4.17.3:
> 
> Adding some printk in PHYSDEVOP_setup_gsi, I  see (in xl dmesg)  that
> (XEN) PHYSDEVOP_setup_gsi setup_gsi : gsi: 7 triggering: 1 polarity: 1
> 
> but later on in dmesg I see :
> [    1.747958] xen: registering gsi 7 triggering 0 polarity 1

Linux has exactly one place where this message is logged from, and that's
ahead of it calling PHYSDEVOP_setup_gsi. Since you said "later", can you
confirm that actually you see two instances of the Xen message and two
instances of the Linux one (each of them with respectively matching
trigger and polarity values)? Or are we indeed observing what would look
to be corruption of a hypercall argument?

If there were two calls, it would be important to realize that Xen will
respect only the first one.

Jan