wt., 10 gru 2019 o 15:55 Kent Gibson <warthog618@xxxxxxxxx> napisał(a): > > On Tue, Dec 10, 2019 at 03:11:12PM +0100, Bartosz Golaszewski wrote: > > wt., 10 gru 2019 o 03:15 Kent Gibson <warthog618@xxxxxxxxx> napisał(a): > > > > > > Restore the external behavior of gpio-mockup to what it was prior to the > > > change to using GPIO_LINE_DIRECTION. > > > > > > Signed-off-by: Kent Gibson <warthog618@xxxxxxxxx> > > > --- > > > > > > Fix a regression introduced in v5.5-rc1. > > > > > > The change to GPIO_LINE_DIRECTION reversed the polarity of the > > > dir field within gpio-mockup.c, but overlooked inverting the value on > > > initialization and when returned by gpio_mockup_get_direction. > > > The latter is a bug. > > > The former is a problem for tests which assume initial conditions, > > > specifically the mockup used to initialize chips with all lines as inputs. > > > That superficially appeared to be the case after the previous patch due > > > to the bug in gpio_mockup_get_direction. > > > > > > drivers/gpio/gpio-mockup.c | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c > > > index 56d647a30e3e..c4fdc192ea4e 100644 > > > --- a/drivers/gpio/gpio-mockup.c > > > +++ b/drivers/gpio/gpio-mockup.c > > > @@ -226,7 +226,7 @@ static int gpio_mockup_get_direction(struct gpio_chip *gc, unsigned int offset) > > > int direction; > > > > > > mutex_lock(&chip->lock); > > > - direction = !chip->lines[offset].dir; > > > + direction = chip->lines[offset].dir; > > > mutex_unlock(&chip->lock); > > > > > > return direction; > > > @@ -395,7 +395,7 @@ static int gpio_mockup_probe(struct platform_device *pdev) > > > struct gpio_chip *gc; > > > struct device *dev; > > > const char *name; > > > - int rv, base; > > > + int rv, base, i; > > > u16 ngpio; > > > > > > dev = &pdev->dev; > > > @@ -447,6 +447,9 @@ static int gpio_mockup_probe(struct platform_device *pdev) > > > if (!chip->lines) > > > return -ENOMEM; > > > > > > + for (i = 0; i < gc->ngpio; i++) > > > + chip->lines[i].dir = GPIO_LINE_DIRECTION_IN; > > > + > > > if (device_property_read_bool(dev, "named-gpio-lines")) { > > > rv = gpio_mockup_name_lines(dev, chip); > > > if (rv) > > > -- > > > 2.24.0 > > > > > > > Hi Kent, > > > > I was applying and testing your libgpiod series and noticed that the > > gpio-tools tests fail after applying patches 16 & 17 (with linux > > v5.5-rc1). Is this fix related to this? > > > > I don't think so. I've only been able to trip this problem with a > couple of corner cases in my Go uapi test suite. > I have been unable to reproduce it with the tools as it requires > multiple requests with the same chip fd, including an as-is, to trip. > > And running the libgpiod tests against v5.5-rc1 works for me. > Can you provide more details as to the errors you are seeing? > Hmm whatever that was, it's gone now. Must have been some leftovers from previous builds. All works now. > Btw, I was writing tests for your LINEINFO_WATCH patch v2, which I was > applying to v5.5-rc1, when I ran across this. That works ok if I > __packed the changed struct. These things can still change, so don't spend too much time on it yet. :) Since the lineinfo struct is not __packed, I'd prefer to not use it for any struct embedding it. I'll just add appropriate padding for 64-bit alignment. > And I can confirm that patch v2 doesn't isolate watches on different > chip fds. > Yeah, I'll fix this. Bart > Kent.