* [PATCH] clk: renesas: cpg-mssr: Fix reset control race condition
@ 2019-07-11 13:03 Geert Uytterhoeven
2019-07-12 9:19 ` Yoshihiro Shimoda
2019-07-22 22:05 ` Stephen Boyd
0 siblings, 2 replies; 3+ messages in thread
From: Geert Uytterhoeven @ 2019-07-11 13:03 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Yao Lihua, Yoshihiro Shimoda, Wolfram Sang, linux-clk,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
The module reset code in the Renesas CPG/MSSR driver uses
read-modify-write (RMW) operations to write to a Software Reset Register
(SRCRn), and simple writes to write to a Software Reset Clearing
Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware
User's Manuals.
However, this may cause a race condition when two devices are reset in
parallel: if the reset for device A completes in the middle of the RMW
operation for device B, device A may be reset again, causing subtle
failures (e.g. i2c timeouts):
thread A thread B
-------- --------
val = SRCRn
val |= bit A
SRCRn = val
delay
val = SRCRn (bit A is set)
SRSTCLRn = bit A
(bit A in SRCRn is cleared)
val |= bit B
SRCRn = val (bit A and B are set)
This can be reproduced on e.g. Salvator-XS using:
$ while true; do i2cdump -f -y 4 0x6A b > /dev/null; done &
$ while true; do i2cdump -f -y 2 0x10 b > /dev/null; done &
i2c-rcar e6510000.i2c: error -110 : 40000002
i2c-rcar e66d8000.i2c: error -110 : 40000002
According to the R-Car Gen3 Hardware Manual Errata for Rev.
0.80 of Feb 28, 2018, reflected in Rev. 1.00 of the R-Car Gen3 Hardware
User's Manual, writes to SRCRn do not require read-modify-write cycles.
Note that the R-Car Gen2 Hardware User's Manual has not been updated
yet, and still says a read-modify-write sequence is required. According
to the hardware team, the reset hardware block is the same on both R-Car
Gen2 and Gen3, though.
Hence fix the issue by replacing the read-modify-write operations on
SRCRn by simple writes.
Reported-by: Yao Lihua <Lihua.Yao@desay-svautomotive.com>
Fixes: 6197aa65c4905532 ("clk: renesas: cpg-mssr: Add support for reset control")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
So far I haven't been able to reproduce the issue on R-Car Gen2 (after
forcing i2c reset on Gen2, too). Perhaps my Koelsch doesn't have enough
CPU cores. What about Lager?
Hi Mike, Stephen,
As this is a bugfix, can you please take this directly, if accepted?
Thanks!
---
drivers/clk/renesas/renesas-cpg-mssr.c | 16 ++--------------
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c b/drivers/clk/renesas/renesas-cpg-mssr.c
index 52bbb9ce3807db31..d4075b13067429cd 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -572,17 +572,11 @@ static int cpg_mssr_reset(struct reset_controller_dev *rcdev,
unsigned int reg = id / 32;
unsigned int bit = id % 32;
u32 bitmask = BIT(bit);
- unsigned long flags;
- u32 value;
dev_dbg(priv->dev, "reset %u%02u\n", reg, bit);
/* Reset module */
- spin_lock_irqsave(&priv->rmw_lock, flags);
- value = readl(priv->base + SRCR(reg));
- value |= bitmask;
- writel(value, priv->base + SRCR(reg));
- spin_unlock_irqrestore(&priv->rmw_lock, flags);
+ writel(bitmask, priv->base + SRCR(reg));
/* Wait for at least one cycle of the RCLK clock (@ ca. 32 kHz) */
udelay(35);
@@ -599,16 +593,10 @@ static int cpg_mssr_assert(struct reset_controller_dev *rcdev, unsigned long id)
unsigned int reg = id / 32;
unsigned int bit = id % 32;
u32 bitmask = BIT(bit);
- unsigned long flags;
- u32 value;
dev_dbg(priv->dev, "assert %u%02u\n", reg, bit);
- spin_lock_irqsave(&priv->rmw_lock, flags);
- value = readl(priv->base + SRCR(reg));
- value |= bitmask;
- writel(value, priv->base + SRCR(reg));
- spin_unlock_irqrestore(&priv->rmw_lock, flags);
+ writel(bitmask, priv->base + SRCR(reg));
return 0;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* RE: [PATCH] clk: renesas: cpg-mssr: Fix reset control race condition
2019-07-11 13:03 [PATCH] clk: renesas: cpg-mssr: Fix reset control race condition Geert Uytterhoeven
@ 2019-07-12 9:19 ` Yoshihiro Shimoda
2019-07-22 22:05 ` Stephen Boyd
1 sibling, 0 replies; 3+ messages in thread
From: Yoshihiro Shimoda @ 2019-07-12 9:19 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd
Cc: Lihua Yao, Wolfram Sang, linux-clk, linux-renesas-soc,
linux-kernel, Hien Dang, Linh Phung
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Thursday, July 11, 2019 10:04 PM
>
> The module reset code in the Renesas CPG/MSSR driver uses
> read-modify-write (RMW) operations to write to a Software Reset Register
> (SRCRn), and simple writes to write to a Software Reset Clearing
> Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware
> User's Manuals.
>
> However, this may cause a race condition when two devices are reset in
> parallel: if the reset for device A completes in the middle of the RMW
> operation for device B, device A may be reset again, causing subtle
> failures (e.g. i2c timeouts):
>
> thread A thread B
> -------- --------
>
> val = SRCRn
> val |= bit A
> SRCRn = val
>
> delay
>
> val = SRCRn (bit A is set)
>
> SRSTCLRn = bit A
> (bit A in SRCRn is cleared)
>
> val |= bit B
> SRCRn = val (bit A and B are set)
>
> This can be reproduced on e.g. Salvator-XS using:
>
> $ while true; do i2cdump -f -y 4 0x6A b > /dev/null; done &
> $ while true; do i2cdump -f -y 2 0x10 b > /dev/null; done &
>
> i2c-rcar e6510000.i2c: error -110 : 40000002
> i2c-rcar e66d8000.i2c: error -110 : 40000002
>
> According to the R-Car Gen3 Hardware Manual Errata for Rev.
> 0.80 of Feb 28, 2018, reflected in Rev. 1.00 of the R-Car Gen3 Hardware
> User's Manual, writes to SRCRn do not require read-modify-write cycles.
>
> Note that the R-Car Gen2 Hardware User's Manual has not been updated
> yet, and still says a read-modify-write sequence is required. According
> to the hardware team, the reset hardware block is the same on both R-Car
> Gen2 and Gen3, though.
>
> Hence fix the issue by replacing the read-modify-write operations on
> SRCRn by simple writes.
>
> Reported-by: Yao Lihua <Lihua.Yao@desay-svautomotive.com>
> Fixes: 6197aa65c4905532 ("clk: renesas: cpg-mssr: Add support for reset control")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
Thank you for the patch! Our test team tested this patch, so
Tested-by: Linh Phung <linh.phung.jy@renesas.com>
> So far I haven't been able to reproduce the issue on R-Car Gen2 (after
> forcing i2c reset on Gen2, too). Perhaps my Koelsch doesn't have enough
> CPU cores. What about Lager?
According to the test team, Lager also could not reproduce this issue.
Should we investigate it why?
Best regards,
Yoshihiro Shimoda
> Hi Mike, Stephen,
>
> As this is a bugfix, can you please take this directly, if accepted?
>
> Thanks!
> ---
> drivers/clk/renesas/renesas-cpg-mssr.c | 16 ++--------------
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c b/drivers/clk/renesas/renesas-cpg-mssr.c
> index 52bbb9ce3807db31..d4075b13067429cd 100644
> --- a/drivers/clk/renesas/renesas-cpg-mssr.c
> +++ b/drivers/clk/renesas/renesas-cpg-mssr.c
> @@ -572,17 +572,11 @@ static int cpg_mssr_reset(struct reset_controller_dev *rcdev,
> unsigned int reg = id / 32;
> unsigned int bit = id % 32;
> u32 bitmask = BIT(bit);
> - unsigned long flags;
> - u32 value;
>
> dev_dbg(priv->dev, "reset %u%02u\n", reg, bit);
>
> /* Reset module */
> - spin_lock_irqsave(&priv->rmw_lock, flags);
> - value = readl(priv->base + SRCR(reg));
> - value |= bitmask;
> - writel(value, priv->base + SRCR(reg));
> - spin_unlock_irqrestore(&priv->rmw_lock, flags);
> + writel(bitmask, priv->base + SRCR(reg));
>
> /* Wait for at least one cycle of the RCLK clock (@ ca. 32 kHz) */
> udelay(35);
> @@ -599,16 +593,10 @@ static int cpg_mssr_assert(struct reset_controller_dev *rcdev, unsigned long id)
> unsigned int reg = id / 32;
> unsigned int bit = id % 32;
> u32 bitmask = BIT(bit);
> - unsigned long flags;
> - u32 value;
>
> dev_dbg(priv->dev, "assert %u%02u\n", reg, bit);
>
> - spin_lock_irqsave(&priv->rmw_lock, flags);
> - value = readl(priv->base + SRCR(reg));
> - value |= bitmask;
> - writel(value, priv->base + SRCR(reg));
> - spin_unlock_irqrestore(&priv->rmw_lock, flags);
> + writel(bitmask, priv->base + SRCR(reg));
> return 0;
> }
>
> --
> 2.17.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] clk: renesas: cpg-mssr: Fix reset control race condition
2019-07-11 13:03 [PATCH] clk: renesas: cpg-mssr: Fix reset control race condition Geert Uytterhoeven
2019-07-12 9:19 ` Yoshihiro Shimoda
@ 2019-07-22 22:05 ` Stephen Boyd
1 sibling, 0 replies; 3+ messages in thread
From: Stephen Boyd @ 2019-07-22 22:05 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette
Cc: Yao Lihua, Yoshihiro Shimoda, Wolfram Sang, linux-clk,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Quoting Geert Uytterhoeven (2019-07-11 06:03:59)
> The module reset code in the Renesas CPG/MSSR driver uses
> read-modify-write (RMW) operations to write to a Software Reset Register
> (SRCRn), and simple writes to write to a Software Reset Clearing
> Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware
> User's Manuals.
>
> However, this may cause a race condition when two devices are reset in
> parallel: if the reset for device A completes in the middle of the RMW
> operation for device B, device A may be reset again, causing subtle
> failures (e.g. i2c timeouts):
>
> thread A thread B
> -------- --------
Applied to clk-fixes
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-07-22 22:05 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-11 13:03 [PATCH] clk: renesas: cpg-mssr: Fix reset control race condition Geert Uytterhoeven
2019-07-12 9:19 ` Yoshihiro Shimoda
2019-07-22 22:05 ` Stephen Boyd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).