From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Luka Perkov <luka.perkov@sartura.hr>,
Robert Marko <robert.marko@sartura.hr>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] nvmem: core: Expose cells through sysfs
Date: Mon, 29 May 2023 12:12:26 +0200 [thread overview]
Message-ID: <20230529121226.4a74a3bb@xps-13> (raw)
In-Reply-To: <20230523191402.0728443a@xps-13>
Hi Greg,
miquel.raynal@bootlin.com wrote on Tue, 23 May 2023 19:14:02 +0200:
> Hi Greg,
>
> gregkh@linuxfoundation.org wrote on Tue, 23 May 2023 17:58:51 +0100:
>
> > On Tue, May 23, 2023 at 12:02:39PM +0200, Miquel Raynal wrote:
> > > +/* Cell attributes will be dynamically allocated */
> > > +static struct attribute_group nvmem_cells_group = {
> > > + .name = "cells",
> > > +};
> > > +
> > > static const struct attribute_group *nvmem_dev_groups[] = {
> > > &nvmem_bin_group,
> > > + NULL, /* Reserved for exposing cells, if any */
> >
> > Please don't do this, but rather use the is_visible callback to
> > determine if it should be shown or not.
>
> Ah, excellent point. Don't know why I overlooked that member.
Actually, the .is_visible callback only acts on the files and
not the directories (created based on the group name). This
means whether they are visible or not, the attributes must be
valid, the nvmem core cannot just toggle a boolean value with
.is_visible because the sysfs core makes a number of checks
regarding the content of the attributes, without checking if
they are visible at all.
I can however expose the "cells" bin group by default by having
it listed in the static bin_attribute list and discard it by
overwriting the list member with NULL (ie. the opposite of the current
solution). This implies two things: I need to provide an empty list of
files (otherwise the core warns) and if no list is provided then the
"cells" folder will always appear, no matter if there are cells or not
exposed by this nvmem device. So the folder can be empty.
If this is fine, I can:
* Expose the "cells" bin group,
* Provide an empty .bin_attrs list (otherwise I get a complain from
the sysfs core when the nvmem device does not expose any cell)
* Overwrite the dummy .bin_attrs member when the device expose cells,
keep it empty otherwise.
Otherwise if we prefer avoiding empty folders, I can as well hide the
"cells" bin group by writing NULL to the relevant member of the
attribute_group list.
Let me know what is your preference.
Thanks,
Miquèl
next prev parent reply other threads:[~2023-05-29 10:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 10:02 [PATCH 0/2] NVMEM cells in sysfs Miquel Raynal
2023-05-23 10:02 ` [PATCH 1/2] ABI: sysfs-nvmem-cells: Expose cells through sysfs Miquel Raynal
2023-05-23 16:59 ` Greg Kroah-Hartman
2023-05-23 17:14 ` Miquel Raynal
2023-05-23 10:02 ` [PATCH 2/2] nvmem: core: " Miquel Raynal
2023-05-23 16:58 ` Greg Kroah-Hartman
2023-05-23 17:14 ` Miquel Raynal
2023-05-29 10:12 ` Miquel Raynal [this message]
2023-05-29 13:05 ` Greg Kroah-Hartman
2023-05-29 13:35 ` Miquel Raynal
2023-05-29 13:43 ` Greg Kroah-Hartman
2023-05-29 14:00 ` Miquel Raynal
2023-05-23 23:51 ` kernel test robot
2023-05-29 4:28 ` Dan Carpenter
2023-05-29 10:14 ` 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=20230529121226.4a74a3bb@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luka.perkov@sartura.hr \
--cc=robert.marko@sartura.hr \
--cc=srinivas.kandagatla@linaro.org \
--cc=thomas.petazzoni@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox