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 <christophe-h.ricard@xxxxxx> > 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' Jason -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
