Re: Adding OTP-only device to MTD or CHAR subsystem?

[Scott Branden]

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