lkml.org 
[lkml]   [2019]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v0] nvmem: core: Export nvmem cell info to userspace
From
Date

On 3/25/2019 4:28 PM, Srinivas Kandagatla wrote:
>
>
> On 24/03/2019 15:25, Gaurav Kohli wrote:
>>
>> On 3/22/2019 8:53 PM, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 20/03/2019 05:53, Gaurav Kohli wrote:
>>>> From: Shiraz Hashim <shashim@codeaurora.org>
>>>>
>>>> Existing nvmem framework export full register space
>>>> as nvmem binary, but not exporting child node of nvmem
>>>> which is nvmem cell. Kernel can read the specific cell
>>>> by using nvmem_cell_read but userspace don't have such
>>>> provision.
>>>>
>>>> Add framework to export nvmem cell as well, So
>>>> userspace can use it directly.
>>>>
>>>> Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>
>>>> Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>
>>>> Co-developed-by: Gaurav Kohli <gkohli@codeaurora.org>
>>>>
>>>> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
>>>
>>> Thankyou for the patch.
>>>
>>> Why do you need such provision when the userspace can just get the
>>> cell values using correct offset and size.
>>> This will also bring over head of managing entries dynamically +
>>> confusing userspace abi.
>>>
>>> Unless you have a valid reason or usecase I don't see the need for
>>> this.
>>
>>
>> Hi Srinivas,
>>
>>
>> This is mainly for user space convenience, In existing implementation
>> they have to do manipulation according
>
>>
>> to offset and bit, And with present patch, they just have to do cat
>> for cell name and which can also be easily maintainable
> Yes, that is expected I guess!
>
>>
>> for different soc. But with current, it is difficult to maintain
>> users space code as each time we have to change user space code
>> according to bit.
>
> Which user space code/application are you referring to here? Are these
> open source?

Hi Srini,

This is not open source, we have a requirement to read certain bits of
nvmem.

>
>>
>>
>> This would also help to expose certain bit only as per the bit
>> parameter mentioned in dt node, which would also help to protect
>> exposing of
>>
> NVMEM is not just limited for DT users, non dt users use this f/w too.
> So the problem is not as simple as it sounds.
>
> If your issue is just about DT, you could easily parse active device
> tree via  /proc/device-tree and get cell offset, length and names from
> it, use this information to read from nvmem.
>
> There are other concerns about the userspace ABI w.r.t udev events.
> udev events would race with the creation on this cell entries
> resulting in a behavior where user-space applications would not see
> the entries after udev events.
>
> In worst case if we decide to go with adding cells to nvmem then we
> should do it before the device is even probed using group attributes.
> And this would mean that we can not support cells that are dynamically
> defined. And there might be some memory freeing issues in this method
> too!
yes i agree they are dynamic entries as well of nvmem cell,  Can you
please suggest some other way ?
>
> --srini
>
>
>> other bits to user space.
>>
>>>
>>> thanks,
>>> srini
>>
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

\
 
 \ /
  Last update: 2019-03-26 14:14    [W:0.053 / U:1.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site