On Fri, Sep 11, 2020 at 3:01 PM Greg Kroah-Hartman
[off-list ref] wrote:

On Tue, Sep 08, 2020 at 07:03:30PM +0200, Bartosz Golaszewski wrote:

quoted

On Mon, Sep 7, 2020 at 2:22 PM Greg Kroah-Hartman
[off-list ref] wrote:

quoted

On Mon, Sep 07, 2020 at 02:06:15PM +0200, Bartosz Golaszewski wrote:

quoted

On Mon, Sep 7, 2020 at 1:53 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Mon, Sep 07, 2020 at 12:26:34PM +0200, Bartosz Golaszewski wrote:

quoted

On Mon, Sep 7, 2020 at 11:59 AM Andy Shevchenko
[off-list ref] wrote:

quoted

On Fri, Sep 04, 2020 at 08:15:59PM -0700, Randy Dunlap wrote:

quoted

On 9/4/20 8:45 AM, Bartosz Golaszewski wrote:

...

quoted

quoted

+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