[0/7] gpio: mockup: extensions for testing purposes

I would like to create an automated test-suite for libgpiod, but
the gpio-mockup driver is quite limited when it comes to current
user space functionality - I can't test neither line event
notifications nor finding GPIO lines by name.

This series proposes to extend the gpio framework by allowing to
inject line events from the kernel code and by providing a debugfs
interface for that to the gpio-mockup driver. We also allow the
user to request that the mockup driver name the lines.

The first patch contains only minor clean-ups. Patches 2/7-4/7
implement the in-kernel mechanism for injecting events, while patch
5/7 extends the mockup driver to provide a relevant debugfs interface.

Patch 6/7 adds a new module param allowing to request naming of the
lines.

The last patch contains some coding style tweaks.

Bartosz Golaszewski (7):
  gpiolib: clean up includes
  gpiolib: support monitoring mockup devices
  gpio: mockup: set the mockup flag in struct gpio_chip
  gpiolib: allow injecting line events
  gpio: mockup: implement injecting events over debugfs
  gpio: mockup: implement naming the GPIO lines
  gpio: mockup: readability tweaks

 drivers/gpio/gpio-dwapb.c      |   1 -
 drivers/gpio/gpio-mockup.c     | 147 +++++++++++++++++++++++++++++++++++++----
 drivers/gpio/gpio-xgene-sb.c   |   1 -
 drivers/gpio/gpiolib-acpi.c    |   2 -
 drivers/gpio/gpiolib-devprop.c |   2 -
 drivers/gpio/gpiolib-legacy.c  |   3 -
 drivers/gpio/gpiolib-of.c      |   1 -
 drivers/gpio/gpiolib-sysfs.c   |   2 -
 drivers/gpio/gpiolib.c         |  44 +++++++++---
 drivers/gpio/gpiolib.h         |   5 ++
 include/linux/gpio/driver.h    |   4 ++
 11 files changed, 175 insertions(+), 37 deletions(-)

-- 
2.9.3

2017-01-31 15:11 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
> On 01/31/2017 03:05 PM, Bartosz Golaszewski wrote:

>> 2017-01-31 14:28 GMT+01:00 Linus Walleij <linus.walleij@linaro.org>:

>>> On Wed, Jan 25, 2017 at 4:34 PM, Bartosz Golaszewski

>>> <bgolaszewski@baylibre.com> wrote:

>>>

>>>> This series proposes to extend the gpio framework by allowing to

>>>> inject line events from the kernel code and by providing a debugfs

>>>> interface for that to the gpio-mockup driver. We also allow the

>>>> user to request that the mockup driver name the lines.

>>>

>>> I sympathize fully with the goal and intentions of the series, I

>>> agree: this is awesome to have for testing and validation of

>>> GPIO.

>>>

>>> I'm reluctant about the changes to gpiolib and want to make that

>>> code as optional as possible, definately #ifdef if nothing else

>>> works. Otherwise the memory footprint people will get me for this,

>>> haha. ;)

>>>

>>> The absolutely best would be if the driver could inject "real"

>>> irqs and also exercise the gpiolib irqchip helpers. I have been

>>> vaguely thinking that sofware interrupts should be able to do this

>>> but I'm not very versed in that kind of stuff.

>>>

>>

>> This was my initial idea, but I thought it's not very likely that

>> Thomas Gleixner would allow me to allocate a new software interrupt

>> just for the sake of testing gpiolib. Also: the handling of softirqs

>> seems to be a bit different than regular IRQs, but I'm too not an

>> expert.

>

> FWIW, we also need this in IIO. We currently inject our software IRQs for

> testing using irq_work and handle_simple_irq()[1]. This has the advantage

> that it goes the normal route through the IRQ subsystem and is even running

> in IRQ context rather than application context (which is what happens if you

> emulate the IRQ directly from the sysfs/debugfs callbacks).

>

> - Lars

>

> [1] http://lxr.free-electrons.com/source/drivers/iio/dummy/iio_dummy_evgen.c#L84


Nice! I didn't know about that. I think this is what we need in gpiolib.

Thanks,
Bartosz