On Sun, Apr 6, 2025 at 6:18 PM Thomas Gleixner tglx@linutronix.de wrote:
On Sun, Apr 06 2025 at 17:46, Huacai Chen wrote:
On Thu, Apr 3, 2025 at 11:48 PM Thomas Gleixner tglx@linutronix.de wrote:
But it won't trigger on both. So no, you cannot claim that this fixes anything.
Yes, it won't trigger on both (not perfect), but it allows drivers that request "both" work (better than fail to request), and there are
By some definition of 'work'. There is probably a good technical reason why those drivers expect EDGE_BOTH to work correctly and otherwise fail to load.
The real problem we encounter is the MMC driver. In drivers/mmc/core/slot-gpio.c there is devm_request_threaded_irq(host->parent, irq, NULL, ctx->cd_gpio_isr, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING | IRQF_ONESHOT, ctx->cd_label, host);
"IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING" is an alias of "IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING", and "IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING" is "IRQ_TYPE_EDGE_BOTH".
Except MMC, "grep IRQ_TYPE_EDGE_BOTH drivers" can give some more examples.
Huacai
You completely fail to explain, why this hack actually 'works' and what the implications are for such drivers.
other irqchip drivers that do similar things.
Justifying bogosity with already existing bogosity is not a technical argument.
Thanks,
tglx