[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2bb569404903bc937fbe3840582f3c4@walle.cc>
Date: Mon, 28 Nov 2022 08:35:24 +0100
From: Michael Walle <michael@...le.cc>
To: Rafał Miłecki <zajec5@...il.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Shawn Guo <shawnguo@...nel.org>, linux-mtd@...ts.infradead.org,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, u-boot@...ts.denx.de,
Rafał Miłecki
<rafal@...ecki.pl>
Subject: Re: [PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB
arguments
Am 2022-11-28 07:59, schrieb Rafał Miłecki:
> From: Rafał Miłecki <rafal@...ecki.pl>
>
> Pass whole NVMEM cell struct and length pointer as arguments to
> callback
> functions.
>
> This allows:
>
> 1. Cells content to be modified based on more info
> Some cells (identified by their names) contain specific data that
> needs further processing. This can be e.g. MAC address stored in an
> ASCII format. NVMEM consumers expect MAC to be read in a binary
> form.
> More complex cells may be additionally described in DT. This change
> allows also accessing relevant DT nodes and reading extra info.
>
> 2. Adjusting data length
> If cell processing results in reformatting it, it's required to
> adjust length. This again applies e.g. to the MAC format change from
> ASCII to the byte-based.
>
> Later on we may consider more cleanups & features like:
> 1. Dropping "const char *id" and just using NVMEM cell name
> 2. Adding extra argument for cells providing multiple values
>
> Signed-off-by: Rafał Miłecki <rafal@...ecki.pl>
> ---
> This solution conflicts with 1 part of Michael's work:
> [PATCH v2 00/20] nvmem: core: introduce NVMEM layouts
> https://lore.kernel.org/linux-arm-kernel/20220901221857.2600340-1-michael@walle.cc/
>
> Instead of:
> 1. Adding NVMEM cell-level post_process callback
> 2. Adding callback (.fixup_cell_info()) for setting callbacks
> 3. Dropping NVMEM device-level post_process callback
> I decided to refactor existing callback.
>
> Michael's work on adding #nvmem-cell-cells should be possible to easily
> rebase on top of those changes.
As yours should be easily added on top of my series. I've showed that
providing a global post process hook is bad because that way you need
to have *all* cells of your device read-only.
-michael
Powered by blists - more mailing lists