linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters
Date: Wed, 18 Mar 2015 14:27:07 +0100	[thread overview]
Message-ID: <20150318132707.GD3580@katana> (raw)
In-Reply-To: <20150317042049.GA6765@roeck-us.net>

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-03-18 13:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04 16:23 [PATCH] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters Guenter Roeck
2015-02-04 17:47 ` Wolfram Sang
2015-02-04 19:08   ` Guenter Roeck
2015-02-04 23:35     ` Wolfram Sang
2015-02-05  0:26       ` Guenter Roeck
2015-02-05 14:40         ` Wolfram Sang
2015-02-05 17:53           ` Guenter Roeck
     [not found]             ` <20150205175326.GA26691-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-02-12  4:01               ` Guenter Roeck
2015-02-16 12:09                 ` Wolfram Sang
2015-02-16 15:37                   ` Guenter Roeck
2015-03-17  4:20                   ` Guenter Roeck
2015-03-18 13:27                     ` Wolfram Sang [this message]
2015-03-19  3:24                       ` Guenter Roeck
     [not found]                         ` <550A4162.8000009-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-03-19  8:16                           ` Wolfram Sang
2015-03-19 13:30                             ` Guenter Roeck
2015-03-19 17:43                             ` Guenter Roeck
2015-03-19 21:39                               ` Wolfram Sang
2015-03-25 14:11                                 ` Guenter Roeck
     [not found]                                   ` <5512C213.7030705-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-03-25 16:15                                     ` Wolfram Sang
2015-03-25 16:37                                       ` Guenter Roeck
2015-03-27  8:09                                   ` Wolfram Sang
2015-03-27 12:51                                     ` Guenter Roeck
2015-03-27 13:01                                       ` Wolfram Sang
2015-03-27 13:14                                         ` Guenter Roeck
2015-03-27 15:27                                           ` Wolfram Sang
2015-03-27 15:42                                             ` Guenter Roeck
2015-02-04 20:33   ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150318132707.GD3580@katana \
    --to=wsa@the-dreams.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).