Message-ID: <5696CA42.1020903@broadcom.com>
Date:	Wed, 13 Jan 2016 14:05:54 -0800
From:	Scott Branden <sbranden@...adcom.com>
To:	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Brian Norris <computersforpeace@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>
Subject: Re: Adding OTP-only device to MTD or CHAR subsystem?

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
>

Powered by blists - more mailing lists