From patchwork Mon Aug 29 08:33:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bartosz Golaszewski X-Patchwork-Id: 74883 Delivered-To: patch@linaro.org Received: by 10.140.29.52 with SMTP id a49csp1514993qga; Mon, 29 Aug 2016 01:33:47 -0700 (PDT) X-Received: by 10.66.165.67 with SMTP id yw3mr30954423pab.8.1472459626984; Mon, 29 Aug 2016 01:33:46 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z10si38017987paz.120.2016.08.29.01.33.46; Mon, 29 Aug 2016 01:33:46 -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 S1756756AbcH2Idc (ORCPT + 27 others); Mon, 29 Aug 2016 04:33:32 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:35125 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756636AbcH2Ida (ORCPT ); Mon, 29 Aug 2016 04:33:30 -0400 Received: by mail-wm0-f43.google.com with SMTP id f65so68249095wmi.0 for ; Mon, 29 Aug 2016 01:33:29 -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=z11I6n4BTWGFvYCKe2995ce3ISgwHUXgJaQ/oFLyjkY=; b=kZVZ18r/OUVylmvReZJdB6rwRBrIoGV5hQwG/t1iVFsnPxgtp+pBGVBLpa525YkBms V31d+JOqYrJS9Dx7XrmbqTBTJc5pS+epb9Y2drny0zkuyHyNHEtdQielo8XnGaUjGoBi jb8qoi7VKZWDKOE0QtSH91hvfPI2SjHb8NYXsDPCGgu22+SJ/kx3M37ycLH4WwBf1CpN 5EzScl+6rD+sQR51FfI17kiSmMvDR6+ts+115k7AHDrRY5fDd5hsMRqxMzmagS1nu9lR 9q9uvKtCLHvSLaXYo3wg0Qjxef4dOan72YFb1nGcRTfE9KjzZwaz6uAxFqydg8ojG5tI HLPA== 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=z11I6n4BTWGFvYCKe2995ce3ISgwHUXgJaQ/oFLyjkY=; b=ZLs4zQCuGTKJtu5UkqG852MQiztwfGU7WsCSvRMEiZ95a8RLSu57yVjIF16vvqAWyV xeZXu/qDxyFWtjVppNx8p5AkyESaPTMfeham+1hw1+7aGC+1tDrn0S/XkKQAU5WfWWjt DBBEk2ORXhQxw/A4at34W3bSmVekexgRLm5Jfkl/mG/0oJ7a1huMTK9wStxS+CQbmlVj DAl0P0aoz0xDcr5315vUBPup8KQofb7tjMmXbHo0m0d0ACTMq/R+KOanvv4C8Gxp7kUb yAHBGbGPSnQ9DJiQuI/EENqTM48qZPar7jIZtgO7RXuBJxmgx62rybON8N89uX/MksoW RnOQ== X-Gm-Message-State: AE9vXwOGfAhzC+A33NYvl7SDjABd/gI9eABirwHChfwQ3HxNj81BiFWn+gIV9C9GnbFuNxQ6 X-Received: by 10.28.56.195 with SMTP id f186mr8833051wma.59.1472459608454; Mon, 29 Aug 2016 01:33:28 -0700 (PDT) Received: from localhost.localdomain ([90.63.244.31]) by smtp.gmail.com with ESMTPSA id a194sm12294996wmd.24.2016.08.29.01.33.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Aug 2016 01:33:27 -0700 (PDT) From: Bartosz Golaszewski To: Linus Walleij , Alexandre Courbot , Andy Shevchenko , Vignesh R , Yong Li , Geert Uytterhoeven Cc: linux-gpio , LKML , Bartosz Golaszewski Subject: [PATCH v2] gpio: pca953x: fix a lockdep warning Date: Mon, 29 Aug 2016 10:33:20 +0200 Message-Id: <1472459600-10815-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 an I2C-GPIO expander framework that would unduplicate common code for all drivers. Signed-off-by: Bartosz Golaszewski --- v1 -> v2: - tweaked the commit message - expanded the comment drivers/gpio/gpio-pca953x.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.7.4 diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index 02f2a56..3387bdd 100644 --- a/drivers/gpio/gpio-pca953x.c +++ b/drivers/gpio/gpio-pca953x.c @@ -329,7 +329,15 @@ 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. + * + * We're using the GPIO base number to distinguish the lock + * subclasses. + */ + mutex_lock_nested(&chip->i2c_lock, chip->gpio_start); if (val) reg_val = chip->reg_output[off / BANK_SZ] | (1u << (off % BANK_SZ));