On Thu, Jun 2, 2016 at 7:45 PM, Jean Delvare <jdelvare@xxxxxxx> wrote: > > On Wed, 1 Jun 2016 17:38:27 +0800, Daniel Kurtz wrote: > > On Wed, Jun 1, 2016 at 5:37 PM, Jean Delvare <jdelvare@xxxxxxx> wrote: > > > > > > Hi Daniel, > > > > > > On Mon, 30 May 2016 22:07:55 +0800, Daniel Kurtz wrote: > > > > On Wed, May 25, 2016 at 3:37 PM, Jean Delvare <jdelvare@xxxxxxx> wrote: > > > > > The interrupt handling code makes it look like several status values > > > > > may be merged together before being processed, while this will never > > > > > happen. Change from bit-wise OR to simple assignment to make it more > > > > > obvious and avoid misunderstanding. > > > > > > > > > > Signed-off-by: Jean Delvare <jdelvare@xxxxxxx> > > > > > Cc: Daniel Kurtz <djkurtz@xxxxxxxxxxxx> > > > > > Cc: Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx> > > > > > Cc: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > > > > Cc: Wolfram Sang <wsa@xxxxxxxxxxxxx> > > > > > --- > > > > > Daniel, was there any reason for this bit-wise OR, which I may be > > > > > missing? > > > > > > > > The only thing I can think of is that I didn't want to assume that we > > > > would always clear priv->status before another interrupt arrived. > > > > > > Well my question is quite clear: can this actually happen? I can't see > > > how. > > > > I have no idea. You'd have to ask Intel, I guess. > > You wrote the code based on public documentation, I thought you would > know. But if you can't be bothered, never mind, I'll trust my > understanding of the code. Here is the documentation: http://www.intel.com/content/dam/doc/datasheet/io-controller-hub-6-datasheet.pdf Page 570 I thought maybe there were situations where you could get INTR and an error condition, but I don't see anything like that in the documentation, so I think you are right and only one bit will be set at a time. Reviewed-by: Daniel Kurtz <djkurtz@xxxxxxxxxxxx> > -- > Jean Delvare > SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
