From: "Marek Behún" <kabel@kernel.org>
To: Matti Vaittinen <mazziesaccount@gmail.com>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
"Gregory CLEMENT" <gregory.clement@bootlin.com>,
soc@kernel.org, arm@kernel.org,
"Hans de Goede" <hdegoede@redhat.com>,
"Horia Geantă" <horia.geanta@nxp.com>,
"Pankaj Gupta" <pankaj.gupta@nxp.com>,
"Gaurav Jain" <gaurav.jain@nxp.com>,
linux-crypto@vger.kernel.org,
"Herbert Xu" <herbert@gondor.apana.org.au>
Subject: Re: [PATCH v5 06/11] devm-helpers: Add resource managed version of irq_create_mapping()
Date: Mon, 25 Mar 2024 10:57:42 +0100 [thread overview]
Message-ID: <20240325105742.0e1c8906@dellmb> (raw)
In-Reply-To: <dd4c655f-39c4-47c1-b5fb-4d6fc94cc430@gmail.com>
On Mon, 25 Mar 2024 11:40:20 +0200
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> On 3/23/24 18:43, Marek Behún wrote:
> > Add resource managed version of irq_create_mapping(), to help drivers
> > automatically dispose a linux irq mapping when driver is detached.
> >
> > The new function devm_irq_create_mapping() is not yet used, but the
> > action function can be used in the FSL CAAM driver.
> >
> > Signed-off-by: Marek Behún <kabel@kernel.org>
> > ---
> > drivers/crypto/caam/jr.c | 8 ++----
> > include/linux/devm-helpers.h | 54 ++++++++++++++++++++++++++++++++++++
> > 2 files changed, 56 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
> > index 26eba7de3fb0..ad0295b055f8 100644
> > --- a/drivers/crypto/caam/jr.c
> > +++ b/drivers/crypto/caam/jr.c
> > @@ -7,6 +7,7 @@
> > * Copyright 2019, 2023 NXP
> > */
> >
> > +#include <linux/devm-helpers.h>
> > #include <linux/of_irq.h>
> > #include <linux/of_address.h>
> > #include <linux/platform_device.h>
> > @@ -576,11 +577,6 @@ static int caam_jr_init(struct device *dev)
> > return error;
> > }
> >
> > -static void caam_jr_irq_dispose_mapping(void *data)
> > -{
> > - irq_dispose_mapping((unsigned long)data);
> > -}
> > -
> > /*
> > * Probe routine for each detected JobR subsystem.
> > */
> > @@ -656,7 +652,7 @@ static int caam_jr_probe(struct platform_device *pdev)
> > return -EINVAL;
> > }
> >
> > - error = devm_add_action_or_reset(jrdev, caam_jr_irq_dispose_mapping,
> > + error = devm_add_action_or_reset(jrdev, devm_irq_mapping_drop,
> > (void *)(unsigned long)jrpriv->irq);
> > if (error)
> > return error;
> > diff --git a/include/linux/devm-helpers.h b/include/linux/devm-helpers.h
> > index 74891802200d..3805551fd433 100644
> > --- a/include/linux/devm-helpers.h
> > +++ b/include/linux/devm-helpers.h
> > @@ -24,6 +24,8 @@
> > */
> >
> > #include <linux/device.h>
> > +#include <linux/kconfig.h>
> > +#include <linux/irqdomain.h>
> > #include <linux/workqueue.h>
>
> My confidence level is not terribly high today, so I am likely to accept
> just about any counter arguments :) But ... More I think of this whole
> header, less convinced I am that this (the header) is a great idea. I
> wonder who has authored a concept like this... :rolleyes:
>
> Pulling punch of unrelated APIs (or, unrelated except the devm-usage) in
> one header has potential to be including a lot of unneeded stuff to the
> users. I am under impression this can be bad for example for the build
> times.
>
> I think that ideally the devm-APIs should live close to their non-devm
> counterparts, and this header should be just used as a last resort, when
> all the other options fail :) May I assume all other options have failed
> for the IRQ stuff?
>
> Well, I will leave the big picture to the bigger minds. When just
> looking at the important things like the function names and coding style
> - this change looks Ok to me ;)
If the authors of devm-helpers or someone else decide it should not
exist (due for example of long build times), I am OK with that.
But currently this seems to me to be the proper place to put this into.
Marek
next prev parent reply other threads:[~2024-03-25 9:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-23 16:43 [PATCH v5 00/11] Turris Omnia MCU driver Marek Behún
2024-03-23 16:43 ` [PATCH v5 06/11] devm-helpers: Add resource managed version of irq_create_mapping() Marek Behún
2024-03-25 9:40 ` Matti Vaittinen
2024-03-25 9:57 ` Marek Behún [this message]
2024-03-26 9:00 ` Dan Carpenter
2024-03-27 9:34 ` Marek Behún
2024-03-27 11:39 ` Dan Carpenter
2024-03-23 16:43 ` [PATCH v5 07/11] platform: cznic: turris-omnia-mcu: Add support for MCU provided TRNG Marek Behún
2024-03-23 16:43 ` [PATCH v5 08/11] devm-helpers: Add resource managed version of debugfs directory create function Marek Behún
2024-03-23 17:21 ` Guenter Roeck
2024-03-23 16:43 ` [PATCH v5 09/11] platform: cznic: turris-omnia-mcu: Add support for digital message signing via debugfs Marek Behún
[not found] ` <20240323164359.21642-9-kabel__6885.49310886941$1711212291$gmane$org@kernel.org>
2024-03-23 21:10 ` [PATCH v5 08/11] devm-helpers: Add resource managed version of debugfs directory create function Christophe JAILLET
2024-03-23 21:25 ` Marek Behún
2024-03-24 9:21 ` Christophe JAILLET
2024-03-24 15:08 ` Marek Behún
2024-03-25 11:05 ` Dan Carpenter
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=20240325105742.0e1c8906@dellmb \
--to=kabel@kernel.org \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=gaurav.jain@nxp.com \
--cc=gregory.clement@bootlin.com \
--cc=hdegoede@redhat.com \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=mazziesaccount@gmail.com \
--cc=pankaj.gupta@nxp.com \
--cc=soc@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox