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

[Jan Beulich <jbeulich@suse.com>]

On 20.12.2023 17:34, Sébastien Chaumat wrote:
> Here are the patches I made to xen and linux kernel
> Plus dmesg (bare metal,xen) and "xl dmesg"

So the problem looks to be that pci_xen_initial_domain() results in
permanent setup of IRQ7, when there only "static" ACPI tables (in
particular source overrides in MADT) are consulted. The necessary
settings, however, are known only after _CRS for the device was
evaluated (and possibly _PRS followed by invocation of _SRS). All of
this happens before xen_register_gsi() is called. But that function's
call to xen_register_pirq() is short-circuited by the very first if()
in xen_register_pirq() when there was an earlier invocation. Hence
the (wrong) "edge" binding remains in place, as was established by
the earlier call here.

Jürgen, there's an interesting comment in xen_bind_pirq_gsi_to_irq(),
right before invoking irq_set_chip_and_handler_name(). Despite what
the comment says (according to my reading), the fasteoi one is _not_
used in all cases. Assuming there's a reason for this, it's not clear
to me whether updating the handler later on is a valid thing to do.
__irq_set_handler() being even an exported symbol suggests that might
be an option to use here. Then again merely updating the handler may
not be sufficient, seeing there are also e.g. IRQD_TRIGGER_MASK and
IRQD_LEVEL.

Sébastien, to prove the (still pretty weak) theory that the change in
handler is all that's needed to make things work in your case, could
you fiddle with pci_xen_initial_domain() to have it skip IRQ7? (That
of course won't be a proper solution, but ought to be okay for your
system.) The main weakness of the theory is that IRQ7 really isn't
very special in this regard - other PCI IRQs routed to the low 16
IO-APIC pins ought to have similar issues (from the log, on your
system this would be at least IRQ6 and IRQ10, except that they happen
to be edge/low, so fitting the ISA defaults); only IRQ16 and up would
work okay.

Furthermore it might be interesting to know whether ELCR would give us
any hint in this case. Sadly depending on where you look,
applicability of this pair of registers (I/O ports 0x4d0 and 0x4d1)
to other than EISA systems is claimed true or false. Could you perhaps
make Xen simply log the values read from those two ports, by e.g.
inserting

    printk("ELCR: %02x, %02x\n", inb(0x4d0), inb(0x4d1));

in, say, setup_dump_irqs()?

Jürgen, looking at pci_xen_initial_domain(), what's the purpose of
the loop in the final if()? Can this ever do anything useful when
the earlier comment suggests nr_legacy_irqs() is zero anyway? Or is
the comment simply inaccurate in not covering the "no IO-APICs" case?

Jan