Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1380751

Re: [PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared

Path csiph.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!news.albasani.net!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod
From Krzysztof Kozlowski <k.kozlowski@samsung.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
Date Sun, 17 Apr 2016 15:40:03 +0200
Message-ID <roV5F-54M-19@gated-at.bofh.it> (permalink)
References <roJxw-4hm-1@gated-at.bofh.it> <roJxw-4hm-5@gated-at.bofh.it>
X-Original-To Javier Martinez Canillas <javier@osg.samsung.com>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jZgP2WZFPkHgH9Hfeh76+jBRq1GF9PBmCU79B4iEMSo=; b=iKARGTuNpA5erHJwZ1lq8gpNWWB8gFIMWP0Ez0cN1GhioJUhSU1hc7TOh9pd6fnV+9 0QpVykPZJauxKYssAA1dq2g6MRT1n3OKCDrLTH3nBUiyiRLUdgMiS0m3Y/etBOgTlZ2z rXdOIPQplOB6hX0MevcZTe5sSwGeSV7h2uf1bGciWJfQus7PIPRHIKv/uU8M6d/YZcgJ Kv5A9xgMwpRo8+tfljWk5f6ReCmam0Ozs9FmHqf3/BbPmMVJXFkZp22Cj+ZmiEV3haHV l41TZGe21oddOy25UIPuYpzESMBVLF2WK3K9G2B1fCTTFeQjuYNeG2Ev6VNrJ53GwJrT C5gQ==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=jZgP2WZFPkHgH9Hfeh76+jBRq1GF9PBmCU79B4iEMSo=; b=EHFQOrCJ9RprHNXmErHjOURRQqGf2+h7W9/mWmw4+XfZp8s/kTDLsRhVgFug8GuVQf H8voiH9Mrf8QmeVuvKMH4LROjy48RH7BzucqDWw+o2uBAk88Dhymy8JpPd3lP1809w3V 7oE6ulqs1G/8hBvzs0PVJG2GhzJclQpJ5pBP0bSxSrzqor6WizXI5rwuHH7uVjd/vlGy rd7TaBHhDNkxDbJ5V9GcyUkHVaeJixw5AWk/2KMpaLhAlHYX3YlbExQbxXe+2vEMG4s3 B8IRxXQTQuF9dmvn0iBdXzbQ8KLML5cSFn8IfTwA5xGqRrhMOAbqyNFkTcy//Xfb9ARU cRSA==
X-Gm-Message-State AOPr4FV9GuqhsRzLVkZUksUTfBDbhOZfZdk9n4HZb3FB8LDCzpsnb63xsXdcDRX1vQ+05Q==
X-Received by 10.25.43.1 with SMTP id r1mr10321634lfr.63.1460900063906; Sun, 17 Apr 2016 06:34:23 -0700 (PDT)
MIME-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Disposition inline
User-Agent Mutt/1.5.23 (2014-03-12)
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 58
Organization linux.* mail to news gateway
X-Original-Cc linux-kernel@vger.kernel.org, Anand Moon <linux.amoon@gmail.com>, Kukjin Kim <kgene@kernel.org>, linux-samsung-soc@vger.kernel.org, Wolfram Sang <wsa@the-dreams.de>, Krzysztof Kozlowski <k.kozlowski@samsung.com>, linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org
X-Original-Date Sun, 17 Apr 2016 15:34:21 +0200
X-Original-Message-ID <20160417133421.GC3620@kozik-lap>
X-Original-References <1460855693-28225-1-git-send-email-javier@osg.samsung.com> <1460855693-28225-2-git-send-email-javier@osg.samsung.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1380751

Show key headers only | View raw


On Sat, Apr 16, 2016 at 09:14:53PM -0400, Javier Martinez Canillas wrote:
> The exynos5 I2C controller driver always prepares and enables a clock
> before using it and then disables unprepares it when the clock is not
> used anymore.
> 
> But this can cause a possible ABBA deadlock in some scenarios since a
> driver that uses regmap to access its I2C registers, will first grab
> the regmap lock and then the I2C xfer function will grab the prepare
> lock when preparing the I2C clock. But since the clock driver also
> uses regmap for I2C accesses, preparing a clock will first grab the
> prepare lock and then the regmap lock when using the regmap API.
> 
> An example of this happens on the Exynos5422 Odroid XU4 board where a
> s2mps11 PMIC is used and both the s2mps11 regulators and clk drivers
> share the same I2C regmap.
> 
> The possible deadlock is reported by the kernel lockdep:
> 
>   Possible unsafe locking scenario:
> 
>         CPU0                    CPU1
>         ----                    ----
>    lock(sec_core:428:(regmap)->lock);
>                                 lock(prepare_lock);
>                                 lock(sec_core:428:(regmap)->lock);
>    lock(prepare_lock);
> 
>   *** DEADLOCK ***
> 
> Fix it by leaving the code prepared on probe and use {en,dis}able in
> the I2C transfer function.
> 
> This patch is similar to commit 34e81ad5f0b6 ("i2c: s3c2410: fix ABBA
> deadlock by keeping clock prepared") that fixes the same bug in other
> driver for an I2C controller found in Samsung SoCs.
> 
> Reported-by: Anand Moon <linux.amoon@gmail.com>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Anand Moon <linux.amoon@gmail.com>
> Tested-by: Anand Moon <linux.amoon@gmail.com>
> 
> ---
> 
> Changes in v2:
> - Add Anand Moon's Reviewed and Tested by tags.
> - Unprepare the clock on suspend. Suggested by Krzysztof Kozlowski.
> 
>  drivers/i2c/busses/i2c-exynos5.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)



Hi,

Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v2 1/2] i2c: exynos5: Check clk_prepare_enable() return value Javier Martinez Canillas <javier@osg.samsung.com> - 2016-04-17 03:20 +0200
  [PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared Javier Martinez Canillas <javier@osg.samsung.com> - 2016-04-17 03:20 +0200
    Re: [PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by  keeping I2C clock prepared Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-04-17 15:40 +0200
    Re: [PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by  keeping I2C clock prepared Wolfram Sang <wsa@the-dreams.de> - 2016-04-22 15:40 +0200
  Re: [PATCH v2 1/2] i2c: exynos5: Check clk_prepare_enable() return  value Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-04-17 15:40 +0200

csiph-web