All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <rafal@milecki.pl>
To: Miquel Raynal <miquel.raynal@bootlin.com>
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: Fri, 29 Sep 2023 07:18:32 +0200	[thread overview]
Message-ID: <5f1221613fb71b87c01c82add9fe5097@milecki.pl> (raw)
In-Reply-To: <1a27a3341379b9679174f7c5143bbeb3@milecki.pl>

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!

-- 
Rafał Miłecki

  reply	other threads:[~2023-09-29  5:55 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 [this message]
2023-10-01 15:59       ` 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=5f1221613fb71b87c01c82add9fe5097@milecki.pl \
    --to=rafal@milecki.pl \
    --cc=daniel@makrotopia.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luka.perkov@sartura.hr \
    --cc=michael@walle.cc \
    --cc=miquel.raynal@bootlin.com \
    --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.