From: Deepak Kumar Singh <quic_deesin@quicinc.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Jingyi Wang <jingyi.wang@oss.qualcomm.com>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>
Cc: <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Chris Lew <chris.lew@oss.qualcomm.com>
Subject: Re: [PATCH 2/2] soc: qcom: smp2p: Add support for smp2p v2
Date: Wed, 22 Oct 2025 16:20:11 +0530 [thread overview]
Message-ID: <aaff2cf4-5811-4cb5-860e-b9704d152da5@quicinc.com> (raw)
In-Reply-To: <15617371-0b20-4326-8e08-2c20b3d3c767@oss.qualcomm.com>
On 10/21/2025 3:09 PM, Konrad Dybcio wrote:
> On 10/21/25 10:23 AM, Deepak Kumar Singh wrote:
>>
>>
>> On 9/24/2025 8:27 PM, Konrad Dybcio wrote:
>>> On 9/24/25 6:18 AM, Jingyi Wang wrote:
>>>> From: Chris Lew <chris.lew@oss.qualcomm.com>
>>>>
>>>> Some remoteproc need smp2p v2 support, mirror the version written by the
>>>> remote if the remote supports v2. This is needed if the remote does not
>>>> have backwards compatibility with v1. And reset entry last value on SSR for
>>>> smp2p v2.
>>>>
>>>> Signed-off-by: Chris Lew <chris.lew@oss.qualcomm.com>
>>>> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +static int qcom_smp2p_in_version(struct qcom_smp2p *smp2p)
>>>> +{
>>>> + unsigned int smem_id = smp2p->smem_items[SMP2P_INBOUND];
>>>> + unsigned int pid = smp2p->remote_pid;
>>>> + struct smp2p_smem_item *in;
>>>> + size_t size;
>>>> +
>>>> + in = qcom_smem_get(pid, smem_id, &size);
>>>> + if (IS_ERR(in))
>>>> + return 0;
>>>> +
>>>> + return in->version;
>>>
>>> are in and out versions supposed to be out of sync in case of
>>> error?
>>>
>> I think that should be ok. If we return error smp2p connection will be completely broken. With default version 1 partial features can be supported even if remote is using version 2. Some features like smp2p connection after subsystem restart may be affected by this.>> +}
>
> Perhaps a different question is in order.. do we ever expect smem_get to
> fail under normal conditions?
>
> [...]
>
Good point, i think that should never happen for early boot processor
which will use version 2. That can possibly happen for processor that is
coming late than local host(version 1). In that case anyway we are
setting default version 1 and proceeding. >>>> /*
>>>> * Make sure the rest of the header is written before we validate the
>>>> * item by writing a valid version number.
>>>> */
>>>> wmb();
>>>> - out->version = 1;
>>>> + out->version = (in_version) ? in_version : 1;
>>>
>>> = in_version ?: 1
>>>
>>> Konrad
>>>
>> We want to assign in_version when value is 1/2 and 1 if value is 0 i.e. error case.
>
> That's what this syntax does, with less characters
>
> Konrad
Yes in_version ?:1 is short hand but i find (in_version) ? in_version :
1; more readable and obvious.
next prev parent reply other threads:[~2025-10-22 10:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 4:18 [PATCH 0/2] soc: qcom: smp2p: Add support for remoteproc early attach Jingyi Wang
2025-09-24 4:18 ` [PATCH 1/2] soc: qcom: smp2p: Add irqchip state support Jingyi Wang
2025-09-24 14:50 ` Konrad Dybcio
2025-10-21 8:12 ` Deepak Kumar Singh
2025-10-21 9:35 ` Konrad Dybcio
2025-10-22 10:57 ` Deepak Kumar Singh
2025-10-22 22:13 ` Bjorn Andersson
2025-10-23 1:05 ` Christopher Lew
2025-09-24 4:18 ` [PATCH 2/2] soc: qcom: smp2p: Add support for smp2p v2 Jingyi Wang
2025-09-24 14:57 ` Konrad Dybcio
2025-10-21 8:23 ` Deepak Kumar Singh
2025-10-21 9:39 ` Konrad Dybcio
2025-10-22 10:50 ` Deepak Kumar Singh [this message]
2025-10-29 0:35 ` Christopher Lew
2025-10-22 22:19 ` Bjorn Andersson
2025-10-23 2:14 ` Jingyi Wang
2025-10-29 0:44 ` Christopher Lew
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=aaff2cf4-5811-4cb5-860e-b9704d152da5@quicinc.com \
--to=quic_deesin@quicinc.com \
--cc=andersson@kernel.org \
--cc=chris.lew@oss.qualcomm.com \
--cc=jingyi.wang@oss.qualcomm.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.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