All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Linus Walleij <linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mike Rapoport <mike-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linus Walleij
	<linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
Subject: Re: [PATCH] MFD: Add U300 AB3100 core support v1
Date: Mon, 18 May 2009 16:44:40 +0200	[thread overview]
Message-ID: <20090518164440.2124a4fa@hyperion.delvare> (raw)
In-Reply-To: <63386a3d0905180722u282f0dd3ua62b119a1a6a97e8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Linus,

On Mon, 18 May 2009 16:22:36 +0200, Linus Walleij wrote:
> Here we have a problem. See above:
> msgs[0].addr = ab3100_i2c_client->addr + 1;
> 
> So this chip actually has two addresses. A "special" address
> to deal with test registers, one address up. The I2C framework
> assume all devices have one and one address only (which is
> of course mostly true).

No, the I2C framework doesn't assume this. All the I2C framework
assumes is that only one device can use a given address on any one I2C
segment (which seems reasonable.)

> Here is a special case. When the first device has registered,
> you know that the other address is available as well.
> 
> You could think of several ugly solutions:
> 
> * Keep using i2c_transfer() directly as we do now.
> 
> * Make a raw copy of the i2c_device with something like
>   memcpy(mock_client, i2c_client, sizeof(i2c_client);
>   mock_client->addr++;
>   then use i2c_master_send()
> 
> * Register a new i2c_device in board_info for the other
>   address while strictly speaking it is the same device, and
>   this will yield a lot of probing and synchronization code,
>   because writing the test registers is used when probing the
>   first device, so we have to wait for that device to be probed
>   before we can probe the other one etc.
> 
> Right now I lean toward the first alternative.

Neither is correct. Simply use i2c_new_dummy() on the second I2C
address, and keep a pointer to the instantiated i2c_client for future
use. Don't forget to call i2c_unregister_device() in your .remove()
method.

-- 
Jean Delvare

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Linus Walleij <linus.ml.walleij@gmail.com>
Cc: Mike Rapoport <mike@compulab.co.il>,
	linux-kernel@vger.kernel.org, sameo@linux.intel.com,
	linux-i2c@vger.kernel.org,
	Linus Walleij <linus.walleij@stericsson.com>
Subject: Re: [PATCH] MFD: Add U300 AB3100 core support v1
Date: Mon, 18 May 2009 16:44:40 +0200	[thread overview]
Message-ID: <20090518164440.2124a4fa@hyperion.delvare> (raw)
In-Reply-To: <63386a3d0905180722u282f0dd3ua62b119a1a6a97e8@mail.gmail.com>

Hi Linus,

On Mon, 18 May 2009 16:22:36 +0200, Linus Walleij wrote:
> Here we have a problem. See above:
> msgs[0].addr = ab3100_i2c_client->addr + 1;
> 
> So this chip actually has two addresses. A "special" address
> to deal with test registers, one address up. The I2C framework
> assume all devices have one and one address only (which is
> of course mostly true).

No, the I2C framework doesn't assume this. All the I2C framework
assumes is that only one device can use a given address on any one I2C
segment (which seems reasonable.)

> Here is a special case. When the first device has registered,
> you know that the other address is available as well.
> 
> You could think of several ugly solutions:
> 
> * Keep using i2c_transfer() directly as we do now.
> 
> * Make a raw copy of the i2c_device with something like
>   memcpy(mock_client, i2c_client, sizeof(i2c_client);
>   mock_client->addr++;
>   then use i2c_master_send()
> 
> * Register a new i2c_device in board_info for the other
>   address while strictly speaking it is the same device, and
>   this will yield a lot of probing and synchronization code,
>   because writing the test registers is used when probing the
>   first device, so we have to wait for that device to be probed
>   before we can probe the other one etc.
> 
> Right now I lean toward the first alternative.

Neither is correct. Simply use i2c_new_dummy() on the second I2C
address, and keep a pointer to the instantiated i2c_client for future
use. Don't forget to call i2c_unregister_device() in your .remove()
method.

-- 
Jean Delvare

  parent reply	other threads:[~2009-05-18 14:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14  8:29 [PATCH] MFD: Add U300 AB3100 core support v1 Linus Walleij
2009-05-14  8:29 ` Linus Walleij
     [not found] ` <63386a3d0905140129s5fd0f32cxde1114489678f012-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-05-14 10:50   ` Mike Rapoport
2009-05-14 10:50     ` Mike Rapoport
     [not found]     ` <4A0BF776.9030301-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org>
2009-05-18 14:22       ` Linus Walleij
2009-05-18 14:22         ` Linus Walleij
     [not found]         ` <63386a3d0905180722u282f0dd3ua62b119a1a6a97e8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-05-18 14:44           ` Jean Delvare [this message]
2009-05-18 14:44             ` Jean Delvare
     [not found]             ` <20090518164440.2124a4fa-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-05-18 17:18               ` Trilok Soni
2009-05-18 17:18                 ` Trilok Soni
2009-05-28  8:22       ` Trilok Soni
2009-05-28  8:22         ` Trilok Soni
2009-05-14 11:37   ` Samuel Ortiz
2009-05-14 11:37     ` Samuel Ortiz

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=20090518164440.2124a4fa@hyperion.delvare \
    --to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
    --cc=linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mike-UTxiZqZC01RS1MOuV/RT9w@public.gmane.org \
    --cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.