All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Bartosz Golaszewski <brgl@bgdev.pl>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Randy Dunlap <rdunlap@infradead.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Kent Gibson <warthog618@gmail.com>,
	linux-gpio <linux-gpio@vger.kernel.org>,
	linux-doc <linux-doc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH 23/23] Documentation: gpio: add documentation for gpio-mockup
Date: Fri, 11 Sep 2020 15:07:02 +0200	[thread overview]
Message-ID: <CAMpxmJUd-ALoBi4aC1nsJ7JmEsANe_gZfBegCiZtP6BwPpC52g@mail.gmail.com> (raw)
In-Reply-To: <20200911125625.GF3758477@kroah.com>

On Fri, Sep 11, 2020 at 3:01 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Sep 08, 2020 at 07:03:30PM +0200, Bartosz Golaszewski wrote:
> > On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:
> > > > On Mon, Sep 7, 2020 at 1:53 PM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > >
> > > > > On Mon, Sep 07, 2020 at 12:26:34PM +0200, Bartosz Golaszewski wrote:
> > > > > > On Mon, Sep 7, 2020 at 11:59 AM Andy Shevchenko
> > > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > > > >
> > > > > > > On Fri, Sep 04, 2020 at 08:15:59PM -0700, Randy Dunlap wrote:
> > > > > > > > On 9/4/20 8:45 AM, Bartosz Golaszewski wrote:
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > > > > +GPIO Testing Driver
> > > > > > > > > +===================
> > > > > > > > > +
> > > > > > > > > +The GPIO Testing Driver (gpio-mockup) provides a way to create simulated GPIO
> > > > > > > > > +chips for testing purposes. There are two ways of configuring the chips exposed
> > > > > > > > > +by the module. The lines can be accessed using the standard GPIO character
> > > > > > > > > +device interface as well as manipulated using the dedicated debugfs directory
> > > > > > > > > +structure.
> > > > > > > >
> > > > > > > > Could configfs be used for this instead of debugfs?
> > > > > > > > debugfs is ad hoc.
> > > > > > >
> > > > > > > Actually sounds like a good idea.
> > > > > > >
> > > > > >
> > > > > > Well, then we can go on and write an entirely new mockup driver
> > > > > > (ditching module params and dropping any backwards compatibility)
> > > > > > because we're already using debugfs for line values.
> > > > > >
> > > > > > How would we pass the device properties to configfs created GPIO chips
> > > > > > anyway? Devices seem to only be created using mkdir. Am I missing
> > > > > > something?
> > > > >
> > > > > Same way how USB composite works, no?
> > > > >
> > > >
> > > > OK, so create a new chip directory in configfs, configure it using
> > > > some defined configfs attributes and then finally instantiate it from
> > > > sysfs?
> > > >
> > > > Makes sense and is probably the right way to go. Now the question is:
> > > > is it fine to just entirely remove the previous gpio-mockup? Should we
> > > > keep some backwards compatibility? Should we introduce an entirely new
> > > > module and have a transition period before removing previous
> > > > gpio-mockup?
> > > >
> > > > Also: this is a testing module so to me debugfs is just fine. Is
> > > > configfs considered stable ABI like sysfs?
> > >
> > > Yes it is.  Or at least until you fix all existing users so that if you
> > > do change it, no one notices it happening :)
> > >
> >
> > Got it. One more question: the current debugfs interface we're using
> > in gpio-mockup exists to allow to read current values of GPIO lines in
> > output mode (check how the user drives dummy lines) and to set their
> > simulated pull-up/pull-down resistors (what values the user reads in
> > input mode).
> >
> > This works like this: in /sys/kernel/debug/gpio-mockup every dummy
> > chip creates its own directory (e.g.
> > /sys/kernel/debug/gpio-mockup/gpiochip0) and inside this directory
> > there's an attribute per line named after the line's offset (e.g.
> > /sys/kernel/debug/gpio-mockup/gpiochip0/4). Writing 0 or 1 to this
> > attribute sets the pull resistor. Reading from it yields the current
> > value (0 or 1 as well).
> >
> > This is pretty non-standard so I proposed to put it in debugfs. If we
> > were to use configfs - is this where something like this should go? Or
> > rather sysfs? Is it even suitable/acceptable for sysfs?
>
> That sounds like it would work in sysfs just fine as-is, why don't you
> all want to use that?  configfs is good for "set a bunch of attributes
> to different values and then do a 'create/go/work'" type action.
>

I've started looking into it. I need to first implement committable
items for configfs because mockup GPIO chips need to be configured
before they're instantiated. It'll be configfs to configure and
instantiate each chip and a set of sysfs attributes to manipulate
existing chips.

Bartosz

  reply	other threads:[~2020-09-11 14:09 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04 15:45 [PATCH 00/23] gpio: mockup: support dynamically created and removed chips Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 01/23] lib: cmdline: export next_arg() Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 02/23] lib: string_helpers: provide kfree_strarray() Bartosz Golaszewski
