From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Marco Felsch <m.felsch@pengutronix.de>
Cc: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Michael Walle" <michael@walle.cc>,
"Rafał Miłecki" <rafal@milecki.pl>,
"Rob Herring" <robh+dt@kernel.org>,
"Frank Rowand" <frowand.list@gmail.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"Robert Marko" <robert.marko@sartura.hr>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Luka Perkov" <luka.perkov@sartura.hr>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Chen-Yu Tsai" <wenst@chromium.org>,
"Daniel Golle" <daniel@makrotopia.org>,
kernel@pengutronix.de
Subject: Re: [PATCH v13 4/6] nvmem: core: Rework layouts to become regular devices
Date: Fri, 24 Nov 2023 20:21:36 +0100 [thread overview]
Message-ID: <20231124202136.799db18b@xps-13> (raw)
In-Reply-To: <20231122220240.4jg245vblnh6d5zy@pengutronix.de>
Hi Marco,
m.felsch@pengutronix.de wrote on Wed, 22 Nov 2023 23:02:40 +0100:
> Hi Miquel,
>
> thanks a lot for your effort on this. Please see my comments inline.
Thanks for your interesting feedback! I do agree with most of your
comments and will correct them for the next version.
> > +static int onie_tlv_probe(struct nvmem_layout *layout)
> > +{
> > + layout->add_cells = onie_tlv_parse_table;
>
> Nit: the add cells could be done here as well, same for the other
> layout. Would save us one indirection.
I prefer all the handling of the cells to be done in a generic place
like the core. In fact patch 5 adds something to this indirection.
...
> > /**
> > * struct nvmem_layout - NVMEM layout definitions
> > *
> > - * @name: Layout name.
> > - * @of_match_table: Open firmware match table.
> > + * @dev: Device-model layout device.
> > + * @nvmem: The underlying NVMEM device
> > * @add_cells: Will be called if a nvmem device is found which
> > * has this layout. The function will add layout
> > * specific cells with nvmem_add_one_cell().
> > * @fixup_cell_info: Will be called before a cell is added. Can be
> > * used to modify the nvmem_cell_info.
> > - * @owner: Pointer to struct module.
> > - * @node: List node.
> > *
> > * A nvmem device can hold a well defined structure which can just be
> > * evaluated during runtime. For example a TLV list, or a list of "name=val"
> > @@ -170,17 +169,19 @@ struct nvmem_cell_table {
> > * cells.
> > */
> > struct nvmem_layout {
>
> Since this became a device now should we refelct this within the struct
> name, e.g. nvmem_layout_dev, nvmem_ldev, nvm_ldev?
I'd say it is a matter of taste, in general I don't like much the _dev
suffix. We handle nvmem layout drivers and nvmem layouts, like we
have joystick drivers and joysticks, I don't feel the need to suffix
them. I would not oppose if someone would rename this structure though.
> Regards,
> Marco
>
I'm fine with all your other comments and will make my best to address
them.
Thanks,
Miquèl
next prev parent reply other threads:[~2023-11-24 19:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-11 11:15 [PATCH v13 0/6] NVMEM cells in sysfs Miquel Raynal
2023-10-11 11:15 ` [PATCH v13 1/6] of: device: Export of_device_make_bus_id() Miquel Raynal
2023-10-11 11:15 ` [PATCH v13 2/6] nvmem: Move of_nvmem_layout_get_container() in another header Miquel Raynal
2023-10-12 12:36 ` kernel test robot
2023-10-11 11:15 ` [PATCH v13 3/6] nvmem: Create a header for internal sharing Miquel Raynal
2023-10-11 11:15 ` [PATCH v13 4/6] nvmem: core: Rework layouts to become regular devices Miquel Raynal
2023-10-12 16:10 ` kernel test robot
2023-11-22 22:02 ` Marco Felsch
2023-11-22 22:45 ` Marco Felsch
2023-11-24 19:25 ` Miquel Raynal
2023-11-24 19:21 ` Miquel Raynal [this message]
2023-10-11 11:15 ` [PATCH v13 5/6] ABI: sysfs-nvmem-cells: Expose cells through sysfs Miquel Raynal
2023-10-11 11:15 ` [PATCH v13 6/6] nvmem: core: " 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=20231124202136.799db18b@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=daniel@makrotopia.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=luka.perkov@sartura.hr \
--cc=m.felsch@pengutronix.de \
--cc=michael@walle.cc \
--cc=rafal@milecki.pl \
--cc=rdunlap@infradead.org \
--cc=robert.marko@sartura.hr \
--cc=robh+dt@kernel.org \
--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.