Messages in this thread | | | Subject | Re: Questions about NVMEM | From | Srinivas Kandagatla <> | Date | Mon, 11 Sep 2017 10:38:25 +0100 |
| |
On 11/09/17 05:44, Masahiro Yamada wrote: > 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?
That is 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. > I agree.
> > > (C) looks reasonable because nvmem_config is pretty small. > (sizeof(struct nvmem_config) = 104 byte on 64bit systems) > Yep, thats much better indeed!
> 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...
You can mark particular instance of provider as read-only which could be specific to board.
reg_write callbacks can be implemented by provider driver, but read-only flag would give the flexibility at board level.
> > > > > > (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. This is mainly done for consistent module naming. I prefer to have nvmem- prefix for nvmem modules.
thanks, srini > > > > >
| |