Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
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.


  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