On Mon, Mar 16, 2015 at 09:20:49PM -0700, Guenter Roeck wrote: > On Mon, Feb 16, 2015 at 01:09:51PM +0100, Wolfram Sang wrote: > > Hi Guenter, > > > > > I wonder where we are with thisp patch; I don't recall a reply to my previous > > > e-mail. > > > > Sorry for the late reply. I needed to recover from a HDD headcrash :( > > > > > Do you need some more time to think about it ? Otherwise I'll publish an > > > out-of-tree version of the at24 driver with the patch applied on github, > > > for those who might need the functionality provided by this patch. > > > > Your last mail made me aware of why we were missing each other before. I > > see your point now, but yes, still need to think about it. My plan is to > > have a decision until the 3.21 merge window. > > > Hi Wolfram, > > any news ? Yes :) The main misunderstanding we had before was: You were talking about multi-master safety between transfers, while I was thinking about multi-master safety between messages. While we need to guarantee this for the latter, you are right about the former, sadly. True multi-master safety between transfers is probably like a can of worms currently. Still, I think we have a race with your patch when having two read processes. If b) kicks in after a) has just set the eeprom pointer, a) will not read the data it wants. For that to prevent, we should take the adapter_lock during those two transfers needed for the read you implemented. My preferred solution would be to have __smbus_transfer like we have __i2c_transfer and then using that. Some mux code could also make use out of that. But if you are going to use adapter->algo->smbus_xfer() directly, well, then be it. Thanks, Wolfram
Attachment:
signature.asc
Description: Digital signature
