From: Joel Becker <jlbec@evilplan.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Christoph Hellwig <hch@lst.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Kent Gibson <warthog618@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [RESEND PATCH v3 0/4] configfs: implement committable items and add sample code
Date: Wed, 13 Jan 2021 15:49:33 -0800 [thread overview]
Message-ID: <X/+HDQBc1dx9Ipdm@google.com> (raw)
In-Reply-To: <CAMRc=MdpYinY1zobG7e9Ds7KdX5-S5hVzHv8ZsShuPqK__QcAQ@mail.gmail.com>
On Mon, Jan 11, 2021 at 09:32:14AM +0100, Bartosz Golaszewski wrote:
> On Tue, Dec 29, 2020 at 11:22 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > Committable items in configfs are well defined and documented but unfortunately
> > so far never implemented.
> >
> > The use-case we have over at the GPIO subsystem is using configfs in
> > conjunction with sysfs to replace our current gpio-mockup testing module
> > with one that will be much more flexible and will allow complete coverage
> > of the GPIO uAPI.
> >
> > The current gpio-mockup module is controlled using module parameters which
> > forces the user to reload it everytime they need to change the chip
> > configuration or layout and makes it difficult to extend its functionality.
> >
> > Testing module based on configfs would allow fine-grained control over dummy
> > GPIO chips but since GPIO devices must be configured before they are
> > instantiated, we need committable items.
> >
> > This implements them and adds code examples to configfs_sample module. The
> > first two patches are just cosmetic.
> >
> > v1 -> v2:
> > - fix a 'set but not used' build warning reported by kernel test robot
> >
> > v2 -> v3:
> > - use (1UL << bit) instead of BIT() in patch 2/4
> > - extend configfs_dump_one() to make it print the new flags
> > - clear the CONFIGFS_USET_DIR bit on the live group dirent
> >
> > Rebased on top of v5.11-rc1.
> >
> > Bartosz Golaszewski (4):
> > configfs: increase the item name length
> > configfs: use (1UL << bit) for internal flags
> > configfs: implement committable items
> > samples: configfs: add a committable group
> >
> > Documentation/filesystems/configfs.rst | 6 +-
> > fs/configfs/configfs_internal.h | 22 +--
> > fs/configfs/dir.c | 240 ++++++++++++++++++++++++-
> > fs/configfs/file.c | 8 +
> > include/linux/configfs.h | 3 +-
> > samples/configfs/configfs_sample.c | 150 ++++++++++++++++
> > 6 files changed, 409 insertions(+), 20 deletions(-)
> >
> > --
> > 2.29.1
> >
>
> Joel, Christoph,
>
> This series in its current form has been on the list for many weeks.
> Are there any objections from your side against merging it for v5.12?
Hey Bartosz,
I don't have much time for code reviews these days (you can see my
lack of mailing list stats), so I only saw your series today. I
accidentally reviewed the first version, but my comments there still
stand. Overall, I'm very happy to see this implemented.
Thanks,
Joel
--
"Get right to the heart of matters.
It's the heart that matters more."
http://www.jlbec.org/
jlbec@evilplan.org
prev parent reply other threads:[~2021-01-14 1:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-29 10:22 [RESEND PATCH v3 0/4] configfs: implement committable items and add sample code Bartosz Golaszewski
2020-12-29 10:22 ` [RESEND PATCH v3 1/4] configfs: increase the item name length Bartosz Golaszewski
2020-12-29 10:22 ` [RESEND PATCH v3 2/4] configfs: use (1UL << bit) for internal flags Bartosz Golaszewski
2020-12-29 10:22 ` [RESEND PATCH v3 3/4] configfs: implement committable items Bartosz Golaszewski
2020-12-29 10:22 ` [RESEND PATCH v3 4/4] samples: configfs: add a committable group Bartosz Golaszewski
2021-01-05 15:12 ` [RESEND PATCH v3 0/4] configfs: implement committable items and add sample code Linus Walleij
2021-01-11 8:32 ` Bartosz Golaszewski
2021-01-13 23:49 ` Joel Becker [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=X/+HDQBc1dx9Ipdm@google.com \
--to=jlbec@evilplan.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bgolaszewski@baylibre.com \
--cc=brgl@bgdev.pl \
--cc=hch@lst.de \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=warthog618@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox