All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Fabien DESSENNE <fabien.dessenne@st.com>
Cc: Paul Cercueil <paul@crapouillou.net>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, "od@zcrc.me" <od@zcrc.me>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/5] remoteproc: Add device-managed variants of rproc_alloc/rproc_add
Date: Mon, 20 Jan 2020 11:45:04 -0800	[thread overview]
Message-ID: <20200120194500.GM1511@yoga> (raw)
In-Reply-To: <6fff431f-dd3f-a67e-e40b-8cee4060c37a@st.com>

On Thu 12 Dec 01:43 PST 2019, Fabien DESSENNE wrote:

> Hi Paul,
> 
> 
> Good initiative! See me remarks below.
> 

I concur!

> 
> On 10/12/2019 5:40 PM, Paul Cercueil wrote:
> > Add API functions devm_rproc_alloc() and devm_rproc_add(), which behave
> > like rproc_alloc() and rproc_add() respectively, but register their
> > respective cleanup function to be called on driver detach.
> >
> > Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> > ---
> >
> > Notes:
> >      v3: New patch
> >      v4: No change
> >
> >   drivers/remoteproc/remoteproc_core.c | 67 ++++++++++++++++++++++++++++
> >   include/linux/remoteproc.h           |  5 +++
> >   2 files changed, 72 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > index 307df98347ba..0a9fc7fdd1c3 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> 
> 
> Maybe these devm function shall be defined in a new remoteproc/devres.c 
> file. Although it seems to be a common usage I don't know if there is a 
> rule for that.
> 

Let's keep it in this same file, the devres.c would be tiny.

