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 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.