回复: [PATCH v6 01/24] genirq/devres: Add devm_request_threaded_irq_probe() and devm_request_irq_probe()

回复: [PATCH v6 01/24] genirq/devres: Add devm_request_threaded_irq_probe() and devm_request_irq_probe()

[潘闯]

Hi tglx and Miquèl,

On Tue, Jun 24 2025 at 16:13, tglx wrote:
> As you cited correctly I said back then:
> 
>   "So there is certainly an argument to be made that this particular
>   function should print a well formatted and informative error
>   message."
>
> This particular function is: devm_request_threaded_irq().
>
> IOW, I did not ask you should go an create a new one, right?

Thank you all for your valuable feedback and guidance regarding the recent patch. I am a bit confused because, in the v1 version, no new function was added. However, in v2, tglx suggested introducing a new function[1]. Now, I would greatly appreciate your advice on the appropriate approach:

  Should we directly integrate dev_err_probe() inside devm_request_threaded_irq()?
  Or should we create a wrapper function instead?

Thank you for your guidance.

[1]https://lore.kernel.org/all/87h6qpyzkd.ffs@tglx/

Thanks,

        PanChuang

Re: 回复: [PATCH v6 01/24] genirq/devres: Add devm_request_threaded_irq_probe() and devm_request_irq_probe()

[Thomas Gleixner]

On Sat, Jul 19 2025 at 23:08, Thomas Gleixner wrote:
> On Wed, Jul 09 2025 at 17:13, panchuang@vivo.com wrote:
>> Hi tglx and Miquèl, Just a gentle ping on this patchset. I understand 
>> you're likely busy with many other tasks, but any feedback or guidance 
>> on how to proceed would be greatly appreciated. As discussed in the 
>> previous thread, there was some uncertainty about whether we should 
>> directly integrate dev_err_probe() into devm_request_threaded_irq(), or 
>> if it's better to create a wrapper function. Thanks for your time! 
>> Thanks, Panchuang

For simplicity sake just rename the existing functions
devm_request_threaded_irq() and devm_request_any_context_irq() to
__devm_request_threaded_irq() and __devm_request_any_context_irq().

Then create new functions for the API, which

   - invoke the underscore variants
   - and on error invoke dev_err_probe() similar to what I suggested in
     my reply in this thread.

In the rare case of failure, this will print error messages for the
affected drivers both in the core and at the callsite, but that's not
the end of the world.

Then go and remove the random printks from the drivers, once the core
change has hit upstream.

Thanks,

        tglx