> 
> > @@ -1932,6 +1932,33 @@ int rproc_add(struct rproc *rproc)
> >   }
> >   EXPORT_SYMBOL(rproc_add);
> >   
> > +static void devm_rproc_remove(void *rproc)
> > +{
> > +	rproc_del(rproc);
> > +}
> > +
> > +/**
> > + * devm_rproc_add() - resource managed rproc_add()
> > + * @dev: the underlying device
> > + * @rproc: the remote processor handle to register
> > + *
> > + * This function performs like rproc_add() but the registered rproc device will
> > + * automatically be removed on driver detach.
> > + *
> > + * Returns 0 on success and an appropriate error code otherwise.
> > + */
> > +int devm_rproc_add(struct device *dev, struct rproc *rproc)
> > +{
> > +	int err;
> > +
> > +	err = rproc_add(rproc);
> > +	if (err)
> > +		return err;
> > +
> > +	return devm_add_action_or_reset(dev, devm_rproc_remove, rproc);
> > +}
> > +EXPORT_SYMBOL(devm_rproc_add);
> > +
> >   /**
> >    * rproc_type_release() - release a remote processor instance
> >    * @dev: the rproc's device
> > @@ -2149,6 +2176,46 @@ int rproc_del(struct rproc *rproc)
> >   }
> >   EXPORT_SYMBOL(rproc_del);
> >   
> > +static void devm_rproc_free(struct device *dev, void *res)
> > +{
> > +	rproc_free(*(struct rproc **)res);
> > +}
> > +
> > +/**
> > + * devm_rproc_alloc() - resource managed rproc_alloc()
> > + * @dev: the underlying device
> > + * @name: name of this remote processor
> > + * @ops: platform-specific handlers (mainly start/stop)
> > + * @firmware: name of firmware file to load, can be NULL
> > + * @len: length of private data needed by the rproc driver (in bytes)
> > + *
> > + * This function performs like rproc_alloc() but the acuired rproc device will
> 
> 
> typo: s/acuired/acquired
> 
> 
> > + * automatically be released on driver detach.
> > + *
> > + * On success the new rproc is returned, and on failure, NULL.
> > + */
> > +struct rproc *devm_rproc_alloc(struct device *dev, const char *name,
> > +			       const struct rproc_ops *ops,
> > +			       const char *firmware, int len)
> > +{
> > +	struct rproc **ptr, *rproc;
> > +
> > +	ptr = devres_alloc(devm_rproc_free, sizeof(*ptr), GFP_KERNEL);
> > +	if (!ptr)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rproc = rproc_alloc(dev, name, ops, firmware, len);
> > +	if (rproc) {
> > +		*ptr = rproc;
> > +		devres_add(dev, ptr);
> > +	} else {
> > +		devres_free(ptr);
> > +	}
> > +
> > +	return rproc;
> 
> 
> Can't you use devm_add_action_or_reset() here too?
> 

The proposed function matches how everyone else is doing devm_*_alloc(),
so I would like to keep it as is.

Regards,
Bjorn

> 
> > +}
> > +EXPORT_SYMBOL(devm_rproc_alloc);
> > +
> >   /**
> >    * rproc_add_subdev() - add a subdevice to a remoteproc
> >    * @rproc: rproc handle to add the subdevice to
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 16ad66683ad0..5f201f0c86c3 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -595,6 +595,11 @@ int rproc_add(struct rproc *rproc);
> >   int rproc_del(struct rproc *rproc);
> >   void rproc_free(struct rproc *rproc);
> >   
> > +struct rproc *devm_rproc_alloc(struct device *dev, const char *name,
> > +			       const struct rproc_ops *ops,
> > +			       const char *firmware, int len);
> > +int devm_rproc_add(struct device *dev, struct rproc *rproc);
> > +
> >   void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry *mem);
> >   
> >   struct rproc_mem_entry *
> 
> 
> BR
> 
> Fabien

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Fabien DESSENNE <fabien.dessenne@st.com>
Cc: Paul Cercueil <paul@crapouillou.net>,
	Ohad Ben-Cohen <ohad@wizery.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, "od@zcrc.me" <od@zcrc.me>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/5] remoteproc: Add device-managed variants of rproc_alloc/rproc_add
Date: Mon, 20 Jan 2020 11:45:00 -0800	[thread overview]
Message-ID: <20200120194500.GM1511@yoga> (raw)
In-Reply-To: <6fff431f-dd3f-a67e-e40b-8cee4060c37a@st.com>

On Thu 12 Dec 01:43 PST 2019, Fabien DESSENNE wrote:

> Hi Paul,
> 
> 
> Good initiative! See me remarks below.
> 

I concur!

> 
> On 10/12/2019 5:40 PM, Paul Cercueil wrote:
> > Add API functions devm_rproc_alloc() and devm_rproc_add(), which behave
> > like rproc_alloc() and rproc_add() respectively, but register their
> > respective cleanup function to be called on driver detach.
> >
> > Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> > ---
> >
> > Notes:
> >      v3: New patch
> >      v4: No change
> >
> >   drivers/remoteproc/remoteproc_core.c | 67 ++++++++++++++++++++++++++++
> >   include/linux/remoteproc.h           |  5 +++
> >   2 files changed, 72 insertions(+)
> >
> > diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> > index 307df98347ba..0a9fc7fdd1c3 100644
> > --- a/drivers/remoteproc/remoteproc_core.c
> > +++ b/drivers/remoteproc/remoteproc_core.c
> 
> 
> Maybe these devm function shall be defined in a new remoteproc/devres.c 
> file. Although it seems to be a common usage I don't know if there is a 
> rule for that.
> 

Let's keep it in this same file, the devres.c would be tiny.

> 
> > @@ -1932,6 +1932,33 @@ int rproc_add(struct rproc *rproc)
> >   }
> >   EXPORT_SYMBOL(rproc_add);
> >   
> > +static void devm_rproc_remove(void *rproc)
> > +{
> > +	rproc_del(rproc);
> > +}
> > +
> > +/**
> > + * devm_rproc_add() - resource managed rproc_add()
> > + * @dev: the underlying device
> > + * @rproc: the remote processor handle to register
> > + *
> > + * This function performs like rproc_add() but the registered rproc device will
> > + * automatically be removed on driver detach.
> > + *
> > + * Returns 0 on success and an appropriate error code otherwise.
> > + */
> > +int devm_rproc_add(struct device *dev, struct rproc *rproc)
> > +{
> > +	int err;
> > +
> > +	err = rproc_add(rproc);
> > +	if (err)
> > +		return err;
> > +
> > +	return devm_add_action_or_reset(dev, devm_rproc_remove, rproc);
> > +}
> > +EXPORT_SYMBOL(devm_rproc_add);
> > +
> >   /**
> >    * rproc_type_release() - release a remote processor instance
> >    * @dev: the rproc's device
> > @@ -2149,6 +2176,46 @@ int rproc_del(struct rproc *rproc)
> >   }
> >   EXPORT_SYMBOL(rproc_del);
> >   
> > +static void devm_rproc_free(struct device *dev, void *res)
> > +{
> > +	rproc_free(*(struct rproc **)res);
> > +}
> > +
> > +/**
> > + * devm_rproc_alloc() - resource managed rproc_alloc()
> > + * @dev: the underlying device
> > + * @name: name of this remote processor
> > + * @ops: platform-specific handlers (mainly start/stop)
> > + * @firmware: name of firmware file to load, can be NULL
> > + * @len: length of private data needed by the rproc driver (in bytes)
> > + *
> > + * This function performs like rproc_alloc() but the acuired rproc device will
> 
> 
> typo: s/acuired/acquired
> 
> 
> > + * automatically be released on driver detach.
> > + *
> > + * On success the new rproc is returned, and on failure, NULL.
> > + */
> > +struct rproc *devm_rproc_alloc(struct device *dev, const char *name,
> > +			       const struct rproc_ops *ops,
> > +			       const char *firmware, int len)
> > +{
> > +	struct rproc **ptr, *rproc;
> > +
> > +	ptr = devres_alloc(devm_rproc_free, sizeof(*ptr), GFP_KERNEL);
> > +	if (!ptr)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	rproc = rproc_alloc(dev, name, ops, firmware, len);
> > +	if (rproc) {
> > +		*ptr = rproc;
> > +		devres_add(dev, ptr);
> > +	} else {
> > +		devres_free(ptr);
> > +	}
> > +
> > +	return rproc;
> 
> 
> Can't you use devm_add_action_or_reset() here too?
> 

The proposed function matches how everyone else is doing devm_*_alloc(),
so I would like to keep it as is.

Regards,
Bjorn

> 
> > +}
> > +EXPORT_SYMBOL(devm_rproc_alloc);
> > +
> >   /**
> >    * rproc_add_subdev() - add a subdevice to a remoteproc
> >    * @rproc: rproc handle to add the subdevice to
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 16ad66683ad0..5f201f0c86c3 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -595,6 +595,11 @@ int rproc_add(struct rproc *rproc);
> >   int rproc_del(struct rproc *rproc);
> >   void rproc_free(struct rproc *rproc);
> >   
> > +struct rproc *devm_rproc_alloc(struct device *dev, const char *name,
> > +			       const struct rproc_ops *ops,
> > +			       const char *firmware, int len);
> > +int devm_rproc_add(struct device *dev, struct rproc *rproc);
> > +
> >   void rproc_add_carveout(struct rproc *rproc, struct rproc_mem_entry *mem);
> >   
> >   struct rproc_mem_entry *
> 
> 
> BR
> 
> Fabien

  parent reply	other threads:[~2020-01-20 19:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-10 16:40 [PATCH v4 1/5] dt-bindings: Document JZ47xx VPU auxiliary processor Paul Cercueil
2019-12-10 16:40 ` [PATCH v4 2/5] remoteproc: Add device-managed variants of rproc_alloc/rproc_add Paul Cercueil
2019-12-12  9:43   ` Fabien DESSENNE
2019-12-14 22:27     ` Paul Cercueil
2020-01-20 19:45     ` Bjorn Andersson [this message]
2020-01-20 19:45       ` Bjorn Andersson
2019-12-16 10:46   ` Clément Leger
2019-12-16 13:41     ` Paul Cercueil
2020-01-20 20:07   ` Bjorn Andersson
2020-01-20 20:07     ` Bjorn Andersson
2019-12-10 16:40 ` [PATCH v4 3/5] remoteproc: Add prepare/unprepare callbacks Paul Cercueil
2019-12-12 10:03   ` Fabien DESSENNE
2019-12-14 22:30     ` Paul Cercueil
2019-12-16  8:42       ` Clément Leger
2019-12-16 16:16         ` Clément Leger
2019-12-17 10:21       ` Fabien DESSENNE
2019-12-21 20:20   ` Bjorn Andersson
2019-12-21 20:20     ` Bjorn Andersson
2020-01-15 21:15     ` Paul Cercueil
2020-01-20 20:19       ` Bjorn Andersson
2020-01-20 20:19         ` Bjorn Andersson
2020-01-21 10:24         ` Arnaud POULIQUEN
2020-01-21 10:24           ` Arnaud POULIQUEN
2019-12-10 16:40 ` [PATCH v4 4/5] remoteproc: ingenic: Added remoteproc driver Paul Cercueil
2019-12-10 16:40 ` [PATCH v4 5/5] MAINTAINERS: Add myself as reviewer for Ingenic rproc driver Paul Cercueil
2019-12-13 19:02 ` [PATCH v4 1/5] dt-bindings: Document JZ47xx VPU auxiliary processor Rob Herring
2019-12-13 21:27   ` Paul Cercueil

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=20200120194500.GM1511@yoga \
    --to=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabien.dessenne@st.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=od@zcrc.me \
    --cc=ohad@wizery.com \
    --cc=paul@crapouillou.net \
    --cc=robh+dt@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 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.