Xen project Mailing List

I spotted the following warning for IRQ7 (along with IRQ6 and 10)

[ 0.686073] fedora kernel: __irq_set_trigger: genirq: No set_type function for IRQ 7 (IR-IO-APIC)

This comes from kernel/irq/manage.c

int __irq_set_trigger(struct irq_desc *desc, unsigned long flags)
{
    struct irq_chip *chip = desc->irq_data.chip;
    int ret, unmask = 0;

    if (!chip || !chip->irq_set_type) {
        /*
         * IRQF_TRIGGER_* but the PIC does not support multiple
         * flow-types?
         */
        pr_debug("No set_type function for IRQ %d (%s)\n",
             irq_desc_get_irq(desc),
             chip ? (chip->name ? : "unknown") : "unknown");
        return 0;
    }

Could this have a role in the IRQ misconfiguration by xen ?

Le lun. 22 janv. 2024 à 21:59, Mario Limonciello <mario.limonciello@xxxxxxx> a écrit :

On 1/22/2024 11:06, Sébastien Chaumat wrote:
>
>
> Le mer. 17 janv. 2024 à 03:20, Mario Limonciello
> <mario.limonciello@xxxxxxx <mailto:mario.limonciello@xxxxxxx>> a écrit :
>
> On 1/16/2024 10:18, Jan Beulich wrote:
> > On 16.01.2024 16:52, Sébastien Chaumat wrote:
> >> Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat
> <euidzero@xxxxxxxxx <mailto:euidzero@xxxxxxxxx>> a
> >> écrit :
> >>
> >>>
> >>> output of gpioinfo
> >>>>
> >>>> kernel alone :
> >>>>
> >>>> line 5: unnamed input active-low
> consumer=interrupt
> >>>> line 84: unnamed input active-low
> consumer=interrupt
> >>>>
> >>>> xen:
> >>>>
> >>>> line 5: unnamed input active-low
> >>>> line 84: unnamed input active-low
> >>>>
> >>>> xen with skipping IRQ7 double init :
> >>>>
> >>>> line 5: unnamed input active-low
> consumer=interrupt
> >>>> line 84: unnamed input active-low
> >>>>
> >>>>
> >>>> So definitely progressing.
> >>>>
> >>>
> >>> Checking /sys/kernel/irq/7
> >>>
> >>> kernel alone :
> >>> actions: pinctrl_amd
> >>> chip_name: IR-IO-APIC
> >>> hwirq: 7
> >>> name: fasteoi
> >>> per_cpu_count: 0,0,0,0,0,20,0,0,0,0,0,0,0,0,0,0
> >>> type: level
> >>> wakeup: enabled
> >>>
> >>> xen skipping IRQ7 double init :
> >>>
> >>> actions: pinctrl_amd
> >>> chip_name: xen-pirq
> >>> hwirq:
> >>> name: ioapic-level
> >>> per_cpu_count: 0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0
> >>> type: edge
> >>> wakeup: disabled
> >>>
> >>> So the skip of IRQ7 in pci_xen_initial_domain() sets the
> correct handler
> >>> (IIUC xen uses the ioapic-level and handles the eoi
> separately), but not
> >>> the correct type (still edge).
> >>> I guess this may explains the results above.
> >>>
> >>>
> >> Mario (in CC) patched the pinctrl_amd to flush pending
> interrupt before
> >> starting the driver for the GPIO.
> >>
> >> This helped in the sense of there's no more pending interrupt
> on IRQ7
> >> (whatever the handler is, level or edge) but then the touchpad
> is not
> >> detected by i2c-hid.
> >>
> >> Is there any work in progress related to the incorrect IRQ
> configuration ?
> >
> > I'm not aware of any. As per my recollection it's still not entirely
> > clear where in the kernel things go astray. And to be honest I don't
> > feel comfortable trying to half-blindly address this, e.g. by trying
> > to circumvent / defer the early setting up of the low 16 IRQs.
> >
> > Jan
>
> Shot in the dark - but could this be a problem where PCAT_COMPAT from
> the MADT is being ignored causing PIC not to be setup properly in the
> Xen case?
>
> See https://lore.kernel.org/all/875y2u5s8g.ffs@tglx/
> <https://lore.kernel.org/all/875y2u5s8g.ffs@tglx/> for some context.
>
> At least we know that no MADT override is found by xen for INT7 as no
> INT_SRC_OVR message is printed.
>
> Do we expect one @Mario Limonciello <mailto:mario.limonciello@xxxxxxx> ?

No; the INT_SRV_OVR you'll see on Framework 13 AMD is on IRQ 2 and IRQ 9.

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