Messages in this thread | | | Date | Tue, 30 Aug 2022 14:37:41 +0100 | Subject | Re: [PATCH v1 00/14] nvmem: core: introduce NVMEM layouts | From | Srinivas Kandagatla <> |
| |
Thanks Michael for the work.
On 29/08/2022 09:22, Michael Walle wrote: > >> One thing I believe you need to handle is replacing "cell_post_process" >> callback with your layout thing. >> >> I find it confusing to have >> 1. cell_post_process() CB at NVMEM device level >> 2. post_process() CB at NVMEM cell level > > What is wrong with having a callback at both levels?
we should converge this tbh, its more than one code paths to deal with similar usecases.
I have put down some thoughts in "[PATCH v1 06/14] nvmem: core: introduce NVMEM layouts" and "[PATCH v1 07/14] nvmem: core: add per-cell post processing" review.
--srini > > Granted, in this particular case (it is just used at one place), I still > think that it is the wrong approach to add this transformation in the > driver (in this particular case). The driver is supposed to give you > access to the SoC's fuse box, but it will magically change the content > of a cell if the nvmem consumer named this cell "mac-address" (which > you also found confusing the last time and I do too!). > > The driver itself doesn't add any cells on its own, so I cannot register > a .post_process hook there. Therefore, you'd need that post_process hook > on every cell, which is equivalent to have a post_process hook at > device level. > > Unless you have a better idea. I'll leave that up to NXP to fix that (or > leave it like that). > > -michael
| |