linux-kernel - Questions about NVMEM

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 11 Sep 2017 13:44:21 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Jassi Brar <jaswinder.singh@...aro.org>,
        Keiji Hayashibara <hayashibara.keiji@...ionext.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew-CT Chen <andrew-ct.chen@...iatek.com>,
        Carlo Caione <carlo@...lessm.com>,
        Michael Grzeschik <m.grzeschik@...gutronix.de>
Subject: Questions about NVMEM

Hi Srinivas,

I have 3 questions about the nvmem sybsystem.

Please correct me if something is missing from my thought.

(Q1) How to allocate struct nvmem_config?

I see 3 ways in allocating struct nvmem_config.
What is a good / bad practice?

   (A)  Allocate statically in .data section

            bcm-ocotp.c
            imx-ocotp.c
            lpc18xx_eeprom.c
            lpc18xx_otp.c
            mxs-octop.c
            qfprom.c
            rockchip-efuse.c
            sunxi_sid
            vf610-ocotp.c
            meson-efuse.c

   (B) devm_kzalloc()

           imx-iim.c
           mtk-efuse.c
           drivers/misc/eeprom/at24.c

   (C) Stack

           drivers/thunderbolt/switch.c

I think (A) is safe only when we know the system has
just one instance of the device.
(A) should not be used if two or more instances exist.
Is this correct?

I think (B) is wasting memory because nvmem_register()
copies all members of nvmem_config to nvmem_device.
nvmem_config is never dereferenced after nvmem_register() finished.
I do not see much sense to keep it until the driver is detached.

(C) looks reasonable because nvmem_config is pretty small.
(sizeof(struct nvmem_config) = 104 byte on 64bit systems)

Several subsystems receive configuration data from stack,
for example,

   "struct clk_init_data" in clk drivers,
   "struct uart_8250_port" in 8250 serial drivers.

sizeof(struct uart_8250_port) = 528 byte,
but it is still working in stack.

(Q2) Is nvmem_config::read_only necessary?

If .reg_write() callback is set, it is probably writable.
If .reg_write() is missing, it must be read-only.

I have no idea when nvmem_config::read_only is useful...

(Q3) The style of  drivers/nvmem/Makefile

This Makefile looks ugly to me.
All nvmem drivers are just single file modules.
Why are they renamed when modules are created?

For the name-space reason for modules,
prefix "nvmem-" makes sense to me.

It is true that adding "nvmem-" prefix is redundant while
they are located in drivers/nvmem/ directory,
but renaming in the Makefile is even more annoying to me.
Having said that, we may not want to churn this.

-- 
Best Regards
Masahiro Yamada