From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Rafał Miłecki" <rafal@milecki.pl>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Michael Walle <michael@walle.cc>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Robert Marko <robert.marko@sartura.hr>,
Luka Perkov <luka.perkov@sartura.hr>,
linux-kernel@vger.kernel.org,
Randy Dunlap <rdunlap@infradead.org>,
Chen-Yu Tsai <wenst@chromium.org>,
Daniel Golle <daniel@makrotopia.org>
Subject: Re: [PATCH v10 3/3] nvmem: core: Expose cells through sysfs
Date: Sun, 1 Oct 2023 17:59:42 +0200 [thread overview]
Message-ID: <20231001175942.749d9bb3@xps-13> (raw)
In-Reply-To: <5f1221613fb71b87c01c82add9fe5097@milecki.pl>
Hi Rafał,
rafal@milecki.pl wrote on Fri, 29 Sep 2023 07:18:32 +0200:
> On 2023-09-28 17:31, Rafał Miłecki wrote:
> > On 2023-09-22 19:48, Miquel Raynal wrote:
> >> The binary content of nvmem devices is available to the user so in the
> >> easiest cases, finding the content of a cell is rather easy as it is
> >> just a matter of looking at a known and fixed offset. However, nvmem
> >> layouts have been recently introduced to cope with more advanced
> >> situations, where the offset and size of the cells is not known in
> >> advance or is dynamic. When using layouts, more advanced parsers are
> >> used by the kernel in order to give direct access to the content of >> each
> >> cell, regardless of its position/size in the underlying
> >> device. Unfortunately, these information are not accessible by users,
> >> unless by fully re-implementing the parser logic in userland.
> >> >> Let's expose the cells and their content through sysfs to avoid these
> >> situations. Of course the relevant NVMEM sysfs Kconfig option must be
> >> enabled for this support to be available.
> >> >> Not all nvmem devices expose cells. Indeed, the .bin_attrs attribute
> >> group member will be filled at runtime only when relevant and will
> >> remain empty otherwise. In this case, as the cells attribute group >> will
> >> be empty, it will not lead to any additional folder/file creation.
> >> >> Exposed cells are read-only. There is, in practice, everything in the
> >> core to support a write path, but as I don't see any need for that, I
> >> prefer to keep the interface simple (and probably safer). The >> interface
> >> is documented as being in the "testing" state which means we can later
> >> add a write attribute if though relevant.
> >> >> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >
> > Tested-by: Rafał Miłecki <rafal@milecki.pl>
> >
> > # hexdump -C /sys/bus/nvmem/devices/u-boot-env0/cells/ipaddr@15c
> > 00000000 31 39 32 2e 31 36 38 2e 31 2e 31 > |192.168.1.1|
> > 0000000b
>
> The same test after converting U-Boot env into layout driver:
>
> # hexdump -C /sys/bus/nvmem/devices/mtd1/cells/ipaddr@15c
> 00000000 31 39 32 2e 31 36 38 2e 31 2e 31 |192.168.1.1|
> 0000000b
>
> Looks good!
>
Great! Thanks a lot for testing!
Miquèl
prev parent reply other threads:[~2023-10-01 15:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 17:48 [PATCH v10 0/3] NVMEM cells in sysfs Miquel Raynal
2023-09-22 17:48 ` [PATCH v10 1/3] nvmem: core: Rework layouts to become platform devices Miquel Raynal
2023-09-28 20:24 ` Rafał Miłecki
2023-10-02 9:23 ` Srinivas Kandagatla
2023-10-03 9:43 ` Miquel Raynal
2023-10-05 14:58 ` Miquel Raynal
2023-10-02 9:35 ` Greg Kroah-Hartman
2023-10-02 15:16 ` Miquel Raynal
2023-09-22 17:48 ` [PATCH v10 2/3] ABI: sysfs-nvmem-cells: Expose cells through sysfs Miquel Raynal
2023-09-22 17:48 ` [PATCH v10 3/3] nvmem: core: " Miquel Raynal
2023-09-28 15:31 ` Rafał Miłecki
2023-09-29 5:18 ` Rafał Miłecki
2023-10-01 15:59 ` Miquel Raynal [this message]
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=20231001175942.749d9bb3@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=daniel@makrotopia.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luka.perkov@sartura.hr \
--cc=michael@walle.cc \
--cc=rafal@milecki.pl \
--cc=rdunlap@infradead.org \
--cc=robert.marko@sartura.hr \
--cc=srinivas.kandagatla@linaro.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wenst@chromium.org \
/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.