From: Thomas Gleixner <tglx@linutronix.de>
To: Zijun Hu <zijun_hu@icloud.com>
Cc: linux-kernel@vger.kernel.org, Zijun Hu <quic_zijuhu@quicinc.com>
Subject: Re: [PATCH] genirq/devres: Simplify API devm_free_irq() implementation
Date: Fri, 18 Oct 2024 10:57:43 +0200 [thread overview]
Message-ID: <87sest94ag.ffs@tglx> (raw)
In-Reply-To: <07f223e0-9a42-4637-a081-a057025e216f@icloud.com>
On Fri, Oct 18 2024 at 06:36, Zijun Hu wrote:
> On 2024/10/18 04:33, Thomas Gleixner wrote:
>>> It is simpler if devm_free_irq() is undoing what any devm_request_irq()
>>> variant did, otherwise, it can avoid wrong and undesired free_irq().
>>
>> This is confusing at best. What's the wrong an undesired free_irq()?
>>
> for current devm_free_irq(..., irq_A, ...):
> it is undesired if irq_A is requested by request_irq().
> it is wrong and dangerous if irq_A was never requested.
There is nothing dangerous about it if it was never requested.
free_irq() won't find a irq action which matches devid and do nothing
than emitting a warning.
But that's not relevant either because there is no matching devres entry
when the interrupt was not requested via devres_request_irq(), so
free_irq() will not be reached because devres_destroy() will return
-ENOENT.
So all this change does is changing the logic from:
devres_free_irq()
if (devres_destroy())
return;
free_irq();
to
devres_release()
where devres_release() does the same thing as the above, i.e. it looks
up the devres for a match and if found, it removes and frees the devres
pointer and invokes the release function which in turn invokes
free_irq().
So in terms of code logic this is exactly the same and does neither
avoid or prevent anything.
All it does is sparing a single line of code.
Thanks,
tglx
next prev parent reply other threads:[~2024-10-18 8:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 15:16 [PATCH] genirq/devres: Simplify API devm_free_irq() implementation Zijun Hu
2024-10-17 20:33 ` Thomas Gleixner
2024-10-17 22:36 ` Zijun Hu
2024-10-18 8:57 ` Thomas Gleixner [this message]
2024-10-18 9:28 ` quic_zijuhu
2024-10-18 10:58 ` Thomas Gleixner
2024-10-18 11:08 ` Zijun Hu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sest94ag.ffs@tglx \
--to=tglx@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_zijuhu@quicinc.com \
--cc=zijun_hu@icloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.