On Fri, Nov 19, 2021 at 11:34:59AM +0100, Bartosz Golaszewski wrote:

On Thu, Nov 18, 2021 at 5:59 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Thu, Nov 18, 2021 at 05:37:02PM +0100, Bartosz Golaszewski wrote:

quoted

On Thu, Nov 18, 2021 at 4:50 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Thu, Nov 18, 2021 at 03:51:38PM +0100, Bartosz Golaszewski wrote:

quoted

This is another shot at the gpio-sim testing module. As there was no
reasoning with configfs maintainers for many months, this time the whole
concept of committable items has been dropped. Instead, each configfs
chip item (or rather a group - more on that later) exposes a new
attribute called 'live'. Writing 1 to it brings the chip on-line
(registers the platform device) and writing 0 tears it down.

There are some caveats to that approach - for example: we can't block
the user-space from deleting chip items when chips are live but is just
handled by silently destroying the chip device in the background.

Andy (rightfully) pointed out that parsing of the lists of line names is
awkward so in this iteration it's been replaced by a system that is more
elegant and will allow to easily extend configuration options for
specific GPIO lines. This is achieved by turning the chip's configfs
item into a configfs group and allowing the user-space to create
additional items inside it. The items must be called line<offset> (e.g.
line0, line12 etc.) where the offset part indicates to the module the
offset for which given item stores the configuration for. Within each
such line item, there are additional attributes that allow specifying
configuration for specific lines. Currently we only support the 'name'
attribute but I plan to extend that to support GPIO hogging too.

One question here. Since you know how the driver looks like in both cases
(with and without committable items), would it be possible to modify what
you proposed here to the former one in case ConfigFS gains the feature?

This would completely change the user interface unfortunately. We
could extend it but we would need to keep this one too most likely.

TBH I don't see the committable items merged anytime soon, and this is
GoodEnough®.

Fine with me then!

Thanks for doing this all, I know it's a bit delayed in terms of getting
into upstream.

Btw, gpio-mockup testing scripts have an issue that the number of lines to
check overflow is hardcoded and since x86_64 switched to 1024 from 512 it
reveals the issue. Does gpio-sim solve this in a better way (like telling
to user space the ngpios, etc)?

Yeah the selftests need fixing now.

No, there need to be new selftests added for your gpio-sim.
The existing selftests cover the gpio-mockup itself.

No, there's no fix for that in gpio-sim - probe() will just fail.
Which makes me think - maybe we should synchronously wait when writing
to 'live' for the probe to return (for instance setup a notifier) so
that we know if the chip probed correctly. Then we can notify the
user-space about the error destroy the device too.

+1 - need definite feedback to userspace that the change to the test setup
is in place so tests can proceed.  No arbitrary waits or waiting for
events from other subsystems like udev as we have to do with gpio-mockup.

Cheers,
Kent.