All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Suman Anna <s-anna@ti.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Loic Pallardy <loic.pallardy@st.com>,
	Arnaud Pouliquen <arnaud.pouliquen@st.com>,
	Tero Kristo <t-kristo@ti.com>,
	linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev
Date: Tue, 17 Mar 2020 12:05:30 -0600	[thread overview]
Message-ID: <20200317180530.GA1801@xps15> (raw)
In-Reply-To: <20200305224108.21351-3-s-anna@ti.com>

Hi Suman,

On Thu, Mar 05, 2020 at 04:41:08PM -0600, Suman Anna wrote:
> The commit 086d08725d34 ("remoteproc: create vdev subdevice with specific
> dma memory pool") has introduced a new vdev subdevice for each vdev
> declared in the firmware resource table and made it as the parent for the
> created virtio rpmsg devices instead of the previous remoteproc device.
> This changed the overall parenting hierarchy for the rpmsg devices, which
> were children of virtio devices, and does not allow the corresponding
> rpmsg drivers to retrieve the parent rproc device through the
> rproc_get_by_child() API.
> 
> Fix this by restoring the remoteproc device as the parent. The new vdev
> subdevice can continue to inherit the DMA attributes from the remoteproc's
> parent device (actual platform device).
> 
> Fixes: 086d08725d34 ("remoteproc: create vdev subdevice with specific dma memory pool")
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  drivers/remoteproc/remoteproc_core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
> index 097f33e4f1f3..ba18f32bd0c4 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -510,7 +510,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct fw_rsc_vdev *rsc,
>  
>  	/* Initialise vdev subdevice */
>  	snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> -	rvdev->dev.parent = rproc->dev.parent;
> +	rvdev->dev.parent = &rproc->dev;

I can see how it would not be possible to retrieve the parent rproc device since
rvdev->dev.parent was set to be platform device...

I wonder how the original change didn't blow up sysmon_probe() and potentially
other out-of-tree users of rproc_get_by_child().  It would be nice to have
someone from the QCOM team test your patch.

>  	rvdev->dev.dma_pfn_offset = rproc->dev.parent->dma_pfn_offset;
>  	rvdev->dev.release = rproc_rvdev_release;
>  	dev_set_name(&rvdev->dev, "%s#%s", dev_name(rvdev->dev.parent), name);

Be mindful there might be fallouts from applying this patch since it does change
the location of the vdev under /sys/device/platform/ .

Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>

> -- 
> 2.23.0
> 

  reply	other threads:[~2020-03-17 18:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 22:41 [PATCH 0/2] Misc. rproc fixes around fixed memory region support Suman Anna
2020-03-05 22:41 ` Suman Anna
2020-03-05 22:41 ` [PATCH 1/2] remoteproc: fall back to using parent memory pool if no dedicated available Suman Anna
2020-03-05 22:41   ` Suman Anna
2020-03-13 16:52   ` Arnaud POULIQUEN
2020-03-18  9:37     ` Tero Kristo
2020-03-18 16:19       ` Suman Anna
2020-03-18 17:29         ` Arnaud POULIQUEN
2020-03-18 17:29           ` Arnaud POULIQUEN
2020-03-18 18:24           ` Suman Anna
2020-03-05 22:41 ` [PATCH 2/2] remoteproc: Fix and restore the parenting hierarchy for vdev Suman Anna
2020-03-05 22:41   ` Suman Anna
2020-03-17 18:05   ` Mathieu Poirier [this message]
2020-03-18 15:00     ` Suman Anna
2020-03-18 15:00       ` Suman Anna
2020-03-18 16:37       ` Mathieu Poirier
2020-03-18 16:38     ` Arnaud POULIQUEN
2020-03-18 16:38       ` Arnaud POULIQUEN
2020-03-18 19:23       ` Suman Anna
2020-03-18 19:23         ` Suman Anna
2020-03-19 11:41         ` Arnaud POULIQUEN
2020-03-19 11:41           ` Arnaud POULIQUEN

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=20200317180530.GA1801@xps15 \
    --to=mathieu.poirier@linaro.org \
    --cc=arnaud.pouliquen@st.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=loic.pallardy@st.com \
    --cc=s-anna@ti.com \
    --cc=t-kristo@ti.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.