From: Greg KH <gregkh@linuxfoundation.org>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>,
srinivas.kandagatla@linaro.org, linux-arm-msm@vger.kernel.org,
quic_bkumar@quicinc.com, linux-kernel@vger.kernel.org,
quic_chennak@quicinc.com, dri-devel@lists.freedesktop.org,
arnd@arndb.de, stable@kernel.org
Subject: Re: [PATCH v2] misc: fastrpc: Fix channel resource access in device_open
Date: Tue, 24 Jun 2025 16:36:35 +0100 [thread overview]
Message-ID: <2025062424-dizziness-theft-0502@gregkh> (raw)
In-Reply-To: <kk3jvlwjdzy2mfs6bip7dadrnsoxwksyp2odi3rfxkv4crmwtn@x5qyn4sp2gck>
On Tue, Jun 24, 2025 at 04:27:21PM +0300, Dmitry Baryshkov wrote:
> On Thu, Jun 19, 2025 at 10:40:26AM +0530, Ekansh Gupta wrote:
> > During rpmsg_probe, fastrpc device nodes are created first, then
> > channel specific resources are initialized, followed by
> > of_platform_populate, which triggers context bank probing. This
> > sequence can cause issues as applications might open the device
> > node before channel resources are initialized or the session is
> > available, leading to problems. For example, spin_lock is initialized
> > after the device node creation, but it is used in device_open,
> > potentially before initialization. Move device registration after
> > channel resource initialization in fastrpc_rpmsg_probe.
>
> You've moved device init, however there is still a possibility for the
> context devices to be created, but not bound to the driver (because all
> the probings are async). I think instead we should drop the extra
> platform driver layer and create and set up corresponding devices
> manually. For example, see how it is handled in
> host1x_memory_context_list_init(). That function uses iommu-maps, but we
> can use OF nodes and iommus instead.
Is this a real platform device? If so, why do you need a second
platform driver, what makes this so unique? If this isn't a platform
device, then why not just use the faux bus instead?
It seems that "number of sessions" is a DT property, is that something
that is really defined by the hardware? Or is it just a virtual thing
that people are abusing in the DT?
And if you really have all these sessions, why not make them real
devices, wouldn't that make things simpler?
thanks,
greg k-h
next prev parent reply other threads:[~2025-06-24 15:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 5:10 [PATCH v2] misc: fastrpc: Fix channel resource access in device_open Ekansh Gupta
2025-06-24 13:27 ` Dmitry Baryshkov
2025-06-24 15:36 ` Greg KH [this message]
2025-06-24 15:38 ` Greg KH
2025-06-24 23:45 ` Dmitry Baryshkov
2025-06-25 7:09 ` Greg KH
2025-06-26 6:03 ` Ekansh Gupta
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=2025062424-dizziness-theft-0502@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ekansh.gupta@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_bkumar@quicinc.com \
--cc=quic_chennak@quicinc.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=stable@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