linux-kernel - Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Jun 2015 13:52:28 +0200
From:	Stefan Wahren <stefan.wahren@...e.com>
To:	maitysanchayan@...il.com
CC:	srinivas.kandagatla@...aro.org, maxime.ripard@...e-electrons.com,
	linux-arm-kernel@...ts.infradead.org, stefan@...er.ch,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	shawn.guo@...aro.org, arnd@...db.de
Subject: Re: [RFC PATCH v6 2/2] nvmem: Add Vybrid OCOTP and OCROM support

Hi Srinivas,

Am 24.06.2015 um 12:45 schrieb maitysanchayan@...il.com:
> Hello Stefan,
>
> On 15-06-24 11:56:14, Stefan Wahren wrote:
>> Hi Sanchayan,
>>
>> Am 24.06.2015 um 07:19 schrieb maitysanchayan@...il.com:
>>> On 15-06-23 21:31:41, Stefan Wahren wrote:
>>>> Hi Sanchayan,
>>>>
>>>>> Sanchayan Maity <maitysanchayan@...il.com> hat am 23. Juni 2015 um 15:44
>>>>> geschrieben:
>>>>>
>>>>>
>>>>> The patch adds support for the On Chip One Time Programmable Peripheral
>>>>> (OCOTP) and On Chip ROM (OCROM) support.
>>>>>
>>>>> On Vybrid OCOTP contain data like SoC ID, MAC address and OCROM has the
>>>>> revision ID.
>>>>>
>>>>> Signed-off-by: Sanchayan Maity <maitysanchayan@...il.com>
>>>>> ---
>>>>> drivers/nvmem/Kconfig | 11 +++++++++
>>>>> drivers/nvmem/Makefile | 2 ++
>>>>> drivers/nvmem/vf610-ocotp.c | 60 +++++++++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 73 insertions(+)
>>>>> create mode 100644 drivers/nvmem/vf610-ocotp.c
>>>>>
>>>>> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
>>>>> index 17f1a57..557c1e0 100644
>>>>> --- a/drivers/nvmem/Kconfig
>>>>> +++ b/drivers/nvmem/Kconfig
>>>>> @@ -33,4 +33,15 @@ config NVMEM_SUNXI_SID
>>>>> This driver can also be built as a module. If so, the module
>>>>> will be called eeprom-sunxi-sid.
>>>>>
>>>>> +config NVMEM_VF610_OCOTP
>>>>> + tristate "VF610 SoCs OCOTP support"
>>>>> + depends on SOC_VF610
>>>>> + select REGMAP_MMIO
>>>> how do you come to the conclusion that Vybrid On-Chip OTP is accessable via
>>>> MMIO?
>>> Frankly speaking I just changed the naming conventions and followed the qfrom
>>> and sunxi sid examples in Srinivas's patches.
>>>
>>> I just tested it without the "select REGMAP_MMIO" and it works just fine.
>>>
>>> - Sanchayan.
>> sorry for the confusion. My question refers to the whole driver
>> implementation not only to the REGMAP_MMIO.
>>
>> According to
>>
>> Vybrid Reference Manual F-Series
>> Document Number: VYBRIDRM
>> Rev 7, 06/2014
>>
>> 35.5 OCOTP memory map/register definition
>>
>> the memory region is organized in control and shadow registers. I'm very
>> sceptical that using REGMAP_MMIO is the right way for accessing the OCOTP.
> Sorry I am not well versed with the regmap stuff. Can you please tell me why
> REGMAP_MMIO is not the right way for accessing the OCOTP?

i think the implementation of OCOTP driver should be more like this:

https://git.linaro.org/people/srinivas.kandagatla/linux.git/commit/b4c3ad253747767511233687436f20144e850d67

It uses REGMAP with a specialized read function.

>
> If this is not the right way, I assume you are referring to the procedures
> in section 35.3.1.5 and 35.3.1.6 for reading and writing from these areas?

Yes. I think writing isn't needed. But the read function should check
at least for OCOTP_CTRL[BUSY] and OCOTP_CTRL[ERROR]. If one of the
bits is set, the read function should return with an error.

This is the same behavior of my OCOTP driver for MXS platform.

Unfortunately i haven't push the driver to my github account.

>> It possible that it works in your case. But in the case the lock bits
>> are set the driver won't work correctly.
> As such the previous implementations were very different.
>
> Currently I only expect to provide a way for users to read the SoC ID from
> the OCOTP block. My understanding was even if the lock bits are set, reading
> from the registers will return 0xBADABADA.
>
> For example, currently for three locations I see this from ocotp block
>
> *
> 0000080 bada bada bada bada bada bada bada bada
> *
> 0000500 bada bada bada bada bada bada bada bada
> *
> 0000c80 bada bada bada bada bada bada bada bada
> *
>
> - Sanchayan.

Until somebody comes to the idea to fetch the MAC address from the OCOTP
block ...

How about doing it right at this point, instead of fixing it later?

Stefan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/