[PATCH] irq: fix the interrupt trigger type override issue
Thomas Gleixner
tglx at linutronix.de
Mon Sep 2 02:51:33 PDT 2024
Richard!
On Mon, Sep 02 2024 at 16:42, richard clark wrote:
> On Mon, Sep 2, 2024 at 3:34 PM Thomas Gleixner <tglx at linutronix.de> wrote:
>> 1) insmod()
>> irq_create_fwspec_mapping(fwspec)
>> irq_domain_translate(fwspec, ... &type); <- Sets type to the FW value
>>
>> virq = irq_find_mapping(domain, hwirq);
>> if (virq) {
>> // Path not taken
>> }
>>
>> // Map interrupt
>> ...
>>
>> irqd_set_trigger_type(..., type);
>>
>> 2) rmmod()
>> tears down mapping
>>
> This just tears down the action allocated and installed by
> request_irq(...), but does not teardown the irq's node inserted in the
> revmap_tree.
So what creates the mapping? If the driver creates it then why doesn't
it unmap it when it exits?
>> 3) insmod()
>>
>> Should be exactly the same as #1 because the previous mapping was
>> torn down by rmmod()
>>
> Not the same exactly, the {irq, irq_data} will still be in the
> revmap_tree, so it will enter another path in this case:
That's exactly the question. Why does the mapping persist?
>> So how exactly does that happen what you describe?
>>
> The logic is if the trigger type specified by request_irq(...) is not
> consistent with the firmware one, the request_irq will override the
> FW. We need to keep this logic the same as when we insmod the same
> kmod next time -- override the FW's too instead of returning a
> mismatch type error.
I can see how that can happen, but what's missing is the information why
this mapping persists and why it's tried to be set up again.
Thanks,
tglx
More information about the linux-arm-kernel
mailing list