[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <725edcc6-250a-0cd3-4c32-300f48a8ad79@quicinc.com>
Date: Thu, 19 Jan 2023 15:03:05 +0530
From: Naman Jain <quic_namajain@...cinc.com>
To: Trilok Soni <quic_tsoni@...cinc.com>,
Bjorn Andersson <andersson@...nel.org>,
Andy Gross <agross@...nel.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>
CC: <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<quic_pkondeti@...cinc.com>
Subject: Re: [PATCH 1/2] soc: qcom: socinfo: Change socinfo variable name and
scope
Hi Trilok,
Thanks for reviewing the patches.
On 1/12/2023 3:07 AM, Trilok Soni wrote:
> On 1/11/2023 12:21 AM, Naman Jain wrote:
>> Change socinfo structure variable scope from function to file
>> to make it easy to support custom attributes for sysfs. Also,
>> change variable name to make it more descriptive.
>
> Did you mean debugfs?
No, I meant sysfs only. debugfs support is generally added with every
version update, in kernel. Since debugfs can't be used for these
purposes in production devices, we are proposing to extend current sysfs
interface.
>
> Can you one example of custom attribute in the commit text so that we
> understand the motivation better?
>
I'll add the examples in next patch. Thanks.
>>
>> Signed-off-by: Naman Jain <quic_namajain@...cinc.com>
>> ---
>> drivers/soc/qcom/socinfo.c | 80 ++++++++++++++++++++------------------
>> 1 file changed, 42 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
>> index 10efdbcfdf05..251c0fd94962 100644
>> --- a/drivers/soc/qcom/socinfo.c
>> +++ b/drivers/soc/qcom/socinfo.c
>> @@ -175,6 +175,7 @@ struct socinfo {
>> __le32 npartnamemap_offset;
>> __le32 nnum_partname_mapping;
>> };
>> +static struct socinfo *soc_info;
>
> Is there any better way to do it? Should not asume the just one object
> and dynamically allocate it? Let's wait for Bjorn to check as well.
So current sysfs attributes are added in probe function, where this
"info" variable is defined and used. For additions to current sysfs
interface, using a separate function, the need for having this variable
with file scope came. Now, I can keep the variable name, same, as "info"
and not change it to "soc_info" if the forum suggests that, just that we
thought it feels more descriptive to change it to "soc_info", when we
make it's scope to file. Also, in future, with this variable global, if
we decide to support kernel clients by exporting these fields through
APIs, we can easily make use of this and implement.
>
> ---Trilok Soni
Thanks,
Naman Jain
Powered by blists - more mailing lists