linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Ben Levinsky <BLEVINSK@xilinx.com>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-remoteproc@vger.kernel.org"
	<linux-remoteproc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Michal Simek <michals@xilinx.com>,
	"Ed T. Mooring" <emooring@xilinx.com>
Subject: Re: [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver
Date: Wed, 17 Mar 2021 10:22:49 -0600	[thread overview]
Message-ID: <20210317162249.GA1494354@xps15> (raw)
In-Reply-To: <1AD6632B-A69E-406B-A644-440B9C8B929F@xilinx.com>

[...]

>     >     > +/*
>     >     > + * zynqmp_r5_remoteproc_probe
>     >     > + *
>     >     > + * @pdev: domain platform device for R5 cluster
>     >     > + *
>     >     > + * called when driver is probed, for each R5 core specified in DT,
>     >     > + * setup as needed to do remoteproc-related operations
>     >     > + *
>     >     > + * Return: 0 for success, negative value for failure.
>     >     > + */
>     >     > +static int zynqmp_r5_remoteproc_probe(struct platform_device *pdev)
>     >     > +{
>     >     > +	int ret, core_count;
>     >     > +	struct device *dev = &pdev->dev;
>     >     > +	struct device_node *nc;
>     >     > +	enum rpu_oper_mode rpu_mode = PM_RPU_MODE_LOCKSTEP;
>     >     > +	struct list_head *cluster; /* list to track each core's rproc */
>     >     > +	struct zynqmp_r5_rproc *z_rproc;
>     >     > +	struct platform_device *child_pdev;
>     >     > +	struct list_head *pos;
>     >     > +
>     >     > +	ret = of_property_read_u32(dev->of_node, "xlnx,cluster-mode", &rpu_mode);
>     >     > +	if (ret < 0 || (rpu_mode != PM_RPU_MODE_LOCKSTEP &&
>     >     > +			rpu_mode != PM_RPU_MODE_SPLIT)) {
>     >     > +		dev_err(dev, "invalid cluster mode: ret %d mode %x\n",
>     >     > +			ret, rpu_mode);
>     >     > +		return ret;
>     >     > +	}
>     >     > +
>     >     > +	dev_dbg(dev, "RPU configuration: %s\n",
>     >     > +		rpu_mode == PM_RPU_MODE_LOCKSTEP ? "lockstep" : "split");
>     >     > +
>     >     > +	/*
>     >     > +	 * if 2 RPUs provided but one is lockstep, then we have an
>     >     > +	 * invalid configuration.
>     >     > +	 */
>     >     > +
>     >     > +	core_count = of_get_available_child_count(dev->of_node);
>     >     > +	if ((rpu_mode == PM_RPU_MODE_LOCKSTEP && core_count != 1) ||
>     >     > +	    core_count > MAX_RPROCS)
>     >     > +		return -EINVAL;
>     >     > +
>     >     > +	cluster = devm_kzalloc(dev, sizeof(*cluster), GFP_KERNEL);
>     >     > +	if (!cluster)
>     >     > +		return -ENOMEM;
>     >     > +	INIT_LIST_HEAD(cluster);
>     >     > +
>     >     > +	ret = devm_of_platform_populate(dev);
>     >     > +	if (ret) {
>     >     > +		dev_err(dev, "devm_of_platform_populate failed, ret = %d\n", ret);
>     >     > +		return ret;
>     >     > +	}
>     >     > +
>     >     > +	/* probe each individual r5 core's remoteproc-related info */
>     >     > +	for_each_available_child_of_node(dev->of_node, nc) {
>     >     > +		child_pdev = of_find_device_by_node(nc);
>     > 
>     >     The device reference needs to be dropped after use, as described in the function
>     >     documentation.
>     > 
>     >     I'm out of time - I will continue tomorrow.
>     > 
>     >     Mathieu
>     > 
>     > 
>     > [Ben] By this do you mean that for each platform_device should have a call like
>     > 	platform_set_drvdata(child_pdev, NULL); if it fails? or something else?
> 
>     Have another read at the documentation and look at how other people have used
>     it.  You may already be aware but Bootlin's kernel cross-reference tool is
>     really good for that.
> 
>     https://elixir.bootlin.com/linux/v5.12-rc3/source
> 
> If I understand what you are saying I will add calls for put_device(child_pdev) in error handling and at end of the loop.

That's one part of it.  But what will happen if there is no errors to deal with?
Where will the reference to child_pdev->dev be dropped?

> 
> 

  reply	other threads:[~2021-03-17 16:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 15:44 [PATCH v26 0/5] Add initial zynqmp R5 remoteproc driver Ben Levinsky
2021-02-23 15:44 ` [PATCH v26 1/5] firmware: xilinx: Add ZynqMP firmware ioctl enums for RPU configuration Ben Levinsky
2021-02-23 15:44 ` [PATCH v26 2/5] firmware: xilinx: Add shutdown/wakeup APIs Ben Levinsky
2021-02-23 15:44 ` [PATCH v26 3/5] firmware: xilinx: Add RPU configuration APIs Ben Levinsky
2021-02-23 15:44 ` [PATCH v26 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings Ben Levinsky
2021-02-23 15:44 ` [PATCH v26 5/5] remoteproc: Add initial zynqmp R5 remoteproc driver Ben Levinsky
2021-03-08 19:00   ` Mathieu Poirier
2021-03-11 23:47     ` Ben Levinsky
2021-03-15 17:25       ` Mathieu Poirier
2021-03-15 21:42         ` Ben Levinsky
2021-03-17 16:22           ` Mathieu Poirier [this message]
2021-03-09 16:53   ` Mathieu Poirier
2021-03-11 23:49     ` Ben Levinsky
2021-03-15 17:37       ` Mathieu Poirier
2021-03-15 21:32         ` Ben Levinsky
2021-03-17 16:27           ` Mathieu Poirier
2021-03-19 17:46             ` Ben Levinsky
2021-03-22  0:10             ` Ben Levinsky
2021-02-23 16:34 ` [PATCH v26 0/5] " Mathieu Poirier

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=20210317162249.GA1494354@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=BLEVINSK@xilinx.com \
    --cc=devicetree@vger.kernel.org \
    --cc=emooring@xilinx.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=michals@xilinx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).