On Mon, Sep 07, 2020 at 02:57:29PM +0200, Bartosz Golaszewski wrote:

On Mon, Sep 7, 2020 at 2:38 PM Andy Shevchenko
[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

quoted

quoted

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?

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.

quoted

Should we
keep some backwards compatibility?

I wouldn't probably spend time on this.

quoted

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