[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211213092948.440424427@linuxfoundation.org>
Date: Mon, 13 Dec 2021 10:30:16 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
stable@...r.kernel.org, Maxime Bizon <mbizon@...ebox.fr>,
Chris Packham <chris.packham@...iedtelesis.co.nz>,
Wolfram Sang <wsa@...nel.org>
Subject: [PATCH 5.15 101/171] i2c: mpc: Use atomic read and fix break condition
From: Chris Packham <chris.packham@...iedtelesis.co.nz>
commit a74c313aca266fab0d1d1a72becbb8b7b5286b6e upstream.
Maxime points out that the polling code in mpc_i2c_isr should use the
_atomic API because it is called in an irq context and that the
behaviour of the MCF bit is that it is 1 when the byte transfer is
complete. All of this means the original code was effectively a
udelay(100).
Fix this by using readb_poll_timeout_atomic() and removing the negation
of the break condition.
Fixes: 4a8ac5e45cda ("i2c: mpc: Poll for MCF")
Reported-by: Maxime Bizon <mbizon@...ebox.fr>
Signed-off-by: Chris Packham <chris.packham@...iedtelesis.co.nz>
Tested-by: Maxime Bizon <mbizon@...ebox.fr>
Signed-off-by: Wolfram Sang <wsa@...nel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
---
drivers/i2c/busses/i2c-mpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -636,7 +636,7 @@ static irqreturn_t mpc_i2c_isr(int irq,
status = readb(i2c->base + MPC_I2C_SR);
if (status & CSR_MIF) {
/* Wait up to 100us for transfer to properly complete */
- readb_poll_timeout(i2c->base + MPC_I2C_SR, status, !(status & CSR_MCF), 0, 100);
+ readb_poll_timeout_atomic(i2c->base + MPC_I2C_SR, status, status & CSR_MCF, 0, 100);
writeb(0, i2c->base + MPC_I2C_SR);
mpc_i2c_do_intr(i2c, status);
return IRQ_HANDLED;
Powered by blists - more mailing lists