Hi Jason,
On 08/10/2014 00:09, Jason Gunthorpe wrote:
On Tue, Oct 07, 2014 at 10:03:04PM +0200, Christophe Ricard wrote:
Remove useless i2c read on TPM_INT_ENABLE and TPM_INT_STATUS
Signed-off-by: Christophe Ricard <[email protected]>
drivers/char/tpm/tpm_i2c_stm_st33.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/char/tpm/tpm_i2c_stm_st33.c
b/drivers/char/tpm/tpm_i2c_stm_st33.c
index e99bb78..660ff8b 100644
+++ b/drivers/char/tpm/tpm_i2c_stm_st33.c
@@ -187,7 +187,6 @@ static u8 clear_interruption(struct tpm_stm_dev *tpm_dev)
I2C_READ_DATA(tpm_dev, TPM_INT_STATUS, &interrupt, 1);
I2C_WRITE_DATA(tpm_dev, TPM_INT_STATUS, &interrupt, 1);
- I2C_READ_DATA(tpm_dev, TPM_INT_STATUS, &interrupt, 1);
Hum, I don't have a chip datasheet here, but is this really useless?
It looks like a synchronizing read to me - ie completing the read at
the CPU is enough to know that the TPM itself has processed the prior
write and is known to have lowered the level triggered interrupt..
A read like this is the sort of thing that you'd expect to avoid the
udelay in your 'Add delay before release_locality to make sure irq are
cleared'
I believe this is completely 2 different things. The delay before the
release locality is to make sure that the isr will be service before
release_locality to guarantee
that any pending interrupt are cleared while the locality is active.
Here i just want to save 2 i2c transaction as only 1 write is enough to
get the register change as effective.
Jason
Best Regards
Christophe
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
