From patchwork Mon Aug 22 13:29:32 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bartosz Golaszewski X-Patchwork-Id: 74425 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp1570288qga; Mon, 22 Aug 2016 06:29:41 -0700 (PDT) X-Received: by 10.98.104.71 with SMTP id d68mr42789293pfc.163.1471872581612; Mon, 22 Aug 2016 06:29:41 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id zh9si25942023pab.208.2016.08.22.06.29.41; Mon, 22 Aug 2016 06:29:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755356AbcHVN3i (ORCPT + 27 others); Mon, 22 Aug 2016 09:29:38 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:36798 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755223AbcHVN3g (ORCPT ); Mon, 22 Aug 2016 09:29:36 -0400 Received: by mail-wm0-f48.google.com with SMTP id q128so121076358wma.1 for ; Mon, 22 Aug 2016 06:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=Q9zcFXBQDKqlX2YpCM1ZQvlqdYJauS50tERGdRndTfU=; b=BRw6K3dgfhs6yXc7Zbw6ZrEthcT/+vWNvRi0ubXERtA0Ozjxwb0yVjrPJsM047qf/6 yG9Dfk6YFx76cmAiOhosaY7ryQqx36KOKKXXXFXVgrB/CwXX5Gxn9I8kXUub3H+9ZkyY So6hZ2dq7+5o5jpINjMJG7eT/Mh+ItbJ1cff+wqG8E7/R0qAveJsplBBv3tXIgXBfQem mPz8j2VE7BHkzm2zVoTyYAJa2peiIDAWc4oN0IRwLK3x+/o0Ac9kbd8nh4A2kipw/X2Z AB+kIc3ty/dBHRT32dCaZFJdgkKEt/2AiLcUCEqjETrRD9uW47oiykl5uBDMJyUkch8v Jkzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=Q9zcFXBQDKqlX2YpCM1ZQvlqdYJauS50tERGdRndTfU=; b=QSliGe1CyzlYk/3CNSZAy8XdzTtkJgJt+thuFCoe3tNt2GOBH697sPKH4oLIm9SLnM 7giPmVVwEPBhzYZB5pB66br3LRLceuQ0PfhWy94JHGgOE42yf1PfMt7M/QSOBmEJ8W7O 6YT98cNxn/k3QuJnHxdm/GIC2vQE6r+1+ZL0awSKNbcbXGCvsywpydKxRLSrRVHckBqV i0B+d0bYCeMJ5y77rz9HA+ktLXst0FdaweIFxK+IvoNXXhSiuTCwWK5xQ0DBqzHm+3Wx JYb+3cJ6b8tY/Hbzd48EVs0gYsjpV96Oo785oriub0QvnbcAP2XU1dP0gMd7AvHEhxs0 KwKA== X-Gm-Message-State: AEkooutDtQYGyiP8ZVukDQ9LD8aE5/iK2jT7bYKI2ojDPrnFgCBwQB7PiUA6ZL6Q54MGk2gB X-Received: by 10.28.206.8 with SMTP id e8mr14556740wmg.57.1471872575032; Mon, 22 Aug 2016 06:29:35 -0700 (PDT) Received: from localhost.localdomain ([90.63.244.31]) by smtp.gmail.com with ESMTPSA id ly9sm24045409wjb.44.2016.08.22.06.29.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 06:29:34 -0700 (PDT) From: Bartosz Golaszewski To: Linus Walleij , Alexandre Courbot Cc: linux-gpio , LKML , Bartosz Golaszewski Subject: [PATCH] i2c: pca953x: fix a lockdep warning Date: Mon, 22 Aug 2016 15:29:32 +0200 Message-Id: <1471872572-25818-1-git-send-email-bgolaszewski@baylibre.com> X-Mailer: git-send-email 2.1.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- drivers/gpio/gpio-pca953x.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) -- 2.7.4 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));