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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.12.2023 14:15, Jan Beulich wrote:
> 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?

Oh, no - what Linux logs are still the ACPI values (level: 0, edge: 1).
What Xen logs are the IO-APIC values (level: 1, edge: 0). So all consistent
here, and presumably indeed only a single call occurring.

Jan