Le 2024-06-06 23:32, Dmitry Torokhov a écrit :
On Wed, Jun 05, 2024 at 03:48:20PM +0200, Kamel BOUHARA wrote:[...] > > > + > > > + error = devm_request_threaded_irq(dev, client->irq, NULL, > > > + axiom_irq, IRQF_ONESHOT, dev_name(dev), ts); > > > + if (error) { > > > + dev_info(dev, "Request irq failed, falling back to polling mode"); > > > > I do not think you should fall back to polling mode if you fail to get > > interrupt. If it was not specified (client->irq) then I can see that > > we > > might want to fall back, but if the system configured for using > > interrupt and you can not get it you should bail out. > > > > Yes, clear, the polling mode can be decorrelated to the irq not provided > case. Just to make sure I understood, is this what you propose ? if (client->irq) { error = devm_request_threaded_irq(...) if (error) { dev_warn(dev, "failed to request IRQ\n"); client->irq = 0; } } if(!client->irq) { // setup polling stuff ... }No, if you fail to acquire interrupt that was described in ACPI/DT it should be treated as an error, like this: if (client->irq) { error = devm_request_threaded_irq(...) if (error) return dev_err_probe(...); } else { .. set up polling .. } This also makes sure that if interrupt controller is not ready and requests probe deferral we will not end up with device in polling mode.
OK, thanks for the clarification, this is fixed in v14. Greetings, -- Kamel Bouhara, Bootlin Embedded Linux and kernel engineering https://bootlin.com
