From: Bartosz Golaszewski <[email protected]>
There's some documentation for gpio-mockup's debugfs interface in the
driver's source but it's not much. Add proper documentation for this
testing module.
Signed-off-by: Bartosz Golaszewski <[email protected]>
---
.../admin-guide/gpio/gpio-mockup.rst | 87 +++++++++++++++++++
1 file changed, 87 insertions(+)
create mode 100644 Documentation/admin-guide/gpio/gpio-mockup.rst
diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst
new file mode 100644
index 000000000000..1d452ee55f8d
--- /dev/null
+++ b/Documentation/admin-guide/gpio/gpio-mockup.rst
@@ -0,0 +1,87 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+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.
+
+Creating simulated chips using debugfs
+--------------------------------------
+
+When the gpio-mockup module is loaded (or builtin) it creates its own directory
+in debugfs. Assuming debugfs is mounted at /sys/kernel/debug/, the directory
+will be located at /sys/kernel/debug/gpio-mockup/. Inside this directory there
+are two attributes: new_device and delete_device.
+
+New chips can be created by writing a single line containing a number of
+options to "new_device". For example:
+
+.. code-block:: sh
+
+ $ echo "label=my-mockup num_lines=4 named_lines" > /sys/kernel/debug/gpio-mockup/new_device
+
+Supported options:
+
+ num_lines=<num_lines> - number of GPIO lines to expose
+
+ label=<label> - label of the dummy chip
+
+ named_lines - defines whether dummy lines should be named, the names are
+ of the form X-Y where X is the chip's label and Y is the
+ line's offset
+
+Note: only num_lines is mandatory.
+
+Chips can be dynamically removed by writing the chip's label to
+"delete_device". For example:
+
+.. code-block:: sh
+
+ echo "gpio-mockup.0" > /sys/kernel/debug/gpio-mockup/delete_device
+
+Creating simulated chips using module params
+--------------------------------------------
+
+Note: this is an older, now deprecated method kept for backward compatibility
+for user-space tools.
+
+When loading the gpio-mockup driver a number of parameters can be passed to the
+module.
+
+ gpio_mockup_ranges
+
+ This parameter takes an argument in the form of an array of integer
+ pairs. Each pair defines the base GPIO number (if any) and the number
+ of lines exposed by the chip. If the base GPIO is -1, the gpiolib
+ will assign it automatically.
+
+ Example: gpio_mockup_ranges=-1,8,-1,16,405,4
+
+ The line above creates three chips. The first one will expose 8 lines,
+ the second 16 and the third 4. The base GPIO for the third chip is set
+ to 405 while for two first chips it will be assigned automatically.
+
+ gpio_named_lines
+
+ This parameter doesn't take any arguments. It lets the driver know that
+ GPIO lines exposed by it should be named.
+
+ The name format is: gpio-mockup-X-Y where X is the letter associated
+ with the mockup chip and Y is the line offset.
+
+Manipulating simulated lines
+----------------------------
+
+Each mockup chip creates its own subdirectory in /sys/kernel/debug/gpio-mockup/.
+The directory is named after the chip's label. A symlink is also created, named
+after the chip's name, which points to the label directory.
+
+Inside each subdirectory, there's a separate attribute for each GPIO line. The
+name of the attribute represents the line's offset in the chip.
+
+Reading from a line attribute returns the current value. Writing to it (0 or 1)
+changes its pull.
--
2.26.1
On Fri, Sep 04, 2020 at 05:45:47PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <[email protected]>
>
> There's some documentation for gpio-mockup's debugfs interface in the
> driver's source but it's not much. Add proper documentation for this
> testing module.
I always for the documentation!
> Signed-off-by: Bartosz Golaszewski <[email protected]>
> ---
> .../admin-guide/gpio/gpio-mockup.rst | 87 +++++++++++++++++++
> 1 file changed, 87 insertions(+)
> create mode 100644 Documentation/admin-guide/gpio/gpio-mockup.rst
>
> diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst
> new file mode 100644
> index 000000000000..1d452ee55f8d
> --- /dev/null
> +++ b/Documentation/admin-guide/gpio/gpio-mockup.rst
> @@ -0,0 +1,87 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +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.
> +
> +Creating simulated chips using debugfs
> +--------------------------------------
> +
> +When the gpio-mockup module is loaded (or builtin) it creates its own directory
> +in debugfs. Assuming debugfs is mounted at /sys/kernel/debug/, the directory
> +will be located at /sys/kernel/debug/gpio-mockup/. Inside this directory there
> +are two attributes: new_device and delete_device.
> +
> +New chips can be created by writing a single line containing a number of
> +options to "new_device". For example:
> +
> +.. code-block:: sh
> +
> + $ echo "label=my-mockup num_lines=4 named_lines" > /sys/kernel/debug/gpio-mockup/new_device
> +
> +Supported options:
> +
> + num_lines=<num_lines> - number of GPIO lines to expose
> +
> + label=<label> - label of the dummy chip
> +
> + named_lines - defines whether dummy lines should be named, the names are
> + of the form X-Y where X is the chip's label and Y is the
> + line's offset
> +
> +Note: only num_lines is mandatory.
> +
> +Chips can be dynamically removed by writing the chip's label to
> +"delete_device". For example:
> +
> +.. code-block:: sh
> +
> + echo "gpio-mockup.0" > /sys/kernel/debug/gpio-mockup/delete_device
> +
> +Creating simulated chips using module params
> +--------------------------------------------
> +
> +Note: this is an older, now deprecated method kept for backward compatibility
> +for user-space tools.
> +
> +When loading the gpio-mockup driver a number of parameters can be passed to the
> +module.
> +
> + gpio_mockup_ranges
> +
> + This parameter takes an argument in the form of an array of integer
> + pairs. Each pair defines the base GPIO number (if any) and the number
> + of lines exposed by the chip. If the base GPIO is -1, the gpiolib
> + will assign it automatically.
> +
> + Example: gpio_mockup_ranges=-1,8,-1,16,405,4
> +
> + The line above creates three chips. The first one will expose 8 lines,
> + the second 16 and the third 4. The base GPIO for the third chip is set
> + to 405 while for two first chips it will be assigned automatically.
> +
> + gpio_named_lines
> +
> + This parameter doesn't take any arguments. It lets the driver know that
> + GPIO lines exposed by it should be named.
> +
> + The name format is: gpio-mockup-X-Y where X is the letter associated
> + with the mockup chip and Y is the line offset.
> +
> +Manipulating simulated lines
> +----------------------------
> +
> +Each mockup chip creates its own subdirectory in /sys/kernel/debug/gpio-mockup/.
> +The directory is named after the chip's label. A symlink is also created, named
> +after the chip's name, which points to the label directory.
> +
> +Inside each subdirectory, there's a separate attribute for each GPIO line. The
> +name of the attribute represents the line's offset in the chip.
> +
> +Reading from a line attribute returns the current value. Writing to it (0 or 1)
> +changes its pull.
> --
> 2.26.1
>
--
With Best Regards,
Andy Shevchenko
Hi,
On 9/4/20 8:45 AM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <[email protected]>
>
> There's some documentation for gpio-mockup's debugfs interface in the
> driver's source but it's not much. Add proper documentation for this
> testing module.
>
> Signed-off-by: Bartosz Golaszewski <[email protected]>
> ---
> .../admin-guide/gpio/gpio-mockup.rst | 87 +++++++++++++++++++
> 1 file changed, 87 insertions(+)
> create mode 100644 Documentation/admin-guide/gpio/gpio-mockup.rst
>
> diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst
> new file mode 100644
> index 000000000000..1d452ee55f8d
> --- /dev/null
> +++ b/Documentation/admin-guide/gpio/gpio-mockup.rst
> @@ -0,0 +1,87 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +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.
> +
> +Creating simulated chips using debugfs
> +--------------------------------------
> +
> +When the gpio-mockup module is loaded (or builtin) it creates its own directory
> +in debugfs. Assuming debugfs is mounted at /sys/kernel/debug/, the directory
> +will be located at /sys/kernel/debug/gpio-mockup/. Inside this directory there
> +are two attributes: new_device and delete_device.
> +
> +New chips can be created by writing a single line containing a number of
> +options to "new_device". For example:
> +
> +.. code-block:: sh
> +
> + $ echo "label=my-mockup num_lines=4 named_lines" > /sys/kernel/debug/gpio-mockup/new_device
> +
> +Supported options:
> +
> + num_lines=<num_lines> - number of GPIO lines to expose
> +
> + label=<label> - label of the dummy chip
> +
> + named_lines - defines whether dummy lines should be named, the names are
> + of the form X-Y where X is the chip's label and Y is the
> + line's offset
> +
> +Note: only num_lines is mandatory.
> +
> +Chips can be dynamically removed by writing the chip's label to
> +"delete_device". For example:
> +
> +.. code-block:: sh
> +
> + echo "gpio-mockup.0" > /sys/kernel/debug/gpio-mockup/delete_device
> +
> +Creating simulated chips using module params
> +--------------------------------------------
> +
> +Note: this is an older, now deprecated method kept for backward compatibility
> +for user-space tools.
> +
> +When loading the gpio-mockup driver a number of parameters can be passed to the
> +module.
> +
> + gpio_mockup_ranges
> +
> + This parameter takes an argument in the form of an array of integer
> + pairs. Each pair defines the base GPIO number (if any) and the number
> + of lines exposed by the chip. If the base GPIO is -1, the gpiolib
> + will assign it automatically.
> +
> + Example: gpio_mockup_ranges=-1,8,-1,16,405,4
> +
> + The line above creates three chips. The first one will expose 8 lines,
> + the second 16 and the third 4. The base GPIO for the third chip is set
> + to 405 while for two first chips it will be assigned automatically.
> +
> + gpio_named_lines
> +
> + This parameter doesn't take any arguments. It lets the driver know that
> + GPIO lines exposed by it should be named.
> +
> + The name format is: gpio-mockup-X-Y where X is the letter associated
> + with the mockup chip and Y is the line offset.
Where does this 'X' letter associated with the mockup chip come from?
> +
> +Manipulating simulated lines
> +----------------------------
> +
> +Each mockup chip creates its own subdirectory in /sys/kernel/debug/gpio-mockup/.
> +The directory is named after the chip's label. A symlink is also created, named
> +after the chip's name, which points to the label directory.
> +
> +Inside each subdirectory, there's a separate attribute for each GPIO line. The
> +name of the attribute represents the line's offset in the chip.
> +
> +Reading from a line attribute returns the current value. Writing to it (0 or 1)
> +changes its pull.
What does "pull" mean here?
thanks.
--
~Randy
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.
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 7, 2020 at 11:59 AM Andy Shevchenko
<[email protected]> 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?
Bart
On Sat, Sep 5, 2020 at 5:16 AM Randy Dunlap <[email protected]> wrote:
>
> Hi,
>
> On 9/4/20 8:45 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <[email protected]>
> >
> > There's some documentation for gpio-mockup's debugfs interface in the
> > driver's source but it's not much. Add proper documentation for this
> > testing module.
> >
> > Signed-off-by: Bartosz Golaszewski <[email protected]>
> > ---
> > .../admin-guide/gpio/gpio-mockup.rst | 87 +++++++++++++++++++
> > 1 file changed, 87 insertions(+)
> > create mode 100644 Documentation/admin-guide/gpio/gpio-mockup.rst
> >
> > diff --git a/Documentation/admin-guide/gpio/gpio-mockup.rst b/Documentation/admin-guide/gpio/gpio-mockup.rst
> > new file mode 100644
> > index 000000000000..1d452ee55f8d
> > --- /dev/null
> > +++ b/Documentation/admin-guide/gpio/gpio-mockup.rst
> > @@ -0,0 +1,87 @@
> > +.. SPDX-License-Identifier: GPL-2.0-only
> > +
> > +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.
>
> > +
> > +Creating simulated chips using debugfs
> > +--------------------------------------
> > +
> > +When the gpio-mockup module is loaded (or builtin) it creates its own directory
> > +in debugfs. Assuming debugfs is mounted at /sys/kernel/debug/, the directory
> > +will be located at /sys/kernel/debug/gpio-mockup/. Inside this directory there
> > +are two attributes: new_device and delete_device.
> > +
> > +New chips can be created by writing a single line containing a number of
> > +options to "new_device". For example:
> > +
> > +.. code-block:: sh
> > +
> > + $ echo "label=my-mockup num_lines=4 named_lines" > /sys/kernel/debug/gpio-mockup/new_device
> > +
> > +Supported options:
> > +
> > + num_lines=<num_lines> - number of GPIO lines to expose
> > +
> > + label=<label> - label of the dummy chip
> > +
> > + named_lines - defines whether dummy lines should be named, the names are
> > + of the form X-Y where X is the chip's label and Y is the
> > + line's offset
> > +
> > +Note: only num_lines is mandatory.
> > +
> > +Chips can be dynamically removed by writing the chip's label to
> > +"delete_device". For example:
> > +
> > +.. code-block:: sh
> > +
> > + echo "gpio-mockup.0" > /sys/kernel/debug/gpio-mockup/delete_device
> > +
> > +Creating simulated chips using module params
> > +--------------------------------------------
> > +
> > +Note: this is an older, now deprecated method kept for backward compatibility
> > +for user-space tools.
> > +
> > +When loading the gpio-mockup driver a number of parameters can be passed to the
> > +module.
> > +
> > + gpio_mockup_ranges
> > +
> > + This parameter takes an argument in the form of an array of integer
> > + pairs. Each pair defines the base GPIO number (if any) and the number
> > + of lines exposed by the chip. If the base GPIO is -1, the gpiolib
> > + will assign it automatically.
> > +
> > + Example: gpio_mockup_ranges=-1,8,-1,16,405,4
> > +
> > + The line above creates three chips. The first one will expose 8 lines,
> > + the second 16 and the third 4. The base GPIO for the third chip is set
> > + to 405 while for two first chips it will be assigned automatically.
> > +
> > + gpio_named_lines
> > +
> > + This parameter doesn't take any arguments. It lets the driver know that
> > + GPIO lines exposed by it should be named.
> > +
> > + The name format is: gpio-mockup-X-Y where X is the letter associated
> > + with the mockup chip and Y is the line offset.
>
> Where does this 'X' letter associated with the mockup chip come from?
>
> > +
> > +Manipulating simulated lines
> > +----------------------------
> > +
> > +Each mockup chip creates its own subdirectory in /sys/kernel/debug/gpio-mockup/.
> > +The directory is named after the chip's label. A symlink is also created, named
> > +after the chip's name, which points to the label directory.
> > +
> > +Inside each subdirectory, there's a separate attribute for each GPIO line. The
> > +name of the attribute represents the line's offset in the chip.
> > +
> > +Reading from a line attribute returns the current value. Writing to it (0 or 1)
> > +changes its pull.
>
> What does "pull" mean here?
>
Yeah I should probably clarify this. "Pull" here means a simulated
pull-down/up resistor basically.
Bart
On Mon, Sep 07, 2020 at 12:26:34PM +0200, Bartosz Golaszewski wrote:
> On Mon, Sep 7, 2020 at 11:59 AM Andy Shevchenko
> <[email protected]> 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?
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 7, 2020 at 1:53 PM Andy Shevchenko
<[email protected]> 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
> > <[email protected]> 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?
Bart
On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:
> On Mon, Sep 7, 2020 at 1:53 PM Andy Shevchenko
> <[email protected]> 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
> > > <[email protected]> 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 :)
thanks,
greg k-h
On Mon, Sep 7, 2020 at 2:38 PM Andy Shevchenko
<[email protected]> 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
> > <[email protected]> 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
> > > > <[email protected]> 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?
>
> Since, for example, I never saw device property bindings for that driver I
> assume that it was never considered as an ABI, so feel free to hack it in
> either direction.
>
> > Should we
> > keep some backwards compatibility?
>
> I wouldn't probably spend time on this.
>
> > Should we introduce an entirely new
> > module and have a transition period before removing previous
> > gpio-mockup?
>
> Neither transition period.
>
I wouldn't rush this actually. gpio-mockup is used a lot by libgpiod
and probably by Kent's Go library. My main goal with this series is to
extend it to allow for more advanced testing like simulating spurious
irqs to test the software debouncer or custom line name formats to
test name lookups.
I need to think about it some more. An entirely new configfs interface
would take time too.
Bart
On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
<[email protected]> 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
> > <[email protected]> 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
> > > > <[email protected]> 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 :)
>
Then another question is: do we really want to commit to a stable ABI
for a module we only use for testing purposes and which doesn't
interact with any real hardware.
Rewriting this module without any legacy cruft is tempting though. :)
Bart
On Mon, Sep 07, 2020 at 03:49:23PM +0200, Bartosz Golaszewski wrote:
> On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:
...
> > Yes it is. Or at least until you fix all existing users so that if you
> > do change it, no one notices it happening :)
> >
>
> Then another question is: do we really want to commit to a stable ABI
> for a module we only use for testing purposes and which doesn't
> interact with any real hardware.
>
> Rewriting this module without any legacy cruft is tempting though. :)
Another thought spoken loudly: maybe it can be unified with GPIO aggregator
code? In that case it makes sense.
--
With Best Regards,
Andy Shevchenko
Hi Andy,
On Mon, Sep 7, 2020 at 4:14 PM Andy Shevchenko
<[email protected]> wrote:
> On Mon, Sep 07, 2020 at 03:49:23PM +0200, Bartosz Golaszewski wrote:
> > On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
> > <[email protected]> wrote:
> > > On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:
>
> ...
>
> > > Yes it is. Or at least until you fix all existing users so that if you
> > > do change it, no one notices it happening :)
> > >
> >
> > Then another question is: do we really want to commit to a stable ABI
> > for a module we only use for testing purposes and which doesn't
> > interact with any real hardware.
> >
> > Rewriting this module without any legacy cruft is tempting though. :)
>
> Another thought spoken loudly: maybe it can be unified with GPIO aggregator
> code? In that case it makes sense.
You want to aggregate GPIOs out of thin air?
From DT, that would be something like
gpios = <&gpio1 2>, <0>, <0>, <&gpio2, 5>;
?
For writing into ".../new_device", we could agree on something like "0"
means not backed by an existing GPIO?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Mon, Sep 7, 2020 at 4:08 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Mon, Sep 07, 2020 at 03:49:23PM +0200, Bartosz Golaszewski wrote:
> > On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
> > <[email protected]> wrote:
> > > On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:
>
> ...
>
> > > Yes it is. Or at least until you fix all existing users so that if you
> > > do change it, no one notices it happening :)
> > >
> >
> > Then another question is: do we really want to commit to a stable ABI
> > for a module we only use for testing purposes and which doesn't
> > interact with any real hardware.
> >
> > Rewriting this module without any legacy cruft is tempting though. :)
>
> Another thought spoken loudly: maybe it can be unified with GPIO aggregator
> code? In that case it makes sense.
>
Cc'ing Geert but I don't quite see how this would make sense. :)
Also one thing I'm not sure about re configfs is the interface we use
to read values/set pull i.e. the line attributes in debugfs, do you
think configfs allows this type of attributes?
Bart
On Mon, Sep 7, 2020 at 5:23 PM Geert Uytterhoeven <[email protected]> wrote:
>
> Hi Andy,
>
> On Mon, Sep 7, 2020 at 4:14 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Mon, Sep 07, 2020 at 03:49:23PM +0200, Bartosz Golaszewski wrote:
> > > On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
> > > <[email protected]> wrote:
> > > > On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:
> >
> > ...
> >
> > > > Yes it is. Or at least until you fix all existing users so that if you
> > > > do change it, no one notices it happening :)
> > > >
> > >
> > > Then another question is: do we really want to commit to a stable ABI
> > > for a module we only use for testing purposes and which doesn't
> > > interact with any real hardware.
> > >
> > > Rewriting this module without any legacy cruft is tempting though. :)
> >
> > Another thought spoken loudly: maybe it can be unified with GPIO aggregator
> > code? In that case it makes sense.
>
> You want to aggregate GPIOs out of thin air?
>
> From DT, that would be something like
>
> gpios = <&gpio1 2>, <0>, <0>, <&gpio2, 5>;
>
> ?
>
> For writing into ".../new_device", we could agree on something like "0"
> means not backed by an existing GPIO?
>
I'm really not sure this makes any sense. Why complicate an otherwise
elegant module that is gpio-aggregator with functionalities that
obviously don't belong here? I want to add various parameters that
would affect the way the simulated chips work - this really doesn't
need to go into the aggregator.
Bart
On Mon, Sep 07, 2020 at 02:57:29PM +0200, Bartosz Golaszewski wrote:
> On Mon, Sep 7, 2020 at 2:38 PM Andy Shevchenko
> <[email protected]> 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
> > > <[email protected]> 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
> > > > > <[email protected]> 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?
> >
> > Since, for example, I never saw device property bindings for that driver I
> > assume that it was never considered as an ABI, so feel free to hack it in
> > either direction.
> >
> > > Should we
> > > keep some backwards compatibility?
> >
> > I wouldn't probably spend time on this.
> >
> > > Should we introduce an entirely new
> > > module and have a transition period before removing previous
> > > gpio-mockup?
> >
> > Neither transition period.
> >
>
> I wouldn't rush this actually. gpio-mockup is used a lot by libgpiod
> and probably by Kent's Go library. My main goal with this series is to
> extend it to allow for more advanced testing like simulating spurious
> irqs to test the software debouncer or custom line name formats to
> test name lookups.
When I wrote above I didn't mean this should be done in a hurry. Just during
one release to make all parties ready for the change.
> I need to think about it some more. An entirely new configfs interface
> would take time too.
Sure!
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:
> On Mon, Sep 7, 2020 at 1:53 PM Andy Shevchenko
> <[email protected]> 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
> > > <[email protected]> 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?
Since, for example, I never saw device property bindings for that driver I
assume that it was never considered as an ABI, so feel free to hack it in
either direction.
> Should we
> keep some backwards compatibility?
I wouldn't probably spend time on this.
> Should we introduce an entirely new
> module and have a transition period before removing previous
> gpio-mockup?
Neither transition period.
> Also: this is a testing module so to me debugfs is just fine. Is
> configfs considered stable ABI like sysfs?
But this one is a good question. I think ConfigFS is stricter than DebugFS,
up to being an ABI. But never did myself such a thing, so would like to hear
experienced developers.
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
<[email protected]> 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
> > <[email protected]> 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
> > > > <[email protected]> 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?
Thanks,
Bartosz
On Fri, Sep 11, 2020 at 3:01 PM Greg Kroah-Hartman
<[email protected]> 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
> > <[email protected]> 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
> > > > <[email protected]> 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
> > > > > > <[email protected]> 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
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
> <[email protected]> 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
> > > <[email protected]> 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
> > > > > <[email protected]> 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.
thanks,
greg k-h