Skip to contentSkip to conversation

Adding OTP-only device to MTD or CHAR subsystem?

DISCUSSION Scott Branden 3 participants 5 messages Dec 28, 2015 – Jan 13, 2016 Memory technology devices (MTD)

lore
Share & tools
lore

Scott Branden

author
#0 lore raw

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

#1 lore raw
Quoted 13 lines · 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).

Quoted 7 lines

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

author
#2 lore raw

+Srinivas/Maxime

Quoted 20 lines · Arnd Bergmann
Quoted 19 lines · 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.

Quoted 3 lines
Quoted 1 line

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?

Quoted 3 lines

Arnd

Regards,
Scott

#3 lore raw

Hi Scott,

Sorry for long delay in replying.. :-)

Quoted 34 lines · Scott Branden

+Srinivas/Maxime

Quoted 22 lines · Arnd Bergmann
Quoted 21 lines · 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.

Quoted 3 lines
Quoted 1 line

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.

Quoted 5 lines

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

Quoted 5 lines
Quoted 3 lines

Arnd

Regards,
Scott

author
#4 lore raw

Hi Srini,

Quoted 44 lines · Srinivas Kandagatla

Hi Scott,

Sorry for long delay in replying.. :-)

Quoted 35 lines · Scott Branden

+Srinivas/Maxime

Quoted 23 lines · Arnd Bergmann
Quoted 22 lines · 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.

Quoted 3 lines
Quoted 1 line

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.

Quoted 5 lines

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?

Quoted 5 lines

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.

Quoted 6 lines

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?

Quoted 4 lines

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?

Quoted 13 lines

Lets continue discussion !!

--srini

Quoted 5 lines
Quoted 3 lines

Arnd

Regards,
Scott