Questions about NVMEM

From: Masahiro Yamada
Date: Mon Sep 11 2017 - 00:45:16 EST


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