* Adding OTP-only device to MTD or CHAR subsystem?
@ 2015-12-28 23:21 Scott Branden
2015-12-28 23:38 ` Arnd Bergmann
0 siblings, 1 reply; 5+ messages in thread
From: Scott Branden @ 2015-12-28 23:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, Arnd Bergmann, Brian Norris; +Cc: linux-kernel, linux-mtd
Greg/Brian/Arnd,
We have OTP device drivers for accessing OTP memory in our SoCs.
I looking for the right place and model to place such OTP device drivers.
1) Should we follow the bfin-otp model in drivers/char? This doesn't
seem like the right place to put it although following the bfin example
is quite simple to implement. We actually had a custom set of Ioctl's
that I changed to use the standard file access model used by the bfin
driver. But a custom util is still needed to issue an OTPLOCK command.
I'm guess mtd-utils has such abilities (or should).
2) Instead, should we start adding OTP-only drivers into the MTD
subsystem? Onenand and CFI based MTD devices already have OTP
programmable regions. If we created a new OTP device type in the MTD
subsystem this looks like a good thing to do. mtd-utils could/should be
used to access the OTP device then along with standard fileio operations.
3) Or some other suggestion of where to place OTP device drivers?
Regards,
Scott
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding OTP-only device to MTD or CHAR subsystem?
2015-12-28 23:21 Adding OTP-only device to MTD or CHAR subsystem? Scott Branden
@ 2015-12-28 23:38 ` Arnd Bergmann
2015-12-29 0:32 ` Scott Branden
0 siblings, 1 reply; 5+ messages in thread
From: Arnd Bergmann @ 2015-12-28 23:38 UTC (permalink / raw)
To: Scott Branden; +Cc: Greg Kroah-Hartman, Brian Norris, linux-kernel, linux-mtd
On Monday 28 December 2015 15:21:08 Scott Branden wrote:
> Greg/Brian/Arnd,
>
> We have OTP device drivers for accessing OTP memory in our SoCs.
>
> I looking for the right place and model to place such OTP device drivers.
>
> 1) Should we follow the bfin-otp model in drivers/char? This doesn't
> seem like the right place to put it although following the bfin example
> is quite simple to implement. We actually had a custom set of Ioctl's
> that I changed to use the standard file access model used by the bfin
> driver. But a custom util is still needed to issue an OTPLOCK command.
> I'm guess mtd-utils has such abilities (or should).
>
> 2) Instead, should we start adding OTP-only drivers into the MTD
> subsystem? Onenand and CFI based MTD devices already have OTP
> programmable regions. If we created a new OTP device type in the MTD
> subsystem this looks like a good thing to do. mtd-utils could/should be
> used to access the OTP device then along with standard fileio operations.
>
> 3) Or some other suggestion of where to place OTP device drivers?
I think drivers/nvmem is now the right place for this.
Arnd
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding OTP-only device to MTD or CHAR subsystem?
2015-12-28 23:38 ` Arnd Bergmann
@ 2015-12-29 0:32 ` Scott Branden
2016-01-09 11:13 ` Srinivas Kandagatla
0 siblings, 1 reply; 5+ messages in thread
From: Scott Branden @ 2015-12-29 0:32 UTC (permalink / raw)
To: Arnd Bergmann, Srinivas Kandagatla, Maxime Ripard
Cc: Greg Kroah-Hartman, Brian Norris, linux-kernel, linux-mtd
+Srinivas/Maxime
On 15-12-28 03:38 PM, Arnd Bergmann wrote:
> On Monday 28 December 2015 15:21:08 Scott Branden wrote:
>> Greg/Brian/Arnd,
>>
>> We have OTP device drivers for accessing OTP memory in our SoCs.
>>
>> I looking for the right place and model to place such OTP device drivers.
>>
>> 1) Should we follow the bfin-otp model in drivers/char? This doesn't
>> seem like the right place to put it although following the bfin example
>> is quite simple to implement. We actually had a custom set of Ioctl's
>> that I changed to use the standard file access model used by the bfin
>> driver. But a custom util is still needed to issue an OTPLOCK command.
>> I'm guess mtd-utils has such abilities (or should).
>>
>> 2) Instead, should we start adding OTP-only drivers into the MTD
>> subsystem? Onenand and CFI based MTD devices already have OTP
>> programmable regions. If we created a new OTP device type in the MTD
>> subsystem this looks like a good thing to do. mtd-utils could/should be
>> used to access the OTP device then along with standard fileio operations.
>>
>> 3) Or some other suggestion of where to place OTP device drivers?
>
> I think drivers/nvmem is now the right place for this.
Thanks for the pointer Arnd. Too bad an extension wasn't added in MTD
but at least there is some sort of a model in place now. The mtd-abi.h
would have been a good thing to use for OTPLOCK as well as the remainder
of the functionality in MTD OTP. The mapping of nvmem to properties to
user settings seems like a useful feature though.
Hi Srinivas/Maxime,
The nvmem drivers don't seem to support row unlocking of OTP. Having
raw write access to the OTP is not a desirable feature. Are there plans
in place to add any additional functionality to the nvm driver model
right now?
>
> Arnd
>
Regards,
Scott
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding OTP-only device to MTD or CHAR subsystem?
2015-12-29 0:32 ` Scott Branden
@ 2016-01-09 11:13 ` Srinivas Kandagatla
2016-01-13 22:05 ` Scott Branden
0 siblings, 1 reply; 5+ messages in thread
From: Srinivas Kandagatla @ 2016-01-09 11:13 UTC (permalink / raw)
To: Scott Branden, Arnd Bergmann, Maxime Ripard
Cc: Greg Kroah-Hartman, Brian Norris, linux-kernel, linux-mtd
Hi Scott,
Sorry for long delay in replying.. :-)
On 29/12/15 00:32, Scott Branden wrote:
> +Srinivas/Maxime
>
> On 15-12-28 03:38 PM, Arnd Bergmann wrote:
>> On Monday 28 December 2015 15:21:08 Scott Branden wrote:
>>> Greg/Brian/Arnd,
>>>
>>> We have OTP device drivers for accessing OTP memory in our SoCs.
>>>
>>> I looking for the right place and model to place such OTP device
>>> drivers.
>>>
>>> 1) Should we follow the bfin-otp model in drivers/char? This doesn't
>>> seem like the right place to put it although following the bfin example
>>> is quite simple to implement. We actually had a custom set of Ioctl's
>>> that I changed to use the standard file access model used by the bfin
>>> driver. But a custom util is still needed to issue an OTPLOCK command.
>>> I'm guess mtd-utils has such abilities (or should).
>>>
>>> 2) Instead, should we start adding OTP-only drivers into the MTD
>>> subsystem? Onenand and CFI based MTD devices already have OTP
>>> programmable regions. If we created a new OTP device type in the MTD
>>> subsystem this looks like a good thing to do. mtd-utils could/should be
>>> used to access the OTP device then along with standard fileio
>>> operations.
>>>
>>> 3) Or some other suggestion of where to place OTP device drivers?
>>
>> I think drivers/nvmem is now the right place for this.
> Thanks for the pointer Arnd. Too bad an extension wasn't added in MTD
> but at least there is some sort of a model in place now. The mtd-abi.h
> would have been a good thing to use for OTPLOCK as well as the remainder
> of the functionality in MTD OTP. The mapping of nvmem to properties to
> user settings seems like a useful feature though.
>
> Hi Srinivas/Maxime,
> The nvmem drivers don't seem to support row unlocking of OTP. Having
> raw write access to the OTP is not a desirable feature. Are there plans
> in place to add any additional functionality to the nvm driver model
> right now?
NVMEM was started to be simple interface based on regmap, As of today we
did not have any users which wanted lock feature, but Am open for more
discussion on this if we want to get this feature via nvmem.
Any ideas and patches are welcome.
Few ideas from my side though,
From Kernel side: introduce nvmem_lock()/nvmem_unlock() apis which
would set the ranges as required, and the providers can use regmap
callbacks writeable_reg()/readable_reg() in regmap configs to enforce
the lock range
From userspace side, As of today nvmem only provides an binary file
interface, which we could probably extend to device based and provide
userspace abi.
Lets continue discussion !!
--srini
>>
>> Arnd
>>
> Regards,
> Scott
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding OTP-only device to MTD or CHAR subsystem?
2016-01-09 11:13 ` Srinivas Kandagatla
@ 2016-01-13 22:05 ` Scott Branden
0 siblings, 0 replies; 5+ messages in thread
From: Scott Branden @ 2016-01-13 22:05 UTC (permalink / raw)
To: Srinivas Kandagatla, Arnd Bergmann, Maxime Ripard
Cc: Greg Kroah-Hartman, Brian Norris, linux-kernel, linux-mtd
Hi Srini,
On 16-01-09 03:13 AM, Srinivas Kandagatla wrote:
> Hi Scott,
>
> Sorry for long delay in replying.. :-)
> On 29/12/15 00:32, Scott Branden wrote:
>> +Srinivas/Maxime
>>
>> On 15-12-28 03:38 PM, Arnd Bergmann wrote:
>>> On Monday 28 December 2015 15:21:08 Scott Branden wrote:
>>>> Greg/Brian/Arnd,
>>>>
>>>> We have OTP device drivers for accessing OTP memory in our SoCs.
>>>>
>>>> I looking for the right place and model to place such OTP device
>>>> drivers.
>>>>
>>>> 1) Should we follow the bfin-otp model in drivers/char? This doesn't
>>>> seem like the right place to put it although following the bfin example
>>>> is quite simple to implement. We actually had a custom set of Ioctl's
>>>> that I changed to use the standard file access model used by the bfin
>>>> driver. But a custom util is still needed to issue an OTPLOCK command.
>>>> I'm guess mtd-utils has such abilities (or should).
>>>>
>>>> 2) Instead, should we start adding OTP-only drivers into the MTD
>>>> subsystem? Onenand and CFI based MTD devices already have OTP
>>>> programmable regions. If we created a new OTP device type in the MTD
>>>> subsystem this looks like a good thing to do. mtd-utils
>>>> could/should be
>>>> used to access the OTP device then along with standard fileio
>>>> operations.
>>>>
>>>> 3) Or some other suggestion of where to place OTP device drivers?
>>>
>>> I think drivers/nvmem is now the right place for this.
>> Thanks for the pointer Arnd. Too bad an extension wasn't added in MTD
>> but at least there is some sort of a model in place now. The mtd-abi.h
>> would have been a good thing to use for OTPLOCK as well as the remainder
>> of the functionality in MTD OTP. The mapping of nvmem to properties to
>> user settings seems like a useful feature though.
>>
>> Hi Srinivas/Maxime,
>> The nvmem drivers don't seem to support row unlocking of OTP. Having
>> raw write access to the OTP is not a desirable feature. Are there plans
>> in place to add any additional functionality to the nvm driver model
>> right now?
> NVMEM was started to be simple interface based on regmap, As of today we
> did not have any users which wanted lock feature, but Am open for more
> discussion on this if we want to get this feature via nvmem.
>
> Any ideas and patches are welcome.
Yes, as I move to the nvmem model we will need to look at adding lock
feature.
>
> Few ideas from my side though,
> From Kernel side: introduce nvmem_lock()/nvmem_unlock() apis which
> would set the ranges as required, and the providers can use regmap
> callbacks writeable_reg()/readable_reg() in regmap configs to enforce
> the lock range
The bfin-otp in drivers/char already solves this problem and I think we
should move that functionality over?
>
> From userspace side, As of today nvmem only provides an binary file
> interface, which we could probably extend to device based and provide
> userspace abi.
The bfin-otp in drivers/char already solves this problem and I think we
should move that functionality over?
>
> Lets continue discussion !!
>
> --srini
>
>
>
>>>
>>> Arnd
>>>
>> Regards,
>> Scott
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-01-13 22:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-28 23:21 Adding OTP-only device to MTD or CHAR subsystem? Scott Branden
2015-12-28 23:38 ` Arnd Bergmann
2015-12-29 0:32 ` Scott Branden
2016-01-09 11:13 ` Srinivas Kandagatla
2016-01-13 22:05 ` Scott Branden
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).