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]

Message-ID: <20150624120500.GB32208@Sanchayan-Arch.toradex.int>
Date:	Wed, 24 Jun 2015 17:35:00 +0530
From:	maitysanchayan@...il.com
To:	Stefan Wahren <stefan.wahren@...e.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

Hello Stefan,

On 15-06-24 13:52:28, Stefan Wahren wrote:
> 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.

Thank you very much for the link.

> 
> >
> > 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.

Understood. Will incoporate this in the v6 patch.

> 
> 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?

Of course. Thanks for the feedback Stefan.

- Sanchayan.
--
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/