public inbox for linux-gpio@vger.kernel.org
 help / color / mirror / Atom feed
From: Clemens Gruber <clemens.gruber@pqgruber.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: linux-gpio@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>
Subject: Re: Regression in v4.15 due to GPIO .get_multiple changes
Date: Mon, 15 Jan 2018 22:49:19 +0100	[thread overview]
Message-ID: <20180115214919.GA17751@archie.localdomain> (raw)
In-Reply-To: <20180115165155.GA20077@wunner.de>

Hi Lukas,

On Mon, Jan 15, 2018 at 05:51:55PM +0100, Lukas Wunner wrote:
> Hi Clemens,
> 
> thanks for reporting this and sorry for the breakage.
> 
> On Mon, Jan 15, 2018 at 04:35:48PM +0100, Clemens Gruber wrote:
> > I noticed a regression when testing the GPIOs on an i.MX6 with the
> > current v4.15-rc8 kernel.
> > 
> > When reading the input value of an internal GPIO, for example with
> > libgpiod's gpiod_line_get_value, strace shows that userspace blocks
> > indefinitely at:
> > ioctl(45, GPIOHANDLE_GET_LINE_VALUES_IOCTL
> > 
> > (The process consumes 100% CPU afterwards and can't be killed)
> > 
> > I looked at changes between v4.14 (working) and v4.15-rc8 (broken),
> > especially in drivers/gpio/gpio-{mxc,mmio}.c and identified the
> > following two commits to be responsible:
> > eec1d566cdf9 ("gpio: Introduce ->get_multiple callback")
> > 80057cb417b2 ("gpio-mmio: Use the new .get_multiple() callback")
> > 
> > Reverting both of them (they are interdependent) fixed the problem.
> 
> They're not interdependent, the latter depends on the former but not
> vice-versa.  Hence, reverting only the latter should be sufficient.
> Can you confirm this?

Yes, that's right.

> 
> Looking at 80057cb417b2, the only possible cause I can imagine is that
> the following somehow becomes an infinite loop.  Can you insert a printk
> to confirm this?

Yes, this loop is the cause. I tried to initialize bit = -1; and pass
bit + 1 to find_next_bit but I see you already suggested a much better
solution in the meantime and discovered more bugs. Thanks for your help!

> 
> +       while ((bit = find_next_bit(mask, gc->ngpio, bit)) != gc->ngpio) {
> +               if (gc->bgpio_dir & BIT(bit))
> +                       set_mask |= BIT(bit);
> +               else
> +                       get_mask |= BIT(bit);
> +       }
> 
> Is you platform big or little endian?

Little endian.

Cheers,
Clemens

      reply	other threads:[~2018-01-15 21:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 15:35 Regression in v4.15 due to GPIO .get_multiple changes Clemens Gruber
2018-01-15 16:51 ` Lukas Wunner
2018-01-15 21:49   ` Clemens Gruber [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180115214919.GA17751@archie.localdomain \
    --to=clemens.gruber@pqgruber.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=lukas@wunner.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox