i2c: mpc: Use atomic read and fix break condition
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: 4a8ac5e45c ("i2c: mpc: Poll for MCF")
Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Tested-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
			
			
This commit is contained in:
		
							parent
							
								
									b503de239f
								
							
						
					
					
						commit
						a74c313aca
					
				| @ -636,7 +636,7 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id) | ||||
| 	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; | ||||
|  | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user