2020-09-04 16:33   ` Andy Shevchenko
2020-09-04 15:45 ` [PATCH 03/23] lib: uaccess: provide getline_from_user() Bartosz Golaszewski
2020-09-04 16:35   ` Andy Shevchenko
2020-09-07 10:02     ` Bartosz Golaszewski
2020-09-07 10:18       ` Andy Shevchenko
2020-09-07 10:28         ` Bartosz Golaszewski
2020-09-07 11:45           ` Andy Shevchenko
2020-09-07 11:57             ` Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 04/23] gpiolib: generalize devprop_gpiochip_set_names() for device properties Bartosz Golaszewski
2020-09-04 16:38   ` Andy Shevchenko
2020-09-07 10:56     ` Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 05/23] gpiolib: unexport devprop_gpiochip_set_names() Bartosz Golaszewski
2020-09-04 16:40   ` Andy Shevchenko
2020-09-07 10:53     ` Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 06/23] gpiolib: switch to simpler IDA interface Bartosz Golaszewski
2020-09-04 16:41   ` Andy Shevchenko
2020-09-07 10:50     ` Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 07/23] gpio: mockup: drop unneeded includes Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 08/23] gpio: mockup: use pr_fmt() Bartosz Golaszewski
2020-09-04 16:29   ` Andy Shevchenko
2020-09-04 15:45 ` [PATCH 09/23] gpio: mockup: use KBUILD_MODNAME Bartosz Golaszewski
2020-09-04 16:30   ` Andy Shevchenko
2020-09-04 15:45 ` [PATCH 10/23] gpio: mockup: fix resource leak in error path Bartosz Golaszewski
2020-09-04 17:00   ` Andy Shevchenko
2020-09-07 11:04     ` Bartosz Golaszewski
2020-09-07 11:47       ` Andy Shevchenko
2020-09-04 15:45 ` [PATCH 11/23] gpio: mockup: remove the limit on number of dummy chips Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 12/23] gpio: mockup: define a constant for chip label size Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 13/23] gpio: mockup: pass the chip label as device property Bartosz Golaszewski
2020-09-04 16:48   ` Andy Shevchenko
2020-09-07 11:01     ` Bartosz Golaszewski
2020-09-07 11:48       ` Andy Shevchenko
2020-09-04 15:45 ` [PATCH 14/23] gpio: mockup: use the generic 'gpio-line-names' property Bartosz Golaszewski
2020-09-04 16:46   ` Andy Shevchenko
2020-09-07 10:58     ` Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 15/23] gpio: mockup: use dynamic device IDs Bartosz Golaszewski
2020-09-04 16:49   ` Andy Shevchenko
2020-09-07 11:04     ` Bartosz Golaszewski
2020-09-07 11:50       ` Andy Shevchenko
2020-09-07 11:59         ` Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 16/23] gpio: mockup: refactor the module init function Bartosz Golaszewski
2020-09-04 16:50   ` Andy Shevchenko
2020-09-07 11:05     ` Bartosz Golaszewski
2020-09-07 11:51       ` Andy Shevchenko
2020-09-04 15:45 ` [PATCH 17/23] gpio: mockup: rename and move around debugfs callbacks Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 18/23] gpio: mockup: require debugfs to build Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 19/23] gpio: mockup: add a symlink for the per-chip debugfs directory Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 20/23] gpio: mockup: add a lock for dummy device list Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 21/23] gpio: mockup: provide a way to delete dummy chips Bartosz Golaszewski
2020-09-04 16:56   ` Andy Shevchenko
2020-09-04 15:45 ` [PATCH 22/23] gpio: mockup: provide a way to create new " Bartosz Golaszewski
2020-09-04 15:45 ` [PATCH 23/23] Documentation: gpio: add documentation for gpio-mockup Bartosz Golaszewski
2020-09-04 16:58   ` Andy Shevchenko
2020-09-05  3:15   ` Randy Dunlap
2020-09-07  9:59     ` Andy Shevchenko
2020-09-07 10:26       ` Bartosz Golaszewski
2020-09-07 11:53         ` Andy Shevchenko
2020-09-07 12:06           ` Bartosz Golaszewski
2020-09-07 12:22             ` Greg Kroah-Hartman
2020-09-07 13:49               ` Bartosz Golaszewski
2020-09-07 14:08                 ` Andy Shevchenko
2020-09-07 15:14                   ` Bartosz Golaszewski
2020-09-07 15:23                   ` Geert Uytterhoeven
2020-09-07 16:08                     ` Bartosz Golaszewski
2020-09-08 17:03               ` Bartosz Golaszewski
2020-09-11 12:56                 ` Greg Kroah-Hartman
2020-09-11 13:07                   ` Bartosz Golaszewski [this message]
2020-09-07 12:38             ` Andy Shevchenko
2020-09-07 12:57               ` Bartosz Golaszewski
2020-09-07 13:52                 ` Andy Shevchenko
2020-09-07 10:45     ` Bartosz Golaszewski

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=CAMpxmJUd-ALoBi4aC1nsJ7JmEsANe_gZfBegCiZtP6BwPpC52g@mail.gmail.com \
    --to=bgolaszewski@baylibre.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brgl@bgdev.pl \
    --cc=corbet@lwn.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rdunlap@infradead.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.