Re: [PATCH libgpiod] tests: uapi: add test-cases for open-drain and open-source emulation

[Kent Gibson <warthog618@gmail.com>]

On Thu, Apr 10, 2025 at 08:34:37PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 10, 2025 at 12:17 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > The kernel GPIO subsystem can emulate open-drain and open-source by not
> > actively driving the line for active and inactive output values
> > respectively. The kernel does it by setting the line to input in these
> > cases but this still must be reported as output to user-space. Add new
> > test-cases that verify this behavior.
>
> Thanks, that's indeed a good idea!
> Reviewed-by: Andy Shevchenko <andy@kernel.org>
>

FWIW, the test suite[1] I wrote for my Go library along with the uAPI v2
also covers these cases, and more - particularly error cases.
Not that I've run it over Bart's changes yet, but it is my first stop when
checking for uAPI breakage.
It is written in Go, as there obviously was no libgpiod v2 at the time.

You can run the whole uapi test suite yourself by grabbing that repo and Go and...

~/go-gpiocdev/uapi$ go test -c
~/go-gpiocdev/uapi$ sudo ./uapi.test --test.v

I believe the cases above are covered (mostly) by

$ sudo ./uapi.test --test.v --test.run "TestGetLine$/output_[drain|source]"
=== RUN   TestGetLine
=== RUN   TestGetLine/output_drain
=== RUN   TestGetLine/output_source
--- PASS: TestGetLine (0.01s)
    --- PASS: TestGetLine/output_drain (0.00s)
    --- PASS: TestGetLine/output_source (0.00s)
PASS

which request the line then check that the reported info corresponds.

I don't seem to have any tests that cover setting the value of
open-drain/open-source outputs yet, so I might have to add some.
Though my existing set value tests check the value reported by the
gpio-sim, which will behave differently for emulated outputs...
Which probably explains why I didn't test that already - it is getting
into the bowels of gpiolib so it is really testing gpiolib behaviour,
not just the uAPI.  (I do have a few kernel specific tests, but they have
generally been added to test specific bugs that were visible though the
uAPI.)

On that point, it might also be handy if we could turn open-drain/open-source
support on and off in the gpio-sim (per sim), so tests can control if they
are getting the emulation, or not.

Cheers,
Kent.

[1] https://github.com/warthog618/go-gpiocdev