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


Groups > linux.kernel > #1380675 > unrolled thread

[PATCH v2 1/2] i2c: exynos5: Check clk_prepare_enable() return value

Started byJavier Martinez Canillas <javier@osg.samsung.com>
First post2016-04-17 03:20 +0200
Last post2016-04-17 15:40 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [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

#1380675 — [PATCH v2 1/2] i2c: exynos5: Check clk_prepare_enable() return value

FromJavier Martinez Canillas <javier@osg.samsung.com>
Date2016-04-17 03:20 +0200
Subject[PATCH v2 1/2] i2c: exynos5: Check clk_prepare_enable() return value
Message-ID<roJxw-4hm-1@gated-at.bofh.it>
The clk_prepare_enable() function can fail so check the return value
and propagate the error to the caller in case of a failure.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---

Changes in v2: None

 drivers/i2c/busses/i2c-exynos5.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index b29c7500461a..ebbcba3de20a 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -671,7 +671,9 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
 		return -EIO;
 	}
 
-	clk_prepare_enable(i2c->clk);
+	ret = clk_prepare_enable(i2c->clk);
+	if (ret)
+		return ret;
 
 	for (i = 0; i < num; i++, msgs++) {
 		stop = (i == num - 1);
@@ -747,7 +749,9 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
 		return -ENOENT;
 	}
 
-	clk_prepare_enable(i2c->clk);
+	ret = clk_prepare_enable(i2c->clk);
+	if (ret)
+		return ret;
 
 	mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	i2c->regs = devm_ioremap_resource(&pdev->dev, mem);
@@ -830,7 +834,9 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
 	struct exynos5_i2c *i2c = platform_get_drvdata(pdev);
 	int ret = 0;
 
-	clk_prepare_enable(i2c->clk);
+	ret = clk_prepare_enable(i2c->clk);
+	if (ret)
+		return ret;
 
 	ret = exynos5_hsi2c_clock_setup(i2c);
 	if (ret) {
-- 
2.5.5

[toc] | [next] | [standalone]


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

FromJavier Martinez Canillas <javier@osg.samsung.com>
Date2016-04-17 03:20 +0200
Subject[PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
Message-ID<roJxw-4hm-5@gated-at.bofh.it>
In reply to#1380675
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(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index ebbcba3de20a..f54ece8fce78 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -671,7 +671,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
 		return -EIO;
 	}
 
-	ret = clk_prepare_enable(i2c->clk);
+	ret = clk_enable(i2c->clk);
 	if (ret)
 		return ret;
 
@@ -697,7 +697,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
 	}
 
  out:
-	clk_disable_unprepare(i2c->clk);
+	clk_disable(i2c->clk);
 	return ret;
 }
 
@@ -803,6 +803,10 @@ static int exynos5_i2c_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, i2c);
 
+	clk_disable(i2c->clk);
+
+	return 0;
+
  err_clk:
 	clk_disable_unprepare(i2c->clk);
 	return ret;
@@ -814,6 +818,8 @@ static int exynos5_i2c_remove(struct platform_device *pdev)
 
 	i2c_del_adapter(&i2c->adap);
 
+	clk_unprepare(i2c->clk);
+
 	return 0;
 }
 
@@ -825,6 +831,8 @@ static int exynos5_i2c_suspend_noirq(struct device *dev)
 
 	i2c->suspended = 1;
 
+	clk_unprepare(i2c->clk);
+
 	return 0;
 }
 
@@ -845,7 +853,7 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
 	}
 
 	exynos5_i2c_init(i2c);
-	clk_disable_unprepare(i2c->clk);
+	clk_disable(i2c->clk);
 	i2c->suspended = 0;
 
 	return 0;
-- 
2.5.5

[toc] | [prev] | [next] | [standalone]


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

FromKrzysztof Kozlowski <k.kozlowski@samsung.com>
Date2016-04-17 15:40 +0200
SubjectRe: [PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
Message-ID<roV5F-54M-19@gated-at.bofh.it>
In reply to#1380677
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

[toc] | [prev] | [next] | [standalone]


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

FromWolfram Sang <wsa@the-dreams.de>
Date2016-04-22 15:40 +0200
SubjectRe: [PATCH v2 2/2] i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
Message-ID<rqJtp-2Ga-31@gated-at.bofh.it>
In reply to#1380677

[Multipart message — attachments visible in raw view] — 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

Squashed both patches into one for easier backporting, added stable and
applied to for-current, thanks!

[toc] | [prev] | [next] | [standalone]


#1380753 — Re: [PATCH v2 1/2] i2c: exynos5: Check clk_prepare_enable() return value

FromKrzysztof Kozlowski <k.kozlowski@samsung.com>
Date2016-04-17 15:40 +0200
SubjectRe: [PATCH v2 1/2] i2c: exynos5: Check clk_prepare_enable() return value
Message-ID<roV5G-54M-33@gated-at.bofh.it>
In reply to#1380675
On Sat, Apr 16, 2016 at 09:14:52PM -0400, Javier Martinez Canillas wrote:
> The clk_prepare_enable() function can fail so check the return value
> and propagate the error to the caller in case of a failure.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> 
> Changes in v2: None
> 
>  drivers/i2c/busses/i2c-exynos5.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>


Hi,

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

Best regards,
Krzysztof

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web