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

["Sébastien Chaumat" <euidzero@gmail.com>]

Le lun. 18 déc. 2023 à 18:04, Sébastien Chaumat <euidzero@gmail.com> a écrit :
>
>
>
> Le lun. 18 déc. 2023, 17:44, Jan Beulich <jbeulich@suse.com> a écrit :
>>
>> On 18.12.2023 17:21, Sébastien Chaumat wrote:
>> >>>>> On 05.12.2023 21:31, Sébastien Chaumat wrote:
>> >>> 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
>> >
>> > So triggering is flipped from 1 to 0 (cannot find the definition for
>> > those values).
>> > Could this be the culprit ?
>>
>> Possibly. Since it would be the kernel to invoke PHYSDEVOP_setup_gsi, it
>> looks as if the kernel was confused about which trigger mode to use. Have
>> you figured from where the kernel takes the two different values?
>>
side note : dom0 is PV.