Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1570752 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/7] gpio: mockup: extensions for testing purposes Linus Walleij <linus.walleij@linaro.org> - 2017-01-31 14:40 +0100
    Re: [PATCH 0/7] gpio: mockup: extensions for testing purposes Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2017-01-31 15:10 +0100
      Re: [PATCH 0/7] gpio: mockup: extensions for testing purposes Lars-Peter Clausen <lars@metafoo.de> - 2017-01-31 15:20 +0100
        Re: [PATCH 0/7] gpio: mockup: extensions for testing purposes Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2017-01-31 15:30 +0100

#1570752 — Re: [PATCH 0/7] gpio: mockup: extensions for testing purposes

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.

The changes to gpio-mockup.c are entirely uncontroversial, it
is for testing so I'm willing to accept almost anything if it looks
maintainable and helps in testing.

Yours,
Linus Walleij

[toc] | [next] | [standalone]

#1570768

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.

> The changes to gpio-mockup.c are entirely uncontroversial, it
> is for testing so I'm willing to accept almost anything if it looks
> maintainable and helps in testing.
>

How about creating a new config option GPIOLIB_LINE_EVENT_DEBUG that
would be selected by GPIO_MOCKUP and enclosing the relevant gpiolib
code with ifdefs (+ potentially comments explaining what's being done
and why)?

Thanks,
Bartosz

[toc] | [prev] | [next] | [standalone]

#1570775

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

[toc] | [prev] | [next] | [standalone]

#1570787

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web