From: Michael Walle <michael@walle.cc>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Shawn Guo" <shawnguo@kernel.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB arguments
Date: Mon, 28 Nov 2022 08:35:24 +0100 [thread overview]
Message-ID: <f2bb569404903bc937fbe3840582f3c4@walle.cc> (raw)
In-Reply-To: <20221128065923.1180-1-zajec5@gmail.com>
Am 2022-11-28 07:59, schrieb Rafał Miłecki:
> From: Rafał Miłecki <rafal@milecki.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@milecki.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
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <michael@walle.cc>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Shawn Guo" <shawnguo@kernel.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB arguments
Date: Mon, 28 Nov 2022 08:35:24 +0100 [thread overview]
Message-ID: <f2bb569404903bc937fbe3840582f3c4@walle.cc> (raw)
In-Reply-To: <20221128065923.1180-1-zajec5@gmail.com>
Am 2022-11-28 07:59, schrieb Rafał Miłecki:
> From: Rafał Miłecki <rafal@milecki.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@milecki.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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <michael@walle.cc>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Miquel Raynal" <miquel.raynal@bootlin.com>,
"Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Shawn Guo" <shawnguo@kernel.org>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, u-boot@lists.denx.de,
"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB arguments
Date: Mon, 28 Nov 2022 08:35:24 +0100 [thread overview]
Message-ID: <f2bb569404903bc937fbe3840582f3c4@walle.cc> (raw)
In-Reply-To: <20221128065923.1180-1-zajec5@gmail.com>
Am 2022-11-28 07:59, schrieb Rafał Miłecki:
> From: Rafał Miłecki <rafal@milecki.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@milecki.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
next prev parent reply other threads:[~2022-11-28 7:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 6:59 [PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB arguments Rafał Miłecki
2022-11-28 6:59 ` Rafał Miłecki
2022-11-28 6:59 ` Rafał Miłecki
2022-11-28 6:59 ` [PATCH V2 2/2] nvmem: u-boot-env: reformat MAC in "ethaddr" cell when reading Rafał Miłecki
2022-11-28 6:59 ` Rafał Miłecki
2022-11-28 6:59 ` Rafał Miłecki
2022-11-28 7:35 ` Michael Walle [this message]
2022-11-28 7:35 ` [PATCH V2 1/2] nvmem: core: refactor .cell_post_process() CB arguments Michael Walle
2022-11-28 7:35 ` Michael Walle
2022-11-28 8:30 ` Miquel Raynal
2022-11-28 8:30 ` Miquel Raynal
2022-11-28 8:30 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2bb569404903bc937fbe3840582f3c4@walle.cc \
--to=michael@walle.cc \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=shawnguo@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=u-boot@lists.denx.de \
--cc=vigneshr@ti.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.