[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Sébastien Chaumat <euidzero@xxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 21 Dec 2023 13:40:19 +0100
  • Autocrypt: addr=jbeulich@xxxxxxxx; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 21 Dec 2023 12:40:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.