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: <771a6f0a-3cc2-da20-2439-9a91dd2bf9d2@linaro.org>
Date:   Tue, 6 Aug 2019 11:05:46 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Jose Diaz de Grenu <Jose.DiazdeGrenu@...i.com>
Cc:     shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
        festevam@...il.com, linux-imx@....com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] nvmem: imx-ocotp: allow reads with arbitrary size and
 offset



On 23/07/2019 16:32, Jose Diaz de Grenu wrote:
> Currently the imx-ocotp driver does only allow reading complete OTP words
> correcty aligned.
> 
> Usually OTP memory is limited, so the fields are stored using as few bits as
> possible. This means that a given value rarely uses 32 bits and happens to be
> aligned.
> 
> Even though the NVMEM API offers a way to define offset and size of each cell
> (at bit level) this is not currently usable iwth the imx-ocotp driver, which
> forces consumers to read complete words and then hardcode the necessary
> shifting and masking in the driver code.
> 
> As an example take the nvmem consumer imx_thermal.c, which reads nvmem cells
> as uint32_t words:
> 
> 	ret = nvmem_cell_read_u32(&pdev->dev, "calib", &val);
> 	if (ret)
> 		return ret;
> 
> 	ret = imx_init_calib(pdev, val);
> 	if (ret)
> 		return ret;
> 
> 	ret = nvmem_cell_read_u32(&pdev->dev, "temp_grade", &val);
> 	if (ret)
> 		return ret;
> 	imx_init_temp_grade(pdev, val);
> 	
> but needs to later adjust the values in code:
> 
> 	// Inside imx_init_calib()
> 	data->c1 = (ocotp_ana1 >> 9) & 0x1ff;
> 
> 	// Inside imx_init_temp_grade()
> 	switch ((ocotp_mem0 >> 6) & 0x3) {
> 	
> This patch adjusts the driver so that reads can be requested using any size
> and offset. Then, for example the nvmem cell "calib" could use the 'bits'
> property to specify size and offset in bits, removing the need to mask and
> shift in the driver code.
> 
> This is specially useful when several drivers use the same nvmem cell and when
> the specific size and offset of a OTP value depends on a hardware version.
> 
> Jose Diaz de Grenu (2):
>    nvmem: imx-ocotp: use constant for write restriction
>    nvmem: imx-ocotp: allow reads with arbitrary size and offset
> 
>   drivers/nvmem/imx-ocotp.c | 34 ++++++++++++++++------------------
>   1 file changed, 16 insertions(+), 18 deletions(-)

Anyone form IMX can test this patchset before I push this out?

Thanks,
srini
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