Message ID | 1471872572-25818-1-git-send-email-bgolaszewski@baylibre.com |
---|---|
State | New |
Headers | show |
On Mon, Aug 22, 2016 at 3:29 PM, Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote: The $SUBJECT of this patch should be something beginning with gpio: atleast. Apart from that it'd be nice to get review from the other people using the PCA953x driver, since it's rather complex. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2016-08-22 16:06 GMT+02:00 Linus Walleij <linus.walleij@linaro.org>: > On Mon, Aug 22, 2016 at 3:29 PM, Bartosz Golaszewski > <bgolaszewski@baylibre.com> wrote: > > The $SUBJECT of this patch should be something beginning with > gpio: atleast. > Oops, it was supposed to be gpio, but I was working on i2c stuff and mixed it. I'll fix that in v2 after getting some reviews. Best regards, Bartosz Golaszewski > Apart from that it'd be nice to get review from the other people using > the PCA953x driver, since it's rather complex. > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 22, 2016 at 4:15 PM, Bartosz Golaszewski <bgolaszewski@baylibre.com> wrote: > 2016-08-22 16:06 GMT+02:00 Linus Walleij <linus.walleij@linaro.org>: >> On Mon, Aug 22, 2016 at 3:29 PM, Bartosz Golaszewski >> <bgolaszewski@baylibre.com> wrote: >> >> The $SUBJECT of this patch should be something beginning with >> gpio: atleast. >> > > Oops, it was supposed to be gpio, but I was working on i2c stuff and > mixed it. I'll fix that in v2 after getting some reviews. OK! Pls include the people I added on the To: line when you repost. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 02f2a56..9086079 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -329,7 +329,12 @@ static void pca953x_gpio_set_value(struct gpio_chip *gc, unsigned off, int val) u8 reg_val; int ret, offset = 0; - mutex_lock(&chip->i2c_lock); + /* + * We're using mutex_lock_nested() here to avoid a lockdep warning + * when there are two pca953x expanders, of which one is used to + * control an i2c gpio mux. + */ + mutex_lock_nested(&chip->i2c_lock, chip->gpio_start); if (val) reg_val = chip->reg_output[off / BANK_SZ] | (1u << (off % BANK_SZ));
If an I2C GPIO multiplexer is driven by a GPIO provided by an expander when there's a second expander using the same device driver on one of the I2C bus segments, lockdep prints a deadlock warning when trying to set the direction or the value of the GPIOs provided by the second expander. The below diagram presents the setup: - - - - - ------- --------- Bus segment 1 | | | | | |--------------- Devices | | SCL/SDA | | | | | Linux |-----------| I2C MUX | - - - - - | | | | | Bus segment 2 | | | | |------------------- ------- | --------- | | | - - - - - ------------ | MUX GPIO | | | | | Devices | GPIO | | | | | Expander 1 |---- - - - - - | | | ------------ | SCL/SDA | ------------ | | | GPIO | | Expander 2 | | | ------------ The reason for lockdep warning is that we take the chip->i2c_lock in pca953x_gpio_set_value() or pca953x_gpio_direction_output() and then come right back to pca953x_gpio_set_value() when the GPIO mux kicks in. The locks actually protect different expanders, but lockdep doesn't see this and says: Possible unsafe locking scenario: CPU0 ---- lock(&chip->i2c_lock); lock(&chip->i2c_lock); *** DEADLOCK *** May be due to missing lock nesting notation To shut lockdep up, use mutex_lock_nested() and use the GPIO base number as the subclass argument (it has the same type). NOTE: this only fixes a specific issue we're experiencing with our setup. The problem would probably occur as well with other I2C expanders under similar circumstances. A proper fix would probably be to implement a GPIO expander framework that would unduplicate common code for all drivers. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> --- drivers/gpio/gpio-pca953x.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)