lkml.org 
[lkml]   [2019]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/9] gpio: mockup: improve the user-space testing interface
On Wed, 6 Feb 2019 11:23:46 +0100
Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> wt., 29 sty 2019 o 09:44 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
> >
> > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> >
> > This series aims at reworking the gpio-mockup debugfs interface. The
> > reason for that is the fact that certain known problems with this
> > testing module exist and the user-space tests are broken anyway
> > after commit fa38869b0161 ("gpiolib: Don't support irq sharing
> > for userspace") which made it impossible for gpio-mockup to ignore
> > certain events (e.g. only receive notifications about rising edge
> > events).
> >
> > The first three patches improve the interrupt simulator. The first one
> > makes the struct irq_chip part of the irq_sim structure so that we can
> > support multiple instances at once. The second delegates the irq number
> > mapping to the irq domain subsystem. The third patch provides a helper
> > that will allow users to specify the type of the fired interrupt so that
> > the configuration set by the set_type() callback can be taken into account.
> >
> > Next six patches improve the gpio-mockup module. Patches 4-5 have been
> > reviewed before but missed the last merge window. Patch 6 is there
> > because we're already breaking the debugfs interface anyway and it
> > removes a link that has no users. Patches 7-8 are minor tweaks.
> >
> > Last patch introduces a rework of the debugfs interface. With this
> > change each mockup chip is represented by a directory named after the
> > chip's device name under <debugfs mount point>/gpio-mockup/. Each line
> > is represented by a file using the line's offset as the name under the
> > chip's directory. Reading from the line's file yields the current
> > *value*, writing to the line's file changes the current "pull". Default
> > pull for mockup lines is down. More info on that can be found in the
> > comment added by this change to the gpio-mockup code.
> >
> > This is somewhat inspired by the idea of the gpio-simulator by
> > Uwe Kleine-König except that I strongly belive that when testing
> > certain user API code paths we should not be using the same paths for
> > verification. That's why there's a separate interface (debugfs) sharing
> > as little as possible with the character device that allows to check if
> > various operations (reading and setting values, events) work as
> > expected instead of two connected dummy chips sharing the same
> > interface.
> >
> > If accepted this will of course require major modification of user-space
> > tests in libgpiod once upstream.
> >
> > v1 -> v2:
> > - instead of providing the irq_sim_get_type() helper, move the irq type
> > logic into the simulator and provide a helper that allows users to specify
> > the type of the fired interrupt
> >
> > Bartosz Golaszewski (9):
> > irq/irq_sim: don't share the irq_chip structure between simulators
> > irq/irq_sim: use irq domain
> > irq/irq_sim: provide irq_sim_fire_type()
> > gpio: mockup: add locking
> > gpio: mockup: implement get_multiple()
> > gpio: mockup: don't create the debugfs link named after the label
> > gpio: mockup: change the type of 'offset' to unsigned int
> > gpio: mockup: change the signature of unlocked get/set helpers
> > gpio: mockup: rework debugfs interface
> >
> > drivers/gpio/gpio-mockup.c | 185 +++++++++++++++++++++++++++++++------
> > include/linux/irq_sim.h | 17 +++-
> > kernel/irq/irq_sim.c | 126 ++++++++++++++++++-------
> > 3 files changed, 263 insertions(+), 65 deletions(-)
> >
> > --
> > 2.19.1
> >
>
> Marc, Thomas,
>
> if there are no objections - could you please ack the three first
> patches and let me take them through the GPIO tree? I would really
> appreciate if we could have them in v5.1.

There are certainly a number of questions that have to be answered
before this can be merged. I can't find a rational for patch #1, and
patch #2 looks like a set of misuse of APIs.

At the very least, I'd like to see these questions answered, and the
code in patch #2 fixed.

Thanks,

M.
--
Without deviation from the norm, progress is not possible.

\
 
 \ /
  Last update: 2019-02-11 23:34    [W:0.205 / U:7.536 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site