Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
To: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>,
	Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] soc: qcom: socinfo: Add support for new fields in revision 21
Date: Sat, 10 May 2025 00:46:13 +0200	[thread overview]
Message-ID: <aa864626-3910-403b-a7f6-b3d86b4ed423@oss.qualcomm.com> (raw)
In-Reply-To: <aB3TkK7wEjdxSSvQ@hu-mojha-hyd.qualcomm.com>

On 5/9/25 12:06 PM, Mukesh Ojha wrote:
> On Thu, May 08, 2025 at 08:01:44PM +0200, Konrad Dybcio wrote:
>> On 5/8/25 6:48 PM, Mukesh Ojha wrote:
>>> On Thu, May 08, 2025 at 06:56:47PM +0300, Dmitry Baryshkov wrote:
>>>> On Thu, May 08, 2025 at 09:07:03PM +0530, Mukesh Ojha wrote:
>>>>> On Fri, Apr 25, 2025 at 08:28:51PM +0300, Dmitry Baryshkov wrote:
>>>>>> On Fri, Apr 25, 2025 at 07:29:45PM +0530, Mukesh Ojha wrote:
>>>>>>> Add the subpartfeature offset field to the socinfo structure
>>>>>>> which came for version 21 of socinfo structure.
>>>>>>>
>>>>>>> Subpart_feat_offset is subpart like camera, display, etc.,
>>>>>>> and its internal feature available on a bin.
>>>>>>>
>>>>>>> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> Changes in v2:
>>>>>>>  - Added debugfs entry and described more about the field in commit.
>>>>>>>
>>>>>>>  drivers/soc/qcom/socinfo.c       | 6 ++++++
>>>>>>>  include/linux/soc/qcom/socinfo.h | 2 ++
>>>>>>>  2 files changed, 8 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
>>>>>>> index 5800ebf9ceea..bac1485f1b27 100644
>>>>>>> --- a/drivers/soc/qcom/socinfo.c
>>>>>>> +++ b/drivers/soc/qcom/socinfo.c
>>>>>>> @@ -154,6 +154,7 @@ struct socinfo_params {
>>>>>>>  	u32 boot_cluster;
>>>>>>>  	u32 boot_core;
>>>>>>>  	u32 raw_package_type;
>>>>>>> +	u32 nsubpart_feat_array_offset;
>>>>>>>  };
>>>>>>>  
>>>>>>>  struct smem_image_version {
>>>>>>> @@ -608,6 +609,11 @@ static void socinfo_debugfs_init(struct qcom_socinfo *qcom_socinfo,
>>>>>>>  			   &qcom_socinfo->info.fmt);
>>>>>>>  
>>>>>>>  	switch (qcom_socinfo->info.fmt) {
>>>>>>> +	case SOCINFO_VERSION(0, 21):
>>>>>>> +		qcom_socinfo->info.nsubpart_feat_array_offset =
>>>>>>> +				   __le32_to_cpu(info->nsubpart_feat_array_offset);
>>>>>>> +		debugfs_create_u32("nsubpart_feat_array_offset", 0444, qcom_socinfo->dbg_root,
>>>>>>> +				   &qcom_socinfo->info.nsubpart_feat_array_offset);
>>>>>>
>>>>>> An offset into what? If this provides additional data, then the data
>>>>>> should be visible in the debugfs. Not sure, what's the point in dumping
>>>>>> the offset here.
>>>>>
>>>>> offset into info(struct socinfo) object.
>>>>>
>>>>> I agree to you and I said the same in first version this is just offset
>>>>> and does not provide any debug info we would look from userspace.  For
>>>>> parity with other fields I did it for all newly added fields.
>>>>> I have dropped it in latest patch.
>>>>
>>>> I'd rather see the decoded structure that is being pointed by this
>>>> offset.
>>>
>>> You mean info + info->nsubpart_feat_array_offset ? 
>>>
>>> There is more to it which I don't want to mention as they are not
>>> upstreamed yet and unrelated to this change.
>>>
>>> data = info + (offset + (part * sizeof(u32)));
>>>
>>> e.g., Here, part is a enum represents camera, display etc., and data
>>> represents their feature presents. Since, part is not upstream yet I
>>> don't feel we should expose this information to debugfs. We could always
>>> add them in debugfs when such things are standardized and upstreamed.
>>
>> That's what Dmitry's saying - just add support for them
> 
> We definitely add support for this in the future.  In the meantime, does
> the absence of the support prevent this socinfo field from being merged?
> Without it, there could be inconsistencies between the boot firmware and
> Linux for the SM8750 platform.

Why delay adding a couple struct definitions into the "future"? I feel
like we spent more time on this thread that describing them would take

Konrad

  reply	other threads:[~2025-05-09 22:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-25 13:59 [PATCH v2 1/3] soc: qcom: socinfo: Add support for new fields in revision 20 Mukesh Ojha
2025-04-25 13:59 ` [PATCH v2 2/3] soc: qcom: socinfo: Add support for new fields in revision 21 Mukesh Ojha
2025-04-25 17:28   ` Dmitry Baryshkov
2025-05-08 15:37     ` Mukesh Ojha
2025-05-08 15:56       ` Dmitry Baryshkov
2025-05-08 16:48         ` Mukesh Ojha
2025-05-08 18:01           ` Konrad Dybcio
2025-05-09 10:06             ` Mukesh Ojha
2025-05-09 22:46               ` Konrad Dybcio [this message]
2025-04-25 13:59 ` [PATCH v2 3/3] soc: qcom: socinfo: Add support for new fields in revision 22 Mukesh Ojha
2025-04-25 17:29   ` Dmitry Baryshkov
2025-04-25 17:29 ` [PATCH v2 1/3] soc: qcom: socinfo: Add support for new fields in revision 20 Dmitry Baryshkov
2025-04-25 19:18 ` Konrad Dybcio
2025-04-26 16:28 ` kernel test robot
2025-04-26 17:30 ` kernel test robot

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=aa864626-3910-403b-a7f6-b3d86b4ed423@oss.qualcomm.com \
    --to=konrad.dybcio@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mukesh.ojha@oss.qualcomm.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