lkml.org 
[lkml]   [2022]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v1 00/14] nvmem: core: introduce NVMEM layouts
From
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

\
 
 \ /
  Last update: 2022-08-30 15:38    [W:0.078 / U:5.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site